Sie sind auf Seite 1von 23
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde
Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign Autoren:   Martin Gödde

Auswirkungen von Server-Virtualisierung und Bladeservern auf das Netzwerkdesign

Autoren:

 
Autoren:   Martin Gödde September 2009 Berater amendos gmbh   Jörg Bujotzek Geschäftsführer amendos

Martin Gödde

September 2009

Berater

amendos gmbh

 
Gödde September 2009 Berater amendos gmbh   Jörg Bujotzek Geschäftsführer amendos gmbh amendos gmbh

Jörg Bujotzek

Geschäftsführer

amendos gmbh

amendos gmbh

amendos whitepaper

Grüner Deich 15

-

20097 Hamburg

-

040 / 248 276 00

-

www.amendos.de

- whitepaper - 1. Einführung 3 2. Ausgangslage 4 2.1. Netzwerk-Konzeption 4 2.2. Server 5

- whitepaper -

1. Einführung

3

2. Ausgangslage

4

2.1. Netzwerk-Konzeption

4

2.2. Server

5

2.3. Speicher

7

3. Heutige Anforderungen an das Rechenzentrum

7

4. Virtuelle Switches im Server-Bereich

9

4.1. IP-Konfiguration

10

4.2. Bandbreite und Redundanz

10

4.3. Unterschied zu physikalischen Switches

12

5.

Blades-Switches im Server-Bereich

12

5.1. Hersteller, Typen und Verantwortungsbereiche

13

5.2. Verschaltung der Blade-Switches und -Server

14

5.3. Virtueller Server und Bladeserver

16

5.4. Cluster und Bladeserver

18

6.

Ausblick und Fazit

20

Literatur

Abkürzungen

- whitepaper - 1. Einführung Täglich melden die Informations-Nachrichtendienste, dass Server-Virtualisierung im

- whitepaper -

1. Einführung

Täglich melden die Informations-Nachrichtendienste, dass Server-Virtualisierung im Rechenzentrum eine inzwischen fast unumgängliche Technik für die anstehenden Effizienzsteigerungen und den damit verbundenen Kostenreduzierungen zusammen mit der Einführung von „Green IT“ ist. Begleitet wird die Server-Virtualisierung einerseits von einem Aufgebot an Bladeserver-Systemen (u.a. nach dem Motto: physikalische Server, Speicher und Netzwerk in einer Box), andererseits erstreckt sich die Virtualisierung, nach Speicher und Server, nun auch auf die Netzwerkkomponenten, wie z.B. bei Extreme (Layer 3 Virtual Switching) oder Cisco (Catalyst 6500 Virtual Switching 1440 bzw. Nexus).

Zunächst ein Blick auf die Entwicklung der Anforderungen auf Seiten der Anwender: Die für die Geschäftsprozesse eingesetzten Applikationen werden immer anspruchsvoller, wenn es um reine Leistungsdaten geht (Rechenleistung, Netzanbindung, Verfügbarkeit etc.). Gleichzeitig wird vom IT-Betrieb erwartet, diese Anforderungen mit zunehmend professionell erbrachten Leistungen zu erfüllen, indem vereinbarte Service Level eingehalten werden und die Leistungen möglichst flexibel, also mit kurzen Anlaufphasen und Kündigungsfristen, genutzt werden können.

In der Umsetzung bedeutet dies, dass die IT-Betreiber ihren Kunden in der Regel keine „Unterstützung beim Betrieb eines Servers inkl. Netzanbindung“ mehr anbieten, sondern stattdessen IT-Produkte, die z.B. „Application Hosting Services“ heißen, angeboten werden, und die Bereitstellung einer IT-Infrastruktur zur Nutzung von Anwendungen inklusive aller erforderlichen Dienstleistungen einschließen. Dabei bleibt es dem IT-Betreiber überlassen, wie er die technischen Aufgaben zur Bereitstellung der notwendigen Infrastruktur löst.

Hier kommen zurzeit zahlreiche Neuerungen auf den Markt, nicht zuletzt durch Cisco’s Einstieg im Servergeschäft und der Antwort seitens der großen Server-Hersteller (HP, IBM). Neben Lösungen für die Server-Virtualisierung (allen voran VMware, aber auch Citrix und Microsoft) sind Gesamt-Lösungen verfügbar, die Speicher, Netzwerk, Bladeserver, Virtualisierungsunterstützung und die notwendigen Management-Tools „aus einer Hand“ bieten. IT-Verantwortliche mit konservativer Einstellung blicken zunächst skeptisch auf die neuen Lösungen, andere sehen hier große Potentiale für Einsparungen und Effizienzsteigerungen.

Welche Strategie die richtige ist, konservativ oder progressiv , ist von den jeweiligen Rahmenbedingungen im Unternehmen abhängig. Wichtig ist es zu erkennen, dass früher getrennte Welten (Server und Netzwerk) zukünftig stärker zusammenwachsen oder sogar verschmelzen. Es wird in jedem Fall auch zu entscheiden sein, ob diese neuen Szenarien herstellerabhängig (Szenarien basierend auf Gesamtlösungen wie Cisco‘s „Unified Computing System“- oder HP‘s „BladeMatrix“-Technologie) oder herstellerunabhängig angegangen werden.

Im Folgenden wird nun auf einige Aspekte eingegangen, die die Auswirkungen der neuen Servertechnologien auf die bestehenden Netzwerkkonzepte beschreiben. Hintergrund ist ein Ansatz, der die schrittweise Einführung der neuen Techniken „Server-Virtualisierung“ und „Bladeserver“ im Fokus hat. Es werden dabei Themen gestreift, wie z.B. Storage, die in diesem Papier nicht weiter behandelt werden, aber natürlich nicht weniger wichtig sind.

- whitepaper - 2. Ausgangslage Im Folgenden wird ein Überblick über die typische aktuelle Netzwerk-

- whitepaper -

2. Ausgangslage

Im Folgenden wird ein Überblick über die typische aktuelle Netzwerk- und Serverumgebung in Unternehmen gegeben, um die Grundlage für die Betrachtung der Einflüsse von Virtualisierung im Rechenzentrum und Bladeserver-Technologie auf die Netzwerkkonzeption zu schaffen.

2.1.

Netzwerk-Konzeption

Generell hat sich in den letzten Jahren an den Grundregeln des Netzwerkdesign nicht viel geändert. Kurz gesagt kann zusammengefasst werden, dass das Netzwerk die von den Clients kommenden Datenströme bündelt und zu den Servern führt – und umgekehrt.

Dabei werden meist die folgenden Ebenen des Netzwerkes unterschieden (siehe auch nebenstehende schematische Darstellung und Abbildung 1):

Access-Bereich In der Regel einfache Switches zum Anschluss der Endgeräte, typisch mit 24 oder 48 Ports. Da bei einem Ausfall nur eine gegrenzte Anzahl von Anwendern betroffen ist und die Konfiguration in diesen Bereich einfach und unkompliziert ist und schnellen Austausch möglich macht, wird auf redundante Auslegung in diesem Bereich meist verzichtet.

Distribution-Bereich Können in einem Netzwerk nicht alle Komponenten des Access- Bereiches direkt an dem Core angeschlossen werden (der begrenzende Faktor ist meist die Anzahl der zur Verfügung stehenden LWL-Verbindungen auf dem Campus), werden diese Accessverbindungen aggregiert (bzw. konzentriert). Da bei einem Ausfall die Anwender auf allen angeschlossen Access-Switchen betroffen sind, werden die Komponenten dieser Ebene meist redundant ausgelegt.

