Tag Archives: VMware

Set nou de carte pentru studenții orelor de VMware

Devine deja o tradiție ca studenții claselor de VMware să primească cadouri sub formă de carte.  La fel s-a întâmplat și cu grupa curentă pentru care tocmai am primit noul set de cărți. De remarcat silința administratorilor academiei care au depus tot efortul ca cadourile să existe și ca acestea să ajungă la studenții noștri într-un timp cât mai scurt de la lansarea grupei. 

WP_20150303_012

Sper să le fie de mare ajutor în inițiativa lor de studiu și le urez într-un ceas bun.

 

GNS3 – doesn’t work ping through the cloud on VM

First of all I would like to mention that all actions published here have as scope educational purpose. A lot of people who are trying to use GNS3 for testing/lab purpose meet the problem with connection to Internet through cloud.

My problem was: I couldn't ping from router in gns3 any external host. I meet this problem several times on different Operating Systems with different versions of GNS3. I researched on Internet for the solution many times and every time gave up in front of the problem. This is why I decided to write this article. It could be useful for someone in the same situation.

Let's begin with topology:

  1. I decided to install GNS3 on the Linux Ubuntu 14.04. Big Thanks to people who wrote this article http://www.computingforgeeks.com/2014/12/best-way-to-install-gns3-version-12-in.html and special thanks for those who wrote installation script.
  2. One of the most important things is that I decided to install GNS3 on VM using as hypervisor ESXi. Below you can see the topology. So I selected VM1 for this purpose.
  3. I connected ESXi host to the Cisco's switch using two cables. Cable connected to the G0/1 interface was set to trunk. Cable on G0/2 wasn't used (we will use it for debug purpose later).
  4. My VM1 has two interfaces. One is for remote management and the second for testing purpose.
  5. From VM1 I could ping from VLAN 10 interface User PC.

VMware_GNS3

Let's move to GNS3 and create topology:

I am not going explain how to create topology and connect to the cloud you could easy find how to do it on internet. I will just publish screen from my topology:

VMware_GNS3_topologyAfter topology creation I was configured Interface Fa0/0 to get ip address via DHCP:

R1(config)#int fa0/0
R1(config-if)#ip add dhcp
R1(config-if)#no sh
R1(config-if)#
*Mar  1 00:03:35.071: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:03:36.071: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 00:03:48.367: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.140.65, mask 255.255.255.0, hostname R1

Ok I have confirmation that packets are going through cloud. Everything is good. Next test is to ping CR2 interface ip address:

R1(config-if)#do ping 192.168.140.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.140.254, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

 Hmm.. Maybe ICMP packets were suppressed. Let's try to send ping from VM – ping test passed. So we have the situation when some packets could reach GNS3 and some others couldn't. Let's try to find where is the exactly the problem. Packets could be stuck on VM or somewhere in the network. We are connected to the Cisco switch and we have option to configure SPAN or port mirroring in order to check out suppositions. Let's do it.

C2960(config)#monitor session 1 source interface gigabitEthernet 0/1 both

C2960(config)#monitor session 1 destination interface GigabitEthernet 0/2

Please keep in mind that Gi0/2 interface couldn't send legacy user traffic after this configuration. In our case this is not a problem because I don't use this interface. On the VM2 I run Wireshark application and from R1 in GNS run again ping command. In the wireshark I see that packets leave VM and return back to the host. So problem seems to be somewhere on the VM. It could be SElinux or iptables.

Let's try another thing. Let's check how is set vmnic0 interface for VLAN10 in security tab. For this go the vSphere Client -> Configuration -> Networking -> Properties -> Double-click on your VLAN -> Press Security tab. I had the following configuration:

VMware_GNS3_errorLet's try to change promiscuous mode from Reject to Accept and repeat test again. The results:

R1(config-if)#do ping 192.168.140.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.140.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/44 ms
R1(config-if)#

Here was my problem. Promiscuous mode allows vSwitch to forward all frames including those which are not directed to VM. Router in GNS3 acts as virtual interface inside of VM. From security purpose VMware block frames which are addressed to VM.

I hope that this article could be useful for you.

 

Limite de scalabilitate servere vCenter (vCenter Server vs vCSA)

Devine interesant de urmărit concurența dintre serverul vCenter realizat pe Windows și cel realizat pe Linux – mai jos menționate ca vCenter Server și respectiv vCenter Server Appliance (vCSA). Serverul vCenter pe Linux apare relativ recent – începând cu vSphere 5.0 și e tânăr în comparație cu tradiționalul server pe Windows. Dacă prima versiune, vCSA-ul reprezenta un produs destul de crud și implementat fără mare entuziasm in mediile de producție, pe parcurs lucrurile sau mai schimbat, de la o versiune la alta vCSA-ul sa maturizat și a devenit o alternativă serioasă, uneori chiar mai buna pentru varianta pe Windows. Până la urmă strategia VMware este în a exclude treptat dependența în produsele sal e de sistemele de operare Microsoft. Ultimul cuvânt va fi după versiunea pe Linux.

