Skip to main content

Toepassing Project NSX-T - uitwerking scenario

Situering​

Om de krachtige toepassing van netwerkvirtualisatie duidelijk te maken, volgen we een fictief scenario. We nemen de rol op van kleine cloud provider die z'n cloud wil delen met meerdere klanten die elk een tenant zullen krijgen. In principe kunnen deze verschillende klanten (tenants) identieke, overlappende ip-ranges gebruiken. Door gebruik te maken van VRF's of een extra NAT-laag kan dit mogelijk gemaakt worden. In onderstaand scenario kiezen we echter wel een duidelijk verschillende range per tenant.

In de voorgaande stappen (hoofdstuk Private Cloud: vSphere > NSX-T configratie basiscomponenten) hebben jullie reeds een aanzet gekregen hoe een T0 en een T1 gateway kunnen geconfigureerd worden.

info

Er zal een nieuwe T0 Gateway moeten aangemaakt worden die als Provider gateway gebruikt wordt. Voor het verder verloop zullen ook nieuwe tenants (voor beide teamleden) moeten voorzien worden en dus 2 nieuwe T1 gateways.

Om dit scenario onmiddellijk een nuttige wending te geven zullen we de virtuele machines die opgezet worden onze eigen vsphere omgeving gaan monitoren en via dashboards visualiseren.

warning

Het is belangrijk om te weten dat het eerste deeltje waarbij je nog fungeert als "provider" samen met je teamgenoot moet uitgevoerd worden (acties en configs op de T0-gateway). Het stuk van de "Tenants", met T1-gateways, moet elke student individueel gaan opzetten. Er zal dus 2 keer een gelijkaardige infrastructuur uitgerold worden (2 tenants) maar deze zouden niet mogen interferen met elkaar.

Verder zal het belangrijk zijn om je goed te informeren en enkele goede bronnen er bij te halen om je te begeleiden bij keuzes en uitwerkingen van dit scenario. We geven zelf enkele handvaten die voldoende zouden moeten zijn om alles te configureren zonder alles in detail te beschrijven.

-------------------​

BELANGRIJK​

danger

Let op. We gaan straks echte, externe netwerken adverteren via OSPF naar het schoolnetwerk. Als hier niet omzichtig mee omgesprongen wordt, kunnen de gevolgen verstrekkend zijn voor de rest van het schoolnetwerk. OSPF distribueert immers alle netwerken die je adverteert!

Let dus heel goed op en controleer jezelf én de opgave eens dubbel vooraleer je netwerken of routering en NAT implementeert!

Falen is voor één keer geen optie, maar in een derdejaarsvak zou dat ook geen probleem mogen zijn... 😉

-------------------​

Opmerkingen​

  • Wees voorzichtig met de resources die je uitdeelt aan de verschillende componenten. CPU, memory en storage is er voldoende als je niet kwistig bent.

  • Maak in je vcenter zowel bij "Hosts and Cluster" als bij "VM's and Templates" repectievelijk een Resource Pools en folders aan met de namen "Provider Resources","Tenant1" en "Tenant2". Zo kan je alle routers, virtuele machines netjes gescheiden houden onder elkaar.

netwerk

Uitwerking​

Om het scenario uit te leggen kan een schema veel verduidelijken.

netwerk

info

Er werd maar 1 tenant getekend hier. Voor de tweede tenant is dat gelijkaardig.
Nietegenstaande we zouden kunnen kiezen voor identieke subnets in beide tenants doen we dat hier niet. Dat betekent dat volgende netwerken moeten gebruikt worden:

  • Tenant 1:
    • Public-Web => 10.129.x.x/29 (zie overzicht ip-adressen, kolom T)
    • Private-Db => 192.168.10.0/24 => wordt via PAT naar buiten vertaald => tweede publiek subnet 10.129.x.y/29
  • Tenant 2:
    • Public-Web => 10.129.x.x /29
    • Private-Db => 192.168.20.0/24 => wordt via PAT naar buiten vertaald => tweede publiek subnet 10.129.x.y/29

In de overzichtslijst met ip-adressen staat er voor elke student een /28 netwerk opgegeven. Dat moet je dus elk nog eens in twee aparte subnetten opdelen (/29). Het ene subnet zal integraal en rechtstreeks via OSPF naar buiten gerouteerd kunnen worden. Het andere subnet kan je gebruiken om een ip-adres uit te kiezen dat je zal gebruiken om de private adressen via PAT te vertalen naar een publiek adres dat op zijn beurt ook routeerbaar zal zijn.

Noteer persoonlijk héél goed welke range je toegewezen kreeg én hoe je die in twee gaat opsplitsen. Noteer dus ook onmiddellijk welke ip-adressen bruikbaar zijn en welke niet (netwerk- en broadcastadressen).

Vereisten Provider​

