Fokusthema Network Functions Virtualization (NFV) Die Top 5 der Virtualisierungsfehler

Die Virtualisierung eroberte die IT-Welt im Sturm. Doch viele CIOs beginnen erst jetzt, sich mit dem Thema auseinanderzusetzen oder nutzen nur einen Bruchteil der Möglichkeiten. Dieser Beitrag zeigt die fünf häufigsten Fehler bei Virtualisierungsprojekten und macht anhand einer Checkliste deutlich, auf was es bei umfassenden Virtualisierungsstrategien ankommt.

Anbieter zum Thema

Dell GmbH

Lenovo Global Technology Germany GmbH

Paessler AG

Brocade Communications GmbH

Fehler Nr. 1: Unsegmentierte Netzwerke

Virtualisierung ist Chance und Bedrohung zugleich. Sie kann enorme Einsparungen bei den Investitionskosten ermöglichen und die Verwaltung vereinfachen. Doch mit der Virtualisierung wird die IT-Infrastruktur auch um eine neue Softwarekomponente erweitert – den Hypervisor oder Virtual Machine Manager. Wie jede andere neue Software birgt auch diese Komponente neue Risiken.

So, wie sich ein Fehler im Betriebssystem auf jede Anwendung auswirken kann, die innerhalb dieses Betriebssystems ausgeführt wird, kann auch ein Problem mit dem Hypervisor alle virtuellen Maschinen innerhalb eines Hardwaresystems beeinträchtigen. Deshalb ist es besonders wichtig, dass Unternehmen eine Sicherheitsstrategie für alle mit dem Hypervisor und insbesondere dessen Interaktion mit dem Netzwerk verbundenen Risiken entwickeln.

Bei einer Umfrage der Network World zur Einschätzung, ob die Virtualisierungstechnologie ein zusätzliches Sicherheitsrisiko darstelle und was man dagegen machen könne, gab mehr als die Hälfte der Befragten an, dieser Bedrohung durch eine weitere Segmentierung ihrer Netzwerke entgegenzuwirken.

Während die meisten Netzwerk-Lösungen den Einsatz zusätzlicher Komponenten zur Lösung dieses Problems erfordern, implementieren softwarebasierte Netzwerk-Lösung zukunftsweisende Routing- und Sicherheitsfunktionen, um ein bestehendes Netzwerk in einer virtualisierten Umgebung zu segmentieren. Brocades Vyatta bietet bspw. Funktionen zur Filterung des Datenverkehrs zwischen verschiedenen Subnetzen und dessen Weiterleitung zwischen den einzelnen LANs. So können den einzelnen Anwendungen in der virtualisierten Umgebung separate Netzwerksegmente zugewiesen und Auswirkungen von Verletzungen der Datensicherheit verhindert werden. Abbildung 1 zeigt ein segmentiertes Rechenzentrum.

Natürlich bieten viele Router und Firewalls Möglichkeiten zur Netzwerksegmentierung. Brocade wartet hier aber mit einer erheblich kostengünstigeren Lösung auf als andere Anbieter. Durch den Einsatz von x86-Hardware werden multiple Anwendungs-Optionen unterstützt und so Kosteneinsparungen auf verschiedenen Ebenen ermöglicht:

Dank günstiger Commodity-Preise der x86-Plattform können beim Kauf von Gehäuse, Netzwerkschnittstellen, Speicher und anderen Komponenten erhebliche Einsparungen erzielt werden.

Durch den Einsatz von Commodity-Hardware können Firewall/Router und andere Server des Rechenzentrums die Komponenten in der Regel gemeinsam nutzen. Das senkt die Kosten für Ersatzteile und steigert die Verfügbarkeit.

Brocade Vyatta lässt sich auf Bladeservern ebenso wie in Rackmount- oder Towersystemen einsetzen und bietet damit umfassende Möglichkeiten zur Integration in die physische Gesamtinfrastruktur. Beim Einsatz von Blades werden Stromversorgung und Belüftung mit dem gesamten Rest der Infrastruktur geteilt. Das steigert die Gesamteffizienz.

Fehler Nr. 2: Beschränkung der Virtualisierung auf Server