Pentru comparație, mai jos, vom verifica limitele de scalabilitate în ceea ce privește numărul maxim de host-uri ESXi și VM-uri running înregistrate pe un singur server vCenter. Sigur, o comparație exhaustivă include mult mai mult decât acești indicatori, dar pentru azi suficient și astea. Așa cum nu am găsit pe net, consolidat, evoluția limitelor de la o versiune la alta, mi-am făcut un tabel al mau care să adune toate detaliile la un loc. Vedeți mai jos ce a ieșit.

vcenter_scalability_limits_general_table

Tabelul include numărul maxim de host-uri ESXi și VM-uri running pentru versiunile vCenter Server și vCSA cu bază de date emmbeded și externe,  începând cu versiunile 5.0 până în 6.0. La fel se prezintă, generalizat, versiunile bază de date suportate de fiecare produs in parte.

Informațiile din tabel sunt confirmate prin următoarele surse VMware (se observă cât de dispersate sunt). Excepție fac limitele pentru vCSA 5.0 cu bază DB2 pentru care nu am putut găsi o documentare clară.

  1. kb.vmware.com – Services bundled with vCenter Server Appliance (2002531) 

“The vCSA 5.0 GA uses an embedded DB2 Express database.”

“The vCSA 5.0 Update 1b, vCSA 5.1, and vCSA 5.5 all use an embedded vPostgres database.”

  1. kb.vmware.com – Minimum requirements for the VMware vCenter Server 5.x Appliance (2005086)

“In vSphere 5.0/5.1, the embedded database provided with the vCenter Server Appliance supports an inventory with a maximum of 5 hosts and 50 virtual machines.”

  1. kb.vmware.com – Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5 (2058441)

“vCenter Server Appliance 5.5 embedded vPostgres database can now support as many as 100 vSphere ESXi hosts and 3,000 virtual machines”

  1. blogs.vmware.com – vSphere 6 – Clarifying the misinformation

“Supported databases for the windows installation are SQL 2008 R2, 2012 and 2014, Oracle  11g and 12c as well as the option to use an embedded vPostgres database. vPostgres on windows is limited to 20 hosts and 200 virtual machines. Upgrades where SQL express was installed will be converted to vPostgres. The vCenter Server Appliance supports embedded vPostgres at full scale, 1000 host and 10,000 virtual machines and is the recommended database for the vCenter Server appliance. External Oracle 11g and 12c databases are supported as well for this release, look for these to be phased out in future releases.”

  1. Purging old data from the database used by VMware vCenter Server 4.x and 5.x (1025914)

“SQL Express 2005/2008 (vCenter Server 5.x is bundled with SQL Express 2008) supports a maximum of 5 hosts and 50 virtual machines. If your environment exceeds these thresholds, you must upgrade your database to SQL Standard edition.”

Lista completă de versiuni bază de date compatibile cu versiunile vCenter o găsiți în VMware Product Interoperability Matrixes (Solution/Database interoperability) 

  1. vmware.com – VMware Product Interoperability Matrixes

Pe final, câteva observații scurte:

  1. Începând cu versiunea 6.0 serverul vCenter pe Windows nu mai folosește MS SQL Express edition pentru setup-uri cu bază de date embedded (simple install). În schimb, VMware propune propriul produs bază de date vPostgres (un Postgres DB customizat de VMware). Pe partea de scalabilitate se observă o săritură de la 50 VM-uri / 5 host-uri (care mult timp a limitat setup-urile cu MS SQL Express) la 200 VM-uri / 20 host-uri.
  2. Începând cu versiunea 5.5 scalabilitatea vCSA-ului cu DB embedded începe să se îmbunătățească simțitor și să devină mai superioară vCenter-ului pe Windows cu DB MS SQL Express – 3000/100 in comparație cu 50/5. La o limită de 3000/100 vCSA-ul se face potrivit pentru implementări pe infrastructuri mai serioase.
  3. Scalabilitatea mai bună este menținută și in versiunea 6.0 chiar dacă ambele versiuni folosesc deja vPostgres ca backend – 10.000/1000 in comparație cu 200/20. Prin astea cred că se dorește scoaterea treptată a vCenter-ului pe Windows ..
  4. Ambele versiuni (vCSA și vCenter pe Windows) au aceleași limite de scalabilitate in caz că folosesc un database extern în loc de cel embedded. Mai mult cifrele nu se schimba de la o versiune la alta și rămân la limita de 10.000 VM-uri pe 1.000 host-uri.
  5. vCSA-ul 6.0 cu bază de date emmbeded vPostgres are aceleași limite ca și pentru cazul cu un database extern pe Oracle. Dacă în anumite cazuri se migra la un database extern pentru a obține o scalabilitate mai buna atunci cu 6.0 DB embedded îți oferă implicit scalabilitatea maximă.
  6. vCSA-ul poate folosi doar Oracle ca database extern. Motivul pentru care nu există suport și pentru MS SQL este că nu încă nu sunt drivere ODBC supported pe Linux DB-ul MS SQL.

 

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

