VMware stellt zur Verwaltung der Virtualisierung von Private Cloud, Public Cloud und Edge mit vRealize Network Insight [1] und dessen Cloudpendant als SaaS-Angebot zwei Produkte zur Verfügung. Im Folgenden kürzen wir diese mit Network Insight beziehungsweise vRNI ab. Das Produkt entstand, nachdem VMware 2016 "Arkin Net" übernommen hatte.

Arkin war im Bereich der softwaredefinierten Sicherheit und des Betriebs von Rechenzentren unterwegs und Arkin Net unterstützte speziell NSX-Umgebungen. Es bot den Netzwerkern volle Visibilität auf alle Schichten der Virtualisierung, inklusive der Netzwerkhardware. Mit der Integration in VMwares vRealize-Suite wurde es möglich, alle Bereiche des virtualisierten Datacenters (lokal und Cloud) und des SD-WANs von der Planung über die Fehlerbehebung und die Automatisierung bis zur Kontrolle und Dokumentation abzudecken. Alles, was wir im Folgenden beschreiben, lässt sich problemlos in den Hands-on-Labs [2] und im "Virtual Network Assessment" [3] ausprobieren.

Die einfache und strukturierte Architektur von vRNI besteht aus mindestens einem Collector (Network Insight Proxy) als VM und einem Network-Insight-Platform-Cluster, der ebenfalls mindestens aus einer VM besteht. Letzterer kommt als Interface für den User-Zugriff zum Einsatz (Bild 1). Die Hardware-Anforderungen an CPU, RAM und Disk hängen bei beiden Komponenten von der Anzahl der zu verwaltenden VMs, der Netzwerkgeräte oder genutzten Funktionen ab. Es empfiehlt sich deshalb, die aktuellen Release Notes vor der Installation zu lesen. Es gibt verschiedene Funktionsvarianten, wie vRNI Advanced, vRNI Enterprise, vRNI Cloud, vRNI SD-WAN und vRNI Assurance and Verification.

Die vRNI-Proxy-VM (Collector) ist für das Sammeln der Daten zuständig. Entweder werden die Daten automatisch geliefert (etwa von vSphere ESXi, Log Insight oder als Netflow von der Netzwerkhardware) oder der Collector sammelt sie ein. Das System fragt dabei vCenter, NSX-Manager und Controller per HTTPS oder SSH nativ ab. Bei den Netzwerkgeräten und den Serversystemen ist die Datensammlung per SSH und CLI oder Standard-SNMP möglich. Hierbei sind verschiedene vordefinierte Hersteller wie Cisco, Juniper und andere unterstützt. Die Platform-VM wird per HTTPS vom Collector bedient und auch der User-Zugriff passiert über HTTPS. Der Collector muss on-premises installiert sein, die Platform-VM kann lokal als auch in der Cloud als SaaS laufen.

Für die vRNI-Installation benötigen Sie zwei geroutete IP-Adressen (Management-Network) und die beiden OVA-Files in der aktuellsten Version. Um vRNI mit dem vCenter und dem NSX-Manager verbinden zu können, sind für die Installation noch User-Accounts notwendig. Für einen Testaufbau als Proof-of-Concept sind folgende Eckwerte ausreichend:

- Platform-VM: 64 GByte RAM, 16 vCPU und 2 TByte HDD (für Flow Based Application Detection – siehe unten – sind mehr RAM und vCPU notwendig)

- Proxy-VM: 12 GByte RAM, 4 vCPUs und 200 GByte HDD.

Die Installation über "vSphere / Deploy OVF Template" startet mit der Platform-OVA. Nach der Eingabe der typischen Installationsinformationen steht die VM zur Verfügung. Auf der Konsole rufen Sie nun über consoleuser/console das "setup" auf. Ein Skript fragt dann die IP-Informationen und die Passwörter ab und startet die VM neu. Nun ist der Webzugriff über "https://<VRNI-Platform-IP-Adresse> möglich und verlangt nach dem vRNI-Lizenz-Key. Die Platform-Installation wird mit der Vergabe des Passworts für "admin@local" beendet.

Nach einem Zwischenschritt, der einen Schlüssel für die Bindung zum vRNI-Proxy generiert, verläuft die Installation für den vRNI-Proxy ähnlich zur Platform-Installation (Platform-Key wird zusätzlich abgefragt). Es werden auch hier die IP-Adresse und verschiedene Passwörter im Skript definiert. Nach etwa einer Stunde können Sie sich per "admin@local" auf der Platform anmelden.

Haben Sie sich als Administrator authentisiert, gilt es, vor dem Einsatz von vRNI einige Grundkonfigurationen durchzuführen. Rechts oben auf dem Startbildschirm findet sich ein Piktogramm für Einstellungen.

