Upload
doankhanh
View
227
Download
0
Embed Size (px)
Citation preview
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.