Mobile-Menu

Nicht Produkte sondern Lösungen für Big Data, Virtualisierung und Ausfallsicherheit Durchgeplant: Ein neues IT-Design im Rechenzentrum

Autor / Redakteur: Stefan Fehr / Ulrike Ostler

Gesucht werden geeignete Lösungen für Big Data, Virtualisierung und Ausfallsicherheit. Doch welche gibt es? Und warum entscheiden sich immer mehr Unternehmen für ein komplettes Re-Design ihres Datacenter? Wie wäre es mit Cisco, VMware, EMC und, oder VCE?

Firmen zum Thema

Stefan Fehr schildert in einem umfangreichen Artikel, wie die verschiedenen Anforderungen und technischen Lösungen ineinander spielen, wenn die Rechenzentreums-IT neu aufgesetzt werden soll.
Stefan Fehr schildert in einem umfangreichen Artikel, wie die verschiedenen Anforderungen und technischen Lösungen ineinander spielen, wenn die Rechenzentreums-IT neu aufgesetzt werden soll.
(Bild: Fotolia/ Andreas Härtle)

IT für Unternehmen nimmt einen immer höheren Stellenwert ein. Dafür gibt es verschiedene Gründe. Einer ist die elektronische Abbildung von operativen Geschäftsprozessen in geeigneten Systemen. Ein anderer der uneingeschränkte Zugriff auf Daten von jedem Ort zu jeder Zeit. Steht die Abbildung von Geschäftsprozessen eher im Fokus des Unternehmens, so ist der permanente Datenzugriff auch ein von Anwendern getriebenes Thema.

Mit dem Aufweichen bekannter Arbeitszeitmodelle sowie dem Einsatz unterschiedlicher mobiler Endgeräte, werden an Daten und IT erweiterte Anforderungen gestellt. Wurde in den letzten Jahren an einer performanten Bereitstellung der Daten über LAN und WAN gearbeitet, sind heute die Herausforderungen eines schier unendlichen Kapazitätsbedarfs sowie einer permanenten rund um die Uhr Verfügbarkeit zu lösen.

Bildergalerie
Bildergalerie mit 8 Bildern

Bausteine jedes Rechenzentrums

Die Ebenen eines Datacenters (siehe: Abbildung 1), gleich welcher Größe, werden immer durch die Grundbausteine Storage, Netzwerk, Server und Backup gebildet. Üblicherweise werden Server und Speichersystem für den benötigten Block-Zugriff über dedizierte Fiberchannel-Strecken verbunden.

Eine Bereitstellung von unstrukturierten Daten auf einem NAS-Device erfolgt durch separate Anbindungen über Ethernet und zusätzlichem Speicher- und Netzwerkequipment. Eine Absicherung der Daten erfolgt üblicherweise auf einem Backup-System in einem vom produktiven Datacenter abgetrennten Brandabschnitt.

Doppelt ausgelegte Netzteile in den physikalischen Hosts, redundante Pfade zwischen Storage und Host, virtuelle Port Channel auf dem Ethernet und redundante Bauteile in dem Storagesystem geben ein hohes Maß an Sicherheit und Verfügbarkeit. Bei einem geeigneten Sicherungsmodell lässt sich so das RTO, also die Zeit die nach einem Ausfall benötigt wird bis die Geschäftsprozesse wieder lauffähig sind, massiv reduzieren. Neue Dienste werden durch Hinzufügen von Servern und Anbindung an die entsprechenden Speichersysteme bereitgestellt.

Wo bleibt die Elastizität?

Diese dem Design geschuldete Vorgehensweise bietet jedoch nicht die nötige Flexibilität, welche an heutige Rechenzentren gestellt wird und bewegt die IT Abteilungen und Betreiber ebensolcher zu einem Umdenken. Skalierbarkeit, Elastizität sind heute genauso wichtig wie Performance und Kapazität. Beim stumpfen Stapeln von Servern für jede neue Anforderung ist nicht nur die Zeit der limitierende Faktor.

