Das C-L-O-U-D Schichtenmodell und die Layer 1 + 2: Storage und Netzwerk-Virtualisierung (Zweitveröffentlichung)...

Hi, mal wieder ein Update, was nicht heisst, dass ich faul war: Das Bloggen konzentriert sich aktuell aber mehr auf den Blog meines Arbeitgebers, so dass ich meine eigene Plattform hier in letzter Zeit leider etwas vernachlässigen musste. Dieser Blog-Post ist deshalb auch die Kopie meiner drei letzten Posts aus dem CloudMACHER-Blog. Happy reading... Und wer mit mir persönlich über den Kram, den ich hier veröffentliche, diskutieren will, der kann das z.B. im Rahmen des CloudMACHER-Events (kostenfrei) tun: Anmeldung CloudMACHER Hannover

Serie C-L-O-U-D (1.): Cloud in Scheiben - Das C-L-O-U-D-Schichtenmodell

In meinem ersten Blog-Post zum Thema Cloud Computing habe ich darüber nachgedacht, ob dies wirklich ein fundamentaler Wechsel in der IT-Strategie für Unternehmen ist oder doch nur ein Marketing-Hype. Das Ergebnis ist aus meiner Sicht eindeutig: Cloud Computing bedeutet definitiv einen fundamentalen Wechsel in der IT-Strategie von Unternehmen, bietet es doch diverse Vorteile:

• Typischerweise deutlich flexiblere und dynamischere IT-Infrastrukturen,
• Höhere Transparenz, 
• Bedarfsgerechte Bereitstellung und Nutzung von Kapazitäten, 
• Eine Fokussierung auf Services. 

Man könnte sogar so weit gehen und die These aufstellen, dass Cloud Computing der beste Weg ist, um ITIL-Prozesse in Unternehmen in die Tat umzusetzen. Bleibt also nur noch die Frage zu klären, wie  sich Unternehmen diesem sehr komplexen und teilweise auch sehr abstrakten Thema Cloud Computing annähern können? Um diese Frage zu klären, ist es meines Erachtens sehr wichtig, genau einordnen zu können, welche Komponenten für die Etablierung einer Cloud-fähigen Infrastruktur notwendig sind. Darüber hinaus ist es  erforderlich zu verstehen, dass ein Großteil dieser Komponenten in einem direkten Zusammenhang bzw. einer direkten Abhängigkeit zueinander steht.
Verdeutlicht wird dies durch das nachfolgende C-L-O-U-D-Schichtenmodell:

Das Modell zeigt neben den verschiedenen Ebenen einer Cloud-Infrastruktur auch die Abhängigkeiten zwischen eben diesen. Eine zusätzliche Gruppierung  der Ebenen zeigt auf, dass diese typischerweise übergreifend/zusammenhängend betrachtet werden sollten. Bei genauerer Betrachtung des  Modells, lassen sich aus meiner Sicht die  „goldenen“ Regeln für den Aufbau einer C-L-O-U-D-Infrastruktur ableiten:

• Eine durchgehende Virtualisierung auf den verschiedenen Ebenen des C-L-O-U-D Delivery Blocks ist zwingend notwendig und Basisvoraussetzung für den Aufbau einer Cloud-Infrastruktur.
• Der C-L-O-U-D Delivery Block ist als Einheit zu verstehen und bildet die Basis der Infrastruktur. Eine Einzelbetrachtung der verschiedenen Ebenen ist zwar grundsätzlich möglich, für den Aufbau einer Cloud-Infrastruktur müssen diese aber in einem übergreifenden Ansatz gemeinsam betrachtet werden.
• Der/die C-L-O-U-D Delivery Block(s) werden durch den Cloud Service-Orchestration Layer übergreifend verwaltet/gesteuert. Die in dieser Ebene befindlichen Komponenten bilden  quasi das Herzstück der Cloud-Infrastruktur.
• Die oberhalb des Service-Orchestration Layers liegenden Ebenen integrieren erweiterte Automatisierungsfunktionen (sofern diese in den Komponenten des Service-Orchestration Layers nicht enthalten sind) sowie Komponenten für die Transformation von Geschäftsprozessen in IT-Prozesse.
• In ihrer Gesamtheit bilden die verschiedenen Management Komponenten den C-L-O-U-D-Management-Block, der dafür verantwortlich ist, die Cloud-Infrastruktur „sichtbar“ und „lebendig“ zu machen. Zumindest der Cloud Service-Orchestration Layer ist als Pflichtkomponente zu verstehen.
• Um auf die Cloud-Infrastruktur zugreifen zu können, werden typischerweise Access- und Client-Komponenten benötigt. Je nach Typ/Definition der Cloud (Private/Community, Hybrid, Public) ist eine Betrachtung dieser Komponenten mehr oder weniger notwendig.

