(Jurnal) Implementasi dan Analisis Server Clustering Menggunakan Cluster File System pada SAN...

IMPLEMENTASI DAN ANALISIS

SERVER CLUSTERING MENGGUNAKAN CLUSTER FILE SYSTEM PADA SAN (STORAGE AREA

NETWORK) BERBASIS iSCSI UNTUK LAYANAN CLOUD STORAGE

Firdauska Darya Satria S.Sy.1 Tody Ariefianto W, ST,MT.2 Leanna Vidya Yovita, ST.,M.T.3

1,2,3Fakultas Elektro dan Komunikasi – Universitas Telkom

Jl. Telekomunikasi, Dayeuh Kolot Bandung 40257 Indonesia

2014

ABSTRAK

Pada pengalokasian media penyimpanan skala jaringan (network storage), diperlukan konsep yang baru untuk meningkatkan

efektivitas komunikasi antar storage server dan client. Pada network storage konvensional, setiap node berkomunikasi dengan

storage server menggunakan single file image yang terdapat pada server sehingga memungkinkan terjadinya kegagalan node

tunggal (single point failure) yang mengakibatkan node server untuk layanan tertentu tidak dapat diakses sama sekali.

Proses transfer file pada server dapat dimodifikasi dengan mengubah mekanisme menjadi end user-initiator-storage server dengan

konsep redundant server initiator sebagaimana konsep yang terdapat pada Storage Area Network. Dengan demikian hal tersebut

membuat setiap initiator node yang ingin mengakses storage server harus memiliki file system yang sama dan mampu

berkoordinasi satu sama lain. Untuk mengatasi hal tersebut diimplementasikan Cluster File System yang terpasang di setiap

initiator node yang akan mengakses storage server. Mekanisme ini mendukung High Availability Clustering, setiap cluster node

dapat mengakses dalam bentuk block-data pada storage server, dan file system pada setiap node merupakan Cluster File System

yang dapat melakukan interkoneksi antar server dengan mekanisme fencing dan locking.

Pada Storage Area Network (SAN), Cluster File System yang diuji pada tugas akhir ini, memiliki failover delay yang bervariasi

antara 6-12 detik yang berpotensi menjadikan proses transfer file menjadi terputus, memiliki kemampuan IOPS yang seragam

dengan nilai bervariasi bergantung kepada spesifikasi hardware yang terdapat pada node server dan mengakibatkan penggunaan

resource memory dan CPU yang lebih besar pada saat menggunakan block data dengan ukuran yang lebih kecil.

Kata kunci: Storage, File System, Cluster.

ABSTRACT

Due to storage media allocation in network scale, it should be another approach to increase the communication performance

between storage server and client. Since in some ordinary network storage, each node communicate to storage server using single

file image exists on server side that may cause single point of failure that make server node fail to deliver any service at all.

File transfer process between nodes can be modified with changing the mechanism. Large file size may interference the

performance of the communication between node.

This case may be solved by switching the mechanism to be end user-initiator-storage server with redundant server initiator concept

as the concept is already existing in Storage Area Network. That is the reaseon that every initiator node accessing the storeage

server need to have the same file system image dan coordinates one each other in the cluster. To solve those problems, then we

implement Cluster File System which has been installed on every initiator node accessing the same storage. This mechanism

supports High Availability Clustering, that every node may access the storage in data-block, and the File System on every node is

Cluster File System which capable to interconnect among server using fencing and locking mechanism.

In Storage Area Network (SAN), Cluster File System tested on this paper, gives various failover delay from 6 to 12 second whoch

potentially make the file transfer process disputed. The IOPS performance on each node are similarly has the same thread pattern

with various throughput result depends on the hardware of each node cluster, and the system consumed more memory and CPU in

order to transfer using smaller block-data for each file.

Although this system can be some solution so every node may still accessing Storage Server and avoiding of single point failure.

Keywords: Storage, File System, Cluster 1. Pendahuluan

1.1 Latar Belakang

Perkembangan teknologi media penyimpanan data network yang ada

saat ini ialah DAS (Direct Attached Storage), NAS (Network

Attached Storage), dan SAN (Storage Area Network). Diantara ketiga

konsep storage diatas, SAN dengan protokol iSCSI ialah konsep

storage yang paling mendukung layanan Cloud Storage, dikarenakan

protokol iSCSI dapat berjalan pada jaringan internet pada umumnya,

dengan kata lain SAN adalah konsep Storage yang sangat cocok

diterapkan pada Cloud Computing. Dikarenakan SAN dapat

melakukan transfer data kepada server dalam bentuk block data

bukan dalam bentuk transfer file, sehingga tidak membebani Storage

server dan berimplikasi terhadap kecepatan, kehandalan dan

keamanan data.

Meskipun demikian, perlu dilakukan analisis terhadap

kinerja server terhadap storage server yang mengalami pembebanan

saat diakses secara simultan oleh banyak user. Sehingga akses user

terhadap media storage senantiasa terjaga meskipun terdapat server

yang failed. Untuk itu digunakanlah konsep Cluster File System pada

cluster server sebagai antisipasi apabila suatu saat server sedang

mengalami kondisi down, aktifitas komunikasi data tidak terganggu

karena trafik dapat dialihkan melalui server yang lain tanpa disadari

oleh user.

1.2 Tujuan

Tujuan dari penulisan tugas akhir ini adalah:

1. Mampu menerapkan konsep Cluster File System pada server

yang dapat menunjang layanan Cloud Storage berbasis

iSCSI SAN.

2. Mengetahui dampak dari penggunaan Cluster File System

pada kinerja server berdasarkan parameter IOPS, CPU load,

CPU target dan initiator, delay failover, dan delay failback.

3. Mampu mengimplementasikan konsep Cluster File System

pada Storage Area Network sebagai pendukung infrastruktur

layanan Cloud Storage.

4. Mampu melakukan interkoneksi antar server pada iSCSI

Inititator dan storage server sebagai iSCSI Target..

1.3 Batasan Masalah

Permasalahan pada tugas akhir ini akan dibatasi pada hal-hal berikut:

1. Menerapkan metode Storage Area Network sebagai konsep

Cloud Storage dengan memanfaatkan protokol FTP

2. Implementasi menggunakan GFS2 dari Sistem Operasi

CentOS 6.5

3. Hanya dilakukan pada jaringan LAN skala kecil

4. Storage Area Network mengunakan protokol iSCSI.

5. Menggunakan iSCSI sebagai protokol transfer data antar

node

6. Terbatas pada konsep server clustering.

7. Terbatas pada penggunaan Cluster File System.

8. Tidak melakukan virtualisasi ataupun hypervisor pada

storage server.

9. Storage server dibangun dengan sederhana dari PC Server.