Core-Bereich Redundant ausgelegter „Kern“, der alle Bereiche des Netzwerkes miteinander verbindet.

Server-Bereich Eigener Bereich, in dem Server meist redundant ans Datennetz angebunden werden. In vielen Fällen sind aber auch die WAN- und Internet-Verbindungen hier anzutreffen, insofern wird auch von einem „Bereich Zentrale Dienste“ gesprochen.

Aufgrund der steigenden Anforderungen an die Verfügbarkeit des Datennetzes (bzw. der darauf laufenden Applikationen) sind alle Bereiche des Datennetzes mehr oder weniger redundant ausgelegt.

alle Bereiche des Datennetzes mehr oder weniger redundant ausgelegt. RZ und Netzwerkdesign September 2009 Seite 4/23
- whitepaper - Dies hat Auswirkung sowohl auf die Verschaltung der Komponenten als auch auf

- whitepaper -

Dies hat Auswirkung sowohl auf die Verschaltung der Komponenten als auch auf die eingesetzten Protokolle.

Im Access-Bereich (z.B. Etagenverteiler) erfolgt die redundante Verschaltung (getrennte Kabeltrassen bzw. Steigebereiche) der Layer-2-Switches an den Core- oder Distribution- Bereich. Als Gateway-Redundanz-Protokoll wird VRRP (oder HSRP) eingesetzt, auf weitere Protokolle (auch Spanning Tree) kann bei geeigneter Konzeption der IP-Netze verzichtet werden. Im Distribution- und Core-Bereich kommen Layer-3-Switches zum Einsatz, die durch Einsatz von Routing-Protokollen (in der Regel OSPF) sowohl den Ausfall einzelner Komponenten ausgleichen als auch Lastteilung auf den redundanten Verbindungswegen zwischen Gebäuden und dem Core-Bereich ermöglichen.

Der Server-Bereich (oder der „Bereich Zentrale Dienste“) ist aufgrund der Heterogenität der verschiedenen Dienste meist wesentlich „differenzierter“ als die oben genannten Bereiche. Das Zentrum bildet in der Regel mindestens ein Paar Layer-3-Switches, auf denen begrenzte IP-Segmente für 30 bis 50 Server eingerichtet werden.

Zusätzlich kommen Router (für die WAN-Kopplung) und Firewall-Systeme (DMZ, Internet) ebenso dazu wie Layer-2-Switches, die z.B. für Cluster-Lösungen, Management oder sonstiges gebraucht werden. Auch hier kann in der Regel auf Spanning Tree verzichtet werden. Es ist jedoch zwischen den Layer-3-Server-Switches die Konfiguration von redundanten „Trunks“ (oder Channels) obligatorisch, um der Gefahr der Bildung von „Split Networks“ vorzubeugen.

Da der Ausfall des zentralen Rechenzentrums nicht ausgeschlossen werden kann, werden in der Regel „Backup-Rechenzentren“ aufgebaut (oder vorbereitet), in denen u.a. die redundanten Aufschaltpunkte der einzelnen Gebäude liegen und in denen verschiedene Lösungen zur Übernahme der Serverdienste im Störfall vorbereitet oder aktiv sind. Dazu gehören z.B. Cluster-Dienste für besonders kritische Systeme (meist SAP-, Exchange- /Notes- und DB-Server), die nicht länger als „Stunden“ ausfallen dürfen oder vorbereitete „Cold-Standby-Systeme“, auf denen innerhalb von „1 bis 2 Tagen“ die Hauptfunktionen des Rechenzentrums wiederhergestellt werden können.

2.2.

Server

In den meisten Unternehmen ist eine Vielfalt von Server-Systemen verschiedenen Alters vorhanden, deren Lebendauer in manchen Fällen deutlich die häufig angesetzte kaufmännische Nutzungsdauer von drei bis fünf Jahren übersteigt.

Überwiegend sind Einzelserver vorzufinden, die zwischen 2 und 4 HE hoch sind, über eigenen Speicher (DAS) verfügen und über 1000 Mbps mit dem Netzwerk verbunden sind. Dazu kommen meist sogenannte „Pizzaschachteln“ (1-HE-Server), größere Server (über 4 HE) und seit ca. 4 Jahren virtuelle Server, sogenannte „virtuelle Maschinen“ oder „VMs“, bei denen es sich um eigenständige Server-Instanzen handelt, die jedoch nicht auf eigener Hardware basieren, sondern diese virtuell von ihren „Host“ genannten Wirts-Servern zur Verfügung gestellt bekommen.

Bei der Netzwerkanbindung der Server können in der Regel drei Anschluss-Varianten unterschieden werden (siehe auch Darstellung in Abbildung 1):

einfacher Server

• einfacher Server - whitepaper - • Anschluss mit 100/1000 Mbps ,kein redundanter Netzanschluss • Server

- whitepaper -

Anschluss mit 100/1000 Mbps ,kein redundanter Netzanschluss

Server mit höherer Verfügbarkeitsanforderung

Anschluss mit 100/1000 Mbps, redundanter Netzanschluss mit Adapter Teaming und Adapter Fault Tolerance (AFT)

Server mit höchsten Verfügbarkeitsanforderungen

2-Knoten-Cluster mit Knoten in verschiedenen Rechenzentren

Anschluss an das „Client-LAN“ mit 100/1000 Mbps, jeweils redundanter Netzanschluss mit AFT pro Knoten, dedizierte Heartbeat-Verbindung (Private-LAN)

Der Anschluss der virtuellen Server kann redundant erfolgen, wobei sich hier der Begriff „Redundanz“ bereits von den herkömmlichen Vorstellungen eines Netzwerkes unterscheiden kann. Zum einen liefern die Virtualisierungslösungen die Möglichkeit, die Netzanbindung der Hosts analog zu normalen Servern mit Adapter Fault Tolerance (AFT) zu konfigurieren. Um eine höhere Bandbreite zu erreichen, können zwei Netzwerkkarten auch als Trunk gebündelt und mit einem Switch verbunden werden. Die Redundanz erfolgt dann einerseits auf Netzwerkkarten-Ebene, andererseits können bei Ausfall eines Switches die VMs auf Hosts migriert werden, die mit einem anderen Switch im RZ verbunden sind und damit wird Redundanz erreicht.

Eine schematische Darstellung der geschilderten möglichen Ausgangslage ist die folgende Abbildung.

- whitepaper - Abbildung 1: Schematische Darstellung der Ausgangslage zu Netzwerk-Konzeption und Server 2.3. Speicher

- whitepaper -

- whitepaper - Abbildung 1: Schematische Darstellung der Ausgangslage zu Netzwerk-Konzeption und Server 2.3. Speicher Das
- whitepaper - Abbildung 1: Schematische Darstellung der Ausgangslage zu Netzwerk-Konzeption und Server 2.3. Speicher Das

Abbildung 1: Schematische Darstellung der Ausgangslage zu Netzwerk-Konzeption und Server

2.3.

Speicher