Die meisten Menschen begreifen Virtualisierung als Servertechnologie. Und tatsächlich war sie das ja auch zu Beginn. Doch bei einer Beschränkung der Virtualisierungsinitiative auf die Server nutzen Unternehmen nicht alle Vorteile vollständig aus, die die Technologie bieten kann. Daher sollte unbedingt auch eine Virtualisierung der Netzwerkfunktionen in Erwägung gezogen werden. Denn die größten Einsparungen im Bereich der Investitionskosten lassen sich tatsächlich durch Netzwerkvirtualisierung erzielen.

Weil Brocade Vyatta im Gegensatz zu vielen proprietären Netzwerklösungen auf Standard-x86-Hardware aufsetzt, lässt sich die Lösung mit denselben Hypervisoren (VMware, XenSource, Hyper-V, Red Hat KVM, etc.) virtualisieren wie Server-Betriebssysteme (Windows und Linux). So wird es möglich, die gesamte mit einer Anwendung verbundene Infrastruktur einschließlich der Netzwerkkomponenten zu virtualisieren.

Wie in Abbildung 2 dargestellt, lässt sich die Virtualisierung durch die Bereitstellung mehrerer virtueller Instanzen auf einer Hardwarekomponente umsetzen, die jeweils eine andere Anwendung unterstützen. Dieser Ansatz empfiehlt sich insbesondere für große Rechenzentren und Anwendungen, die auf unterschiedlichen Server-Tiers (virtuell oder physisch) implementiert werden.

Wird die gesamte Anwendung auf einem einzigen Server bereitgestellt, eignet sich die in Abbildung 3 dargestellte Konfiguration besser. In diesem Fall werden die virtualisierte Netzwerkinfrastruktur sowie die virtuelle Maschine der Anwendung auf derselben Hardware aufgesetzt. Diese Einsatzvariante kann eine effektive Sicherheitslösung einschließlich Firewall- und VPN-Services darstellen. Besonders interessant ist diese Vorgehensweise, um Sicherheitsdienste für direkt mit dem Internet interagierende Anwendungen wie Microsoft Exchange-Mailserver zu ergänzen. Außerdem kann durch die Etablierung einer VPN-Verbindung zwischen bestimmten Anwendungen und den Clients die Kommunikation mit diesen Anwendungen gesichert werden.

Fehler Nr. 3: Außenstellen bei der Virtualisierung nicht mit einbeziehen

In einem Bericht vom Oktober 2006 (The Evolving Branch Office: Intelligently Reducing Your Network Infrastructure Footprint) beschäftigte sich Forrester Research mit der enorm gewachsenen Bedeutung der Niederlassungskonsolidierung. Im Zuge der Beschreibung einiger Best Practices ging Forrester auch auf die mit dem heiligen Gral der Konsolidierung – der sogenannten „Branch-in-a-Box“ – verbundenen Probleme ein. Denn obwohl es Lösungen gibt, die eine substantielle funktionale Integration ermöglichen, bemerkte Forrester doch, dass es realistisch wohl keine All-in-One-Lösung für die Niederlassungskonsolidierung gebe. Trotz dieser pragmatischen Einschätzung kann man der „Branch-in-a-box“ aber doch bereits sehr nahe kommen – und Virtualisierung spielt hier eine nicht unerhebliche Rolle.

IT-Manager denken häufig über eine Virtualisierung von Rechenzentren nach. Doch wie in Abbildung 5 gezeigt, kann die Virtualisierung auch zur Konsolidierung verschiedener, verteilter Anwendungen und Systeme auf derselben Hardware in einer Niederlassung beitragen. So lassen sich beispielsweise lokale Mail- und Fileserver auf einem einzigen Server betreiben, selbst wenn diese verschiedene Betriebssysteme nutzen.

Man kann aber auch noch einen Schritt weiter gehen. Statt darauf zu warten, dass ein Hersteller eine „All-in-One-und-Branch-in-a-Box“-Lösung anbietet, können Unternehmen ihre eigene „Branch-in-a-Box“ aus unterschiedlichen Best-of-Breed-Komponenten zusammenstellen. Mit Brocade Vyatta und der entsprechenden Virtualisierungtechnologie können bspw. neben den Datei-/Druck- und Mailservern auch die Firewall, Router und VPN-Verbindung virtualisiert werden, die die Niederlassung mit der Zentrale verbinden. Diese Variante ist in Abbildung 6 dargestellt.