10. Parameter yang diukur adalah IOPS (Input Output pers

Second), Beban kerja CPU (CPU Load) target dan intitator,

response time, delay failover dan delay failback.

11. Tidak membahas aspek trafik secara mendalam.

12. Tidak membahas aspek keamanan sistem dan jaringan.

13. Tidak membahas secara mendalam sisi komunikasi dan

transmisi..

14. Tidak melakukan konfigurasi RAID

1.4 Rumusan Masalah

Permasalahan-permasalahan yang akan dibahas pada tugas akhir ini

meliputi:

1. Bagaimana menerapkan konsep Cluster File System pada

server yang dapat menunjang layanan Cloud Storage

berbasis iSCSI SAN.

2. Apa dampak dari penggunaan Cluster File System pada

kinerja server berdasarkan parameter IOPS, CPU load, CPU

target dan initiator, delay failover, dan delay failback.

3. Bagaimana mengimplementasikan konsep Cluster File

System pada Storage Area Network sebagai layanan Cloud

Storage.

Bagiamana melakukan interkoneksi antar server pada iSCSI

Inititator dan storage server sebagai iSCSI Target

2. DASAR TEORI

2.1 Server[10]

Server adalah sebuah sistem komputer yang menyediakan jenis

layanan tertentu dalam sebuah jaringan komputer. Terkadang istilah

server disebut sebagai web server, namun pada umumnya orang lebih

suka menyebutnya sebagai ‘server’ saja. Sebuah server didukung

dengan prosesor yang bersifat scalable dan RAM yang besar, juga

dilengkapi dengan sistem operari khusus. Sistem operasi ini berbeda

dengan sistem operasi biasa.

Sistem operasi dari server adalah sistem operasi jaringan atau dikenal

dengan network operating system. Server juga bertugas untuk

menjalankan software administratif. Yakni software yang mengontrol

akses terhadap jaringan dan sumber daya yang terdapat di dalamnya.

Hal ini termasuk file maupun perangkat yang digunakan bersamaan

(shared) dan memberikan akses kepada workstation anggota jaringan.

2.2 Computer Cluster[5]

Computer cluster adalah sekumpulan komputer independen yang

beroperasi dan terlihat oleh klien jaringan tersebut seolah-olah

komputer tersebut adalah satu buah unit komputer. Sedangkan yang

dimaksud dengan Server Clustering ialah menggunakan lebih dari

satu server yang menyediakan redundant interconnections, sehingga

user hanya mengetahui ada satu sistem server yang tersedia dan

komputer client tidak menyadari jika terjadi kegagalan pada sistem

server karena tersedianya server cadangan sebagai redundant atau

backup

2.3 Load Balancing Clustering [22]

Load Balancing adalah sebuah konsep untuk berbagi beban atau

muatan kerja dengan mendistribusikan request dari client ke beberapa

komputer server. cara kerja load balancer adalah menerima incoming

request dari client dan meneruskan request tersebut pada server

tertentu jika dibutuhkan. Load Balancing clustering berfungsi untuk:

o Membagi traffic jaringan menjadi individual request dan

menentukan server mana yang akan menerima

individual requests.

Me-monitor server yang ada serta memastikan server server tersebut

merespon traffic. Jika terjadi kegagalan pada sebuah server maka

