În funcție de cât de puternic este echipamentul pe care îl avem și de resursele necesare pentru sistemele noastre, vom avea un raport mediu de mașini virtuale pe server.
Luați, de exemplu, întreținerea programată a unui server în Computer Center. Cu câțiva ani în urmă, dacă acest lucru nu făcea parte dintr-un cluster, sistemul conținut în echipament ar fi luat offline, prin urmare, utilizatorii ar fi afectați și / sau personalul implicat în întreținere trebuia să lucreze în ferestre de timp reduse (pentru a nu spune incomod).
În cazul unui mediu virtualizat, mașinile virtuale pot fi pur și simplu „mutate sau migrate” către un alt membru al unui cluster și echipamentul poate fi oprit pentru a lucra la acesta. Problema rezolvata.
Să începem să vedem situații în care lipsa serviciului nu este programată.
Monitorizarea mașinilor virtuale și a aplicațiilor
De fiecare dată când creăm o mașină virtuală, se recomandă instalarea unui compendiu de aplicații și drivere care optimizează comportamentul hardware-ului virtual în întregime (disponibil pentru Windows, Mac OS, Linux și alte sisteme de operare). Aceste instrumente, numite VMTools, includ, printre altele, posibilitatea ca gazda să monitorizeze mașina virtuală (prin bătăi de inimă, ca în clustere). Dacă nu răspunde într-o anumită perioadă, repornește sistemul de operare.
Un caz similar se întâmplă cu monitorizarea aplicației, dar mai întâi trebuie să obțineți SDK-ul adecvat (sau să utilizați o aplicație care acceptă monitorizarea aplicațiilor VMware).
Dar … ce se întâmplă dacă vina este hardware?
Clusterul menționat mai sus este primul strat al soluției.
Stocare partajatăUnde toți membrii clusterului au acces la mașini virtuale.
Asocierea în rețeaConfruntați cu eșecul unei plăci, celelalte rămase continuă să gestioneze traficul.
Căi multiple (multipathing)Pentru stocare, acestea nu numai că vor optimiza accesul, dar vor oferi și redundanță.
În linii mari, aceste trei tehnologii reduc timpul în care informațiile noastre sunt inaccesibile. Acum, în funcție de licențierea pe care o avem, putem avea și două caracteristici foarte interesante: Disponibilitate ridicată (HA) și Fault Tolerance (FT).
În ambele cazuri avem nevoie de un cluster cu stocare partajată. Fără a fi nevoie să instalați software suplimentar, HA poate fi activat și configurat în așa fel încât, dacă un server sau o mașină virtuală eșuează în cluster, acesta va porni automat pe un alt membru al clusterului. Merită clarificat faptul că HA nu este destinat VM-urilor (mașini virtuale) critice pentru misiune. Deci timpul estimat fără service va fi: „Pornirea sistemului de operare + Pornirea serviciilor”.
Numărul de eșecuri gazdă acceptate de cluster
Avem X cantitate de mașini virtuale distribuite în servere Y într-un cluster.
Câte gazde pot eșua fără a afecta disponibilitatea și performanța mediului nostru virtual?
HA poate fi configurat pentru a suporta un anumit număr de erori ale serverului, asigurându-se că există resurse suficiente în recuperare.
HA face feluri de resurse disponibile ale unui cluster ținând cont de CPU și RAM configurate și consumate de mașinile noastre virtuale într-un mod foarte conservator. Este nevoie de cea mai mare rezervare CPU configurată din orice VM pe fiecare gazdă din cluster și apoi cea mai mare rezervare de memorie și excesul acesteia. Dacă nu există o rezervare configurată, va dura minimum 32 Mhz per VM pentru CPU și 0 Mb de RAM + excesul său.
Cu aceste numere se presupune că fiecare mașină virtuală utilizează va consuma acel CPU și memorie, apoi va genera o valoare numită dimensiunea slotului. Cu această valoare, se determină câte sloturi sunt disponibile / utilizate de fiecare gazdă.
Problema apare atunci când, de exemplu, avem o singură mașină cu un procesor mare și rezervă de memorie. Luând rezervări configurate, este foarte probabil ca restul mașinilor noastre virtuale să nu aibă nevoie de aceste resurse, ceea ce duce la mai puține sloturi pentru clusterul nostru.
Procentul de resurse cluster ca capacitate pentru eșecuri
Spre deosebire de opțiunea anterioară, aceasta funcționează foarte bine atunci când aveți VM-uri cu configurații de CPU și memorie foarte variabile.
Este posibil să configurați valorile procentuale ale procesorului și ale memoriei separat, fiind astfel mai flexibile și, prin urmare, economisind resurse. Aceasta este, în general, metoda preferată pentru configurarea HA.
Gazde pentru reluare
Aceasta este configurația tipică de cluster de așteptare. Această opțiune este dată în principal, deoarece unele organizații mențin politici care indică faptul că trebuie să existe servere în așteptare în caz de dezastru. Deoarece VMware gestionează bine toleranța la erori, poate că aceasta ar fi opțiunea atunci când resursele sunt abundente … dar cu siguranță nu sunt cele mai bune.
vMotion: Migrații în direct
Migrarea live vă permite să mutați mașinile virtuale de lucru de la un server fizic la altul, păstrând în același timp conexiunea și identitatea de rețea. Memoria activă (procesele care rulează) este transferată prin rețeaua de mare viteză. Întregul proces durează mai puțin de 5 secunde într-o rețea gigabit.
Este posibil să mutați VM, fișierele pe care le folosește sau ambele, iar procedura se poate face cu mașina pornită sau oprită. În acest din urmă caz, o numim „migrație la rece” și dacă mașina funcționează, o numim vMotion.
Utilizări și beneficii ale vMotion
- Reorganizarea VM, optimizând astfel resursele. Eliminați-le de pe servere care sunt predispuse la eșec sau saturate.
- Optimizarea automată a resurselor disponibile (Lucrez împreună cu Dynamic Resource Scheduler sau DRS).
- Do întreținerea infrastructurii subiacente nu este nevoie de programarea întreținerii sau întreruperea afacerii.
Fiecare componentă a sănătății VM este tratată diferit în timpul migrării. Configurația generală este cea mai simplă, nu se mișcă, dar este recreată pe computerul țintă.
Deoarece discul nu poate fi recreat într-un timp atât de scurt, este necesar să aveți stocare partajată. Starea curentă a memoriei este copiată treptat la gazda de destinație. La sfârșitul copiei, se compară diferențele existente care au apărut în timpul migrării, starea VM sursă este înghețată și sistemul de operare este activat pe VM de destinație. .
Deoarece în unele cazuri opțiunea de a reporni mașina nu este ideală, pentru misiunea critică avem Toleranță la erori. Ceea ce se dorește în aceste cazuri nu încetează să funcționeze în niciun moment, chiar dacă gazda sa eșuează. Singura modalitate prin care acest lucru este posibil este dacă VM rulează în două locuri în același timp. Este configurat la nivel de mașină virtuală și va genera o copie exactă a VM, păstrându-l 100% replicat tot timpul pe un alt server, deci în cazul unei defecțiuni hardware, gemenele sale vor continua să funcționeze fără pierderi de informații. Interesant, nu?
Dacă ar fi vorba doar de resurse, am activa FT în toate mașinile virtuale din centrul nostru de date, dar în versiunile anterioare ale vSphere am întâmpinat câteva limitări, cea mai importantă: Nu a fost posibil să activăm FT în mașinile care foloseau mai mult de un virtual procesor. Din fericire, în cea mai recentă versiune a produsului, acesta acceptă până la 4 procesoare virtuale simultan per mașină protejată, totuși licențierea va trebui luată în considerare:
Numărul de vCPU-uri acceptate de o VM activată FT este limitat de nivelul de licențiere achiziționat pentru vSphere.
Toleranța la erori este acceptată după cum urmează:
- vSphere Standard și Enterprise. Permite până la 2 vCPU-uri.
- vSphere Enterprise Plus. Permite până la 4 vCPU-uri.
Aceasta nu este singura cerință a sistemului.
DepozitareVM-urile trebuie să aibă stocare partajată. Nu este posibil să utilizați RDM fizic (Raw Devide Mapping).
NetEste necesar să aveți cel puțin două carduri virtuale (vmnics), una pentru vMotion și cealaltă (10 gbps) pentru FT Logging. Este o nouă cerință a versiunii 6 (anterior, erau necesare plăci de 1 gbps)
ProcesorProcesoarele și sistemele de operare trebuie să fie compatibile cu FT (și între ele).
Limitări
- Nu este posibil să faceți instantanee ale VM-urilor care sunt protejate cu FT și trebuie șterse înainte de a activa această funcție.
- Discuri virtuale (VMDK) mai mari de 2 Tb.
- Există o listă de dispozitive și caracteristici specifice în documentația VMware.
Și există, de asemenea, o limitare a numărului de VM-uri pe server: maximum 4 mașini protejate pe gazdă sau 8 vCPU-uri protejate (oricare dintre limită vine prima). Aceste valori maxime includ mașina primară și secundară (și vCPU-urile)
Diferențe între moștenirea FT (anterioară) și cea actuală
IPv6
FT vechi = Nu este acceptat de plăcile de rețea configurate pentru înregistrarea FT FT = Suportat
API-uri VStorage - Backup cu protecție a datelor
Vechi FT = Neacceptat FT = Acceptat
Discul virtual
Legacy FT = EZT (Eager Zeroed Thick) FT = Toate tipurile, inclusiv gros și subțire
Redundanță Vmdk (disc virtual)
Legacy FT = Copie unică FT = Mașinile primare și secundare mențin copii independente, acest lucru le permite să fie stocate în diferite magazii de date și să crească redundanța
Lățimea de bandă a plăcii de rețea
FT vechi = NIC dedicat de 1 Gb recomandat FT = NIC dedicat de 10 Gb recomandat
Compatibilitate CPU și gazdă
Legacy FT = Necesită același model de CPU și familie. Versiunile vSphere aproape identice FT = CPU-urile trebuie să fie compatibile cu vSphere vMotion sau EVC. Versiunea VSphere trebuie să fie compatibilă cu vSphere vMotion
Activați / dezactivați FT cu mașina în funcțiune
Legacy FT = Nu întotdeauna acceptat FT = Suportat
Amintiți-vă că FT protejează împotriva eșecurilor hardware ale serverului, nu a eșecurilor sistemelor de operare sau ale aplicațiilor.
vCenter Server Watchdog este o funcționalitate încorporată a versiunii 6.x. Acesta verifică periodic starea serviciilor care alcătuiesc vCenter, va reporni procesele de administrare sau VM, dacă este necesar.
