T1 672009047 Full text

1 1. Pendahuluan

Dalam kajian Teknologi Virtualisasi Tingkat Sistem Operasi, mesin virtual (guest OS) yang disediakan harus sama dengan induk mesin (host OS)

dimana Teknologi Virtualisasi Tingkat Sistem Operasi tersebut berada [1]. Dengan keterbatasan fungsi dari teknologi virtualisasi tersebut, kemudian dilakukan penelitian untuk mengatasi masalah tersebut yaitu dengan menggunakan teknologi virtulisasi cloud computing. Salah satu software cloud computing yang dapat digunakan untuk membangun layanan cloud computing Infrastructure as a Service (IaaS) adalah OpenStack. OpenStack memiliki beberapa service, dan salah satu service yang digunakan untuk membuat sebuah virtual server serta melakukan manajemen terhadap

instance atau mesin virtual adalah compute yang mempunyai project name

Nova. Compute mengatur tentang pengalokasian processor, memory dan

resource yang lain. Dalam penelitian ini akan dibahas mengenai cara kerja salah satu service yang ada di OpenStack yaitu compute dan akan dilakukan analisis mengenai keelastisitasan dari OpenStack. Analisis dilakukan dengan menggunakan bantuan Devstack.

2. Tinjauan Pustaka

Penelitian yang telah dilakukan oleh Omar Sefraoui, Mohammed Aissaoui, dan Mohsine Eleuldj dengan judul “OpenStack : Toward an Open-Source Solution for Cloud Computing ” melakukan studi perbandingan antara beberapa software cloud yaitu, Eucalyptus, OpenNebula, dan OpenStack. Dari hasil perbandingan ketiga software cloud tersebut didapat OpenStack merupakan solusi cloud terbaik dikarenakan OpenStack merupakan software cloud open source dan support terhadap standard baru. [2]

Penelitian tentang cloud computing dengan deployment model infrastructure as a service juga dilakukan oleh Luchi Sulistyowati. Penelitian dilakukan dengan menggunakan UEC ( Ubuntu Enterprise Cloud), UEC digunakan untuk melakukan implementasi cloud computing untuk penyediaan

web server. Berdasarkan dari penelitan yang telah dilakukan cloud computing

dengan layanan Infrastructure as a Service dapat digunakan dan menopang kinerja penyediaan web server. [3]

Dengan melihat beberapa penelitian yang sudah dilakukah sebelumnya, akhirnya dilakukan penelitian untuk melakukan analisis terhadap cara kerja dan elastibilitas dari layanan cloud computing infrastructure as a service yang menggunakan software cloud OpenStack. Penelitian akan dikhususkan terhadap komponen OpenStack yaitu komponen compute, untuk melihat seberapa elastis komponen tersebut.

2

dengan menggunakan penyedia layanan jasa. Berdasarkan service model yang ada, cloud computing dibagi menjadi 3 hal yaitu, infrastructure as a service, platform as a service dan software as a service. Sedangkan berdasarkan

deployment model, cloud computing dibagi menjadi 4 hal yaitu, private cloud, community cloud, public cloud dan hybrid cloud. [4]

Infrastructure as a service (IaaS) merupakan salah satu komponen dari cloud computing jika dilihat dari service models yang diberikan. Server, sistem pemberkasan, switch, router dan sistem lain digabungkan dalam sebuah pool dan dibuat agar dapat diakses untuk mengurusi beban kerja yang terjadi dalam komponen aplikasi sampai pada aplikasi berkomputasi level tinggi. [5]

Openstack merupakan salah satu software cloud yang digunakan untuk membangun infrastructure as a service, openstack sendiri bersifat open source. Terdapat 7 service inti dari OpenStack yaitu : Compute, Object Storage, Identity, Dashboard, Block Storage, Network dan image service. Compute dengan project name Nova adalah service yang digunakan untuk menyediakan sebuah virtual server. Object Store dengan project nameSwift,

merupakan service yang digunakan untuk menyimpan data dalam skala yang besar. Identity dengan project name Keystone menyediakan autentikasi dan autorisasi bagi semua layanan OpenStack. Dashboard dengan project name Horizon merupakan sebuah modul web-based yang dapat digunakan untuk melakukan management OpenStack. Block Storage dengan project name Cinder menyediakan infrastruktur untuk melakukan management terhadap

volume yang ada di OpenStack. Network dengan project name Neutron ada untuk melayani keperluan jaringan di OpenStack. Image Service dengan

3

Gambar 1Conceptual Architecture [7]

Pada Gambar 1 merupakan service yang ada di OpenStack. Dijelaskan juga hubungan masing-masing service yang ada di OpenStack. Setiap service

