Alternative la vMotion pentru mutarea mașinilor virtuale într-un alt depozit de date

Compania pentru care lucrez rulează un mediu virtual mic și are mai multe servere virtuale pe 2 gazde ESXi diferite gestionate de un vCenter, din motive legate de verificarea backupului, trebuie să fac loc pe unul dintre depozitele de date ale gazdelor ESXi. Gazda are montat un NAS Datastore care mai are încă mult spațiu pe el, așa că m-am gândit că ar fi o idee bună să muți acolo câteva dintre mașinile virtuale mai mari, problema este că gazdele noastre ESXi sunt licențiate cu o licență esențială, deci Nu am acces la stocare vmotion sau chiar vMotion îmbunătățit pentru această sarcină. Alternativ, m-am gândit să folosesc soluția noastră de backup (nakivo) pentru a face o copie de rezervă completă a mașinilor și a le restabili în Datastore-ul dorit sau pentru a clona mașinile virtuale în Datastore-ul dorit sau doar pentru a opri mașinile și a le migra. Niciuna dintre aceste opțiuni nu este la fel de confortabilă ca utilizarea vMotion, dar aș dori să știu care dintre aceste metode ar fi cea mai bună, în ceea ce privește riscul și timpul de nefuncționare. Evident, dacă cineva are o idee mai bună despre cum aș putea realiza acest lucru cu un risc minim și un timp de nefuncționare minim, sunt întotdeauna deschis la idei noi. Gazdele rulează ESXi-Versiunea 7.0.2

Iertați-mă dacă ceea ce sugerez nu este fezabil din cauza opțiunilor dvs. de licențiere, dar în timp ce StorageVMotion ar putea să nu funcționeze, ce ziceți să închideți mașinile virtuale, să navigați la depozitul de date în care se află și să mutați manual fișierele de la vechiul la cel nou - destul de sigur că este „gratuit” de făcut, doar că nu în timp ce VM-urile rulează. Poate fi necesar să eliminați mașinile virtuale din inventarul VC și apoi să le adăugați din nou din fișierul .vmx, dar asta se face rapid.

Estimați prețul pentru câteva opțiuni și cereți organizației - oricine plătește facturile - să vă ajute să decidă. Atât timpul de nefuncționare, cât și reducerea la minimum a timpului de nefuncționare au costuri. Includeți costurile perioadei de nefuncționare și timpul dvs., precum și orice achiziție.

Restaurarea copiei de rezervă folosește tehnologia pe care o aveți deja, deci este posibil să nu aibă costuri software. Ar trebui să faceți deja copii de rezervă și să faceți ocazional test de restaurare și, așadar, aveți o idee despre cât timp durează. Dacă nu ați făcut niciodată o restaurare, acesta este un motiv excelent pentru a face una. O simplă închidere și restaurare este ușor de făcut, menținând corect integritatea datelor, dar ar putea implica ore de nefuncționare. Timpul de recuperare și punctul de recuperare probabil ar putea fi îmbunătățite dacă sunteți mai inteligent cu restaurarea.

Minimizarea timpului de nefuncționare a sistemului necesită un anumit design și infrastructură. Pot aplicațiile să devină foarte disponibile, prin echilibrarea sarcinii pe mai multe VM de calcul? Apoi, o opțiune ar putea fi să afișați o instanță nouă, să le aveți pe ambele în spatele unui echilibrator de încărcare pentru ceva timp, apoi să scurgeți și să eliminați instanța veche.Cost ridicat al infrastructurii, timpului de proiectare și întreținere, dar timp de nefuncționare mic al serviciului. În plus, menținerea instanțelor de calcul separate poate fi utilă, de exemplu în timpul actualizărilor sistemului de operare.

Și opțiunea de migrare live. Aproape sigur vMotion Storage va implica plata VMware, să vă spună vânzările cât de mult. De asemenea, migrarea stocării live are cerințe considerabile de rețea. Ceea ce cumpără această investiție este o comandă pentru a muta o VM cu timp de nefuncționare aproape zero. Deși acest lucru nu vă exercită restaurările, nu contează ca rezervă într-un plan de continuitate a afacerii.

Ai putea folosi VMWare Converter Standalone - un instrument gratuit oferit chiar de VMWare pentru virtualizarea sistemelor hardware sau migrarea de la alte platforme de virtualizare la VMWare. Aici puteți folosi funcția „Virtual2Virtual”, unde vă puteți conecta la un sistem de virtualizare, iar convertorul va migra sistemul la altul. Sau puteți utiliza funcția „Physical2Virtual” - aici vă gestionați VM-ul sursă ca și cum ar fi un server fizic care trebuie virtualizat.

Acest lucru se poate face și ca „migrare la cald” fără a opri mașina sursă - cel puțin dacă nu este ceva de genul unui MS Domain Controler, de asemenea, foarte cu baze de date foarte ocupate, nu aș folosi cu adevărat „migrarea la cald”.