Π napag-usapan namin ang tungkol sa aming mga pagtatangka na gamitin ang Watcher at nagbigay ng isang pagsubok na ulat. Pana-panahon kaming nagsasagawa ng mga naturang pagsubok para sa pagbabalanse at iba pang kritikal na function ng isang malaking enterprise o operator cloud.
Ang mataas na pagiging kumplikado ng problemang nireresolba ay maaaring mangailangan ng ilang artikulo upang ilarawan ang aming proyekto. Ngayon ay ini-publish namin ang pangalawang artikulo sa serye, na nakatuon sa pagbabalanse ng mga virtual machine sa cloud.
Ang ilang mga terminolohiya
Ipinakilala ng kumpanya ng VmWare ang DRS (Distributed Resource Scheduler) na utility upang balansehin ang load ng virtualization environment na kanilang binuo at inaalok.
Habang nagsusulat siya
βAng VMware DRS (Distributed Resource Scheduler) ay isang utility na nagbabalanse sa pag-compute ng mga load sa mga available na mapagkukunan sa isang virtual na kapaligiran. Ang utility ay bahagi ng isang virtualization suite na tinatawag na VMware Infrastructure.
Sa VMware DRS, tinutukoy ng mga user ang mga panuntunan para sa pamamahagi ng mga pisikal na mapagkukunan sa mga virtual machine (mga VM). Maaaring i-configure ang utility para sa manu-mano o awtomatikong kontrol. Ang mga VMware resource pool ay madaling maidagdag, maalis, o muling ayusin. Kung ninanais, ang mga mapagkukunang pool ay maaaring ihiwalay sa pagitan ng iba't ibang mga yunit ng negosyo. Kung ang workload sa isa o higit pang mga virtual machine ay kapansin-pansing nagbabago, muling ibinabahagi ng VMware DRS ang mga virtual machine sa mga pisikal na server. Kung bumababa ang kabuuang workload, maaaring pansamantalang i-offline ang ilang pisikal na server at pagsama-samahin ang workload."
Bakit kailangan ang pagbabalanse?
Sa aming opinyon, ang DRS ay isang kailangang-kailangan na tampok na ulap, bagama't hindi ito nangangahulugan na ang DRS ay dapat gamitin palagi at saanman. Depende sa layunin at pangangailangan ng cloud, maaaring may iba't ibang mga kinakailangan para sa DRS at mga paraan ng pagbabalanse. Maaaring may mga sitwasyon kung saan hindi kailangan ang pagbabalanse. O kahit nakakapinsala.
Upang mas maunawaan kung saan at para sa kung aling mga kliyente ang DRS ay kailangan, isaalang-alang natin ang kanilang mga layunin at layunin. Maaaring hatiin ang mga ulap sa pampubliko at pribado. Narito ang mga pangunahing pagkakaiba sa pagitan ng mga ulap na ito at mga layunin ng customer.
Mga pribadong ulap / Mga kliyente ng malalaking negosyo
Mga pampublikong ulap / Katamtaman at maliliit na negosyo, mga tao
Ang pangunahing criterion at layunin ng operator
Nagbibigay ng maaasahang serbisyo o produkto
Pagbabawas ng halaga ng mga serbisyo sa pakikipaglaban sa isang mapagkumpitensyang merkado
Mga kinakailangan sa serbisyo
Pagiging maaasahan sa lahat ng antas at sa lahat ng elemento ng system
Garantisadong pagganap
Unahin ang mga virtual machine sa ilang mga kategorya
Seguridad ng impormasyon at pisikal na data
SLA at XNUMX/XNUMX na suporta
Pinakamataas na kadalian ng pagtanggap ng serbisyo
Mga simpleng serbisyo
Ang responsibilidad para sa data ay nasa kliyente
Walang kinakailangang VM prioritization
Seguridad ng impormasyon sa antas ng mga karaniwang serbisyo, responsibilidad sa kliyente
Maaaring may mga glitches
Walang SLA, hindi garantisado ang kalidad
Suporta sa email
Hindi kailangan ang backup
Mga Tampok ng Kliyente
Napakalawak na hanay ng mga aplikasyon.
Mga legacy application na minana sa kumpanya.
Mga kumplikadong custom na arkitektura para sa bawat kliyente.
Mga panuntunan sa pagkakaugnay.
Gumagana ang software nang walang tigil sa 7x24 mode.
On-the-fly backup na mga tool.
Nahuhulaang paikot na pag-load ng customer.
Mga karaniwang application β pagbabalanse ng network, Apache, WEB, VPN, SQL
Maaaring huminto ang application nang ilang sandali
Nagbibigay-daan sa arbitrary na pamamahagi ng mga VM sa cloud
Backup ng kliyente
Nahuhulaang na-average na pag-load sa istatistika na may malaking bilang ng mga kliyente.
Mga implikasyon para sa arkitektura
Geoclustering
Sentralisado o distributed na imbakan
Nakareserbang IBS
Lokal na imbakan ng data sa mga compute node
Pagbalanse ng mga Layunin
Kahit na pamamahagi ng load
Pinakamataas na pagtugon sa application
Minimum na oras ng pagkaantala para sa pagbabalanse
Pagbabalanse lamang kapag malinaw na kinakailangan
Paglabas ng ilang kagamitan para sa preventative maintenance
Pagbabawas ng mga gastos sa serbisyo at mga gastos ng operator
Hindi pagpapagana ng ilang mapagkukunan kung sakaling mahina ang pagkarga
Pag-save ng enerhiya
Pagbawas ng mga gastos sa tauhan
Ginagawa namin ang mga sumusunod na konklusyon para sa ating sarili:
Para sa mga pribadong ulapna ibinigay sa malalaking corporate na customer, maaaring gamitin ang DRS sa ilalim ng mga sumusunod na paghihigpit:
- seguridad ng impormasyon at isinasaalang-alang ang mga patakaran ng affinity kapag nagbabalanse;
- pagkakaroon ng sapat na mga mapagkukunan sa reserba sa kaganapan ng isang aksidente;
- ang data ng virtual machine ay matatagpuan sa isang sentralisadong o distributed storage system;
- nakakagulat na pangangasiwa, backup at pagbabalanse na mga pamamaraan sa paglipas ng panahon;
- pagbabalanse lamang sa loob ng isang pinagsama-samang mga host ng kliyente;
- pagbabalanse lamang kapag may malakas na kawalan ng timbang, ang pinakamabisa at ligtas na paglilipat ng VM (pagkatapos ng lahat, maaaring mabigo ang paglipat);
- pagbabalanse ng medyo "tahimik" na mga virtual machine (ang paglipat ng "maingay" na mga virtual machine ay maaaring tumagal ng napakatagal na oras);
- pagbabalanse na isinasaalang-alang ang "gastos" - ang pagkarga sa sistema ng imbakan at network (na may mga pasadyang arkitektura para sa malalaking kliyente);
- pagbabalanse na isinasaalang-alang ang mga indibidwal na katangian ng pag-uugali ng bawat VM;
- Ang pagbabalanse ay mas mainam na gawin sa mga oras na walang pasok (gabi, katapusan ng linggo, pista opisyal).
Para sa mga pampublikong ulappagbibigay ng mga serbisyo sa maliliit na customer, mas madalas na magagamit ang DRS, na may mga advanced na kakayahan:
- kawalan ng mga paghihigpit sa seguridad ng impormasyon at mga panuntunan sa pagkakaugnay;
- pagbabalanse sa loob ng ulap;
- pagbabalanse sa anumang makatwirang oras;
- pagbabalanse ng anumang VM;
- pagbabalanse ng "maingay" na virtual machine (upang hindi makaistorbo sa iba);
- Ang data ng virtual machine ay madalas na matatagpuan sa mga lokal na disk;
- isinasaalang-alang ang average na pagganap ng mga sistema ng imbakan at mga network (ang arkitektura ng ulap ay pinag-isa);
- pagbabalanse ayon sa mga pangkalahatang tuntunin at magagamit na istatistika ng pag-uugali ng data center.
Ang pagiging kumplikado ng problema
Ang kahirapan ng pagbabalanse ay ang DRS ay dapat gumana sa isang malaking bilang ng mga hindi tiyak na mga kadahilanan:
- pag-uugali ng mga gumagamit ng bawat isa sa mga sistema ng impormasyon ng mga kliyente;
- mga algorithm para sa pagpapatakbo ng mga server ng sistema ng impormasyon;
- pag-uugali ng mga server ng DBMS;
- load sa computing resources, storage system, network;
- pakikipag-ugnayan ng mga server sa isa't isa sa pakikibaka para sa mga mapagkukunan ng ulap.
Ang pag-load ng isang malaking bilang ng mga virtual na server ng aplikasyon at mga database sa mga mapagkukunan ng ulap ay nangyayari sa paglipas ng panahon, ang mga kahihinatnan ay maaaring magpakita ng kanilang mga sarili at magkakapatong sa isa't isa na may hindi inaasahang epekto sa isang hindi inaasahang oras. Kahit na upang makontrol ang medyo simpleng mga proseso (halimbawa, upang makontrol ang isang makina, isang sistema ng pagpainit ng tubig sa bahay), ang mga awtomatikong control system ay kailangang gumamit ng kumplikado mga algorithm na may feedback.
Ang aming gawain ay maraming mga order ng magnitude na mas kumplikado, at may panganib na ang system ay hindi magagawang balansehin ang pag-load sa mga itinatag na halaga sa isang makatwirang oras, kahit na walang mga panlabas na impluwensya mula sa mga gumagamit.
Kasaysayan ng ating mga pag-unlad
Upang malutas ang problemang ito, nagpasya kaming hindi magsimula mula sa simula, ngunit upang bumuo sa umiiral na karanasan, at nagsimulang makipag-ugnayan sa mga espesyalista na may karanasan sa larangang ito. Sa kabutihang palad, ang aming pag-unawa sa problema ay ganap na nag-tutugma.
1 Stage
Gumamit kami ng system batay sa teknolohiya ng neural network at sinubukan naming i-optimize ang aming mga mapagkukunan batay dito.
Ang interes ng yugtong ito ay sa pagsubok ng isang bagong teknolohiya, at ang kahalagahan nito ay sa paglalapat ng isang hindi pamantayang diskarte sa paglutas ng isang problema kung saan, ang iba pang mga bagay ay pantay, ang mga karaniwang diskarte ay halos naubos ang kanilang mga sarili.
Inilunsad namin ang sistema, at talagang nagsimula kaming magbalanse. Ang sukat ng aming cloud ay hindi nagbigay-daan sa amin upang makuha ang mga positibong resulta na sinabi ng mga developer, ngunit ito ay malinaw na ang pagbabalanse ay gumagana.
Kasabay nito, mayroon kaming mga malubhang limitasyon:
- Upang sanayin ang isang neural network, ang mga virtual machine ay kailangang tumakbo nang walang makabuluhang pagbabago sa loob ng ilang linggo o buwan.
- Ang algorithm ay idinisenyo para sa pag-optimize batay sa pagsusuri ng mas naunang "makasaysayang" data.
- Ang pagsasanay sa isang neural network ay nangangailangan ng medyo malaking halaga ng data at computing resources.
- Ang pag-optimize at pagbabalanse ay maaaring gawin nang medyo bihira - isang beses bawat ilang oras, na malinaw na hindi sapat.
2 Stage
Dahil hindi kami nasiyahan sa estado ng mga gawain, nagpasya kaming baguhin ang sistema, at upang gawin ito, sagutin pangunahing tanong β para kanino natin ito ginagawa?
Una - para sa mga kliyente ng korporasyon. Nangangahulugan ito na kailangan namin ng isang sistema na mabilis na gumagana, kasama ang mga paghihigpit ng kumpanya na nagpapasimple lamang sa pagpapatupad.
Pangalawang tanong β ano ang ibig mong sabihin sa salitang βmaagapβ? Bilang resulta ng maikling debate, napagpasyahan namin na maaari kaming magsimula sa isang oras ng pagtugon na 5β10 minuto, upang hindi maipasok ng mga panandaliang surge ang system sa resonance.
Pangatlong tanong β anong sukat ng balanseng bilang ng mga server ang pipiliin?
Nalutas mismo ang isyung ito. Karaniwan, hindi ginagawa ng mga kliyente ang mga pagsasama-sama ng server na napakalaki, at ito ay naaayon sa mga rekomendasyon ng artikulo na limitahan ang mga pagsasama-sama sa 30-40 na mga server.
Bilang karagdagan, sa pamamagitan ng pagse-segment ng server pool, pinapasimple namin ang gawain ng algorithm ng pagbabalanse.
Pang-apat na tanong β gaano kaangkop ang isang neural network para sa atin sa mahabang proseso ng pagkatuto nito at pambihirang pagbabalanse? Napagpasyahan naming iwanan ito pabor sa mas simpleng mga algorithm sa pagpapatakbo upang makakuha ng mga resulta sa ilang segundo.
Ang isang paglalarawan ng isang system na gumagamit ng mga naturang algorithm at ang mga disadvantage nito ay matatagpuan
Ipinatupad at inilunsad namin ang system na ito at nakatanggap ng mga nakapagpapatibay na resulta - ngayon ay regular nitong sinusuri ang cloud load at gumagawa ng mga rekomendasyon para sa paglipat ng mga virtual machine, na higit sa lahat ay tama. Kahit ngayon ay malinaw na makakamit natin ang 10-15% na paglabas ng mga mapagkukunan para sa mga bagong virtual machine habang pinapabuti ang kalidad ng trabaho ng mga umiiral na.
Kapag may nakitang imbalance sa RAM o CPU, nag-iisyu ang system ng mga utos sa Tionix scheduler para magsagawa ng live na paglipat ng mga kinakailangang virtual machine. Tulad ng makikita mula sa sistema ng pagsubaybay, ang virtual machine ay lumipat mula sa isa (itaas) patungo sa isa pa (mas mababang) host at pinalaya ang memorya sa itaas na host (naka-highlight sa mga dilaw na bilog), ayon sa pagkakabanggit ay sumasakop dito sa mas mababang isa (naka-highlight sa puti. mga bilog).
Ngayon ay sinusubukan naming mas tumpak na masuri ang pagiging epektibo ng kasalukuyang algorithm at sinusubukan na makahanap ng mga posibleng error dito.
3 Stage
Tila na ang isang tao ay maaaring huminahon tungkol dito, maghintay para sa napatunayan na pagiging epektibo at isara ang paksa.
Ngunit kami ay itinulak na magsagawa ng isang bagong yugto sa pamamagitan ng mga sumusunod na malinaw na pagkakataon sa pag-optimize
- Mga istatistika, halimbawa, ΠΈ ay nagpapakita na ang dalawang- at apat na-processor system ay makabuluhang mas mababa sa pagganap kaysa sa single-processor system. Nangangahulugan ito na ang lahat ng mga gumagamit ay tumatanggap ng makabuluhang mas kaunting output mula sa CPU, RAM, SSD, LAN, FC na binili sa mga multiprocessor system kumpara sa mga single-processor.
- Ang mga tagapag-iskedyul ng mapagkukunan mismo ay maaaring magkaroon ng malubhang pagkakamali, sa paksang ito.
- Ang mga teknolohiyang inaalok ng Intel at AMD para sa pagsubaybay sa RAM at cache ay ginagawang posible na pag-aralan ang pag-uugali ng mga virtual machine at ilagay ang mga ito sa paraang ang "maingay" na mga kapitbahay ay hindi makagambala sa "tahimik" na mga virtual machine.
- Pagpapalawak ng hanay ng mga parameter (network, storage system, priyoridad ng virtual machine, gastos ng paglipat, kahandaan nito para sa paglipat).
Sa kabuuan
Ang resulta ng aming trabaho upang pahusayin ang mga algorithm ng pagbabalanse ay ang malinaw na konklusyon na ang paggamit ng mga modernong algorithm ay posible na makamit ang makabuluhang pag-optimize ng mga mapagkukunan ng data center (25-30%) at kasabay nito ay mapabuti ang kalidad ng serbisyo sa customer.
Ang isang algorithm na batay sa mga neural network ay tiyak na isang kawili-wiling solusyon, ngunit isa na nangangailangan ng karagdagang pag-unlad, at dahil sa mga umiiral na limitasyon, hindi ito angkop para sa paglutas ng ganitong uri ng problema sa mga volume na tipikal para sa mga pribadong ulap. Kasabay nito, ang algorithm ay nagpakita ng magagandang resulta sa mga pampublikong ulap na may malaking sukat.
Sasabihin namin sa iyo ang higit pa tungkol sa mga kakayahan ng mga processor, scheduler, at high-level na pagbabalanse sa mga sumusunod na artikulo.
Pinagmulan: www.habr.com