Dual boot Windows și ESXi instalat pe stick USB

Mai devreme sau mai târziu unul din studenții din clasele noi de VMware îmi dă aceeași “Cum ai configurat dual boot-ul de Windows și ESXi pe PC-urile din clasă ?” Ca să am explicația la îndemână am să fac o descriere pe pași pentru configurația de dual boot utilizată pe PC-urile din clasa de VMware academie DNT. Dual boot-ul e configurat intre două sisteme de operare: unul de Windows 7 (pre-instalat) și o imagine ESXi instalată pe un stick USB.

Înainte să continuu e bine să explic contextul în care am avut nevoie de dual booting pe PC-urile din sala de studiu VMware. Încă de la bun început s-a pus problema ca în cadrul orelor practice VMware să putem organiza scenarii complexe de laborator cu minim de achiziție de echipament. Printre soluții, varianta cu destinație dublă pentru PC-urile deja instalate sa dovedit a fi cea mai potrivită, pe de-o parte PC-urile le putem folosi ca desktop-uri cu Windows iar pe de altă parte ca host-uri ESXi in scenariile de laborator. Configurația am realizat-o cu dual boot intre SO-ul Windows deja instalat pe discul rigid și imagine ESXi instalată pe un stick USB compact fixat in spatele PC-ului. Drept datastore pentru VM-uri pe ESXi folosim spațiul pe un server iSCSI dedicat.

Ce opțiuni am încercat pentru dual-boot ?

Ca să găsim o variantă mai optimă am încercat câteva opțiuni pentru dual-boot:

  • dual-boot Windows vs ESXi pe același disk rigid, idee care sa dovedit a fi imposibil de implementat. Problema e că procesul de setup ESXi distruge automat restul partițiilor pe disk și deci și pe cea de Windows. ESXi-ul nu e prea prietenos când vine vorba de a partaja același disk cu alte sisteme de operare.
  • dual-boot Windows vs ESXi pe disk-uri rigide separate – indezirabil pentru că: (1) nu avem spațiu liber pentru un disk nou in case-urile PC-urilor (Optiplex 780 – ultrasmall form factor) și (2) implica achiziții in plus pentru 10 HDD-uri noi (3) overhead de spațiu pe dikc-urile noi – o imagine de ESXi nu are nevoie de mai mult de câțiva GB pentru setup.
  • dual-boot Windows vs ESXi cu imagine ESXi instalată pe stick USB extern. Soluție realizabilă și practică pentru că: (1) minim investiții – doar pentru 10 stick-uri de 4GB noi (2) partițiile Windows pe disk-ul existent nu sunt atinse (3) configurație simplă.

Evident că am mers pe varianta cu ESXi-ul instalat pe stick-uri USB. Urma să găsim modul in care vom configura dual-boot-ul:

  • no at all – ne bazăm pe BIOS boot meniu, din care alegi fie USB pentru ESXi fie Hard Disk pentru Windows. Realizabil, dar cam non-practic: bunăoară nu poți să setezi ca meniul să-ți apară automat și dacă ai scăpat moment-ul pentru BIOS boot meniu (care e foarte scurt) ești nevoit să mai treci odată prin reboot.
  • or modificăm boot loader-ul din Windows în așa fel încât să fie posibilă și încărcarea ESXi.

Evident că am mers pe varianta cu modificarea boot loader-ului din Windows, configurație pe care o voi descrie în textul de mai jos.

dual_boot_esxi_and_win7_scheme

Cum se încarcă sistemele de operare Windows ?

Până a merge mai departe fac un overview scurt la cum se încarcă sistemele de operare Windows. Cred că de folos pentru ce urmează.

(1) Windows XP, Server 2003:

  • folosește NTLDR ca boot loader – hidden, boot partition, C:\
  • folosește boot.ini pentru boot configuration – hidden, boot partition, C:\
  • boot.ini conține opțiunile pentru boot menu.
  • boot.ini editabil cu notepad sau cu System Configuration Utility.
  • NTLDR e încărcat de loader-ul din MBR (VBR): bootstrap.
  • NTLDR încarcă ntoskernel.exe
  • aceeași partiție pentru system și boot partition

(2) Windows Vista, 7, Server 2008, 2012:

  • boot manager complet nou: Windows Boot Manager
  • folosește Boot Configuration Date (BCD) in loc de boot.ini
  • BCD in format Windows Registry: HKEY_LOCAL_MACHINE\BCD00000
  • BCD conține opțiunile pentru boot menu.
  • BCD poate fi modificat cu: bcdedit.exe, regedit.exe sau cu mai simplu cu EasyBCD.
  • Windows Boot Manager încarcă winload.exe
  • implicit partiții diferite pentru (1) system partition (boot loader files, no letter) și (2) boot partition (..\windows folder, c:\)

Instalare imagine ESXi pe stick-ul USB

