NSX-v vs NSX-T: Uitgebreide vergelijking

Virtualisatie heeft revolutionaire veranderingen teweeggebracht in de manier waarop datacenters worden gebouwd. De meerderheid van de moderne datacenters gebruikt hardwarevirtualisatie en implementeert fysieke servers als hypervisors om virtuele machines op genoemde servers uit te voeren. Deze aanpak verbetert de schaalbaarheid, flexibiliteit en kostenefficiëntie van het datacenter. VMware is een van de belangrijkste spelers op de virtualisatiemarkt en hun producten worden zeer gerespecteerd in de IT-industrie, waarbij VMware ESXi Hypervisor en VMware vCenter veelvoorkomende componenten zijn van de VMware vSphere virtualisatieoplossing.

Het netwerk is een cruciaal onderdeel van elk datacenter, inclusief gevirtualiseerde datacenters, en als u grote netwerken en complexe netwerkconfiguraties nodig heeft voor uw gevirtualiseerde datacenter, overweeg dan het gebruik van softwaregedefinieerde netwerken (SDN). Softwaregedefinieerd netwerken is een architectuur die tot doel heeft netwerken wendbaar en flexibel te maken. Het doel van SDN is om netwerkbeheer te verbeteren door bedrijven en serviceproviders in staat te stellen snel te reageren op veranderende zakelijke eisen. VMware geeft om zijn klanten en biedt de VMware NSX-oplossing voor het bouwen van softwaregedefinieerde netwerken. De blogpost van vandaag behandelt VMware NSX en onderzoekt het verschil tussen VMware NSX-v en VMware NSX-T.

Wat is VMware NSX en hoe kan het worden gebruikt?

VMware NSX is een netwerkvirtualisatieoplossing die u toelaat om software-gebaseerde netwerken te bouwen in virtuele datacenters. Net zoals VMs geabstraheerd zijn van fysieke serverhardware, worden virtuele netwerken, inclusief switches, poorten, routers, firewalls, enz., in de virtuele ruimte opgebouwd. Virtuele netwerken worden geprovisioneerd en beheerd onafhankelijk van de onderliggende hardware. Virtuele machines worden verbonden met de virtuele poorten van virtuele switches; de verbinding tussen virtuele netwerken wordt uitgevoerd met virtuele routers en toegangsregels worden geconfigureerd op virtuele firewalls. Alternatief is ook netwerkloadbalancing beschikbaar. VMware NSX is een opvolger van VMware vCloud Networking & Security (vCNS) en Nicira NVP, die in 2012 door VMware werd overgenomen.

Microsegmentatie

Bij het gebruik van een traditionele aanpak voor het configureren van toegang tussen meerdere netwerken in een virtuele omgeving, wordt meestal een fysieke router of een edge gateway die op een VM draait ingezet, hoewel deze aanpak niet bijzonder snel of handig is. VMware heeft het concept van microsegmentatie geïmplementeerd in NSX door gebruik te maken van een gedistribueerde firewall die is ingebouwd in de kern van de hypervisor. Beveiligingsbeleidsregels, netwerkinteractieparameters voor IP-adressen, MAC-adressen, VM’s, toepassingen en andere objecten worden allemaal ingesteld in deze gedistribueerde firewall. De regels kunnen geconfigureerd worden door gebruik te maken van objecten zoals Active Directory-gebruikers en groepen als NSX wordt ingezet binnen uw bedrijf waar de Active Directory Domain Controller (ADDC) wordt gebruikt. Elk object kan worden beschouwd als een microsegment in zijn eigen beveiligingsperimeter van het betreffende netwerk dat zijn eigen DMZ (gedemilitariseerde zone) heeft.

De Gedistribueerde Firewall stelt u in staat om virtuele datacenterentiteiten zoals virtuele machines te segmenteren. Segmentatie kan gebaseerd zijn op VM-namen en attributen, gebruikersidentiteit, vCenter-objecten zoals datacenters en hosts, of kan gebaseerd zijn op traditionele netwerkattributen zoals IP-adressen, poortgroepen, enzovoort.