Das Thema „Speicher“ darf in diesem Zusammenhang grundsätzlich nicht vernachlässigt werden, ist aber aufgrund des Themenumfangs nicht Teil dieses Beitrags. Es kann jedoch festgehalten werden, dass zurzeit keine der auf Ethernet-Technologie abgebildeten Speicheranbindungen, d.h. weder iSCSI noch FCoE, als „state-of-the-art“ etabliert sind: hier werden in der Regel immer noch eigene Netze auf Basis von Fibre Channel verwendet. Insofern sollte die heutige Planung zukünftige Entwicklungen im Auge behalten, muss sie aber nicht zwangsläufig schon berücksichtigen.

3. Heutige Anforderungen an das Rechenzentrum

Dass die Dienstleistungen des Rechenzentrums oftmals in steigender Qualität und gleichzeitig stagnierenden oder sogar kleineren Budgets erbracht werden müssen, stellt die IT-Betreiber des Rechenzentrums vor neue Herausforderungen. Einige Anforderungen sollen hier kurz genannt und die „technologischen Antworten“ darauf aufgezeigt werden:

Server-Leistung

Die Anwendungen und ihre Nutzer erwarten eine steigende Leistung der IT- Infrastruktur, sei es die „reine“ Leistungsfähigkeit der Systeme (CPU, RAM), des

- whitepaper - Datenvolumens (Speicher) oder der Übertragungsgeschwindigkeit (Netzwerk- Bandbreite). • Moderne Server

- whitepaper -

Datenvolumens (Speicher) oder der Übertragungsgeschwindigkeit (Netzwerk- Bandbreite).

Moderne Server bieten Mehrfach-Kern-CPUs, mehrere Dutzend GByte Hauptspeicher, Terabyte an Datenspeicher und bis zu 10 Gbps Netzanschluss.

Ressourcenausnutzung

Die eingesetzten Systeme sollen optimal ausgelastet werden, um Investitionen in gering oder kaum genutzte Ressourcen zu reduzieren bzw. zu vermeiden.

Das vorhandene Personal soll möglichst effektiv eingesetzt werden, zusätzliche Ressourcen im Rechenzentrum, in der Regel externe Dienstleister für „Standard- Prozesse“ (e.g. Server aufsetzen, einbauen und verkabeln etc.) möglichst reduziert werden.

Mehrfachnutzung einzelner Systeme (z.B. durch Virtualisierung) und Entlastung des Personals durch Automatisierung (z.B. bei der Installation eines Servers) helfen die Effizienz und Auslastung der Ressourcen zu steigern.

Energie- und Kosteneinsparungen

Green-IT und steigende Strompreise sind Argumente, die seit einiger Zeit auch im Rechenzentrum zu berücksichtigen sind. Neben Verbesserungen der Raum- Infrastruktur (Belüftung, Kühlung, etc.) steht hier vor allen der Strom-Verbrauch pro Server im Vordergrund.

Neben intelligenten Komponenten zur Erfassung und Steuerung des Stromverbrauchs (Sensoren und Regler) stehen neue Komponenten zur Verfügung, die die zugeführte Energie effizienter nutzen und so den Stromverbrauch senken und die Umwelt und das Budget entlasten.

Konsolidierung bzw. „Komprimierung“ der Server

Der steigenden Anzahl von Anwendungen und Servern kann durch Schaffung zusätzlichen Raums entgegnet werden. Solche Projekte lassen sich ggf. mit der Modernisierung und Vergrößerung des Rechenzentrums oder der Schaffung eines redundanten Rechenzentrums realisieren, es werden aber stattdessen in der Regel Projekte zur Server-Konsolidierung gestartet. Durch die konsequente Nutzung beispielsweise „gemeinsamer“ Datenbankserver (sogenannte „Shared Database Applikation Hosting Services“) und der konsequente Abschaltung nicht mehr produktiver Systeme, soll das Wachstum der Serveranzahl begrenzt werden.

Um mehr Server pro Rack bzw. Rechenzentrum zu realisieren, sollen kleinere Bauweisen der Server installiert werden. Dies ist u.a. durch die Loslösung der einzelnen Server vom Speicher (interne Festplatten für Daten etc.) möglich. Angeboten werden sogenannte „Pizzaschachteln“ (1 HE-Server) und seit gut 4 Jahren die Blade-Server, mit denen sich problemlos 30 Server und mehr in einem 40HE-Schrank realisieren lassen.

Durch Virtualisierung der Server soll eine weitere Steigerung des „Komprimierungsgrades“ erreicht werden; es sind so über 100 Server in einem 40HE- Schrank m Bereich des Möglichen.

- whitepaper - Oftmals steht dem allerdings eine Abnahme des „Konsolidierungsgrades“ entgegen, vor allem dann,

- whitepaper -

Oftmals steht dem allerdings eine Abnahme des „Konsolidierungsgrades“ entgegen, vor allem dann, wenn von den Applikations-Managern zusätzliche, kostenfrei bereitgestellte „virtuelle Maschinen“ für Test-Umgebungen in Anspruch genommen werden, die ohne die Virtualisierung aus organisatorischen oder finanziellen Gründen nicht möglich wären.

Service-Qualität und Kostenverrechnung

Die Bereitstellung der IT-Leistungen sollen so flexibel wie möglich realisiert werden, um die Geschäftsprozesse in einem sich immer schneller wandelndem Umfeld optimal zu unterstützen. Dazu gehört auch, dass die Bereitstellungszeiten reduziert werden und nicht mehr benötigte Ressourcen schnell aus Sicht des Kunden abgebaut werden können und keine Kosten mehr produzieren.

Dies erfordert, dass bei der Bereitstellung der IT-Ressourcen (hier also Server) ein hoher Grad an Standardisierung, Automatisierung, Bevorratung und Wiederverwendbarkeit erreicht wird. Unterstützt wird dies z.B. durch Werkzeuge, die bei Bedarf, teilweise durch automatisierte Prozessschritte, neue Server reservieren, vorkonfigurieren, so dass diese dem Anwender schnell verfügbar gemacht werden können. Im Idealfall wird der gesamte Vorgang der Bereitstellung zukünftig sogar vollautomatisch und innerhalb von Minuten erfolgen.

Welche Anforderungen bzw. technischen Lösungen für den einzelnen IT-Betreiber relevant sind, hängt von zahlreichen Faktoren ab. Auch wenn einige Szenarien, die bei einem vollständigen Umstieg auf die neuen Lösungen, seien es nun neue Server, mit und ohne Blades und Virtualisierung, einen ROI in weniger als 24 Monaten bei gleichzeitiger Leistungs- und Servicequalitäts-Steigerung versprechen, ist in vielen Fällen eine schrittweise Einführung der neuen Technik grundsätzlich sinnvoller und in der Regel kostengünstiger.

Besonders „kritisch“ sind viele der neuen Techniken aus der Sicht der Netzwerkbetreiber zu betrachten. Durch Virtualisierung, aber auch durch Einsatz von Bladeservern und Bladeserver-Switches, wird eine von der Serverseite getriebene Umgestaltung der Netzwerkkonfiguration forciert, indem neue Elemente (virtuelle Switches, Blade-Switches) in den Netzwerkverbund eingebracht werden. Es empfiehlt sich, rechtzeitig Erweiterungen im eigenen Netzwerkdesign und im Betriebskonzept für die neuen Techniken zu planen.

Auf diese zusätzlichen Netzwerkelemente soll nun im Folgenden eingegangen werden.

