В ni parolis pri niaj provoj uzi Watcher kaj provizis testan raporton. Ni periode faras tiajn testojn por ekvilibro kaj aliaj kritikaj funkcioj de granda entrepreno aŭ operaciista nubo.
La alta komplekseco de la problemo solvita povas postuli plurajn artikolojn por priskribi nian projekton. Hodiaŭ ni publikigas la duan artikolon de la serio, dediĉita al ekvilibro de virtualaj maŝinoj en la nubo.
Iom da terminologio
La firmao VmWare lanĉis la DRS (Distributed Resource Scheduler) servaĵon por ekvilibrigi la ŝarĝon de la virtualiga medio, kiun ili evoluigis kaj ofertis.
Kiel li skribas
"VMware DRS (Distribuita Rimeda Planilo) estas ilo kiu ekvilibrigas komputikajn ŝarĝojn kun disponeblaj rimedoj en virtuala medio. La utileco estas parto de virtualiga serio nomita VMware Infrastructure.
Kun VMware DRS, uzantoj difinas regulojn por distribuado de fizikaj rimedoj inter virtualaj maŝinoj (VM). La ilo povas esti agordita por mana aŭ aŭtomata kontrolo. VMware-rimedoj povas esti facile aldonitaj, forigitaj aŭ reorganizitaj. Se dezirite, rimedoj povas esti izolitaj inter malsamaj komercsekcioj. Se la laborkvanto sur unu aŭ pluraj virtualaj maŝinoj ŝanĝiĝas draste, VMware DRS redistribuas la virtualajn maŝinojn tra fizikaj serviloj. Se la totala laborkvanto malpliiĝas, iuj fizikaj serviloj povas esti provizore senretaj kaj la laborkvanto firmiĝos."
Kial necesas ekvilibro?
Laŭ nia opinio, DRS estas nepra nuba funkcio, kvankam ĉi tio ne signifas, ke DRS devas esti uzata ĉiam kaj ĉie. Depende de la celo kaj bezonoj de la nubo, povas ekzisti malsamaj postuloj por DRS kaj ekvilibraj metodoj. Povas ekzisti situacioj, kie ekvilibro tute ne bezonas. Aŭ eĉ malutila.
Por pli bone kompreni kie kaj por kiuj klientoj DRS estas bezonata, ni konsideru iliajn celojn kaj celojn. Nuboj povas esti dividitaj en publikajn kaj privatajn. Jen la ĉefaj diferencoj inter ĉi tiuj nuboj kaj klientceloj.
Privataj nuboj / Grandaj entreprenaj klientoj
Publikaj nuboj / Mezaj kaj malgrandaj entreprenoj, homoj
La ĉefa kriterio kaj celoj de la funkciigisto
Provizante fidindan servon aŭ produkton
Reduktante la koston de servoj en la batalo en konkurenciva merkato
Servaj postuloj
Fidindeco je ĉiuj niveloj kaj en ĉiuj sistemaj elementoj
Garantia agado
Priorigu virtualajn maŝinojn en plurajn kategoriojn
Sekureco de informoj kaj fizikaj datumoj
SLA kaj subteno XNUMX/XNUMX
Maksimuma facileco ricevi la servon
Relative simplaj servoj
Respondeco por la datumoj kuŝas kun la kliento
Neniu VM-prioritigo necesa
Informa sekureco je la nivelo de normaj servoj, respondeco sur la kliento
Povas esti misfunkciadoj
Neniu SLA, kvalito ne garantiita
Retpoŝta subteno
Rezervo ne estas necesa
Kliento Trajtoj
Tre larĝa gamo de aplikoj.
Heredaĵaj aplikoj hereditaj en la kompanio.
Kompleksaj kutimaj arkitekturoj por ĉiu kliento.
Reguloj de afineco.
La programaro funkcias sen halto en 7x24 reĝimo.
Sur-la-muŝe rezerva iloj.
Antaŭvidebla cikla kliento-ŝarĝo.
Tipaj aplikoj - retbalancado, Apache, WEB, VPN, SQL
La aplikaĵo povas ĉesi por iom da tempo
Permesas arbitran distribuadon de VM-oj en la nubo
Kliento sekurkopio
Antaŭvidebla statistike averaĝa ŝarĝo kun granda nombro da klientoj.
Implicoj por arkitekturo
Geoclustering
Centrigita aŭ distribuita stokado
Rezervita IBS
Loka datumstokado sur komputaj nodoj
Ekvilibrado de Celoj
Eĉ ŝarĝa distribuo
Maksimuma aplika respondeco
Minimuma prokrastotempo por ekvilibro
Ekvilibro nur kiam klare necesas
Elportante iun ekipaĵon por preventa prizorgado
Reduktante servokostojn kaj funkciigistkostojn
Malebligante iujn rimedojn en kazo de malalta ŝarĝo
Ŝparante energion
Reduktante personajn kostojn
Ni mem tiras la jenajn konkludojn:
Por privataj nubojprovizita al grandaj kompaniaj klientoj, DRS povas esti uzata sub la sekvaj limigoj:
- informa sekureco kaj konsiderante afinecajn regulojn dum ekvilibro;
- havebleco de sufiĉaj rimedoj en rezervo en kazo de akcidento;
- virtualaj maŝinaj datumoj situas sur centralizita aŭ distribuita stokadsistemo;
- ŝanceliĝanta administrado, sekurkopio kaj ekvilibraj proceduroj laŭlonge de la tempo;
- ekvilibrigi nur ene de aro de klientgastigantoj;
- ekvilibrigi nur kiam estas forta malekvilibro, la plej efikaj kaj sekuraj VM-migradoj (post ĉio, migrado povas malsukcesi);
- ekvilibrigi relative "trankvilajn" virtualajn maŝinojn (migrado de "bruaj" virtualaj maŝinoj povas preni tre longan tempon);
- ekvilibro konsiderante "koston" - la ŝarĝon sur la stokado kaj reto (kun personigitaj arkitekturoj por grandaj klientoj);
- balancado konsiderante la individuajn kondutkarakterizaĵojn de ĉiu VM;
- Ekvilibro estas prefere farita dum nelaboraj horoj (noktoj, semajnfinoj, ferioj).
Por publikaj nubojprovizante servojn al malgrandaj klientoj, DRS povas esti uzata multe pli ofte, kun altnivelaj kapabloj:
- foresto de informasekurecaj limigoj kaj afinecreguloj;
- ekvilibro ene de la nubo;
- ekvilibro en ajna racia tempo;
- ekvilibrigi ajnan VM;
- ekvilibrigi "bruajn" virtualajn maŝinojn (por ne ĝeni aliajn);
- virtualaj maŝinaj datumoj ofte troviĝas sur lokaj diskoj;
- konsiderante la averaĝan rendimenton de stokaj sistemoj kaj retoj (la nuba arkitekturo estas unuigita);
- ekvilibro laŭ ĝeneralaj reguloj kaj disponeblaj datumcentraj kondutstatistikoj.
Komplekseco de la problemo
La malfacileco de ekvilibro estas, ke DRS devas funkcii kun granda nombro da necertaj faktoroj:
- konduto de uzantoj de ĉiu el la informsistemoj de la klientoj;
- algoritmoj por funkciado de informsistemoj serviloj;
- konduto de DBMS-serviloj;
- ŝarĝo sur komputikaj rimedoj, stokaj sistemoj, reto;
- interago de serviloj unu kun la alia en la lukto por nubaj rimedoj.
La ŝarĝo de granda nombro da virtualaj aplikaĵserviloj kaj datumbazoj sur nubaj rimedoj okazas kun la tempo, la konsekvencoj povas manifestiĝi kaj interkovri unu la alian kun neantaŭvidebla efiko dum neantaŭvidebla tempo. Eĉ por kontroli relative simplajn procezojn (ekzemple por kontroli motoron, akvohejtigan sistemon hejme), aŭtomataj kontrolsistemoj bezonas uzi kompleksajn. algoritmoj kun retrosciigo.
Nia tasko estas multaj ordoj pli kompleksa, kaj estas risko, ke la sistemo ne povos ekvilibrigi la ŝarĝon al establitaj valoroj en racia tempo, eĉ se ne ekzistas eksteraj influoj de uzantoj.
Historio de niaj evoluoj
Por solvi ĉi tiun problemon, ni decidis ne komenci de nulo, sed konstrui sur ekzistanta sperto, kaj komencis interagi kun specialistoj kun sperto en ĉi tiu kampo. Feliĉe, nia kompreno de la problemo tute koincidis.
Etapo 1
Ni uzis sistemon bazitan sur neŭrala reto teknologio kaj provis optimumigi niajn rimedojn surbaze de ĝi.
La intereso de ĉi tiu etapo estis en testado de nova teknologio, kaj ĝia graveco estis en aplikado de ne-norma aliro al solvado de problemo kie, aliaj aferoj estante egalaj, normaj aliroj preskaŭ elĉerpis sin.
Ni lanĉis la sistemon, kaj ni vere komencis ekvilibrigi. La skalo de nia nubo ne permesis al ni akiri la optimismajn rezultojn deklaritajn de la programistoj, sed estis klare, ke la ekvilibro funkcias.
Samtempe, ni havis sufiĉe gravajn limigojn:
- Por trejni neŭralan reton, virtualaj maŝinoj devas funkcii sen signifaj ŝanĝoj dum semajnoj aŭ monatoj.
- La algoritmo estas dizajnita por optimumigo bazita sur la analizo de pli fruaj "historiaj" datumoj.
- Trejni neŭralan reton postulas sufiĉe grandan kvanton da datumoj kaj komputikaj rimedoj.
- Optimumigo kaj ekvilibro povas esti faritaj relative malofte - unufoje ĉiujn kelkajn horojn, kio klare ne sufiĉas.
Etapo 2
Ĉar ni ne kontentiĝis pri la stato de la aferoj, ni decidis modifi la sistemon, kaj por fari tion, respondi ĉefa demando – por kiu ni faras ĝin?
Unue - por kompaniaj klientoj. Ĉi tio signifas, ke ni bezonas sistemon, kiu funkcias rapide, kun tiuj kompaniaj limigoj, kiuj nur simpligas efektivigon.
Dua demando – kion vi volas diri per la vorto “prompte”? Sekve de mallonga debato, ni decidis, ke ni povus komenci per responda tempo de 5–10 minutoj, por ke mallongdaŭraj ekflugoj ne enkonduku la sistemon en resonon.
Tria demando – kian grandecon de la ekvilibra nombro da serviloj elekti?
Ĉi tiu problemo solvis sin. Tipe, klientoj ne faras servilajn agregadojn tre grandaj, kaj tio kongruas kun la rekomendoj de la artikolo por limigi agregadojn al 30-40 serviloj.
Krome, segmentante la servilon, ni simpligas la taskon de la ekvilibra algoritmo.
Kvara demando – kiom taŭgas por ni neŭrala reto kun sia longa lernado kaj malofta ekvilibro? Ni decidis forlasi ĝin favore al pli simplaj funkciaj algoritmoj por akiri rezultojn en sekundoj.
Priskribo de sistemo kiu uzas tiajn algoritmojn kaj ĝiajn malavantaĝojn troveblas
Ni efektivigis kaj lanĉis ĉi tiun sistemon kaj ricevis kuraĝigajn rezultojn - nun ĝi regule analizas la nuban ŝarĝon kaj faras rekomendojn por movi virtualajn maŝinojn, kiuj estas plejparte ĝustaj. Eĉ nun estas klare, ke ni povas atingi 10-15% liberigon de rimedoj por novaj virtualaj maŝinoj plibonigante la kvaliton de laboro de ekzistantaj.
Kiam malekvilibro en RAM aŭ CPU estas detektita, la sistemo eldonas komandojn al la horaro Tionix por plenumi vivan migradon de la bezonataj virtualaj maŝinoj. Kiel videblas el la monitora sistemo, la virtuala maŝino moviĝis de unu (supra) al alia (malsupera) gastiganto kaj liberigis memoron sur la supra gastiganto (elstarigita en flavaj rondoj), respektive okupante ĝin sur la malsupra (markita en blanka). rondoj).
Nun ni provas pli precize taksi la efikecon de la nuna algoritmo kaj provas trovi eblajn erarojn en ĝi.
Etapo 3
Ŝajnus, ke oni povas trankviliĝi pri tio, atendi pruvitan efikecon kaj fermi la temon.
Sed ni estas puŝitaj por efektivigi novan etapon per la sekvaj evidentaj optimumigo-ŝancoj
- Statistikoj, ekzemple, и montras ke du- kaj kvar-procesoraj sistemoj estas signife pli malaltaj en efikeco ol unu-procesoraj sistemoj. Ĉi tio signifas, ke ĉiuj uzantoj ricevas signife malpli da eligo de CPU, RAM, SSD, LAN, FC aĉetita en multprocesoraj sistemoj kompare kun unu-procesoraj.
- La rimedoj-planistoj mem povas havi gravajn erarojn, pri ĉi tiu temo.
- Teknologioj ofertitaj de Intel kaj AMD por monitorado de RAM kaj kaŝmemoro ebligas studi la konduton de virtualaj maŝinoj kaj meti ilin tiel, ke "bruaj" najbaroj ne malhelpas "trankvilajn" virtualajn maŝinojn.
- Vastiĝo de la aro de parametroj (reto, stokadosistemo, prioritato de la virtuala maŝino, kosto de migrado, ĝia preteco por migrado).
Tuta
La rezulto de nia laboro por plibonigi ekvilibrajn algoritmojn estis la klara konkludo, ke uzante modernajn algoritmojn eblas atingi signifan optimumigo de datumcentraj rimedoj (25-30%) kaj samtempe plibonigi la kvaliton de klienta servo.
Algoritmo bazita sur neŭralaj retoj estas certe interesa solvo, sed unu kiu bezonas plian disvolviĝon, kaj pro ekzistantaj limigoj, ĝi ne taŭgas por solvi ĉi tiun specon de problemo sur la volumoj tipaj por privataj nuboj. Samtempe, la algoritmo montris bonajn rezultojn en publikaj nuboj de signifa grandeco.
Ni rakontos al vi pli pri la kapabloj de procesoroj, planiloj kaj altnivela ekvilibro en la sekvaj artikoloj.
fonto: www.habr.com