Primul pas a fost să instalez ESXi-ul pe stick-urile USB. Inițial credeam că fac un install pe unul din stick-uri după care găsesc un tool cu care le clonez pe restul. Până la urmă le-am instalat de la zero pe fiecare, tool-urile de clonning pe care le-am încercat copiau rău de tot, iti lua o groza de timp pină făcea copua. Install-ul l-am făcut din VMware Workstation într-un VM la care am adus stick-urile USB. Printre altele, metodă documentată de VMware (link aici). Procedura pentru insalarea ESXi pe stick cu VMware Workstation se reduce la:

  • Creăm un VM pentru setup-ul de ESXi (2x vCPU, 4GB RAM, no HDD)
  • Montam CD/DVD-ul sau ISO file de instalare ESXi la VM
  • Pornim VM-ul după care facem pass-through in VM pentru dispozitivul stick-ului
  • Pornim procesul standard de setup. Se asigura ca installer-ul a detectat stick-ul.
  • După ce setup-ul este încheiat, shutdown la VM, eject USB stick.
  • ESXi-ul este instalat pe stick și gata de utilizare

Configurare boot menu in BCD pe Windows.

Acum că avem stick-ul cu ESXi preparat, il instalăm in unul din porturile USB pe PC. La academie am folosit cele mai mici posibile stick-uri USB, de 4GB, cu urechiușe, pe care le-am montat aproape invizibil în spatele PC-utilor, pentru siguranță le-am fixat suplimentar cu coliere din plastic pentru cabluri.

Pentru editare configurație boot BCD, prefer să folosesc EasyBCD care e simplu de utilizat și gratuit pentru non-comercial use (link aici). Tool-ul distribuit împreună cu sistemul de operare bcdedit.exe sau editarea directă a registrului nu sunt tocmai confortabile.

Așadar, după ce instalăm EasyBCD pe stația cu SO Windows (nu merită să descriu aici) parcurgem următorii pași pentru a configura dual-boot-ul cu imaginea ESXi:

  • Vom instala loader-ul GRUB (NeoGrub) care in serie cu Windows Boot Manager va încarcă loader-ul ESXi (syslinux bootloader). Serializam prin GRUB pentru că loader-ul ESXi nu poate fi inițiat din Windows Boot Manager. Din EasyBCD Toolbox click pe Add New EntryNeoGrub bootloader (install).
  • După install, pe disk-ul de sistem vor fi copiate fișierele bootloader-ului: neogrub, neogrub.mbr și menu.lst (ultimele in folderul NST pe root)
  • Din aceeași fereastră click pe Configure (sau edit fișier menu.lst cu notepad). În notepad-ul deschis inserăm configurația cu textul de mai jos:

Note1: Dacă mai tirziu nu funcționează, se va juca cu alte valori pentru hd1: hd2, hd3 …

  • Până aici suficient pentru dual boot, la repornirea PC-ului vor apărea consecutiv două ferestre de dialog pentru selecție opțiuni de boot: (1) una din Windows Boot Manager cu variante pentru Windows și GRUB și (2) a două din GRUB cu o singura variantă pentru disk-ul pe care este instalat ESXi-ul. In fereastra GRUB titlu opțiunii va fi cea specificată fișierul menu.lst după linia title.
  • Ce se mai poate de făcut e să redenumim opțiunile din Windows Boot Manager:

dual_boot_esxi_and_win7_modify_menu_entries

Așa că in final vom avea, primul dialog pentru Windows Boot Manager:

dual_boot_esxi_and_win7_windows_boot_manager_boot_menu

și dacă selectăm VMware ESXi urmează să se deschidă următorul boot menu:

dual_boot_esxi_and_win7_GRUB_boot_menu

Așa cum meniul din GRUB nu prea are sens (o singura opțiune care se selectează automat după timeout) e bine ca acesta sa nu mai fie afișat. Pentru asta in configurația GRUB setăm un timeout de 0 secunde așa că la momentul afișării se va trece automat peste el.

Configurațiile de mai sus au mers pentru ESXi 5.1/5.5 și sisteme de operare Windows Server 2008R2/Windows 7. Cred că și alte mix-uri funcționează.

Funny testing cu disk-uri in RAM

Mi-am găsit distracție pentru sfârșitul ăsta de săptămână: am să verific pe cât de rapidă poate poate fi memoria RAM atunci când o parte din ea e transformată într-un disk logic. Scenariul testat mai jos e cam lipsit de valoare în practică, totuși pentru amuzament merită.  N-o să vă povestesc prea multe despre ce este un disk RAM, am să zic doar că e un disk virtual cu suport pentru stocare organizat in memoria RAM, e super-fast și are un throughput net-superior in raport cu disk-urile mecanice și chiar și cu SSD-urile.  E și clar: no mechanical parts, plus un throughput la viteza magistralei de date a PC-ului. Legat de subiect mi-am adus aminte de un calcul interesant făcut de autor in Mastering VMware vSphere 5 (pag. 544) care după ce compara timpii de acces (seek time) pentru RAM, SSD și HDD – corespunzător de 10ns, 500us și respectiv 8ms continuă cu a raporta diferențele la o secundă de acces pe RAM:

RAM is accessed 800.000 times faster than traditional rotation disk or 50.000 times faster than SSD. Or to put it another way, if RAM takes 1 second to access, the disk could take 800.000 second to access – or nine and a quarter days …

  • HDD: ((800.000/60 seconds)/60 minutes)/24 hours = 9.259 days
  • SSD:((50.00/60 seconds)/60 minutes)/24 hours = 0.5 days

Continue reading

Pe cât de practic poate fi HotPlug/HotAdd-ul VMware ?

Mulți din noi suntem deja familiarizați cu funcționalitatea prin care putem reconfigura din mers capacitățile vRAM și vCPU a mașinilor virtuale pe un hypervizor ESXi. Aplicată pe un VM, funcționalitatea ne promite reconfigurare dinamică și fără downtime a mașinii virtuale. Mecanismul pare a avea potențial practic, mai ales in scenarii cu aplicații critice găzduite in VM-uri ce au nevoie la un moment dat de capacități in plus dar totodată nu pot fi întrerupte pentru upgrade. Chiar dacă există in hypervizor, utilizarea funcției nu întotdeauna e fezabilă în practică. Pe de o parte există factori care depind de OS alții care deprind de însuși aplicații. Ceea ce am să încerc mai jos e să analizez atitudinea a două din aplicațiile Microsoft: servere WEB și SQL față de HotPlug-ul de CPU. Încep totuși cu o introducere in HotAdd/HotPlug-ul din VMware.

Particularități tehnologie VMware HotAdd/HotPlug

  • funcționează pentru VM-uri începând cu versiunea 7 VM (ESXi 4.x/Workstation 7.x)
  • ai nevoie de licențe Enterprise sau Enterprise Plus pe hosturile de virtualizare – dacă  licența nu include feature-ul de Hot-Pluggable virtual HW  atunci la reconfigurare vei primi mesajul de eroare: Feature HotPlug is not licensed with this edition ..
  • are sens doar daca folosești un guest OS compatibil cu HotAdd/HotPlug – atât Microsoft Windows (cu excepții) cât și Linux au suport pentru HotAdd RAM și HotPlug CPU.
  • nu e compatibil cu funcționalitatea de Fault Tolerance (FT).
  • online doar într-o direcție: HotAdd/HotPlug nu și Remove (cândva posibil acum depreciat)
  • HotAdd vs HotPlug ? Subiect de semantică, de regulă HotAdd-ul e folosit in context cu RAM-ul pe când HotPlug in raport cu resurse CPU.
  • Implicit deconectat pentru toate VM-urile. Se configurează pe fiecare VM in parte cu settings separat pe CPU și RAM, obligatoriu pe VM deconectat. Implicit deconectat pentru că (1) HotAdd/HotPlug-ul implică un plus de overhead pe VMM-ul VM-ului si (2) in practică prea puține VM-uri au nevoie reconfigurare online, așa că un disabled all e mai dezirabil. Funcția trebuie activată din timp pentru a nu ajunge in situația in care îți dorești un upgrade online pe unul din VM-uri dar care încă nu are funcția activată, astfel încât vei fi nevoit până la urmă să introduci un downtime pentru shutdown-reconfigure VM or ăsta nu e tocmai scenariul pe care ți l-ai dorit.
  • Activarea feature-ulu de CPU HotPlug deconectează topologia vNUMA.

Suport guest OS pentru Hot Add-ul de CPU si RAM ?

Dacă e să vorbim de sisteme de operare Microsoft (server) și Linux atunci pentru ambele există suport, totuși nu fără mici excepții:

  • Windows Server 2008R2 Standard (doar RAM) Enterprise/Datacenter (RAM & CPU)
  • Windows Server 2012R2 Standard/Datacenter (RAM & CPU)
  • Linux pe un kernel 2.6.14 sau superior

Sigur lista putea fi una mai comprehensivă și să includă de exemplu toate versiunile servere Windows începând 2003 cu sau fără SP2/R2, Standard/Enterprise sau Datacenter pe 32 sau 64 de biți dar pentru simplitate m-am limitat doar la câteva OS-uri cele mai implementate azi.

Pentru servere 2003 Windows 2003 lucrurile se complică pentru că acestea folosesc  HAL-uri diferite pentru sisteme uniprocessor (UP) și multiprocessor (SMP). HAL-ul corespunzător se configurează automat la instalarea OS-ului așa că pentru un upgrade de la un vCPU pe mai multe (de altfel și invers) va fi nevoie și de reconfigurat HAL-ul (din Device Manager – Computer – ACPI Uniprocessor – Update Driver .. se alege ACPI multiprocesor ș.a.m.d). Din curiozitate verificați articolul: Modifying the Hardware Abstraction Layer (HAL) for a Windows virtual machine (1003978). Sistemele de operare Microsoft începând cu servere 2008 / Windows Vista au un HAL comun pentru UP și SMP așa că ne scutește de nevoia de a reconfigura HAL-ul. Un HAL potrivit e important pentru că dacă e greșit atunci inevitabil vor fi probleme de performanță (CPU pe guest OS liber cu core pe host-ul fizic încărcat la maxim): High CPU utilization of inactive Windows virtual machines (1077).

