Category Archives: VMware

VMware Category

VMware NSX logical routing LAB

Following the subject of previous post, I will continue with NSX routing LAB topology used by me in my NSX learning. LAB topology diagram are inserted below. 

VMware NSX logical routing LAB diagram

(click on picture for hi resolution image)

A brief description for lab topology:

  • There are tree VXLAN logical switches: 5001, 5002 and 5003 corresponding to segments in a formal three-tier application (WEB/APP/DB). Each segment have a related subnet network: 10.128.20.0/24 for LS5003 (WEB), 10.128.21.0/24 for LS5002 (APP) and 10.128.22.0/24 for LS5001 (DB).
  • Inter VXLAN routing are provided by a Distributed Logical Router (DLR) and an Edge Services Gateway (ESG). DLR act as a default gateway for DB and APP segments and ESG provide routing for WEB network segment. First IP from each subnet are reserved for default gateway.
  • Both DLR and ESG are configured in HA configuration mode (active-standby) – that is why these services are represented by two VMs each (vShield Edge for ESG and Control VM for DLR) – x per Edge ESXi host.
  • A group of two ESG appliances configured for Equal Cost Multi Path (ECMP) routing provides upstream communications. ECMP are enabled as well for DLR and ESG routers.
  • All routers are interconnected trough a transit logical switch 5004. Routers in this segment will use IP addresses from 10.128.10.0/24 subnet: .5 for ESG, .254 and .253 for each of upstream routers. The DLR router use two IP addresses: first (.2) as a forwarding address and second (.3) as a control plane address (protocol address).
  • DLR, ESG and upstream routers exchange routing information via OSPF. All routers forms OSPF neighbor relationships.
  • ESG router are configured with both interfaces (internal and uplink) as part of the OSPF process (mapped to OSPF Area 0). DLR router have OSPF activated only on uplink interface and configured to redistribute in OSPF directly connected networks (APP and DB).
  • Upstream routers use OSPF on its internal interfaces and form BGP peering with external physical routers via its uplink interfaces.
  • External communications take place trough a dedicated dvPG (EDGE) with uplinks via physical NICs – DirectPath IO pass-through from physical host to EDGE nested ESXi.
  • Upstream ESG routers will redistribute BGP routes in OSPF and conversely OSPF to BGP.  

Presented below, are the configurations applied on physical routers (RTR1/2). VLAN 100 are used to interconnect with ESG upstream routers (EDGE/10.128.30.0/24 subnet) and VLAN 102 to reach next hop on Mikrotik router (subnet 192.168.1.0/24). For Internet access, a NAT overload function is configured on Mikrotik network appliance.

VMware NSX logical routing - physical router configuration

After all the configurations applied, we can check the routing protocol adjacencies and routing table information. For instance, here’s what DLR routers showing us:

OSPF adjacencies with ESG router (.5) and upstream routers (.253 and .254)

VMware NSX logical routing - DLR ospf adjacencies

Respectively, the routing table: 

VMware NSX logical routing - DLR routing table

We can observe two routes learned via OSPF: one to 10.128.20.0/24 (WEB) learned from ESG routers (.5) and a default route 0.0.0.0/0 as external redistribute route. All other routers are directly connected type. Btw, 172.16.22.121 is the IP address of the DLR’s router management interface and 169.254.1.8/30 are the automatically assigned network used for heartbeating between DLR router failover peers.

BGP peering can be checked on one of the upstream ESG router:

VMware NSX logical routing - upstream ESG BGP peering

and corresponding, all known networks: 

VMware NSX logical routing - upstream ESG known networks

It’s interesting to verify the routes installed in routing table on physical routers. Bellow, are shown the routes on RTR1 physical routers.

VMware NSX logical routing - physical router routing table

Finally, we can check the connectivity to some internet resources from one of the VM connected to internal logical switch (5002/APP): 

VMware NSX logical routing - traceroute test

My NSX Lab environment – short description

In this post, I will insert a diagram from my NSX LAB environment. A brief description follow thereafter.

My NSX Lab environment – short description

(click on picture for hi resolution image)

General LAB environment description:

  • All NSX lab components (ESXi servers with NSX loadable modules, NSX manager, Controller Cluster VMs, DLR control VM, etc.) are performed as virtual machines, all running on a single physical server. It is the same physical server used by our students (at DNT) in their lab exercises. Physical server have sufficient capacity to support all of my NSX lab scenarios (in my particular case I had access to 8x 2,9GHz x5570 CPU cores, 64GB RAM, 500GB storage space on 8xHDD 10k RAID10 LUN).
  • Physical server resources are controlled by LAB vCenter Server that define a particular vAPP container with minimum reserved resources for each student. My NSX LAB act in such a container. Each student have privileges to manage VMs only in their own container.
  • All LAB scenario’s VMs can be connected only to one permitted port group: dvPortGroup-Students. This port group have no uplinks (in other words isolated from physical networks), configured to carry all VLAN numbers and act in promiscuous mode (mandatory for nested ESXi). Students will use a remote access VPN connection to get into this network (via a VPN gateway build as a VM connected at the same time to production and isolated students network). An http proxy server are configured to enable access to Internet http/s resources from isolated student network. Lab vCenter Server, VPN and Proxy Server are all part of ADM-INFRA-VMW vAPP container with restricted access.

Note: For more information about DNT classroom VMware’s lab environment check one of the previous article series (Mediu de laborator pentru studenții claselor de VMware, part I, part II, part III).

NSX lab architecture brief description:

  • NSX lab will use IP addresses from 172.16.22.0/24 subnet (all IP allocations are shown in diagram)
  • a dedicated vCenter sever is installed (further integrated with NSX manager)
  • five nested ESXi are installed and configured. These are grouped in three clusters: two computer clusters and one edge/mgmt cluster.
  • two distributed switches are used, one for ESXi in compute clusters and other for edge/mgmt cluster. A single transport zone are configured across all ESXi clusters.
  • several VXLAN switches are configured and interconnected via a Distributed Logical Router or NSX Edge. Some test VMs are connected to these VXLAN switches.
  • EDGE cluster’s nested ESXi hosts are additionally equipped with dual port physical NIC brought here via DirectPath IO from physical server. Physical ports are connected to external routers and switches (Cisco equipment from our CCNP lab kit). 

Image below show the inventory views for LAB vCenter Server (left) and NSX LAB vCenter Server (right):

My NSX Lab environment – short description - inventory views

My list for useful links for VMware NSX studying