Ich hoffe, dass ich mit dem C-L-O-U-D-Schichtenmodell  etwas Licht ins Dunkel des Cloud Computing bringen kann. In zukünftigen Blog-Posts werde ich auf die einzelnen Ebenen des Schichtenmodells näher eingehen, verfügbare Produkte bewerten/gegenüberstellen und vielleicht auch schon über erste Praxiserfahrungen berichten können.

Serie C-L-O-U-D (2.): Delivery-Block (Storage-Virtualisierung)

In meinem letzten Blog-Post habe ich das C-L-O-U-D Schichtenmodell vorgestellt und versprochen, auf die einzelnen Schichten näher einzugehen. Dieses Versprechen möchte ich heute  einlösen und mit der untersten Schicht des Delivery-Blocks beginnen, dem Storage Virtualization Layer.

Storage-Hersteller und Systeme gibt es mittlerweile wie Sand am Meer und erfahrungsgemäß hat jeder Kunde in diesem Umfeld eine eigene Präferenz. Neben den klassischen Hardware-Anbietern bzw. System-Lieferanten gibt es inzwischen auch immer mehr auf Software basierende Lösungen, die vorhandene Storage-Systeme um zusätzliche Funktionen erweitern. Welche dieser verschiedenen Lösungen, bezogen auf den Aufbau einer Cloud-Infrastruktur, sinnvoll einzusetzen sind und welche Funktionen in den Storage-Systemen für Cloud-Computing wirkliche Relevanz haben, möchte ich mit diesem Blog-Post aufzeigen.
Bevor ich mich jedoch intensiver mit dem Thema des Storage Virtualization Layer beschäftige, ist es aus meiner Sicht erforderlich, sich noch einmal die typischen Eigenschaften einer Cloud-Infrastruktur ins Gedächtnis zu rufen:

• Eine Cloud-Infrastruktur ist hochdynamisch, um nicht zu sagen elastisch. Sie kann in alle Richtungen (und somit auch in allen zum Einsatz kommenden Komponenten) skalieren und stellt die verfügbaren Ressourcen bei Bedarf zur Verfügung.
• Eine Cloud fokussiert größtenteils auf die Bereitstellung von Services, was typischerweise eine hohe Integration der einzelnen Komponenten erfordert. Darüber hinaus gibt es für Services zumeist klare Nutzungs- und Verfügbarkeitsanforderungen (Service-Level), die durch alle Komponenten sichergestellt werden müssen. Idealerweise unterstützen die Komponenten die Definition qualitativ unterschiedlicher Service-Level pro Service.
• Eine Cloud-Infrastruktur wird normalerweise gleichzeitig von mehreren Mandanten genutzt. Diese müssen in allen Ebenen und Komponenten voneinander isoliert sein. Durch die gemeinsame Nutzung der verfügbaren Ressourcen soll eine optimierte Ressourcen-Auslastung erreicht werden, wodurch die Wirtschaftlichkeit der Infrastruktur gesteigert werden kann.

Neben diesen allgemeingültigen Punkten, die von allen eingesetzten Komponenten unterstützt werden müssen, sollte das Storage-System einer Cloud-Infrastruktur idealerweise aber auch einige spezifische Funktionalitäten aufweisen. So werden auf einem Cloud-Storage im Regelfall Objekte unterschiedlicher Art gespeichert, durch die verschiedene Anforderungen an das Storage-System entstehen. Typische Objekte einer Cloud-Infrastruktur sind:

• Virtuelle Maschinen
• Snapshots
• Templates
• ISOs

