Tag Archives: disaster recovery

Configurație vSphere Replication pe 2x site-uri și un singur vCenter. (2/3)

Articol pe 3 parți:

  1. Part I: prezentare generală, descriere funcționare
  2. Part II (curent): descriere topologii cu vSphere Replication
  3. Part III (urmeaza): lab time, configurație vSphere Replication pe două site-uri și un singur vCenter.

In prima parte a articolului am discutat particularitățile tehnologiei VMware vSphere Replication pentru replicarea de mașini virtuale. În cele ce urmează vom continua cu descrierea mai multor topologii posibile pentru vSphere Replication – topologii pe un singur sau mai multe site-uri cu unul sau mai multe servere vCenter. Până a trece mai departe să enumerăm câteva principii discutate in partea I a articolului:

  • vSphere Replication folosește VR agent pentru tracking-ul modificărilor pe discul VM-ului și seeding-ul acestora către destinație. VR agent folosește networking-ul VMK de management. Agentul folosește TCP:44046/31031 pentru replicarea spre vSRA/S.
  • destinație pentru traficul de replicare il constituie fie un server vSRA fie vSRS (vSphere Replication Appliance, vSphere Replication Server). vSRA-ul include vSRS-ul ca destinație pentru traficul de replicare plus componente de interacțiune cu server-ul vCenter: plug-unul WEB pentru vSphere Web Client. Prin WEB Client se administrează/monitorizează procesele de replicare, tot de aici se inițiază procesul de recuperare VM-uri.
  • La configurare vSRA-ul se asociază cu serverul vCenter. Un singur vSRA per vCenter.
  • In caz cu nu e practică găzduirea vSRA-ului la destinația replicării sau traficul de replicare depășește capacitatea appliance-ului vSRA se pot introduce unul sau mai multe servere vSRS.
  • La configurare unul sau mai multe servere vSRS se asociază cu un server vSRA. vSRS-ul poate fi asociat doar cu un singur vSRA.
  • Procesul de replicarea are loc asincron, periodic la intervale de timp definite print RPO, specific per VM. Bundle-ul de replicare ajunge la destinație prin două segmente: (a) de la agent la vSRA/S (b) de la vSRA/S pe fișierul VMDK a VM-ului. A doilea segment in general e sensibil la calitatea conexiunii asa că e bine ca distanța de la vSRA/S la ESXi-ul cu datastore-ul destinație să fie cât mai mică și sigura.

Așadar, vom continua prin a analiza particularitățile pentru următoarele câteva topologii vSphere Replication:

  • Topologii pe mai multe site-uri si multiple servere vCenter: (a) un singur server vSRA pentru întreg trafic de replicare și (b) cu un vSRA și multiple servere vSRS pentru balansare de trafic.
  • Topologii pe mai multe site-uri cu un singur server vCenter: (a) un singur vSRA și (b)  vSRA cu multiple servere vSRS înregistrate.
  • Topologii pe mai multe site-uri cu un singur server vCenter și cu destinație pentru replicare pe site-ul principal.
  • Topologii pe un singur site cu un singur server vCenter: (a) pe un singur host pentru datastore redundancy și (b) pe mai multe host-uri pentru datastore și host redundancy.

Topologii pe mai multe site-uri și multiple servere vCenter

Cea mai populară topologie, presupune replicarea intre două site-uri fiecare cu propriul server vCenter și server(e) vSRA/S. Traficul NFC este ținut local. Topologie perfectă pentru scenarii de disaster recovery (DR). În caz că pierdem primary site putem trece imediat pe vCenter-ul din secondary site de unde să inițiem procedura de recuperare a VM-urilor din replica (manual). Partea negativă e că avem nevoie de licențe in plus de servere vCenter deci de costuri in plus.

vSR_2site_single_VC_multiple_vSRS

E posibil ca traficul/sarcina de replicare să depășească capacitățile appliance-ului vSRA și atunci se introduc unul sau mai multe servere vSRS. La configurare, serverele vSRS se asociază cu vSRA-ul (mai multe la un singur vSRA). Ca destinație pentru traficul de replicare serverul vSRA/S se alege la configurarea pentru VM a replicii (balansarea sarcinii se atinge distribuind manual cât mai uniform sarcinile de replicare peste serverele vSRA/S).

