Low Latency Networks im Überblick, Teil 8 Management-Aspekte und Konsequenzen beim Highspeed-Networking

In einem der letzten Artikel hatte ich den Begriff „FaaS“, Fabric as a Service, bereits angesprochen. Es dürfte auch klar geworden sein, dass das vielfältige Zusammenwirken von Servern, Speichern, Virtualisierungssoftware, Anwendungen, Middleware, Web2.0-Komponenten und Netzen nur durch eine Management-Umgebung betrieben werden kann, die weitestgehend auf Automatisierung beruht. Doch welche Konsequenzen hat das Ganze nun für ein Unternehmensnetzwerk?

Anbieter zum Thema

Dell GmbH

ICP Deutschland GmbH

Paessler AG

ComConsult Akademie

ComConsult Beratung und Planung GmbH

Die Konsolidierung eines RZs kann nicht erreicht werden, ohne die zugrundeliegende Netzwerk-Infrastruktur entsprechend zu kontrollieren. Da die Umgebungen, die das Netz nutzen, automatisiert und durch Service-Konzepte definiert sind und ebenso verwaltet werden, ist eine manuelle Konfiguration des Netzes unmöglich. Daher benötigt man ein Service-orientiertes Paradigma für das Fabric Management.

In naher Zukunft wird mit den SSDs eine völlig neue Speicherklasse in die Rechenzentren eingeführt. Bestimmte, besonders anspruchsvolle Betreiber haben das schon jetzt. Doch wie verändert sich dadurch unsere Netzwerk-Landschaft? Das werden wir getrennt zu behandeln haben, aber über die grundsätzlichen Konsequenzen können wir heute schon sprechen.

Management-Aspekte

Neue Automations- und Virtualisierungsumgebungen haben den Begriff IaaS geprägt: Infrastruktur als ein Dienst. Dahinter steckt der simple Gedanke, dass Benutzer Aufträge formulieren sollen und diese dann „irgendwo“ durch entsprechende VMs in einem Netz ausgeführt werden. Das ist nichts anderes als ein weiterer Begriff für Cloud Computing, entweder lokal oder durch einen externen Anbieter.

Bei der RZ-Konsolidierung und/oder der Einführung von Cloud Computing gibt es folgende Herausforderungen, die letztlich die Fabric betreffen:

• Mängel bei Isolation und Sicherheit zwischen Virtuellen RZs
• Mangel beim Monitoring von Service Leveln und der Durchsetzung bei verteilten Fabrics
• Die Virtualisierung von Servern und Speichern hat nur eine schwache Korrelation zu der Definition von Policies in Fabrics
• Die Mobilität von Anwendungen und das Wandern Virtueller Maschinen erfordert einen Abgleich zu den Policies in Fabrics
• CPU-Konsolidierung und Virtualisierung können zu Engpässen bei der I/O führen. Es ist Aufgabe der Fabric, diese so weit wie möglich zu kompensieren um die ursprünglich bei der Einführung von Anwendungen definierten Leistungsziele zu erreichen. Dazu benötigt man letztlich die Optimierung von Fabric Ressourcen und I/O.
• Die Platzierung von Jobs und VMs über die Server und die Fabric ist eine komplizierte Aufgabe, wenn man das Fabric Layout, die aktuelle Last und die I/O-Anforderungen berücksichtigt.
• Scale-Out Umgebungen können besondere Anforderungen an Administration und Trouble-Shooting stellen.
• Es ist schwierig, den Einfluss von Fabric Congestion und Überbuchung auf die Leistung von Anwendungen zu messen oder auf eine andere Art zu bestimmen.

Wir haben den Unified Fabric Manager von Voltaire ja bereits kennengelernt. Ich möchte nochmals auf dieses Produkt zurückkommen, weil ich der Ansicht bin, dass es Funktionen enthält, die absolut elementar für die Implementierung geeigneter Management-Strukturen und die Errichtung von FaaS sind. Es ist eines der ersten, wenn nicht das erste Produkt mit diesem Funktionsumfang. Alle anderen Produkte in dieser Richtung werden sich daran messen lassen müssen. Die Zeit einfacher SNMP-Management-Tools ist mit dem Einzug der Virtualisierung endgültig abgelaufen!

Funktionen innerhalb von UFM zur besonderen Unterstützung von Fabrics Virtualisierter Umgebungen sind:

• Sammlung von Statistiken und Informationen physikalischer und virtueller Switches
• Generierung von Statistiken und Verkehrsanalysen pro VM, spezifischer I/O oder Traffic Flows
• Zerlegung der Fabric in multiple Dienstklassen für LAN, IPC und Storage
• Anwendung von QoS (Prioritäten, Limits, Garantien) pro I/O oder Traffic Flow
• Provisioning physikalischer Partitionierung, VLANs und Virtueller I/O
• Garantie von Hochverfügbarkeit (Multi-Rail und Multi-Path Konfiguration sowie Policy Synchronisation)
• Zentrale Verwaltung vieler Switches mit einer Konsole
• Automatische Vorschläge für optimale Platzierung von VMs oder Anwendungslasten in Abhängigkeit von Fabric-Zuordnung oder Last
• Isolation, Kontrolle, Monitoring und Abstellen von Congestions

Die Teaser-Abbildung fasst das schön zusammen und zeigt, dass es sich bei allem hier natürlich nicht um statische Einstellungen, sondern dynamische Prozesse handelt.

Wir bekommen mit den latenzarmen Netzen in jedem Fall auch die DCB-Funktionen und Konvergenz in unterschiedlichen Ausprägungen. Auf der Seite der Virtualisierungssoftware werden VMs definiert und Anforderungen an sie gestellt. Die Aufgabe von Management-Werkzeugen für die zugrunde liegenden Netze ist es einfach gesagt, diese Anforderungen mit Hilfe der DCB-Funktionen und der Konvergenz systematisch und weitestgehend automatisiert durchzusetzen.

Dabei ist es völlig unerheblich, ob man nur ein halbwegs „normales“ Spektrum von Anwendungen, Web2.0-Anendungen, HPC oder Cloud-Anwendungen betreiben möchte.

weiter mit: Die Konsequenzen

(ID:2049008)