Begrenzte Datacenter-Fläche und eine nicht mehr zu erbringende energetische Versorgung sind viele Unternehmen durch die Virtualisierung ihres Datacenter begegnet. Oft wird hier stumpfes Stapeln von Servern durch stumpfes Virtualisieren auf vorhandener Physik ersetzt.

Eine konsequente, aufeinander aufbauende Nord-Süd-Abstraktion für die Erhöhung der Verfügbarkeit und der Möglichkeit einer zentralen und dynamischen Provisionierung wird meist erst im zweiten und dritten Schritt eines Datacenter Re-Designs betrachtet. Eine ganzheitliche Betrachtung ist jedoch immer wichtig, auch dann, wenn nur dedizierte Layer eines Datacenter getauscht oder erneuert werden sollen.

Die Virtualisierung ändert alles

Mit dem Einsatz einer Server-Virtualisierungs-Schicht hält ein bis dahin nicht dagewesenes Maß an Skalierbarkeit und Elastizität Einzug in die x86-Welt der IT Abteilungen (siehe: Abbildung 2). Richtig Schwung bekommt man aber erst, wenn innerhalb eines Redesign die einzelnen Datacenter-Ebenen miteinander verzahnt werden.

Mit einem Unified Storage werden nicht nur die Grenzen zwischen Block und File gelockert, vielmehr trägt ein solches System durch Plug-Ins in der virtuellen Umgebung, wie das von EMC verfügbare VSI-Plugin, zu einer optimalen Integration und Automatisierung im Datacenter bei. Damit werden die Administratoren in die Lage versetzt, eine Provisionierung des Storage aus dem vCenter heraus durchzuführen ohne das Speichersystem direkt zu verwenden.

Konvergierte Netzwerkstrukturen tragen maßgeblich zu einer weiterführenden Konsolidierung im Rechenzentrum bei. Optisches Merkmal ist eine massiv reduzierte Verkabelung (siehe: Abbildung 3).

Unified Storage und konvergente Netze

Technisch werden über ein gemeinsames Medium, das DCE (Data Center Ethernet), iSCSI, IP und Fibre Channel gemeinsam als FCoE (Fiber Channel over Ethernet) übertragen. Zusätzlich profitiert man beim Einsatz von Datacenter-Switches, wie dem „Cisco Nexus 5000“, von der Funktionalität des DCB (Datacenter Bridging) Protokolls. Damit können über Techniken wie PFC (Piority Flow Control) auch über Ethernet verlustfreie Übertragungen erreicht werden.

Auch für die permanente Verfügbarkeit von Systemen und Daten ist das Netzwerk maßgeblich. Zunehmend werden zwei räumlich getrennte Datacenter gekoppelt und bilden so eine Aktiv-Passiv oder auch eine Aktiv-Aktiv Instanz ab.

Variantenvielfalt

Hat man sich nun entschieden ein Re-Factoring des vorhandenen Datacenter durchzuführen, ist es wichtig den für sich passenden Weg dorthin zu finden. Neben dem bekannten DIY-Modell, bei welchem Kunde und Dienstleister ein geeignetes Design erarbeiten und die zur Realisierung benötigten Komponenten auswählen, werden durch Hersteller wie EMC mit VSPEX oder VCE mit dem VBLOCK validierte und zertifizierte Infrastruktur-Stacks angeboten.

Ist ein Trend zu vorkonfigurierten und validierten Umgebungen zu erkennen, ist die Flexibilität bei der Produktauswahl noch immer ein entscheidender Faktor. Das klassische Beratungsgeschäft mit den Einzelkomponenten bietet die höchste Flexibilität.

Technische Abhängigkeiten müssen selbstständig erarbeitet werden, was sich im Design und der Implementierung als Zeit- und Kostenfaktor bemerkbar macht. Die „VSPEX Proven Infrastructure“ von EMC kompensiert durch verschiedene, den Anforderungen entsprechende validierte Konfigurationsvarianten den bei Einzel-Design entstehenden Aufwand und senkt so die zur Implementierung benötigte Zeit.