yang ada tidak berdiri sendiri, tapi saling bergantung. Compute merupakan

service dari OpenStack yang dibahas dipenelitian ini. Compute memiliki beberapa komponen inti, seperti nova-api, nova-compute, nova-scheduler,

dan nova-conductor.

3. Metode Penelitian

Metode yang digunakan dalam penelitian ini adalah metode Network Development Life Cycle (NDLC). Dalam metode ini, terdapat 6 tahapan yang digunakan, setiap tahapan akan menghasilkan sebuah output tertentu. Output

4

Gambar 2 Network Development Life Cycle [8]

Analysis, Tahapan analysis dimulai dengan membuat check list

terhadap kebutuhan hardware dan software yang akan digunakan dalam penelitian. Kebutuhan hardware dan software ini disesuaikan dengan kasus atau permasalahan yang dihadapi yaitu tentang analisis salah satu komponen yang ada di Openstack, nova, dan proof of concept dari sebuah fungsi cloud

yaitu elastisitas. Sistem operasi yang digunakan dalam penelitian ini adalah Ubuntu Server 12.04 64 bit, pada penelitian ini, installasi openstack tidak menggunakan script dari openstack melainkan menggunakan shell script dari devstack, untuk versi Openstack yang digunakan adalah Openstack dengan

codename Havana. Sedangkan untuk kebutuhan hardware, hanya membutuhkan dua buah komputer, yang pertama yang berfungsi sebagai

controller node dan compute node, sedangkan komputer kedua digunakan untuk melakukan konfigurasi. Selain itu, juga dibutuhkan hardware lain seperti switch dan kabel unshielded twisted pair (UTP) yang digunakan untuk menunjang komunikasi data.

5

Gambar 3Rancangan Topologi Jaringan Cloud

Pada Gambar 3, modem digunakan untuk mengakses internet, akses internet diperlukan ketika pertama kali melakukan penginstalan Devstack.

Cloud server merupakan server utama yang digunakan, pada server ini terdapat semua komponen dari Openstack yang sudah terinstall. Client

sendiri digunakan untuk dapat mengakses cloud server melalui dashboard

atau melalui SSH.

Adapun spesifikasi perangkat keras yang digunakan dalam penelitian ini adalah sebagai berikut :

Tabel 1Spesifikasi Perangkat

Perangkat Spesifikasi Fungsi

Server - Prosesor Intel® core™ 2

quad CPU Q9300 @ 2.50 GHz (4 CPUs)

- RAM 3 GiB - 500 GiB HDD - Ubuntu Server 12.04

Controller node dan

Compute node, tempat masing-masing service

dari OpenStack berjalan.

Laptop - Prosesor Intel® core™ i3 CPU m 330 @2.13 GHz (4 CPUs)

- RAM 2 GiB - 320 GiB HDD

Client dan konfigurasi OpenStack.

Switch Switch untuk jaringan

192.168.1.1 / 24

192.168.1.20 / 24

6

Perangkat lunak dan perangkat keras diatas sudah memenuhi kebutuhan untuk melakukan penelitian tentang analisis fungsi compute pada openstack yang dikarenakan pada tahap pembuatan instance hanya menggunakan flavor m1.low. Pada tahap design, juga dilakukan pembuatan

flowchart mengenai alur pembuatan cloud instance dan tahapan yang terjadi didalamnya.

Gambar 4Flowchart Pembuatan Cloud Instance

7

Gambar 5 Detail flowchart proses pembuatan instance

Dalam pembuatan cloud instance, terdapat beberapa tahapan yang terjadi seperti yang ditunjukan pada Gambar 5, dimulai dari tahap scheduling, building, networking, block device mapping, dan yang terakhir tahap

spawning. Pada tahap design juga dilakukan pengalokasian alamat IP seperti yang tertera pada tabel 2.

Tabel 2Pengalokasian Alamat IP

Mesin Alamat IP Fungsi

Server 192.168.1.10 / 24

10.11.12.0/24 192.168.1.224/27

Host IP Fixed IP Floating IP

8

Simulation prototyping, Pada tahapan ini dilakukan simulasi terhadap

prototype dari desain yang sudah dirancang dengan menggunakan bantuan aplikasi GNS3. Hasil dari simulasi tersebut ditunjukan oleh gambar 7.

Gambar 6Simulation Prototyping dengan GNS3

Pada Gambar 6, server adalah tempat dimana OpenStack diinstall dengan menggunakan shell script Devstack. Didalam server tersebut, terdapat dua node yang diinstall dalam satu server yang sama, yaitu compute node

dan controller node.

