Flexiant Cloud Orchestrator: ສິ່ງທີ່ມັນມາພ້ອມກັບ

ເພື່ອໃຫ້ບໍລິການ IaaS (Virtual Data Center), ພວກເຮົາ Rusonyx ພວກເຮົາໃຊ້ວົງດົນຕີການຄ້າ Flexiant Cloud Orchestrator (FCO). ການແກ້ໄຂນີ້ມີສະຖາປັດຕະຍະກໍາທີ່ເປັນເອກະລັກ, ເຊິ່ງແຕກຕ່າງຈາກ Openstack ແລະ CloudStack, ເປັນທີ່ຮູ້ຈັກກັບປະຊາຊົນທົ່ວໄປ.

KVM, VmWare, Xen, Virtuozzo6/7, ເຊັ່ນດຽວກັນກັບບັນຈຸຈາກ Virtuozzo ດຽວກັນໄດ້ຮັບການສະຫນັບສະຫນູນເປັນ hypervisors node ຄອມພິວເຕີ. ທາງເລືອກການເກັບຮັກສາທີ່ສະຫນັບສະຫນູນປະກອບມີທ້ອງຖິ່ນ, NFS, Ceph ແລະ Virtuozzo Storage.

FCO ສະຫນັບສະຫນູນການສ້າງແລະການຄຸ້ມຄອງຫຼາຍກຸ່ມຈາກການໂຕ້ຕອບດຽວ. ນັ້ນແມ່ນ, ທ່ານສາມາດຈັດການກຸ່ມ Virtuozzo ແລະກຸ່ມ KVM + Ceph ໂດຍການປ່ຽນລະຫວ່າງພວກມັນດ້ວຍການຄລິກຫນູ.

ຢູ່ໃນຫຼັກຂອງມັນ, FCO ແມ່ນການແກ້ໄຂທີ່ສົມບູນແບບສໍາລັບຜູ້ໃຫ້ບໍລິການຟັງ, ເຊິ່ງນອກເຫນືອຈາກການ orchestration, ຍັງປະກອບມີການເອີ້ນເກັບເງິນ, ດ້ວຍການຕັ້ງຄ່າທັງຫມົດ, plugins ການຈ່າຍເງິນ, ໃບແຈ້ງຫນີ້, ການແຈ້ງເຕືອນ, ຜູ້ຂາຍ, ອັດຕາພາສີ, ແລະອື່ນໆ. ຢ່າງໃດກໍຕາມ, ພາກສ່ວນການເອີ້ນເກັບເງິນແມ່ນບໍ່ສາມາດກວມເອົາ nuances ລັດເຊຍທັງຫມົດ, ດັ່ງນັ້ນພວກເຮົາປະຖິ້ມການນໍາໃຊ້ຂອງຕົນໃນເງື່ອນໄຂຂອງການແກ້ໄຂອື່ນ.

ຂ້ອຍດີໃຈຫຼາຍກັບລະບົບທີ່ມີຄວາມຍືດຫຍຸ່ນໃນການແຈກຢາຍສິດທິຂອງຊັບພະຍາກອນຟັງທັງຫມົດ: ຮູບພາບ, ແຜ່ນ, ຜະລິດຕະພັນ, ເຄື່ອງແມ່ຂ່າຍ, ໄຟວໍ - ທັງຫມົດນີ້ສາມາດຖືກ "ແບ່ງປັນ" ແລະໃຫ້ສິດລະຫວ່າງຜູ້ໃຊ້, ແລະແມ້ກະທັ້ງລະຫວ່າງຜູ້ໃຊ້ຂອງລູກຄ້າທີ່ແຕກຕ່າງກັນ. ລູກຄ້າແຕ່ລະຄົນສາມາດສ້າງສູນຂໍ້ມູນເອກະລາດຫຼາຍສູນໃນຄລາວຂອງເຂົາເຈົ້າແລະຈັດການໃຫ້ເຂົາເຈົ້າຈາກແຜງຄວບຄຸມດຽວ.

ໃນສະຖາປັດຕະຍະກໍາ, FCO ປະກອບດ້ວຍຫຼາຍພາກສ່ວນ, ແຕ່ລະຄົນມີລະຫັດເອກະລາດຂອງຕົນເອງ, ແລະບາງສ່ວນມີຖານຂໍ້ມູນຂອງຕົນເອງ.