Idealerweise unterstützt das Storage-System ein sogenanntes „Multi-Tiering“, also die Definition unterschiedlicher Storage-Bereiche für die verschiedenen Objekttypen der Cloud-Infrastruktur. Diese Definition bezieht sich dabei hauptsächlich auf die gleichzeitige Verwaltung verschiedenartiger Disk-Typen wie SAS, SATA oder SSD, in Kombination mit der flexiblen Nutzung von unterschiedlichen Storage-Protokollen wie iSCSI, FC, FCoE oder NFS durch das Storage-Management. Durch die Kombination von Disk-Typ und Storage-Protokoll ist es beispielsweise möglich, den Nutzern der Cloud-Infrastruktur unterschiedliche Service-Level auf der Storage-Ebene anzubieten. Benötigt der Mandant z.B. nur einen Webserver für Entwicklungszwecke, kann er die Disk dieses Webservers auf einem kostengünstigen, aber langsameren SATA-Storage speichern, welches z. B.  über iSCSI angesteuert wird. Benötigt er zusätzlich noch einen produktiven Datenbank-Server, kann er die Disk für dieses System einfach auf den SAS-Bereich speichern, der wiederum über FC angebunden ist.
Weitere Kriterien für das Storage-System einer Cloud-Infrastruktur sind (je nach Einsatz-Zweck):

• Deduplikation (reduziert das notwendige Storage-Volumen der Cloud-Infrastruktur)
• Integrierte High-Availability bzw. Replikations-Mechanismen (notwendig für die Abbildung kritischer Systeme)
• Hypervisor-Integration (vereinfacht das Storage-Management)
• API-Schnittstelle (für Automatisierungsroutinen)

Nach dieser Aufzählung (die nur eine Auswahl darstellt und mit der ich keinen Anspruch auf Vollständigkeit erhebe) existieren sicherlich immer noch viele Hersteller und Systeme am Markt, die die gewünschten Funktionen auf die eine oder andere Weise unterstützen.
Exemplarisch möchte ich an dieser Stelle auf zwei Lösungen etwas genauer eingehen, die unterschiedlicher nicht sein könnten, die aber beide im Kontext von Cloud-Computing bereits sehr erfolgreich eingesetzt werden. Einerseits sind dies die Systeme der Firma NetApp, die bereits seit Jahren den Ansatz größtmöglicher Flexibilität, z.B. hinsichtlich der Protokoll-Unterstützung, verfolgen. Andererseits ist es das Openstack Object Storage (Codename Swift), das Software-basierende Storage-System des Openstack Open-Source-Projektes.
NetApp bietet in seinen Storage-Systemen seit Jahren die Möglichkeit der gleichzeitigen Nutzung unterschiedlicher Storage-Protokolle. Vor einiger Zeit wurde dieser Ansatz um die Möglichkeiten des Multi-Tierings sowie die Nutzung sogenannter Unified-Adpater in den NetApp-Management-Systemen erweitert. Diese bieten die Fähigkeit, mehrere Storage-Protokolle gleichzeitig über einen physikalischen Adapter zur Verfügung zu stellen, was das Management und das Systemdesign des Storage-Systems weiter vereinfacht, ohne die Flexibilität zu beeinträchtigen. Darüber hinaus bietet NetApp integrierte Möglichkeiten zur Isolation von Mandanten (vFiler) und optimiert den Speicherbedarf, z.B. durch die Bildung von Speicherpools (FlexVols) und integrierte Deduplikations-Technologien.
Die NetApp-Systeme bestehen aus ideal aufeinander abgestimmter Hard- und Software. Besonders interessant für das Cloud-Umfeld: NetApp bringt seine Storage-Kompetenz in den Flexpod ein, ein stark standardisiertes System aus NetApp-Storage-Systemen, Cisco-Servern, Netzwerk-Komponenten und VMware vSphere: Sozusagen ein fertiger
C-L-O-U-D-Delivery-Block, der von den beteiligten Unternehmen gemeinsam zu attraktiven Preisen vermarktet und auch supported wird.
Einen gänzlich anderen Ansatz verfolgt das Software-basierte Openstack Object Storage „Swift“, welches aus Standard-Servern ein geclustertes und somit hochverfügbares und theoretisch unendlich skalierbares Cloud-Storage erzeugt. Fällt ein Cluster-Knoten aus, kann dieser einfach durch einen neuen Knoten ersetzt werden. Entsprechende Replikations-Mechanismen sind in „Swift“ standardmäßig enthalten.