Cum se configurează Hot Add / Hot Plug ?

Din settings-ul VM-ului (Virtual Machine Properties – Options – Advanced – Memory/CPU Hot Plug) se activează funcțiile de Memory HotAdd  și CPU HotPlug (mai jos screen pe vSphere client). Se configurează pe VM-ul deconectat. Btw, opțiunea de Memory/CPU Hotplug lipsește la VM-urile configurate pentru Guest OS-uri incompatibile cu HotAdd/HotPlug.

how_practicaly_hot_add_can_be_activate_hotadd

Din acest moment VM-ul poate fi reconfigurat cu resurse RAM si CPU in plus chiar si după ce mașina virtuală este pornită. De remarcat warrning-ul de loc evident sub dropbox-ul cu numărul de procesoare – o atenționare in plus pentru a verifica configurația OS-ului la configurația hardware-ului (multiprocessor HAL pentru SMP or uniprocessor HAL pu UP):

how_practicaly_hot_add_can_be_cpu_add_warrning

Resursele noi de CPU și RAM sunt interpretate de către guest OS ca și dispozitive PnP care se auto-configurează și devine disponibile imediat. Prezența resurselor poate fi verificată simplu din (1) System Properties, (2) Device Manager sau (3) Task Manager:

how_practicaly_hot_add_can_be_confirm_hotadd

Dacă la momentul upgrade-ului aplicația Task Manager este deja deschisă, un dialog ne va propune reîncărcarea aplicației pentru a reflecta corect resursele adăugate (doar pentru vCPU hot plug, pentru hot add de vRAM se actualizează automat):

how_practicaly_hot_add_can_be_restart_task_manager

Verificare Hot Plug de vCPU pe aplicații single și multi-thread

Pentru început vom încerca câteva teste de HotPlug pe un server VM cu un workload generat sintetic. Sarcina pe server o vom simula cu un tool Sysinternals: CPUSTRESS:EXE, distribuit gratuit și care poate fi descărcat de aici. Ce este bine la CPUSTRESS e că cu acesta putem genera un workload pe mai multe thread-uri paralele, cu fiecare thread configurabil ca prioritate (in process queue) și intensitate a sarcinii (consumă o fracțiune din timpul CPU-ului sau il saturează la maxim). Subiectul muli-thread-ului e foarte important in contextul HotPlug-ului pentru dacă e HotPlug atunci sigur vorbim de mai multe vCPU-uri ori mai multe vCPU-uri pot fi consumate doar de aplicații multi-thread. Aplicațiile single-thread (majoritatea din ele) nu au cum să consume mai mult decât puterea unui singur CPU, asta e, ține de caracterul sarcinii din aceste aplicații – sarcini ce nu pot fi împărțite pe task-uri paralele. Din asta rezultă si una din recomandările de design a VM-urilor: numărul de vCPU-uri intr-un VM trebuie configurat reieșind din ce aplicații rulează pe acesta, pentru aplicații single-thread se vor configura VM-uri cu un singur vCPU, mai multe vCPU-uri nu vor aduce performanță în plus ci doar overhead pe hypervizor.

Așadar, să realizăm câteva teste cu CPUSTRESS și HOT PLUG in regim single și multi-thread. Efectul îl vom urmări în Task Manager. Btw, din TM putem urmări numărul de thread-uri asociate cu o aplicație sau process, pentru asta adăugam coloana Threads in lista Processes (View-Select Columns ..). In screen-ul de mai jos este ilustrat CPUSTRESS cu 3x thread-uri (app-ul propriu zis) + 2x thread-uri (sintetic) și Task Manager cu coloana Threads inclusă.

how_practicaly_hot_add_can_be_CPUSTRESS

Pentru început să încercăm pe un VM pre-configurat cu un singur vCPU să adăugăm prin Hot Plug încă un vCPU în timp ce CPUSTREES rulează un thread de sarcina sintetic (cu activity setat pe maximum). Se observă că adăugarea unui vCPU nou nu-l face încă disponibil pentru thread-ul de aplicație, core-ul inițial rămâne încărcat iar cel nou fără sarcină. Interesant e că dacă repornești aplicația se implică de acum și al doilea vCPU totuși nu în același timp așa că in sumă tot capacitatea unui vCPU va fi absorbită (50% din ambele vCPU-uri). E și de așteptat pentru o aplicație single-thread care nu poate consuma mai mult decât capacitatea unui singure vCPU.

how_practicaly_hot_add_can_be_CPUSTRESS_singlethread

Să încercăm acum același test pentru CPUSTRESS setat cu 2x thread-uri in paralel (ambele cu activity pe maximum). Același rezultat se observă, noul vCPU (HotPluged) disponibil in sistem nu este încă disponibil pentru workload-ul aplicației, unica soluție pentru a ajunge la el e repornirea aplicației. După repornire deja se observă ambele core-uri implicate. Prin contrast cu testul precedent multithreading-ul saturează ambele core-uri la maxim.