Als provider voorzie je een centrale router die voor "North-South" communicatie verantwoordelijk is en dus alle verkeer van en naar je datacenter regelt. Hiervoor voorzien we een nieuwe TO Gateway.
Om jullie wat houvast te geven en het risico op fouten wat te verkleinen, geven we hieronder de belangrijkste satppen mee om een nieuwe T0 gateway op te zetten.

Edge Node​

Aangezien een Edge node maar één T0 Gateway ondersteunt moet er een nieuwe Edge node én Edge Cluster aangemaakt worden.

  • Maak een nieuwe Edge aan met de naam nsx-edge-project en fqdn nsx-edge-project.teamxx.ikdoeict.be
  • Kies Medium deployment
  • Voorzie als Management adres het eerstvolgende ip-adres uit je VLAN 27 range.
  • De andere stappen zijn gelijkaardig als het voorbereidende labo.

Edge Cluster​

Maak een nieuwe Edge Cluster aan

  • met de naam edgecluster-project-teamxx

Nieuwe T0 Gateway​

Maak een nieuwe T0 Gateway aan:

  • met de naam T0-Provider-Teamxx

  • Active/Passive

  • selecteer de cluster die je zonet aanmaakte

    netwerk

  • Voorzie een nieuwe interface:

    • met de naam T0-Edge-Provider-Int01
    • Kies opnieuw het volgende vrije ip-adres uit de range van VLAN 27
    • Als uplink-segment gebruik je upstream-segment.
    • Je selecteert je nieuwe Edge node nsx-edge-project.

    netwerk

  • Schakel BGP uit

    • zie figuur hieronder

  • Schakel OSPF in

    netwerk

    • Stel de Area Definition in (zie figuur hierboven)

      • Area 0.0.0.42 en Type NSSA (Not So Stubby Area)

      netwerk

    • Stel OSPF Configured Interfaces in (zie figuur hierboven)

      • Selecteer je uplink interface T0-Edge-Provider-Int01
      • Selecteer je OSPF Area 0.0.0.42 en Type Broadcast

      netwerk

    • Configureer Route Summarization (zie figuur hierboven)
      Om er voor te zorgen dat de twee netwerken die jullie kregen, niet apart in de route tabellen verschijnen, passen we summarization toe.
      Let goed op om hier geen fouten te maken!!

      • Stel als prefix de summary in van jullie beide routes.
        Dat zou typisch het eerste netwerk van de twee moeten zijn, maar met een /27 notatie.

      netwerk

    • Route Redistribution
      Straks gaan we segmenten met bepaalde netwerk prefixen aanmaken. Om te bepalen welke netwerken nu veilig mogen opgenomen en gedistribueerd worden kunnen we bepaalde limieten instellen.

      netwerk

      netwerk

      Hieronder geven we aan dat we enkel de geconnecteerde segmenten en de NAT/PAT ip's van een T1 Gateway willen verder naar buiten distribueren. We zullen later, bij de T1 gateway, de geconnecteerde netwerken nog verder filteren.

      netwerk

CONTROLE

Bovenstaande stappen waren vrij belangrijk voor het goed functioneren van OSPF in de area van de school.
Je kan dat nu verifiëren of je T0 interface wel degelijk adjacenies is aangegaan met zijn OSPF neighbors. De status van het OSPF proces zou telkens FULL state moeten zijn.

netwerk

Vereisten Tenant​

warning

Vanaf hier werkt elke teamgenoot het scenario apart uit. Zorg er voor dat de naamgeving van je resources duidelijk aangeeft van welke tenant ze zijn en plaats deze resources ook in de juiste resource groups en folders (zie hogerop).

Ook hier zullen we nog wat houvast bieden om de T1 Gateway goed te configureren om deels segmenten rechtstreeks te laten routeren en deels segmente via NAT/PAT te adverteren.

Nieuwe T1 Gateway aanmaken​

  • Geef die de naam T1-Tenant-StudentNaam
  • Active/Standby
  • Link deze T1 aan de nieuwe T0 Gateway
  • Selecteer ook de nieuwe Edge Cluster waar deze T1 moet terecht komen.
  • Controleer bij Router Advertisement de settings zoals hieronder.

netwerk

  • Route Advertisement Rules
    Omdat we niet alle subnetten van de segmenten aan deze T0 Gateway willen adverteren (enkel "Public-Web") zullen we Route Advertisement Rules instellen.
    Hiermee kunnen we bepalen welke (super-)netwerken we van bv. de geconnecteerde segmenten willen adverteren.
    • Neem hier het /29 netwerk op dat je eerder berekende voor je Public-Web

      netwerk

Segement Public-Web voorzien​

Segment Private-DB voorzien​

DHCP​

Zoek zelf even uit hoe je de T1 Gateway kan instellen zodat er op de segmenten Public-Web en Private-DB DHCP kan gebruikt worden.
Demonstreer dat voor beide segmenten met een kleine VM (Tiny Linux).