4. Virtuelle Switches im Server-Bereich

Bevor die Netzwerktechnik beleuchtet wird, ein kurzer Satz zu den Vorteilen der Virtualisierung. Server-Virtualisierung ermöglicht es den RZ-Betreibern, den Applikationsmanagern relativ schnell und kostengünstig zusätzliche bzw. neue Server zur Verfügung zu stellen. Teilweise können auch physikalische Server, deren Hardware ausgetauscht werden muss, ohne Neuinstallation in virtuelle Server migriert werden (sogenannte P2V-Migration). Gleichzeitig steigt die Auslastung der Serverhardware; der bessere Auslastungsgrad kann zur Kostenreduktion beisteuern.

Virtuelle Switches stellen dabei die Schnittstelle zwischen den virtuellen Servern und dem physikalischen Datennetz dar. Sie werden auf den „Hosts“ installiert und stellen gegenüber den virtuellen Servern VLANs dar, die über dedizierte oder gemeinsam genutzte Netzwerkkarten des Hosts mit einem Netzwerkswitch verbunden sind.

- whitepaper - Die Virtuellen Switches, oft einfach als vSwitches bezeichnet, können dazu verwendet werden,

- whitepaper -

Die Virtuellen Switches, oft einfach als vSwitches bezeichnet, können dazu verwendet werden, virtuelle Server auf einem Host netzwerktechnisch zu trennen (separate VLANs). Sie haben jedoch auch Einfluss auf die Netzwerkkonfiguration der „externen“ Switches, wenn Funktionen wie z.B. Tagging verwendet werden müssen, um die verschiedenen VLANs über einzelne Netzwerkkarten mit dem Datennetz zu verbinden.

4.1. IP-Konfiguration

Aus Sicht der Netzwerkkonfiguration ist beim Einsatz virtueller Server folgendes zu beachten.

Der Host, d.h. der physikalische Server, der die virtuellen Server oder „Guests“ bereitstellt, kann wie ein „normaler“ Server mit dem Netz verbunden werden. Der Datenverkehr zu den virtuellen Maschinen wird einfach über die Netzwerkkarte des Hosts „gebridget“. Dies ist die denkbar einfachste und stabilste Konfiguration und für das Datennetz vollständig transparent.

Es besteht jedoch eine grundlegende Einschränkung: alle virtuellen Maschinen müssen im selben IP-Segment wie der Host sein. Desweiteren müssen alle Hosts, die ein Verschieben von virtuellen Maschinen untereinander unterstützen (vMotion bei VMware bzw. Live Motion bei Citrix), im selben IP-Segment sein.

Der Host wird mit dem Datennetz verbunden, es wird jedoch „getaggt“. Das heißt, es werden über eine einfache physikalische Verbindung unterschiedlich markierte (getaggte) VLANs übertragen.

Dazu ist es erforderlich, die unterschiedlichen VLANs auf dem Host (via vSwitches) UND am Port im Datennetz einzurichten, die Netzwerkskonfiguration muss zwischen dem Server- und Netzbetreiber abgestimmt und einheitlich sein.

Der Vorteil besteht darin, über die virtuellen Switches mehrere VLANs für virtuelle Maschinen auf einem Host verwenden zu können, ohne dass eine strikte Abhängigkeit zum primären IP-Segment des oder der Hosts besteht.

4.2. Bandbreite und Redundanz

Ein weiteres Thema ist die Bandbreite, mit der der Host angebunden wird. Je nach Anwendung und Nutzung, können 10 bis 20 virtuelle Server auf einem (entsprechend mit Arbeitsspeicher ausgestattetem) Host betrieben werden.

Muss der Host dann auch mit 10- bis 20-mal höherer Bandbreite als die virtuellen Server vernetzt sein?

Für die allermeisten Umgebungen kann dies wohl verneint werden. Eine gewisse Überbuchung ist im Server-Bereich nicht zu vermeiden, wenn Bandbreitenbedarf und Aufwand in einem vernünftigen Verhältnis stehen sollen. Mit einem Verkehrswert von 1/10 Erlang kalkuliert, wird für einen mit bis zu 10 virtuellen Maschinen beladenen Host eine einfache Gbps-Anbindung bzw. bei 20 VMs ein Trunk mit 2 mal Gbps ausreichen. Der Verkehrswert ist allerdings abhängig von den Anwendungen auf den virtuellen Maschinen.

- whitepaper - Neben der reinen Bandbreite sind außerdem folgende Aspekte bei der Anzahl der

- whitepaper -

Neben der reinen Bandbreite sind außerdem folgende Aspekte bei der Anzahl der erforderlichen Netzwerkkarten zu beachten:

Es ist eine zusätzliche dedizierte Verbindung zwischen dem Host und dem Control- Center (Virtual Center bzw. vCenter) erforderlich.

Bei Ausfall der Netzwerkverbindung (fehlende Netzwerkredundanz) fällt automatisch die Konnektivität aller auf dem Host geladenen virtuellen Server weg. Dies kann zum Beispiel bei VMware zwar durch interne Funktionen (Serverredundanz durch High Availability und vMotion) ausgeglichen werden, erfordert jedoch eine sehr genaue Kenntnis darüber, welche Hosts aktuell mit welchem Switch verbunden sind und wie viele virtuelle Maschinen durch Verlagerung auf Hosts mit aktiver Datenverbindung wirklich redundant abgesichert sind. Hinweis: Auch mit den neuesten Funktionen in VMware vSphere können zwar „kritische“ virtuelle Maschinen (VMs) bei Ausfall eines Hosts von einem verbleibenden Host übernommen werden, es werden auf diesem jedoch keine „unkritischen“ VMs heruntergefahren, um entsprechende Ressourcen freizugeben.

Unter der Annahme, dass ein Host über drei Netzwerkkarten verfügt, sind nun verschiedene Anschlussvarianten möglich:

Eine Management-Verbindung plus 2 Verbindungen, die per Trunk (Bündelung der Leitungen zwecks höherer Bandbreite) zusammengeschaltet und mit einem Server- Switch verbunden sind oder

eine Management-Verbindung plus 2 Verbindungen, die - ohne Leistungsbündelung - in einem Fail-Over-Team konfiguriert sind (AFT) und redundant mit zwei Server-Switches verbunden sind. Hinweis zu VMware: Der Fail-Over-Mechanismus prüft nicht nur den Link-Status zum Switchport, sondern unterstützt zudem sogenanntes „Beacon Probing“, vergleichbar mit einem Ping auf eine entfernte Zieladresse, um auch Ausfälle hinter dem direkt verbundenen Server-Switch aufzuspüren.

Der große Vorteil der zweiten Lösung besteht darin, dass Server- und Netzwerkbetrieb so klar getrennt sind, ein Ausfall im Netz (z.B. eines Server-Switches) also keine Reaktion seitens der Server erfordert.

Beide genannten Varianten stehen für einfache Lösungen, in deren Fokus entweder auf Bandbreite oder Redundanz liegt. Zusätzliche Varianten bestehen in der Möglichkeit, einzelne Netzwerkkarten oder Teams dediziert einzelnen VMs zur Verfügung zu stellen. Es sollte in diesem Zusammenhang aber immer beachtet werden, dass zusätzliche Konfigurationen im Fehlerfall das Trouble Shooting erschweren können und damit nicht mehr einfach zu kontrollieren sind.