Objekte werden je nach Design automatisch an mehreren Stellen gespeichert und sind somit redundant enthalten. Damit verfolgt das Projekt einen sehr interessanten Ansatz, der zudem dem typischen Open-Source-Gedanken folgt: Mit einem relativ geringem Einsatz von Mitteln, soll durch eine intelligente Lösungen ein Maximum an Funktionalität erreicht werden.
Ich bin sehr gespannt darauf, welcher Ansatz sich final durchsetzen wird oder ob es eventuell doch eine Mischung verschiedener Lösungen geben wird. Diesbezüglich wird viel von dem die Hardware-Ressourcen überspannenden Management abhängen bzw. von den spezifischen Anforderungen der Kunden. Die Frage ist auch, ob europäische bzw. speziell deutsche Unternehmen überhaupt den Einsatz eines aktuell hauptsächlich in den USA verbreiteten Open-Source-Projektes in Betracht ziehen. Aber dazu später mehr in einem weiteren Blog-Post.

Serie C-L-O-U-D (3.): Delivery-Block (Netzwerk-Virtualisierung)

In meinem letzten Blog-Post zum C-L-O-U-D Schichtenmodell ging es um die unterste Ebene des C-L-O-U-D Delivery-Blocks, die Storage-Virtualisierung. Die nächst höhere Schicht ist die der Netzwerk-Virtualisierung, die Thema des heutigen Blog-Posts ist. Ich möchte an dieser Stelle gleich vorweg nehmen, dass dieser Ebene meiner Meinung nach eine ganz besondere Bedeutung zukommt. Warum? Weil jeder IT-Administrator bzw. jeder mit IT-Infrastrukturen Beschäftigte weiß, dass ein „vernünftiges“ Netzwerk die Basis für eine performante und verlässliche IT-Infrastruktur darstellt - und dies gilt umso mehr in hochdynamischen Cloud-Infrastrukturen.

Das nachfolgende Video von Intel unterstützt diese These und vermittelt noch einmal auf anschauliche Art und Weise, warum die Virtualisierung von Netzwerken für Cloud-Infrastrukturen ein Muss ist:

Welche Kern-Aussagen bzgl. Cloud-Infrastrukturen können wir aus dem Video mitnehmen:

• „Unified Networking“: Durch die Definition von „Channels“ ist es möglich, auf einer einzigen physikalischen Verbindung unterschiedliche Protokolle (Netzwerk / Storage) parallel zu nutzen.
• „Wider and smarter pipe“: Durch die Unterstützung von 10GBit ist eine optimale Bereitstellung von Netzwerk-Ressourcen (z.B. Bandbreite), abhängig vom Bedarf der virtuellen Maschine (Workload) möglich.

Das Fazit aus dem Video:

• „No more Over-Engineering of DataCentres“: Die zuvor genannten Technologien verhindern also eine „Über-Dimensionierung“ des Rechenzentrums, sorgen sie doch für eine bessere Auslastung der verfügbaren Netzwerk-Ressourcen sowie eine bedarfsgerechte Bereitstellung und eine Reduktion der notwendigen Hardware durch gleichzeitiger Nutzung mehrerer Protokolle auf einer Verbindung.

Hört sich super an und ist es im Prinzip auch. Aber wie kann man das Ganze denn nun wirklich in die Tat umsetzen? Dies gestaltet sich „wie so oft“ nicht immer einfach, sondern bedarf typischerweise einer sorgfältigen Planung, denn:

• Eine Cloud-Infrastruktur entsteht selten auf der „grünen Wiese“, sondern wird zumeist aus einer bestehenden IT-Infrastruktur heraus „geboren“.

