Tag Archives: vSphere Replication

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

Articol pe 3 parți:

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

Acum că ne-am clarificat cu principiile de funcționare și topologii posibile pentru vSphere Replication a venit timpul și pentru teste in lab. Din topologiile descrise anterior o vom încerca topologia pe două site-uri cu un singur vCenter si un singur server vSRA(S) ca fiind de interes practic pentru mine.

Descriere mediu de test și topologie vSphere Replication

Mediul de test funcționează pe un server fizic cu suficiente resurse hardware pentru toate componentele topologiei de laborator. Topologia de laborator e complet izolată de producție. Host-urile ESXi funcționează in mașini virtuale ca ESXi-uri nested peste care rulează restul VM-urilor (ca VM-uri nested) din topologia de test. Topologia de laborator e prezentată mai jos:

vSR_p3_lab_env_architecture

In schemă: (de jos in sus)

  • rețeaua de producție – o vom folosi pentru (a) a ajunge prin vSphere Client la host-ul ESXi fizic și console VM-uri cu nested ESXi și (b) prin BI-NAT pe router-ul VYATTA cu vSphere Client la host-urile ESXi nested și la console VM-uri pe acestea.
  • host-ul ESXi fizic – platforma pentru mediul de test cu suficient resurse hardware. E nevoie de un host cu un minim de 16 GB RAM, CPU pe 4 core-uri și un storage mai rapid
  • standard switch pe ESXi-ul fizic – pentru networking-ul intre host-urile ESXi nested. Host-urile ESXi nested funcționează cu management network in subnet-uri diferite mai mult pentru a modela topologia pe două site-uri remote (care de obicei se interconectează prin L3). Routing-ul intre site-uri il vom organiza printr-un VM cu router VYTTA instalat. Pentru fiecare site pe vSwitch vom crea câte un grup de porturi fără uplink-uri și asociate cu VLAN-uri libere in producție.
  • host-uri ESXi nested – pe care vom construi topologia de test (izolat de producție).
  • VM cu router VYATTA pre-instalat pentru: (a) routing intre site-urile topologiei (primary/secondary) și (b) pentru acces din rețeaua de producție la cea de test (vSphere Client la managementul ESXi)
  • switch-uri virtuale pe host-urile ESXi – pentru (a) internetworking intre componentele topologiei de test (b) pentru management network host-uri ESXi nested.
  • VM-uri din topologia de test: (a) server domain controller / DNS (b) server vCenter din appliance vCSA (c) server vSRA (d) server vSRS (e) VM cu OS Win7 replicat de pe primary pe secondary site.

VM-urile din LAB le vom configura cu caracteristicile tehnice și networking ca in tabele de mai jos:

vSR_p3_VM_specs

Subnet-urile 192.168.1.0/24 și 192.168.2.0/24 utilizate in topologia de laborator pentru primary și respectiv secondary site. Subnet 10.128.23.0/24 network de serviciu din care 3x IP-uri mapate la management-ul host-urilor ESXi (23.181-1.10, 23.182-2.10) și server vCenter (23.183 – 1.160).

Configurare mediu de test

Pentru a nu ne pierde într-un ghid pas cu pas voi continua doar cu o descriere scurtă a configurațiilor pe componente:

configurare host-uri ESXi nested:

  • configurare pe vSwitch (host ESXi fizic) 2x grupuri de porturi: (a) pentru primary și (b) secondary site. Izolate, fără uplink-uri, asociate cu VLAN-uri ne-utilizate în alte rețele (e.g. 1918/1920).
  • creare VM-uri pentru ESXi-urile nested: (a) setează nume și virtual hardware alocat ca în tabelul de sus (b) Guest OS: Other 64-bit.
  • După creare VM: (a) schimbă Guest OS în VMware ESXi 5.x (b) scoate Floppy Drive (c) setează Power On Boot Delay la 10 sec (d) upgrade virtual hardware la VM version 9 – din linia de comanda cu vim-cmd: [vim-cmd vmsvc/upgrade vmid vmx-09]. (e) activare VHV (Virtual Hardware-Assisted Virtualization) pe VM-uri ESXi – prin edit vmx file: [echo vhv.enable = \”TRUE\”>> vmname.vmx]
  • instalare ESXi nested: (a) host name ca si VM name (b) IP-uri management, tabel (c) DNS (d) suffix: lab.local (e) default gateway: .1 din subnet.
  • update host-uri nested ESXi: (a) din linia de comanda cu esxcli: pofile list/update (b) reboot
  • instalare VMware Tools pentru nested ESXi: din linia de comanda cu esxcli: [esxcli software vib install -v /vmfs/volumes/[DATASTORE]/esx-tools-for-esxi-9.7.1-0.0.00000.i386.vib -f] (more info) . Ca alternativă, VMware tools inclus din timp in image profile-ul ISO-ului de setup fie prin (a) PowerCLI image builder sau cu (more info) fie cu  (b) ESXi-Customizer tool (more info)

