Switches und ADCs in Cloud-Umgebungen
Schneller durch die Wolken
Mal unter der Überschrift "Private Cloud" oder "interne Cloud", mal ganz ohne Bezug auf Marketing-Schlagwörter arbeiten IT-Abteilungen daran, ihre Infrastrukturen mithilfe aktueller Virtualisierungstechnik leistungsstärker, effizienter und flexibler zu gestalten. Mit der Einführung solcher Ansätze steigen zugleich die Anforderungen an die Netzwerkinfrastruktur wie auch an die Anwendungsbeschleuniger (Application Delivery Controller, ADCs): Die Problempunkte heißen hohe Auslastung und schneller Wandel.
Beim Stichwort Cloud denken die meisten Menschen vorrangig an externe oder Public Clouds: an
IaaS-Angebote (Infrastructure as a Service) wie Amazons EC2, PaaS (Platform as a Service) wie die
Salesforce-Plattform Force.com, die der Anbieter jüngst per Partnerschaft mit VMware um eine
Java-Entwicklungsplattform namens VMforce ergänzt hat, oder an die vielen SaaS-Angebote wie
Microsofts Office Live, IBMs Lotus Live oder in der "WAN-Wolke" gehostete CRM-Lösungen wie
Salesforce.com oder Microsofts Dynamics CRM.
Zeitgleich versuchen aber auch viele IT-Organisationen, die Vorteile des Cloud Computings für
ihre hauseigenen IT-Umgebungen zu nutzen. Denn zur Kerncharakteristik einer Cloud-Umgebung zählen
diverse Funktionen, die sich eine IT-Truppe auch für den internen IT-Betrieb wünschen würde:
Agilität (also die schnelle und vor allem unproblematische Reprovisionierung von Ressourcen), eine
ebenso schnelle und automatisierte Skalierung, Mandantenfähigkeit mit der Option einer dynamischen
Zuweisung von Rechen-Power nach Bedarf (und vor allem nach SLA), Messbarkeit des
Ressourcenverbrauchs (nach Rechenleistung, Plattenplatz, Traffic, Benutzerzahl, Zeitraum etc.)
sowie letztlich – das versprechen die Cloud-Marketiers – niedrigere Kosten (zumindest für den
Betrieb, wenn schon nicht unbedingt für die erforderliche neue Hardware und Software).
Das Netzwerk muss mitspielen
Das Erzielen all dieser in Aussicht gestellten Vorteile hängt hochgradig von der
Netzwerkinfrastruktur ab. Denn die Cloud – egal, ob privat oder öffentlich, intern, extern oder
hybrid – ist das logische Gegenteil lokalen Rechnens: Erfolgt der Zugriff auf Daten, Applikationen
und Rechenleistung nicht übers Netz, ist es kein Cloud Computing. Und das bedeutet für die
Netzwerker: Die Anforderungen steigen enorm.
Die offensichtlichste Anforderung ist die der Hochverfügbarkeit des Netzwerks: Wenn jeder
Zugriff auf Applikationen (einschließlich Telefonie) über das Netz läuft, kann bei der Angabe der
Netzwerkverfügbarkeit die Zahl der Neunen nach dem Komma gar nicht hoch genug sein. Das bedeutet
vor allem einmal hohe Kosten: für redundante Auslegung, Vermaschung, Netzwerkequipment mit im
laufenden Betrieb austauschbaren Komponenten etc.
Eine weitere Folge virtualisierter IT-Landschaften ist die deutlich gestiegene Server-Dichte:
Auf einer Hardware laufen nun acht, zehn, zwölf oder noch mehr virtuelle Maschinen – die alle
angebunden sein wollen und eifrig Datenverkehr erzeugen. Da wundert es nicht, das die Nachfrage
nach 10-Gigabit-Ethernet (10GbE) fröhlich steigt: Das Analystenhaus Dell?Oro meldete kürzlich, die
Anzahl verkaufter 10GbE-Ports habe 2009 bei über zwei Millionen gelegen. Laut dem Dell?Oro-Report
war 10GbE das einzige Segment im Switch-Markt, das im Wirtschaftsflautenjahr 2009 in puncto
Port-Shipment und Umsatz ein kontinuierliches Wachstum vorweisen konnte. Laut den Marktauguren soll
auch dieses Jahr der Großteil des Umsatzwachstums auf die 10GbE-Geräte entfallen: "Wir erwarten,
dass der Markt 2010 weiter expandiert," so Alan Weckel, Director of Ethernet Switch Research bei
der Dell?Oro Group, "insbesondere, da 10 Gigabit Ethernet weiterhin zulegt, nicht nur als Technik
für die Server-Anbindung, sondern auch für die Aggregation im Data Center." Bei Core-Switches schon
Standard, findet 10GbE also nicht zuletzt dank Virtualisierung auch bei den Aggregations-, EoR- und
ToR-Geräten (End of Row, Top of Rack) immer mehr Verbreitung.
Mit 10GbE-Ports bestückte Switches – darunter auch kleine Fixed-Configuration-Geräte für den
Top-of-Rack-Einsatz – bieten längst alle führenden Hersteller, von Cisco über den frisch
fusionierten Cisco-Rivalen HP Procurve/3Com bis hin zu Brocade, Force10 und Extreme. Da die
Server-Farmen auch per Ethernet auf die Datenspeicher zugreifen sollen, ist zudem FCoE (Fibre
Channel over Ethernet) eine Standardanforderung geworden. FCoE wurde vor ziemlich genau einem Jahr
offiziell ratifiziert und ist längst ebenfalls im Repertoire einschlägiger Hersteller: Cisco bietet
das im Nexus ebenso wie zum Beispiel Brocade im Brocade 8000, und Blade Network Technologies
stellte im Februar als Erster ein FCoE-Switch-Blade vor. Als Alternative zu FCoE versucht sich
derzeit iSCSI zu etablieren. Geräte wie Ciscos Nexus bieten eine Unfied Fabric, können also FCoC
ebenso verarbeiten wie iSCSI und Fibre Channel.
Cloud-Dynamik erfordert
Intelligenz im Netz
Die in Clouds geforderte Agilität – dynamisches Verschieben von Servern, Applikationen und
Storage unter Beibehaltung der Netzwerk-Links – erfordert von der Netzwerkinfrastruktur ein
möglichst enges Zusammenspiel mit den Server- und Storage-Backends. Nicht umsonst integrieren
manche Hersteller Server, Storage und Virtual Switching zu einem Gesamtsystem, wie dies Cisco mit
dem UCS (Unified Computing System) oder HP mit den Matrix-Systemen vorexerziert haben.
Um ein "Virtual-Machine-Aware Networking" – also Netzwerkverbindungen, die den Zuständen der VMs
folgen und darauf reagieren können – zu realisieren, nutzt Switch-Marktführer Cisco seine so
genannte VN-Link-Technik. Dank VN-Link integriert sich Ciscos UCS in VMwares Vsphere-Software,
sodass Switches und Storage immer über die vorhandenen VMs auf dem Laufenden sind. Cisco verspricht
damit Policy-basierte Echtzeitkonfiguration, dynamische Umsetzung von Netzwerk- und
Sicherheitsrichtlinien im Einklang mit Vmotion sowie ein durchgängiges Management-Modell von der VM
bis zu Netzwerk und Storage. HP bietet mit Virtual Connect eine Konkurrenztechnik an.
Genau im Grenzgebiet zwischen Netzwerk und Applikation sind auch die ADCs angesiedelt.
Kernaufgabe der ADCs ist es, per Lastverteilung und Offload physische oder virtuelle Server
regelbasiert von Aufgaben zu entlasten und damit Applikationszugriffe zu beschleunigen. Auch die
ADCs werden immer leistungsstärker, wie die Marktübersicht auf Seite 36 veranschaulicht: F5s
Chassis-System Viprion führt das ADC-Feld mit 72 GBit/s Layer-7-Durchsatz klar an; F5s größtes
Standalone-Gerät, die jüngst vorgestellte Big-IP 11050, stemmt 42 GBit/s. Citrix? aktuelle
Netscaler-Familie MPX mit dem Flaggschiff MPX 21500 spielt inzwischen mit bis zu 50 GBit/s
L7-Durchsatz in der gleichen Liga wie Marktführer F5. Citrix setzt für diese hohe Skalierbarkeit
auf Intel-CPUs und die hauseigene Ncore-Technik, die pro CPU-Core eine eigene Packet Engine bietet.
Zur Anpassung lassen sich laut Citrix "App Templates" schnell aus der Community-Site oder
Staging-Umgebung in die Produktivumgebung übernehmen. Die Regelwerke (Regular Expressions) kann der
Administrator dank der Tools Reg Ex Creator und Reg Ex Evaluator direkt auf der Box testen.
VM-Dynamik stellt neue
Anforderungen
Wie die Virtual Switches stehen auch ADCs vor der Herausforderung, zur Abarbeitung ihrer
Policies über den Status der virtuellen Server Bescheid zu wissen, selbst im Fall einer Migration
mittels Mechanismen wie Vmotion oder Xenmotion. Dazu kann ein ADC im Grunde die laufenden VMs per
Monitoring vom ICMP Ping bis hin zu komplexen Applikationsabfragen im Blick behalten: Wenn er eine
Applikation nicht findet, nimmt er den Server aus dem Verbund heraus – unabhängig davon, ob es sich
um einen defekten physischen oder einen deprovisionierten virtuellen Server handelt. Dies
funktioniert laut Angaben von F5 und Citrix problemlos, solange sich die IP-Adresse des virtuellen
Servers nicht ändert. Es können aber durchaus auch anspruchsvollere Szenarien vorkommen: zum
Beispiel die Skalierung einer Web-Server-Farm über den IP-Adressbereich der Grundkonfiguration
hinaus, extra zum Zweck einer Kampagne, oder auch die standortübergreifende Migration virtueller
Maschinen zu Disaster-Recovery-Zwecken.
Der Integration in virtuelle Umgebung dient bei Citrix das Werkzeug Workflow Studio: Darüber
kann der Adminstrator einem Netscaler mitteilen, welches Backend-System zum Beispiel in Wartung
geht. Der ADC kann dann die VMs oder physischen Server aus der Server-Farm nehmen, sobald alle
Anwender abgemel-
det sind.
F5 bietet für komplexere Einsatzfälle über seine Icontrol-Schnittstelle eine Integration in
VMwares Verwaltungslösung Vcenter. Durch das Zusammenspiel des Vcenter Site Recovery Managers mit
F5s GTM-Modul (Global Traffic Manager) können virtuelle Maschinen laut F5 mit VMwares
Long-Distance-Vmotion in ein anderes RZ umgeleitet werden, ohne dass laufende Sessions
verlorengehen. Auch Funktionen für WAN-Optimierung und Data Deduplication bietet Big-IP hier
an.
Virtuelle ADCs
Ebenfalls dem Virtualisierungstrend geschuldet ist der Umstand, dass ADCs nun auch als Virtual
Appliances auf den Markt kommen. Solche Virtual Appliances (betriebsfertig vorbereitete VM-Images)
sind sehr nützlich, lassen sie sich doch leichter in virtualisierte Umgebungen einbinden als
klassische Hardware-Appliances – und sie sind nicht zuletzt auch für einen Test schneller zum
Interessenten geschickt. Zu nennen sind hier Citrix? Netscaler VPX, den es seit Neuestem in
Ausführungen mit bis zu 3 GBit/s Durchsatz gibt und der laut Citrix künftig bis 15 GBit/s skalieren
soll. F5 ist inzwischen mit dem Big-IP LTM VE (Local Traffic Manager Virtual Edition) nachgezogen,
der allerdings nur auf maximal 1 GBit/s Traffic ausgelegt ist. Big-IP LTM VE dient rein dem lokalen
Load Balancing, während der Netscaler als VPX-Image laut Citrix den identischen Funktionsumfang
bietet wie die MPX-Appliances. Eine Ausnahme bilden natürlich die hardwaregestützten
Offload-Funktionen wie SSL- oder HTTP-Compression-Offload.
Um hier volle Funktionalität mit hoher Skalierbarkeit zu kombinieren, raten die beiden
ADC-Anbieter bei größeren Installationen zur Kaskadierung physischer und virtueller ADCs im Rahmen
von Hybrid-Deployments: Ein physischer ADC liefert dann die Offload-Power, während sein
virtualisierter Kollege die Lastverteilung zwischen den VMs übernimmt – und letztlich auch
dynamisch mit einer virtuellen Server-Farm mitwandern kann. Damit hat man zwar einen ADC-Tier mehr
im Einsatz, dafür aber volle Flexibilität bei der Optimierung einer Cloud-Infrastruktur. Ab Version
11.0, die für Ende 2010 geplant ist, sollen sich F5s Viprion und Big-IP übrigens dann selbst in
virtuelle Instanzen aufteilen lassen.
Lesen Sie mehr zum Thema