Het Edge Firewall-component helpt u om te voldoen aan belangrijke perimeterbeveiligingseisen, zoals het bouwen van DMZ’s op basis van IP/VLAN-constructies, huurder-tot-huurder isolatie in multi-tenant virtuele datacenters, Network Address Translation (NAT), partner (extranet) VPN’s, en op gebruikers gebaseerde SSL VPN’s.

Als een virtuele machine (VM) wordt gemigreerd van de ene host naar de andere – van de ene subnet naar de andere – worden de toegangsregels en beveiligingsbeleid aangepast aan de nieuwe locatie. Als een database server op een gemigreerde VM draait, zullen de in de firewall ingestelde regels voor deze VM na de migratie naar een andere host of netwerk blijven werken, waardoor de database server toegang kan krijgen tot de applicatieserver die draait op de VM die niet gemigreerd is. Dit is een voorbeeld van verbeterde flexibiliteit en automatisering in actie bij het gebruik van VMware NSX. NSX kan vooral nuttig zijn voor cloudproviders en grote virtuele infrastructuur. VMware biedt twee soorten van het NSX software-gebaseerde netwerkplatform – NSX-v en NSX-T.

NSX for vSphere (NSX-v) is sterk geïntegreerd met VMware vSphere en vereist de implementatie van de VMware vCenter. VMware NSX-v is specifiek voor vSphere-hypervisoromgevingen en werd ontwikkeld vóór NSX-T.

NSX-T (NSX-Transformers) werd ontworpen voor verschillende virtuele platformen en multi-hypervisoromgevingen en kan ook worden gebruikt in gevallen waar NSX-v niet van toepassing is. Terwijl NSX-v SDN alleen ondersteunt voor VMware vSphere, ondersteunt NSX-T ook het netwerkvirtualisatiestack voor KVM, Docker, Kubernetes, OpenStack en AWS-workloads. VMware NSX-T kan worden geïmplementeerd zonder een vCenter Server en is aangenomen voor heterogene rekensystemen.

De belangrijkste scenario’s voor het gebruik van NSX-v worden in de onderstaande tabel weergegeven. De tabel is verdeeld in drie rijen, waarvan er één de scenario-categorie beschrijft. Scenario’s voor het gebruik van NSX-T zijn vetgedrukt weergegeven.

Beveiliging	Automatisering	Toepassingscontinuïteit
Microsegmentatie	Automatisering van IT	Rampenherstel
Veilige eindgebruiker	Ontwikkelaarscloud	Samenvoegen van meerdere datacenters
DMZ overal	Multi-tenant infrastructuur	Cross-cloud

Onderdelen van NSX

De belangrijkste onderdelen van VMware NSX zijn NSX Manager, NSX controllers en NSX Edge-gateways.

NSX Manager is een gecentraliseerd onderdeel van NSX dat wordt gebruikt voor het beheer van netwerken. NSX Manager kan worden geïmplementeerd als een VM op een van de ESXi-servers die worden beheerd door vCenter (vanuit een OVA-sjabloon). In gevallen waarin u NSX-v gebruikt, kan NSX Manager werken met slechts één vCenter Server, terwijl NSX Manager voor NSX-T kan worden geïmplementeerd als een ESXi-VM of KVM-VM en kan werken met meerdere vCenter servers tegelijk.

NSX Manager voor vSphere is gebaseerd op het Photon OS (vergelijkbaar met de vCenter Server Appliance).

NSX-T Manager wordt uitgevoerd op het Ubuntu-besturingssysteem.

NSX-controllers. De NSX-controller is een gedistribueerd statusbeheersysteem dat wordt gebruikt om transporttunnels en virtuele netwerken te bedienen, welke als VM op ESXi of KVM hypervisors kunnen worden geïnstalleerd. De NSX Controller beheert alle logische switches binnen het netwerk en handelt informatie over VM’s, hosts, switches en VXLANs af. Met drie controller-knooppunten wordt gegevensredundantie gegarandeerd in geval van een storing van een NSX Controller-knooppunt.