Implementation, Pada bagian ini dibahas mengenai pembangunan proyek secara fisik yang mencakup instalasi mesin, konfigurasi jaringan fisik dan pengaturan alamat IP. Implementasi dilakukan dengan menggunakan

script dari devstack.

Monitoring, Tahapan monitoring dilakukan untuk mengetahui sistem berjalan dengan baik secara keseluruhan. Terutama untuk mengetahui penggunaan resource yang terpakai. Pengamatan terhadap resource yang dipakai diperlukan untuk mengambil hasil analisis yang dibutuhkan. Aspek yang akan diamati yaitu mengenai penggunaan RAM serta lama downtime

ketika melakukan proses resize image.

Management, dalam tahapan management dilakukan pengalokasian

flavor atau computing resources seperti processor, RAM dan disk storage

yang dapat dipilih oleh tenant atau penyewa. Dalam proses management

dilakukan penambahan flavor yang mempunyai nama m1.low.

Gambar 7 flavors m1.low

Host IP 192.168.1.10 / 24 Fixed IP 10.11.12.0 / 24 Floating IP 192.168.1.224 / 27

9

Flavors m1.low mempunyai RAM sebesar 1024 MB dan mempunyai 1 buah VCPU, 0 MB swap dan 0 GB ephemeral disk seperti yang terlihat pada Gambar 7.

4. Hasil dan Pembahasan

Pada tahapan ini dijelaskan mengenai hasil dari analisis fungsi

compute. Dalam Openstack sudah disediakan tipe-tipe flavors yang dapat digunakan dalam pembuatan instance.

Gambar 8tipe-tipe flavors

Gambar 8 menjelaskan mengenai tipe-tipe flavors yang ada didalam Openstack, dari m1.nano sampai m1.xlarge, flavors juga dapat dikonfigurasi sesuai dengan keinginan. Dalam analisis ini dilakukan uji coba pembuatan

instance menggunakan image linux mint dengan tipe flavors m1.tiny dan kemudian akan dilakukan resize instance dari m1.tiny ke m1.low dalam kondisi instance sedang running untuk membuktikan sifat elastis dari OpenStack.

Pada saat client menjalankan sebuah instance, API akan menjalankan fungsi run_instance() dan mengirimkan request untuk membuat sebuah

instance baru kepada nova-api. Nova-api kemudian menerima permintaan tersebut dan mengirimkan permintaan untuk melakukan validasi auth-token

dan access permission ke pada keystone.

Gambar 9tahap scheduling

10

kemudian berinteraksi dengan nova-database, dan dilakukan pembuatan

database entry terhadap instance baru. Setelah itu nova-api akan meminta kepada nova-scheduler untuk melakukan proses filtering dan weighting guna memperoleh host ID yang valid. Nova-scheduler kemudian berinteraksi dengan nova-database untuk menentukan host yang tepat yang dapat digunakan oleh instance. Setelah melalui proses filtering dan weighting,

nova-scheduler akan meminta kepada nova-compute untuk menjalankan

instance di host yang sudah ditentukan. Setelah nova-compute menerima permintaan tersebut dari nova-scheduler, nova-compute kemudian melakukan interaksi dengan nova-conductor untuk meminta informasi tentang instance

yang berupa host ID dan flavor yang digunakan (Ram, CPU, Disk). Nova-conductor kemudian berinteraksi dengan nova-database untuk meminta informasi tersebut, nova-database kemudian memberikan informasi instance

kepada nova-conductor dan kemudian mengirimkannya kepada nova-compute. Setelah itu nova-compute akan melakukan penguploadan image dari

image storage dengan cara mengirimkan auth-token kepada glance untuk mendapatkan image URL, glance kemudian melakukan verifikasi kepada

keystone dan sesudah itu nova-compute akan memperoleh image metadata.

Setelah tahap ini selesei, berakhir sudah tahapan scheduling seperti yang terlihat pada Gambar 9. Setelah melalui tahapan scheduling, tahapan selanjutnya adalah tahapan networking. Pada tahapan ini nova-compute akan meminta kepada neutron-server untuk melakukan pengalokasian dan konfigurasi jaringan supaya instance dapat memperoleh IP address.

.

Gambar 10tahap Block Device Mapping

Tahap selanjutnya adalah tahap block device mapping seperti yang terlihat pada Gambar 10. Tahapan ini dilakukan untuk memperoleh volume

atau disk yang akan digunakan oleh instance. Pada tahap ini, nova-compute melakukan interaksi kepada volume API untuk memasangkan volumes kepada

instance. Cinder-api kemudian melakukan validasi kepada keystone. Setelah proses tersebut selesei nova-compute akan memperoleh informasi tentang