Bezogen auf das Netzwerk, ist dieser Umstand eine besondere Herausforderung. Warum? Weil das Netzwerk quasi das Rückenmark der IT-Infrastruktur ist – sämtliche Fäden laufen hier zusammen, eine Störung oder Fehlfunktion an dieser Stelle kann vielfältige Auswirkungen haben und niemand weiß ganz sicher, welche Konsequenzen eine Änderung wirklich nach sich zieht.
Deshalb ist es wichtig, sich mit den verschiedenen technischen Komponenten der Netzwerk-Virtualisierung vertraut zu machen, um dann die richtigen Entscheidungen zu treffen und sein Netzwerk Stück für Stück „Cloud-ready“ zu machen.
Die zentrale Schnittstelle in der Netzwerk-Virtualisierung ist der virtuelle Switch im Hypervisor. Dieser abstrahiert die physikalisch am Virtualisierungs-Host anliegenden Netzwerk-Verbindungen und stellt sie den virtuellen Maschinen zur Verfügung. Mittlerweile gibt es virtuelle Switches mit extrem umfangreichen Funktionen, die ihren physikalischen Geschwistern oftmals nicht mehr nachstehen bzw. teilweise vom Funktionsumfang bereits überlegen sind. Besonders hervorzuheben ist hierbei der Cisco Nexus 1000V, der aktuell bereits von dem Hypervisor VMware vSphere unterstützt wird und zukünftig auch mit der neuen Version von Microsofts Hypervisor Hyper-V (ab der Version 3.0, verfügbar mit Windows Server 2012) kompatibel sein soll.
Andere Hersteller oder Hypervisor, z.B. Citrix ab XenServer Version 6.0 oder KVM, setzen auf den Open vSwitch, einen frei verfügbaren virtuellen Switch, der seit der Linux Version 3.3 sogar Bestandteil des Linux Mainline Kernels ist.
Aber egal welcher virtuelle Switch zum Einsatz kommt, die Funktionen, die sie für den Aufbau einer Cloud-Infrastruktur unabdingbar machen, sind oftmals die gleichen. Vor allem wird die Möglichkeit geschätzt, komplexe Netzwerk-Infrastrukturen bereits auf der Ebene der Virtualisierungs-Hosts abbilden zu können. Denn nur so kann eine saubere Trennung  unterschiedlicher Mandanten auf dem Hypervisor erreicht werden, wie sie z.B. von Zertifizierungs-Instanzen wie dem BSI oder ISO für multi-mandantenfähige IT-Infrastrukturen gefordert wird. Des Weiteren sorgen die virtuellen Switches dafür, dass alle definierten Netzwerk-Richtlinien, z.B. auch nach einer vollautomatischen Migration einer virtuellen Maschine, im Fehlerfall wieder angewendet werden. Wichtig für viele Kunden ist auch die Transparenz und Nachvollziehbarkeit des Netzwerk-Verkehrs zwischen VMs, z.B. im Rahmen einer Fehleranalyse, die durch die Unterstützung von Protokollen wie NetFlow und sFlow gegeben ist. Oftmals lassen sich auch QoS-Regeln definieren, die vor allem bei einem Unified-Networking-Ansatz unverzichtbar sind. Des Weiteren bieten die virtuellen Switches bereits heute eine Unterstützung für auf zukünftige Anforderungen ausgerichtete Netzwerktechnologien wie IPv6 oder VXLAN.
Sollten zusätzliche Netzwerk- und Sicherheits-Mechanismen gefordert sein, kann Cisco ebenfalls punkten, lässt sich der virtuelle Switch Cisco Nexus 1000V doch durch zusätzliche Komponenten z.B. um Load-Balancing- oder Firewall-Funktionen erweitern.
Eine Kombination unterschiedlichster Netzwerk-Funktionen bietet der Hersteller Vyatta mit seinem Network OS an, dass mittlerweile mit den gängigsten Virtualisierungslösungen eingesetzt werden kann. In Kombination mit Produkten des Herstellers Citrix ist zusätzlich eine interessante Lösung entstanden: Der vNetworkStack fasst verschiedene virtuelle Appliances beider Hersteller zusammen und stellt auf allen Ebenen des OSI-Modells Funktionen im Netzwerk zur Verfügung.
Zusammengefasst bleibt festzuhalten, dass die virtuellen Switches im Zusammenspiel mit dem Hypervisor zentrale Komponenten bei der Virtualisierung von Netzwerken sind. Ihre volle Leistung können Sie allerdings nur dann entfalten, wenn auch die zugrundeliegende Hardware entsprechend „mitspielt“. In diesem Umfeld bietet mittlerweile fast jeder Hersteller von Netzwerk-Komponenten entsprechende Produkte. Allerdings möchte ich an dieser Stelle noch einmal auf den Hersteller Cisco hinweisen, der in seinen DataCentre-Produkten sein langjähriges Netzwerk Know-How einfließen lässt und damit eine hochinteressante Hardware-Plattform für den Aufbau von Cloud-Infrastrukturen darstellt. Aber dazu mehr im nächsten Blog-Post zum C-L-O-U-D Schichtenmodell.