NSX Edge is een gatewaydienst die toegang biedt tot fysieke en virtuele netwerken voor VM’s. NSX Edge kan worden geïnstalleerd als een gedistribueerd virtueel router of als een services gateway. De volgende diensten kunnen worden aangeboden: Dynamische routing, firewalls, Netwerkadresvertaling (NAT), Dynamisch Host Configuration Protocol (DHCP), Virtueel Privaat Netwerk (VPN), Load Balancing en High Availability.

Deployeringsopties

Het concept van het deployeren is vrijwel hetzelfde voor zowel NSX-v als NSX-T. U moet de volgende stappen uitvoeren om NSX te deployeren:

• Deployeer NSX Manager als een VM op een ESXi-host met behulp van een virtuele appliance. Zorg ervoor dat u NSX Manager registreert bij vSphere vCenter (voor NSX-v). Als u NSX-T gebruikt, kunt u NSX Manager als een virtuele appliance op een KVM-host deployeren, aangezien VMware NSX-T u in staat stelt een cluster van NSX Managers te maken.
• Deployeer drie NSX-controllers en maak een NSX-controllercluster aan.
• Installeer VIB’s (kernelmodules) op ESXi-hosts om een gedistribueerde firewall, gedistribueerde routing en VXLAN mogelijk te maken als u NSX-v gebruikt. Als u NSX-T gebruikt, moeten kernelmodules ook op KVM hypervisors worden geïnstalleerd.
• Installeer NSX Edge als een VM op ESXi (voor NSX-v en NSX-T). Als je NSX-T gebruikt en er is geen mogelijkheid om Edge als een virtuele machine op ESXi te installeren, kan Edge worden ingezet op een fysieke server. Het installeren van Edge als een VM op KVM-hypervisors wordt op dit moment niet ondersteund (voor NSX-T v.2.3). Als je Edge op een fysieke server wilt implementeren, controleer dan de hardwarecompatibiliteitslijst (belangrijk voor CPU’s en NIC’s) voordat je dit doet.

NSX Gemeenschappelijke mogelijkheden

Er zijn een reeks mogelijkheden die beschikbaar zijn voor beide NSX-types.

De gemeenschappelijke mogelijkheden voor NSX-v en NSX-T zijn:

• Softwaregebaseerde netwerkvirtualisatie
• Softwaregebaseerde overlay
• Gedistribueerde routering
• Gedistribueerde firewalling
• API-gestuurde automatisering
• Gedetailleerde monitoring en statistieken

Wees je ervan bewust dat de API’s verschillend zijn voor NSX-v en NSX-T.

Licenties

De licenties zijn hetzelfde voor beide NSX-types, omdat ze meer flexibiliteit en universaliteit bieden. Bijvoorbeeld, je kunt een licentie bestellen voor het gebruik van NSX voor vSphere, en als je wijzigingen aanbrengt in je infrastructuur en NSX-T moet implementeren, kun je de verkregen licentie voor ESXi-v gebruiken. NSX is NSX – er is geen onderscheid vanuit het oogpunt van licenties, aangezien de licentie-edities ook hetzelfde zijn.

Overlay-encapsulatie

De VXLAN-header bestaat uit de volgende onderdelen.

Er worden 8 bits gebruikt voor vlaggen. De I-vlag moet worden ingesteld op 1 om een geldige VXLAN Network ID (VNI) te maken. De andere 7 bits zijn R-velden die zijn gereserveerd en moeten worden ingesteld op nul bij verzending. De R-velden die op nul zijn ingesteld, worden genegeerd bij ontvangst.De VXLAN Network Identifier (VNI), ook wel bekend als VXLAN Segment ID, is een waarde van 24 bits die wordt gebruikt om het individuele overlay-netwerk te bepalen dat wordt gebruikt voor het communiceren van VM’s met elkaar.

Gereserveerde velden (24-bit en 8-bit) moeten worden ingesteld op nul en worden genegeerd bij ontvangst.

GENEVE. De GENEVE-header lijkt veel op VXLAN en heeft de volgende structuur:

Er zijn variabele lengteopties beschikbaar om toekomstige innovaties mogelijk te maken.