block-storage.

11

Tahap terakhir adalah tahap spawning, seperti yang terlihat pada Gambar 11, pada tahap ini nova-compute menghasilkan data untuk driver hypervisor. Sesudah semua tahapan dari scheduling sampai dengan spawning

diselesaikan, instance akan berada pada power state running, seperti yang terlihat pada gambar 12, jika sudah berada pada kondisi running maka

instance sudah berhasil dibuat dan dapat dijalankan.

Gambar 12 running instance

Untuk pengaksesan instance dapat dilakukan dengan dengan mengakses VNC console yang terdapat pada dashboard.

Gambar 13 akses instance melalui VNC console

12

Gambar 14 state diagram fungsi nova.compute.api.resize

Pertama kali akan dilakukan pengecekan apakah terjadi perubahan flavor_id atau tidak, jika tidak terdapat perubahan maka proses yang

dilakukan adalah migrasi instance ke host tanpa melakukan penggantian

flavor. Kemudian dilakukan juga reservasi kuota untuk instance type yang

baru. Setelah itu task state instance akan diperbaharui menjadi

RESIZE_PREP dan nova-scheduler akan dipanggil untuk menjalankan fungsi

prep_resize().

Gambar 15 state diagram fungsi nova.scheduler.manager.prep_resize

Pada saat fungsi tersebut berjalan dilakukan proses filtering host,

proses yang dilakukan untuk memperoleh valid host. Apabila tidak ditemukan

host yang valid maka instance state akan dirubah kembali menjadi active dan

akan terjadi rollback quota reservation. Jika terdapat host yang valid

nova-compute.manager dipanggil untuk menjalankan fungsi prep_resize().

13

Fungsi prep_resize() akan mengirimkan notifikasi mengenai instance

usage kepada nova-conductor dan memanggil fungsi _prep_resize() yang

berguna untuk melakukan validasi apakah resize ke host yang sama

diperbolehkan atau tidak, sesuai dengan konfigurasi yang sudah dibuat.

Kemudian informasi instance yang sudah diperbaharui dikirim ke

nova-conductor dan fungsi resize_instance() dijalankan.

Gambar 17 state diagram fungsi nova.compute.manager.resize_instance

Fungsi resize_instance() akan meminta informasi mengenai network

dan informasi mengenai instance kepada nova-conductor. Kemudian task

state instance akan diperbaharui menjadi RESIZE_MIGRATING. Setelah itu

akan meminta informasi mengenai block device dan kemudian meminta

compute driver untuk melakukan migrasi disk dan power off instance.

Kemudian sesudah itu menghubungi volume service untuk memutuskan

hubungan volume yang terhubung dengan instance. Setelah itu, network

service akan dipanggil untuk melakukan migrasi network. Task state instance

kemudian akan diperbaharui menjadi RESIZE_MIGRATED. Fungsi yang

akan berjalan selanjutnya adalah fungsi finish_resize().

14

Pada fungsi ini jika terjadi perubahan flavor maka dilakukan update

flavor instance dari flavor type yang lama ke flavor type yang baru.

Kemudian dilakukan pengaturan network instance ke host tujuan dengan

memanggil network service. Instance task state akan diperbaharui lagi

menjadi RESIZE_FINISHED, setelah itu nova-compute akan mengambil

informasi mengenai block device dari volume service dan task state instance

akan dirubah menjadi RESIZED.

Gambar 19 state diagramfungsi nova.compute.api.confirm_resize

Tahapan terakhir yang dijalankan adalah confirm resize, fungsi yang

berjalan pada tahap ini adalah fungsi nova.compute.api.confirm_resize.

Dilakukan reservasi quota kemudian pengkonfirmasian pergantian resource.

Sesudah itu instance state akan berubah menjadi ACTIVE, dan dilakukan

commit quota reservation. Instance sudah berhasil dilakukan pergantian

flavor.

Gambar 20 Running instance sesudah proses resize

Pada gambar 20 nampak bahwa flavor instance sudah berganti dari m1.tiny

menjadi m1.low yang mempunyai resource RAM sebesar 1 GB.

15

Dapat dilihat juga di gambar 21, melalui system monitor yang terdapat di linux mint bahwa memory yang terpasang sudah berganti menjadi 1001.6 MiB yang semula.

Dilakukan juga pengujian untuk mengetahui bagaimana cara kerja pembagian memori pada OpenStack. Jumlah RAM fisik yang digunakan pada pengujian ini sebesar 3 GB, tetapi pada server OpenStack hanya digunakan 2 GB. Pengujian dilakukan dengan menguji quota, quota