Recently, I had the chance to get a new VMware certification: VMware Certified Professional 6 – Network Virtualization. During the study, I made a list of useful links and references – a list that I want to share in this post. Certainly, the subject is continuously evolving so the list will become outdated shortly, but even so, it can be a starting point. The list is as is for the end of 2015, no updates will be added. The list is presented with no particular order.

  1. VMware NSX for vSphere (NSX-V) Network Virtualization Design Guide (pdf, 93 pag.) (link)
  2. VCP Network Virtualization – Exam Blue Print (pdf, 25 pag.)
  3. VMware NSX Install. Configure, Manage [6.0] – student guide (pdf, 480 pag.)
  4. VMware NSX Install. Configure, Manage [6.0] – lab manual (pdf, 226 pag.)
  5. vmware.com – microsegmentation using NSX distributed firewall (pdf, 30 pag.)
  6. vmware.com – NSX for vSphere, getting started guide (pdf, 43 pag.)
  7. blog.bertello.org – NSX for Newbies – Part 1-10 (link)
  8. routetocloud.com – NSX Distributed Logical Router Deep Dive (link)
  9. routetocloud.com – NSX Distributed Firewall Deep Dive (link)
  10. HOL-SDC-1403   VMware NSX Introduction (link)
  11. HOL-SDC-1425   VMware NSX Advanced (link)
  12. featurewalkthrough.vmware.com  – NSX – (link)
  13. buildVirtual – VCP-NV Objectives Study Guide (link)
  14. YAVB – Rich Dowling  – VCP-NV (link)
  15. Ivan Pepelnjak – Overlay Virtual Networks in SDN (pdf, 278 pag.)
  16. HOL-PRT-1462   Palo Alto Networks – Virtualized Data Center Security (link)
  17. HOL-SDC-1415   IT Outcomes – Security Controls Native to Infrastructure (link)
  18. HOL-SDC-1420   OpenStack with VMware vSphere and NSX (link)
  19. HOL-SDC-1424   VMware NSX and the vRealize Suite (link)
  20. HOL-SDC-1412   IT Outcomes – Data Center Virtualization and Standardization (link)
  21. HOL-SDC-1319  VMware NSX … (link)
  22. packetmischief – DCI: THE NEED FOR STRETCHED LAYER 2 (link)
  23. packetmischief – Five Functional Facts about VXLAN (link)
  24. packetmischief – WHY IS THERE A “WRONG WAY” TO INTERCONNECT DATACENTERS? (link)
  25. packetmischief – DCI SERIES: OVERLAY TRANSPORT VIRTUALIZATION (link) // offtop
  26. packetmischief – FIVE FUNCTIONAL FACTS ABOUT OTV (link) // offtop
  27. telecomoccasionally – NSX for vSphere: Understanding Transport Zone scoping (link)
  28. VMware NSX Use Case – Simplifying Disaster Recovery – Part 1 (link)
  29. VMware NSX Use Case – Simplifying Disaster Recovery – Part 2 (link)
  30. Considerations for Management Interface of Distributed Logical Router Control VM (2122060)
  31. blog.ipspace.net – Does uRPF Make Sense in Internet Service Provider Networks? (link)
  32. NSX 6.2 admin guide – Add a Logical (Distributed) Router (link)
  33. blogs.vmware.com – Getting Started with VMware NSX Part I – Building Virtual Networks (link)
  34. blogs.vmware.com – Getting Started with VMware NSX Part II – Building Virtual Networks (link)
  35. NSX Compendium- VMware NSX for vSphere (link)
  36. Сетевые оверлейные технологии для ЦОД. Часть 1 (link)
  37. Сетевые оверлейные технологии для ЦОД. Часть 2 (link)
  38. Сетевые оверлейные технологии для ЦОД. Часть 3 (link)
  39. bradhedlund.com- Going Over the Edge with your VMware NSX and Cisco Nexus (link)
  40. bradhedlund.com- The vSwitch ILLUSION and DMZ virtualization (link) // offtop
  41. bradhedlund.com- Distributed virtual and physical routing in VMware NSX for vSphere (link)
  42. bradhedlund.com- On choosing VMware NSX or Cisco AICI (link)
  43. bradhedlund.com- What is Network Virtualization? (link)
  44. bradhedlund.com- What is a Distributed Firewall? (link)
  45. bradhedlund.com- An introduction to Zero Trust virtualization-centric security (link)
  46. blog.ipspace.net – ROUTING PROTOCOLS ON NSX EDGE SERVICES ROUTER (link)
  47. blog.ipspace.net – HYPER-V NETWORK VIRTUALIZATION (HNV/NVGRE): SIMPLY AMAZING  (link)
  48. VMworld 2014: SEC1746 – NSX Distributed Firewall Deep Dive (link)
  49. telecomoccasionally – Distributed Firewall (DFW) in NSX for vSphere, and “Applied To:” (link)
  50. telecomoccasionally – NSX for vSphere: VXLAN Control Plane modes explained (link)
  51. networkinferno.net – Validating Distributed Firewall rulesets in NSX (link)
  52. networkinferno.net – Implementing a  Zero Trust Security Architecture (link)
  53. Manage and report on a Distributed Firewall using NSX Manager and ESXi CLI commands (link)
  54. blog.ipspace.net – INTERFACING OVERLAY VIRTUAL NETWORKS WITH MPLS/VPN WAN (link)
  55. blogs.vmware.com – VMware vCloud Hybrid Service Direct Connect Primer (link)
  56. habr – Сети для самых маленьких. Часть восьмая. BGP и IP SLA (link)
  57. VMware NSX, Convergence, and Reforming Operational Visibility for the SDDC (link)
  58. Tom Fojta's Blog  – vCloud Director with NSX: Edge Cluster (link)
  59. VMware.com – vCloud Architecture Toolkit – vCAT-SP (link)
  60. blogs.technet.com – Border Gateway Protocol (BGP) with Windows Server 2012 R2 (link)
  61. blogs.technet.com – Multi-tenant Site-to-Site (S2S) VPN GW  with Windows Server 2012 R2 (link)
  62. NSX Use Case Diagrams (link)
  63. VMware vRealize Automation with NSX (link)
  64. Architecture Design: vSphere with IPv6 (link)
  65. Network Virtualization (NSX) and vSphere Data Protection Interop (link)
  66. VMware NSX Installation Part 5 – Checking NSX Controller Status (link)
  67. routetocloud.com – Troubleshooting NSX-V Controller (link)
  68. routedocloud.com – NSX Load Balancing (link)
  69. routedocloud.com – NSX-V Edge NAT (link)
  70. blogs.vmware.com – Useful VXLAN commands in ESXCLI 5.1 (link)
  71. blogs.vmware.com – Understanding and troubleshooting NSX for vSphere 6.x DFW (link
  72. SR-IOV support status FAQ (2038739) (link)
  73. NSX vSphere troubleshooting (link)
  74. LAG vs. LBT for vSwitch Uplinks in vSphere  (link)
  75. vSphere Distributed Switch Part 14 – Configuring dvPortGroup General Settings (link)
  76. IPv6 in vSphere 6 (link)
  77. blog.ine.com – The Inside and Outside of NAT (link)
  78. NSX Useful numbers – VCP-NV Study (link)
  79. Deploying, Troubleshooting, and Monitoring VMware NSX Distributed Firewall (link)
  80. HOW TO TROUBLESHOOT USING NET-VDR COMMAND (link)
  81. Proxy ARP & ICMP Redirect in vShield Edge NIC – Explained (link)
  82. How to install and configure VMware NSX 6.1.2 SSL VPN-Plus Step by Step (link)

Following the subject, next I will post some info about my NSX lab environment.

 

Rețele Private VLAN (PVLAN) – part II

După o scurtă introducere în rețele PVLAN făcută în prima parte a articolului am să continui cu o prezentare pentru câteva exemple de utilizare PVLAN. În părțile ce vor urma planific să descriu tipuri de interfețe trunk specifice PVLAN pe switch-uri Cisco, condițiile impuse pentru un switch peste care sunt tranzitate VLAN-uri private precum și modul în care pot fi configurate PVLAN-urile pe un switch distribuit VMware.

Exemple de utilizare

Să analizăm câteva use case-uri tipice pentru rețele PVLAN:

  • rețea hosting provider
  • rețea demilitarizată DMZ
  • rețea de backup
  • rețea desktop-uri virtuale VDI.

Rețea hosting provider

O rețea a unui hosting provider adună la un loc (într-un singur network) nodurile/host-urile mai multor clienți – ultimii, funcție de dimensiunea provider-ului posibil să ajungă de ordinul sutelor, miilor, zecilor de mii s.a.m.d. Sigur, fiecare client își dorește un mediu de rețea securizat și izolat de restul clienților, dar, securizat și izolat însemnă VLAN-uri și subnet-uri IP dedicate per client or acest lucru e aproape imposibil pentru hoster-ii mari, pe de-o parte VLAN-urile tradiționale suferă de o scalabilitate proastă – un maxim de 4094 de VLAN ID-uri și pe de altă parte overhead în plus pe IP – adrese IP pierdute pe numărul/broadcast-ul rețelei, interfețe L3 pe router/firewall pentru fiecare subnet, overhead administrativ.

PVLAN-urile oferă o soluție simplă și totodată scalabilă pentru așa fel de scenarii. În loc de VLAN-uri/subnet-uri separate per client, va fi suficient ca în rețeaua hoster-ului să se configureze un PVLAN pe o singură rețea L3. Pentru segregare, fiecare client se va ancora în VLAN-ul secundar izolat din PVLAN. Serviciile partajate se vor conecta în port-urile promiscous pe VLAN-ul primar. Design-ul va consuma două VLAN-uri (primar și secundar izolat), două adrese IP și o singură interfață pentru router/firewall folosit ca și default gateway la subnet. Soluția e de-a dreptul fără limite de scalabilitate, imaginați-vă că aceasta e bună și pentru de un hoster cu 1M de clienți – indiferent de dimensiune se vor consuma aceleași două VLAN-uri și un singur subnet iar clienții în același timp vor rămâne izolați între ei. Vedeți mai jos o ilustrare pentru un astfel de scenariu:

PVLAN-part2-usecase-secureISP

Rețea demilitarizată DMZ

În rețeaua unei companii PVLAN-urile se pot dovedi extrem utile pe segmentul ei de DMZ. Într-o arhitectură de rețea securizată se obișnuiește ca serverele cu acces public ale companiei să fie organizate într-un segment de rețea izolat, separat de celelalte servere interne. Respectivul segment formează așa numita zona demilitarizată DMZ a rețelei. Într-un DMZ, este permis accesul din rețeaua publică (Internet) la serverele din DMZ și totodată blocat pe alte rețele interne. Pe de altă parte, serverelor din DMZ le este permis să comunice cu rețelele interne. Segmentul de DMZ este separat de rețelele interne și rețeaua publică prin dispozitive firewall. Altfel spus, DMZ-ul permite expunerea controlată a unui grup de servere într-o rețea publică fără să se compromită securitatea pentru celelalte servere din infrastructură.

Chiar dacă oferă un layer în plus de protecție, DMZ-ul nu ne poate apăra de situațiile în care sunt compromise însuși servere din DMZ. Odată rupte – de exemplu prin exploatarea unei găuri în chiar sistemul de operare, intrusul poate încerca să obțină acces neautorizat în rețelele interne sau pe alte servere din DMZ. Toate serverele din DMZ rămân deschise unul în față de celălalt iar securitatea întregului ansamblu se raportează la securitatea celui mai slab protejat server.

Pentru a reduce vulnerabilitatea serverelor din DMZ în fața unui vecin compromis se pot utiliza rețelele private PVLAN. Să luăm ca exemplu scenariul din schema prezentată mai jos (stânga), avem aici un segment DMZ cu două servere DNS, un server de poștă și un server WEB. Serverele din DMZ nu au nevoie să comunice între ele cu excepția DNS-urilor care lucrează în failover unul pentru altul și care au nevoie să schimbe periodic informații între ele.

PVLAN-part2-usecase-DMZ&LB

Pentru un setup cu PVLAN-uri serverele SMTP și WEB se vor plasa în Secondary Isolated VLAN al VLAN-ului privat iar serverele DNS se vor conecta în porturile asociate cu un Secondary Community VLAN dedicat. În așa fel, serverele DNS vor putea să comunice liber intre ele dar nu și cu celelalte servere din DMZ la fel și restul serverelor vor fi restricționate să comunice unul cu altul. Acum suprafața de atac va fi blocată pe perimetrul serverul compromis asigurându-se protecție pentru celelalte servere din DMZ.

Vom face același lucru și pentru cazul cu mai multe servere conectate în spatele unui Load Balancer, de exemplu într-o fermă de servere HTTP pentru un site WEB (vezi in desenul de mai sus pe dreapta). În regim normal serverele nu au nevoie să comunice între ele așa că pentru o securitate mai bună va fi bine să le izolăm între ele, de exemplu prin conectarea într-un Secondary Isolated VLAN dintr-un PVLAN.

Ce este interesant, migrarea de pe o arhitectură cu un singur VLAN pe una cu PVLAN poate fi realizată transparent, fără reconfigurări și întreruperea serverelor. Tot de ce este nevoie e ca pe switch-uri să se adauge VLAN-urile secundare după care să se modifice corespunzător configurația pe porturi. Nu se schimbă configurația IP nici pe servere nici pe echipamentul de rețea.

Rețea de backup

Chiar dacă un pic arhaică – mai ales pentru un mediu cu servere virtuale, arhitectura cu backup-ul serverelor inițiate de agenți instalați direct pe OS și cu trafic de backup împins printr-o rețea dedicată are totuși drept la viață. Într-o astfel de arhitectură, fiecare server are câte o conexiune în plus la rețea – una dedicată traficului de backup prin care agentul de backup transmite traficul de backup spre aplicația de backup. Pe partea de backup, toate serverele figurează ca făcând  parte dintr-o singură rețea de date. Evident că o așa arhitectură nu e tocmai securizată, paradoxal pe de-o parte serverele sunt organizate în subnet-uri protejate de firewall-uri iar pe de altă parte legate transparent într-o rețea mare de backup. Rețeaua de backup poate să devină mediul pentru propagarea unui atac pe servere – de exemplu de pe un server compromis într-o rețea pe un alt server dintr-o altă rețea; sau răspândirea virușilor s.a.m.d.

O soluție pentru securizarea rețelei de backup poate fi implementarea de PVLAN. Într-un PVLAN, serverele se vor conecta în porturi configurate pentru Secondary Isolated VLAN astfel încât să nu se observe unul pe celălalt iar serverul cu aplicația de backup se va conecta într-un port promiscous în așa fel încât să poată fi accesat de celelalte servere. Mai jos o ilustrare pentru o astfel de arhitectură.

PVLAN-part2-usecase-bkp&VDI

Rețea desktop-uri virtuale VDI

Pentru o securizare în plus se obișnuiește ca într-un VDI (mai ales pentru unul cu destinație publică ca de ex. desktop-urile virtuale dintr-o bibliotecă sau kiosk-urile din salile unui hotel) să se restricționeze comunicațiile între desktop-urile virtuale. Ca și în case-urile de mai sus, obiectivul se atinge simplu prin implementarea de PVLAN (btw supported pe switch-uri virtuale vSphere/Hyper-V) cu includerea desktop-urilor virtuale în VLAN-ul secundar izolat din PVLAN. 

Rețele Private VLAN (PVLAN) – part I

Recentele ore de teorie și laborator dedicate rețelelor Private VLAN m-au cam lăsat cu o groază de notiție pe care ca să nu le pierd în timp cred că am să le expun aici într-un nou articol. Acesta va include o introducere în rețele PVLAN, exemple de utilizare, condiții pentru switch-urile ce tranzitează VLAN-uri private și alte subiecte. Informațiile de aici vor prinde bine pentru un următor articol în care planific să descriu acțiunile din laboratorul dedicat rețelelor PVLAN realizat cu studenții claselor VMware.

Introducere în rețele Private VLAN (PVLAN)

Odată cu apariția VLAN-urilor a devenit posibilă segmentarea unui switch fizic pe mai multe switch-uri logice. Prin interconectarea switch-urilor fizice prin porturi de tip trunk aceleași VLAN-uri (switch-urile logice) pot deja acoperi mai multe switch-uri fizice. Un port trunk, la ieșire, va marca fiecare frame cu numărul VLAN-ului din care a pornit pachetul și la intrare va interpreta numărul VLAN-ului pentru a comuta corect frame-ul pe porturile din respectivul VLAN. Frame-urile pe un trunk 802.1q sunt marcate cu numărul VLAN-ului prin inserarea în header-ul de Ethernet a 4 octeți noi, din care 12 biți sunt rezervați pentru numărul VLAN-ului (VLAN ID). Cu 12 biți dedicați ID-ul VLAN-ului se pot defini până la 4094 de VLAN-uri (de fapt disponibile mai puține datorită câtorva VLAN-uri rezervate: 1,1001-1005). Fiecare VLAN reprezintă un domeniu de broadcast aparte și de regulă se asociază cu un singur subnet de rețea. VLAN-urile sunt complet izolate între ele. Comunicațiile între VLAN-uri pot fi asigurate prin dispozitive L3 cu interfețe în acele VLAN-uri. Introducerea VLAN-urilor simplifică mult topologia fizică a rețelei garantând funcționarea mai multor rețele logice pe același dispozitive fizice (switch) – e ca și cum ai consolida mai multe servere virtuale pe un host fizic doar că aici vorbim de mai multe rețele logice pe un singur switch fizic. Folosirea VLAN-urilor îmbunătățește scalabilitatea rețelei prin localizarea broadcast-ului în domenii de broadcast mai mici și ne oferă o izolare între acestea prin blocarea traficului L2 între VLAN-uri.

Cu toate beneficiile aduse de VLAN-urile tradiționale acestea suferă totuși de câteva neajunsuri:

  • scalabilitate redusă ca număr de VLAN-uri posibile (4094 din care mai trebuie de scos VLAN-urile rezervate).
  • complexitate rețea L3 – fiecare VLAN are nevoie pentru routing de câte o interfață pe un dispozitiv L3 fie el router, firewall sau interfață virtuală pe un switch L3.
  • risipă de adrese IP – pe fiecare subnet asociat cu un VLAN se vor pierde câte două adrese IP una pentru numărul și alta pentru broadcast-ul rețelei. Pe deasupra o adresa IP va fi rezervată pentru default gateway-ul subnet-ului.

Imaginați-vă un scenariu cu hosting de servere virtuale (VPS) în care fiecare client primește un VLAN separat pentru comunicații de rețea. E de înțeles că într-un așa caz numărul maxim de clienți va fi limitat la numărul de VLAN-uri disponibile (din cele 4094 minus câteva ID-uri rezervate mai trebuie scoase VLAN-urile pe care însuși hoster-ul și le-a rezervat, de exemplu pentru networking-ul de management, vMotion, FT ș.a.m.d așa ca numărul la drept vorbind e și mai mic). Sigur, există o problemă de scalabilitate în această abordare.

Rețelele Private VLAN vin să acopere o parte din aceste neajunsuri. Conceptul de Private VLAN se bazează pe ideea restricționării comunicațiilor la nivel de switch între porturi sau grupuri de porturi asociate cu unul din VLAN-urile existente dar care pot în același timp accesa nerestricționat un oarecare grup de porturi dedicat. În porturile restricționate se vor conecta nodurile protejate iar în cele nerestricționate se vor conecta interfețele unor dispozitive partajate în rețea, ca de exemplu interfața router-ului default gateway. Toate nodurile vor fi configurate ca făcând parte din același subnet IP. În așa fel, prin Private VLAN e posibilă o izolare la nivel L2 a dispozitivelor aflate în același subnet IP.

Funcționarea PVLAN-urilor se bazează pe segmentarea unui VLAN standard numit Primary Private VLAN în sub-VLAN-uri auxiliare Secondary Private VLANs. Acestea din urmă sunt posibile de două tipuri: Secondary Isolated Private VLAN și Secondary Community Private VLAN. Într-un Private VLAN pot exista doar un singur Isolated Private VLAN și unul sau mai multe Community Private VLANs. Porturile de acces sunt configurate fie direct în Primary VLAN fie în unul din sub-VLAN-urile secundare. Funcție de VLAN-ul asociat, un port acces în PVLAN poate fi: (a) promiscous port – configurat în Primary Private VLAN (b) isolated port – configurat în Isolated Private VLAN și (c) community port – configurat în unul din Community Private VLANs. Nodurile din VLAN-urile secundare pot comunica liber cu cele din VLAN-ul primar și sunt restricționate să comunice fie în grupuri (Community VLANs) fie  complet izolate între ele (Isolated VLAN).

Note: În documentația VMware, Primary Private VLAN mai este numit Promiscous Private VLAN.

Să analizăm un exemplu de rețea a cărei topologie este ilustrată mai jos: 

private VLANs - sample topology

Într-o rețea pe două switch-uri avem configurat un Private VLAN cu (a) Primary VLAN 5 (b) Isolated VLAN 155 și (c) un Community VLAN 17. Switch-urile au configurate porturi de acces pentru: (a) Primary VLAN – în care sunt conectate router-ul și serverul de backup (b) Isolated VLAN – ce are conectate 3x servere și (c) Community VLAN  17 – cu alte 3x servere. Fâșiile hașurate pot fi interpretate ca domenii de broadcast create de VLAN-urile secundare. Switch-urile sunt interconectate printr-un trunk 802.1q standard (în continuare vor urma mai multe detalii despre tranzitul de Private VLANs).

Pentru topologia și configurația descrisă mai sus:

  • router-ul și server-ul de backup din Primary VLAN 5 vor putea comunica cu toate serverele din VLAN-urile secundare (VLAN 17, 155).
  • serverele din Community VLAN  17 vor putea comunica între ele precum și cu router-ul și serverul de backup din Primary VLAN 5. Acestea nu vor putea însă accesa serverele conectate in Isolated VLAN 155.
  • serverele din Isolated VLAN 155 sunt restricționate să comunice doar cu router-ul și server-ul de backup.

Pe switch-uri pot fi create mai multe Private VLAN-uri. Un număr de sub-VLAN asociat cu un VLAN primar nu poate fi re-utilizat pe un alt VLAN primar. Comunicațiile în interiorul VLAN-ului primar rămân izolate de celelalte VLAN-uri definite pe switch.

Ca și altădată (vezi de ex. Explicație pentru vSwitch Security Policies) am încercat și acum să inventez un model prin care sa-mi explic cumva mai simplu fenomenele ce au loc într-un Private VLAN. Vedeți mai jos o ilustrație pentru modelul meu de Private VLANs. Avem aici drumuri și porți. Drumurile reprezintă căile pe care circulă frame-urile în interiorul switch-ului iar porțile sunt porturile pe switch. Fiecare drum reprezintă un VLAN dintr-un Private VLAN (VLAN-ul primar și cele secundare). Nu toate drumurile sunt la fel, unele sunt pe dublu sens – VLAN-ul primar și VLAN-ul community cu excepția segmentelor până la porțile promiscous, altele pe un singur sens – VLAN-ul izolat. În desen, drumul pentru VLAN-ul primar (5) este marcat cu albastru, cel pentru VLAN-ul izolat (155) marcat cu verde și cel pentru VLAN-ul community (17) marcat roșu. Drumurile au desenate marcaje care indică sensul mișcării, pe alocuri mai sunt și indicatoarele de circulație (observați la stânga pe segmentul de la portul community la portul promiscous). Porțile la rândul lor pot fi de unul din următoarele trei tipuri: community, isolated sau promiscous, corespunzător configurațiilor pentru porturile pe switch. În desen mai avem porți ce corespund porturilor trunk pe switch. Printre altele, schema din model transpune topologia din rețeaua discutată în exemplu de mai sus, aceleași tipuri și număr de porturi (porți).

private VLANs - PVLAN model

Modelul este guvernat de câteva reguli ce stabilesc modul de deplasare a frame-urilor:

  • fiecare tip de poartă folosește drumul lui pentru deplasarea dinspre port a frame-urilor. Astfel frame-urile dintr-un port community vor pleca întotdeauna pe drumul roșu (Community VLAN), frame-urile dintr-un port isolated vor pleca pe drumul verde (Isolated VLAN) și cele din promiscous pe drumul albastru (Primary VLAN).
  • porțile promiscous accepta intrarea frame-urile de pe toate trei drumuri
  • porțile community accepta intrarea frame-urilor de pe drumurile promiscous și isolated
  • porțile isolated accepta intrarea frame-urilor doar de pe drumul promiscous.
  • prin porțile trunk trec toate trei drumuri și toate sunt dublu-sens.

Să încercăm acum să deducem din model traseele parcurse de frame-uri pentru câteva conversații de rețea în cadrul respectivul Private VLAN:

  • dintre un nod conectat într-un port community pe un switch la un nod într-un port promiscous pe alt switch. Pe direcția dinspre community spre promiscous frame-urile își vor începe traseul pe drumul roșu marcate fiind cu Community VLAN 17 după care vor trece prin porturile trunk de pe un switch pe alt switch după care în final vor ajunge pe portul promiscous. Pe direcția opusă, frame-urile vor părăsi portul promiscous pe drumul albastru marcate cu Promiscous VLAN 5, după care vor trece prin porturile trunk de pe un switch pe alt switch, după care vor ajunge pe portul community.
  • dintre un nod conectat într-un port community pe un switch pe  un nod conectat pe un port în același community. Pe ambele direcții, frame-urile vor circula pe același drum roșu, marcate fiind cu Community VLAN 17, își vor începe traseul de la un port community după care vor trece peste porturile trunk și se vor încheia într-un alt port community.
  • dintre un nod conectat într-un port isolated pe un switch la un nod conectat pe alt switch într-un port promiscous. Pe direcția dinspre isolated spre promiscous frame-ul va porni pe drumul verde, marcat cu Isolated VLAN 155 după care va trece peste porturile trunk pe celălalt switch și își va încheia traseul în portul promiscous destinație. Pe calea întoarsă, frame-ul va porni pe drumul albastru, macat cu Primary VLAN 5 după care va trece peste porturile trunk și își va încheia traseul pe portul isolated destinație.
  • nu sunt posibile căile între porturi community și porturi isolated și nici între porturi din același VLAN isolated, pur si simplu traseul și sensul drumurilor nu permit (vezi în desen).

Pun aici punct că mi se primește prea lung textul. În următoarele părți vom analiza exemple tipice de utilizare PVLAN, condiții impuse switch-urilor ce tranzitează VLAN private, tipuri de porturi PVLAN trunk.

Configurare vCenter și nested ESXi în lab (part II)

În prima parte a articolului am descris pas cu pas procedura pentru instalarea și configurarea server-ului vCenter pentru o configurație tipică de laborator. În partea a doua am să continui cu instalarea a două host-uri ESXi nested. Lista de activități va include: instalarea și configurarea inițială a două host-uri ESXi nested; actualizarea imaginilor ESXi până la ultimul update disponibil; instalarea VMware Tools for nested ESXi; înregistrare host-uri ESXi nested în inventarul server-ului vCenter.

Instalare și configurare host-uri ESXi nested

Scenariul de laborator – descris pe scurt in prima parte a articolului, presupune crearea a două host-uri ESXi nested care, împreună cu server-ul vCenter instalat anterior, pot fi folosite ulterior ca și platformă pentru alte scenarii de laborator. Pe o așa configurație se pot încerca teste de la cele mai simple, gen vMotion, clustere HA și DRS, dvSwitch s.a.m.d, până la construcții complexe cu multiple produse VMware: vSphere Data Protection, vSphere Replication ș.a.m.d, limita fiind doar în imaginație.

Așadar, în cele ce urmează vom merge pe următorul workflow:

  • creăm un VM cu caracteristici potrivite pentru un host ESXi nested
  • instalăm o imagine fresh de ESXi 5.5 pe VM-ul preparat anterior
  • aplicăm o configurație de bază pentru host-ul ESXi nested
  • actualizăm imaginea ESXi până la ultimul update disponibil.
  • instalăm pachetul VMware Tools for Nested ESXi
  • înregistrăm host-ul ESXi nested în inventarul server-ului vCenter
  • se repetă punctele de mai sus și pentru un al doilea host ESXi nested.

Creare VM ca gazdă pentru un host ESXi 5.5 nested.

Pentru ca o mașină virtuală să poată să găzduiască cu succes un host ESXi nested va trebui ca aceasta să corespundă unei configurații specifice: pe deoparte să dețină un minim de resurse hardware 4GB RAM/2x vCPU necesare pornirii ESXi-ului nested și pe de altă parte să aibă activat mecanismul de virtualizare a funcției de virtualizare hardware (VHV). Fără de ultima va fi practic imposibil de rulat VM-uri nested de 64 de biți peste host-ul ESXi nested.  

  • inițiem procesul pentru crearea unui VM nou. Pentru aceasta, din vSphere Client conectat la server-ul vCenter din laboratorul DNT – atenție nu la cel din scenariu, click dreapta pe containerul vAPP legat de student – Create New Virtual Machine. Încercarea de a crea VM-ul într-un alt vAPP decât cel asociat va eșua din lipsa de drepturi – fiecare student poate crea/gestiona VM-uri doar în contextul containerului cu care a fost asociat.
  • în wizard-ul pornit (a) pe pagina Configuration se alege varianta Custom (b) în Name and Location se specifică un nume pentru VM, nu e obligatoriu dar e bine de ținut cont de recomandarea de nume pentru VM-uri in lab: numele VM-urilor trebuie să pornească POD-0X- unde X numărul POD-ului urmat de un scurt string ce ar reflecta destinația VM-ului. În cazul meu am folosit titlurile POD-02-ESXi-01 și POD-02-ESXi-02 pentru primul și respectiv pentru al doilea host ESXi nested (c) la faza cu storage se selectează datastore-ul RAID10-store – până când unicul disponibil (d) în Virtual Machine Version se lasă pe opțiunea sugerată: Virtual Machine Version 8 (e) pe pagina Guest Operating System pentru OS se bifează Others și pentru versiune se selectează Other (64-bit). Dacă se dorește se poate completa câmpul cu descriere, exemplu VMware. Se observă că dropdown-ul cu OS-uri nu ne oferă o opțiune pentru nested ESXi, e și de înțeles, lista conține doar OS-urile supported de VMware or configurațiile cu nested ESXi nu sunt suportate în producție ele fiind adecvate doar în scenarii de laborator (f) pe pagina cu CPUs se asigură un minim de două procesoare virtuale – fie ca core-uri într-un socket fie ca socket-uri aparte (g) în Memory se alocă un spațiu de RAM pentru ESXi-ul nested. Atenție nu mai puțin de 4GB. În cazul meu am folosit 8GB RAM. Poate fi schimbat mai târziu (h) la Network, configurăm un număr de NIC-uri virtuale, poate fi unul sau mai multe, eu am ales 4x. Se configurează fiecare NIC ca conectat în grupul de porturi dvPortGroup-STUDENTS pe switch-ul distribuit dvSwitch-LAB. Atenție, procesul de creare a VM-ului va eșua în caz că se alege un alt grup de porturi decât cel menționat – studenții sunt admiși să folosească doar acel grup de porturi. Tipul adaptorului se lasă E1000 sugerat implicit (k) pe pagina cu SCSI Controller, se lasă pe implicitul LSI Logic Parallel  (l) în Select a disk se alege opțiunea pentru crearea unui disk virtual nou, după care pe pagina următoare se specifică: i. capacitatea disk-ului virtual – un 80 GB suficient pentru început, se poate de redimensionat mai târziu, ii. modul de alocare a spațiului, obligatoriu în Thin Provision – atenție, implicit se propune opțiunea cu Thick Provision Lazy Zeroed care e cel mai lacom mod ca spațiu consumat or spațiul pe LAB e cam limitat. Dacă ați creat un VM cu un așa disk, distrugeți disk-ul inițial și recreați-l din nou dar deja în formatul Thin (m) restul paginilor se trec pe valori implicite. Vedeți mai jos un screen cu câteva fragmente din configurația VM-ului destinat host-ului ESXi nested:

config_vCenter_neste_ESXi_part_II_create_VM_for_nested_ESXi

  • modificăm Guest OS-ul din VM. Pentru acesta din proprietățile VM-ului, pe pagina Options, în General Options – Guest Operating System deschidem lista cu OS-uri din care selectăm valoarea cu VMware ESXi 5.x (în versiuni precedente titlul mai includea cuvântul experimental). Lista respectivă, spre deosebire de cea din wizard-ul de creare a VM-urilor include și OS-uri unsupported de VMware. Unsupported nu neapărat înseamnă că nu funcționează, pur si simplu pentru acestea VMware nu dă nici un fel de garanții.
  • upgradăm VM-ul de la versiunea 8 la versiunea 10. Anterior, în wizard, versiunea maximă posibilă de selectat a fost 8 fiind o limită de GUI nu și de maxim pe host-ul ESXi. Începând cu 5.0, VMware nu mai dezvoltă client-ul vSphere Client (C#) concentrându-și toată atenția doar pe vSphere WEB Cilent, de aceea tot ce ține de funcții și opțiuni în versiunile noi vSphere nu mai sunt incluse in clientul vechi inclusiv și numere noi de versiuni de VM-uri (9 pentru 5.1, 10 pentru 5.5). Note: Dacă wizard-ul pentru crearea VM-ului era să fie inițiat din clientul WEB atunci versiunea VM-ului se putea selecta din start pe 10 așa că punctul curent nu mai era nevoie de executat. Totuși, dacă ați pornit-o in vSphere Client, upgrade-ul pentru VM se poate de făcut printr-un click dreapta pe VM după care Upgrade Virtual Hardware. Versiunea noua a VM-ului poate fi verificată în VM version pe pagina Summary a VM-ului și ar trebui să coincidă cu vmx-10. De menționat, că după upgradarea VM-ului la ultima versiune, editarea proprietăților acestuia va fi posibilă doar din clientul WEB.
  • activăm mecanismul virtualizării funcției de virtualizare hardware (VHV). De menționat că aceasta va fi posibil doar dacă s-au executat corect precedentele două puncte (guest OS in VMware ESXi 5.x și Virtual Machine version in vmx-10), în caz contrar opțiunea din GUI de activare a mecanismului va fi marcată ca inactivă. Pentru a activa VHV-ul se poate de mers pe una din două căi: (a) fie prin adăugarea în fișierului de configurare a VM-ului a secvenței vhv.enable=”true”  – destul de complex dar și imposibil cu privilegiile pe LAB a studenților (b) fie prin WEB Client, recomandat. Pentru Web Client, se deschide proprietățile VM-ului cu Edit Virtual Machine Settings după care din Virtual Hardware – CPU se bifează parametrul: Hardware Virtualization – Expose hardware assisted virtualization to the guest OS.

​Instalare imagine ESXi 5.5 în VM-ul destinat host-ului ESXi nested.

În continuare vom instala o imagine ESXi 5.5 pe VM-ul creat anterior pentru host-ul ESXi nested.

  • montăm ISO-ul cu setup-ul pentru VMware ESXi. Pentru aceasta, din vSphere WEB Client deschidem proprietățile VM-ului, trecem pe secțiunea Virtual Hardware, unde în CD/DVD drive 1 specificăm Datastore ISO File. În fereastra Select File alegem fișierul: VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso, folder: RAID10-Store\ISO. Pentru comoditate iso-ul setup-ului a fost încărcat din timp pe datastore-ul din LAB, e posibil să nu fie tocmai ultimul build așa că dacă se dorește se poate de descărcat un iso mai nou pe pagina de download VMware (aveți nevoie de un simplu cont pe site). Note: Am ales să montăm ISO-ul din vSphere WEB Client din simplu motivă că după upgrade-ul de versiune a mașinii virtuale proprietățile acesteia pot fi modificate deja doar prin WEB Client și deloc prin vSphere Client.
  • se pornește VM-ul, fie din WEB Client fie din vSphere Client. Se lasă să pornească procesul de setup pentru ESXi (fereastră cu sur pe galben și progress bar)
  • în continuare se parcurge wizard-ul pentru instalare ESXi: (a) pe pagina Welcome .. click pe Enter (Continue) (b) în EULA click pe (F11) Accept and Continue (c) în Select a Disk to Install or Upgrade mergem de acord cu unica opțiune: disk-ul virtual de 80GB creat anterior – spațiul de stocare va fi folosit atât pentru ESXi-ul propriu-zis cât și ca datastore VMFS pentru VM-uri nested pe acest ESXi (d) în keyboard layout click (Enter) Continue cu US default (e) pe pagina Enter a root password specificăm o parola cu confirmare pentru root-ul ESXi. Urmează un proces automat cu reboot pe final – câteva minute.

Configurare inițială pentru ESXi-ul  nested

Vom continua prin a aplica o configurație de bază pe host-ul ESXi nested. Vom re-configura ESXi nested din consola VM-ului ce îl găzduiește accesând Direct Console User Interface (DCUI).

  • ne autentificam pe consola DCUI ESXi . Pentru asta, din consola VM-ului care ar trebui să afișeze pagina de standby DCUI (sur pe galben) se apasă pe <F2> Customize System/View Logs care schimbă view-ul pe un dialog pentru introducerea credențialelor pentru autentificare. Se introduce username-ul root și password-ul lui (setat la faza de instalare ESXi).
  • în System Customization se trece pe Configure Management Network unde vom configura: (a) în Network Adapters vom bifa toate adaptoarele disponibile – anterior am configurat pe VM patru vmnic-uri vmnic0-3. Toate adaptoarele vor face parte din vSwitch0 și vor participa in team pentru interfața de management vmk0 ESXi (b) în IP Configuration se trece de pe configurația cu DHCP implicit, pe configurație cu parametri setați manual: Set static IP address and network configuration. Setăm o adresă IP din intervalul recomandat pentru numărul POD-ului și o mască de rețea de 16 biți, în cazul meu am folosit IP-ul: 172.16.22.41(.42 pentru al doilea host ESXi), Subnet Mask: 255.255.0.0. In general studentul e liber să folosească orice adrese IP pe care le consideră potrivite, condiția e doar ca să nu coincidă cu ceva deja setat pe LAB (c) în IPv6 Configuration deconectăm stack-ul IPv6 prin de-bifarea: Enable IPv6 .. – implicit bifat (d) în DNS Configuration setăm drept server DNS IP-ului server-ul vCenter din LAB – care a fost configurat și ca server DNS. În câmpul Hostname specificăm un nume pentru ESXi – care pentru simplitate poate să coincidă cu numele VM-ului, în cazul meu: pod-02-esxi-01 (e) în Custom DNS Suffixes formăm numele zonei DNS setate pe serverul DNS (vCenter), in cazul meu: lab.local. Aplicam configurațiile de mai sus prin abandonarea meniului cu Management Network. Mai mult ca sigur se va propune reboot-area host-ului ESXi, se confirmă dialogul după care host-ul pleacă automat in reboot.
  • între timp, se configurează o înregistrare A NAME pe serverul DNS corespunzătoare numelui host-ului ESXi. Pentru aceasta, pe serverul DNS (vCenter) se deschide consola serverului DNS: DNS Manager. De aici, click dreapta pe zona lab.localNew Host (A or AAAA). În fereastra New Host se specifică hostname-ul ESXi-ului și adresa IP ce-i corespunde: pod-02.esxi-01 și respectiv 172.16.22.41. Se asigură că bifată opțiunea Create associated pointer (PTR) record.
  • e bine ca după restart-ul ESXi-ului de făcut un test de networking pe acesta. Pentru asta, din DCUI se accesează System CustomizationTest Management Network. Implicit se încearcă ping-ul pe adresa IP a server-ului DNS (ping address #0) și rezoluția numelui hostname (resolve hostname) plus ping pe acel IP (IP-ul ESXi-ului). În Resolve Hostname completăm hostname-ul până la FQDN astfel încât să includă și sufixul DNS. Note: primul ping va eșua pentru că pe server-ul DNS (vCenter) funcționează firewall-ul din Windows care implicit blochează ICMP-ului, dacă se dorește, se poate de permis ICMP-ul prin activarea (enable) a regulilor File and Printer Sharing (Echo Request .. )

config_vCenter_neste_ESXi_part_II_configure_ESXi

Actualizare imagine ESXi până la ultimul update disponibil

Chiar dacă va fi folosit într-un mediu de test e bine totuși ca și ESXi-ul din lab să fie actualizat up-to-date. În cele ce urmează vom aplica peste imaginea existentă ESXi ultimele update-uri disponibile pe depot-ul de download VMware folosind linia de comandă și accesând Internet-ul peste server-ul proxy din LAB.

  • configurăm accesul la linia de comandă CLI. CLI-ul îl vom accesa peste SSH așa că va trebuie pentru început de activat SSH-ul pe host-ul ESXi. Pentru aceasta, ne conectăm cu vSphere Client pe IP-ul host-ului ESXi nested (172.16.22.41), atenție nu IP-ul vCenter-ului din LAB sau din POD dar pe ESXi-ul instalat în p. precedent. Folosim credențialele root-ului. Odată autentificați, accesăm Configuration – Security Profile (software) – Services – Properties. În fereastra Service Properties facem click pe SSH (implicit e in statut Stopped) după care pe butonul Options (stânga jos). În ESXi Shell (TSM) Options click pe Start Ok.
  • deschidem consola ESXi prin SSH. Din clientul preferat SSH (recomandat putty.exe) deschidem o sesiune pe IP-ul host-ului ESXi (172.16.22.41). Client-ul SSH poate fi pornit din orice loc din lab de unde aste acces pe IP la ESXi-ul nested, exemplu din VM-ul cu Win7 din POD-ul studentului. Pentru autentificare prezentăm credențialele root-ului.
  • verificăm versiunea curentă pentru imaginea ESXi (build number). O putem face prin două căi: fie prin vSphere Client conectat la host-ul ESXi (pe ribon deasupra tab-urilor), fie prin CLI cu esxcli system version get. În cazul meu, am pornit cu un build ESXi de 2068190 ce corespunde imaginii: VMware ESXi 5.5 Update 2 (pentru un lookup build_number-to-version puteți folosi de exemplu lista de aici).

config_vCenter_neste_ESXi_part_II_update_ESXi_get_verssion

  • pachetele de actualizări le vom descărca direct de pe depot-ul de download VMware din Internet așa că în comenzile din CLI va trebui de specificat în plus la adresa depot-ului și detaliile serverului http proxy. In LAB, Internet-ul îl accesăm prin server-ul proxy aflat pe IP-ul 172.16.0.39 și folosind port-ul 8080. Atenție, în caz că folosiți procedura de mai jos pentru un alt sistem decât LAB-ul și accesați Internet-ul printr-un proxy ce funcționează pe un alt port decât 8080 atunci, suplimentar, veți trebui să adăugați o regulă în plus pe firewall-ul ESXi. Adevărul e că ESXi-ul își are un firewall al lui, care implicit blochează majoritatea porturilor de comunicații lăsând deschise doar anumite porturi specifice serviciilor de ESXi. Din fericire, port-ul folosit de proxy-ul din LAB: 8080, e deschis cu una din regulile existente de firewall (regula pentru serviciul vsanvp) așa că nu mai e nevoie de manipulări în plus pe acest subiect. Pentru mai multe detalii legate de reguli de firewall custom pe ESXi vă recomand să consultați KB 2008226. În caz că accesați Internet-ul peste NAT veți trebui să porniți una din regulile de firewall deja existente – implicit oprită: httpClient (outgoing 80,443) – o puteți face fie din CLI (esxcli network firewall ruleset set -e true -r httpClient) fie din vSphere Cilent (Security Profile – Firewall – Properties – check httpClient). Încă odată, în LAB nu avem nevoie de modificări în plus pe firewall-ul ESXi.
  • așa cum ESXi-ul nested are configurat server-ul vCenter ca server DNS, care la rândul lui este unul izolat de DNS-ul zonelor din Internet, rezultă că ne va fi imposibil să avem o rezoluție cu succes pentru host-uri din Internet. În general, prin rețeaua din LAB izolată, practic devine imposibil de soluționat host-uri pentru zone din Internet. Ce este interesant totuși, dintr-un browser setat cu http proxy rezoluția de nume are loc cumva prin proxy și nu tradițional cu request-uri pe IP-ul serverului DNS (setat in tcp/ip settings), dar asta nu funcționează și pentru CLI-ul ESXi așa că în acest caz va trebui să aplicăm un workaround. Vom crea pe DNS (vCenter) o zona cu numele vmware.com în care vom crea o înregistrare A Name cu numele hostupdate legată de unul din IP-urile reale de Internet. IP-urile le aflăm de pe un PC cu acces la Internet prin nslookup pentru FQDN-ul hostupdate.vmware.com. Mie mi-a dat IP-ul: 23.40.163.43, dar fiți atenți că acesta se poate schimba așa că e bine ca de fiecare dată se verificați valorile. Pentru a crea o zonă pe server-ul DNS deschideți consola serviciului DNS (pe server-ul vCenter) după care în forward lookup zone porniți wizard-ul pentru crearea unei noi zone (vmware.com). După ce ați creat zona, adăugați în aceasta o înregistrare pentru hostupdate cu IP-ul aflat mai sus. Pe final, verificați cu nslookup rezoluția pentru FQDN-ul hostupdate.vmware.com pornit direct pe server-ul vCenter (cel din POD-ul vostru).
  • executăm următoarea comandă ESXCLI pentru a verifica lista de actualizări disponibile in depot-ul VMware pe Internet: 

note 1: pe output-ul comenzii am aplicat un filtru cu grep pentru a scoate în evidență ultimele bundle-uri de actualizări disponibile pentru versiunea 5.5 de ESXi. În titlul bundle-ului după cratimă după versiunea ESXi urmează release date-ul codat in forma YYYYMM.. așa că indicând in argument-ul grep-ului anul si luna se poate de îngustat output-ul până la ultimele actualizări. Fără filtru, comanda va afișa o listă lungă de bundle-uri pentru toată perioada și pentru toate versiunile ESXi 5.x – listă greu de interpretat.

note 2: bundle-urile de update sunt cumulative așa că pentru a actualiza un host până la ultima versiune va fi suficient de aplicat doar ultimul bundle de update. Nu e deloc nevoie de aplicat update-uri consecutive pentru a ajunge la ultima versiune pentru imaginea ESXi.

config_vCenter_neste_ESXi_part_II_update_ESXi_get_update_bundles

Din lista de bundle-uri de update disponibile la momentul întocmirii articolului, ultimele update-uri sunt cele care încep cu: ESXi-5.5.0-20150402001-xx. Din acestea (două), vom alege pe cel cu sufixul standard ca fiind complet (include toate actualizările inclusiv vmware-tools). 

  • executăm următoarea comandă ESXCLI pentru a aplica pe imaginea ESXi bundle-ul de update selectat:

odată pornită, comanda poate să dureze până se execută și poate crea impresia că e blocată așa că înarmați-vă cu puțină răbdare și așteptați un răspuns pe consolă. Vedeți mai jos, replay-ul pentru o execuție reușită a comenzii, din output am scos o parte din lista ce ne afișează numărul de VIB-uri ce nu au fost atinse de update (destul de lungă). 

config_vCenter_neste_ESXi_part_II_update_ESXi_apply_update_bundles

  • reboot-ăm host-ul ESXi fie din CLI cu comanda reboot fie din vSphere Client. După reboot, verificăm încă odată versiunea imaginii ESXi, fie din lina de comandă cu esxcli system version get fie cu vSphere Client: 

config_vCenter_neste_ESXi_part_II_update_ESXi_version_check_after_update

se observă că avem deja un build number superior celui de până la update (2638301 vs 2068190) care e ultimul la momentul întocmirii articolului.

De remarcat că procedura de actualizare a unui host ESXi poate fi realizată și fără acces direct la Internet. Pentru aceasta se descarcă în prealabil a bundle-ul de update de pe portalul de download VMware după care se încarcă pe unul din datastore-urile ESXi-ului. În linia de comandă, ca argument la ESXCLI-ul de update se va specifica drept depot path-ul pe datastore. Pentru detalii cum de făcut asta  puteți consulta articolul (vladan – how to patch free vmware esxi). Este la discreția voastră cu ce metodă să mergeți, ambele funcționează.

Instalare pachet VMware Tools for Nested ESXi

Deloc obligatoriu dar totuși recomandabil, este ideea de a instala pachetul VMware Tools for Nested ESXi pe imaginea host-ului ESXi nested. După install, acesta vine ca un pachet VIB încadrat în image profile-ul ESXi. Prin VMware Tools for Nested ESXi vom putea: (a) obține informații despre OS-ul ESXi-ului nested direct pe ESXi-ul ce-l găzduiește (adresa IP, hostname .. ) – se vor citi cu vSphere Client/WEB Client în summary pentru VM-ul cu nested ESXi și (b) deconecta/restarta corect ESXi-ul nested cu comenzi shut down guest/restart guest din ESXi-ul ce-l găzduiește. Pentru mai multe detalii verificați referințele aici și aici. Trebuie de menționat că în versiunea 6.0 de ESXi VIB-ul pentru VMware Tools for Nested ESXi face parte deja ca implicit din image profile-ului ESXi așa că dacă încercați 6.0 atunci pasul ăsta este ca și cum exectutat.

  • pentru a instala VMware Tools for Nested ESXi vom folosi linia de comandă. VIB-ul îl vom descărca din Internet odată cu executarea comenzii de install prin specificarea în argumente a adresei depot-ului de download. Ca și în cazul cu actualizarea imaginii ESXi va trebui de adăugat pe DNS o înregistrare A Name pentru host-ul download3.vmware.com și IP-ul de Internet ce-i corespunde – la momentul întocmirii articolului acesta a fost: 23.64.211.51. Despre cum de creat o înregistrare pe DNS vedeți mai sus textul cu actualizarea ESXi-ului.
  • din CLI, executăm următoarea comandă ESXCLI pentru a instala VIB-ul cu VMware Tools for Nested ESXi

Note: versiunea curentă pentru VMware Tools for Nested ESXi este de 9.7.1 dar se poate schimba în timp așa că înainte de a porni comanda de install verificați pe site-ul proiectului (aici) în instructions numărul ultimei versiuni și corectați corespunzător link-ul de download.

config_vCenter_neste_ESXi_part_II_install_vmware_tools_for_nested_esxi

se rebotează host-ul ESXi nested, după care se verifică statutul VMware tools din vSphere Client conectat la vCenter-ul din LAB și focusat pe VM-ul cu ESXi nested: 

config_vCenter_neste_ESXi_part_II_vmware_tools_for_nested_esxi_status

Înregistram host-ul ESXi nested în inventarul server-ului vCenter

Acum că avem vCenter-ul și unul din host-urile ESXi nested instalate și configurate putem să înregistrăm ESXi-ul pe vCenter. Pentru aceasta, din vSphere Client conectat la server-ul vCenter (din POD-ul studentului) în inventar se face click dreapta pe numele datacenter-ului (acesta se creează în prealabil) după care se alege Add Host … În wizard-ul pornit, (a) pe pagina Connection Settings în Host specificăm FQDN-ul pentru host-ul ESXi nested: pod-02-esxi-01.lab.local precum și credențialele pentru root. După Next va apărea un dialog pentru confirmarea certificatului, click Yes. (b) restul pașilor din wizard se parcurg cu valori implicite (no license/no lockdown mode).

Instalarea și configurarea unui al doilea host ESXi nested

Așa cum scenariul presupune prezența a două host-uri ESXi nested, se vor parcurge pașii descriși pentru primul ESXi și pentru un al doilea ESXi nested. Diferențele vor fi doar in hostname și adresă IP de management, care în cazul meu vor fi pod-02-esxi-02 și respectiv 172.16.22.42.

Cu asta închei partea a doua și finală a articolului pentru configurarea componentelor dintr-un prim scenariu de laborator recomandat studenților claselor de VMware realizat pe platforma de laborator DNT.

Configurare vCenter și nested ESXi în lab (part I)

Ca să continui cu subiectul platformei de laborator VMware (început aici, aici și aici) am să încerc în cele ce urmează să descriu pas cu pas configurarea componentelor dintr-un prim scenariu de laborator. Scenariul presupune instalarea a două host-uri ESXi nested și a unui server vCenter. Conținutului articolului am sa-l organizez pe două parți: în prima parte am să descriu instalarea și configurarea server-ului vCenter și a doua va fi dedicată configurării host-urilor ESXi nested.

Dacă e să generalizez, atunci ceea ce vom avea de făcut va fi să:

  • instalăm de la zero un server vCenter Server 5.5 pe Windows și ca să nu risipim resurse vom folosi același VM și ca server DNS (necesar pentru un setup corect de vCenter).
  • instalăm două host-uri ESXi nested (ca VM-uri in lab) cu o configurație potrivită pentru networking-ul din mediul de laborator.
  • actualizăm imaginile pe host-urile ESXi nested până la ultimul update disponibil.
  • instalăm pe hosturile ESXi nested pachetul cu VMware Tools for nested ESXi.
  • înregistrăm host-urile ESXi nested pe server-ul vCenter instalat anterior.

Pentru o reprezentarea grafică vedeți desenul de mai jos:

config_vCenter_neste_ESXi_part_I_general

Instalare și configurare server vCenter Server

În scenariul de laborator vom instala și configura un server vCenter bazat pe Windows. Sigur, e posibil de încercat și varianta pe Linux: vCSA. Pentru exemplu, totuși, am ales varianta pe Windows pentru că ne oferă mai multă granularitate la instalare și parcă e mai didactic așa. Pe același VM cu serverul vCenter vom configura in prealabil rolul de server DNS. Vom avea nevoie de DNS până a începe install-ul server-ului vCenter, ultimul având nevoie de DNS pentru un setup corect, mai multe detalii urmează. Pentru a nu pierde timpul pe instalarea de la zero a sistemului de operare Windows Server vom folosi o imagine template pre-instalată din timp.

Mai jos va urma procedura pentru instalarea și configurarea serverului vCenter in LAB. Pașii din descriere au fost executați pe viu folosind un utilizator cu privilegii identice ca a unui student cu acces standard la mediul de laborator. Prin aceasta am mai verificat odată setările pentru drepturi de acces la mediul de laborator. VM-urile le-am găzduit in POD-02. 

  • desfășurăm un VM cu Windows Server folosind unul din template-urile pre-instalate. Pentru acesta, din vSphere Client conectat la server-ul vCenter de laborator (172.16.0.4) accesăm view-ul VMs and Templates. În folder-ul TEMPLATES click dreapta pe template-ul LAB-Win2k12r2-TEMPLATE. Pornim wizard-ul de setup prin Deploy Virtual Machine from this Template. În wizard vom specifica: (a) în Name and Location numele VM-ului, care ca recomandare e bine să corespundă convenției de nume deja discutate – prefixul POD-0X urmat de un string ce reflecta destinația funcțională a VM-ului: Name: POD-02-vCenter-01 (b) în Host and Cluster selectăm LAB-Cluster (c) în Resource Pool selectăm containerul alocat: STD-POD-A02 – fiecare student are asociat un POD și doar în acesta are dreptul să creeze/gestioneze VM-uri (d) în Storage ne asigurăm încă odată ca avem o alocare pentru disk-ul virtual de tip Thin Provisioning – implicit se selectează Same format as source care pentru template-ul respectiv înseamnă Thin dar ca deprindere e bine totuși de arătat în mod evident formatul. Ca destinație de stocare nu avem altă opțiune decât unicul datastore Raid10-Store (e) în Guest Customization se lasă implicit pe Do not customize (f) în Ready to Complete verificăm încă odată opțiunile alese, confirmăm cu Finish. E bine aici de bifat Edit virtual hardware pentru a accesa fereastra cu proprietățile VM-ului (până la desfășurarea template-ului).
  • ajustăm configurația VM-ului, verificăm ca viitorul VM să aibă asigurate cel puțin următoarele resurse hardware: (a) 2x vCPU (b) 8192 MB RAM. Template-ul, implicit, va crea un VM cu 2x vCPU-uri și 12GB RAM. Confirmăm proprietățile VM-ului, după care automat pornește procesul de desfășurare a template-ului. Procesul poate să dureze mai multe minute – la mine a durat aproape 4 min. Un timp foarte bun dacă e să compar cu cât timp era să pierdem dacă instalam tradițional OS-ul.
  • configuram network-ul destinație pentru VM. Pentru aceasta cu Edit SettingsNetwork Adapter – Network Connect selectăm dvPortgroup-STUDENTS (dvSwitch-LAB ca rețea destinație. Implicit, template-ul creează un VM detașat de rețea.
  • pornim VM-ul după care urmărim în consolă procesul de inițializare a sistemului de operare. În fereastra de autentificare folosim user-ul Administrator cu parola standard asdfgh1!
  • odată autentificați pe server executăm următoarele configurații în OS: (a) adresă IP care trebuie să corespundă spațiului de adrese recomandat 172.16.2X.0/24 unde X e numărului POD-ului, în exemplu am folosit IP-ul 172.16.22.20/16. Atenție, folosiți o mască de 16 biți (cea sugerată la formarea adresei IP). Nu se mai configurează nimic altceva, nici default gateway nici servere DNS. Verificăm conexiunea de rețea cu un ping la server-ul proxy 172.16.0.39. (b) in Internet Options – LAN Settings specificăm adresa IP și port-ul pentru server-ul Proxy: 172.16.0.39, tot aici, obligatoriu, bifăm: bypass proxy server for local address și în excepții prin advanced specificam wildcard-ul 172.16.*.* (c) redenumim Computer Name în așa fel încât ca să coincidă cu numele VM-ului: POD-02-vCenter-01. Restart Guest OS. (d) dacă se insistă se poate și de verificat/aplicat ultimele actualizări pentru OS.

Pentru a realiza un install corect și complet pentru serverul vCenter vom avea nevoie de o infrastructură DNS funcțională. DNS-ul ar trebui să dețină în forward lookup zone și reverse lookup zone înregistrări cu hostname-ul (FQDN) și IP-ul server-ului vCenter. Deși setup-ul pentru cazul când DNS-ul lipsește se limitează doar la câteva warrning-uri lăsând ca procesul în ansamblu să se încheie cu succes, recomandarea generală este totuși în a avea un DNS configurat corespunzător. Afirmații despre requirements-ul pentru DNS le găsim în documentația pentru vCenter (VMware vSphere Documentation Center): DNS Requirements for vSphere (link)

Ensure that the vCenter Server is installed on a machine that has a resolvable fully qualified domain name (FQDN). To check that the FQDN is resolvable, type nslookup your_vCenter_Server_fqdn at a command line prompt. ….  Ensure that DNS reverse lookup returns a fully qualified domain name when queried with the IP address of the vCenter Server.

Pentru a acoperi această cerință vom implementa un server DNS care pentru economie de resurse îl vom instala pe VM-ul cu server vCenter. Cel mai probabil așa configurație nu e supported pentru un setup în producție, dar pentru un mediu de laborator e mai mult ca ok. Cum se face asta pentru un server vCenter pe Linux verificați link-ul. Pentru Windows puteți urma următoarea procedură: 

  • pe VM-ul destinat vCenter-ului instalăm rolul de DNS Server. Pentru asta, din Server Manager click pe Manage – Add Roles and Feature, în wizard selectăm: DNS Server. Parcurgem restul paginilor din Wizard pe default. Așteptăm ca install-ul să finalizeze.
  • vom configura server-ul DNS ca responsabil de o zona DNS la alegere – în exemplu am ales zona lab.local. Pentru aceasta, deschidem DNS Manager în ierarhie, click dreapta pe Forward Lookup Zone – New Zone. În wizard de crearea a zonei specificăm: (a) zone type: primary (b) zone name: lab.local (c) restul pașilor se lasă cu opțiunile implicite.
  • fără a închide consola DNS-ului se inițiază crearea unei zone reverse lookup, pentru acesta click dreapta pe reverse lookup zone – New Zone, în wizard vom specifica: (a) zone type: primary (b) IPv4 Reverse Lookup Zone (c) în Network ID indicăm network ID-ul pentru subnet-ul rezervat lab-ului: 172.16.22.0. (d) restul pașilor se lasă cu opțiunile implicite.
  • configurăm lab.local ca și sufix DNS pentru conexiunea de rețea a server-ului vCenter. Pentru acesta, din TCP/IP settings pe conexiunea de rețea, în Advanced Settings – DNS în căsuța DNS suffix for this connection indicăm numele lab.local.
  • în Use the following DNS server addresses, specificăm 127.0.0.1 (loopback) ca Preferred DNS server.
  • din consola server-ului DNS, inițiem crearea unei înregistrări noi de tip CNAME în zona lab.local. În fereastra deschisă, în câmpul Name specificăm hostname-ul server-ului vCenter: POD-02-vCenter-01 și în IP address adresa IP: 172.16.22.20. Se asigură că bifa Create associated point (PTR) record este setată – parametru va asigura crearea automată a unei înregistrări în reverse lookup zone.
  • se verifică setările DNS. Pentru aceasta, din linia de comandă se pornește utilitarul nslookup în care se solicită consecutiv rezoluția de nume pentru FQDN la serverul vCenter: POD-02-vCenter-01.lab.local și rezoluția reverse pentru IP-ul server-ului vCenter: 172.16.22.20. Ambele rezoluții trebuie să reușească, dacă nu au mers mai verificați odată pașii de mai sus.

Pentru comoditate, am înregistrat într-un screencast pașii din procedura descrisă mai sus:

Acum că avem toate pre-rechizitele pentru a instala server-ul vCenter, vom continua cu:

  • montăm ISO-ul cu setup-ul server-ului vCenter Server 5.5 la VM. Pentru aceasta, din Edit Settings la VM, click pe CD/DVD Drive. Pe dreapta, se asigură că bifele pentru Connected/Connected at Power On sunt setate iar in Device Type selectăm Datastore ISO File. Cu Browse accesăm folder-ul ISO de pe datastore și de aici selectăm fișierul ISO: VMware-VIMSetup-all-5.5.0-2183112-20140901-update02.iso.
  • in VM, dacă nu s-a lansat automat, pornim aplicația de setup vCenter (splash). În fereastră, inițiem instalarea vCenter-ului printr-un click pe Simple Install. Pentru simplitate am ales formatul cu instalare automat pentru toate componentele vCenter.
  • În wizard-ul Simple Install Setup: (a) EULA: I accept the terms. .. (b) în Select network interface  alegem interfața cu adresa IP IPv4 (c) în pre-requisites check verificăm să nu avem erori. Un warrning totuși se va afișa: cel cu Machine is not domain joined, care poate fi liber ignorat – nu e deloc obligatoriu un domain AD pentru instalarea cu succes a serverului vCenter (d) în vCenter Single Sign-On Information specificăm un password cu confirmare pentru administratorul serviciului SSO si a serverului vCenter. Se verifică complexitatea password-ului așa că indicați o parola complicată. Important ca această parolă să fie reținută undeva pentru că mai târziu cu aceasta se va accesa pentru prima data vCenter-ul. (e) restul paginilor din wizard se parcurg cu valorile lor implicite.  Se așteaptă câteva minute până când setup-ul se încheie. Posibil ca pe parcurs să primiți un dialog cu mesajul: Stop running this script ? ..  pe acesta îl puteți ignora printr-un click pe No.
  • în următoarea fază automat se va porni install-ul pentru următorul component, primul a fost SSO-ul, urmează vCenter WEB Client-ul. La un moment dat se va cere să acceptați certificatul SSL, click Yes. Întreg procesul rulează automat.
  • urmează setup-ul pentru Inventory Service care la fel a automat.
  • pe final pornește install-ul serviciului vCenter. În wizard: (a) pe pagina License Key ignorăm cu Next. Cheile de licență le vom instala mai târziu. (b) în Database Options lăsăm opțiunea implicită cu Install a Microsoft SQL Server 2008 Express instance. Vom merge cu o configurație pe SQL Sever Express tocmai potrivită în lab (c) în vCenter Server Service account information lăsăm bifat Use Windows Local System Account iar în Fully Qualified Domain Name înlocuim valoarea sugerată: IP-ul vCenter-ului, cu numele de domain al acestuia: POD-02-vCenter-01.lab.local. (d) restul paginilor din wizard se parcurg cu valorile implicite.
  • în continuare (opțional), vom instala browser-ul Chrome, acesta e mai light și are Adobe Flash Player-ul pre-instalat, ultimul fiind obligatoriu pentru accesul la vSphere WEB Client.
  • accesăm WEB Client-ul din browser-ul Chrome, pentru aceasta formăm în browser adresa: https://172.16.22.20:9443/vsphere-client. Pe pagina de autentificare specificăm credențialele pentru administratorul SSO/vCenter: Administrar@vsphere.local/password. Obligatoriu, numele utilizator trebuie să conțină sufixul domain-ului local: @vsphere.local. Mai târziu, se va configura SSO-ul ca default  identity source așa ca să nu mai fie necesar de specificat prefixul.
  • pe final, se poate instala și vSphere Client (opțional), pentru aceeași fereastra din care sa ales setup-ul pentru vCenter se inițiază install-ul pentru vSphere Client. Se parcurge wizard-ul de instalare fără a specifica vreun detaliu.

Vedeți partea a doua a screencast-ului cu install-ul server-ului vCenter:

Până aici avem instalat și configurat server-ul vCenter, in partea a doua a articolului vom instala și configura host-urile ESXi nested.

Mediu de laborator pentru studenții claselor de VMware (part III)

În părțile precedente ale articolului (part I, part II) am descris arhitectura și detaliile pentru configurația serviciilor vCenter, VPN, Proxy pe mediul de laborator DNT VMware. În partea a 3-a, ultima, am să descriu unele activități privind utilizarea enviroment-ului de laborator.

How to connect to DNT VMware LAB via VPN

Vom folosi o conexiune VPN pentru o legătură remote la enviroment-ul de laborator. Pentru acesta:

  • descărcăm client-ul VPN pe site-ul proiectului SoftEther VPN (secțiune download, ~35MB)
  • instalăm pachetul de instalare (banal, next – next .. finish)
  • pornim client-ul VPN, din top menu selectăm Connect – New VPN Connection Settings
  • în fereastra New VPN Connection Settings Properties secțiunea Destination VPN Server specificăm următorii parametri pentru o conexiune nouă: (a) setting name – un nume p/u noua conexiune (b) host name specificăm IP-ul de Internet pe router-ul DNT: 178.168.50.194, (c) port number selectăm din listă numărul 443 (d) dacă in punctele b și c nu sa greșit atunci lista cu Virtual Hub Name ar trebui să se completeze automat cu singura valoare Default pe care o și specificăm.
  • în aceeași fereastră în secțiunea User Authentication Settings specificăm username-ul și password-ul distribuite anterior de instructor pentru fiecare student. Așa cum sa mai zis, user name-ul se ia ca nume/prenume separat prin punct. În drop-down-ul Auth Type ne asigurăm că avem selectat Standard Password Authentication. Click Ok pentru confirmarea configurației. Mai jos, vedeți screen-ul pentru o configurație tipică a conexiunii VPN (exemplu pentru unul din studenți): 

dnt_vmware_lab_enviroment_p3_client configuration

Note: În caz că accesați Internet-ul prin web proxy va trebui să specificați și detaliile server-ului proxy. Pentru aceasta, în secțiunea Proxy Server as Relay (mai jos de Destination VPN server) bifați Connect via HTTP Proxy Server după care faceți click pe Proxy Server Settings. În fereastra Proxy Server Connection Settings specificați numele sau IP-ul serverului proxy, port-ul pe care acesta e configurat să funcționeze și dacă e cazul credențiale pentru autentificare.

  • pe final, în fereastra de bază SoftEther VPN Client Manager inițiem conexiunea VPN nou creată prin click dreapta pe conexiune, connect. Dacă totul a fost făcut corect, conexiunea trebuie să se stabilească cu succes fapt remarcat într-o fereastră de confirmare în care veți observa și IP-ul asignat pe interfața VPN (unul din intervalul 172.16.0.100 – 172.16.0.200). 

dnt_vmware_lab_enviroment_p3_client_connected

În continuare, se va accesa VM-ul cu Win7 legat de POD-ul studentului. VM-ul se accesează prin Remote Desktop (RDP). Adresa IP se deduce simplu, fiind a 10-a adresa in intervalul /24 asociat cu POD-ul studentului, altfel spus: 172.16.2X.10 unde X numărul POD-ului. Pentru autentificare pe VM se folosește user-ul Administrator cu password-ul asdfgh1! (nu schimbați acest password !!!).  Ca alternativă, se poate de lucrat direct pe enviroment fără a mai accesa stația cu Win7, pentru acesta se deschide vSphere Client (WEB Client) direct de pe PC-ul de acasă în care se specifică IP-ul server-ului vCenter din rețeua de laborator 172.16.0.4.

De remarcat, că conexiunea VPN nu este necesară pentru accesul la enviroment-ul de laborator din sălile de studiu DNT. De acolo, vCenter-ul din LAB se accesează direct pe IP-ul său din rețeaua de producție, adică 10.10.1.45.

How to change VPN user password

Nu este obligatoriu, dar totuși, dacă se dorește schimbarea parolei pentru conexiunea de VPN aceasta se va realiza din fereastra Properties a conexiunii VPN. În secțiunea User Authentication Settings se face click pe Change Password (vezi în screen-ul din punctul precedent). În fereastra de Change Password specificăm parola inițială precum și parola nouă plus confirmarea ei. Cred că nu mai merită să reamintesc despre cerințele de complexitate a parolei pentru o conexiune VPN.

How to change vCenter SSO user password

Odată ajunși pe mediul de laborator – in VM-ul cu Win7, studenții vor accesa server-ul vCenter fie prin vSphere Client fie cu Web Client. Pentru a accesa client-ul WEB, in browser (recomandat Chrome Browser pentru că are deja instalat adobe flash player) se va accesa adresa https://172.16.0.4:9443/vsphere-client/  sau pentru sălile de studiu DNT link-ul cu IP din rețeaua de producție https://10.10.1.45:9443/vsphere-client/. Studenții vor folosi drept username numele/prenumele propriu separat prin punct cu un password inițial distribuit de instructor. Dacă se dorește password-ul pentru user-ul vSphere poate fi schimbat. Schimbarea parolei poate fi executată doar din WEB Client după prima autentificare reușită accesând sub-meniul pe top bar. Pentru detalii vedeți imaginea de mai jos:

dnt_vmware_lab_enviroment_p3_vSphere_change_password

How to create a new Virtual Machine

Prima sarcina de realizat pe mediul de laborator sigur va fi crearea unui VM nou. Să vedem pe pași, cum vom crea un VM în vSphere Client:

  • poziționăm cursorul mouse-ului pe containerul vAPP cu care suntem asociat. Click dreapta, New Virtual Machine .. Opțiunea New Virtual Machine .. va fi ne-disponibilă (grayed) în caz că încercați crearea VM-ului într-un container ce nu vă aparține (alt vAPP, pe cluster sau datacenter).
  • în wizard-ul Create New Virtual Machine pe pagina Configuration selectăm după caz Typical sau Custom pentru exemplu vom alege Typical.
  • în continuare, pe pagina Name and Location atribuim un nume pentru noul VM. Ca recomandare, de obicei propun studenților să respecte cu toții o convenție de nume și anume ca toate VM-ul să-și înceapă numele cu titlul POD-ului: POD-0X-<nume VM>  unde X este numărul vAPP-ului personal. De ex pentru 3x VM-uri in vAPP-ul 03 (a) POD-03-ESXi-01 (b) POD-03-ESXi-02 și (c) POD-03-vCenter-01. Măsura va reduce situații de conflict în care mai mulți studenți încep a-și crea VM-uri cu același nume or așa moment se mai întâmplă – fiecare își va începe LAB-ul cu un VM cu ESXi nested cu un nume gen ESXi-01.
  • pe pagina Storage, selectăm datastore-ul destinat VM-urilor. De aici, se poate verifica și spațiul liber pe Datastore. Click Next.
  • în Guest Operating System, selectăm OS-ul și versiunea OS-ul pentru viitorul GuestOS din VM. E foarte important ca OS-ul ales să coincidă cu OS-ul din VM – doar în așa caz se poate garanta o funcționare optima a VM-ului. Ca remarcă, pentru un VM destinat unui ESXi nested selectați: OtherOther (64-bit).
  • pe pagina Network , modificăm corespunzător numărul de NIC-uri necesare pe VM prin How many NICs do you want to connect ? după care specifică tipul adaptorului (E1000, vmxnet) și network-ul in care se dorește a fi conectat VM-ul. În drop-down cu network-urile configurate lista le arată pe toate, dar prin design, studenții se pot conecta doar la grupul de port-uri special configurat pentru network-ul de laborator și anume dvPortgroup-STUDENTS. Chiar dacă disponibil la faza de selecție, specificarea unui altui group de porturi decât cel permis va genera o eroare le închiderea wizard-ului de creare a VM-ului cu eșuarea procesului. În imaginea de mai jos, eroarea produsă după ce s-a încercat a se crea un VM într-o altă rețea decât cea admisă pentru lab (LAB_STP_S). 

dnt_vmware_lab_enviroment_p3_vSphere_error_message

  • pe următoarea pagină Create a disk specificăm capacitatea disk-ului virtual în Virtual Disk Size și obligatoriu, modul de alocare a spațiului in Thin Provisioning. Atenție, wizard-ul,  implicit propune modul de alocare Thick Provision așa ca e foarte important a nu se scăpa cu vederea acest settings. Avem nevoie de Thin pentru a folosi cât mai eficient spațiul pe datastore-ul enviroment-ului de laborator.

Note: În principiu, procesul de creare a VM-ului din WEB Client în mare parte coincide cu procesul pe vSphere Client. O mică excepție totuși există, în Web Client la un moment dat se cere de ales vCenter/Datacenter în care să creezi viitorul VM or pe respectivele containere studenții nu au acces. Ca workaround, la acea fază, selectați ca destinație mai jos pe ierarhie folderul TEMPLATES setat în lab pentru stocarea template-urilor de VM-uri. Ca atenționare in plus, pe WEB Client modul de alocare a disk-ului virtual e prezentat și mai puțin evident în fereastra de dialog și la fel implicit e pe Thick așa că double attention here.

How to Enable virtualized HV (Hardware Virtualization) for a VM

Scenariile de laborator vor utiliza pe larg host-uri ESXi nested cu VM-uri nested peste acestea. Pentru a permite rularea de VM-uri nested de 64 biți, va trebui ca pe VM-ul ce găzduiește ESXi-ul nested de activat virtualizarea funcției de virtualizare hardware (VHV). O putem face fie prin a adăugă parametrul vhv.enable=”true” în fișierul de configurație VMX a VM-ului cu ESXi fie prin settings-ul VM-ului din WEB Client. Prima metodă e oarecum mai complicată și are nevoie de permissions în plus per student pe datastore pe când metoda cu GUI e una simplă și comodă. Recomand studenților configurația prin GUI.

Așadar, pentru a activa VHV-ul pe un VM destinat unui ESXi nested se va deschide din WEB Client proprietățile VM-ului cu Edit Virtual Machine Settings  după care din Virtual Hardware – CPU se va bifa parametrul: Hardware Virtualization – Expose hardware assisted virtualization to the guest OS.

dnt_vmware_lab_enviroment_p3_VHV_enable

De remarcat că respectivul parametru va fi imposibil de bifat (grayed out) dacă VM-ul nu are un hardware version de cel puțin vmx-09. Implicit, VM-urile sunt create în versiunea 08 așa că până activa VHV-ul va trebui de upgradat mașina virtuala la o versiune hardware mai superioara (din client deodată pe vmx-10). Pe deasupra, pentru ESXi-uri nested se va specifica ca Guest OS opțiunea cu VMware 5.x.

Temă pentru acasă

Primul scenariu de laborator recomandat pentru studenți este în a:

  • să instaleze 2x servere ESXi 5.5 nested cu alocarea de suficiente resurse ca pentru mai târziu să fie posibilă crearea pe acestea a altor VM-uri (2x vCPU-uri, 8GB RAM, 60GB virtual disk, 4x vmNICs).
  • să realizeze configurația inițială pentru networking-ul ESXi-ului nested.
  • să updateze ESXi-urile noi create până la ultima actualizare disponibilă.
  • să instaleze VMware Tools for nested ESXi.
  • să instaleze într-un VM pe ESXi-ul nested, de la zero, server-ul vCenter 5.5 pe Windows 2k12.
  • să aducă în inventarul vCenter-ului noi instalat host-urile ESXi nested.

Rezultatul primului scenariu de laborator va juca rolul de platformă pentru unele scenarii ulterioare așa că e important ca aici din prima totul să fie făcut corect.

Până aici tot, închei cu descrierea platformei de laborator DNT destinată orelor practice VMware și care poate fi accesată 24 din 24 de oriunde se poate ajunge la Internet. Sper să le fie de mare ajutor studenților mei și ca până la urmă să rămân cu senzația că sa muncit cu folos în acest sistem.

Mediu de laborator pentru studenții claselor de VMware (part II)

În prima parte a articolului am făcut o descriere generală pentru arhitectura enviroment-ului folosit de studenții claselor de VMware pentru executarea scenariilor practice de laborator. În partea a doua voi încerca să intru în detaliile legate de configurațiile pe serverele vCenter, VPN și Proxy. Urmează și o treia parte (ultima) în care voi descrie pas cu pas activități de bază pe mediul de laborator.

Configurație vCenter Server

Server-ul vCenter joacă rolul de aplicație de management pentru resursele server-ului fizic, este realizat ca și mașină virtuală și găzduit pe același server cu mediul de test. Server-ul vCenter va fi accesat de către studenți prin vSphere Client sau vSphere WEB Client pentru ași crea/gestiona propriile mașini virtuale potrivite scenariilor de laborator.

VM-ul pentru server-ul vCenter (LAB-vCenter-01s) are alocat 2x vCPU-uri, 12GB RAM și un spațiu de stocare pe disk de 60GB. Server-ul are două interfețe de rețea: una conectată în rețeaua de producție setată cu IP-ul 10.10.1.45/24 și alta conectată în rețeaua de laborator (izolată) setată cu IP-ul 172.16.0.4/16. Primul IP va fi folosit pentru accesul la vCenter din sălile de studiu DNT iar al doilea IP pentru access prin conexiune remote prin VPN.

Autentificarea pe server-ul vCenter are loc cu utilizatori creați în SSO pe domain-ul vsphere.local. Fiecare student își are propriul username și password. Username-ul e format din nume/prenume separat cu punct. Domain-ul vsphere.local este setat ca default așa că sufixul @vsphere.local poate fi omis la specificarea username-ului in căsuța de autentificare. Password-ul inițial, generat de instructor poate fi schimbat mai târziu de către student prin procedura de change password din interfața web client – mai multe detalii vedeți in partea a 3-a a articolului.

Networking-ul virtual, în laborator, este realizat pe un switch distribuit (dvSwitch-LAB) cu două grupuri de port-uri pre-configurate: (a) dvPortgroup-PRODUCTION și (b) dvPortgroup-STUDENTS, primul cu uplink-uri in rețeaua de producție și al doilea izolat pentru VM-urile din scenariile de laborator. Tehnic, din rețeaua STUDENTS (de laborator) nu ai cum să ajungi în PRODUCTION. Din două grupuri, studenții au dreptul să atașeze VM-uri doar pe grupul STUDENTS, orice tentativă de a accesa grupul de porturi de producție va genera un mesaj de eroare cu access denied. Grupul de porturi STUDENTS este configurat cu Promiscous Mode, MAC Address Changes și Forget Transmis ca Accept – configurație obligatorie pentru ESXi-urile nested conectate pe acel grup de porturi.

Rețeaua de producție are asociat subnet-ul 10.10.1.0/24 și cea de laborator 172.16.0.0/16. Spațiul de adrese /16 în rețeaua de laborator nu este controlată în nici un fel, studenții fiind liberi să utilizeze orice IP le este comod. Totuși, pentru comoditate, am împărțit intervalul în grupe de /24, fiecărui student revenindu-i un spațiu din acestea. Regula e simplă, un POD are asociat un interval 172.16.2X.0/24, unde x e numărul podului (de la 1 la 9), fiecare student cu POD-ul lui. Segregarea pe spații de adrese separate va reduce situațiile cu conflicte de adrese IP. Chiar dacă legați de spații /24 studenții vor continua să folosească mască de 16 biți în configurațiile proprii de rețea.

In laborator, folosim următoarea distribuție de adrese IP: 

dnt_vmware_lab_enviroment_p2_IP_addresses

Pentru a accesa pe mediul de laborator, studenții vor iniția o conexiune VPN prin care vor ajunge să fie conectați în rețeaua STUDENTS și auto-configurați cu un IP din intervalul VPN DHCP. În continuare se poate de mers fie cu conexiune direct de pe PC-ul de acasă prin vSphere Client la serverul vCenter fie printr-o sesiune RDP la VM-ul cu Windows 7 preinstalat și configurat cu toate necesare. Fiecare POD are configurat un VM cu Windows 7, configurat cu networking, remote desktop activat și cu aplicații necesare scenariilor de laborator pre-instalate. VM-urile respective au fost configurate cu al 10-lea IP din intervalul asociat POD-ului. In tabel mai sus, aceste IP-uri sunt prezentate in paranteze.

Accesele la resursele server-ului fizic și pe obiectele vCenter-ului au fost configurate în așa fel încât studenții să fie limitați doar la acțiuni necesare sarcinilor de laborator fără a putea influința configurația globală a mediului de laborator. Mai mult, fiecare student își are propriul container in care poate crea/gestiona VM-uri ne-având privilegii pe containere vecine și alte obiecte in vCenter. 

Configurația accesului pe vCenter se bazează pe:

  • roluri de utilizator custom: (a) Power Users for DNT Students (b) Read Only for DNT Students, primul moștenit din  rolul embedded Virtual Machine Power Users (sample) și respectiv al doilea moștenit din rolul Read-Only.
  • rolul de  Power Users for DNT Students a fost augmentat cu privilegii specifice pentru obiectele Datastore, Virtual Machine și Networking. Privilegiile respective au fost găsite empiric pe parcursul primei săptămâni de exploatare a mediului de laborator.
  • pe SSO-ul vCenter-ului este definită grupa de utilizatori vmware-class-std care include toată lista de utilizatori studenți.
  • pe ierarhie, la nivel de vCenter, grupul vmware-class-std a fost configurat cu rolul de Read Only for DNT Students fapt ce va permite accesul la inventarul vCenter și va asigura vizibilitate read-only peste toate obiectele vCenter.
  • pentru a putea executa activități legate de creare/gestionare VM-uri fiecare student a fost configurat ca Power Users for DNT Students pe container-ul vAPP cu care a fost asociat (un POD per student)
  • pentru avea acces la datastore-ul host-ului ESXi, grupul de utilizatori vmware-class-std a fost configurat ca Power Users for DNT Students pe containerul datastore-ului (Raid10-Store).
  • pentru a putea anexa VM-urile din laborator la networking-ul izolat de lab, grupul de utilizator vmware-class-std a fost configurat ca Power Users for DNT Students pe grupul de porturi dvPortgroup-STUDENTS. Atenție, doar pe grupul de porturi STUDENTS nu și PRODUCTION.
  • pentru a putea re-utiliza template-uri de VM-uri, a fost creat folderul TEMPLATES in view-ul VMs and Templates pe care sa configurat accesul ca Power Users for DNT Students pentru grupul de utilizatori vmware-class-std. Pentru a re-utiliza template-uri, studenții vor copia cu drag-and-drop template-ul nou creat din root-ul arborelui in folder-ul TEMPLATES. După această mișcare template-ul devine disponibil a fi utilizat – mai multe detalii vedeți in partea a 3-a a articolului.

Vedeți mai jos configurația privind alocarea de drepturi pe obiectele vCenter-ului: 

dnt_vmware_lab_enviroment_p2_permissions

Configurație Server VPN

Server-ul VPN permite accesul  remote la mediul de laborator, este realizat ca și mașină virtuală și se bazează pe o soluție SoftEther VPN (Windows). Ca și vCenter, VM-ul cu VPN are două interfețe, una public conectată in rețeaua de producție și configurată cu IP-ul 10.10.1.10 și a alta conectată în rețeaua studenților și configurată cu 172.16.0.1. Pe router-ul DNT-ului la Internet avem configurat un port-mapping de pe IP-ul public 178.168.50.194 pe IP-ul serverului VPN 10.10.1.10 pe port-ul 443. Serverul VPN funcționează pe deasupra și ca server DHCP pentru segmentul STUDENTS cu distribuire de IP-uri din intervalul 172.16.0.100-172.16.0.200. Pe stația remote pentru acces la VPN se instalează SoftEther VPN Client care poate fi descărcat gratuit pe site-ul SoftEther (click aici)

Fiecare student are propria pereche nume utilizator/password cu care se autentifică pe serverul VPN. Username-ul se formează din numele/prenumele studentului separat prin punct. Parola inițială este distribuită de instructor și poate fi oricând schimbată de utilizator. Despre cum de configurat o conexiune nouă pe client și cum de schimbat parola inițială aflați în partea a 3-a articolului.

Pe serverul VPN avem realizate următoarele configurații:

  • virtual HUB (default) configurat în bridge (prin Local Bridge Settings) cu a interfața ce pleacă in rețeaua STUDENTS. Implicit, bridge-ul e format cu interfața în PRODUCTION. Schimbarea bridge-ului pe altă interfață garantează ca conexiunea de VPN să va termina în rețeaua izolată de laborator și nu cea de producție.  

De remarcat că pentru a funcționa corect, interfața bridged a serverului VPAN (partea STUDENTS) trebuie conectată într-un grup de port-uri pe switch-ul virtual în care Promiscous Mode este in Accept or acest requirement în cazul nostru este asigurat automat. Așa cum menționasem mai sus grupul de porturi STUDENTS are configurat Promiscous Mode împreună cu celelalte două politici în Accept.

  • VPN-ul este configurat cu Split Tunneling astfel încât, odată conectat pe VPN, utilizatorul continuă să acceseze rețelele proprii și Internet-ul prin propria conexiune Internet și nu prin link-ul de VPN – pe client, apare o singură rută: cea spre rețeaua 172.16.0.0/16 ca directly connected prin interfața VPN-ului.
  • restul configurațiilor pe serverul SoftEther VPN rămân în condiția lor implicită

Configurație Proxy Server

Destinația inițială a server-ului Proxy a fost in a asigura accesul la WEB-ul (http, https) Internet-ului din rețeaua izolată de laborator. In lab, poți avea nevoie de Internet atunci când de exemplu dorești să aplici actualizări pe un ESXi nested or să descarci un tool sau orice altceva. În astfel de cazuri, pentru a accesa Internet-ul trebuie doar de configurat în proxy settings adresa private a server-ului proxy 172.16.0.39 cu portul 8080. Ca remarcă, toate VM-urile cu Win7 pe care studenții intră prin RDP au deja pre-configurate proxy server (tot aici, bifat bypass proxy server for local addresses și adăugat ca excepție network-ul 172.16.*.*).

Pe parcurs, ca workaround la o problema reachability, serverul Proxy a fost configurat și ca port mapping cu scopul de a permite accesul din rețeaua izolată de laborator la IP-ul de management vmk0 a host-ului ESXi aflat in rețeaua de producție. Mapping-ul e făcut doar pentru câteva porturi necesare funcționarii consolei la VM-uri din vSphere Client (TCP: 902, 9443, 443).

Problema de reachability menționată se descrie simplu: din moment ce deschizi din vSphere Client consola la un VM, client-ul inițiază o conexiune TCP pe portul 902 direct pe vmk0 a host-ului ESXi chiar daca vSphere Client este conectat pe IP-ului serverului vCenter. Consola folosește un path direct de la client la ESXi ocolind serverul vCenter. Așa cum, în arhitectura mediului de laborator vmk0 (interfața de management ESXi) este configurată pentru rețeaua de producție (cu IP-ul 10.10.1.120) rezultă că orice tentativă de a deschide o consolă la un VM din rețeaua de laborator duce într-o consolă failed și un mesaj cu reachability issues .. unable to connect.

Pentru a explica soluția realizată prin proxy, vedeți pentru început următoarea reprezentare grafică (errata: in desen numărul portului 903 trebuie inlocuit cu 902): 

dnt_vmware_lab_enviroment_p2_port_proxy_conf

In schemă avem 2x VM-uri, primul e VM-ul cu PROXY și al doilea un VM cu Win7. Serverul PROXY este conectat în același timp și in rețeaua de producție (PRODUCTION) împreună cu management-ul ESXi (vmk0) și în rețeaua de laborator (STUDENTS). VM-ul cu Win7 e conectat doar in rețeaua de laborator. In momentul in care se încearcă a deschide consola la un VM, aplicația vSphere Client inițiază o conexiune directă la managementul ESXi ocolind serverul vCenter. Așa conexiune nu are cum să aibă loc pentru că clientul și managementul ESXi se află în rețele diferite.

Ca workaround la problema descrisă s-au făcut următoarele configurații:

  • pe VM-urile cu Win7 s-au creat interfețe Loopback pe care s-au setat IP-ul de management a host-ului ESXi 10.10.1.120/32. Așa cum, in rețeaua de laborator nu exista un default gateway, loopback-ul va permite un routing pentru IP-ul ESXi-ului. Comunicațiile pentru 10.10.1.120 se vor întoarce în stack-ul de networking.
  • pe VM-urile cu Win7 s-au configurat translări de adresă IP prin așa numite port proxy-uri, create cu netsh. Port proxy-ul se setează per port și face translarea adresei destinație dintr-un IP în alt IP. Minim pentru deschiderea consolei avem nevoie de translare pentru portul TCP 902, totuși pentru siguranță fiecare stație mai are translare și pentru porturile 9443 și 443. Următorul code batch a fost executat pentru crearea translărilor port proxy (primele 3x linii, ultimele 3x e codul care le distruge): 

dnt_vmware_lab_enviroment_p2_port_proxy_cmd

Efectul port proxy-ului este ca ori de câte ori întră în stack-ul de networking un pachet cu destinație 10.10.1.120 și port 902 acesta să fie translat intr-un pachet cu destinație 172.16.0.39 cu același port. Altfel spus, pentru cazul nostru, toate pachetele destinate comunicațiilor consolei de VM-uri din vSphere Client vor fi supuse translării respective.

  • pe server-ul proxy este configurat o translare cu efect invers și anume destinația pe 172.16.0.39 pe port-ul 902 va fi translată în 10.10.1.120 pe același port. Modul realizării configurației depinde de soluția serverului proxy, pentru cazul nostru unde am folosit un CCProxy, settings-ul arată așa:

dnt_vmware_lab_enviroment_p2_port_map_proxy_server

Așadar, dacă e să parcurgem acum calea comunicațiilor pentru consola pe VM aceasta ar trece prin următoarele faze:

  • consola inițiază o conexiune pe IP-ul de management a host-ului ESXi 10.10.1.120 pe portul 902.
  • pachetele cu destinație 10.10.1.120 ajung pe interfața Loopback după care sunt întoarse în stack-ul de networking
  • întoarse pachetele sunt translate din destinația 10.10.1.120 pe IP-ul server-ului proxy 172.16.0.39 (doar acele pachete ce au ca destinație 10.10.1.120 și port destinație 902)
  • pachetele translate sunt plasate pe cealaltă interfața din VM 172.16.21.10 și sunt livrate către VM-ul cu serverul Proxy.
  • ajunse pe server-ul Proxy pachetele inițiate de aplicația consolei sunt supuse unei translări repetate prin care IP-ul destinație 172.16.0.39 este translat la valoarea inițială de 10.10.1.120 astfel încât să fie posibilă livrarea către interfața de management ESXi. (vor fi translatate doar pachetele cu IP-ul destinație 172.16.0.29 și port 902)
  • pachetele translate repetat vor fi plasate pe stack-ul de networking unde vor fi rutate pe interfața legată în rețeaua de producție (10.10.0.39)
  • în final pachetele vor ajunge pe interfața de management ESXi vmk0 cu IP-ul 10.10.1.120.

Pe desenul de mai sus, path-ul cu translări de IP-uri este ilustrat cu săgeți linie continue albastre.  Path-ul logic este ilustrat cu linie orange întreruptă.

Trebuie să recunosc că există o soluție mai simplă la problemă, însuși studenții mi-au sugerat-o atunci când le povesteam de arhitectură. Adevărul e că se poate și fără de interfața de loopback, IP-ul 10.10.1.120 poate fi liber setat ca secondary IP pe prima interfață – verificat, funcționează. Cool, încântat de așa studenți.

Aici pun punct descrierii detaliilor de configurație la serviciile ce fac ca mediul de laborator să funcționeze. În partea a 3-a (ultima) am să descriu într-o manieră How To mai multe activități pe care le poate executa un student pe mediul de test.

Mediu de laborator pentru studenții claselor de VMware (part I)

Ca parte a ofertei de curs VMware, DNT Training Center oferă studenților săi acces la resursele proprii de laborator. În cadrul orelor practice fiecare student poate accesa capacități rezervate pentru realizarea individuală a oricărui scenariu de laborator. Mai nou, mediul de laborator DNT poate fi accesat deja și de acasă și este disponibil 24/24. Astfel, studenții noștri pot accesa resursele de laborator oricând le este comod și de oriunde au acces la Internet. Legătura se realizează printr-o conexiune VPN peste Internet. Specificul laboratoarelor VMware, in comparație cu cele din alte cursuri, e că aici e nevoie de resurse hardware considerabile. Dacă la Cisco spre exemplu îți era suficient un PC de o capacitate medie pentru a rula Packet Tracer-ul sau/și GNS3-ul aici ai nevoie de mult mai mult – un singur PC dacă nu e dotat cu discuri SSD și cu memorie RAM peste 10GB poate să nu-ți fie suficient. Printr-un enviroment de laborator accesat de acasă încercăm să acoperim acest neajuns în așa fel încât studenții să obțină cunoștințe și deprinderi practice de cea mai înaltă calitate. În cele ce urmează, am să încerc să descriu cum a fost realizat proiectul mediului de laborator, configurațiile specifice pe acesta și unele recomandări pentru studenți. Voi organiza conținutul pe 3x parți:

  1. Part I (curent): prezentare generală, descriere arhitectura.
  2. Part II: detalii configurație servere vCenter, VPN, WEB Proxy
  3. Part III: ghid How to pentru studenți

Arhitectura mediului de laborator

Pentru început, să vedem ce obiective trebuiau asigurate de viitorul mediu de laborator:

  • acces 24 din 24, de oriunde este access la Internet-ul (acasă, serviciu)
  • acces controlat prin nume utilizator și password – personal per student
  • resurse hardware rezervate pe fiecare student in parte
  • capacitate de a rula host-uri ESXi nested cu VM-uri nested pe acestea
  • mediul de laborator izolat de rețeaua de producție DNT
  • acces la mediu de lab inclusiv și din sălile de studiu DNT

Mediul de laborator e construit pe un singur server fizic, supradotat, resursele căruia sunt partiționate între studenți cu o parte din ele rămânând rezervate pentru propriile servicii. Serverul fizic are instalat VMware ESXi 5.5 gestionat de un server vCenter Server 5.5 realizat ca și mașină virtuală pe același mediu. Adițional, alte două VM-uri lucrează pentru a asigura serviciile de VPN și Web Proxy. Studenții vor folosi resursele alocate prin crearea de mașini virtuale proprii care vor funcționa fie ca gazde pentru host-uri ESXi nested fie ca servere pentru unele servicii necesare scenariilor de laborator.

Serverul fizic reprezintă un workstation model DELL Precision T5500 dotat cu următoarele resurse hardware:

  • două procesoare Intel Xeon X5570, 2,93GHz, 8MB cache, 4 core-uri cu HT, care în sumă ne asigură un total de 16 procesoare logice.
  • o capacitate RAM de 144 GB, DDR3-1333Mhz, ECC Registered Memory
  • controller de disk-uri RAID Controller (PERC) H310, no WT/WB cache. UPD:01.05.2015 (PERC) H700, read cache/write back cache, cache memory size 512 MB, BBU.
  • 8x disk-uri SATA 2.5'', 300GB, 10K RPM configurate într-o matrice RAID 10, care în ansamblu de asigură un total de 1.2 TB capacitate de stocare alocabilă și un aproximativ de 500 IOPS pe write  și 1000 IOPS pe read. Întreaga capacitate formează datastore-ul VMFS pentru stocare VM-urilor din laboratoare.
  • adițional 2x disk-uri SATA, 300GB conectate direct în controler-ul pe motherboard, folosite separat ca două datastore-uri VMFS pentru stocarea de imagini ISO și template-uri de VM-uri.
  • 3x adaptoare de rețea GbE, unul embedded in motherboard (Broadcom BCM5761) și celelalte 2x ca parte dintr-o extensie PCIe (Intel 82571EB). In general, adaptoarele vor funcționa în paralel într-un team activ conectate la rețeaua de producție cu excepții pentru câteva laboratoare realizate in clasă în care două din NIC-uri vor fi re-comutate pe switch-urile Cisco din kit-ul de CCNA/CCNP.

Să analizăm acum elementele ce formează arhitectura mediului de laborator VMware DNT. Pentru o reprezentare grafică vedeți schema de mai jos. 

dnt_vmware_lab_enviroment_p1_lab_architecture

Așadar, următoarele elemente formează arhitectura mediului de laborator:

  • host-ul ESXi – serverul fizic despre care s-a vorbit mai sus, are instalat un ESXi 5.5 (la momentul articolului în build: 1623387 – 5.5 update 1). Imaginea ESXi a fost instalată pe un removable flash memory stick de 4GB, montat într-un port USB intern.
  • networking-ul fizic de la host-ul ESXi la router/switch-ul intern DNT (CRS125-24G-1S-2HnD-IN). Implicit, toate 3x NIC-uri pe host-ul ESXi sunt conectate la rețeaua DNT (team).
  • la nivel de IP, partea de producție din rețeaua enviroment-ului de la lab e separată de networking-ul din sălile de studiu și Wi-Fi. Pentru aceasta pe router-ul DNT a fost creat un network aparte asociat cu un subnet în intervalul 10.10.1.0/24. În acest network este conectat vmk-ul de management a host-ului ESXi, precum și câte una din interfețele VM-urilor vCenter, Proxy, VPN (interfața public)
  • partea de lab din rețeaua mediului de laborator e formată pe un grup de porturi izolat (fără uplink-uri în networking-ul fizic) pentru care se recomandă folosirea intervalului de IP-uri 172.16.0.0/16. Aici se vor conecta VM-urile din scenariile de laborator și tot aici prin interfețele secundare (interfața private) sunt conectate VM-urile serviciilor vCenter, Proxy, VPN. VM-urile create în laborator pot fi anexate doar pe acest network și orice tentativă de a te conecta pe celălalt group de porturi (producție) va duce inevitabil la eroare de drepturi de acces. E lesne de înțeles că de aici nu se poate de ajuns în rețeaua de producție.
  • server vCenter Server 5.5, element central în arhitectura mediului de laborator, folosit pentru gestionarea și accesul la resursele host-ului ESXi fizic. Configurat cu două interfețe, una in rețeaua de producție cu IP-ul 10.10.1.45 și alta în cea de laborator cu IP-ul 172.16.0.4. Studenții se vor conecta la server-ul vCenter cu vSphere Client or cu Web Client, folosind IP-ul 172.16.0.4, pentru a crea/controla VM-uri din propriile scenariile de laborator. Pe server-ul vCenter (SSO) sunt definiți utilizatori (vsphere.local) pentru fiecare student în parte, grupuri de utilizatori, roluri și permisiuni pe obiecte din inventar.
  • server WEB Proxy pentru access din rețeaua izolată de la laborator la rețeaua Internet. Are două interfețe, una conectată in rețeaua de producție și are configurat IP-ul 10.10.1.39 și alta în rețeaua de laborator cu IP-ul 172.16.0.39. Proxy-ul folosește port-ul TCP:8080. Pe client, pentru a accesa Internetul va trebui de configurat corespunzător proxy settings.
  • server VPN pentru acces remote din Internet la rețeaua de laborator. Are două interfețe, una în rețeaua de producție configurată cu IP-ul 10.10.1.15 și alta în rețeaua de laborator cu IP-ul 172.16.0.1. Fiecare student folosește propriul set username și password. Odată conectat, PC-ul remote ajunge în rețeaua de laborator și se auto-configurează prin DHCP cu un IP din intervalul 172.16.0.100-172.16.0.200.  Pe router-ul DNT, este configurat un port mapping intre IP-ul public DNT 178.168.50.194 și IP-ul server-ului VPN 10.10.1.15 pe portul 443. Server-ul VPN, este configurat să primească conexiuni pe portul TCP:443.
  • VM-uri cu Windows 7 pre-instalat și pre-configurat pentru fiecare student. VM-urile sunt conectate in rețeaua de laborator, pre-configurate manual cu un IP, Remote Desktop pornit și au pre-instalate vSphere Client și Chrome Browser. Odată conectat la mediul de laborator, studenții își deschid prin RDP propriul desktop cu Windows din care încep a-și execută task-urile necesare scenariului de laborator. Ca alternativă, e posibil și lucru cu vSphere Client (WEB Client) printr-o conexiune directă de pe PC-ul de acasă, dar asta cu siguranță va însemna un GUI mai greoi din cauza bandwith-ului redus la conexiunea de Internet a DNT-ului. VM-urile cu Windows 7 folosesc toate același password:asdfgh1! pentru utilizatorul Administrator.
  • pool-uri de resurse sub forma de vApp-uri pentru fiecare student in parte. La nivel de vApp se configurează rezervarea de RAM (câte 10GB de memorie garantată) și drepturile de acces per student. Studenții vor putea crea VM-urile doar in contextul vApp-ului de care a fost asociat. 

Vedeți mai jos screen-ul la inventarul server-ului vCenter pe mediul de laborator VMware DNT. Se observa clar VM-urile de infrastructura (vCenter, VPN, Proxy) și pool-urile de resurse alocate studenților (STD-POD-A01..A09).

dnt_vmware_lab_enviroment_p1_vCenter_inventory

Serverul fizic este montat pe poliță în rack-ul echipamentelor de laborator DNT, alături de routere și switch-uri Cisco și e conectat la o sursă de alimentare neîntreruptibilă UPS. Așa cum rack-ul cu echipamentul de laborator se află în una din sălile de studiu DNT, a fost important ca server-ul nou să fie unul cât mai silențios – de unde și decizia de a folosi un echipament de tip workstation pe rol server în loc de un server Rack Mounted, ultimul generând un nivel de zgomot considerabil.

dnt_vmware_lab_enviroment_rack_mount

În următoarele părți din articol voi descrie configurațiile specifice pe serverele vCenter, VPN, Proxy precum și un guide How To pentru cele mai de bază acțiuni pe mediul de laborator.