Upang magbigay ng mga serbisyo ng IaaS (Virtual Data Center), kami gumagamit kami ng isang komersyal na orkestra (FCO). Ang solusyon na ito ay may medyo kakaibang arkitektura, na nakikilala ito sa Openstack at CloudStack, na kilala sa pangkalahatang publiko.
KVM, VmWare, Xen, Virtuozzo6/7, pati na rin ang mga container mula sa parehong Virtuozzo ay sinusuportahan bilang compute node hypervisors. Kasama sa mga sinusuportahang opsyon sa storage ang lokal, NFS, Ceph at Virtuozzo Storage.
Sinusuportahan ng FCO ang paglikha at pamamahala ng maraming kumpol mula sa iisang interface. Iyon ay, maaari mong pamahalaan ang isang Virtuozzo cluster at isang KVM + Ceph cluster sa pamamagitan ng paglipat sa pagitan ng mga ito gamit ang isang pag-click ng mouse.
Sa kaibuturan nito, ang FCO ay isang komprehensibong solusyon para sa mga cloud provider, na, bilang karagdagan sa orkestrasyon, kasama rin ang pagsingil, kasama ang lahat ng mga setting, mga plugin ng pagbabayad, mga invoice, mga notification, mga reseller, mga taripa, at iba pa. Gayunpaman, ang bahagi ng pagsingil ay hindi kayang saklawin ang lahat ng mga nuances ng Russia, kaya tinalikuran namin ang paggamit nito pabor sa isa pang solusyon.
Lubos akong nalulugod sa flexible system para sa pamamahagi ng mga karapatan sa lahat ng cloud resources: mga imahe, disk, produkto, server, firewall - lahat ng ito ay maaaring "ibahagi" at bigyan ng mga karapatan sa pagitan ng mga user, at maging sa pagitan ng mga user ng iba't ibang kliyente. Ang bawat kliyente ay maaaring gumawa ng ilang independiyenteng data center sa kanilang cloud at pamahalaan ang mga ito mula sa isang control panel.
Sa arkitektura, ang FCO ay binubuo ng ilang bahagi, ang bawat isa ay may sariling independiyenteng code, at ang ilan ay may sariling database.
Skyline – admin at user interface
magpapagod – lohika ng negosyo, pagsingil, pamamahala ng gawain
tigrelily – service coordinator, namamahala at nagkoordina sa pagpapalitan ng impormasyon sa pagitan ng lohika ng negosyo at mga kumpol.
XVPManager – pamamahala ng mga elemento ng cluster: mga node, storage, network at virtual machine.
XPAgent – isang ahente na naka-install sa mga node upang makipag-ugnayan sa XVPManager
Plano naming isama ang isang detalyadong kuwento tungkol sa arkitektura ng bawat bahagi sa isang serye ng mga artikulo, kung, siyempre, ang paksa ay nakakapukaw ng interes.
Ang pangunahing bentahe ng FCO ay nagmumula sa likas na "kahon" nito. Ang pagiging simple at minimalism ay nasa iyong serbisyo. Para sa control node, isang virtual machine sa Ubuntu ang inilalaan, kung saan naka-install ang lahat ng kinakailangang pakete. Ang lahat ng mga setting ay inilalagay sa mga file ng pagsasaayos sa anyo ng isang variable-value:
# 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"
…
Ang buong configuration ay unang na-edit sa mga template, pagkatapos ay inilunsad ang generator
#build-config na bubuo ng vars file at uutusan ang mga serbisyo na muling basahin ang config. Ang user interface ay maganda at madaling ma-brand.
Tulad ng nakikita mo, ang interface ay binubuo ng mga widget na maaaring kontrolin ng user. Madali siyang magdagdag/mag-alis ng mga widget mula sa page, sa gayon ay ginagawa ang dashboard na kailangan niya.
Sa kabila ng pagiging sarado nito, ang FCO ay isang lubos na nako-customize na sistema. Mayroon itong malaking bilang ng mga setting at entry point para sa pagbabago ng daloy ng trabaho:
- Sinusuportahan ang mga custom na plugin, halimbawa, maaari mong isulat ang iyong sariling paraan ng pagsingil o ang iyong sariling panlabas na mapagkukunan upang mabigyan ang user ng
- Ang mga custom na pag-trigger para sa ilang partikular na kaganapan ay sinusuportahan, halimbawa, pagdaragdag ng unang virtual machine sa isang kliyente kapag ito ay ginawa
- Sinusuportahan ang mga custom na widget sa interface, halimbawa, direktang pag-embed ng video sa YouTube sa user interface.
Ang lahat ng pagpapasadya ay nakasulat sa FDL, na nakabatay sa Lua. Kung kilala mo si Lua, walang magiging problema sa FDL.
Narito ang isang halimbawa ng isa sa mga pinakasimpleng trigger na ginagamit namin. Ang trigger na ito ay hindi nagpapahintulot sa mga user na ibahagi ang kanilang sariling mga larawan sa ibang mga kliyente. Ginagawa namin ito upang pigilan ang isang user na gumawa ng nakakahamak na larawan para sa ibang mga user.
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
Ang register function ay tatawagin ng FCO kernel. Ibabalik nito ang pangalan ng function na tatawagin. Ang "p" na parameter ng function na ito ay nag-iimbak ng konteksto ng tawag, at sa unang pagkakataong ito ay tinatawag na ito ay magiging walang laman (nil). Na magpapahintulot sa amin na irehistro ang aming trigger. Sa triggerType, ipinapahiwatig namin na ang trigger ay ginagamit BAGO ang pag-publish na operasyon, at nakakaapekto lamang sa mga user. Siyempre, pinapayagan namin ang mga administrator ng system na i-publish ang lahat. Sa triggerOptions, idedetalye namin ang mga operasyon kung saan gagana ang trigger.
At ang pangunahing bagay ay ibalik ang {exitState = “CANCEL”}, kaya naman binuo ang trigger. Magbabalik ito ng kabiguan kapag sinubukan ng user na ibahagi ang kanilang larawan sa control panel.
Sa arkitektura ng FCO, ang anumang bagay (disk, server, imahe, network, network adapter, atbp.) ay kinakatawan bilang Resource entity, na may mga karaniwang parameter:
- Resource UUID
- pangalan ng mapagkukunan
- uri ng mapagkukunan
- UUID na may-ari ng mapagkukunan
- katayuan ng mapagkukunan (aktibo, hindi aktibo)
- metadata ng mapagkukunan
- mga susi ng mapagkukunan
- UUID ng produkto na nagmamay-ari ng mapagkukunan
- mapagkukunan VDC
Ito ay napaka-maginhawa kapag nagtatrabaho gamit ang isang API, kapag ang lahat ng mga mapagkukunan ay ginawa ayon sa parehong prinsipyo. Ang mga produkto ay na-configure ng provider at iniutos ng kliyente. Dahil nasa gilid ang aming pagsingil, malayang makakapag-order ang kliyente ng anumang produkto mula sa panel. Kakalkulahin ito mamaya sa pagsingil. Ang produkto ay maaaring isang IP address bawat oras, isang karagdagang GB ng disk bawat oras, o isang server lamang.
Maaaring gamitin ang mga susi upang markahan ang ilang partikular na mapagkukunan upang baguhin ang lohika ng pakikipagtulungan sa kanila. Halimbawa, maaari nating markahan ang tatlong pisikal na node gamit ang Weight key, at markahan ang ilang kliyente ng parehong key, at sa gayon ay personal na inilalaan ang mga node na ito sa mga kliyenteng ito. Ginagamit namin ang mekanismong ito para sa mga kliyenteng VIP na hindi gusto ang mga kapitbahay sa tabi ng kanilang mga VM. Ang pag-andar mismo ay maaaring magamit nang mas malawak.
Kasama sa modelo ng paglilisensya ang pagbabayad para sa bawat core ng processor ng isang pisikal na node. Ang gastos ay apektado din ng bilang ng mga uri ng cluster. Kung plano mong gamitin ang KVM at VMware nang magkasama, halimbawa, tataas ang halaga ng lisensya.
Ang FCO ay isang ganap na produkto, ang pag-andar nito ay napakayaman, kaya plano naming maghanda ng ilang mga artikulo nang sabay-sabay na may detalyadong paglalarawan ng paggana ng bahagi ng network.
Ang pagkakaroon ng trabaho sa orkestrator na ito sa loob ng maraming taon, maaari naming markahan ito bilang napaka-angkop. Sa kasamaang palad, ang produkto ay walang mga bahid:
- kailangan naming i-optimize ang database dahil ang mga query ay nagsimulang bumagal habang ang dami ng data sa mga ito ay tumaas;
- pagkatapos ng isang aksidente, hindi gumana ang mekanismo ng pagbawi dahil sa isang bug, at kinailangan naming bawiin ang mga sasakyan ng mga kapus-palad na kliyente gamit ang aming sariling hanay ng mga script;
- Ang mekanismo para sa pag-detect ng hindi available na node ay naka-hardwired sa code at hindi maaaring i-customize. Ibig sabihin, hindi kami makakagawa ng sarili naming mga patakaran para sa pagtukoy sa hindi pagiging available ng isang node.
- hindi laging detalyado ang pag-log. Minsan, kapag kailangan mong bumaba sa isang napakababang antas upang maunawaan ang isang partikular na problema, wala kang sapat na source code para maunawaan ng ilang bahagi kung bakit;
TOTAL: Sa pangkalahatan, maganda ang mga impression ng produkto. Patuloy kaming nakikipag-ugnayan sa mga developer ng orkestra. Ang mga lalaki ay nakalaan sa nakabubuo na kooperasyon.
Sa kabila ng pagiging simple nito, ang FCO ay may malawak na pag-andar. Sa mga artikulo sa hinaharap, pinaplano naming suriin nang mas malalim ang mga sumusunod na paksa:
- networking sa FCO
- pagbibigay ng live-recovery at FQP protocol
- pagsulat ng iyong sariling mga plugin at widget
- pagkonekta ng mga karagdagang serbisyo tulad ng Load Balancer at Acronis
- backup
- pinag-isang mekanismo para sa pag-configure at pag-configure ng mga node
- pagproseso ng virtual machine metadata
Z.Y. Sumulat sa mga komento kung interesado ka sa iba pang aspeto. Manatiling nakatutok!
Pinagmulan: www.habr.com