În Am discutat despre încercările de a utiliza Watcher și am prezentat un raport al testelor. Astfel de teste le efectuăm periodic pentru echilibrare și alte funcții critice ale unui cloud corporativ sau de operator de mari dimensiuni.
Gradul ridicat de complexitate al problemei poate necesita mai multe articole pentru a descrie proiectul nostru. Astăzi publicăm al doilea articol din ciclu, dedicat echilibrării mașinilor virtuale în cloud.
Puțină terminologie
Compania VmWare a introdus utilitarul DRS (Distributed Resource Scheduler) pentru a echilibra sarcinile de lucru în mediul de virtualizare dezvoltat și oferit de aceasta.
Așa cum scrie
«VMware DRS (Planificatorul de resurse distribuite) este un utilitar care echilibrează sarcinile de calcul cu resursele disponibile în mediul virtual. Utilitarul face parte din pachetul de virtualizare numit VMware Infrastructure.
Cu ajutorul VMware DRS, utilizatorii definesc reguli pentru distribuirea resurselor fizice între mașinile virtuale (MV). Utilitarul poate fi configurat pentru gestionarea manuală sau automată. Puzzile de resurse VMware pot fi ușor adăugate, eliminate sau reorganizate. La cerere, puzzile de resurse pot fi izolate între diferitele unități de afaceri. Dacă sarcina de lucru pe una sau mai multe mașini virtuale se schimbă brusc, VMware DRS redistribuie mașinile virtuale între serverele fizice. Dacă sarcina de lucru totală scade, unele servere fizice pot fi temporar oprite, iar sarcina de lucru consolidată.»
De ce este necesară echilibrarea?
În opinia noastră, DRS este o funcție esențială a cloud-ului, deși aceasta nu înseamnă că DRS trebuie utilizat întotdeauna și oriunde. În funcție de scopul și nevoile cloud-ului, pot exista cerințe diferite pentru DRS și metodele de echilibrare. Există probabil situații când echilibrarea nu este deloc necesară. Sau chiar dăunătoare.
Pentru a înțelege mai bine unde și pentru ce clienți este necesar DRS, să luăm în considerare obiectivele și sarcinile lor. Cloud-urile pot fi împărțite în publice și private. Iată principalele diferențe între aceste cloud-uri și obiectivele clienților.
Cloud-uri private / Clienți corporativi mari
Cloud-uri publice / Întreprinderi mici și mijlocii, persoane
Criteriul principal și obiectivele operatorului
Furnizarea unui serviciu sau produs de încredere
Reducerea costurilor serviciilor în lupta pe piața competitivă
Cerințele pentru serviciu
Fiabilitate la toate nivelurile și în toate componentele sistemului
Performanță garantată
Prioritizarea mașinilor virtuale în mai multe categorii
Securitatea informațională și fizică a datelor
SLA și suport 24/7
Maxima simplificare în obținerea serviciului
Servicii relativ simple
Responsabilitatea pentru date revine clientului
Prioritizarea VM nu este necesară
Securitatea informațională la nivelul serviciilor standard, responsabilitatea revine clientului
Pot exista defecțiuni
Fără SLA, calitatea nu este garantată
Suport prin e-mail
Backup-ul nu este obligatoriu
Particularitățile clientului
O gamă foarte largă de aplicații.
Aplicații legate de companie.
Arhitecturi personalizate complexe pentru fiecare client.
Reguli de afinitate.
Funcționarea software-ului fără oprire în modul 7x24.
Instrumente de backup „în timpul funcționării”.
Încărcătură ciclică predictibilă a clientului.
Aplicații standard – echilibrarea rețelei, Apache, WEB, VPN, SQL
Posibilitatea de a opri aplicația pentru o perioadă de timp
Se permite distribuirea aleatorie a VM în cloud
Backup efectuat de client
Încărcătură medie previzibilă statistic pentru un număr mare de clienți.
Consecințe pentru arhitectură
Geoclusterizare
Stocare centralizată sau distribuită S ext{HÎ}
R ext{SRK} rezervabilă
Stocarea locală a datelor pe nodurile de calcul
Obiectivele echilibrării
Distribuția uniformă a sarcinii
Maxima reactivitate a aplicațiilor
Timp minim de întârziere la echilibrare
Echilibrarea doar în caz de necesitate evidentă
Dezvoltarea unei părți a echipamentului pentru întreținere preventivă
Reducerea costului serviciului și a cheltuielilor operatorului
Dezactivarea unor resurse în cazul unei încărcături reduse
Economisirea energiei electrice
Reducerea costurilor pentru personal
Facem următoarele concluzii pentru noi:
Pentru cloud-uri private, ofereți instituțiilor mari, DRS poate fi aplicat ținând cont de restricții:
- securitatea informațională și respectarea regulilor de afinitate la echilibrare;
- disponibilitatea într-un rezervor a unui volum suficient de resurse în caz de accident;
- datele mașinilor virtuale se află pe un S ext{HÎ} centralizat sau distribuit;
- distribuirea în timp a procedurilor de administrare, backup și echilibrare;
- echilibrarea doar în cadrul agregatului de gazde ale clientului;
- echilibrarea doar în caz de un dezechilibru semnificativ, cele mai eficiente și sigure migrații VM (deoarece migrarea poate fi și nereușită);
- echilibrarea în raport cu mașinile virtuale «calme» (migrarea mașinilor virtuale «zgomotoase» poate dura foarte mult);
- echilibrarea având în vedere «costul» — încărcarea pe sistemul de stocare și rețea (în arhitecturi personalizate pentru clienți mari);
- echilibrarea cu considerație pentru particularitățile comportamentului fiecărei VM;
- echilibrarea preferabil în afara orelor de lucru (noaptea, în weekend, sărbători).
Pentru cloud-urile publice, care oferă servicii clienților mici, DRS poate fi aplicat mult mai frecvent, cu funcționalități extinse:
- lipsa restricțiilor de securitate informațională și a regulilor de afinitate;
- echilibrarea în cadrul cloud-ului;
- echilibrarea în orice moment rezonabil;
- echilibrarea oricărei VM;
- echilibrarea mașinilor virtuale «zgomotoase» (pentru a nu deranja restul);
- datele mașinilor virtuale se află adesea pe discuri locale;
- considerarea performanței medii a sistemului de stocare și a rețelei (arhitectura cloud-ului este unitară);
- echilibrarea conform regulilor generalizate și statisticii comportamentului DC.
Complexitatea problemei
Complexitatea echilibrării constă în faptul că DRS trebuie să funcționeze cu un număr mare de factori necunoscuți:
- comportamentul utilizatorilor fiecărui sistem informațional al clienților;
- algoritmii de funcționare ai serverelor sistemelor informaționale;
- comportamentul serverelor DBMS;
- încărcarea pe resursele de calcul, sistemul de stocare, rețea;
- interacțiunea serverelor între ele în competiția pentru resursele cloud-ului.
Încărcarea unui număr mare de servere virtuale pentru aplicații și baze de date pe resursele cloud-ului se desfășoară în timp, consecințele putând apărea și suprapune unele peste altele cu efecte imprevizibile la momente imprevizibile. Chiar și pentru gestionarea proceselor relativ simple (de exemplu, gestionarea motorului, sistemului de încălzire pe bază de apă al casei), sistemele de reglare automată trebuie să folosească algoritmi complicați cu feedback.
Sarcina noastră este mult mai complexă, iar există riscul ca sistemul să nu poată realiza echilibrarea încărcăturii în valori stabilite într-un timp rezonabil, chiar dacă nu apar intervenții externe din partea utilizatorilor.
Istoria dezvoltărilor noastre
Pentru a rezolva această problemă, am decis să nu începem de la zero, ci să ne bazăm pe experiența existentă, colaborând cu specialiști cu experiență în acest domeniu. Din fericire, înțelegerea problemelor noastre a fost complet aliniată.
Etapa 1
Am folosit un sistem bazat pe tehnologia rețelelor neuronale și am încercat să ne optimizăm resursele pe baza acestuia.
Interesul acestei etape a consistat în testarea unei noi tehnologii, iar importanța sa a fost aplicarea unei abordări neobișnuite pentru rezolvarea problemei, unde, în condiții egale, abordările standard s-au epuizat practic.
Am lansat sistemul și, într-adevăr, a început echilibrarea. Scala cloud-ului nostru nu ne-a permis să obținem rezultate optimiste, așa cum au declarat dezvoltatorii, dar a fost clar că echilibrarea funcționează.
În același timp, aveam restricții destul de serioase:
- Pentru a antrena rețeaua neuronală, este necesar ca mașinile virtuale să funcționeze fără modificări semnificative timp de săptămâni sau luni.
- Algoritmul este conceput pentru optimizare pe baza analizei datelor 'istorice' anterioare.
- Pentru a antrena rețeaua neuronală este nevoie de un volum suficient de mare de date și resurse de calcul.
- Optimizarea și echilibrarea pot fi realizate relativ rar – la câteva ore, ceea ce este evident insuficient.
Etapa 2
Dat fiind că situația nu ne mulțumea, am decis să modificăm sistemul și, pentru aceasta, trebuie să răspundem la întrebarea principală – pentru cine o facem?
Mai întâi – pentru clienții corporativi. Înseamnă că avem nevoie de un sistem care să funcționeze rapid, cu acele restricții corporative care simplifică doar implementarea.
A doua întrebare – ce înțelegem prin cuvântul „rapid”? În urma unor dezbateri scurte, am decis că putem să ne referim la un timp de reacție de 5 – 10 minute, astfel încât fluctuațiile pe termen scurt să nu introducă sistemul în rezonanță.
A treia întrebare – ce dimensiune a cantității de servere echilibrate să alegem?
Această problemă s-a rezolvat de la sine. De obicei, clienții nu fac grupuri de servere foarte mari, iar acest lucru este conform recomandărilor din articol de a limita grupurile la 30-40 de servere.
În plus, prin segmentarea grupului de servere, simplificăm sarcina algoritmului de balansare.
Întrebarea patra – cât de mult ne convine rețeaua neuronală cu procesul ei lung de învățare și balansările rare? Am decis să renunțăm la ea în favoarea algoritmilor operaționali mai simpli, pentru a obține rezultate în câteva secunde.
O descriere a sistemului care folosește astfel de algoritmi și dezavantajele acestuia poate fi consultată
Am implementat și lansat acest sistem și am obținut rezultate promițătoare – în prezent, acesta analizează în mod regulat sarcina din cloud și oferă recomandări pentru mutarea mașinilor virtuale, care sunt în mare parte corecte. Chiar și acum este evident că putem obține 10-15% eliberare de resurse pentru noi mașini virtuale, îmbunătățind calitatea funcționării celor existente.
Atunci când se detectează un dezechilibru la nivel de RAM sau CPU, sistemul dă comenzi planificatorului Tionix pentru a efectua migrarea în timpul funcționării a mașinilor virtuale necesare. Așa cum se poate observa din sistemul de monitorizare, mașina virtuală s-a mutat de la un host (superior) la altul (inferior) și a eliberat memorie pe hostul superior (evidentiat cu cercuri galbene), ocupând-o corespunzător pe cel inferior (evidentiat cu cercuri albe).
Acum ne străduim să evaluăm mai exact eficiența algoritmului în funcțiune și încercăm să identificăm eventualele sale erori.
Etapa 3
Ar părea că aici putem să ne liniștim, așteptând eficiența dovedită și să încheiem subiectul.
Dar suntem împinși spre un nou stadiu de următoarele oportunități evidente de optimizare
- Statisticile, de exemplu, și arată că sistemele cu două și patru procesoare sunt semnificativ mai puțin performante decât cele cu un procesor. Asta înseamnă că toți utilizatorii obțin de la sistemele multi-procesoare CPU, RAM, SSD, LAN, FC o randament considerabil mai mic în comparație cu sistemele uniprocesor.
- Însă planificatoarele de resurse pot funcționa cu erori grave, pe această temă.
- Tehnologiile oferite de companiile Intel și AMD pentru monitorizarea RAM-ului și a cache-ului permit studierea comportamentului mașinilor virtuale și plasarea acestora astfel încât vecinii "zgomotoși" să nu interfereze cu funcționarea mașinilor virtuale "liniștite".
- Extinderea setului de parametri (rețea, stocare, prioritatea mașinii virtuale, costul migrației, pregătirea pentru migrare).
În concluzie
Rezultatul muncii noastre în îmbunătățirea algoritmilor de balansare este concluzia clară că, datorită algoritmilor moderni, se poate obține o optimizare semnificativă a resurselor (25-30%) în centrele de date și, în același timp, îmbunătățirea calității serviciilor pentru clienți.
Algoritmul bazat pe rețele neuronale este, fără îndoială, interesant, dar are nevoie de dezvoltări ulterioare și, din cauza constrângerilor existente, nu este potrivit pentru rezolvarea acestui tip de probleme la volumele caracteristice pentru cloud-urile private. În schimb, în cloud-urile publice de dimensiuni considerabile, algoritmul a arătat rezultate bune.
Detalii despre capabilitățile procesoarelor, planificatorilor și balansării la nivel înalt le vom prezenta în articolele următoare.
Sursa: habr.com
