Deze blogserie bestaat uit meerdere delen, die in de komende maanden uitkomen. De volgende delen zijn op dit moment uitgebracht of gepland:

1. Wat is de VMware NSX REST API
2. Aanroepen van de VMware NSX REST API met PowerShell
3. Met PowerShell aanmaken van een eenvoudig 3-tier netwerk in VMware NSX (deze blogpost)
4. PowerNSX
5. Van virtueel naar visueel: Genereer een netwerkdiagram met PowerNSX
6. Kloon uw netwerk: van productie naar test met REST
7. …

Deel 3: Met PowerShell aanmaken van een eenvoudig 3-tier netwerk in VMware NSX

Nadat we in deel 1 de basisprincipes van de REST API hebben uitgelegd en we in deel 2 een werkend voorbeeld van een bevraging in PowerShell hebben gemaakt, gaan we in dit deel met PowerShell een netwerk aanmaken met een Edge, een Distributed Logical Router en drie logische switches. Het netwerk wordt aangemaakt inclusief routing-configuratie voor OSPF-routers. Of deze routing-configuratie goed gaat werken hangt uiteraard van uw situatie af, niet iedereen heeft OSPF in het netwerk geconfigureerd.

De volledige code van deze blogserie is hier te vinden:

https://bitbucket.org/metisit/powershellnsxrestapi/src

De code van dit deel staat in de folder ‘Part 3’ en bestaat uit 4 bestanden, namelijk:

Het netwerk komt er als volgt uit te zien (een grotere versie staat als pdf in BitBucket):

De hoeveelheid PowerShell-code is te groot om volledig in deze blog te behandelen, dus de beschrijving in deze blog blijft beperkt tot het configuratiebestand en de belangrijkste delen van de code.

Het configuratiebestand is gemaakt in JSON (JavaScript Object Notation). De reden dat we JSON gebruiken i.p.v. XML is tweeledig:

1. JSON is beter leesbaar en compacter
2. JSON kan in PowerShell direct omgezet worden in een PSCustomObject, wat het gebruik in PowerShell veel eenvoudiger en compacter maakt dan een XML-Document.

Het configuratiebestand bestaat uit de volgende onderdelen:

• vsphere: De configuratie van vSphere waarbinnen het netwerk wordt aangemaakt; Dit moet zeker worden aangepast aan uw situatie. Let op: de standaard resourcepool van elk cluster is “Resources”.
• edge: De configuratie van de Edge Service Gateway. We maken hier een Edge aan zonder firewall en zonder High Availability (HA). Let hier vooral op:
  • De portgroepnaam (iface) van het management en de uplink. Dit moeten bestaande portgroepen zijn op uw distributed switch.
  • De OSPF area ID. Hier is nu 123 gedefinieerd.
  • De IP-configuratie van de uplink.
• transit: De configuratie van het transit netwerk.
• router: De configuratie van de Distributed Logical Router. Ook hier weer geen firewall en geen HA. Let ook hier weer op:
  • De juiste portgroep (iface) voor het management.
  • De OSPF area ID. Gelijk aan wat gedefinieerd is bij de Edge.
• switches: De namen en de IP-configuratie van de netwerk tiers.

Als u het script ‘Create-NSXTier.ps1’ aanroept om het netwerk aan te maken dan geeft dit, als alles juist is geconfigureerd, de volgende uitvoer:

Zoals u in bovenstaand plaatje kunt zien, worden eerst de switches aangemaakt en daarna pas de DLR en de Edge. Reden hiervoor is dat we bij de configuratie van de Router en de Edge gelijk de interfaces willen configureren, en dat kan alleen als de switches al bestaan.

In het configuratiebestand staan er IP-adressen bij de switches, maar feitelijk heeft een switch helemaal geen IP-adres. Het IP-adres wat bij de switch staat is het IP-adres van de poort waarmee de router/edge aan de switch is gekoppeld.

Wat ook belangrijk is om te weten, is dat de routing van de Edge en de Router pas kan worden geconfigureerd als de Edge of Router al zijn aangemaakt. Het in één keer configureren, inclusief routing, werkt niet.

Als u het script ‘Remove-NSXTier.ps1’ aanroept om het netwerk te verwijderen dan geeft dit de volgende uitvoer:

Bij het verwijderen worden eerst de Edge en de Router verwijderd. Daarna wordt er 10 seconden gewacht en vervolgens worden de switches verwijderd. Reden voor de wachttijd is om NSX Manager de tijd te geven om de switches los te koppelen van de Edge/Router, anders mislukt het verwijderen van de switches mogelijk.

Enkele relevante onderdelen van de code in ‘Create-NSXTier.ps1’:

1. De configuratie uit het JSON-bestand halen en in de variabele $config zetten (regel 129 t/m 140):
   

1. Verbinding maken met vCenter om de interne namen van objecten op te halen (regel 150 t/m 182):
   

1. De transport zone ophalen (regel 183 t/m 198):
   
   Let vooral op het gebruik van de variabele $paging. Door deze waarde toe te voegen aan de URL bij alle bevragingen worden, met bijna absolute zekerheid, alle objecten opgehaald (de eerste 9999). Als we dit niet meegegeven dan worden alleen de eerste 20 objecten opgehaald, een fout die in de meeste blogs op internet gemaakt wordt. Let op: we zijn hier lui door gewoon de eerste transportzone te gebruiken. Als u meer transportzones heeft, dan zou u deze configureerbaar kunnen maken.

1. Een switch aanmaken (regel 228 t/m 247):
   Hier gaan we echt iets nieuws doen: het aanmaken van een object met de REST API. Een paar dingen wijken af van een bevraging zoals we die in deel 2 van deze blogserie hebben gezien:
   1. We geven als extra argument mee ‘-Body $Body’. In $Body staat de definitie van de switch in XML-formaat volgens de documentatie van VMware. Zie hiervoor https://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf.
   2. We geven als extra argument mee ‘-Method Post’ (in plaats van de default ‘-Method Get’) omdat we een nieuw object aan gaan maken.
   3. We controleren na uitvoering van de webrequest of de statusomschrijving de tekst ‘Created’ bevat.

1. Het aanpassen van de routing-configuratie van de Router (regel 452 t/m 464):
   
   
   Let hier vooral op ‘-Method Put’. We wijzigen hier de routing (van niet geconfigureerd naar geconfigureerd). We voegen dus geen object toe maar wijzigen het, vandaar ‘Put’ i.p.v. ‘Post’.

In het script ‘Remove-NSXTier.ps1’ wordt maar één constructie gebruikt die nieuw is, namelijk het verwijderen van een object (regel 126 t/m 131):

Met ‘-Method Delete’ wordt aangegeven dat het object verwijderd moet worden.

In de volgende deel gaan we PowerNSX behandelen.