how_practicaly_hot_add_can_be_CPUSTRESS_multithread

Suport HotPlug de CPU pentru aplicații pe IIS Web

Să încercăm acum să repetăm scenariile de mai sus pentru o aplicație pe serverul IIS. Pentru test vom folosi o aplicație WEB programată cu un loop infint pentru a simula o sarcină CPU pe procesul IIS-ului. De menționat că aplicația WEB e una single-thread – pentru multithreading e nevoie de cod in plus :). Efectul multi-thread il vom simula prin deschiderea in paralel a mai multor instanțe de aplicație (un tab in browser cu pagina aplicației). Codul sursă e cel din screen-ul de mai jos, loop-ul este pornit printr-un buton.

how_practicaly_hot_add_can_IISCPUHOG_code

Testele le vom realiza pe o configurație default de IIS 7 (IIS/ASP.NET/.NET4/no-afinity) pe un site separat (CPUHOG) rulat într-un Application Pool izolat. Din Task Manager vom urmări sarcina pe vCPU-uri. Intr-un IIS un application pool este asociat cu un process w3wp.exe in OS – anume pe acesta se observă workload-ul din TM. Repornirea aplicației o vom face cu IISRESET din linia de comandă, de menționat că kill la procesul w3wp.exe din task manager s-au recycle pe Application Pool din IIS Manager nu are efectul presupus (mai multe mai jos).

Așadar să mergem pe următoarele două scenarii:

  • VM pornit cu un singur vCPU upgradat cu HotPlug la două vCPU-uri in timp ce pe IIS rulează o instanța a aplicației CPUHOG. Repornim worker process cu IISRESET.
  • VM pornit cu un singur vCPU upgradat cu HotPlug la două vCPU-uri în timp ce pe IIS rulează două instanțe a aplicației CPUHOG. Repornim worker process cu IISRESET.

Se observă un rezultat similar ca și in testele de mai sus cu workload sintetic și anume:

  • IIS-ul ignoră orice vCPU nou in sistem. Atât pentru single-thread cât și multi-thread doar un singur core rămâne saturat, pe când cel nou e in așteptare.
  • Pentru implicarea noului vCPU e nevoie de repornirea IIS-ului. După repornirea IIS-ului single-thread-ul va fi distribuit de către scheduler-ul OS de CPU pe ambele core-uri dar niciodată in paralel așa că capacitatea sumară rămâne la puterea unui core. Multi-thread-ul așa și cum și era de așteptat va satura ambele vCPU-uri din sistem.

Chiar dacă testul arată contrariul, totuși trebuie de menționat ca IIS-ul știe de fapt să reacționează la apariția unui nou vCPU și anume prin recycling-ul automat la process-ul w3wp.exe care face ca ISS-ul să conștientizarea noul vCPU. De ce nu mers in cazul testelor de mai sus, e pentru că IIS-ul folosește metoda overlapped recycle prin care noul w3wp.exe este pornit in paralel cu cel vechi, care va prelua treptat sarcinile noi din aplicație iar cele vechi rămânând a fi deservite de vechiul w3wp.exe până vor fi încheiate. Or aplicația folosită de noi e una fără sfârșit și deci va fi asociată la infinit de w3wp.exe-ul inițial fără a trece pe procesul w3wp.exe nou (cel care știe deja de vCPU-ul in plus) – de aici si rezultat-ul cu lipsa de interes pentru noul vCPU.

Suport HotPlug de CPU pentru Microsoft SQL Server

Microsoft SQL Server are suport pentru funcția de CPU HotPlug. Următoarele cerințe trebuie satisfăcute pentru hot plug-ul de CPU intr-un server SQL:

  • Hardware și x64 SO cu suport pentru HotPlug CPU (evident)
  • Server Microsoft SQL de la 2008 in sus (Hot Add RAM prezent de la 2005)
  • Server Microsoft SQL ediție Enterprise
  • Serverul SQL nu poate fi configurat pentru soft NUMA.

Spre deosebire de IIS serverul SQL evită intenționat să implice resursele noi de CPU. Pentru a folosi CPU-urile noi pe instanța SQL va trebui de rulat procedura de RECONFIGURE server. In plus dacă e folosit un affinity mask: affinity64 (>32 CPU) acesta va trebui modificat și el.

