Untuk menyediakan layanan IaaS (Pusat Data Virtual), kami kami menggunakan orkestrator komersial (FCO). Solusi ini memiliki arsitektur yang cukup unik, yang membedakannya dengan Openstack dan CloudStack yang dikenal masyarakat umum.
KVM, VmWare, Xen, Virtuozzo6/7, serta kontainer dari Virtuozzo yang sama didukung sebagai hypervisor node komputasi. Opsi penyimpanan yang didukung mencakup Penyimpanan lokal, NFS, Ceph, dan Virtuozzo.
FCO mendukung pembuatan dan pengelolaan beberapa cluster dari satu antarmuka. Artinya, Anda dapat mengelola cluster Virtuozzo dan cluster KVM + Ceph dengan beralih di antara keduanya dengan satu klik mouse.
Pada intinya, FCO adalah solusi komprehensif untuk penyedia cloud, yang selain orkestrasi, juga mencakup penagihan, dengan semua pengaturan, plugin pembayaran, faktur, notifikasi, pengecer, tarif, dan sebagainya. Namun, bagian penagihan tidak mampu mencakup semua nuansa Rusia, jadi kami mengabaikan penggunaannya demi solusi lain.
Saya sangat senang dengan sistem fleksibel untuk mendistribusikan hak atas semua sumber daya cloud: gambar, disk, produk, server, firewall - semua ini dapat “dibagikan” dan diberikan hak antar pengguna, dan bahkan antar pengguna klien yang berbeda. Setiap klien dapat membuat beberapa pusat data independen di cloud mereka dan mengelolanya dari satu panel kontrol.
Secara arsitektural, FCO terdiri dari beberapa bagian, yang masing-masing memiliki kode independennya sendiri, dan beberapa memiliki database sendiri.
Kaki langit – admin dan antarmuka pengguna
Giok – logika bisnis, penagihan, manajemen tugas
Harimau – koordinator layanan, mengelola dan mengoordinasikan pertukaran informasi antara logika bisnis dan cluster.
Manajer XVP – pengelolaan elemen cluster: node, penyimpanan, jaringan, dan mesin virtual.
Agen XVP – agen yang diinstal pada node untuk berinteraksi dengan XVPManager
Kami berencana untuk memasukkan cerita mendetail tentang arsitektur setiap komponen dalam serangkaian artikel, jika, tentu saja, topik tersebut menarik.
Keuntungan utama FCO berasal dari sifatnya yang “kotak”. Kesederhanaan dan minimalis siap melayani Anda. Untuk node kontrol, satu mesin virtual di Ubuntu dialokasikan, di mana semua paket yang diperlukan diinstal. Semua pengaturan ditempatkan di file konfigurasi dalam bentuk nilai variabel:
# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…
Seluruh konfigurasi awalnya diedit dalam template, kemudian generator diluncurkan
#build-config yang akan menghasilkan file vars dan memerintahkan layanan untuk membaca ulang konfigurasi. Antarmuka penggunanya bagus dan dapat dengan mudah diberi merek.
Seperti yang Anda lihat, antarmukanya terdiri dari widget yang dapat dikontrol oleh pengguna. Dia dapat dengan mudah menambah/menghapus widget dari halaman, sehingga membuat dashboard yang dia butuhkan.
Meskipun sifatnya tertutup, FCO adalah sistem yang sangat dapat disesuaikan. Ini memiliki sejumlah besar pengaturan dan titik masuk untuk mengubah alur kerja:
- Plugin khusus didukung, misalnya, Anda dapat menulis metode penagihan Anda sendiri atau sumber daya eksternal Anda sendiri untuk disediakan kepada pengguna
- Pemicu khusus untuk peristiwa tertentu didukung, misalnya, menambahkan mesin virtual pertama ke klien saat mesin tersebut dibuat
- Widget khusus di antarmuka didukung, misalnya, menyematkan video YouTube langsung ke antarmuka pengguna.
Semua penyesuaian ditulis dalam FDL, yang didasarkan pada Lua. Jika Anda mengenal Lua, tidak akan ada masalah dengan FDL.
Berikut adalah contoh salah satu pemicu paling sederhana yang kami gunakan. Pemicu ini tidak mengizinkan pengguna untuk berbagi gambar mereka sendiri dengan klien lain. Kami melakukan ini untuk mencegah satu pengguna membuat gambar berbahaya untuk pengguna lain.
function register()
return {"pre_user_api_publish"}
end
function pre_user_api_publish(p)
if(p==nil) then
return{
ref = "cancelPublishImage",
name = "Cancel publishing",
description = "Cancel all user’s images publishing",
triggerType = "PRE_USER_API_CALL",
triggerOptions = {"publishResource", "publishImage"},
api = "TRIGGER",
version = 1,
}
end
-- Turn publishing off
return {exitState = "CANCEL"}
end
Fungsi register akan dipanggil oleh kernel FCO. Ini akan mengembalikan nama fungsi yang akan dipanggil. Parameter “p” dari fungsi ini menyimpan konteks panggilan, dan saat pertama kali dipanggil akan kosong (nihil). Yang memungkinkan kita mendaftarkan pemicu kita. Di triggerType kami menunjukkan bahwa pemicu dipanggil SEBELUM operasi publikasi, dan hanya memengaruhi pengguna. Tentu saja, kami mengizinkan administrator sistem untuk mempublikasikan semuanya. Di triggerOptions kami memerinci operasi yang akan memicu pemicunya.
Dan yang utama adalah return {exitState = “CANCEL”}, itulah sebabnya trigger dikembangkan. Ini akan mengembalikan kegagalan ketika pengguna mencoba membagikan gambar mereka di panel kontrol.
Dalam arsitektur FCO, objek apa pun (disk, server, image, jaringan, adaptor jaringan, dll.) direpresentasikan sebagai entitas Sumber Daya, yang memiliki parameter umum:
- UUID Sumber Daya
- nama Sumberdaya
- jenis sumber daya
- UUID pemilik sumber daya
- status sumber daya (aktif, tidak aktif)
- metadata sumber daya
- kunci sumber daya
- UUID produk yang memiliki sumber daya
- sumber daya VDC
Ini sangat nyaman ketika bekerja menggunakan API, ketika semua sumber daya bekerja berdasarkan prinsip yang sama. Produk dikonfigurasi oleh penyedia dan dipesan oleh klien. Karena penagihan kami bersifat sampingan, klien dapat dengan bebas memesan produk apa pun dari panel. Itu akan dihitung nanti di penagihan. Produknya bisa berupa alamat IP per jam, tambahan GB disk per jam, atau hanya server.
Kunci dapat digunakan untuk menandai sumber daya tertentu untuk mengubah logika bekerja dengannya. Misalnya, kita dapat menandai tiga node fisik dengan tombol Weight, dan menandai beberapa klien dengan kunci yang sama, sehingga mengalokasikan node ini secara pribadi ke klien tersebut. Kami menggunakan mekanisme ini untuk klien VIP yang tidak menyukai tetangga di sebelah VM mereka. Fungsionalitasnya sendiri dapat digunakan lebih luas.
Model lisensi melibatkan pembayaran untuk setiap inti prosesor dari node fisik. Biaya juga dipengaruhi oleh jumlah tipe cluster. Jika Anda berencana menggunakan KVM dan VMware secara bersamaan, misalnya, biaya lisensinya akan meningkat.
FCO adalah produk lengkap, fungsinya sangat kaya, jadi kami berencana menyiapkan beberapa artikel sekaligus dengan penjelasan rinci tentang fungsi bagian jaringan.
Setelah bekerja dengan orkestra ini selama beberapa tahun, kami dapat menilainya sebagai sangat cocok. Sayangnya, produk ini bukannya tanpa kekurangan:
- kami harus mengoptimalkan database karena kueri mulai melambat seiring dengan bertambahnya jumlah data di dalamnya;
- setelah satu kecelakaan, mekanisme pemulihan tidak berfungsi karena ada bug, dan kami harus memulihkan mobil klien yang malang menggunakan rangkaian skrip kami sendiri;
- Mekanisme untuk mendeteksi ketidaktersediaan node sudah tertanam dalam kode dan tidak dapat disesuaikan. Artinya, kita tidak bisa membuat kebijakan sendiri untuk menentukan tidak tersedianya sebuah node.
- pencatatan tidak selalu rinci. Terkadang, ketika Anda perlu turun ke level yang sangat rendah untuk memahami masalah tertentu, Anda tidak memiliki cukup kode sumber untuk beberapa komponen untuk memahami alasannya;
TOTAL: Secara umum kesan produknya bagus. Kami terus berhubungan dengan pengembang orkestrator. Orang-orang cenderung melakukan kerja sama yang konstruktif.
Meskipun sederhana, FCO memiliki fungsionalitas yang luas. Dalam artikel mendatang kami berencana untuk mempelajari lebih dalam topik-topik berikut:
- jaringan di FCO
- menyediakan pemulihan langsung dan protokol FQP
- menulis plugin dan widget Anda sendiri
- menghubungkan layanan tambahan seperti Load Balancer dan Acronis
- cadangan
- mekanisme terpadu untuk mengkonfigurasi dan mengkonfigurasi node
- memproses metadata mesin virtual
ZY Tulis di komentar jika Anda tertarik dengan aspek lainnya. Pantau terus!
Sumber: www.habr.com