Standardisierung schafft Freiraum

Trotz einer Standardisierung bleibt ein Höchstmaß an Flexibilität erhalten. Einzelne Layer des Datacenters können weiter verwendet werden, ohne sich innerhalb des Gesamtkonzeptes auszugrenzen. Mit dem „Vblock“ des Unternehmens VCE, einem vollständig validierten und in einem Rack konfigurierten Datacenter, erhält der Kunde ein bisher in der IT unbekannt hohes Maß an Standardisierung.

Der Vblock, bestehend aus Blade-Servern und Netzwerkkomponenten von Cisco, einem Storage (VNX) von EMC und „VMware vSphere“ zur Virtualisierung, bietet auf Grund seiner kompakten Bauweise auf minimalstem Raum ein innovatives und zukunftsfähiges Datacenter. Ist auch die Flexibilität bei Design-Wünschen und Implementierung eingeschränkt, werden Umsetzungszeiten innerhalb eines Datacenter-Projektes massiv reduziert.

File-Sharing, Backup oder Archivierung, abrunden kann man die Dienste des eigenen Rechenzentrums durch eine Expansion in die Cloud. Ganz gleich für welche der Varianten man sich entscheidet, auch ein neues Datacenter besteht aus Servern, Netzwerk und Storage. Neben dem Netzwerk trägt das Speichersystem einen entscheidenden Teil bei.

Unified Storage

„VNX“ bezeichnet das aktuelle Storage-System von EMC und wartet mit vielen Features auf, welche bei einem Re-Design des Datacenter hin zu einer voll virtualisierten und automatisierten Umgebung unterstützt. Dass Speichersysteme von EMC in sich redundant sind ist nicht neu, zeichnet sich aber gerade jetzt bei der Anforderung nach maximaler Verfügbarkeit aus.

Mit Unified wird die Vereinigung von Block und File in einem System verstanden. Das ist wichtig, erlebt doch NFS durch VMware eine Renaissance. Diese Vereinigung erstreckt sich jedoch noch weiter bis hin zur zentralen Management Konsole – das „Unisphere“. Da auch ein konvergentes Netzwerk an einem Ende den Server anbindet und am anderen ein Storage zur Verfügung stellt, sollte das Speichersystem eine entsprechende Flexibilität aufweisen, um die unterschiedlichen Protokolle zu unterstützen.

Im Beispiel einer VNX werden über Line-In Module Kupfer- oder optische Anschlüsse angeboten, welche je nach Karte alle gängigen Protokolle (FC, FCoE, iSCSI, CIFS, NFS, REST und SOAP) mit Datenraten bis 8 Gigabit im FC Bereich und bis 10 Gigabit im Ethernet unterstützen. Diese Flexibilität und Skalierbarkeit spiegelt sich auch in dem möglichen Plattenlayout wieder.

Erweiterbar und sicher

Das Zusammenfassen der unterschiedlichen Tiers (high Performance Tier – EFD, Performance Tier – SAS und Capacity – NL SAS) in einem Pool, ermöglicht beim Einsatz von FAST VP eine vom Storage-System automatisierte Verteilung der Daten gemäß ihrer Anforderung. So wird sichergestellt, dass Daten kostenoptimal aufbewahrt werden und trotzdem mit maximaler Performance zur Verfügung stehen.

Abgerundet wird das Konzept durch einen über EFD Platten erweiterbaren Cache. Auf diese Weise kann ein Großteil der IO Anforderungen über den Cache befriedigt werden und bildet eine solide Basis für IO-hungrige Anwendungen wie Virtual DesktopInfrastructure (VDI).