Skyline - admin ແລະ​ການ​ໂຕ້​ຕອບ​ຜູ້​ໃຊ້​
Jade - ຕາມ​ເຫດ​ຜົນ​ທຸ​ລະ​ກິດ​, ໃບ​ບິນ​, ການ​ຄຸ້ມ​ຄອງ​ວຽກ​ງານ​
Tigerlily – ຜູ້​ປະ​ສານ​ງານ​ການ​ບໍ​ລິ​ການ​, ຄຸ້ມ​ຄອງ​ແລະ​ປະ​ສານ​ງານ​ການ​ແລກ​ປ່ຽນ​ຂໍ້​ມູນ​ລະ​ຫວ່າງ​ເຫດ​ຜົນ​ທຸ​ລະ​ກິດ​ແລະ​ກຸ່ມ​.
XVPManager - ການ​ຄຸ້ມ​ຄອງ​ອົງ​ປະ​ກອບ​ຂອງ​ກຸ່ມ​: nodes​, ການ​ເກັບ​ຮັກ​ສາ​, ເຄືອ​ຂ່າຍ​ແລະ virtual machines​.
XVPAgent – ຕົວແທນທີ່ຕິດຕັ້ງຢູ່ໃນ nodes ເພື່ອໂຕ້ຕອບກັບ XVPManager

ພວກເຮົາວາງແຜນທີ່ຈະລວມເອົາເລື່ອງລາຍລະອຽດກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງແຕ່ລະອົງປະກອບໃນຊຸດຂອງບົດຄວາມ, ຖ້າຫາກວ່າ, ແນ່ນອນ, ຫົວຂໍ້ທີ່ເຮັດໃຫ້ເກີດຄວາມສົນໃຈ.

ປະໂຫຍດຕົ້ນຕໍຂອງ FCO ແມ່ນມາຈາກລັກສະນະ "ກ່ອງ" ຂອງມັນ. ຄວາມລຽບງ່າຍ ແລະ ໜ້ອຍທີ່ສຸດຢູ່ໃນການບໍລິການຂອງເຈົ້າ. ສໍາລັບໂຫນດຄວບຄຸມ, ເຄື່ອງ virtual ຫນຶ່ງໃນ Ubuntu ໄດ້ຖືກຈັດສັນ, ເຊິ່ງຊຸດທີ່ຈໍາເປັນທັງຫມົດໄດ້ຖືກຕິດຕັ້ງ. ການ​ຕັ້ງ​ຄ່າ​ທັງ​ຫມົດ​ແມ່ນ​ໄດ້​ຖືກ​ຈັດ​ໃສ່​ໃນ​ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ໃນ​ຮູບ​ແບບ​ຂອງ​ຕົວ​ປ່ຽນ​ແປງ​ຄ່າ​:

# 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"
…

ການຕັ້ງຄ່າທັງຫມົດແມ່ນການແກ້ໄຂໃນເບື້ອງຕົ້ນໃນແມ່ແບບ, ຫຼັງຈາກນັ້ນເຄື່ອງກໍາເນີດແມ່ນເປີດຕົວ
#build-config ເຊິ່ງຈະສ້າງໄຟລ໌ vars ແລະສັ່ງໃຫ້ການບໍລິການອ່ານຄືນ config. ການໂຕ້ຕອບຜູ້ໃຊ້ແມ່ນງາມແລະສາມາດສ້າງຍີ່ຫໍ້ໄດ້ງ່າຍ.

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການໂຕ້ຕອບປະກອບດ້ວຍ widget ທີ່ສາມາດຄວບຄຸມໄດ້ໂດຍຜູ້ໃຊ້. ລາວສາມາດເພີ່ມ / ເອົາ widget ອອກຈາກຫນ້າໄດ້ງ່າຍ, ດັ່ງນັ້ນການສ້າງ dashboard ທີ່ລາວຕ້ອງການ.

ເຖິງວ່າຈະມີລັກສະນະປິດຂອງມັນ, FCO ແມ່ນລະບົບທີ່ສາມາດປັບແຕ່ງໄດ້ສູງ. ມັນມີການຕັ້ງຄ່າ ແລະຈຸດເຂົ້າຈຳນວນຫຼວງຫຼາຍສຳລັບການປ່ຽນແປງຂັ້ນຕອນການເຮັດວຽກ:

