Jasa Managed OpenStack

Komponen OpenStack yang kami pasang dan rawat

Kami memasang komponen sesuai kebutuhan nyata, bukan seluruh katalog — semakin sedikit komponen, semakin sedikit pula yang bisa rusak:

• Keystone — layanan identitas dan autentikasi terpusat.
• Nova — pengelolaan instance komputasi.
• Neutron — jaringan virtual, router, dan alamat IP mengambang.
• Cinder — penyimpanan blok yang dapat dipasang ke instance.
• Glance — katalog image sistem operasi.
• Horizon — antarmuka web untuk pengguna dan administrator.
• Ceph — lapisan penyimpanan terdistribusi sebagai fondasi Cinder dan Glance.

Perancangan kapasitas dan high availability

Kesalahan perancangan pada tahap awal paling mahal untuk diperbaiki. Karena itu kami memulai dari beban kerja yang akan dijalankan, lalu menghitung mundur kebutuhan CPU, memori, penyimpanan, dan jaringan — bukan sebaliknya.

Untuk lingkungan produksi, komponen kendali dijalankan pada beberapa node dengan penyeimbang beban di depannya, sehingga kegagalan satu node tidak membuat seluruh cloud tak bisa dikendalikan. Skenario kegagalan diuji sebelum lingkungan diserahkan.

Pembaruan versi tanpa mengganggu layanan

OpenStack merilis versi baru dua kali setahun. Melewatkan terlalu banyak versi membuat pembaruan berikutnya jauh lebih berisiko, karena lompatan perubahannya menjadi besar.

Kami menjaga jarak versi tetap wajar, menguji setiap pembaruan di lingkungan terpisah lebih dulu, dan menjalankannya node demi node agar layanan tetap berjalan selama proses berlangsung.

Dari uji coba ke deploy OpenStack production

Jarak antara OpenStack yang jalan di laboratorium dan OpenStack yang layak dipakai produksi cukup jauh. Yang membedakannya bukan komponen tambahan, tapi hal-hal yang tidak terlihat saat semuanya normal: bagaimana perilaku cluster ketika satu node kendali mati, apa yang terjadi pada mesin virtual saat jaringan penyimpanan terputus sesaat, dan apakah cadangan basis data konfigurasinya benar-benar bisa dipulihkan.

Untuk deploy OpenStack production kami menguji ketiga skenario itu sebelum lingkungan diserahkan. Node dimatikan satu per satu dengan sengaja, jaringan penyimpanan diputus sementara, lalu pemulihan basis data Keystone dan Nova dilatih dari cadangan. Hasil setiap pengujian ditulis, termasuk yang gagal dan apa yang diperbaiki setelahnya.

Jaringan dan penyimpanan: Neutron dan Cinder

Dua komponen yang paling sering menjadi sumber masalah adalah OpenStack Neutron Cinder — jaringan virtual dan penyimpanan blok. Neutron karena pilihan mekanismenya banyak dan salah pilih berarti menata ulang dari awal; Cinder karena performanya sangat bergantung pada lapisan penyimpanan di bawahnya.

Untuk jaringan kami umumnya memakai OVN, yang jauh lebih sederhana dirawat dibanding kombinasi agen lama. Untuk penyimpanan, Ceph menjadi pilihan default karena datanya tersebar sehingga mesin virtual bisa dinyalakan di node mana pun. Keduanya menuntut jaringan terpisah untuk lalu lintas penyimpanan — kalau digabung dengan lalu lintas pengguna, performanya akan naik-turun tanpa pola yang jelas.

Maintenance OpenStack setelah lingkungan berjalan

Pekerjaan maintenance OpenStack yang rutin justru yang paling sering ditunda: memangkas basis data yang menyimpan riwayat instance bertahun-tahun, membersihkan image lama yang sudah tidak dipakai, memantau kapasitas Ceph sebelum menyentuh ambang yang membuat cluster berhenti menerima tulisan, dan memperbarui sertifikat internal sebelum kedaluwarsa.

Sebagai mitra implementasi OpenStack Indonesia, hal-hal inilah yang kami jadwalkan dan laporkan — bukan hanya menangani gangguan setelah terjadi. Kapasitas penyimpanan khususnya perlu peringatan dini, karena Ceph yang penuh jauh lebih sulit dipulihkan daripada Ceph yang hampir penuh.

Pemeliharaan rutin ini juga yang menentukan seberapa mulus pembaruan versi berikutnya. Cluster yang basis datanya rapi dan image-nya terkurasi bisa di-upgrade dalam satu jendela pemeliharaan; yang dibiarkan menumpuk bertahun-tahun sering butuh pekerjaan pembersihan lebih dulu.

Biaya sebenarnya memiliki private cloud sendiri

Perangkat lunaknya tanpa biaya lisensi, dan itu yang membuat OpenStack menarik. Tetapi perbandingan yang adil harus memasukkan seluruh komponen: perangkat keras beserta penggantiannya dalam empat sampai lima tahun, ruang rak dan listrik, jaringan, serta tenaga yang merawatnya.

Titik ketika OpenStack menjadi lebih murah daripada menyewa cloud publik biasanya muncul saat beban kerja berjalan stabil sepanjang tahun dan kapasitasnya sudah cukup besar. Untuk beban yang naik-turun tajam atau masih kecil, menyewa hampir selalu lebih ekonomis.

Kami menghitung kedua skenario dengan angka Anda sebelum menyarankan apa pun. Kalau hasilnya menunjukkan menyewa lebih murah, itu yang kami sampaikan — meski artinya pekerjaan implementasinya tidak ada.

Skenario ketiga yang sering terlupakan: memakai OpenStack hanya untuk sebagian beban kerja, dan menyewa cloud publik untuk sisanya. Pola ini menghindari pembelian kapasitas puncak yang jarang terpakai, dengan konsekuensi ada dua lingkungan yang harus dipantau dan didokumentasikan.