NSX - Erste Erkenntnisse

Manchmal denkt man einfach zu weit.

Die letzten paar Tage war leider nichts mit NSX herumprobieren, leider, oder vielleicht auch gut?

Zum Testen von NSX habe ich mir eigenes vCenter installiert, dazu 3 Hosts. Innerhalb des vCenters 2 Cluster, wovon der erste Cluster 2 Hosts und der zweite 1 Hosts umfasst.

Im ersten Cluster sitzten noch zwei Debian VMs und im zweiten Cluster eine Debian VM, damit ich das Verhalten unter den VMs ein wenig durchprobieren kann.

Vielleicht komme ich noch dazu, ein kleines Schema zu zeichnen.

 

Nun die Hosts wurden für NSX vorbereitet und auf dem Switch Jumboframes aktiviert. Das ist entsprechend wichtig, da die MTU um 100 Units, von 1500 auf 1600 ansteigt. So beginnt der Switch nicht, die Pakete zu fragmentieren. Nun kam das erstellen der Transportzonen.

Für mich war zu beginn sehr unlogisch, warum VMware alle DB Server in eine Zone packt und alle App Server in eine andere Zone packt. Dass widerspricht eigentlich der heutig gängigen Microsegmentierung. Dabei sollte DB und App im gleichen Netz sitzen, um ein Maximum an Performance herauszuholen, der Zugriff auf das Segment wird via Regel nur auf die App gewährt. Wird ein Segment kompromitiert, wird das ganze in ein isoliertes Netz weggeschoben und hermetisch verriegelt, dass keine Zugriffe mehr möglich sind. Danach kann die VM inspiziert werden.

Den grössten Sinn darin hätte ich höchstens gesehen, wenn ein Loadbalancer auf dem Segemnt sitzen würde. Aber wie bereits geschrieben, man denkt einfach zu weit. Das Bild sollte wirklich nur ein Beispiel darstellen.

Hinzu kommt, dass ich bis jetzt einen Produktiv-Cluster, eine DR-Cluster, eine Testing-Cluster habe. Da wollte mir eigentlich nicht ganz logisch sein, warum ich jetzt da NSX wirklich einsetzten sollte.

Nun, nicht logisch hat manchmal damit zu tun, weil man nicht weiss wie etwas funktioniert. Spontan habe ich mir 3 Transportzonen erstellt. Eine lokal begrenzt auf den ersten Cluster, eine zweite Zone lokal begrenzt auf den zweiten Cluster und sinnigerweise eine dritte, welche über beide Cluster geht. Somit habe ich die Transportwege erstellt.

Dann kamen entsprechend logische Switche dazu. Einer bezieht sich nur auf den ersten Cluster, den zweiten auf den zweiten Cluster und der dritte zonenübergreifend. Entsprechend sind den Switches die entsprechende logische Zone zugewiesen.

Kurzes Resume -> Transportzone erstellt entsprechend gewünschter Cluster, die miteinander kommunizieren müssen, Switch erstellt und der entsprechenden Transportzone zugewiesen -> fertig.

Jetzt mach dir mal den Gedanken, wenn du das physisch hättest bauen müssen... 3 VLANs bauen, dann im ersten Cluster VLAN 1 und 3 anbinden, im zweiten Cluster 2 und 3. Dazu noch Portgruppen erstellen, vielleicht noch via dvSwitch, na viel Spass damit. Na hast du die Übersicht noch???

Ok. auf diesem Level ist mal alles ok, nun ein Rechtsklick auf den logischen Switch, Add VM und die VMs entsprechend zuweisen.

Erster Test, Alle VMs auf den lokalen Switch A -> kann man wählen, aber du wirst nur 2 vNICs bekommen, da NSX merkt, dass die Transportzone nur auf die ersten beiden Debian NICs zugreifen kann. Dann die VM aus dem zweiten Cluster dem lokalen Switch B angehängt. Nun wird losgepingt: VM1 <-> VM2 passt, VM2 <-> VM3 geht nicht, wie auch VM1 <-> VM3 nicht, was klar ist, da wir hier in verschiedenen Transportzonen sind.

Nun alle VMs auf den Switch gesetzt, welcher auf beiden Clustern sitzt und alles kann einander pingen. Das alles innert weniger Sekunden... Wie genial ist das denn? Und das ohne Anpassungen am physikalischen Netzwerk. Ausser Anpassung an der MTU?

 

Die nächsten Rätsel, die ich lösen möchte, sind logische Router. Aktuell verwalte ich alle Netze mit einer Opnsense, das eröffnen eines Netzes geht entsprechend immer sehr lange, da ich zuerst ein VLAN einrichten muss, dann das Interface einrichten darf, oder das Netz einem Interface hinzuzufügen, damit das Routing klappt. Danach geht das ganze auf den dvSwitch. Man muss aber auch klar davon wegkommen, sich an einer physikalischen Firewall oder Router festzuhalten.

Das kann an Einspeisepunkten noch Sinn machen, aber innerhalb einer virtuellen Farm sollte man sich davon lösen. Hier soll die CPU arbeiten und das Netzwerk entlastet werden, damit Richtung Kunde soviel Datenfluss wie möglich stattfinden kann.


Drucken