Vereisten Services in de Tenant​

Elke tenant (en dus student) zal voorzien in een monitoringoplossing voor de vsphere-omgeving. Die monitoring moet naar de buitenwereld (=odisee netwerk) bereikbaar gemaakt worden. Als eindresultaat zal je twee dashboards opzetten waarbij je live de load op je vSphere omgeving kan zien.

netwerk

Om bovenstaande te realiseren worden vier services gebruikt:

Telegraf: deze service zal data adhv input plugins verzamelen en met output plugins wegschrijven. Wij gebruiken vcenter monitoring als input en influxdb als output

Influxdb: deze databank heeft een heel specifieke functie: het bewaren van time series. Wij gebruiken het om de monitoring parameters van vcenter te bewaren

Grafana: met deze visualisatietool kan je heel snel dashboarden maken voor monitoring. Wij gebruiken het om de verzamelde data in influxdb te visualiseren.

Cronograf: Alternatieve visualisatietool, specifiek ontwikkeld voor influxdb.

warning

Telegraph en InfluxDB kunnen best op 1 vm samen geconfigureerd worden om resources te besparen.

Voor onze eindgebruikers zijn Grafana en Cronograf extern (via VPN) te bereiken:

  • Grafana => grafana_voornaam.teamxx.labci.eu
  • Cronograf => cronograf_voornaam.teamxx.labci.eu
info

Beide URN's moeten verwijzen naar hetzelfde ip-adres!!! (uiteraard voor elke student een ander ip-adres)
Via Reverse Proxy mbv Load Balancing (zie verder) zal het verkeer dan bij de juiste server terecht komen.

Jullie hoeven hiervoor zelf geen DNS-server voor resolving op te zetten. Je kan de benodigde records configureren in een gemeenschappelijk toegankelijke DNS-server. Op deze DNS-server kan je dan de nodige records toevoegen zodat bovenstaande URN's resolven naar een ip-adres op de "publieke" kant van je vsphere-omgeving.

note

Deze ip-adressen zullen uiteraard niet bruikbaar zijn om vanop het publieke internet te surfen naar jullie resources (de ip-range (10.129.4x.0/28) die je kreeg komt uit een private range). Met jullie VPN (Bij voorkeur Cisco Anyconnect) actief zou dit echter wel moeten werken.

De gegevens van de DNS-server, waar de DNS-zone voor "labci.eu geconfigureerd staat, kan je bereiken via:

  • RDP op 10.129.36.193
  • gebruikersnaam: .\labci
  • wachtwoord: OdiseeGent!
warning

Gedraag je op deze DNS-service als een 'goeie huisvader'...

Opzetten van de servers​

Hou bij het opzetten van de servers rekening met de beperkte resources op jullie servers. Kies daarom 2GB RAM en Rocky minimal als OS. Zet Grafana, Telegraf & Cronograf op als container. Voor influxdb hoef je dat niet te doen, deze service kan je met de package manager installeren.

Om de statusdata te halen uit vSphere zal je credentials moeten aanmaken in vCenter. Doe dat volgens de regels van de kunst: maak een account met net genoeg rechten om dit te doen.

Reverse proxy - Load Balancer​

Om onze diensten beschikbaar te maken naar externe gebruikers zullen jullie moeten een reverse proxy functionaliteit opzetten. We hebben immers meerdere sites op hetzelfde domein die naar een verschillend ip moeten doorgestuurd worden. Deze dienst wordt ook aangeleverd door een NSX-component, nl de Load Balancer.

tip

Gebruik het scenario van een Inline Load Balancer die toegevoegd wordt aan de T1 gateway.
Om de load balancer te laten verwijzen naar verschillende servers bij het ontvangen van verschillende URL's zal je moeten gebruik maken van Load Balancer Rules op de Virtual Server. Je zal meerbepaald de HTTP Request Header moeten bekijken bij de Request forwarding om op basis van de URL (host) die meegegeven werd het verkeer door te sturen naar de juiste Server Pool.

Firewall​

Beveilig je omgeving. Deze beveiliging realiseer je niet met de ingebouwde firewall-functionaliteit van het besturingssysteem maar met de *Distributed Firewall", een onderdeel van NSX.

Enkele regels waar zeker moet aan voldaan worden:

  • De influx-DB mag enkel connecties ontvangen van de grafana/chronograph services. Dit realiseer je met de "distributed firewall" functie van NSX (en dus niet met de klassieke firewall regels in de Edge of DLR)
  • de toegang tot het 192.168.(20,40).0/24 netwerk moet beperkt worden tot het strikt noodzakelijke.
  • beveilig waar nodig je setup verder. (verantwoorden wat je al dan niet nog extra zal beveiligen)
tip

Je kan best even de documentatie er op nalezen hoe je precies een dergelijke distributed firewall (East-West en North-South) kan configureren.