merupakan batas limit penggunaan resource, dengan menggunakan parameter RAM. Pertama kali pengujian dilakukan dengan melakukan pengaturan quota RAM sebesar 2 GB.

Gambar 22 status intances

Kemudian dibuat 2 buah instance dengan masing-masing instance

memiliki RAM sebesar 1 GB, dan kedua instance tersebut dijalankan, seperti yang terlihat pada Gambar 22. Hasilnya, kedua instance tersebut dapat dijalankan dengan lancar, hal ini dikarenakan masih terdapat alokasi memori yang tersedia untuk kedua instance tersebut.

Gambar 23 instances sebelum dijalankan

Pengujian yang kedua dilakukan dengan cara pengaturan quota

melebihi dari batas RAM fisik atau overcommit quota. Hal ini dapat dilakukan karena terdapat management memory, apabila terdapat memory

yang idle akan dialokasikan kepada instance yang membutuhkan memory

16

Gambar 24 instances sesudah dijalankan

Ketiga instances tersebut kemudian dijalankan secara bergantian dimulai dari linux mint kemudian linux mint 2 dan terakhir linux mint 3. Setiap instance akan diberi beban untuk memaksimalkan penggunaan RAM. Pada Gambar 24 terdapat 2 instance yang berjalan dengan lancar yaitu, linux mint dan linux mint 2. Tetapi pada instance linux mint 3 tidak dapat berjalan. Hal ini dikarenakan memori yang dimiliki oleh server sudah dialokasikan terlebih daulu untuk kedua instance yang pertama kali dijalankan.

Tabel 3 Status instance

Instance Memory total Memoryused Status

Linux mint 1025648k 868176k Running

Linux mint 2 1025648k 894762k Running

Linux mint 3 1025648k - Shutdown

Pada Tabel 3, merupakan hasil dari monitoring RAM setiap instance

yang menggunakan command linux top. Pada saat instance linux mint dan linux mint 2 sudah hampir mencapai batas maksimal penggunaan RAM, instance linux mint 3 statusnya berubah menjadi shutdown dan tidak dapat dijalankan.

Sesudah tahapan pengujian selesei, kemudian dilakukan tahap monitoring. Dalam proses monitoring juga terdapat perubahan kondisi RAM, monitoring ini dilakukan ketika dalam proses pembuatan instance sampai

instance tersebut berhasil dijalankan. Monitoring dilakukan dengan menggunakan command dari linux yaitu top.

Gambar 25 Monitoring awal sebelum pembuatan instance

17

Gambar 26 Monitoring sesudah instance running

Setelah dilakukan pembuatan instance, terjadi perubahan pada kondisi RAM yang terpakai yaitu menjadi 3889292k. Hal ini terjadi karena instance sedang dalam posisi running yang ditunjukan dengan berjalannya hypervisor kvm.

Gambar 26 Monitoring downtime

Gambar 27 Monitoring downtime

Dilakukan juga proses monitoring untuk mengetahui lama downtime

ketika melakukan proses resize instance ke flavor yang baru. Proses

monitoring ini menggunakan aplikasi PRTG, dengan menggunakan sensor ping. Pada Gambar 26 dan 27 merupakan hasil dari proses monitoring downtime, dapat dilihat dari kedua gambar tersebut terjadi downtime selama 30 detik.

5. _Kesimpulan

Dari penelitian yang telah dilakukan tentang analisis cara kerja dan analisis elastisitas teknologi cloud computing Infrastructure as a Service

18

overcommit quota, tetapi mempunyai batasan apabila RAM yang tersedia sudah terpakai penuh maka apabila terdapat instance lain yang ingin berjalan harus menunggu sampai resource RAM kembali tersedia.

6. Daftar Pustaka

[1] Bayu, TI, dkk, 2010, Penerapan Teknologi Virtualisasi Tingkat Sistem Operasi pada Server Linux Ubuntu 8.04 Menggunakan OpenVZ, Aiti Vol. 7 No. 1.

[2] Sefraoui. O., Aissaoui, M., Eleuldj, M., 2012, OpenStack: Toward an Open-Source Solution for Cloud Computing, IJCA, (55)03 : 38-42.

[3] Sulistyowati, Luchi, 2012, Implementasi Cloud Computing sebagai Infrastructure as a Service untuk Penyediaan Web Server.

[4] Mell, P., Grance, T., 2011, The NIST Definition of Cloud Computing.

[5] Carolan, J dan Gaede, S, 2009, Introduction to Cloud Computing Architechture White Paper-1st Edition.

[6] OpenStack, 2013, OpenStack Compute Administration Guide.

[7] OpenStack, 2014, OpenStack Cloud Administrator Guide.