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.

Cloud computing adalah sebuah bentuk layanan yang memungkinkan

untuk dapat hadir dimanapun, memberikan kenyamanan, akses jaringan sesuai

permintaan (on-demand) ke lokasi sumber daya komputasi terkonfigurasi

(misalnya, jaringan, server, storage, aplikasi, dan layanan) yang dapat dengan

cepat dijalankan dan diluncurkan, dengan upaya pengelolaan minimal atau

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 name Swift,

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

project name Glance adalah komponen yang digunakan untuk membuat

sebuah virtual disk images. [6] Konseptual arsitektur pada OpenStack dapat

digambarkan seperti pada Gambar 1

3

Gambar 1 Conceptual 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

yang dihasilkan dari setiap tahapan akan menjadi dasar dari tahapan

selanjutnya. Gambar 2 menjelaskan alur dari NDLC.

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.

Design, Pada tahapan ini dibangun sebuah arsitektur jaringan baru

dan topologi logikanya yang didasarkan dari hasil analisis. Arsitektur

jaringan yang baru digambarkan seperti pada gambar 3.

5

Gambar 3 Rancangan 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 1 Spesifikasi 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

Host IP 192.168.1.10 / 24

Fixed IP 10.11.12.0 / 24

Floating IP 192.168.1.224 / 27

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 4 Flowchart Pembuatan Cloud Instance

Pada Gambar 4 merupakan flowchart pembuatan cloud instance, dimulai dari

proses pemilihan image sistem operasi, pemilihan jenis flavors sampai

kepada hasil yang berupa sebuah 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 2 Pengalokasian 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

Client 192.168.1.20/24 Tester Client 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 6 Simulation 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

192.168.1.20 / 24 192.168.1.1 / 24

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 8 tipe-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 9 tahap scheduling

Keystone kemudian melakukan validasi terhadap token yang diterima

dan mengirimkan auth headers dengan roles dan permission. Nova-api

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 10 tahap 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.

Gambar 11 tahap spawning

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

Pada Gambar 13 merupakan hasil akhir dari pembuatan instance yang diakses

melalui VNC console. Setelah dilakukan analisis mengenai cara kerja saat

OpenStack melakukan pembuatan instance, kemudian dilakukan juga analisis

tentang elastisitas dari OpenStack yaitu dengan melakukan uji coba resize

instance.

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().

Gambar 16 state diagram fungsi nova.compute.manager.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().

Gambar 18 state diagram fungsi nova.compute.manager.finish_resized

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 diagram fungsi 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.

Gambar 21 System monitor Linux Mint sebelum dan sesudah pergantian

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

yang lebih. Pada Gambar 23 terdapat 3 instances yang dibuat untuk

melakukan pengujian, setiap instance mempunyai RAM sebesar 1 GB.

Gambar 23 menunjukkan kondisi ketika setiap instance sudah dapat

digunakan tetapi belum dijalankan.

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 Memory used 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

Pada gambar 25 terlihat bahwa kondisi awal free RAM adalah 681492k,

kondisi ini merupakan kondisi RAM sebelum dilakukan 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

yang dalam hal ini menggunakan OpenStack. Dapat disimpulkan bahwa

ketika terjadi proses penggantian flavor, terjadi downtime selama 30 detik

yang mengakibatkan instance tidak dapat diakses. Dari hasil uji coba yang

sudah dilakukan dapat disimpulkan bahwa di OpenStack dapat dilakukan

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.

[8] Goldman, J.E., & Rawles, P.T., 2001, Applied Data

Communications, A Business-Oriented Approach, Hoboken : John

Wiley & Sons, Inc.