• De grootte van de GENEVE-header is variabel.NSX-T maakt gebruik van GENEVE (GEneric NEtwork Virtualization Encapsulation) als een tunnelprotocol dat traditionele offload-mogelijkheden behoudt die beschikbaar zijn op NICs (Network Interface Controllers) voor de beste prestaties. Er kan aanvullende metadata worden toegevoegd aan overlay-headers en dit maakt het mogelijk om de contextdifferentiatie te verbeteren voor het verwerken van informatie zoals end-to-end telemetrie, gegevensopvolging, encryptie, beveiliging, enzovoort op de gegevensoverdrachtslaag. Aanvullende informatie in de metadata wordt TLV (Type, Lengte, Waarde) genoemd. GENEVE is ontwikkeld door VMware, Intel, Red Hat en Microsoft. GENEVE is gebaseerd op de beste concepten van VXLAN, STT en NVGRE encapsulation-protocollen.
• Het VXLAN Network Identifier (VNI), ook bekend als VXLAN Segment ID, is een 24-bits waarde die wordt gebruikt om het individuele overlaynetwerk te bepalen dat wordt gebruikt voor het communiceren van VM’s met elkaar.
• Gereserveerde velden (24-bits en 8-bits) moeten worden ingesteld op nul en genegeerd bij ontvangst.

A size of the VXLAN header is fixed and is equal to 8 bytes. Using Jumbo frames with MTU set to 1600 bytes or more is recommended for VXLAN.

GENEVE. De GENEVE-header lijkt veel op VXLAN en heeft de volgende structuur:

• A compact tunnel header is encapsulated in UDP over IP.
• A small fixed tunnel header is used to provide control information, as well as a base level of functionality and interoperability.
• Variabele lengteopties zijn beschikbaar om toekomstige innovaties mogelijk te maken.

De grootte van de GENEVE-header is variabel.

NSX-T gebruikt GENEVE (GEneric NEtwork Virtualization Encapsulation) als een tunnelprotocol dat de traditionele offload-mogelijkheden behoudt die beschikbaar zijn op NIC’s (Network Interface Controllers) voor de beste prestaties. Aan overlayheaders kan aanvullende metadata worden toegevoegd, waardoor contextdifferentiatie mogelijk is voor de verwerking van informatie zoals end-to-end telemetrie, datatracking, versleuteling, beveiliging, enz. op de gegevensoverdrachtslaag. Aanvullende informatie in de metadata wordt TLV (Type, Lengte, Waarde) genoemd. GENEVE is ontwikkeld door VMware, Intel, Red Hat en Microsoft. GENEVE is gebaseerd op de beste concepten van VXLAN, STT en NVGRE-encapsulatieprotocollen.

De MTU-waarde voor Jumbo-frames moet minimaal 1700 bytes zijn bij gebruik van GENEVE-encapsulatie, wat wordt veroorzaakt door het aanvullende metagegevensveld van variabele lengte voor GENEVE-headers (een MTU van 1600 of hoger wordt gebruikt voor VXLAN, zoals u zich zult herinneren).

NSX-v en NSX-T zijn niet compatibel vanwege het verschil in overlay-encapsulatie dat in deze sectie wordt uitgelegd.

Layer-2 Networking

Nu je weet hoe virtuele laag 2 Ethernet-frames worden geëncapsuleerd over IP-netwerken, is het tijd om de implementatie van virtuele laag 2-netwerken voor NSX-v en NSX-T te verkennen.

Transportnodes en virtuele switches

Transportnodes en virtuele switches vertegenwoordigen NSX-datadoorvoercomponenten.

Transport Node (TN) is het NSX-compatibele apparaat dat deelneemt aan de verkeerstransmissie en NSX-netwerkoverlay. Een node moet een hostswitch bevatten om te kunnen dienen als transportnode.

NSX-v vereist het gebruik van de vSphere distributed virtual switch (VDS) zoals gebruikelijk in vSphere. Standaard virtuele switches kunnen niet worden gebruikt voor NSX-v.

NSX-T veronderstelt dat je een NSX-T distributed virtual switch (N-VDS) moet implementeren. Open vSwitches (OVS) worden gebruikt voor KVM-hosts en VMware vSwitches worden gebruikt voor ESXi-hosts en kunnen voor dit doel worden gebruikt.