1. plugins ແບບກໍານົດເອງໄດ້ຮັບການສະຫນັບສະຫນູນ, ສໍາລັບການຍົກຕົວຢ່າງ, ທ່ານສາມາດຂຽນວິທີການໃບບິນຂອງທ່ານເອງຫຼືຊັບພະຍາກອນພາຍນອກຂອງທ່ານເອງເພື່ອໃຫ້ຜູ້ໃຊ້ມີ.
2. ຕົວກະຕຸ້ນແບບກຳນົດເອງສຳລັບເຫດການສະເພາະແມ່ນຮອງຮັບ, ຕົວຢ່າງ, ການເພີ່ມເຄື່ອງ virtual ທຳອິດໃຫ້ກັບລູກຄ້າເມື່ອມັນຖືກສ້າງ.
3. widget ທີ່ກໍາຫນົດເອງໃນການໂຕ້ຕອບແມ່ນສະຫນັບສະຫນູນ, ສໍາລັບການຍົກຕົວຢ່າງ, ການຝັງວິດີໂອ YouTube ໂດຍກົງໃນການໂຕ້ຕອບຜູ້ໃຊ້.

ການປັບແຕ່ງທັງຫມົດແມ່ນຂຽນໃນ FDL, ເຊິ່ງອີງໃສ່ Lua. ຖ້າທ່ານຮູ້ຈັກ Lua, ຈະບໍ່ມີບັນຫາກັບ FDL.

ນີ້ແມ່ນຕົວຢ່າງໜຶ່ງຂອງຕົວກະຕຸ້ນທີ່ງ່າຍທີ່ສຸດທີ່ພວກເຮົາໃຊ້. ຕົວກະຕຸ້ນນີ້ບໍ່ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດແບ່ງປັນຮູບພາບຂອງຕົນເອງກັບລູກຄ້າອື່ນໆ. ພວກເຮົາເຮັດອັນນີ້ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຊ້ຄົນໜຶ່ງສ້າງຮູບພາບທີ່ເປັນອັນຕະລາຍຕໍ່ຜູ້ໃຊ້ອື່ນ.

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

ຟັງຊັນການລົງທະບຽນຈະຖືກເອີ້ນໂດຍແກ່ນ FCO. ມັນຈະສົ່ງຄືນຊື່ຂອງຟັງຊັນທີ່ຈະເອີ້ນ. ພາລາມິເຕີ "p" ຂອງຟັງຊັນນີ້ເກັບຮັກສາບໍລິບົດການໂທ, ແລະຄັ້ງທໍາອິດທີ່ມັນຖືກເອີ້ນວ່າມັນຈະຫວ່າງເປົ່າ (nil). ເຊິ່ງຈະຊ່ວຍໃຫ້ພວກເຮົາລົງທະບຽນຕົວກະຕຸ້ນຂອງພວກເຮົາ. ໃນ triggerType ພວກເຮົາຊີ້ບອກວ່າ trigger ໄດ້ຖືກເອີ້ນກ່ອນທີ່ຈະດໍາເນີນການເຜີຍແຜ່, ແລະມີພຽງແຕ່ຜົນກະທົບຕໍ່ຜູ້ໃຊ້. ແນ່ນອນ, ພວກເຮົາອະນຸຍາດໃຫ້ຜູ້ເບິ່ງແຍງລະບົບເຜີຍແຜ່ທຸກສິ່ງທຸກຢ່າງ. ໃນ triggerOptions ພວກເຮົາລາຍລະອຽດການດໍາເນີນງານທີ່ trigger ຈະ fire.

ແລະສິ່ງທີ່ສໍາຄັນແມ່ນການກັບຄືນ {exitState = “CANCEL”}, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າຕົວກະຕຸ້ນໄດ້ຖືກພັດທະນາ. ມັນຈະກັບຄືນຄວາມລົ້ມເຫຼວໃນເວລາທີ່ຜູ້ໃຊ້ພະຍາຍາມແບ່ງປັນຮູບພາບຂອງເຂົາເຈົ້າຢູ່ໃນກະດານຄວບຄຸມ.