Fehler Nr. 4: Keine Einbindung von Netzwerkvirtualisierung in den Disaster-Recovery-Plan

Reaktionen auf die unterschiedlichsten Katastrophenszenarien – vom Erdbeben bis zum Virenbefall – werden in den meisten Unternehmen sorgfältig geplant. Für alle geschäftskritischen Anwendungen werden Backups erstellt und die Stromversorgung sowie der Maschinenpark von Rechenzentren redundant gestaltet, um sicherzustellen, dass der Geschäftsbetrieb im Notfall möglichst schnell wieder aufgenommen werden kann. Mit der Virtualisierung verfügen Unternehmen über eine weitere großartige Technologie für das Disaster Recovery. Viele Hypervisoren unterstützen Snapshots sowie die automatische Migration virtueller Maschinen von einem physischen System auf ein anderes. Im Ernstfall ermöglicht dies die Migration der gesamten Infrastruktur eines Rechenzentrums von einem Standort an einen anderen – praktisch in Echtzeit. Diese Möglichkeit der blitzschnellen Migration erleichtert die Disaster-Planung erheblich. Und zusätzlich beschleunigen solche Funktionen auch die routinemäßige Datenmigration.

Unglücklicherweise konzentrieren sich viele IT-Manager bei der Disaster-Planung auf Server und Anwendungen und gehen davon aus, dass das Netzwerk alle Dienste zur Verfügung stellen wird, um die Konnektivität der Nutzer zu gewährleisten. Im Hinblick auf grundlegende Funktionen der L2/L3-Infrastruktur wie Switching und Routing sollte die Konnektivität von primären und Backup-Standorten sichergestellt sein. Aber sind Netzwerkdienste wie Firewalls und VPN-Verbindungen Teil des Netzwerks selbst, oder sollten sie eher als Teil der auf den Servern laufenden Anwendungen verstanden werden? Anders formuliert: Wenn eine Firewall am Hauptstandort eingesetzt wird, wird dann stets auch konsequent auf die Replizierung aller Änderungen der Firewallrichtlinien am Recovery-Standort geachtet? Und ist auch die Firmware der Firewall am Backup-Standort stets auf dem neuesten Stand und sind auch hier alle aktuellen Patches und Updates installiert?

Auch hier kann die Virtualisierung Abhilfe schaffen. Wie Abbildung 7 zeigt, kann äquivalent zu einem virtualisierten Anwendungsserver auch die virtuelle Maschine der Firewall einfach am Backup-Standort repliziert werden. Damit entfällt die Notwendigkeit, identische Firewalls an beiden Standorten aufzubauen und Firmware wie Konfiguration jederzeit auf demselben Stand zu halten. Je nachdem, wie das Netzwerk aufgebaut ist, ist lediglich bei der Konfiguration darauf zu achten, dass diese auch mit dem neuen Standort kompatibel ist (ggf. ist die Anpassung einiger IP-Adressen erforderlich).

Als Teil des Disaster-Plans sollte ein Set von Anweisungen mit den im Notfall erforderlichen Schritten entwickelt werden. So können Unternehmen sicher sein, dass der Backup-Standort stets auf dem aktuellen Stand ist und die Konfiguration mit der des Hauptstandortes übereinstimmt – weil ja dieselbe virtuelle Maschine eingesetzt wird.

Fehler Nr. 5: Nicht vergessen, die alte Hardware auf eBay zu verkaufen

Nach Abschluss der Virtualisierung sollte nicht vergessen werden, die alte proprietäre Netzwerkhardware zu verkaufen. So kann zumindest ein Teil der Anfangsinvestitionen wieder gutgemacht und das Geld zur Finanzierung der Virtualisierungsstrategie genutzt werden.

Frank Kölmel

Über den Autor

Frank Kölmel ist Senior Director für die Region EMEA-CENTRAL und als solcher zuständig für den Ausbau der Marktpräsenz von Brocade und die enge Zusammenarbeit mit Vertriebspartnern. Kölmel verfügt über mehr als 15 Jahre Erfahrung in der Netzwerk- und Internetbranche.

(ID:42549298)