Flexiant Cloud Orchestrator: apa yang dimakannya



Untuk menyediakan layanan IaaS (Pusat Data Virtual), kami di Rusonyx menggunakan orkestra komersial Flexiant Cloud Orchestrator (FCO). Solusi ini memiliki arsitektur yang agak unik, yang membedakannya dari Openstack publik dan CloudStack yang terkenal.

Sebagai penghitung node hypervisor, KVM, VmWare, Xen, Virtuozzo6 / 7, serta kontainer dari Virtuozzo yang sama didukung. Dari penyimpanan yang didukung - penyimpanan lokal, NFS, Ceph dan Virtuozzo.

FCO mendukung pembuatan dan pengelolaan beberapa kluster dari satu antarmuka. Artinya, Anda dapat mengelola klaster Virtuozzo dan kluster KVM + Ceph dengan beralih di antara mereka dengan mengeklik tetikus.

Intinya, FCO adalah solusi komprehensif untuk penyedia cloud, yang, selain mengatur, juga mencakup penagihan, dengan semua pengaturan, plug-in pembayaran, akun, notifikasi, pengecer, tarif, dan sebagainya. Namun, bagian penagihan tidak dapat mencakup semua nuansa Rusia, jadi kami menolak untuk menggunakannya demi solusi lain.

Sistem fleksibel dalam mendistribusikan hak untuk semua sumber daya cloud sangat menyenangkan: gambar, disk, produk, server, firewall - semua ini bisa "dikacaukan" dan diberikan hak antara pengguna, dan bahkan antara pengguna klien yang berbeda. Setiap klien dapat membuat beberapa pusat data independen di cloud mereka dan mengelolanya dari panel kontrol tunggal.



Secara arsitektur, FCO terdiri dari beberapa bagian, yang masing-masing memiliki kode independen sendiri, dan beberapa memiliki database sendiri.

Skyline - admin dan antarmuka pengguna
Jade - logika bisnis, penagihan, manajemen tugas
Tigerlily adalah koordinator layanan yang mengelola dan mengoordinasikan pertukaran informasi antara logika bisnis dan kluster.
XVPManager - manajemen elemen cluster: node, penyimpanan, jaringan dan mesin virtual.
XVPAgent - agen yang diinstal pada node untuk berinteraksi dengan XVPManager



Sebuah kisah terperinci tentang arsitektur dari setiap komponen yang kami rencanakan cocok dengan serangkaian artikel, kecuali, tentu saja, topiknya menarik.

Keuntungan utama FCO berasal dari "kotak" -nya. Menawarkan kesederhanaan dan minimalis. Untuk node kontrol, satu mesin virtual di Ubuntu dialokasikan, di mana semua paket yang diperlukan diinstal. Semua pengaturan ditransfer ke 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 dikoreksi dalam template, kemudian generator mulai
# build-config yang akan membentuk file vars dan memerintahkan layanan untuk membaca kembali konfigurasi. Antarmuka pengguna bagus dan dapat dengan mudah diberi merek.



Seperti yang Anda lihat, antarmuka terdiri dari widget, yang manajemennya tersedia untuk pengguna. Dia dapat dengan mudah menambah / menghapus widget dari halaman, sehingga membentuk dashboard yang dia butuhkan.

Terlepas dari kedekatannya, FCO adalah sistem yang sangat dapat disesuaikan. Ini memiliki sejumlah besar pengaturan dan titik masuk untuk mengubah alur kerja:

  1. Plugin khusus didukung, misalnya, Anda dapat menulis metode penagihan Anda sendiri atau sumber daya eksternal Anda sendiri untuk diberikan kepada pengguna
  2. Pemicu khusus untuk acara tertentu didukung, misalnya, menambahkan mesin virtual pertama ke klien ketika dibuat
  3. Widget khusus didukung di antarmuka, misalnya, sematkan video dari youtube langsung di antarmuka pengguna.

Semua kustomisasi ditulis dalam bahasa FDL, yang didasarkan pada Lua. Jika Anda tahu Lua, tidak akan ada masalah dengan FDL.