N-VDS (virtual distributed switch that is previously known as a hostswitch) is a software NSX component on the transport node, that performs traffic transmission. N-VDS is the primary component of the transport nodes’ data plane that forwards traffic and owns at least one physical network interface controller (NIC). NSX Switches (N-VDS) of the different transport nodes are independent but can be grouped by assigning the same names for centralized management.

Op ESXi-hypervisors wordt N-VDS geïmplementeerd door gebruik te maken van de VMware vSphere Distributed Switch via de NSX-vSwitch-module die wordt geladen in de kernel van de hypervisor. Op KVM-hypervisors wordt de hostswitch geïmplementeerd door de Open-vSwitch (OVS)-module.

Transportzones zijn beschikbaar voor zowel NSX-v als NSX-T. Transportzones definiëren de grenzen van de distributie van logische netwerken. Elke transportzone is gekoppeld aan zijn NSX Switch (N-VDS). Transportzones voor NSX-T zijn niet gekoppeld aan clusters.

Er zijn twee soorten transportzones voor VMware NSX-T vanwege GENEVE-encapsulatie: Overlay of VLAN. Wat betreft VMware NSX-v, definieert een transportzone alleen de distributiegrenzen van VXLAN.

Logische switch-replicatiemodi

Wanneer twee virtuele machines die op verschillende hosts zijn gevestigd, rechtstreeks communiceren, wordt het unicast-verkeer uitgewisseld in de geëncapsuleerde modus tussen twee eindpunt-IP-adressen die aan hypervisors zijn toegewezen zonder dat er sprake is van flooding. Soms moet laag-2 netwerkverkeer dat afkomstig is van een VM op dezelfde manier worden gefloode als laag-2 verkeer in traditionele fysieke netwerken, bijvoorbeeld als een verzender het MAC-adres van de bestemmingsnetwerkinterface niet kent. Dit betekent dat hetzelfde verkeer (broadcast, unicast, multicast) naar alle VM’s die zijn aangesloten op dezelfde logische switch moet worden gestuurd. Als VM’s op verschillende hosts zijn gevestigd, moet het verkeer naar die hosts worden gerepliceerd. Broadcast-, unicast- en multicast-verkeer staat ook bekend als BUM-verkeer.

Laten we het verschil bekijken tussen replicatiemodi voor NSX-v en NSX-T.

NSX-v ondersteunt Unicast-modus, Multicast-modus en Hybride modus.

NSX-T ondersteunt Unicast-modus met twee opties: Hiërarchische tweelaagse replicatie (geoptimaliseerd, hetzelfde als voor NSX-v) en Hoofdreplicatie (niet geoptimaliseerd).

ARP-onderdrukking vermindert de hoeveelheid ARP-broadcastverkeer die over het netwerk wordt verzonden en is beschikbaar voor Unicast- en Hybride verkeersreplicatiemodi. ARP-onderdrukking is dus beschikbaar voor zowel NSX-v als NSX-T.

Wanneer een VM1 een ARP-verzoek stuurt om de MAC-adres van een VM2 te weten te komen, wordt het ARP-verzoek onderschept door de logische switch. Als de switch al een ARP-vermelding heeft voor het doelnetwerkinterface van de VM2, wordt het ARP-antwoord door de switch naar de VM1 gestuurd. Anders stuurt de switch het ARP-verzoek naar een NSX-controller. Als de NSX-controller informatie bevat over de VM IP naar MAC binding, stuurt de controller het antwoord met die binding en vervolgens stuurt de logische switch het ARP-antwoord naar de VM1. Als er geen ARP-vermelding is op de NSX-controller, wordt het ARP-verzoek opnieuw gebroadcast op de logische switch.

NSX laag 2-bridgetechnologie

Laag 2-bridgetechnologie is handig voor het migreren van workloads van overlay-netwerken naar VLAN’s, of voor het splitsen van subnetten over fysieke en virtuele workloads.

NSX-v: Deze functie werkt op het kernelniveau van een hypervisor waarop een control VM draait.