ໃນສະຖາປັດຕະຍະກໍາ FCO, ວັດຖຸໃດນຶ່ງ (ແຜ່ນ, ເຊີບເວີ, ຮູບພາບ, ເຄືອຂ່າຍ, ອະແດບເຕີເຄືອຂ່າຍ, ແລະອື່ນໆ) ແມ່ນເປັນຕົວແທນຂອງຊັບພະຍາກອນ, ທີ່ມີຕົວກໍານົດການທົ່ວໄປ:

• UUID ຊັບພະຍາກອນ
• ຊື່ຊັບພະຍາກອນ
• ປະເພດຊັບພະຍາກອນ
• ເຈົ້າຂອງຊັບພະຍາກອນ UUID
• ສະ​ຖາ​ນະ​ຊັບ​ພະ​ຍາ​ກອນ (ບໍ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​, ບໍ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​)
• metadata ຊັບພະຍາກອນ
• ກະແຈຊັບພະຍາກອນ
• UUID ຂອງຜະລິດຕະພັນທີ່ເປັນເຈົ້າຂອງຊັບພະຍາກອນ
• ຊັບພະຍາກອນ VDC

ນີ້ແມ່ນສະດວກຫຼາຍໃນເວລາທີ່ເຮັດວຽກໂດຍໃຊ້ API, ເມື່ອຊັບພະຍາກອນທັງຫມົດເຮັດວຽກຕາມຫຼັກການດຽວກັນ. ຜະລິດຕະພັນຖືກຕັ້ງຄ່າໂດຍຜູ້ໃຫ້ບໍລິການແລະສັ່ງໂດຍລູກຄ້າ. ເນື່ອງຈາກໃບບິນຂອງພວກເຮົາແມ່ນຢູ່ດ້ານຂ້າງ, ລູກຄ້າສາມາດສັ່ງຊື້ສິນຄ້າໃດໆຈາກກະດານໄດ້. ມັນຈະຖືກຄິດໄລ່ພາຍຫຼັງໃນການຮຽກເກັບເງິນ. ຜະລິດຕະພັນສາມາດເປັນທີ່ຢູ່ IP ຕໍ່ຊົ່ວໂມງ, ເພີ່ມເຕີມ GB ຂອງແຜ່ນຕໍ່ຊົ່ວໂມງ, ຫຼືພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍ.

ຄີສາມາດຖືກນໍາໃຊ້ເພື່ອຫມາຍຊັບພະຍາກອນທີ່ແນ່ນອນເພື່ອປ່ຽນເຫດຜົນຂອງການເຮັດວຽກກັບພວກເຂົາ. ຕົວຢ່າງ, ພວກເຮົາສາມາດຫມາຍສາມໂຫນດທາງດ້ານຮ່າງກາຍດ້ວຍປຸ່ມນ້ໍາຫນັກ, ແລະຫມາຍລູກຄ້າບາງຄົນດ້ວຍກະແຈດຽວກັນ, ດັ່ງນັ້ນການຈັດສັນ nodes ສ່ວນບຸກຄົນໃຫ້ກັບລູກຄ້າເຫຼົ່ານີ້. ພວກເຮົາໃຊ້ກົນໄກນີ້ສໍາລັບລູກຄ້າ VIP ທີ່ບໍ່ມັກເພື່ອນບ້ານໃກ້ກັບ VMs ຂອງພວກເຂົາ. ການທໍາງານຂອງຕົວມັນເອງສາມາດຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງຫຼາຍ.

ຮູບແບບການອອກໃບອະນຸຍາດກ່ຽວຂ້ອງກັບການຈ່າຍເງິນສໍາລັບແຕ່ລະຫຼັກຂອງໂປເຊດເຊີຂອງ node ທາງດ້ານຮ່າງກາຍ. ຄ່າໃຊ້ຈ່າຍຍັງໄດ້ຮັບຜົນກະທົບຈາກຈໍານວນປະເພດຂອງກຸ່ມ. ຖ້າທ່ານວາງແຜນທີ່ຈະໃຊ້ KVM ແລະ VMware ຮ່ວມກັນ, ສໍາລັບຕົວຢ່າງ, ຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດຈະເພີ່ມຂຶ້ນ.

FCO ແມ່ນຜະລິດຕະພັນເຕັມຮູບແບບ, ຫນ້າທີ່ຂອງມັນມີຄວາມອຸດົມສົມບູນຫຼາຍ, ດັ່ງນັ້ນພວກເຮົາວາງແຜນທີ່ຈະກະກຽມບົດຄວາມຫຼາຍໆຄັ້ງພ້ອມໆກັນກັບລາຍລະອຽດຂອງການເຮັດວຽກຂອງພາກສ່ວນເຄືອຂ່າຍ.