server yang gagal tidak akan digunakan (menggunakan server yang

masih bekerja

2.4 Cloud Storage[10]

Cloud Storage adalah media penyimpanan data yang dapat diakses

oleh para penggunanya lewat jaringan internet. Tentu saja filenya

berada di storage server dimana kita membuat akun cloud storage.

Misalnya diilustasikan seperti ini, jika seorang web designer

memerlukan banyak gambar, font, ilustrasi, flash dll,supaya untuk

memudahkannya bekerja dimana saja, maka akan menyimpannya di

cloud storage.

Memang pada dasarnya terdapat banyak pilihan untuk menyimpan

data-data. Dapat disimpan pada media penyimpanan fisik seperti

harddisk, CD, flashdisk. Tapi untuk sebagian pengguna komputer hal

tersebut mulai menjadi penghalang efisiensi kerja saat data-data yang

dibutuhkan tak dapat diakses. Misalnya flashdisk yang tertinggal atau

keeping CD yang rusak.

Saat data disimpan secara ‘cloud’, data-data tersebut dapat dengan

mudah diakses lewat jaringan internet. Tidak perlu mengambil laptop

atau flashdisk. Yang perlu ditekankan dari keuntungan teknologi ini

adalah kemudahan mengakses data kita dimana saja, kapan saja, dan

menggunakan perangkat apa saja

2.5 Storage Area Network[6]

SAN adalah sebuah jaringan yang bertindak sebagai jalur transfer

data antara sistem komputer dan elemen penyimpanan. Sebuah SAN

terdiri dari infrastruktur komunikasi yang menyediakan koneksi fisik

dan lapisan manajemen yang mengatur koneksi, unsur-unsur storage,

dan sistem komputer sehingga transfer data jadi jauh lebih aman dan

lebih kuat. Sebuah SAN juga dapat menjadi sistem penyimpanan

yang terdiri dari perangkat penyimpanan, sistem komputer, peralatan

network, dan perangkat-perangkat lunak lainnya yang berkomunikasi

melalui jaringan.

SAN mampu menyediakan kualitas kecepatan yang baik antara server

dan storage. Karena hal inilah terkadang SAN biasa disebut juga

sebagai “Jaringan di Belakang Server”.

2.6 iSCSI (Internet Small Computer System Interface)[4]

iSCSI merupakan protokol yang bekerja pada transport layer. Hal ini

menggambarkan tentang protokol SCSI yang dapat bekerja melalui

jaringan TCP/IP. iSCSI memungkinkan prosedur yang bekerja pada

protokol SCSI biasa agar dapat dikirimkan end-to-end melewati

jaringan LAN, WAN, ataupun Internet.

iSCSI dikembangkan oleh IETF (Internet Engineering Task Force)

dengan kode nomor RFP 3720. iSCSI merupakan salah satu

pendekatan yang digunakan untuk melakukan transmisi data melalui

jaringan IP, metode ini merupakan alternatif dari metode Fibre

Channel (FCIP) yang dikenal mahal

3. Perancangan Sistem dan Implementasi

3.1.1 Menentukan topologi jaringan yang digunakan pasa iSCSI

SAN Arsitektur dan Titik Pengukuran

Gambar 3.2 Topologi sistem yang dirancang

Storage Area Network yang di implementasikan merupakan

suatu jaringan tersendiri yang terisolasi dengan jaringan luar. Hal itu

dimaksudkan agar tidak terjadi satruasi trafik antara trafik I/O iSCSI

dengan trafik lain yang berasal dari jaringan LAN lain sehingga dapat

memberikan hasil pengujian troughput yang lebih optimal.

3.1.2 Melakukan instalasi dan konfigurasi pada iSCSI target

Pada tahap ini iSCSI Target yaitu Storage Server yang

berupa PC Storage akan dikonfigurasi menggunakan OS (Operating

System) yang dapat menunjang implementasi Cluster File System dan

bertindak sebagai SAN yang diakses melalui iSCSI Initiator. Dalam

Tugas Akhir ini, OS yang digunakan ialah CentOS 6.5 dengan GFS2

(Global File System2) pada Initiator yang mendukung implementasi

Cluster File System.

3.1.3 Melakukan instalasi dan konfigurasi pada iSCSI Inititator

Pada tahap ini adalah melakukan konfigurasi tiga buah node

sebagai iSCSI Initiator menggunakan OS (Operating System) yang

dapat menunjang implementasi Cluster File System. Setelah instalasi

package iSCSI Initiator, maka dilakukan penamaan pada setiap node

dengan nama node 1, node 2, dan node3. Pada setiap node dilakukan

instalasi “High Availability” packages dan “Reselient Storage”

packages yang terdapat didalam cd repository CentOS 6.5, termasuk

dengan GFS (Global File System) sehingga memungkinkan

mekanisme fencing dan locking antar node.

3.1.4 Melakukan interkoneksi antar node

Setelah iSCSI Target dan Inititator berhasil dikonfigurasi,

maka dilakukan konfigurasi lanjutan interkoneksi untuk menjamin

bahwa sistem dapat berjalan sebagaimana semestinya. Konfigurasi

tersebut ialah proses discovery dan login dari Initiator menuju

Target.

Setelah berhasil login ke dalam iSCSI Target maka

dilakukan cluster configuration antar iSCSI Initiator menggunakan

Luci Server hal ini dilakukan untuk mempermudah proses konfigurasi

melalui aplikasi berbasis web yang terdapat pada Luci Server

# yum -y --disablerepo=\* --enablerepo=c6-media install luci

3.1.6 Implementasi skenario pengujian yang ingin dilakukan

Pada tahap ini akan dilakukan skenario pengujian untuk mendapatkan

data-data yang akan dianalisa meliputi parameter IOPS, CPU Load

pada target dan initiator, delay failover/delay failback, dan

throughput.

3.1.7 Analisa hasil keluaran berdasarkan parameter yang diuji

Dari masing-masing keluaran tiap variabel kecepatan akan

menunjukkan hasil apakah koneksi mengalami perubahan performa

atau tidak. Selanjutnya akan di analisa dan ditarik kesimpulan

berdasarkan hasil pengujian yang

3.2 Keluaran yang diharapkan

Dari pelaksanaan Tugas Akhir ini diharapkan keluaran dari

hasil simulasi yang menunjukkan kenaikan performansi dari Cluster

File System pada sistem Cloud Storage. Untuk sistem SAN dengan

protokol iSCSI diharapkan dapat diintegrasikan dengan Cluster File

System sehingga dapat mendukung layanan Cloud Storage pada

teknologi Cloud

3.3 Kondigurasi Hardware

a. Perangkat Utama

1. iSCSI Initiator

3 buah iSCSI Initiator berfungsi sebagai cluster server

yang akan mengakses storage server secara simultan

menggunakan cluster file system. Cluster server dapat

diperlakukan sebagai web server, ftp server, database

server, dsb. Namun dalam kasus Cloud Storage ini, penulis

akan menerapkan sistem sebagai FTP Server karena

dianggap merepresentasikan konsep Cloud Storage secara

teknikal.

2. Luci Server

Luci server berfungsi sebagai Cluster Management control,

mengendalikan cluster server yang aktif dan yang non-aktif

sehingga menjaga konsistensi cluster file system dan juga

mempermudah Cluster Management.

3. iSCSI Target

iSCSI Target berfungsi sebagai Storage Server yang

diakses melalui iSCSI Initiator sehingga harddisk dalam

Target dapat tampil seolah-olah harddisk lokal pada

Initiator.

b. Perangkat Penunjang

1. Hardware

Perangkat jaringan yang dibutuhkan ialah:

a. Gigabit Ethernet Switch yang akan digunakan

sebagai SAN Switch

2. Software

a. CentOS 6.5

b. Luci Cluster Management

c. Redhat “High Availability” dan “Resilient

Storage” packages.

d. IOzone

Software ini berfungsi untuk melakukan

pengujian berupa pembangkitan trafik I/O pada

media penyimpanan yang ada pada server.

e. Wireshark

Program ini digunakan untuk melakukan capture paket data didalam

jaringan sehingga memiliki fungsi untuk melakukan diagnosa

keadaan jaringan yang sedang berjalan. Paket yang dicapture akan

ditamppilkan beserta dengan parameter yang lain secara lengkap,

seperti protocol pada paket data, payload paket data, waktu terima,

waktu kirim, alamat tujuan dan sumber. Program ini menjadi sangat

fleksibel karena dapat melakukan capture paket data pada semua

layer OSI.

3.4 Skenario Pengujian

Software yang digunakan untuk pengujian atau benchmark

adalah Iozone untuk benchmark Input/Output per second (IOPS).

Beberapa skenario yang akan dijalankan untuk menguji performansi

sistem dan juga menunjukkan berjalannya semua fitur yang

disediakan oleh iSCSI SAN yang telah dibuat adalah:

a. Skenario satu pengujian

Untuk mendapatkan hasil benchmark IOPS dan CPU load,

maka Iozone dijalankan pada masing-masing Initiator secara

bergantian untuk menguji kemampuan Cluster File System

pada direktori /GFS yang terdapat pada tiap-tiap cluster node

dengan kondisi Initiator sudah terhubung kepada Target

(Storage Server)

b. Skenario dua pengujian

Untuk mendapatkan hasil failover delay dan failback delay,

maka salah satu Initiator yang sedang digunakan akan

dinonaktifkan dengan cara memindahkan service dari salah

satu node kepada node lain. Mekanisme tersebut digunakan

untuk mengetahui apakah layanan yang berjalan pada suatu

node berhasil dialihkan ke node yang lain apabila terjadi

kegagalan. Hasil pengamatan dapat dilihat melalui syslog pada

node yang menjadi backup terhadap node yang failure.

c. Skenario tiga pengujian

Untuk mendapatakan hasil throughput sistem sebagai layanan

Cloud Storage, maka tiap-tiap Initiator diperlakukan sebagai FTP

server. Sehingga client atau user dapat mengakses file maupun data

pada Initiator melalui protokol FTP secara bersamaan. Nilai

throughput dapat diamati melalui wireshark pada user.

4. IMPLEMENTASI DAN ANALISIS

4.1 Analisis performansi iSCSI SAN

4.1.1 IOPS (Input Output per Second)

4.1.1.1 Sistematika Pengukuran

Pengukuran dilakukan dengan menggunakan software

IOzone. Pengukuran dilakukan pada setiap iSCSI Initiator dengan

ukuran block 4KB hingga 16384KB, dengan ukuran sebesar 1 GB.

Trafik yang dibangkitkan ialah trafik I/O antar iSCSI Initiator dengan

iSCSI Target. Pengukuran atau benchmark dilakukan secara

bergantian antara Initiator di node 1, node 2, dan node 3. Hal ini

ditujukan untuk mendapatkan hasil IOPS yang tidak dipengaruhi oleh

trafik dari sesama Initiator.

Proses benchmark terhadap File System dilakukan untuk

mengukur IOPS write dan IOPS Read pada GFS2 Cluster File System

yang terdapat pada cluster node. Benchmarking dilakukan melalui

aplikasi IOzone, yang bekerja dengan melakukan pengujian file

system menggunakan data yang di generate secara sequential

berdasarkan ukuran block data pada tiap-tiap ukuran file yang

berukuran 1 GB. Proses pengujian IOPS Write dan IOPS Read pada

setiap file juga dilakukan secara sequential mulai dari ukuran block 4

KB hingga 16 MB. Pengujian dilakukan pada iSCSI Initiator secara

bergantian untuk melihat kemampuan GFS2 Cluster File Systerm di

masing-masing node.

4.1.2 Hasil Pengukuran

Hasil pengukuran Read dan Write IOPS berulang pada Initiator node1

Gambar 4.1 Grafik IOPS file system tanpa cluster node 1

Gambar 4.2 Grafik IOPS cluster node 1

Pada hasil pengukuran IOPS Write dan Read di node 1,

performa file system terus cenderung meningkat mengikuti besar

block data yang digunakan sekitar 27000 – 65000 IOPS READ dan

24000 – 64000 IOPS Write. Hasil tersebut didapatkan pada block

dengan ukuran 4 KB hingga 256 KB. Dari hasil tersebut juga tampak

bahwa kemampuan Cluster File System GFS2 terus meningkat dari

27000 IOPS READ dan 24000 IOPS WRITE pada block 4 KB dan

mulai stabil pada kisaran 65000 IOPS READ dan 64000 IOPS

WRITE pada block dengan ukuran 32 KB.

Nilai IOPS READ kemudian cenderung stabil pada blok-

blok data dengan ukuran yang lebih besar dari 32 KB, yaitu IOPS

READ berada pada kisaran 62000 IOPS. Sedangkan pada hasil IOPS

WRITE terdapat penurunan performa yang signifikan hingga kisaran

30000 IOPS ketika pengukuran berada pada ukuran block 512 KB

dan seterusnya hingga ukuran block 16 MB.

Hasil pengukuran Read dan Write IOPS berulang pada

Initiator node2



Pada hasil pengukuran IOPS write dan Read di node 2,

performa file system cenderung menigkat mengikuti besar block data

yang diuji, yaitu mulai dari 58000 – 192000 IOPS READ dan 39000

– 190000 IOPS WRITE. Berdasarkan hasil pengujian, performa IOPS

Read file system pada masing file size semakin meningkat pada saat

ukuran block data semakin besar.

Hasil pengukuran Read dan Write IOPS berulang pada

Initiator node3


0

500000

1000000

1500000

2000000

IOPS Read & Write node 1 (1G)

Write

Read

0

20000

40000

60000

80000

IOPS node 1 (1G)

write

read

0

2000000

4000000

6000000


Write

Read

0

50000

100000

150000

200000

250000

IOPS node 2 (1G)

Writer

Reader

0

20000

40000

60000

80000

100000

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4


Write

Read


Pada hasil pengukuran IOPS Read dan Write di node 3,

performa file system cenderung mengalami peningkatan performa

seiring dengan peningkatan block size yang diuji menggunakan

IOzone, yaitu mulai dari 12000 – 28000 IOPS Read dan 11000 –

27000 IOPS Write. Berdasarkan hasil pengujian menggunakan

IOzone, performa IOPS Read file system pada masing-masing block

memiliki trend yang serupa dengan hasil pengukuran pada node-node

sebelumnya.

Dari hasil tersebut juga tampak bahwa kemampuan Cluster

File System GFS2 terus meningkat dari 12000 IOPS READ dan

11000 IOPS WRITE pada block 4 KB dan mulai stabil pada kisaran

27000 IOPS READ dan 28000 IOPS WRITE pada block dengan

ukuran 16 KB.

Pada hasil pengukuran di node 3, tidak terdapat penurunan

performa yang signifikan pada block data dengan ukuran lebih besar

dari 16 KB. Hal tersebut dapat terlihat pada saat pengujian dilakukan

dengan ukuran blok data sebesar 1MB, terdapat penurunan sekitar

200 – 500 IOPS pada IOPS READ maupun IOPS WRITE.

Sedangkan hasil pengukuran pada iSCSI Initiator sebelum

menggunakan Cluster File System adalah sebagai berikut:

4.1.3 Analisis Hasil Pengukuran

Dari hasil pengujian diatas dapat terlihat bahwa pada

masing-masing node yang sudah terkonfigurasi dengan GFS2 Cluster

File System, performa IOPS Cluster File System cenderung

mengalami peningkatan seiring dengan besar block data yang

digunakan dalam proses IO Read dan Write. Namun tingkat performa

IOPS Cluster Files System antar node memiliki skala yang berbeda-

beda. Dilihat dari hasil pengukuran, kemampuan IOPS Read dan

Write tertinggi didapatkan pada GFS2 Cluster File System pada node

2 dibandingkan dengan node 1 dan node 3. Sedangkan performa

GFS2 Cluster File System pada node 3 menunjukkan nilai IOPS Read

dan Write yang paling rendah, namun memiliki stabilitas IOPS yang

cukup baik. Berbeda dengan node 1, meskipun memiliki nilai IOPS

yang dapat mencapai 60000 IOPS Read, Cluster File System pada

node 1 memiliki tingkat stabilitas yang paling rendah atau tidak

stabil, hal tersebut terlihat dari penurunan performa yang sangat

drastis ketika melakukan proses IO Write dan Read pada blok

berukuran 512 KB.

Perbedaan tersebut sangat jelas dipengaruhi oleh spesifikasi

hardware atau peripheral yang berbeda-beda antar iSCSI Initiator. Hal

tersebut dapat mempengaruhi tingkat IOPS Read dan Write karena

proses IO merupakan proses yang amat erat kaitannya dengan kinerja

hardware. Dimana proses IO adalah proses lalu lintas komunikasi

data yang terjadi antar peripheral. IOPS dipengaruhi oleh latency

yang berasal dari buffering pada memory (RAM) dan memory cache

pada CPU. Itulah sebabnya ketika terjadi perbedaan CPU ataupun

RAM hasil IOPS yang didapatkan bisa berbeda-beda meskipun

terhubung pada jaringan yang sama, pengaruh lain juga disebabkan

oleh penggunaan NIC yang berbeda-beda antar node..

4.2 Beban Processor (CPU Load)

4.2.1 Sistematika Pengukuran


Iozone. Pengukuran dilakukan pada iSCSI Initiator dengan ukuran

block 4KB hingga 16384KB, dengan ukuran file sebesar 1 GB. Trafik

yang dibangkitkan ialah trafik I/O antar iSCSI Initiator dengan iSCSI

Target. Parameter yang diambil dalam pengukuran ini adalah

processor interrupt time untuk mengukur beban processor terhadap

proses I/O yang ditampilkan dalam bentuk persen. Pada iSCSI

initiator pengukuran dengan menggunakan Iozone.


Hasil pengukuran CPU Load pada node 1:

Gambar 4.8 Grafik CPU Load tanpa cluster file system node 1

Gambar 4.9 Grafik CPU Load cluster node 1

Berdasarkan grafik CPU Load pada node 1, tampak bahwa

proses IO Write menggunakan resource CPU yang lebih besar

daripada yang digunakan pada proses IO Read meskipun pada blok 8

KB dan 16 KB resource untuk IO Read lebih besar daripada IO

Write. Dari masing-masing ukuran block, terlihat resource yang

0

10000

20000

30000

40000

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4

IOPS node 3 (1G)

write

read

0

50

100

150

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4

CPU Load Read & Write node 1 (1G)

Write

Read

0

10

20

30

40

50

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4

CPU LOAD node 1 (1G)

write

read

digunakan lebih besar saat ukuran block jauh lebih kecil dari ukuran

file. Beban tertinggi sebesar 48% didapat pada block 4 KB.





rata-rata proses IO Write menggunakan resource CPU yang lebih

besar daripada yang digunakan pada proses IO Read. Dari masing-

masing ukuran block, terlihat resource yang digunakan lebih besar

saat ukuran block jauh lebih kecil dari ukuran file.





rata-rata proses IO Write menggunakan resource CPU yang lebih

besar daripada yang digunakan pada proses IO Read. Dari masing-

masing ukuran file, terlihat resource yang digunakan lebih besar saat

ukuran block jauh lebih kecil dari ukuran block.


Berdasarikan hasil pengukuran rata-rata CPU load pada

Initiator (node 1,2 dan 3) terlihat kecenderungan kenaikan persentase

utilisasi CPU berbanding lurus dengan besar block size yang

digunakan selama proses benchmark menggunakan IOzone. Dari

keseluruhan node, meskipun memiliki tingkat persentase utilisiasi

yang berbeda, namun terdapat pola kenaikan yang serupa. Yakni

kenaikan CPU Load maksimal terjadi pada block size dengan ukuran

file sebesar 4 KB.

Pada ukuran block yang lebih kecil, prosesor akan

memproses instruksi lebih banyak untuk melakukan sebuah proses

I/O kedalam harddisk, prosesor juga menambahkan instruksi untuk

melakukan proses I/O melalui NIC yang juga meningkatkan beban

prosesor karena adanya proses tambahan tersebut. CPU mendapat

beban yang lebih besar karena terdapat overhead dari setiap paket

yang akan diproses. Hal tersebutlah yang menyebabkan beban CPU

yang meningkat pada block yang lebih kecil untuk file size yang sama

Hasil tersebut dapat dibandingkan dengan nilai CPU Load

tanpa cluster file system. Nilai CPU Load cenderung tidak mengalami

perubahan yang signifikan untuk besar file yang sama meskipun

menggunakan block size yang berbeda-beda. Hal ini dikarenakan

proses IOPS file yang terjadi pada internal CPU tidak melibatkan

block data dan tidak terdapat overhead pada transmisi paket data

melaui NIC.

4.3 Throughput


Semua cluster node terkonfigurasi sebagai FTP Server,

dengan Floating IP Address 192.168.1.100, Dengan menggunakan

floating IP, maka client hanya akan memandang satu buah IP address

yang berperan sebagai gateway menuju ketiga Cluster Node, sehingga

ketika client sedang mengakses FTP server dari salah satu node dan

terjadi failover ke node yang lain, maka client tidak perlu merubah IP

Address yang menuju FTP server.

Masing-masing iSCSI Initiator dikonfigurasi secara manual

untuk menjadi FTP server, kemudian layanan FTP diintegrasikan

dengan floating IP Address sebagai Cluster Service Group melalui

Luci Cluster Management. Direktori yang digunakan media

penyimpanan pada layanan FTP ialah /GFS, yaitu direktori dimana

GFS2 Cluster File System berada. Interkoneksi antar Client menuju

Cluster Node menggunakan FastEthernet Switch. Client kemudian

terhubung kepada salah satu iSCSI initiator untuk menggunakan

layanan FTP menggunakan software FileZilla. Setelah proses login

dan authentikasi user dilakukan, maka client men-download file yang

terdapat pada direktori /GFS. File yang digunakan sebagai pengujian

proses transfer file ialah file video dengan ukuran 1,2 GB. Nilai

020406080

100


Write

Read

0

10

20

30


write

read

0

5

10

15

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4


Write

Read

0

10

20

30

40

4 8

16

32

64

12

8

25

6

51

2

10

24

20

48

40

96

81

92

16

38

4


write

read

Throughput didapatkan berdasarkan pengamatan selama proses

download pada sisi client menggunakan Wireshark.


Gambar 4.14 Hasil throughput FTP pada client

Dari hasil pengamatan menggunakan wireshark, didapatkan

nilai throughput layanan FTP pada Cluster File System sebesar 34

MBps. Nilai tersebut didapatkan pada jaringan lokal yang terisolasi

dari trafik internet menggunakan interkoneksi Fast Ethernet Switch.

Dengan FTP Server menggunakan IP Address 192.168.1.100.

Pengukuran dilakukan menggunakan wireshark pada sisi client

dengan sistem operasi CentOS 6.5.

Pada saat mekanisme failover diberlakukan pada Cluster

Node, hal tersebut tidak mempengaruhi transmisi paket dari Cluster

Node menuju client. Hal tersebut diamati dari software dimana tetap

terjadi komunikasi dari client menuju FTP Server dengan IP Address

192.168.1.100


Dari hasil pengukuran throughput, tampak bahwa nilai

throughput sebesar 34 MBps dengan kanal informasi menggunakan

kabel 100 MBps Ethernet LAN ialah tidak maksimal. Hal tersebut

merupakan indikasi terjadinya bottleneck pada jaringan tersebut.

Bottleneck yang terjadi dapat diakibatkan oleh FastEthernet Switch

yang digunakan. Keterbatasan kapasitas dan kualitas FastEthernet

yang digunakan mengakibatkan trafik yang mengalir dari Cluster

Node menuju client tidak dialirkan dengan sempurna. Latency dan

bottleneck juga dapat terjadi pada NIC yang menjadi port koneksi

menuju kabel Ethernet. Hal ini juga mengindikasikan bahwa

penggunaan dan pemilihan Hardware dalam interkoneksi jaringan

memegang peranan penting dalam nilai throughput yang akan

didapatkan oleh Client.

4.4 Failover Delay


Proses failover digunakan sebagai salah satu parameter

pengujian guna mengetahui performa High-Availability pada GFS2

Cluster File System sebagai layanan media penyimpanan data. Suatu

service hanya dapat berjalan pada salah satu node,. Pada kasus ini,

service yang dijalankan dalam mekanisme failover ialah FTP Client-

Server. Service tersebut dikonfigurasi secara default agar berjalan

pada node 1 iSCSI Initator yang sudah terintegrasi dengan floating IP

Address sebagai Resource Group pada Cluster.

Floating IP Address digunakan untuk memastikan saat

proses failover terjadi, client tidak menyadari bahwa terdapat migrasi

sistem (failover) dari node 1 ke node failover (node2). Sebelum

melakukan mekanisme pengujian failover, terlebih dahulu dilakukan

konfigurasi failover domain berdasarkan skala prioritas, sehingga

ketika node 1 failure, service akan berpindah ke node 2, dan apabila

node 2 mengalami failure, service FTP akan berpindah lagi menuju

node 3.

Dalam mekanisme failover terdapat dua macam metode

yang bisa digunakan. Metode pertama ialah dengan salah satu node

dimatikan (poweroff) agar service berpindah kepada node yang masih

aktif. Yang kedua ialah dengan metode cold failover, dimana service

pada node yang aktif dipindahkan kepada node yang lain sesuai

keinginan admin melalui perintah / command.

:#clusvcadm –r GFS –m node2


Hasil pengukuran dengan proses failover:

Gambar 4.15 Pengamatan failover melalui syslog

Hasil pengukuran dengan proses failover melalui wireshark:

Gambar 4.16 Pengamatan failover melalui wireshark

Dari hasil pengamatan pada syslog dan wireshark di node 2,

dapat terlihat bahwa selama proses failover terjadi semenjak suatu

node dinyatakan DOWN oleh rgmanager. Berikutnya, kernel akan

melakukan mekanisme fencing dan locking melalui DLM

(Distributed Lock Manager) serta melakukan pengecekan terhadap

journal yang terdapat pada setiap node. Kemudian GFS2 Cluster File

System akan dinyatakan siap oleh kernel dan kemudian service mulai

aktif pada node 2.

Setelah node 2 dinyatakan sebagai active node, dan layanan

FTP berjalan pada node 2, dilakukan pengecekan ulang pada node 2

terhadap status Cluster melalui perintah CLUSTAT untuk memastikan

bahwa service telah berpindah ke node 2.

4.4.3 Analisa Hasil Pengukuran

Dari hasil pengukuran delay failover diatas, tampak delay

selama perpindahan ialah sebesar 42 second. Dan melalui proses cold

failover, tingkat akurasi delay dapat diamati dengan lebih detail

melalui wireshark dengan delay sebesar < 0,2 second.

Dengan demikian proses perpindahan trafik maupun service

dari suatu node yang mengalami failure dapat mengakibatkan

gangguan terhadap user dikerenakan delay failover yang cukup lama.

Namun apabila menggunakan cold failover maka migrasi terjadi

secara singkat tanpa dirasakan oleh user.

Berdasarkan hasil pengamatan, selama proses failover

berlangsung. Cluster Manager (CMAN) akan melakukan monitoring

terhadap jumlah cluster node yang berada dalam posisi on. Ketika

kondisi dalam suatu cluster berubah, maka CMAN akan mendeteksi

perubahan tersebut dan melakukan tindakan yang perlu dilakukan.

Dalam hal ini, ketika cluster node tidak memberikan message apapun

untuk berkomunikasi dengan node yang lain dalam rentang waktu

tertentu, maka CMAN akan melakukan proses remove terhadap node

tersebut dan membership of cluster pada node tersebut dinonaktifkan,

dan node tersebut tidak lagi dianggap sebagai cluster member.

Selanjutnya, DLM dan kernel akan melakukan proses

recovery terhadap Cluster File System. Ketika suatu node dianggap

failure, maka aktivitas cluster akan di-suspend, DLM dan GFS akan

melakukan recovery. DLM melepas locking management pada failure

node, dan GFS melakukan recovery journal terhadap node yang

failure.

Setelah mekanisme recovery diatas selesai, maka aktivitas

pada Cluster akan dilanjutkan. Service yang sebelumnya berjalan

pada node 1 siap untuk diaktifkan melalui node 2. Kemudian

pemulihan service dilakukan berdasarkan konfigurasi cluster yang

terdapat pada Cluster Configuration Management. Layanan FTP yang

sempat di-suspend, kembali dijalankan, dan proses transfer file data

dapat diteruskan berdasarkan journal yang sudah di-recovery tanpa

harus mengirimkan data ulang dari awal.

Mekanisme fencing dan locking tampak pada hasil

screenshoot berikut.

Gambar 4.18 Mekanisme fencing dan locking ketika GFS failover

Analisa juga dilakukan dengan melakukan failover ketika terdapat 2

buah cluster node yang dinonaktifkan.

Gambar 4.19 Pengamatan Service GFS failover saat terjadi kegagalan

di 2 node

Berdasarkan pengamatan diatas, dapat dilihat bahwa failover

yang terjadi ketika dua buah node mengalami kegagalan ialah failover

yang sesuai dengan failover domain sebagaimana yang sudah

terkonfigurasi pada Cluster Manager. Sehingga ketika node 1 dan

node 2 mengalami kegagalan, maka service akan mati dan cluster

akan nonaktif dikarenakan cluster tidak memenuhi quorum (1/2+1

jumlah total node yang aktif).

Sedangkan delay failover yang terjadi antara node yang satu

dengan node yang lainnya dapat dilihat pada grafik berikut:

Gambar 4.20 Pengamatan failover delay Service GFS dari node 1 ke

node 2 dan node 2 ke node 3

Gambar 4.21 Pengamatan cpu load sebelum dan sesudah failover

0

5

10

15

1 to 2 2 to 3

failover delay antar node (second)

0

10

20

30

40

node 1 node 2 node 3

failover cpu load

before failover

after failover

fencing

locking

Dari hasil pengukuran delay diatas, dapat terlihat bahwa

spesifikasi hardware pada masing-masing server dapat mempengaruhi

delay ketika terjadi kegagalan pada suatu node. Demikian pula saat

terjadi failover dengan menumpangkan layanan yang berbeda kepada

node lain, terlihat bahwa dengan hardware yang ber spesifikasi lebih

tinggi, total resource yang digunakan tidak terlalu besar.

Pada gambar 4.21 dapat dilihat nilai CPU Load pada

masing-masing node dengan kondisi ketika sebelum menerima

service failover dari node lain, dan kondisi sesudah node tersebut

menerima service failover dan melakukan back up terhadap layanan

cluster node yang mengalami failure. Contohnya ialah saat terdapat

suatu layanan web service yang berjalan pada node 3, kemudian node

3 mengalami kegagalan, maka service tersebut akan mengalami

failover kepada node 1 atau node lain berdasarkan pada failover

domain yang sudah dikonfigurasi melalui cluster management.

Dikarenakan standby node menangani service yang

sebelumnya berjalan pada node yang mengalami kegagalan, maka

terdapat kenaikan beban pada initiator yang menerima service

failover dan mengakibatkan penambahan layanan atau service yang

harus ditangani oleh standby node tersebut. Kenaikan beban CPU

Load dengan failover pada layanan yang berbeda berkisar antara

110% hingga 250% terhadap CPU Load sebelum dilakukan failover.

4.5 Video Streaming Server

Streaming server pada layanan cloud storage merupakan

salah satu layanan dengan jenis Video on Demand. Pengujian

terhadap kualitas Video on Demand pada cluster file system

digunakan untuk menggambarkan kemampuan Storage sebagai

penyedia layanan video yang diakses oleh client melalui Cluster

Server.

4.5.1Sistematika Pengukuran

Pengukuran dilakukan dengan mengunakan aplikasi VLC

Media Player pada sisi client. Service layanan video pada Cluster

Server dikonfigurasi menggunakan nginx yang dapat diakses melalui

setiap initiator node dengan terintegrasi sebagai suatu cluster service.

File video yang digunakan untuk pengujian terletaka pada Storage

Device dibawah direktori /GFS.

Pengukuran dilakukan dengan mengamati koneksi yang

terjadi melalui software Wireshark. Akan dilakukan simulasi failover

pada saat user sedang mengakses layanan video dari cluster service.

Dengan demikian dapat diketahui dampak dan performansi

penggunaan Cluster File System pada layanan Video on Demand.

Pengukuran dilakukan dengan mencoba menghubungkan

client dengan storage server melalui masing-masing node dan

kemudian diambil capture menggunakan wireshark untuk

mendapatkan nilai throughput dari masing-masing node.


Gambar 4.22 Pengamatan video streaming melalui wireshark

Melalui gambar 4.22, dapat terlihat hasil video yang berhasil

diakses oleh client melalui mekanisme server cluster lewat salah satu

node cluster menggunakan cluster service. Dapat dilihat melalui hasil

capture mengunakan aplikasi wireshark, bahwa protokol yang yang

digunakan pada layanan tersebut ialah protokol-protokol yang

mendukukng layanan video streaming, seperti UDP, RTP, dan RSTP.

File video yang digunakan merupakan file berekstensi .mp4 dengan

ukuran 864 MB. Kualitas tayangan yang didapat cukup baik dan tidak

terjadi noise (0 % error).

Namun apabila dilakukan simulasi proses failover layanan,

koneksi user terhadap file video yang diakses akan terputus dan tidak

tersambung kembali secara otomatis. Hal ini dapat diamati lebih

lanjut melalui gambar 4.23

Gambar 4.23 Pengamatan video streaming saat terjadi failover

Tampak bahwa ketika dilakukan proses failover, paket data

yang berisikan file video tidak dikirimkan oleh cluster dan tidak ada

protokol UDP ataupun RTMP yang masuk kepada client, melainkan

laporan error yang dikirimkan oleh cluster dengan berisikan pesan

bahwa paket yang diminta dari node tersebut ialah tidak diketahui

(unknown).

Meskipun cluster server tidak dapat menjalankan proses

failover terhadap layanan akses video, skenario pengujian dapat

dilakukan dengan menguji kemampuan masing-masing node secara

satu-persatu dan mengetahui nilai throughput yang didapatkan oleh

client pada saat mengakses file video dari node-node yang berbeda.

Nilai throughput pada client dapat dilihat melalui wireshark. Dengan

nilai throughput yang berbeda-beda ketika video diakses melalui node

yang berbeda-beda, hasil throughput yang didapatkan tidak

mempengaruhi kualitas video secara langsung.

Gambar 4.24 Nilai throughput video pada client


Dari hasil pengujian diatas, menunjukkan bahwa ketika user

mengakses layanan video dan terjadi failover, maka koneksi terhadap

file yang diakses akan terputus, dan dapat diakses kembali dengan

cara melakukan reload terhadap alamat yang disediakan oleh Cluster

Management. Hal ini terjadi karena pada layanan video, akses

streaming pada sesi tersebut akan terputus dan media player tidak

dapat mendeteksi sesi yang sudah dilakukan ketika terjadi failover

dan tidak mendapat packet video lagi dikarenakan terdapat delay

selama proses failover. Hal tersebut yang kemudian menyebabkan

setiap terjadi failover, maka user harus melakukan reload untuk

membangun sesi streaming video dari awal untuk dapat melanjutkan

layanan video.

Tampak dari hasil pengukuran throughput melalui wireshark

pada sisi client, meskiputn hasil dari throughput relatif serupa, namun

terdapat perbedaan ketika jalur koneksi melalui node dengan

spesifikasi hardware yang lebih baik, pada jaringan dan layanan yang

sama, maka nilai throughput juga ikut menjadi lebih baik.


IOzone. Pengukuran dilakukan pada setiap iSCSI Initiator dengan

ukuran block 4KB hingga 16384KB, dengan ukuran sebesar 1 GB.

Trafik yang dibangkitkan ialah trafik I/O antar iSCSI Initiator dengan

iSCSI Target. Pengukuran atau benchmark dilakukan secara

bergantian antara Initiator di node 1, node 2, dan node 3. Hal ini

ditujukan untuk mendapatkan hasil IOPS yang tidak dipengaruhi oleh

trafik dari sesama Initiator.

Pengukuran dilakukan sebanyak 30 kali untuk meningkatkan

akurasi pengukuran, mengeliminasi anomali pengukuran, dan

menggambarkan pola hasil pengukuran yang muncul.

5. PENUTUP

5.1 Kesimpulan

Dari pengujian dan analisa yang dilakukan, dapat

diambil beberapa kesimpulan sebagai berikut :

1. Berdasarkan konfigurasi dan implementasi Storage Device pada

Cluster File Systerm dengan melibatkan iSCSI Target, iSCSI

Initiator dan GFS, maka dapat disimpulkan bahwa Cluster File

System pada SAN berbasis iSCSI dapat digunakan sebagai salah

satu metode yang dapat menunjang layanan Cloud Storage.

2. Berdasarkan benchmark yang dilakukan menggunakan IOzone,

maka kinerja Cluster File System sebagai penunjang layanan

Cloud Storage memiliki kemampuan IO Write yang lebih baik

dibanding dengan kemampuan IO Read, dan juga membutuhkan

resource yang cukup besar pada memory di iSCSI Initiator yang

dapat mencapai hingga 100%, namun tidak menggunakan

resource CPU yang tinggi karena rata-rata penggunaan CPU

pada Initiator hanya berkisar antara 0,2% - 30 %.

3. Pada pengukuran delay failover, dapat disimpulkan bahwa

proses migrasi dari suatu node ke node yang lain pada suatu

cluster apabila salah satu sistem terdapat kegagalan ialah >7

detik, hal ini mengakibatkan koneksi dan proses transfer file

akan terputus ketika user sedang mengakses suatu layanan pada

server.

4. Dari implementasi yang dilakukan penggunaan Cluster File

System terbukti dapat menghilangkan single node failure pada

layanan Cloud Storage yang terdapat pada suatu server.

5. Nilai throughput dalam jaringan dipengaruhi oleh kualitas

hardware yang digunakan untuk interkoneksi pada jaringan

tersebut.

6. Cluster File System tidak mendukung failover pada layanan

Video on Demand yang diakses melalui Cluster Server

5.2 Saran

Penelitian selanjutnya diharapkan dapat melakukan penelitian

lebih lanjut dengan:

1. Implementasi Multipath untuk membuat lebih banyak LUN

yang mengarah kepada iSCSI Target.

2. Melakukan analisis sistem ketika menggunakan high-end

interconnection hardware.

3. Menguji performa IOPS dengan menggunakan peripheral

hardware dengan high-end spesification.

4. Melakukan pengujian performansi sistem dengan parameter

response time dan pengaruh terhadap jumlah user yang

dapat ditangani,.

5. Menggunakan layanan yang berbeda-beda pada setiap

cluster node yang dapat diakses secara simultan oleh

multiuser.

6. Menggunakan komponen LVS Router sebagai tambahan

dalam menunjang trafik failover menuju Cluster Server.

7. Mengimplementasikan Cluster Server untuk berbagai layanan

yang berbeda antar node.

DAFTAR PUSTAKA

Armanda, Ryan A.P. Skripsi: Implementasi Teknologi Cloud

Computing Menggunakan Cloudsim Untuk Implementasi

TIK Hijau. Universitas Indonesia. Depok. 2010.

0

50

100

150

node 1 node 2 node 3

throughput video

throughputvideo

Boronzyk, Timothy dan Christopher Negus. CentOS Bible. Wiley

Publishing, Inc. Indianapolis. USA. 2009.

Capps, Done (dkk). Analyzing NFS Client Performance with IOzone.

NFS Industry Conference. 2002.

Carolan, Jason dan Steve Gaede. Introduction to Cloud Computing

Architectre, White Paper, 1st Edition. Sun Microsystem.

Santa Clara. USA. 2009.

Chevance, René J. Server Architecture: Multiprocessors, Clusters,

Parallel System, Web Servers, and Storage Solutions.

Elsevier Digital Press, Burlington, USA. 2005.

Farley, Marc. Storage Networking Fundamentals: An Introduction to

Storage Devices, Subsystems, Applications, Management,

and Filing Systems. Cisco Press. Indianapolis. 2005

Fatahna, Muhammad An’im. CentOS Network Administrator, Beta1.

CentOS Indonesia Community. Indonesia. 2011

Gauger. C. M. (dkk). Modeling and Performance Evaluation of iSCSI

Storage Area Network over TCP/IP-based MAN and WAN

networks. University of Stuttgart. Stuttgart. Germany. 2005.

Jacobi, Tim-Daniel dan Jan Lingermann. Evaluation of Distributed

File System. Universitat Hamburg. Germany. 2012.

Kurniagraha, Deni. Tugas Akhir: Analisis Performansi Layanan

Cloud Storage pada sistem operasi windows dan linux.

Institut Teknologi Telkom. Bandung. 2012

Lu, Yingping dan David. Performance Study of iSCSI-Based Storage

Subsystems. University of Minnesota. USA. 2003.

McPherson, Amanda. Linux: The Operating System of the Cloud. The

Linux Foundation. 2009.

Nimis. Jens. Cloud Computing Tutorial. IPE-Klausurtagung.

Freudenstadt, Germany. 2009.

NN. iSCSI Protocol Concepts and Implementation. Cisco Systems,

USA. 2001.

NN. Network Protocols Handbook, 2nd Edition. Javvin

Technologies, Inc. Saratoga. USA. 2005.

NN. Red Hat Enterprise Linux 5.8 Beta: Cluster Suite Overview

RHEL, Edition 5. Red Hat, Inc. USA. 2010

NN. Red Hat Enterprise Linux 6: Global File System 2. Red Hat, Inc.

USA. 2013

NN. SAN System Design and Deployment Guide. Vmware, Inc.

Hilview Ave. USA. 2010.

Norcott, William D. Iozone Filesystem Benchmark.doc.

http://www.iozone.org.

Radkov, Peter (dkk). A Performance Comparison of NFS and iSCSI

fo IP-Networked Storage. University of Massachusetts.

USA. 2004

Routray, Ramani (dkk). iSAN: Storage Area Network Management

Modeling Simulation. IBM India System and Technology

Lab. India. International Conference on Networking,

Architecture, and Storage. 2007.

Tate, Jon dkk. Redbooks: Introduction to Storage Area Networking

and System Networking. 5th Edition. IBM, USA. 2012

Thain, Douglass dkk. Chirp: A Practical Global Filesystem for

Cluster and Grid Computing. Department of Computer

Science and Engineering, University of Notre Dame. 2007.

Towns, Anthony. Red Hat Cluster Suite for Red Hat Enterprise Linux

5: Cluster Suite Overview, Edition 5. Redhat, Inc. 2010.

Troppers, Ulf (dkk). Storage Networks Explained: Basics and

Application of Fibre Channel SAN, NAS, iSCSI, InfiniBand

and FcoE, Second Edition. John Wiley & Sons Ltd. 2009.

Wiratama, Hendra. Tugas Akhir: Implementasi Storage Area Network

Menggunakan Protokol iSCSI Pada Sistem Terdistribusi.

Institut Teknologi Telkom, Bandung. 2012.

http://www.iozone.org/

(Jurnal) Implementasi dan Analisis Server Clustering Menggunakan Cluster File System pada SAN...

Documents

Transcript of (Jurnal) Implementasi dan Analisis Server Clustering Menggunakan Cluster File System pada SAN...