Mai multe detalii despre procesul de setup ESXi nested citiți in: How to provision nested ESXi hosts on free ESXi.

configurare virtual router VYATTA:

  • VM pre-configurat cu 3x vNIC, tip E1000. Interfețe conectate in: (a) primary site port group (b) secondary site port group (c) in production network port group.
  • boot VM cu live CD VYATTA (folosit: vyatta-livecd-vc5.0.2.iso).
  • configurare VYATTA din linia de comandă: (a) adrese IP interfețe (b) bidirectional NAT pentru IP-urile ESXi-urilor și serverului vCenter (vezi tabel). Mai multe informații in: (a) Vyatta System – Quick Start Guide și (b) Vyatta System – NAT Reference Guide
  • testare networking prin connect cu vSphere Client din production network la ESXi-urile nested din lab.

configurare server AD/DNS/DHCP:

  • controller AD pe Windows Server 2012R2 cu DNS AD Integrated. Domain Name: lab.local. In principiu, se poate și fără acesta dar pentru deplinătate exercițiu il vom folosi mai târziu ca (a) serviciu de autentificare (b) server DNS (c) server DHCP (d) sursă NTP.
  • TCP/IP settings: (a) IP din primary site – 192.168.1.20 (b) default gateway – 192.168.1.1 (c) dns – local host.
  • opțional – pentru autentificare pe ESXi cu conturi AD: (a) aderare host-uri ESXi nested la domain-ul AD (b) reconfigurare DNS settings pe serverul AD/DNS.