NSX-T: Er wordt een apart NSX-bridgeknooppunt voor deze doeleinden gecreëerd. NSX-bridgeknooppunten kunnen worden samengevoegd in clusters om de fouttolerantie van het gehele oplossingsvermogen te verbeteren.

In NSX-v control VM werd redundantie geïmplementeerd door gebruik te maken van het High Availability (HA) schema. Eén VM-exemplaar is actief terwijl het tweede VM-exemplaar in de wachtstand staat. Als de actieve VM uitvalt, kan het enige tijd duren om de VM’s te wisselen en de wachtende VM te laden door het actief te maken. NSX-T heeft dit nadeel niet, aangezien een fouttolerant cluster wordt gebruikt in plaats van het actief/wachtend schema voor HA.

Het Routingsmodel

In gevallen waarin u VMware NSX gebruikt, worden de volgende termen gebruikt:

Oost-west verkeer verwijst naar het overbrengen van gegevens over het netwerk binnen het datacenter. Deze naam wordt gebruikt voor dit specifieke type verkeer omdat horizontale lijnen op diagrammen meestal het lokale netwerkverkeer (LAN) aangeven.

Noord-zuid verkeer verwijst naar client-server verkeer of verkeer dat tussen een datacenter en een locatie buiten het datacenter beweegt (externe netwerken). Verticale lijnen op de diagrammen beschrijven meestal dit type netwerkverkeer.

Gedistribueerde logische router (DLR) is een virtuele router die gebruik kan maken van statische routes en dynamische routeringsprotocollen zoals OSPF, IS-IS of BGP.

Tenant verwijst naar een klant of een organisatie die toegang krijgt tot een geïsoleerde beveiligde omgeving die wordt geleverd door een beheerde serviceprovider (MSP). Een grote organisatie kan een multi-tenant architectuur gebruiken door elk departement als een enkele tenant te beschouwen. VMware NSX kan bijzonder nuttig zijn voor het leveren van infrastructuur als een dienst (IaaS).

Routering in NSX-v

NSX voor vSphere maakt gebruik van DLR (gedistribueerde logische router) en gecentraliseerde routering. Op elk hypervisor is een routeringskernelmodule aanwezig waarop routering tussen logische interfaces (LIFs) op de gedistribueerde router wordt uitgevoerd.

Laten we bijvoorbeeld het typische routeringsschema voor NSX-v overwegen, wanneer u een set van drie segmenten heeft: VM’s die databases uitvoeren, VM’s die applicatieservers uitvoeren en VM’s die webservers uitvoeren. VM’s van deze segmenten (hemelsblauw, groen en diepblauw) zijn verbonden met een gedistribueerde logische router (DLR) die op zijn beurt is verbonden met externe netwerken via edge gateways (NSX Edge).

U kunt ook het werkingsprincipe zien op het schema waarop componenten zijn verdeeld in clusters: Managementcluster, Edge-cluster en Compute-cluster. In dit voorbeeld gebruikt elk cluster 2 ESXi-hosts. Als twee VM’s op dezelfde ESXi-host draaien maar tot verschillende netwerksegmenten behoren, verloopt het verkeer via de NSX Edge-gateway die zich bevindt op een andere ESXi-host van het Edge-cluster. Na het routeren moet dit verkeer worden teruggestuurd naar de ESXi-host waarop de bron- en doel-VM’s draaien.

De route van verkeerstransmissie is in dit geval niet optimaal. De voordelen die beschikbaar zijn voor gedistribueerd routeren in het multi-tenant model met Edge-gateways kunnen niet worden benut, wat resulteert in grotere latentie voor uw netwerkverkeer.Routering in NSX-T

NSX-T gebruikt een tweelagenmodel voor gedistribueerde routering om de bovenstaande problemen op te lossen. Zowel Tier0 als Tier1 worden aangemaakt op de Transport-nodes, waarvan de laatste niet noodzakelijk is, maar bedoeld is om de schaalbaarheid te verbeteren.

