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.