Berikut adalah contoh dari salah satu pemicu paling sederhana yang kami gunakan. Pemicu ini tidak memungkinkan pengguna untuk berbagi gambar mereka sendiri dengan klien lain. Kami melakukan ini sehingga satu pengguna tidak dapat 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 kontes panggilan, dan pada panggilan pertama itu akan kosong (nihil). Itu akan memungkinkan kami untuk mendaftarkan pemicu kami. Di triggerType, kami menunjukkan bahwa pemicu disebut SEBELUM operasi penerbitan, dan hanya berlaku untuk pengguna. Untuk administrator sistem, tentu saja, kami mengizinkan semuanya dipublikasikan. Dalam triggerOptions, kami merinci operasi yang memicu trigger.

Dan yang paling penting, kembalikan {exitState = "CANCEL"}, itulah sebabnya pemicu dikembangkan. Ini akan mengembalikan kegagalan ketika pengguna mencoba untuk membagikan gambarnya di panel kontrol.

Dalam arsitektur FCO, objek apa pun (disk, server, gambar, jaringan, adaptor jaringan, dll.) Direpresentasikan sebagai entitas Sumber Daya yang memiliki parameter umum:

  • Sumberdaya uuid
  • nama sumber daya
  • jenis sumber daya
  • Pemilik sumber daya UUID
  • status sumber daya (aktif, tidak aktif)
  • metadata sumber daya
  • kunci sumber daya
  • UUID produk tempat sumber daya berada
  • Sumber Daya VDC

Ini sangat nyaman ketika bekerja pada API, ketika bekerja dengan semua sumber daya dilakukan dengan prinsip yang sama. Produk dikonfigurasikan oleh penyedia, dan pelanggan memesannya. Karena tagihan kami ada di sela-sela, klien dapat memesan produk apa pun dari panel tanpa biaya. Ini akan dipertimbangkan nanti dalam penagihan. Produk mungkin - alamat ip per jam, GB disk tambahan per jam, atau hanya server.

Anda dapat menandai sumber daya tertentu dengan kunci untuk mengubah logika bekerja dengannya. Misalnya, kita dapat menandai tiga simpul fisik dengan kunci Bobot, dan menandai beberapa klien dengan kunci yang sama, sehingga menyoroti simpul-simpul ini secara pribadi untuk klien-klien ini. Kami menggunakan mekanisme seperti itu untuk klien VIP yang tidak suka tetangga di sebelah VM mereka. Fungsionalitas itu sendiri dapat diterapkan secara lebih luas.

Model lisensi menyiratkan pembayaran untuk setiap inti prosesor dari simpul fisik. Biaya juga dipengaruhi oleh jumlah jenis cluster. Jika Anda berencana untuk menggunakan bersama, misalnya, KVM dan VMware, maka biaya lisensi akan meningkat.

FCO adalah produk lengkap, fungsinya sangat kaya, jadi kami berencana menyiapkan beberapa artikel sekaligus dengan deskripsi terperinci tentang fungsi bagian jaringan.

Setelah bekerja dengan orkestra ini selama beberapa tahun, kami dapat menandainya sebagai sangat cocok. Sayangnya, produk ini bukan tanpa cacat:

  • kami harus mengoptimalkan database, karena kueri mulai melambat karena jumlah data di dalamnya meningkat;
  • setelah satu kecelakaan, karena bug, mekanisme pemulihan tidak bekerja, dan kami harus meningkatkan mesin klien yang tidak puas dengan set script kami sendiri;
  • mekanisme deteksi tidak dapat diaksesnya node ditransfer ke dalam kode dan tidak dapat dikustomisasi. Artinya, kami tidak dapat membuat kebijakan kami sendiri untuk menentukan tidak dapat diaksesnya suatu node.
  • logging tidak selalu rinci. Terkadang, ketika Anda harus turun ke level yang sangat rendah untuk menganalisis masalah tertentu, kode sumber beberapa komponen tidak cukup untuk memahami alasannya;

JUMLAH: secara keseluruhan, pengalaman produk bagus. Kami terus berhubungan dengan pengembang orkestra. Orang-orang diatur untuk kerjasama yang konstruktif.

Meskipun sederhana, FCO memiliki fungsi yang luas. Dalam artikel mendatang, kami berencana mempelajari topik-topik berikut:

  • jaringan di FCO
  • dukungan live-recovery dan protokol FQP
  • menulis plugin dan widget khusus
  • menghubungkan layanan tambahan seperti Load Balancer dan Acronis
  • cadangan
  • mekanisme terpadu untuk mengkonfigurasi dan mengkonfigurasi node
  • pemrosesan metadata mesin virtual

PS Tulis komentar jika ada aspek lain yang menarik. Tetap disini!

Source: https://habr.com/ru/post/id449196/


All Articles