configurare server vCenter (vCSA):

  • deploy appliance vCSA (folosit: VMware-vCenter-Server-Appliance-5.5.0.20000-2063318_OVF10.ova) pe host-ul ESXi nested primary site.
  • pe serverul DHCP se creează o rezervare pentru MAC-ul VM-ului cu vCSA. Reboot vCSA.
  • pe serverul DNS se creează o înregistrare A record cu numele severului vCenter: hq-vcsa-01, obligatoriu și înregistrarea in reverse lookup zone. A record legat de IP-ul 192.168.1.160.
  • din VAMI (admin WEB-UI, login cu root/vmware) (a) se schimba IP settings din DHCP in static pe același IP: 192.168.1.160. (b) se configurează time synchronization la serverul AD, ultimul la rândul lui se sincronizează la ESXi-ul nested prin VMware Tools (c) in network settings schimba FQDN in hq-vcsa.lab.local (daca nu sa autoconfigurat din DNS)
  • din VAMI se lansează Wizardul de configurare (in custom mode: Note: La SSO settings se introduce SSO password.
  • actualizare vCSA la ultima versiune (in cazul meu avut nevoie in prealabil de proxy settings). Build number trecut de la 2063318 la 2183109.
  • connect la vCSA cu (a) vSphere Client și (b) vSphere WEB Client.
  • din vSphere WEB Client (logged in cu administrator@vsphere.local) se configurează vCSA-ul pentru autentificare prin AD – in SSO configuration adăugat new identity source la AD-ul de laborator: lab.local.
  • in permissions pentru vCSA se adaugă contul AD local\vcenter.admin (creat din timp) cu privilegii de administrator.
  • adăugare host-uri ESXi nested (primary/secondary) la inventarul vCenter Sever.
  • pentru checkpoint e bine de creat aici snapshot-uri pentru ESXi-urile nested și VYATTA.

Configurare componente vSphere Replication

Conform topologiei de laborator pentru vSphere Replication vom avea nevoie de: (a) server vSRA in primary site și (b) server vSRS in secondary site. Mai jos vom instala ambele componente după care vom configura replicarea in secondary site pentru un VM din primary site.

Vom începe cu serverul vSRA care va fi asociat cu serverul vCenter după care vom înregistra pe vSRA serverul vSRS. vSRA-ul vine ca VM pre-configurat (un appliance – de unde si numele vSRA vSphere Replication Appliance) ce poate fi descărcat de aici și se implementează cu Deploy OVF Template din vSphere Client sau vSphere WEB Client (mai jos screen-urile capturate pentru WEB client). Pachet-ul de instalare (zip) include template-urile pentru două appliance-uri, unul pentru vSRA și altul pentru vSRS respectiv fișiere OVF vSphere_Replication_OVF10.ovf și vSphere_Replication_AddOn_OVF10.ovf.

Note: Înainte de a începe deployment-ul propriu-zis se asigură ca pe serverul DNS să avem înregistrările A Name (reverse/lookup zone) pentru serverele vSRA/S respectiv hq-vSRA-01.lab.local și drc-vSRA-01.

vSR_p3_DNS_records

Așadar, pentru vSRA implementăm OVF-ul pentru VSRA cu următorii parametri:

  • nume VM: HQ-vSRA-01, CPU 2x sau 4x, host ESXi: hq-vESXi-01.lab.local
  • configurație network: IP static, server DNS: 192.168.1.20, IP: 192.168.1.40, password
  • după deployment se pornește VM-ul vSRA-ului, progresul se urmărește in consola.
  • eventual pentru verificare/reconfigurare se poate accesa VAMI pe WEB (5480)

vSR_p3_VM_VRA_inventory

Teoretic dacă implementarea a avut loc cu succes, in vSphere WEB client trebuie să apară secțiunea cu vSphere Replication pe pagina căreia să avem statului Enabled (OK) pentru serviciul de replicare:

vSR_p3_vSR_enabled

Acum, vom implementa serverul vSRS pe site-ul secundar. Pentru asta din vSphere WEB Client in Manage – vSphere Replication – Replication Server pe obiectul vCenter se pornește Wizardul de deployment pentru servere vSRS:

  • ca source OVF folosim: vSphere_Replication_AddOn_OVF10.ovf
  • nume: DRC-vSRS-01, CPU 2x sau 4x, host ESXi: drc-vESXi-01.lab.local
  • configurație network: IP static, server DNS: 192.168.1.20, IP: 192.168.2.40, password
  • după deployment se pornește VM-ul vSRA-ului, progresul se urmărește in consola.
  • eventual pentru verificare/reconfigurare se poate accesa VAMI pe WEB (5480)

După implementare appliance serverul vSRS trebuie înregistrat pe vSRA, pentru asta in vSphere WEB Client in Manage – vSphere Replication – Replication Server se pornește Wizardul pentru Register vSphere Replication Sever. In Wizard se selectează serverul vSRS nou instalat: DRC-vSRS-01. Dacă procesul are loc cu succes ambele appliance-uri sunt prezentate in lista cu Replicated Servers:

vSR_p3_VM_VRS_registered

Starea serviciului vSphere Replication poate fi verificată din Service Health, in vSphere Client: Home – Administration – vCenter Service Status:

vSR_p3_vSR_health

Acum că avem configurate toate componentele pentru vSphere Replication suntem gata pentru a iniția replicarea unui VM de pe un site pe altul (primary to secondary).

Configurare vSphere Replication pentru un VM

Pentru replicare am creat un VM separat (HQ-RTEST-01) cu OS Windows 7 pe el (in principiu ar fi mers si daca replicam unul din VM-urile existente, de ex. cel cu AD/DNS sau vCSA). Din vSphere WEB Client – context menu la VM-ul pu care se dorește replicare – Actions – All vSphere Replication ActionsConfigure Replication …

vSR_p3_VM_repl_setup

De aici se pornește Wizardul pentru configurare replicare VM cu vSphere Replication in care în:

  • Replication type, selectăm (default) Replicate to a vCenter Server
  • Target site, selectăm unicul site reprezentat de singurul vCenter: hq-vcsa-01

vSR_p3_VM_repl_setup_target_site

  • Replication server, selectăm server vSRS din secondary site (DRC): DRC-VRS-01

vSR_p3_VM_repl_setup_repl_server

  • Target Location, select destinația pentru VM-ul replicat prin specificarea datastore-ului destinație: DS-LOCAL-01-D (așa cum l-am numit pentru ESXi-ul din secondary site). Tot de aici, prin Adavanced Configuration se poate de specificat formatul disk-ului la destinație, thin sau thick.

vSR_p3_VM_repl_setup_target_DS

  • Replication Options, dacă e cazul se selectează in Quiescing Guest OS metoda cu MS Shadow Copy Service (VSS).
  • Recovery Settings, se specifică RPO-ul pentru job-ul de replicare – practic cel mai important parametru de până acum. Așa cum am mai menționat mai înainte, RPO reprezintă perioada de replicare si are un min de 15 min. Altfel spus, maximum ce putem pierde din viața unui VM e 15 min de la ultima replicare. Pentru VM-urile critice se alege minimul de 15 min pentru VM-uri mai puțin importante se alege un RPO mai puține agresiv.  Valorile de RPO pentru VM-urile replicate trebuie alese si din perspectiva lățimii de bandă intre site-uri, cu cât mai des au loc job-urile de replicare cu atât mai mult bandwith se consumă așa că pin la urmă este un trade-off intre RPO per VM si bandwith disponibil intre site-uri. Pentru exemplu am ales RPO-ul de 4 h. Tot de aici, daca e cazul se configurează retention policy pentru checkpoint-uri in timp la VM-ul replicat.

vSR_p3_VM_repl_setup_RPO_set

In momentul imediat următor are loc faza de sincronizare inițială a VM-ului pe site-ul replicat (initial seeding) – fază care poate dura mai multe minute (depinde de bandwith si dimensiune VM).

Faptul că procesul de replicare a început poate fi confirmat pe client in lista Recent Tasks, in plus, cu datastore browser pe datastore-ul destinație se pot deja urmări folder-ul cu fișierele VM-ului replicat (in desen a doua copie pentru HQ-RTEST-01 e de la un job de replicare mai vechi):

vSR_p3_VM_datastore_verify

Pentru interes, cât are loc sincronizarea inițială se poate de urmărit conexiunea TCP intre VR Agent prin interfața VMK pe ESXi-ul sursă și IP-ul serverului vSRS pe site-ul destinație. Sincronizarea inițiala are loc prin TCP:31031 (pe când sincronizările periodice prin TCP:440046). În lista de conexiuni pe interfața VMk pe host-ul ESXi la sursă regăsim sesiunea cu serverul vSRS (192.168.2..20) prin TCP:310131.

vSR_p3_vSR_initial_seed_tcp_esxi

Pe de altă parte aceeași conexiune o găsim în terminalul serverului vSRS (Linux):

vSR_p3_vSR_initial_seed_tcp_vSRS

Pe deasupra, traficul de replicare poate fi urmărit cu ESXTOP atât pe ESXi sursă cât și destinație. In screen-ul de mai jos, VMk-ul pe ESXi-ul sursă transmite date la o rată de 80Mbps – așa cum altceva nu poate fi, putem presupune că e traficul de replicare (seeding-ul inițial).

vSR_p3_vSR_initial_seed_tcp_esxi_esxtop

La capătul opus, avem server-ul vSRS care recepționează tot traficul de replicare:

vSR_p3_vSR_initial_seed_tcp_dest_esxi_esxtop

Recuperare VM-ului din copia de replică

Pentru a încerca recuperarea VM-ului din copia de replică vom simula pierderea VM-ului sursă prin deconectarea acestuia. Procedurii de recuperare se inițiază din: vCenter Server – Monitor – vSphere Replication – context menu pentru VM-ul recuperat – Recovery …

vSR_p3_vSR_VM_recover

De aici se pornește Wizardul de recuperare VM, in care în:

  • Recovery Options, daca nu avem VM-ul sursă disponibil (tocmai situația pe care încercăm s-o modelăm) selectăm: Use latest available data

vSR_p3_vSR_VM_recover_options

  • Folder, selectăm container-ul de datacenter pentru secondary site.
  • Resource, selectăm host-ul destinație (drc-esxi-01)

Procesul de recuperare începe imediat, durează câteva secunde și poate fi urmărit in list cu recent tasks – all. In scurt timp, VM-ul recuperat apare in inventarul host-ului ESXi din secondary site. De remarcat că după recuperare din replică VM-ul nu este conectat automat la network (probabil pentru a exclude încă odată riscul conflictului cu VM-ul original) așa că procedura de recuperare trebuie să presupună si reconnect-ul pentru network.

vSR_p3_vSR_VM_recover_status

Cam atât pentru vSphere Replication, ușor de instalat, simplu de utilizat și pe deasupra gratuit.

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