Până a trece pe teste, va fi util să analizăm un pic subiectului de thread and task architecture în serverul SQL:

  • aplicațiile Windows sunt planificate (alocare time slot) pe CPU de către scheduler-ul încorporat in kernel-ul sistemului de operare. Aplicațiile/procesle ce au nevoie de CPU formează o coadă către acesta, cu o ordine bazată pe priorități (preemptive scheduling), mai mult SO-ul poate oricând decupla forțat un process de la CPU în favoarea altui process mai prioritar.
  • abordarea descrisă funcționează pentru majoritatea aplicațiilor (inclusiv și cele 2x descrise mai sus) nu și pentru serverul SQL. Asta pentru că tratarea thread-urilor din interiorul SQL-ului cu aceeași algoritmi ca și restul proceselor ar fi ineficientă pentru că ar duce la o mulțime de comutări intre contexte datorată realocărilor de CPU. Reieșind din asta pe serverul SQL sa implementat propriul scheduler de CPU numit SOS Scheduler și care introduce un algoritm cooperativ (în loc să fie decuplate forțat thread-urile sunt lăsate să se cedeze voluntar CPU-ul).
  • in SOS Scheduler fiecare core fizic sau procesor logic are asociat un așa numit scheduler – responsabil de planificarea accesului la CPU pentru thread-urile SQL. Fiecare CPU are asociat scheduler (numit scheduler SQL) destinat thread-urilor utilizator (interogări SQL) și niciunul sau câteva Scheduler-e administrative: ​(1) mai multe Scheduler-e pentru Resource Monitor  – supervisor peste Scheduler-e SQL, ce garantează că acestea nu vor monopoliza resursele CPU ș.a.(2) un Scheduler pentru DAC (Dedicated Administrator Connection) – pentru a te putea conecta in caz că Scheduler-ele SQL sunt blocate.
  • Lista de Scheduler-e poate fi obținută din DMV-ul: sys.dm_os_scheduler.
  • Un Scheduler se poate afla în mai multe stări printre care: (1) VISIBLE ONLINE (DAC) – scheduler DAC (2) VISIBLE ONLINE – scheduler standard SQL (3) HIDEN ONLINE – scheduler Resource Monitor (4) HOT_ADDED – creat ca răspuns la un nou CPU (HotPluged) in sistem. Screen-ul de mai jos prezinta DMV-ul cu Scheduler-e SOS pentru un sistem de CPU Quad Core.

Schema de mai jos încearcă să ilustreze ce sa scris despre Scheduler-e si sarcini pe SQL:

how_practicaly_hot_add_can_be_SQLOS_architecture

Acum că ne-am familiarizat cu mecanismele de threading și task management pe un server SQL să încercăm câteva teste pe viu. Vom merge pe scenariul cu un VM pornit cu un singur vCPU upgradat cu HotPlug la două vCPU-uri in timp ce pe instanța de SQL se execută un script-ul pentru simularea de sarcină pe CPU. Vom verifica impactului adus de noul vCPU până și după executarea procedurii RECONFIGURE pe serverul SQL. Pentru exercițiu vom folosi un VM cu OS: Windows Server 2012R2 Standard și o instanță Microsoft SQL Server 2012 x64 Enterprise.

In mare parte testele pe SQL sunt inspirate din How to hot-add a vCPU to a virtual SQL Server, tot de aci vom scoate script-ul pentru generarea de sarcină CPU intensive pe o instanță SQL:

how_practicaly_hot_add_can_be_T-SQL_for_CPUHOG

Așadar, după ce porni, scriptul pentru generare de sarcină pe CPU, merge pe următorii pași:

  • urmărim in Task Manager Usage-ul pe singurul vCPU – consumat la 100%
  • verificam Processor Affinity pe instanța SQL (Server Properties – Processor) -> grayed out pentru ca avem un singur CPU și nici o modificare nu e permisă.
  • verificam scheduler-ii SQL cu SELECT * FROM sys.dm_os_schedulers -> avem un singur scheduler pentru thread-urile rulate pe instanța SQL (screen mai jos, Schedulers.A)
  • adăugăm un vCPU nou la VM (VM-ul pre-configurat pentru HotAdd/HotPlug)
  • urmărim în Task Manager sarcina pe CPU-uri – serverul SQL rămâne să consume un singur vCPU (screen mai jos, CPU.B). Obținem același rezultat și dacă pornim mai multe instanțe de script in paralel – in concluzie, serverul SQL nu ia in calcul noul vCPU.
  • verificăm scheduler-ii SQL -> nimic nou (screen mai jos, Schedulers.B)
  • pentru reconfigurare server executăm procedura RECONFIGURE -> nu merge din prima, pentru că: The affinity mask specified does not match the CPU mask on this system … Ca soluție pe server in affinity mask se trece pe manual după care se bifează singurul vCPU. După RECONFIGURE se setează affinity mask iarăși pe automat.
  • verificam Scheduler-ii SQL -> observăm un scheduler nou asociat cu noul vCPU și care figurează cu statut: VISIBLE ONLINE HOT_ADDED. (screen mai jos, Schedulers.C)
  • repornim script-ul pentru generare sarcina pe CPU (cu mai multe instanțe in paralel)
  • in Task Manager verificam Usage-ul pe CPU – acum ambele CPU-uri sunt implicate (screen mai jos, CPU.C)
  • repornim instanța SQL, verificăm Scheduler-ii SQL – Scheduler-ul nou și-a schimbat statutul in VISIBLE ONLINE (screen mai jos, Schedulers.D)

how_practicaly_hot_add_can_be_T-SQL_CPU_usage_x

how_practicaly_hot_add_can_be_T-SQL_SQL_schedulers