Verkeer wordt verzonden via het meest optimale pad, aangezien de routering vervolgens wordt uitgevoerd op de ESXi- of KVM-hypervisor waarop de VM’s draaien. Het enige geval waarin een vast punt van routering moet worden gebruikt, is bij het verbinden met externe netwerken. Er zijn aparte Edge-nodes ingezet op servers die hypervisors uitvoeren.

Aanvullende services zoals BGP, NAT en Edge Firewall kunnen worden ingeschakeld op Edge-nodes, die op hun beurt kunnen worden gecombineerd in een cluster om de beschikbaarheid te verbeteren. Bovendien biedt NSX-T ook snellere foutdetectie. In eenvoudige bewoordingen is de beste manier om routering te verdelen, routering binnen de gevirtualiseerde infrastructuur.

NSX-T maakt gebruik van een tweeledig gedistribueerd routemodel om de hierboven uitgelegde problemen op te lossen. Zowel Tier0 als Tier1 worden aangemaakt op de Transport-nodes, waarvan de laatste niet noodzakelijk is, maar bedoeld is om de schaalbaarheid te verbeteren.

Verkeer wordt verzonden via de meest optimale route, aangezien de routing vervolgens wordt uitgevoerd op de ESXi- of KVM-hypervisor waarop de VM’s draaien. Het enige geval waarin een vast routepunt moet worden gebruikt, is bij het verbinden met externe netwerken. Er zijn aparte Edge-nodes ingezet op servers die hypervisors draaien.

Aanvullende diensten zoals BGP, NAT en Edge Firewall kunnen worden ingeschakeld op Edge-nodes, die op hun beurt kunnen worden gecombineerd tot een cluster om de beschikbaarheid te verbeteren. Bovendien biedt NSX-T ook snellere foutdetectie. Kortom, de beste manier om routing te verdelen is routing binnen de gevirtualiseerde infrastructuur.

IP-adressering voor virtuele netwerken

Als je NSX-v configureert, moet je een plan opstellen voor IP-adressering binnen NSX-segmenten. Transit-logische switches die DLR’s en Edge-gateways verbinden, moeten ook in dit geval worden toegevoegd. Als je een groot aantal Edge-gateways gebruikt, moet je het IP-adresseringsschema opstellen voor segmenten die zijn verbonden door deze Edge-gateways.

NSX-T vereist echter deze bewerkingen niet. Alle netwerksegmenten tussen Tier0 en Tier1 verkrijgen automatisch IP-adressen. Er worden geen dynamische routingprotocollen gebruikt, in plaats daarvan worden statische routes gebruikt en verbindt een systeem de componenten automatisch, waardoor de configuratie eenvoudiger wordt; je hoeft niet veel tijd te besteden aan het plannen van IP-adressering voor service (transit) netwerkcomponenten.

Integratie voor verkeersinspectie

NSX-v biedt integratie met services van derden, zoals agentless antivirus, geavanceerde firewalling (next generation firewalls), IDS (Intrusion Detection Systems), IPS (Intrusion Prevention Systems) en andere vormen van verkeersinspectie services. De integratie met genoemde vormen van verkeersinspectie wordt uitgevoerd op het niveau van een hypervisor kernel met behulp van een beveiligde VMCI-bus (Virtual Machine Communication Interface).

NSX-T biedt op dit moment geen van deze mogelijkheden.

Beveiliging

Kernel-level gedistribueerde firewalls kunnen geconfigureerd worden voor zowel NSX-v als NSX-T, werkend op het niveau van een VM-virtuele adapter. Schakelbeveiligingsopties zijn beschikbaar voor beide NSX-types, maar de optie “Beperken van uitzendingen en multicast-verkeer” is alleen beschikbaar voor NSX-T.

NSX-T stelt u in staat om regels op een meer gedetailleerde manier toe te passen, wat resulteert in een meer rationeel gebruik van transportknooppunten. Bijvoorbeeld, u kunt regels toepassen op basis van de volgende objecten: logische switch, logische poort, NSGroup. Deze functie kan worden gebruikt om de configuratie van de regelset op de logische switch, logische poort of NSGroup te verminderen om hogere niveaus van efficiëntie en optimalisatie te bereiken. U kunt ook ruimte besparen en zoekcycli voor regels verminderen, naast het hosten van multi-tenant implementaties en het toepassen van tenant-specifieke regels (regels die worden toegepast op workloads van de juiste tenant).