- whitepaper - Abbildung 2: Einsatz virtueller Switches, mit und ohne VLAN-Tagging 4.3. Unterschied zu

- whitepaper -

- whitepaper - Abbildung 2: Einsatz virtueller Switches, mit und ohne VLAN-Tagging 4.3. Unterschied zu physikalischen

Abbildung 2: Einsatz virtueller Switches, mit und ohne VLAN-Tagging

4.3. Unterschied zu physikalischen Switches

Bei den virtuellen Switches muss beachtet werden, dass sie sich nicht wie „normale“ Switches verhalten, sondern eher wie Netzwerkkarten beim Adapter Teaming.

Das heißt, sie leiten keine Broadcasts oder Hello-Pakete zwischen den Netzwerkports weiter. Damit besteht keine Gefahr, dass sich durch die redundante Verschaltung eine Schleife (Loop) bilden könnte oder durch Einsatz des Spanning-Tree-Protokolls unterdrückt werden müsste.

5. Blades-Switches im Server-Bereich

Parallel zur Virtualisierung hat sich die Bladeserver-Technologie entwickelt. Im Folgenden wird der Fokus auf die in Blade-Enclosures integrierten Switches sowie deren Anbindung an das Gesamtnetz gelegt.

- whitepaper - 5.1. Hersteller, Typen und Verantwortungsbereiche Inzwischen werden geeignete Bladeserver-Systeme von allen

- whitepaper -

5.1. Hersteller, Typen und Verantwortungsbereiche

Inzwischen werden geeignete Bladeserver-Systeme von allen namhaften Herstellern von Serverlösungen angeboten, allen voran HP und IBM, aber natürlich auch FCS, Dell und Sun.

Sie alle versprechen, neben der durch die kompakte Bauweise erreichte Platzersparnis im Rack, auch eine deutlich bessere Energieeffizienz und dadurch Strom- und Kostenersparnis für die Kunden sowie Aufwandsreduzierung durch zusätzliche Managementtools zur voll- oder semiautomatischen Installation der Server.

Im Folgenden werden wir uns jedoch auf die Netzwerkseite konzentrieren. Hier stehen Blade-Switches, also Module, die die Konnektivität zwischen der Backplane des Blade- Chassis (Enclosure) und damit der Bladeserver einerseits und dem Datennetz (d,h, der Server-Switches) andererseits herstellen. Generell sind zwei Varianten dieser sogenannten „Interconnects“ oder „Connection Modules“ zu unterscheiden:

Blade-Switches: aktive Komponenten, die meist bis zu 24 x 1 Gbps-Ethernet-Ports bereitstellen

Pass-Through-Module: passive Komponenten, die die Netzwerkverbindung vom Server Richtung Server-Switch „durchschleifen“

Die Blade-Switches kommen von Cisco (alle Server-Hersteller), Blade Networks (mind. HP und IBM) und und zum Teil von den Herstellern selbst (Dell, FCS, Sun). Die Bandbreiten reichen inzwischen von Gigabit-Ethernet auf allen Ports über Gigabit-Downlinks und 10- Gigabit-Uplinks bis hin zu 10-Gigabit auf allen Ports (entsprechende Netzwerkkarten oder „Mezzanine Cards“ auf den Bladeservern vorausgesetzt).

Nachdem es sich anfangs ausschließlich um einfache (und kostengünstige) Layer-2- Switches handelte (vergleichbar den Access-Switches), werden nun, im Zuge der erfolgreichen Ausbreitung der Bladeserver, entsprechend höher entwickelte Systeme angeboten, die neben IP-Routing auch erweiterte Funktionen (Quality of Service, Security etc.) bieten.

Im Gegensatz zu den Virtuellen Switches ist klar, dass es sich bei Blade-Switches um aktive Netzwerkkomponenten handelt und dementsprechend nur von den für diesen Bereich verantwortlichen Personen administriert werden sollten. Es ist aber immer wieder zu beobachten, dass die Switches, die ja fest mit dem Blade-Enclosure verbunden sind und dessen Management-Modul den Zugriff auf die Switches gewähren kann, eben auch von Server-Administratoren konfiguriert werden, unter anderem auch nur „mal eben zum Testen“ und nicht in Abstimmung mit den Netzwerkadministratoren. Im besten Fall passiert nichts Unvorhergesehenes, im schlimmsten Fall können aktivierte Protokolle wie Spanning-Tree zu einem Ausfall des gesamten Server-Bereichs führen.

Grundsätzlich erfordert der Einsatz von Bladeservern eine klare organisatorische Regelung, wer (Netzwerkadministrator, Serveradministrator) für welche Aufgaben zuständig ist. Dies schließt Informationspflichten und Delegationsoptionen mit ein. Insofern kann es eine Strategie sein, auf Blade-Switches ganz zu verzichten und ausschließlich mit den passiven Pass-Through-Modulen zu arbeiten. Und objektiv betrachtet spricht auch nicht dagegen, wenn auf den Server-Switches genügend Ports zur Verfügung stehen. Der Vorteil ist jedenfalls, dass das bestehende Netzwerkkonzept wegen des Einsatzes von Bladeservern nicht angepasst werden muss.

- whitepaper - Wenn dies jedoch nicht möglich oder gewünscht ist, muss die Verschaltung und

- whitepaper -

Wenn dies jedoch nicht möglich oder gewünscht ist, muss die Verschaltung und Administration der dann eingesetzten Blade-Switches, wie bei allen aktiven Netzkomponenten, entsprechend sorgfältig geplant und ein Zugriffskonzept für die Komponenten umgesetzt sein (Radius etc.).

5.2. Verschaltung der Blade-Switches und -Server

Im Prinzip können Blade-Switches wie Access-Switches im Front-End-Bereich angebunden werden. Da die Server, im Gegensatz zu PC-Endgeräten, in der Regel jedoch redundant angeschlossen werden, sind mindestens zwei Blade-Switches pro Enclosure zu konfigurieren.

Dabei ist jedoch zu beachten, dass die meisten Server (z.B. Windows-Server von HP) im Rahmen der Fail-Over-Konfiguration „nur“ den Linkstatus der Netzwerkkarte berücksichtigen (erweiterte Funktionen wie Beacon Probing, z.B. im „HP Intelligent Network Pack“ enthalten, sind gegen Aufpreis verfügbar).

Das heißt, dass der Fail-Over-Mechanismus des Servers (AFT) zwar auf einen Ausfall des Blade-Switches reagiert, nicht aber auf einen Ausfall „hinter“ dem Switch (z.B. die Verbindung zwischen Blade- und Server-Switch).

(z.B. die Verbindung zwischen Blade- und Server-Switch). Abbildung 3: Ausfallszenarien, ohne internen Trunk Um dem
(z.B. die Verbindung zwischen Blade- und Server-Switch). Abbildung 3: Ausfallszenarien, ohne internen Trunk Um dem

Abbildung 3: Ausfallszenarien, ohne internen Trunk

Abbildung 3: Ausfallszenarien, ohne internen Trunk Um dem vorzubeugen, sind die beiden Blade-Switches

