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).