Verbesserte Sichtbarkeit zum Monitoring
Die von Cisco entwickelte Nexus-1000V-Serie ist ein Beispiel für vollständig in eine virtuelle Vmware-Infrastruktur integrierte virtuelle Switches. Die Cisco-Nexus 1000V-Serie ist in die regulären Administrationsprozesse integriert und vereinfacht die vSwitch- und Port-Gruppen-Konfiguration bzw. sorgt dafür, dass bei der Netzwerkkonfiguration die Fehler reduziert werden. Darüber hinaus wird sichergestellt, dass die festgelegten Netzwerkregeln konsequent im gesamten Rechenzentrum umgesetzt werden. Die Weitervermittlung des Datenverkehrs zwischen virtuellen Maschinen auf dem gleichen physikalischen Rechner auf Basis der Cisco-Nexus-1000V-Serie erfolgt ohne den Umweg über einen physikalischen Switch. Dies hat jedoch den Nachteil, dass dadurch Blindstellen für die Überwachungs- und Management-Werkzeuge entstehen. Wird zusätzlich ein „GigaVUE-VM Fabric Node“ installiert, lässt sich der gesamte virtuelle Datenverkehr intelligent erfassen, filtern und lokal bzw. extern ausleiten. Hierzu sind keine Änderungen an den Betriebsabläufen erforderlich und die bisher vorhandenen Monitoring- und Management-Tools können weiter genutzt werden.
Zusätzlich zum Aufbau von verteilten virtuellen Switches bietet Cisco auch die Möglichkeit zur Weiterleitung virtueller Verkehrsströme an einen externen Switch. Hierzu werden die betreffenden Pakete mit einer speziellen VN-Tag-Kennung gekennzeichnet. Die wichtigsten Komponenten des Tags sind die ID des Interfaces der virtuellen Datenquelle und die ID des Interfaces der Ziel-Schnittstelle (VIF) zur eindeutigen Identifizierung mehrerer virtueller Schnittstellen auf einem physikalischen Port. Die Herausforderung bei der Übermittlung der mit zusätzlichen Tags versehenen Pakete besteht darin, ohne Hardware- oder Software-Änderungen und ohne zusätzlichen Performance-Overhead zu übermitteln.
Eine adaptive Paketfilterung ermöglicht das Filtern und das Weiterleiten eingehenden Verkehrsströme auf Basis der VN-Tag-Quelle oder der Ziel-VIF_IDs und/oder der im Paket gekapselten Paketinhalte. Da die Analyse- und Monitoring-Tools die zusätzlichen VN-Tag-Header nicht verstehen, kann die adaptive Paketfilterung in Kombination mit Strippen (Löschen) des VN-Tag-Headers vor der Weiterleitung der Pakete zum betreffenden Endgerät aufgesetzt werden.
„Virtuelle eXtensible Local Area Network“ (VXLAN)
Die Grenzen der aktuellen physischen Netzwerke schaffen zunehmend Probleme bei der Realisierung verteilter virtueller Rechnerwelten (Clouds). Die Generierung einer virtuellen Maschine ist eine Angelegenheit von wenigen Minuten. Dagegen dauert die Konfiguration der erforderlichen Netzwerk- und Security-Dienste unter Umständen mehrere Tage. Hochverfügbare virtualisierte Serverumgebungen funktionieren immer noch in „flachen“ Layer-2-Netzwerken am besten. Wobei die Konfiguration und das Management eines solchen verteilt arbeitenden Server- und Netzkonstrukts schwierig ist. Die Umsetzung von Software-Defined-Networking (SDN), bei der sich ein Betreiber eines Rechenzentrums oder einer Cloud Betreiber, nicht mehr um die Netzwerk-Hardware kümmern muss, steht erst am Anfang. Momentan werden in diesem Bereich die ersten Openflow- und VXLAN-Umsetzungen getestet.
VXLAN (Virtual-Extensible-LAN) ist ein Infrastrukturprotokoll um ein Overlay-Netzwerk auf einer existierenden Layer-3-Infrastruktur zu realisieren. Bei der VXLAN-Technik geht es allgemein gesprochen, um die Zuordnung von IP-Adressen in einem größeren Netzverbund und um die Beibehaltung der IP-Adresse bei Standortänderungen. Technisch gesehen erzeugt ein VXLAN logische Layer-2-Netzwerke, die dann in standardmäßige Layer-3-Pakete eingepackt werden. Dadurch werden die logischen Layer-2-Netzwerke über physische Grenzen hinaus erweitert. Zur Unterscheidung der jeweiligen Netze wird eine Segment-ID in jedes Paket eingefügt. In Cloud-Umgebungen lassen sich solche Tunnel auch innerhalb von Hypervisoren, also in den virtuellen Maschinen, generieren und terminieren. Dabei spielt es keine Rolle, ob die physischen Host-Systeme in einem einzigen Rechenzentrum stehen oder über mehrere Standorte weltweit verteilt sind. Das logische Overlay ist vollkommen unabhängig von der zugrunde liegenden physischen Netzwerkinfrastruktur.
Durch dieses Verfahren kann nicht nur eine sehr große Anzahl von isolierten Schicht-2 VXLAN-Netzen auf einer Layer 3-Infrastruktur realisiert werden. Darüber hinaus können durch VXLANs virtuelle Maschinen auf demselben virtuellen Layer 2-Netzwerk installiert werden, obwohl sich diese auf unterschiedlichen Schicht-3-Netzwerken befinden. Die VXLAN-Technik arbeitet mit Standard-Switches, die nicht für diese Erweiterungen hochgerüstet werden müssen.
Nachteilig wirkt sich dieser Lösungsansatz dadurch aus, dass der gesamte Layer-2-Datenverkehr in einem Tunnel versteckt wird und die Netzwerküberwachung bzw. das Monitoring sehr schwierig wird. Daher werden die in den Tunneln übermittelten Anwendungen in der Regel nicht überwacht.
Darstellung der in VXLANs übermittelten Datenströme
VXLAN sorgt für die Erweiterung des VLAN-Konzepts. Für diesen Zweck wurde ein 24 Bit langes Segment (Sement-ID) hinzugefügt. Damit lassen sich Millionen an isolierten Layer-2-VXLAN-Netzwerken auf einer herkömmlichen Layer-3-Infrastruktur realisieren und die im gleichen logischen Netzwerk installierten virtuellen Maschinen können über Layer-3-Strukturen direkt miteinander kommunizieren. Darüber hinaus können die VXLAN-Tunnel dynamisch auf- und abgebaut werden.
An das Monitoring und die Netzanalyse stellen verteilt arbeitende VMs jedoch große Herausforderungen. Das Troubleshooting und das Netzwerk-Performance-Management einer solchen Struktur sind sehr schwierig. Wird beispielsweise ein Paket in einem VXLAN-Overlay von einer virtuellen Maschine zu einer anderen gesendet und kommt nicht dort an, ist es schwer nachzuvollziehen, ob es im Hypervisor oder auf physischer Netzwerkebene verloren gegangen ist. Vielleicht hat aber auch das Routing des Datenverkehrs im virtuellen Switch nicht korrekt funktioniert, oder das Empfängersystem hat das Paket schlicht ignoriert.
Wie in konventionellen Netzwerken hängt die Performance einer Applikation auch in virtuellen Umgebungen von Faktoren wie Netzwerkauslastung, Server-Performance und Speicherlatenz ab. In klassischen Serverstrukturen und Netzwerken lässt sich die Performance relativ gut vorhersagen. An definierten Zugangspunkten angeschlossene Analyse- und Monitoringwerkzeuge können den Datenverkehr bestimmter Anwendung in Echtzeit messen. In dynamisch konfigurierten Serverstrukturen und Netzwerken ist die Darstellung der notwendigen Monitoring- und Analyseparameter schwierig oder sogar unmöglich. Die logischen Overlay-Netzverbindungen werden bei Bedarf auf- und wieder abgebaut. Dadurch verändert sich dynamisch die Topologie und Konnektivität der Applikationen sowie der Computer- und Speicherressourcen.
Eine Unified-Visibility-Fabric-Architektur kann das Monitoring-Problem lösen, da diese in verteilten VM-Strukturen und VXLAN-Overlay-Netzwerken zur Sichtbarmachung der dynamischen Datenverbindungen genutzt werden kann. Die zu überwachenden Datenströme werden gezielt an die jeweilige Analyse-, Sicherheits- oder Monitoring-Komponente ausgegeben.
Fazit
In virtuellen Netzen und Serverstrukturen werden zusätzliche Mechanismen zur Sichtbarmachung der Datenströme benötigt. Dabei ist es egal, ob die virtuellen Maschinen auf einem oder verteilt auf mehreren physikalischen Rechnern realisiert werden. Die Datenverkehre lassen sich nicht mehr für das Monitoring, die Analyse oder zur Kontrolle abgreifen. Für ein erfolgreiches Monitoring ist es erforderlich, Ereignisse auf physischer und logischer Ebene zu korrelieren. Diese Aufgabe kann eine so genannte „Unified Visibility Fabric“ übernehmen. Diese ermöglicht es zudem, dass die IT-Abteilung einen Zugriff auf die für sie wichtigen Informationen erhält.