Eine Verfügbarkeit der Daten wird zum einen durch eine redundante Auslegung aller Komponenten erreicht und kann durch synchrones Spiegeln der Daten (MirrorView) auf ein, in einem separaten Brandabschnitt befindlichen, Storage erhöht werden. Fällt das Storagesystem doch einmal aus, kann nach entsprechenden manuellen Arbeiten die gespiegelte LUN in Betrieb genommen und der produktive Betrieb fortgeführt werden. Unterstützung für einen automatisierten Failover findet man im „SRM“, dem „Side Recovery Manager“ für VMware.

Anbindung an den VMware Side Recovery Manager

Starten die meisten Unternehmen und Organisationen die Virtualisierung Ihres Datacenter sehr verhalten mit unkritischen Maschinen, ändert sich das im weiteren Betrieb meist sehr schnell. Aus einer Hand voll VMs (Virtuelle Maschinen) werden dann viele Systeme mit höherer oder hoher Priorität. Und mit jeder weiteren VM wächst das Netz der Abhängigkeiten.

Kann der Administrator im Fehlerfall zu Beginn der Virtualisierung den Schwenk auf das zweite Datacenter manuell durchführen, wird das Synchonisieren des Speichers, das Erstellen eines Snapshots, das Ausschalten und das priorisierte Einschalten von virtuellen Maschinen, bei mehr als 20 Systemen schon eine schweißtreibende Angelegenheit.

Der VMware Side Recovery Manager unterstützt als Erweiterung im „vCenter“-Server mit einer Schnittstelle in den Storage den Administrator bei diesen Aufgaben. Virtuelle Maschinen werden in Schutzgruppen zusammengefasst und in Wiederherstellungsplänen automatisiert und priorisiert bei einem Fehler verschoben und aktiviert. Einzig die Einschätzung des Fehlerfalls und das Drücken eines Buttons im SRM zum Starten der Aktion sind durch den Administrator noch erforderlich.

Downtime virtueller Maschinen

Ein Fallback, also der Schwenk aller Maschinen zurück auf das Ursprungsspeichersystem, wird ebenfalls automatisiert vollzogen. Über den Knopf „Testen“ ist der Administrator in der Lage einen Failover-Fall zu testen ohne die produktive Landschaft zu tangieren.

Zudem kann bei einem Failover zwischen einer geplanten Migration und einer Notfallwiederherstellung unterschieden werden. So einfach ein Schwenk von einem Datacenter in ein anderes erfolgt, ein Wermutstropfen bleibt: Es kommt zu einem Ausfall der virtuellen Maschinen.

Und diese Downtime dauert so lange, bis alle Maschinen wieder vollständig gestartet wurden. Was aber, wenn ein Ausfall des Speichersystems und damit der virtuellen Maschinen nicht bemerkt werden darf? Wenn ein System einen Recovery Time Objective (RTO) von Null, also dauerhafte Verfügbarkeit besitzen soll?

Der Einsatz von EMC VPLEX

Systeme unterbrechungsfrei anbieten zu können bedeutet: Möglichst alle Komponenten redundant auszulegen, Anwendungen zu Clustern oder auf Fehlermechanismen wie HA und FT zurück zu greifen um eine hohe Absicherung gegen den Ausfall von virtuellen Servern oder den darunter laufenden Hypervisoren zu erreichen. Da sich in virtuellen Zeiten alles als Datei auf einem Storage befindet, fällt auch alles aus, wenn der äußerst seltene Fall eines Storage-Ausfalls eintritt.

Um diesem Umstand entgegen zu wirken, wird eine weitere Abstraktionsschicht nötig. EMC bietet mit VPLEX eine Lösung, mit welcher LUNs auf räumlich getrennten Storage-Systemen zu einem virtuellen Volumen verschmolzen werden.

Durch den Zugriff der Hosts auf das verteilte virtuelle Volumen werden bei einem Ausfall oder einer geplanten Downtime des Speichersystems alle Verbindungen auf den zweiten aktiven Storage umgeleitet. Dieser Vorgang geschieht für den Host oder die VM vollständig transparent und ohne jedwede Unterbrechung.

Verbindung von Storage-Systemen unterschiedlicher Machart