Um dem vorzubeugen, sind die beiden Blade-Switches miteinander zu koppeln. Zu diesem Zweck verfügen die meisten Blade-Switches über „interne Trunk-Ports“. Diese Ports können zur Konfiguration eines Trunks (nach IEEE 802.3ad oder Cisco EtherChannel)´verwendet werden.

- whitepaper - Abbildung 4: Ausfallszenarien, mit internem Trunk Wie im Access-Bereich besteht auch hier

- whitepaper -

- whitepaper - Abbildung 4: Ausfallszenarien, mit internem Trunk Wie im Access-Bereich besteht auch hier die

Abbildung 4: Ausfallszenarien, mit internem Trunk

Wie im Access-Bereich besteht auch hier die Möglichkeit, durch ein geeignetes IP-Adress- Konzept auf Spanning-Tree ganz zu verzichten, indem pro Enclosure ein dediziertes IP- Segment (VLAN) konfiguriert wird und jeder Blade-Switch mit genau einem Server-Switch verbunden wird. Auf dem Trunk zwischen den Server-Switches wird dieses VLAN nicht übertragen und es entsteht kein Loop.

Warum sollte denn überhaupt auf Spanning-Tree verzichtet werden? Hier gilt zu bedenken, dass es sich bei den Blade-Switches oft um „einfache“ Switches handelt, evtl. von einem anderen Hersteller als die Server-Switches, und sich diese Kombination in der Vergangenheit häufig als nicht sehr stabil erwiesen hat. Viel wichtiger ist allerdings, dass bei einer Störung (z.B. Ausfall eines Switches oder einer Switch-zu-Switch-Verbindung) die Spanning-Tree-Struktur (Topologie) erneuert wird und durch den relativ langsamen Regenerationseffekt auch von RSTP ganze Bereiche temporär ausfallen können.

Um dieses Szenario zu verdeutlichen: werden in einem RZ ausschließlich Blades eingesetzt und diese über Blade-Switches, die wiederum mit den zentralen Server-Switches verbunden sind, angeschlossen, kann die Störung eines einzelnen Blade-Switches (z.B. ein „Flattern“ der Verbindung zum Server-Switch) dazu führen, dass durch regelmäßige STP-Topology Changes die Netzwerkkommunikation im gesamten Serverbereich (alle angeschlossenen Blade-Server) zusammenbricht.

- whitepaper - Abbildung 5: Verschaltung von Bladeservern und „schleifen-freies“ Design 5.3. Virtueller Server und

- whitepaper -

- whitepaper - Abbildung 5: Verschaltung von Bladeservern und „schleifen-freies“ Design 5.3. Virtueller Server und

Abbildung 5: Verschaltung von Bladeservern und „schleifen-freies“ Design

5.3. Virtueller Server und Bladeserver

Der Ansatz, virtuelle Server auf Bladeserver-Systemen zu realisieren, ist bei verschiedenen Herstellern zu beobachten. Das Stichwort ist Cloud Computing und wird von den Anbietern unterschiedlich interpretiert, so z.B. als „Unified Computing“ (Cisco), „Blade Frame“ (FCS) oder „BladeSystem Matrix“ (HP). Kern dieser Lösungen ist meist eine „Box“, die neben den Servern (Blades) auch Netzwerk, Speichernetz und Speicher sowie deren Virtualisierung und Management „aus einer Hand“ bietet.

Aber auch schon vor dem Cloud-Computing-Hype wurde, im Sinne der Konsolidierung im RZ, diese Lösung eingesetzt und ist insofern nicht wirklich neu. Die Schwierigkeit besteht oft darin, die einzelnen Elemente aus Blade- und VM-Technik in bestehende RZ-Konzepte zu integrieren, wenn diese nicht als „Box“ angeschafft wurden. Gründe dafür, nicht eine geschlossene Hersteller-Lösung zu implementieren, können sein, dass in der „Box“ verschiedene Techniken gemischt sind (Server, Netzwerk, Storage) und damit schnell eine Hersteller-Abhängigkeit entsteht oder dass für eine Technik (z.B. Netzwerk) Komponenten dieses Herstellers verwendet werden, die bei einem Mitbewerber sowohl besser als auch preiswerter angeboten werden. Ziel sollte es sein, Lösungen einzusetzen, die auf standardisierten Techniken basieren und eine optimale Unterstützung sowohl beim Aufsetzen der virtuellen Maschinen als auch bei Zuweisen einzelner Ressourcen bieten.

- whitepaper - Durch die Verwendung der Bladeserver geht einiges an Flexibilität verloren, da sinnvolle

- whitepaper -

Durch die Verwendung der Bladeserver geht einiges an Flexibilität verloren, da sinnvolle Netzwerkkonzepte, wie z.B. ein durchgehend „schleifen-freies Design“, durch die Bindung der Server an ihre „Enclosures“ erschwert werden. Dennoch können ein paar einfache Ansätze hier weiterhelfen:

ein guter und einfacher Ansatz, Server und deren IP-Segmente zu administrieren, ist: die IP-Adresse ist nicht an den Server gebunden, sondern dieser wird über seinen DNS- Namen angesprochen. Bei der Verwendung von Bladeservern (Verschaltung siehe Abbildung 5) bedeutet dass, dass ein Server, der „von einem Enclosure in ein anderes wandert“ (d.h. verschoben wird), seine IP-Adresse ändern muss (das schleifen-freie Design wird ja erst möglich, wenn ein IP-Segment auf ein Enclosure beschränkt ist).

Leider ist das nicht möglich, wenn virtuelle Server und Verschiebe-Mechanismen (z.B. vMotion) ins Spiel kommen. Hier muss ein Server ja verschoben werden können, ohne dass sich die IP-Adresse ändert.

Wie ein schleifen-freies Design in der Verschaltung von 2 Enclosures dennoch erreicht werden kann, wird im folgenden Kapitel über Cluster und Bladeserver gezeigt, da hier eine ähnliche Problematik vorliegt.

Da virtuelle Server bzw. deren Hosts in der Regel verstärkt Anforderungen an die Netzwerkanbindung stellen (vor allem eine höhere Anzahl an Netzwerkkarten), empfiehlt es sich, über separate Enclosures für diese Server nachzudenken.

Während für gewöhnliche Server eine redundante Netzwerkverbindung (neben der Anbindung ans SAN) in der Regel ausreicht, wird für VM-Hosts noch mindestens eine zusätzliche Nerzwerkkarte für die Management-Verbindung gefordert.

Eine entsprechende Enclosure-Konfiguration könnte, zusätzlich zu den Blade- Switches, z.B. Pass-Through-Module enthalten.

VM-Hosts lassen sich vor diesem Hintergrund sinnvoll mit Cluster-Knoten in einem Enclosure kombinieren, da diese ebenfalls, im Gegensatz zu gewöhnlichen Servern, zusätzliche Netzwerkkarten benötigen (Heartbeat).

Netzwerk-Verbindungen der Hosts können bei Verwendung der Pass-Through-Module „durchgeschliffen“ werden, damit entfällt die oben genannte Einschränkung hinsichtlich der IP-Adressen.

Es werden die Verbindungen durchgeschliffen, die von den produktiven VMs genutzt werden, deren IP-Adresse sich auch nach einem Verschieben nicht ändern darf. Die Management-Verbindung des Hosts kann davon unabhängig über die Switches im Enclosure erfolgen, da dieser ja nicht bewegt und damit seine IP-Adresse fest mit dem Enclosure verbunden bleibt.