Sie sollten am Anfang unter "Infrastructure and Support" bei "Overview and Updates" die "System Health" und die "Infrastructure" überprüfen. Damit nun Daten von vCenter und NSX-T-Manager an den Collector geschickt werden können, müssen Sie bei "Accounts and Data Sources" diese als "Source" hinzufügen.

vRNI ist passiv zur vSphere-, NSX- und Netzwerkinstallation. Es benötigt also keine Konfigurationsanpassungen – mit zwei Ausnahmen: Beim Einbinden des vCenters wird IPFIX auf den Hypervisoren (Virtual Distributed Switch notwendig) angeschaltet und automatisch konfiguriert. Eine weitere Ausnahme bildet der Einsatz von SNMP zur Datenabfrage bei Netzwerkkomponenten. Das heißt, im Normalfall lässt sich vRNI im laufenden Betrieb ohne Unterbrechung oder Beeinflussung des Netzwerkes einschalten und nutzen. Als Datenquellen kommen die folgenden Systeme und Dienste infrage:

- vCenter und NSX

- VeloCloud (SD-WAN)

- VMware Cloud (VMC), AWS, MS Azure

- Container

- Konvergente Infrastrukturen (Cisco UCS, HP VCM und HP One View Manager)

- Router und Switches (Cisco Catalyst, Nexus, ACI, Arista, Juniper, Dell und andere)

- Weitere Systeme wie Standard-Netflow, VMware Log Insight, Infoblox, F5 LB und CMDBs (ServiceNow)

Sie sollten neben der Konfiguration auch darauf achten, dass bevor vRNI sich richtig nutzen lässt, es erst einmal Daten sammeln muss. Aus der Erfahrung zeigt es sich, dass ein oder zwei Tage Vorlauf sinnvolle Informationen ergeben.

Grundsätzlich kommt vRNI in drei Bereichen zum Einsatz: über das gesamte Netzwerk (Under- und Overlay) von der Branch/Edge über Physical/Virtual/Containers bis zur Multicloud:

- Applications (Infrastruktur und Cloud): Discovery, Curation, Operations

- Networking (Netzwerk): End-to-End-Troubleshooting, Traffic- und Pfadanalyse, Applikationslatenzen und Netzwerkperformance

- Security: Traffic Visibility, Application Modeling, Operations, Change/Audit und Compliance

Typische Anwendungsfälle von vRealize Network Insight sind:

- Networking: Einheitliche Sichtbarkeit in hybriden und Multi-Cloudumgebungen, Transparenz für NSX, VMware-SD-WAN, Kubernetes, VMware Cloud on AWS, AWS, Microsoft Azure, Azure VMware, Google Cloud VMware Engine und VMware Cloud auf Dell EMC, Konnektivität zwischen Overlay- und Underlay-Netzwerken, Ende-zu-Ende-Fehlerbehebung, Verkehrs- und Pfadanalysen, Netzwerksicherung und -überprüfung.

- Anwendungen: Anwendungserkennung und -migrationen, Messung von Latenz und Leistung, Verkürzung der mittleren Reparaturzeit (MTTR) bei Konnektivitätsproblemen, Optimieren der Leistung durch Beseitigung von Netzwerkengpässen, Analyse des Datenverkehrs und der Applikationen in Hybrid und Multicloud.

- Sicherheit: Planen der Anwendungssicherheit und der Cloudmigration, Planung der Sicherheit, Empfehlung von Firewallrichtlinien und Netzwerksegmentierungs-Anwendungen, Fehlerbehebung bei der Sicherheit von hybriden Anwendungen auf VMs, Containern und Clouds sowie die Abbildung von Abhängigkeiten zur Risikominderung bei der Migration von Anwendungen.

Schnelle Ergebnisse erreichen Sie bei vRNI mit "Flow Based Application Detection" (FBAD), der Security-Planung und dem Visualisieren des Netzwerkpfades für das Troubleshooting. FBAD gibt die Möglichkeit, über "VMware Magic" Flows zwischen VMs zu nutzen, um Zusammenhänge zwischen den einzelnen VMs zu einer Anwendung zu erkennen. Das heißt, Sie müssen nicht mehr wie in den älteren Versionen die Applikationen über eine CMDB importieren oder per Hand mit VM-Namen definieren (Bild 2).

Mithilfe der definierten Applikationen ist nun die Security-Planung möglich. NSX-T benötigt für die Microsegmentierung durch die NSX-T Distributed Firewall (DFW) Policies und Regeln, die den

Verkehr von und zur VM filtern. Diese Firewallregeln lassen sich natürlich per Hand erstellen, dies bringt aber die Schwierigkeit mit sich, dass die Verkehrsbeziehungen zwischen den Applikationsservern nicht bekannt sind oder dass diese sich ändern. Dies mit einem Netzwerkanalysator nachzuvollziehen, ist mühsam und fehleranfällig.