Des Weiteren lassen sich über diesen Abstraktions-Layer in Form einer Storage-Virtualisierung Migrationen zwischen herstellerunterschiedlichen Speichersystemen durchführen. „VPLEX“ gibt es in den Versionen „Local“, „Metro“ und „Geo“ (siehe: Abbildung 6). Bei der Local-Variante handelt es sich um eine Speichervirtualisierung, mit welcher unterschiedliche Storage-Systeme als ein logisches Speichersystem dem Host bereitgestellt werden.

VPLEX Metro und VPLEX Geo unterscheiden sich durch ihre Datensynchronität, welche auf die maximalen Entfernungen der Systeme zurückzuführen ist. Metro dient zur Verbindung von Datacenter über kleine und mittlere Entfernung und führt eine synchrone Datenspiegelung durch. Die Variante Geo ist hingegen für weltumspannende Verbindungen gedacht und arbeitet in einem asynchronen Modus.

Für kleine Umgebungen wurde Mitte 2012 eine „VPLEX Express“-Version vorgestellt. Bei dieser Version wird je Seite eine Engine und eine Volumenlizenz von 40 Terabyte für das verteilte virtuelle Volume geliefert. Die Lizenzierung des virtual Volume bei Standard VPLEX Systemen erfolgt Terra-Byte genau. Eine Skalierung ist durch das Hinzufügen weiterer Engines möglich.

Ohne Split Brain

Zur Vermeidung des bekannten Split-Brain-Problems kann an einen dritten unabhängigen Standort ein so genannter „Witness“ installiert werden (siehe: Abbildung 7). Der Witness koordiniert den Failover und führt alle dazu nötigen Schritte durch.

Bei dem Witness handelt es sich um eine virtuelle Maschine, welche auf einem ESX Host an die VPLEX Systeme beider Standorte angebunden wird. Die Themen Disaster Recovery, Skalierbarkeit und zentrales Management sind nicht nur Anforderungen an das Speichersystem in einem Datacenter. Vielmehr ziehen sich die Anforderungen wie ein roter Faden über alle Ebenen des Rechenzentrums hinweg und gelten genauso für die zur Virtualisierung nötigen Host-Systeme. Ein Kandidat ist das „UCS“-System von Cisco als Server Blade.

Ganz ohne physikalische Server geht es nicht

Auch wenn ein Datacenter vollständig virtualisiert ist, ganz ohne physikalische Server geht es dann doch nicht. Die Anforderung an einen Server, welcher als ESX Host fungiert, so meint man, sollte überschaubar und unspektakulär sein.

Man bedient sich eines Servers, den man mit genügend Ethernet-Interfaces für Daten, Management und „vMotion“ ausstattet und über einen dedizierten HBA die Anbindung an den Storage realisiert. Skalierbarkeit wird durch eine iterativen Vermehrung der Systeme erreicht.

Abgesehen von dem Fakt, dass bei benötigten sechs Interfaces je Server bei 5 Servern bereits ein 24 Port Switch überfordert ist, wird das Thema Converged Network damit ad absurdum geführt. Betrachtet man noch den energetischen Aspekt sucht man sehr schnell nach anderen Lösungsvarianten.

Cisco macht alles anders

Anders macht es Cisco mit dem UCS Blade System. Hierbei werden Netzwerk und Server so kombiniert, dass auf minimalsten Raum mit der niedrigsten Port-Dichte ein Maximum an Skalierbarkeit und Performance erreicht wird. Die gesamte Steuerungslogik wurde nicht in das Chassis implementiert, sondern als ASIC in einen Switch ausgelagert, welcher als Cluster die Logik des Blade-Centers übernimmt.

Die Konnektivität zwischen dem Chassis und den Switches mit der Bezeichnung „Fabric Interconnect“ erfolgt über nach außen geführte Line-Cards als FEX (Fabric Extender) in das Chassis. Die Verbindung zwischen FEX und Fabric Interconnect wird über 4 oder 8 Twinax-Verbindungen pro FEX mit einer Datenrate von 10 Gigabit realisiert.