Het proces van het creëren en toepassen van de regels is vrij gelijkaardig voor zowel NSX-v als NSX-T. Het verschil is dat de beleidsregels die zijn gemaakt voor NSX-T naar alle controllers worden gestuurd waar de regels worden omgezet naar IP-adressen, terwijl bij NSX-v de beleidsregels onmiddellijk worden overgebracht naar de vShield Firewall Daemon (VSFWD).

NSX-v vs NSX-T – Vergelijkingstabel

Nu je bekend bent geraakt met de meest interessante mogelijkheden van VMware NSX, laten we de belangrijkste kenmerken van NSX-v en NSX-T samenvatten die in deze blogpost zijn verkend, naast het vergelijken ervan in de tabel.

Conclusie

NSX-v is de meest optimale oplossing als u alleen een vSphere-omgeving gebruikt, terwijl NSX-T kan worden gebruikt niet alleen voor vSphere maar ook voor KVM, Docker, Kubernetes, en OpenStack virtualisatieplatforms in het kader van het bouwen van virtuele netwerken. Er is geen enkel antwoord op welk type NSX beter is. Of u NSX-v of NSX-T moet gebruiken, hangt af van uw behoeften en de functies die elk type NSX biedt.

Het NSX-licentiebeleid is gebruikersvriendelijk – u hoeft slechts één NSX-licentie te kopen, ongeacht het type NSX dat u gaat gebruiken. Later kunt u NSX-T installeren in een NSX-v-omgeving of omgekeerd, afhankelijk van uw behoeften, en uw enkele NSX-licentie blijven gebruiken.

U kunt uw eigen softwaregedefinieerde datacenter bouwen met VMware door gebruik te maken van de NSX-oplossing. VMware biedt u

clusteringfuncties

om de operationele continuïteit, hoge beschikbaarheid en fouttolerantie te garanderen, maar VM-back-up zal geen overbodige maatregel zijn. Maak regelmatig een back-up van uw productie-VM’s die verband houden met verschillende projecten en VM’s die worden uitgevoerd als onderdelen van VMware vSphere en VMware NSX (zoals vCenter, NSX Manager, NSX Controller, NSX Edge) om uw gegevens te beschermen. NAKIVO Backup & Replication kan u helpen de VMware-back-up op een betrouwbare en efficiënte manier te maken, zelfs als u clusters gebruikt.

Conclusie

NSX-v is de meest optimale oplossing als je alleen een vSphere-omgeving gebruikt, terwijl NSX-T kan worden gebruikt voor vSphere, maar ook voor KVM, Docker, Kubernetes en OpenStack virtualisatieplatforms bij het opzetten van virtuele netwerken. Er is geen eenduidig antwoord op welk type NSX beter is. Of je NSX-v of NSX-T moet gebruiken, hangt af van je behoeften en de functies die elk NSX-type biedt.

Het NSX-licentiebeleid is gebruiksvriendelijk – je hoeft slechts één NSX-licentie te kopen, ongeacht het type NSX dat je gaat gebruiken. Later kun je NSX-T installeren in een NSX-v-omgeving of omgekeerd, afhankelijk van je behoeften, en blijven profiteren van je enkele NSX-licentie.

Je kunt je eigen softwaregedefinieerde datacenter bouwen met VMware door gebruik te maken van de NSX-oplossing. VMware biedt je clusteringfuncties om de continuïteit van de werking, hoge beschikbaarheid en fouttolerantie te waarborgen, maar het maken van een back-up van virtuele machines is geen overbodige maatregel.

Maak regelmatig een back-up van je productie-VM’s die verband houden met verschillende projecten en VM’s die draaien als onderdelen van VMware vSphere en VMware NSX (zoals vCenter, NSX Manager, NSX Controller, NSX Edge) om je gegevens te beschermen. NAKIVO Backup & Replication kan je helpen om op een betrouwbare en efficiënte manier een back-up van VMware te maken, zelfs als je clusters gebruikt.