vSR_multiple_sites_VC_and_vSRS

În schemă, site-ul B funcționează pe două ESXi-uri, un server vCenter și două servere vSRA/S ca target de replicare. VM-urile vor fi replicate uniform pe ambele servere vSRA/S. În aceeași schemă se prezintă un al treilea site gestionat cu vCenter-ul din site-ul B dar care are propriul server vSRS. Unele VM-uri din B sunt replicate pe site-ul C. In topologie trasele de replicare limitează traficul NFC in segmentul local.

Topologii pe mai multe site-uri cu un singur server vCenter

În caz că bugetul ne limitează la o singură licență de vCenter – care de obicei se instalează in primary site, atunci se poate incerca o topologie din cele descrise in continuare. In schema de mai jos, serverul vCenter este instalat in primary site si are inregistrate ESXi-urile din amabele site-uri. Poziția vSRA-ul in principiu e bine de ținut in secondary mai aprope de destinație (NFC-ul trebuie limitat local). Se prespune că WAN-ul e destul de calitativ ca intercațiunea dintre vCenter și vSRA sa fie una sigura (vSRA-ul furnizeaza plugin-ul pentru vSphere Web Client).

vSR_multiple_sites_single_VC

In caz că WAN-ul lasă de dorit e bine atunci de ținut vSRA-ul mai aproape de serverul vCenter iar pentru target de replicare de folosit un server vSRS in plus (inregistrat la primary vSRA) exact ca in schema de mai jos.

vSR_multiple_sites_single_VC_with_vSRS

Topologiile cu un singur vCenter sunt ieftine (licență doar pentur un singur vCenter) dar au neajunsul că nu pot acoperi un scenariul full de disaster recovery. Adevărul e că în caz că pierdem site-ul principal și ne dorim recuperea VM-urilor din replici vom avea nevoie de serverele vCenter și vSRA/S or astea gazduite in primary site nu mai sunt disponibile. Pe de altă parte, as a workaround, se poate de inclus si servere vCenter/vSRA in lista de VM-uri replicate dar recuperarea lor va trebui de realizat manual, manipulînd fișierele replicii pe datastore-ul destinație. Procedura pentru recuperea din replică a VM-ului vCenter este descrisă mai amănunțit aici: Can I protect my vCenter Server with vSphere Replication?.  Touși, trebuie de menționat că chiar dacă funcționează procesul nu este supported de VMware așa că use at your own risk.

Topologii pe mai multe site-uri cu un singur server vCenter și cu destinația de replicare pe site-ul principal.

Un use case interesant e cu topologia configurată pentru consolidarea replicilor intr-un singur loc, de exemplu VM-urile de pe ESXi-urile din branch-uri replicate pe un datastore in HQ. In schema de mai jos, primary site are instalat vSRA-ul (la nevoie pentru LB se pot instala adițional servere vSRS) iar agent-ul din ESXi-urile din branch-uri transmit replicile in primary site.

vSR_multiple_sites_replication_to_HQ

Topologii pe un singur site cu un singur server vCenter.

Chiar dacă destinat replicării la distanță vSphere Replication poate fi util și pentru topologii cu un singur site. In schema de mai jos (stânga) VM-ul protejat este configurat pentru replicare de pe un datastore pe altul pe același host, rezultatul e redundanță în plus la nivel de datastore. Topologia e una comoda pentru lab-uri de familiarizare cu produsul vSphere Replication. In schema din dreapta prin replicarea VM-ului de pe un host pe altul se obține redundanță atât la nivel de datastore cât și de host. Simplu și fără storage partajat intre ESXi-uri. 🙂

vSR_single_site_single_VC_ab

Acum că am clarificat nițel topologii posibile pentru vSphere Replication în ultima parte a articolului (part III) vom încerca pe viu in laborator produsul. Topologia de interes pentru mine va fi cea cu un singur server vCenter pe două site-uri și cu vSRA in secondary site.

Configurație vSphere Replication pe 2x site-uri și un singur vCenter. (1/3)