Damit existieren bei einer maximalen Ausbaustufe zwischen Server und Netzwerk 16 physikalische Verbindungen a‘ 10 Gigabit, über welche IP, iSCSI und FC über Ethernet als FCoE transportiert werden. Pro Chassis lassen sich 6 Blades halber Baubreite oder vier voller Baubreite unterbringen. Die Erweiterung eines Chassis erfolgt einfach durch die Verbindung des neuen Chassis mit den vorhanden "Fabric Interconnect Cluster".

UCS und CNA

Die in dem Chassis befindlichen Blades sind statuslos und werden über eine Hardware-Abstraktionsschicht in Form eines Server-Profils betrieben. Diese Profile ermöglichen einen enormen Zeitgewinn bei der Implementierung neuer Blades oder einem Disaster Recovery nach einem Ausfall

Die Administration des Systems erfolgt auf einem zentralen Management-Interface welches per Browser über die Cluster-IP-Adresse des Fabric Interconnect angesprochen wird. Zusätzlich ist eine Steuerung durch Drittanbieter-Produkte über die offene XML API möglich.

Die für das System verfügbaren Blades reichen von Low-Entry-Modelle wie dem Rechner „B22 M3“ bis hin zu High-End-Blades mit vier E7 Prozessoren und 40 Cores und bis zu 1 Terabyte Speicher. Speziell für SAP HANA steht ein von SAP zertifiziertes Blade „B230 M2“ zur Verfügung.

Über den CNA (Converged Network Adpater) lassen sich iSCSI, Fibre Channel und Ethernet Adapter logisch abbilden. Dabei werden auf dem „P81E“ bis zu 128 virtuelle Interfaces unterstützt. Neben einer Datenrate von 10GB wird der Gedanke des converged Networks bei Cisco konsequent verfolgt. Wer einen Switch sucht, der diese und weitere Anforderungen erfüllt, sollte sich mit dem „Nexus 5000“ beschäftigen.

Nexus 5000 und Nexus 2000

Bei dem Nexus 5000 handelt es sich um einen Datacenter-Switch, welcher durch seine offene Unified-Fabric-Infrastruktur und für den Aufbau konvergenter Infrastrukturen in virtualisierten Umgebungen prädestiniert ist. Der Switch liefert ein hochperformantes 10 Gigabit Ethernet über welches IP, FC und FCoE durch die Unified-Ports transportiert werden kann.

Derzeit sind die Nexus 5000 Switches als 48 Port oder 96 Port Version erhältlich. Die Switches sind in der Basiskonfiguration mit 32 oder 48 Unified-SFP-Ports ausgestattet und lassen sich über Erweiterungsschächte modular vergrößern.

Über eine Layer-3 Karte, welche entweder als Daugther-Card bei dem „Nexus 5548“ oder einem separaten Einschubmodul bei dem „Nexus 5596“, kann der Switch um eine Routing-Funktionalität mit den bekannten Protokollen erweitert werden. Die Anbindung von RJ45 Kuperanschlüssen lassen sich über einen an den Nexus 5000 angeschlossene Fabric Extender vom Typ Nexus 2000 realisieren.

Der Fabric Extender

Bei einem „Nexus 2000“ handelt es sich um eine nach außen geführte Line-Card, welche ihr Bootimage von ihrem Parent, dem Nexus 5000 erhält. Die Konfiguration erfolgt über die CLI des Nexus 5000 durch dedizierte Interfaces.

Der Nexus 2000 Fabric Extender kann über Glasfaser oder Twinax Kabel über die vier SFP Uplinks mit dem Nexus 5000 verbunden werden. Den FEX gibt es als 1-Gigabit- oder 10-Gigabit-Ausführung mit 24 oder 28 Ports. Üblicherweise findet die Nexus 2000 FEX als Switch für Management und Legacy-Systeme Verwendung.

Der Autor:

Stefan Fehr ist Technical Account Manager bei der MTI Technology GmbH.

(ID:35856290)