ໂດຍໄດ້ເຮັດວຽກກັບວົງດົນຕີນີ້ເປັນເວລາຫຼາຍປີ, ພວກເຮົາສາມາດຫມາຍວ່າມັນເຫມາະສົມຫຼາຍ. ອະນິຈາ, ຜະລິດຕະພັນບໍ່ແມ່ນບໍ່ມີຂໍ້ບົກພ່ອງ:

• ພວກເຮົາຕ້ອງເພີ່ມປະສິດທິພາບຖານຂໍ້ມູນເພາະວ່າການສອບຖາມເລີ່ມຊ້າລົງຍ້ອນວ່າຈໍານວນຂໍ້ມູນໃນພວກມັນເພີ່ມຂຶ້ນ;
• ຫຼັງຈາກອຸປະຕິເຫດຄັ້ງຫນຶ່ງ, ກົນໄກການຟື້ນຕົວບໍ່ໄດ້ເຮັດວຽກເນື່ອງຈາກມີ bug, ແລະພວກເຮົາຕ້ອງໄດ້ຟື້ນຕົວລົດຂອງລູກຄ້າທີ່ໂຊກບໍ່ດີໂດຍໃຊ້ຕົວກໍານົດຂອງພວກເຮົາເອງ;
• ກົນໄກສໍາລັບການກວດສອບຄວາມບໍ່ມີຂອງ node ແມ່ນ hardwired ເຂົ້າໄປໃນລະຫັດແລະບໍ່ສາມາດປັບແຕ່ງໄດ້. ນັ້ນແມ່ນ, ພວກເຮົາບໍ່ສາມາດສ້າງນະໂຍບາຍຂອງພວກເຮົາເອງເພື່ອກໍານົດຄວາມບໍ່ພ້ອມຂອງ node.
• ການບັນທຶກບໍ່ແມ່ນລາຍລະອຽດສະ ເໝີ ໄປ. ບາງຄັ້ງ, ໃນເວລາທີ່ທ່ານຈໍາເປັນຕ້ອງລົງໄປໃນລະດັບຕ່ໍາຫຼາຍເພື່ອເຂົ້າໃຈບັນຫາສະເພາະໃດຫນຶ່ງ, ທ່ານບໍ່ມີລະຫັດແຫຼ່ງພຽງພໍສໍາລັບບາງອົງປະກອບທີ່ຈະເຂົ້າໃຈວ່າເປັນຫຍັງ;

TOTAL: ໂດຍທົ່ວໄປ, ຄວາມປະທັບໃຈຂອງຜະລິດຕະພັນແມ່ນດີ. ພວກເຮົາຕິດຕໍ່ກັນຢ່າງຕໍ່ເນື່ອງກັບນັກພັດທະນາວົງດົນຕີ. guys ແມ່ນ disposed ກັບ ການ ຮ່ວມ ມື ໃນ ການ ກໍ່ ສ້າງ.

ເຖິງວ່າຈະມີຄວາມງ່າຍດາຍຂອງມັນ, FCO ມີຫນ້າທີ່ກວ້າງຂວາງ. ໃນບົດຄວາມໃນອະນາຄົດພວກເຮົາວາງແຜນທີ່ຈະເຈາະເລິກເຂົ້າໄປໃນຫົວຂໍ້ຕໍ່ໄປນີ້:

• ເຄືອຂ່າຍຢູ່ FCO
• ສະຫນອງການຟື້ນຕົວສົດແລະອະນຸສັນຍາ FQP
• ຂຽນ plugins ແລະ widget ຂອງທ່ານເອງ
• ເຊື່ອມຕໍ່ການບໍລິການເພີ່ມເຕີມເຊັ່ນ: Load Balancer ແລະ Acronis
• ສຳຮອງ
• ກົນໄກການລວມສໍາລັບການຕັ້ງຄ່າແລະການຕັ້ງຄ່າ nodes
• ປະມວນຜົນ metadata ຂອງເຄື່ອງ virtual

ZY ຂຽນໃນຄໍາເຫັນຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈໃນລັກສະນະອື່ນໆ. ຕິດຕາມຢູ່!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com