Es werden, z.B. für die unterschiedlichen Service-Levels, Gruppen von Hosts gebildet, so dass die Anzahl von Host-Systemen, die aufgrund der im Service Level festgelegten Verfügbarkeit über automatische oder semi-automatische Verschiebe-Mechanismen verfügen müssen, begrenzt bleibt.

In vielen Umgebungen lässt sich so die Anzahl von Hosts, die zu einer Gruppe gehören, auf ein Enclosure beschränken.

- whitepaper - • Für Hochverfügbarkeitslösungen (zwei Rechenzentren), die auf der Verwendung von mindestens zwei

- whitepaper -

Für Hochverfügbarkeitslösungen (zwei Rechenzentren), die auf der Verwendung von mindestens zwei Enclosures basieren, kann auf die eben schon verwiesene Lösung im Kapitel Cluster und Bladeserver zurückgegriffen werden.

Es liegt auf der Hand, dass es durch den Einsatz von Blade-Switches und virtuellen Switches zu einer höheren Komplexität bezüglich des Netzwerkdesigns im Rechenzentrum kommt.

Um dem zu begegnen, reicht in den meisten Fällen bereits die Einhaltung einfacher Regeln aus. Nach einer Analyse der tatsächlichen Anforderungen (ggf. unter Nicht-Nutzung neuer „Features“, die nicht unbedingt benötigt werden) ist es möglich, ein sauberes Netzwerkkonzept aufrecht zu erhalten und erfolgreich gegenüber den neuen Entwicklungen auf dem Servermarkt „zu verteidigen“. Verteidigung heißt hier nicht, sich gegen die notwendigen Anpassungen zu verschließen, sondern soweit wie möglich aus einem funktionierenden Netzdesign heraus Grenzen zu setzen, an die sich die Implementierung der neuen Lösungen orientieren muss.

5.4. Cluster und Bladeserver

Es ist im Einzelfall zu prüfen, ob Bladeserver sich als Basis für Clusterlösungen eignen. Dies hängt unter anderem natürlich von der Anzahl der Cluster ab: für einzelne Anwendungen (z.B. Exchange, CRM o.ä.) sind gegebenenfalls einzelne Server geeigneter, bei Gruppen von Clustern ist der Einsatz von Bladeservern eher sinnvoll. Dies hängt vor allem von der aufwendigeren Konfiguration (z.B. Heartbeat-Verbindungen) und der Tatsache ab, dass durch die zusätzlichen Komponenten die Verfügbarkeitsanforderungen meist schwerer einzuhalten sind (die Verfügbarkeit der Gesamt-Lösung ergibt sich aus der Multiplikation der Einzel-Verfügbarkeiten).

Generell spricht jedoch nichts gegen eine solche Lösung. Bei der redundanten Netzanbindung sind jedoch einige Besonderheiten zu beachten.

Beide Clusterknoten müssen (natürlich) im selben IP-Segment adressiert werden, schließlich „teilen“ sie sich eine IP-Adresse,

wenn möglich, sollte auf Spanning-Tree verzichtet werden, da sich ein mögliches Fehlverhalten der Switches ggf. auf beide Knoten auswirkt,

die Knoten sollten in unterschiedlichen Enclosures und, wenn möglich, in unterschiedlichen Rechenzentren (oder Brandabschnitten) untergebracht sein, um auch einen Komplettausfall des Serverraums kompensieren zu können,

dedizierte Heartbeat-Verbindungen lassen sich bei einzelnen Clustern via Pass-Through- Modul realisieren, bei Gruppen ist der Einsatz dedizierter „Heartbeat-Switches“ in den Blade-Enclosures sinnvoll, da so das Einsparen von LWL-Leitungen zwischen entfernten Rechenzentren möglich sind.

Eine mögliche Konfiguration ist in der folgenden Abbildung dargestellt. Es werden zwei Enclosures in der Art verschaltet, dass

alle beteiligten Blade-Switches in einem IP-Segment liegen,

- whitepaper - • keine Schleifen bzw. Loops entstehen, die per Spanning-Tree aufgelöst werden müssten,

- whitepaper -

keine Schleifen bzw. Loops entstehen, die per Spanning-Tree aufgelöst werden müssten,

der Standard-Redundanz-Mechanismus seitens der Server (AFT) funktioniert.

seitens der Server (AFT) funktioniert. Abbildung 6: „Cluster“-Verschaltung von Bladeservern und
seitens der Server (AFT) funktioniert. Abbildung 6: „Cluster“-Verschaltung von Bladeservern und

Abbildung 6: „Cluster“-Verschaltung von Bladeservern und „schleifen-freies“ Design

Dazu wird jeweils ein Blade-Switch pro Enclosure (Blade-Switch I) aktiv genutzt. Diese beiden Switches werden, wie ein „Standard-Serverswitch-Paar“, über einen redundanten Trunk gekoppelt (auch hier: IEEE 802.3ad oder EtherChannel). Der zusätzliche Switch pro Enclosure (Blade-Switch II) dient der Ausfallsicherheit und ist jeweils mit dem aktiven Switch des anderen Enclosures verbunden.

Zusätzliche Verbindungen (z.B. Heartbeat) können über Pass-Through-Module oder weitere Blade-Switches realisiert werden.

Bei dieser Verschaltung ist zu beachten, dass auf den Servern das Adapter-Teaming mit Fehlertoleranz (AFT) so konfiguriert wird, dass der „Preferred Adapter“ des Teams mit dem Blade-Switch I verbunden ist. Geschieht dies nicht, ist die Verbindung nicht redundant (siehe Abbildung 3: Ausfallszenarien, ohne internen Trunk).

- whitepaper - Abbildung 7: „Preferred Adapter“-Konfiguration (aktiv/passiv), am Beispiel HP Proliant Diese Art der

- whitepaper -

- whitepaper - Abbildung 7: „Preferred Adapter“-Konfiguration (aktiv/passiv), am Beispiel HP Proliant Diese Art der

Abbildung 7: „Preferred Adapter“-Konfiguration (aktiv/passiv), am Beispiel HP Proliant

Diese Art der Verschaltung ist ebenfalls für die Hosts virtueller Maschinen geeignet und zwar dann, wenn diese in einem IP-Segment adressiert werden müssen und, aus bereits genannten Gründen, auf Spanning Tree verzichtet werden soll.

Die Enclosures samt Cluster-Knoten und VM-Hosts können auf verschiedene Rechenzentren verteilt werden, eine Migration (Verschieben des aktiven Knotens bzw. vMotion-vergleichbare Funktion) zwischen den Rechenzentren ist möglich (immer vorausgesetzt, es steht ein entsprechendes SAN RZ-übergreifend zur Verfügung).

Empfehlung: Es hat sich in der Praxis als hilfreich erwiesen, wie oben bereits erwähnt, Verfügbarkeitsgruppen entsprechend der mit den Kunden vereinbarten Service Level zu definieren und für die Systeme mit hohen Verfügbarkeitsanforderungen ein entsprechendes Enclosure-Paar einzurichten, auf dem die betreffenden Systeme laufen, unabhängig davon, ob es sich um Cluster oder virtuelle Maschinen handelt.

6. Ausblick und Fazit