Articol pe 3 parți:

  1. Part I (curent): prezentare generală, descriere funcționare
  2. Part II (urmeaza): descriere topologii cu vSphere Replication
  3. Part III (urmeaza): lab time, configurație vSphere Replication pe două site-uri și un singur vCenter.

Preocuparea pentru siguranța și funcționarea neîntreruptă a aplicațiilor rămâne a fi una din sarcinile de bază pentru orice administrator IT. Dacă până nu demult problema asigurării continuității aplicațiilor era una complexă și complicată (trebuia să ții cont de particularitățile mecanismelor de HA pe fiecare aplicație in parte – dacă in general le avea) acum, odată cu virtualizarea serverelor, problema devine una trivială, toate aplicațiile le protejăm la fel prin aceleași mecanismele simple și sigure oferite de platforma de virtualizare. Virtualizarea serverelor ne aduce nu doar beneficiile consolidării dar și instrumente robuste pentru siguranța VM-urilor și a aplicațiilor. Începând cu vSphere 5.0 VMware introduce vSphere Replication pentru replicarea de mașini virtuale prin care, unui VM i se creează o copie (shadow) sincronizată periodic cu sursa desfășurată de obicei într-o altă locație (recovery site). Mai jos un sumar pe vSphere Replication  (in mare parte inspirat din VMware vSphere Replication 5.5 Overview, link aici):

  • disponibil la pachet cu licențe vSphere începând cu Essential Plus, no extra costs.
  • modul de replicare vSphere Replication integrat in hypervisor (vSphere 5.1 in sus, in 5.0 agent-ul de replicare era realizat in appliance-ul vSRA). Implicit, ca parte componentă din imaginea ESXi (esxi-base VIB). Din arhitectură mai face parte și un appliance: vSphere Replication Appliance (vSRA) ce are rolul de target (receptor) pentru traficul de replicare: – agentul urmărește modificările pe disk după care le transmite periodic către appliance-ul vSRA care le aplică pe discul virtual la destinație.
  • mecanism de replicare realizat sută la sută in software, nu are dependențe de hardware-ul storage-ului, alternativă ieftină pentru replicarea de nivel SAN. De aici libertatea de a folosi tehnologii și sisteme SAN neomogene intre site-uri (primary/recovery site): replicarea poate  fi configurată de pe un datastore VMFS la sursă pe un share NFS sau local storage la destinație, de pe iSCSI pe local s.a.m.d. Configurația thin sau thick pentru discurile mașinilor virtuale la destinație nu depinde de configurația respectivă la sursă (ex. replicare în thin pentru un disk thick). La fel replicarea e indiferentă dacă VM-ul sursă are sau nu snapshot-uri, snapshot-urile nu sunt replicate la destinație iar pe VM-ul shadow acestea devin consolidate într-o singură imagine flat. Revert-ul la un snapshot pe VM-ul sursă implică o resincronizare completă pentru vSphere Replication. Nu poate fi configurat pentru disk-uri virtuale RDM.
  • replicarea și parametri de replicare se configurează separat pe fiecare VM. Unele VM-uri mai critice pot fi configurate cu un RPO mai agresiv (sincronizare la intervale mai mici in timp) pe când altele mai puțin importante configurate cu replicare la intervale mai mari – poate fi important pentru economie de bandwith pe trafic de replicare. Mai mult, pe fiecare VM se poate decide care discuri sa fie replicate și care nu – uneori are sens de exclus din replicare discurile destinate datelor intermediare sau valide doar pe durata cât VM-ul e pornit, ca de ex. un disc rezervat swap-ului sau page file.
  • procesul de replicare este transparent pentru VM-ul protejat, non intruziv și independent de sistemul de operare din interiorul VM-ului. Nu e nevoie de configurații suplimentare in Guest OS.
  • vSphere Replication poate fi configurat pentru a asigura consistența datelor din aplicații și guest OS. Înainte de sincronizare agentul de replicare va impune OS-ul și aplicațiile să-și împingă (flush) datele intermediare (din buffere) pe discuri asigurând o copie consistentă (quiesce) a VM-ului. Interacționează prin VMware Tools cu writer-ii VSS din OS (server 2008/2012) și aplicații (Microsoft SQL databases, Exchange Server). Uneori, pentru VM-ui foarte active ca operațiuni pe disc și cu RPO mic trebuie deconectat – quiescing-ul poate dura mai multe minute și chiar depăși pragul RPO, in plus adaugă overhead asa că poate avea impact pe performanța aplicațiilor.
  • vSphere Replication se administrează dintr-o singură interfață integrată cu vSphere WEB Client (pentru 5.0 prin plug-in la client-ul c#). Appliance-ul vSphere Replication (target-ul de replicare) se configurează prin VAMI (virtual appliance management interface: https://<virtual appliance IP>:5480) – configurare adresa IP, host name, DNS s.a.m.d
  • vSphere Replication poate fi configurat să rețină mai multe replici in timp (istoric) ca potențiale stări de recuperare in trecut a VM-ului (MPIT – multiple point in time). Per VM se configurează dacă vor fi sau nu reținute în timp replici, câte replici trebuie rezervate pe zi (nu mai mult de 24) și pentru cât timp (nu mai mult de 20 zile) – retention policy. În esență replicile reținute formează un lanț de snapshot-uri pentru VM-ul shadow și pot fi interpretate standard din Snapshot Manager (snapshot-urile primesc ca nume string-ul cu timestamp-ul momentului în care au fost create). Restore-ul se execută întotdeauna la ultima replică după care dacă e cazul se trece pe una din replicile precedente prin aplicarea snapshot-ul respectiv.
  • vSphere Replication nu include instrumente pentru orchestrarea proceselor de recuperare în grup a VM-urilor (ex. cazul un scenariu de DR). Restore-ul se execută in regim manual, separat pentru fiecare VM in parte și de cele mai multe ori implică și unele ajustări in configurația guest OS-ului (ex. reconfigurare adresă IP). În ansamblu destul de mult efort totuși acceptabil pentru infrastructuri mici (cu până la câteva zeci de VM-uri replicate). Pentru infrastructuri medii/mari se recomandă utilizarea produsului Site Recovery Manager (SRM) on top la vSphere Replication care știe cum să automatizeze procesele de restore/failover. SRM-ul se licențiază/achiziționează separat și poate folosi pe lingă replicare software cu vSphere Replication și replicarea de nivel SAN.
  • începând cu versiunea 5.5 sunt scoase problemele legate de interacțiunea cu storage vMotion si storage DRS. Pina la 5.5 migrarea unui VM protejat cu vSphere Replication de pe un datastore pe altul (storage vMotion) întotdeauna ducea la o re-sincronizare full a VM-ului replică la VM-ul sursă (doar checksum nu și seed), inevitabil cu impact pe performanța storage-ului. Începând cu 5.5 problema e scoasă, migrarea are loc fără resync (împreună cu fișierele VM-ului se migrează și fișierul psf cu modificările de la ultima replicare). Storage DRS nu interpretează in nici un fel fișierele VM-ului shadow, altfel spus nu participa la balansarea sDRS și nici nu poate fi migrat cu storage vMotion. (more info)
  • vSphere Replication nu folosește Changed Block Tracking (CBT) pentru a urmări modificările discurile virtuale ci propriul mecanism implementat in agentul de replicare (prin vSCSI filter). Independența de CBT garantează că procesele de replicare nu vor interfera cu aplicațiile de backup ce folosesc vSphere Storage API for Data Protection și deci și CBT-ul.

Cum funcționează vSphere Replication ?

Sarcina vSphere Replication este de a crea o copie a VM-ului într-o locație alternativă cu sincronizarea (replicarea) periodică a acesteia la VM-ul sursă. Sincronizarea presupune identificarea și replicarea segmentelor de disc ce au suferit înscrieri unice în perioada de replicare (întotdeauna se replică ultima modificare). Perioada de replicare are loc la intervale de timp definit de administrator la configurarea replicării pentru VM (configurație per VM) – prin parametrul RPO. Minimum RPO este de 15 min ceea ce înseamnă că in cel mai rău caz (failure un ultima minută până la următoare sesiune de replicare) putem pierde cel mult 15 min din viața VM-ului. Într-o sesiune nouă de replicare vSphere Replication va livra doar modificările pe disc petrecute de la ultima sesiune de replicare (LWD – light weight delta). In faza inițiala are loc copierea integrală a VM-ului (baseline synchronization) de la sursă la destinație după care se intră in regim cu livrarea periodică a modificările. Se poate organiza copierea inițială a VM-ului la destinație fără vSphere Replication – ex. prin intermediul un suport de stocare mobil (snikersnet), util pentru economie de timp și bandwith.

Componente arhitectură vSphere Replication:

  • vSphere Replication Agent (VR agent) care: (a) urmărește modificările pe disc VM-ului intre două sesiuni consecutive de replicare și (b) transmite bundle-ul de modificări LWD către serverele vSphere Replication. Integrat in ESXi.
  • vSphere Replication Appliance (vSRA) ce include: (a) module pentru integrare cu serverul vCenter și (b) vSphere Replication Server. Prin modulele de integrare se asigură plugin-ul vSphere Replication in vSphere Web Access prin care: (a) se configurează replicarea pe VM-uri (b) se monitorizează procesul de replicare (c) se inițiază procedura de recuperare din replica. Obligatoriu un vSRA pe infrastructură, un singur vSRA per vCenter.
  • vSphere Replication Server (vSRS) cu sarcinile: (a) de a recepționa traficul de replicare de la agentul de replicare și ulterior (b) de a aplica modificările pe disc-ul destinație. Traficul de replicare are loc intre agent și vSRS in cadrul unei sesiuni TCP cu portul destinație 44046 (TCP:31031 pentru replicarea inițială)

Note: Dat fiind faptul că vSRA-ul include serverul vSRS sunt valide topologiile cu un singur server vSRA. Totuși, deși valide, nu întotdeauna aplicabile în scenarii de producție. Mai multe detalii sunt discutate in secțiunea următoare.

vSR_2site_single_vCenter

Legat de topologia de mai sus procesul de replicare trece prin următoarele faze:

  • agentul de replicare colectează (prin vSCSI filter) modificările pe disc-ul(rile) VM-ului ce au avut loc de la ultima sesiune de replicare. La momentul sincronizării agentul stabilește o sesiune de replicare cu serverul vSRA(S) asociat cu VM-ul respectiv ca target pentru traficul de replicare. Conexiunea are loc intre IP-ul portului VMK pe ESXi și IP-ul vSRA(S). In schema de mai sus replicarea VM-ului este configurată cu target-ul in vSRS-ul din site-ul secundar. Traficul de replicare parcurge traseul de la VMK – vmNIC – rețeaua fizică între site-uri – vmNIC – vNIC – VM vSRS.
  • serverul vSRS recepționează traficul de replicare din care adună setul de modificări transmise. Intermediarul este colectat intr-un redo log. Numai după recepționarea întregului set de modificări vSRS trece la faza de aplicare a modificărilor pe VM-ul destinație.
  • aplicarea modificărilor pe VM-ul destinație. vSRS-ul stabilește o conexiune cu kernel-ul hypervizorului prin care își montează VMDK-ul destinație. VMDK-ul este montat peste IP prin protocolul Network File Copy (NFC) – block based similar ca idee cu iSCSI. In final vSRS aplică pe discul destinație modificările recepționate de la ultima sesiune de replicare. Traficul de replicare parcurge traseul de la vmNIC-ul vSRS-ului până la VMK-ul ESXi-ului.
  • după un interval RPO procesul se repetă de la început.

Note: E bine ca traficul NFC să aibă loc pe segmente scurte de rețea, de ex. in interiorul LAN-ului. NFC-ul e destul de sensibil la calitatea conexiunii de rețea așa că tranzitarea lui peste linii WAN nu este recomandată. De aici și o recomandare de design de avut câte un server vSRS pe fiecare site peste WAN.

În următorul articol din serie voi descrie mai pe larg alte topologiile posibile pentru vSphere Replication (part II) după care vom încerca in lab topologia pe două site-uri cu un singur vCenter (part III).