Mit "Plan and Assess" auf der linken Seite des Hauptmenüs gelangen Sie zur Auswahl "Security Planning". Hier definieren Sie die Art der Flows, die auszuwertende Datenmenge und die Informationsgruppierung. Anschließend berechnet vRNI die Flows zwischen den Anwendungen und nutzt zur Anzeige den typischen "vRNI Doughnut". Wählen Sie nun die zu bearbeitende Applikation aus, werden Ihnen die "Recommended Firewall Rules" für diese angeboten.

Diese Firewallregeln können Sie als CVS- oder XML-Datei exportieren und in NSX-T importieren. Wichtig ist hierbei, dass nicht mehr die typischen Five-Tuples (Source/Destination-IP, Source/Destination-Port und Protokoll) zum Einsatz kommen, sondern Gruppen für die Source und Destination, sowie Services lesbar dargestellt werden.

Sollten nach der Installation der Firewallregeln oder anderer Änderungen im Netzwerk Kommunikationsprobleme entstehen, greifen Sie einfach in vRNI auf die Darstellung des Pfades zum Trouble-shooting zu. Über die Befehlszeile mit kontext-definierter Hilfe via

oder der Auswahl über das Menü lassen sich sehr schnell und einfach komplette Verkehrspfade darstellen. Die Darstellung kann in Echtzeit oder über die Historie der Archivdatenbank auch in der Vergangenheit erfolgen. Parallele Wege (ECMP) lassen sich ebenso anzeigen wie alle beteiligten Netzelemente von der virtuellen Netzwerkkarte über die lokalen Firewallregeln, den verschiedenen Verbindungsnetzen und aktiven Services bis hin zur Netzwerkhardware (Bild 3).

Zusätzlich zu diesen Funktionen kann vRNI recht einfach einen Überblick über alle Netzwerkbereiche geben. Mit "Intents" verwalten Sie regelmäßige Prüfungen zu Themen wie MTU Mismatch, Konfigurationsfehlern, doppelten IP-Adressen, STP-Problemen (Spanning Tree Protocol) und selbstdefinierten Tests. Über "Alerts" verwalten Sie die verschiedenen Fehleranzeigen und -prüfungen. Über "Outliers" und "Thresholds" haben Sie die Möglichkeit, Ausreißer aus einer Gruppe von Messwerten zu finden und dies zu melden. Die "Thresholds" können Sie nutzen, um Veränderungen in den Durchsatzdaten, Delay/Jitter oder anderen Verkehrsraten zu finden.

Mit der Version 3.1 von NSX-T steht mit NSX Intelligence ein neues, integriertes Tools im NSX-Manager zur Verfügung. NSX Intelligence ist eine Analyse-Engine, die die aktuelle Sicherheitslage visualisiert. In der aktuellen Version gibt es eine Überlappung mit vRNI, wenn es um Sicherheitsregeln für die Microsegmentierung geht. Die Anwendung von Machine-Learning-Analysen auf den tiefgreifenden Workload- und Netzwerkkontext, der nur in NSX vorhanden ist, stellt eine detaillierte Visualisierung der Anwendungstopologie, automatisierte Empfehlungen für Sicherheitsrichtlinien, eine kontinuierliche Überwachung jedes Datenflusses und ein vollständiges Audit-Protokoll der Sicherheitsrichtlinien bereit. In zukünftigen NSX-Versionen soll NSX Intelligence zur zentralen Schaltstelle für die gesamte Sicherheit (Microsegmentierung, IDS/IPS und Netzwerkkommunikation) werden.

Während Intelligence sich auf die Virtualisierung im Datacenter und in der Multicloud konzentriert, betrachtet vRNI das Netzwerk mit Netzwerkhardware, die Virtualisierung, die Cloud und das SD-WAN ganzheitlich.

Für virtualisierte Umgebungen und beim Einsatz von Multicloud und SD-WAN ist vRNI eigentlich ein echtes Muss, wenn es darum geht, ein Netzwerk zu sichern, zu überprüfen und zu planen. Da vRNI alle Betriebs- und Konfigurationsdaten der VMs erfasst und für Public Clouds, SD-WAN und auch die physische Netzwerkhardware die Informationen sammelt, bekommt der Nutzer einen ganzheitlichen Überblick der Umgebung. Der Zeitaufwand und die Komplexität der Fehlersuche und das Sammeln von Daten für die Optimierung wird reduziert und vereinfacht. IT-Verantwortliche haben die Wahl, vRNI mit NSX-T zu lizenzieren oder das Tool extra zuzukaufen, denn auch mit vSphere allein lassen sich schon große Mehrwerte erreichen.