Die Server-Virtualisierung hat das Potential, sich wesentlich schneller in den Rechenzentren auszubreiten als die Speicher-Virtualisierung, die auch bei bestehenden SANs noch nicht immer zum Einsatz kommt, obwohl sie durch die Trennung von physikalisch installiertem und in virtuellen Einheiten angebotenem Speicher eine deutlich flexiblere Nutzung und höhere Auslastungsgrade ermöglicht.

Eine Technik, die fast immer in Zusammenhang mit virtuellen Servern genannt wird, heißt Bladeserver. Diese Kombination verspricht laut den Herstellern, die geeignete Antwort auf Anforderungen zu Kostenreduktion und Umweltschutz zu sein. Server-Virtualisierung heißt aber auch, neben gemeinsam genutztem Speicher, das Netzwerk auf die kommenden Herausforderungen anzupassen.

Ansätze dafür, wie sich das Netzwerk weiterentwickeln wird, sind bereits deutlich zu sehen. Ein Schlagwort heißt „Konvergenz“ (z.B. in „FC over Convergence Enhanced Ethernet“). Damit ist jedoch nicht mehr die „Annäherung“ der TK-Technik und Datentechnik (VoIP) gemeint, sondern die „Annäherung“ zwischen Datennetz (LAN) und Speicher (SAN).

- whitepaper - Nachdem 10-Gbps-Ethernet verfügbar ist und damit ausreichend Bandbreite zur Verfügung steht, steht

- whitepaper -

Nachdem 10-Gbps-Ethernet verfügbar ist und damit ausreichend Bandbreite zur Verfügung steht, steht FCoE kurz vor der endgültigen Verabschiedung des Standards. Es ist nicht vorauszusehen, wie sich dieser Standard durchsetzen wird, aber dass Netzwerk und Speicher zusammenwachsen, ist kaum anzuzweifeln. Neben diesen „I/O-Fabriken“ werden auch der Server, die Server-Virtualisierung und ggf. weitere Komponenten Teil dieser „konvergenten“ Welt sein.

Wie die aussehen kann, zeigen fertige Lösungen, die sowohl von Netzwerk- (z.B. Cisco) wie auch Server-Herstellern (z.B. HP, FCS) angeboten werden.

Aber auch bei der schrittweisen Einführung der neuen Techniken steht eine wachsende Auswahl von Produkten zur Verfügung, die die neuen Anforderungen in diesem Bereich wiederspiegelt. Bestes Beispiel ist ein „virtueller Switch“, der Nexus 1000V, der von Cisco für die Verwendung auf VMware-Hosts angeboten wird. Er ist Teil einer Strategie, mit der VMware größtmögliche Flexibilität bei der Migration einzelner VMs zwischen den Hosts erreichen möchte (Distributed Switch). Werden die VMs verschoben, soll ein gemeinsames Management dafür sorgen, dass die Netzwerkkonfiguration (auch Switch-seitig) mit migriert werden kann. Doch auch wenn hier neue Management-Tools zum Einsatz kommen, behält doch der grundsätzliche Aussage Gültigkeit, dass ein übergreifendes Netzwerkkonzept das beste Mittel ist, einen möglichst reibungslosen Betrieb des Rechenzentrums zu gewährleisten.

Ein anderes Beispiel ist eine Lösung wie HP Virtual Connect Flex-10, die speziell für virtuelle Maschinen, die auf Bladeservern gehostet werden, eine zusätzliche Abstraktionsebene schafft, um Bandbreiten von 100 Mbps bis 10 Gbps flexibel zuweisen zu können und gleichzeitig Investitionskosten in zusätzliche LAN- oder SAN-Ports zu reduzieren. Hier ist in Zukunft noch eine Vielzahl von Änderungen und neuen Techniken zu erwarten, da - auch durch die Server-Virtualisierung getrieben - die Bandbreitenanforderungen weiter steigen und dementsprechend die Standards für performantere Netzwerktechnologien (40 bzw. 100 GbE) in Vorbereitung sind. Auch die zunehmende Konvergenz bezüglich LAN- und SAN- Techniken wird sich in einer Vielzahl neuer Produkte widerspiegeln.

Es ist also zu erkennen, dass die Lösungen einerseits immer ausgefeilter werden, wodurch sich der Einsatzbereich der Blade- und virtuellen Server weiter ausdehnt (inkl. Sicherheitsfeature für Mandanten-Fähigkeit oder Einsatz in der DMZ). Andererseits kommen wie immer in einer frühen Phase einer Technologie proprietäre Techniken auf den Markt, die Interoperabilität und freie Technik- und Anbieterwahl erschweren.

Es kommt nun darauf an, einen Weg zu finden, der sich den neuen Techniken nicht verschließt und gleichzeitig aufzeigt, wie sich diese Techniken in das Unternehmens- spezifische Gesamtkonzept einbinden lassen oder wo dieses Konzept angepasst werden muss, um die neuen Entwicklungen dort zu ermöglichen, wo sie sinnvoll zum Einsatz kommen können. Es kann jedoch nicht im Sinne eines reibungslosen Betriebs sein, durch unkontrollierten Einsatz neuer Features die strategische Hoheit über das Netzwerkdesign und dessen Implementierung abzugeben oder durch den Einsatz der neuen Servertechnologien zu verwässern.

- whitepaper - Literatur Cisco (2009) Integrating the Virtual Switching System in Cisco Data Center

- whitepaper -

Literatur

Cisco (2009)

Integrating the Virtual Switching System in Cisco Data Center Infrastructure; in:

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns74

3/ns994/landing_virtual_switching.html; download: 01.09.2009

Galdy, Alexander (2008)

Hewlett-Packard (2007)

Pütter, Christiane (2009)

VMware (2007)

Gartner: Die IT-Trend 2009; in: http://www.cio.de/859923; download: 01.09.2009

Planning a VMware Virtual Infrastructure with HP ProLiant servers, storage, and management; Whitepaper - 4AA1- 0357ENW.pdf; in:

http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=

4AA1-0357ENW; download: 01.09.2009

Der neue Gartner Hype Cycle 2009, in:

http://www.cio.de/895084; download: 01.09.2009

VMware Virtual Networking Concepts; in:

http://www.vmware.com/files/pdf/virtual_networking_concepts.p df; download: 01.09.2009

Abkürzungen

Abkürzungen - whitepaper - AFT Adapter Fault Tolerance DAS Direct Attached Storage DMZ De-Militarisierte

- whitepaper -

AFT

Adapter Fault Tolerance

DAS

Direct Attached Storage

DMZ

De-Militarisierte Zone

DNS

Domain Name System

FCoE

Fibre Channel over Ethernet

GbE

Gigabit Ethernet

Gbps

Gigabit per Second (Gbit/s)

HE

Höheneinheit (in einem Serverschrank)

HP

Hewlett-Packard

LAN

Local Area Network

Mbps

Megabit per Second (Mbit/s)

OSPF

Open Shortest Path First (Routing Protokoll)

P2V

Physical to Virtual

ROI

Return on Investment bzw. Kapitalrendite

RSTP

Rapid Spanning Tree Protocol

RZ

Rechenzentrum

SAN

Storage Area Network

STP

Spanning Tree Protocol

TK

Telekommunikation

VLAN

Virtual LAN

VM

Virtuelle Maschine

VoIP

Voice over IP

VRRP

Virtual Router Redundancy Protocol

WAN

Wide Area Network