NetApp Tech OnTap
     

Kundenreferenz: Gesammelte Erfahrungen zu
Hyper-V und NetApp

Der geschäftliche Erfolg von Avanade hängt davon ab, wie gut unsere weltweiten Berater den Anforderungen von Firmenkunden begegnen. Vor diesem Hintergrund hat Avanade erhebliche Investitionen in IT-Applikationen und -Services getätigt, um mit deren digitalen Tools unsere Ziele zu erreichen. Zu den zentralen Gründen, warum wir ursprünglich einen Wechsel auf die Server-Virtualisierung mit Microsoft® Hyper-V™ untersuchten, zählten die flexiblen Disaster Recovery-Lösungen und Verfügbarkeitsszenarien. Wir waren der Meinung, dass uns dieser Architekturtyp in Verbindung mit einer Shared Storage Backend Lösung vor einem katastrophalen Ausfallzenario bewahrt, indem sie unseren Applikationen und Services einen einfachen Failover auf einen anderen Knoten sowie einfaches Replizieren der Daten von und zu einem entfernten Data-Center gestattet.

Neben anderen wichtigen Argumenten für den Wechsel auf Hyper-V war letztendlich die Flexibilität bei der Wiederherstellung von virtuellen Server-Umgebungen im Rahmen eines Disaster Recovery ausschlaggebend dafür, dass unser CIO die erhebliche Vorabinvestition absegnete. Weitere Beweggründe zugunsten von Hyper-V waren die folgenden Erfordernisse:

  • Reduzierung unserer Datacenter-Kosten (Rack-Kapazität, Stromversorgung und Kühlung), ohne Abstriche bei der Qualität der Service-Bereitstellung
  • bessere Ausnutzung unserer leistungsstärkeren Server-Ressourcen
  • schnellere Bereitstellung neuer Applikations-Server-Umgebungen

Wir hofften, auf all diesen Gebieten einen wichtigen Vorstoß zu machen. So meldeten wir uns als Beta-Benutzer für den noch nicht veröffentlichten Windows Server® 2008 with Hyper-V von Microsoft an. An diesem Punkt begann unsere Arbeit erst richtig.

Implementierung von Hyper-V

Bevor ich näher auf unsere aktuelle Hyper-V Umgebung eingehe, möchte ich zunächst einige Hintergrundinformationen zu unserer IT-Infrastruktur vor Implementierung von Hyper-V geben. Unsere Umgebung besteht aus drei Datacentern (in den USA, Europa und Asien). Die meisten von unseren Beratern genutzten Applikations-Services stammen aus dem US-amerikanischen Datacenter in Seattle. Als wir mit der Implementierung von Hyper-V begannen, waren weit mehr als 200 verteilte Server im Einsatz, welche die Arbeit der über 8.000 Mitarbeiter bei Avanade unterstützten.

Seit Avanade als Joint Venture zwischen Microsoft und Accenture fungiert, baut die IT-Umgebung zur Unterstützung des Außendienstes und des allgemeinen Geschäftsbetriebs hauptsächlich auf Microsoft Applikationen. Zu diesen Applikationen zählen ein umfangreich installierter Microsoft Office SharePoint® Server, Microsoft Exchange, Microsoft SQL Server®, Microsoft Team Foundation Server, Microsoft Terminal Services und 120 Web Front End-gestützte Business-Applikationen.

Um unsere künftige virtuelle Server-Umgebung optimal zu nutzen, haben wir uns entschlossen, Microsoft Hyper-V zusammen mit einer Shared Storage-Infrastruktur zu betreiben. Zur Unterstützung unserer SQL Server-Infrastruktur verwendeten wir bereits NetApp® Storage mit iSCSI. Daher lag es für uns nahe, NetApp auch für die künftige Implementierung von Hyper-V in Erwägung zu ziehen. Wir schätzten die Flexibilität des Systems und die Effizienz von Technologien wie etwa NetApp Snapshot™ und SnapMirror® zur Datensicherung und -replizierung. Wir waren es gewohnt, schnelle Storage-Lösungen für neue Applikationen bereitstellen zu können und begannen außerdem mit der Untersuchung von Kapazitätsfreigaben, indem wir die NetApp Deduplizierung im Primärspeicher einsetzten.

Hier erwarteten wir, dass sich NetApp für Hyper-V genauso eignen würde wie es bei unseren anderen Umgebungen der Fall war. Die bei Hyper-V und NetApp über iSCSI durchgeführten Performance-Tests bestätigten, dass wir für die Kombination NetApp/Hyper-V eine ausreichend hohe Performance erreichen.

Mit dem Entschluss zur Weiterführung wurde die Hyper-V Implementierung für zwei Bereiche bereitgestellt: Produktionsumgebung sowie Test- und Entwicklungsumgebung. Im Folgenden seien einige Höhepunkte der aktuellen Implementierung genannt:

Produktionsumgebung

  • Microsoft Hyper-V für Windows Server 2008, Kerninstallation, Enterprise Edition
  • konfiguriert als Hyper-V Cluster mit vier Nodes
  • 27 Child-Partitionen (Virtual Machines)
  • virtualisierte Applikationen, die entweder auf dem Windows Server 2003 oder unter dem Gast-Betriebssystem des Windows Server 2008 laufen
    Virtualisierte Applikationen
  • Team Foundation Server
  • Systems Center Operations Manager 2007
  • Microsoft Windows Server 2008 Terminal Services (TS-Farm und TS-Gateway)
    Server und Storage
  • Sun Fire X4150 Server mit jeweils zwei Quad-Kernprozessoren, 32 GB RAM
  • NetApp FAS3040 Storage System, konfiguriert mit iSCSI-Protokoll

Entwicklungs- und Testumgebung

  • Microsoft Hyper-V für Windows Server 2008, Vollinstallation, Enterprise Edition
  • ein Cluster mit 4 Nodes
  • ein Cluster mit 2 Nodes
  • drei Standalone-Server
  • mehr als 150 Child-Partitionen (Virtual Machines), verteilt über die Hyper-V Hosts der Entwicklungs- und Testumgebung
    Virtualisierte Applikationen
  • verschiedene, jedoch produktive Applikationen
    Server und Storage
  • Dell 2950 Server mit jeweils zwei Quad-Kernprozessoren, 32 GB RAM
  • NetApp FAS3020 Storage System, konfiguriert mit iSCSI-Protokoll

VMware DRS

Abbildung 1) NetApp Support für Hyper-V Cluster mit vier Nodes von Avanade

Entscheidungen auf dem Weg zu Hyper-V

Rückblickend auf unsere Entwicklungserfahrungen lässt sich feststellen, dass unser Ansatz in einigen kritischen Bereichen zum allgemeinen Projekterfolg beigetragen hat. Dazu gehören:

  • Entscheidung über die bereitzustellende Version von Microsoft Windows Server 2008, Vollversion oder leichtere Version Windows Server Core
  • Entscheidung über die Konfiguration des NetApp Systems zur Nutzung mit den VHD-Dateien (Dateien der virtuellen Festplatte) der Hyper-V Child-Partitionen
  • Entwicklung eines Prozesses, mithilfe dessen eine neue virtuelle Festplatte schnell zur Verfügung gestellt und an einen vorhandenen Hyper-V Node angeschlossen werden kann

Entscheidung über die Kernversion von Microsoft Windows Server 2008
Wir brauchten einige Zeit, um herauszufinden, ob Server Core oder die Vollversion von Windows Server 2008 zur Anwendung kommen soll. Wir wussten, dass Server Core sicherheitstechnisch gesehen weniger Management-Aufwand bedeutet und somit wahrscheinlich weniger häufig Patches durchgeführt werden müssten. Dies war wichtig, da auf jedem Host letztlich möglicherweise 10, 15 oder 20 Virtual Machines laufen. Um die Virtual Machines hochverfügbar zu machen, hatten wir vor, die Anzahl der Host-Server-Neustarts auf ein Minimum zu reduzieren.

Server Core verfügt jedoch über eine Befehlszeilenschnittstelle, die auf die First-Level-Mitarbeiter im Betrieb abschreckend wirkte. Sie fragten uns: „Wie gut werden wir Server Core betreuen oder auftretende Störungen beheben können?“ Nach einigen Verhandlungen haben wir uns für Server Core entschieden. Diese Entscheidung erwies sich als äußerst gewinnbringend. Gleich nach der Implementierung funktionierte alles richtig gut, und eine sehr solide Infrastruktur war bereitgestellt. Unsere Support-Mitarbeiter konnten nach wie vor Standard-Tools für Windows Server 2008 verwenden, darunter MMC Snap-Ins und Administrations-Tools für Remote Server. Durch diese Erfahrung wurden wir alle zu großen Fans von Server Core.

Konfigurieren von NetApp Storage zur Nutzung mit Hyper-V Child-Partitionen und VHDs

Wir wussten, dass die Deduplizierungs- und Snapshot-Technologie von NetApp auf der Volume-Ebene funktioniert. Also entschieden wir uns, Storage zur Nutzung mit Hyper-V Child-Partitionen einzurichten, um diese Funktionen bestmöglich auszunutzen.
Aufgrund der vielen doppelten Daten in Instanzen desselben Gastbetriebssystems gingen wir von beträchtlichen Einsparungen aus, als wir die NetApp Deduplizierung auf einem Entwicklungs- und Test-Volume mit vorhandenen Hyper-V VHDs durchführten. Äußerst zufrieden konnten wir Speicherplatzeinsparungen von mehr als 50 % feststellen und freuen uns bereits darauf, die Deduplizierung auch in unserer Produktionsumgebung einzusetzen. In Anbetracht der auf Volume-Ebene realisierten Funktionen haben wir die folgenden Verfahrensweisen angewandt:

  • Zusammenfassung von Child-Partitionen, auf denen dasselbe Gastbetriebssystem läuft, in jeweils dasselbe flexible NetApp Volume (FlexVol®).
    Für unsere Produktionsumgebung bedeutete dies, dass sich die Child-Partitionen des Windows Server 2003 und die Partitionen des Windows Server 2008 jeweils auf verschiedenen Volumes befinden würden. (In unserer Entwicklungs- und Testumgebung war diese Regel leicht anzuwenden, da wir zu weiteren Testzwecken mit NetApp Snapshots für die gesamte Umgebung schnell ein Backup erstellen und dieses wieder einspielen können. In diesem Fall kann die Umgebung mehr als ein Gastbetriebssystem umfassen.)
  • Herstellung eines 1:1 Mappings von VHDs auf LUNs.
    Jeder Child-Partition ist eine LUN zugeordnet. Auf dieser werden die VHD-Dateien (Dateien der virtuellen Festplatte) und die zugehörigen Daten der Child-Partition gespeichert. Dieses 1:1 Mapping bedeutet, dass eine LUN nicht durch mehrere Child-Partitionen gemeinsam genutzt wird. Dadurch wird die Unabhängigkeit der Child-Partitionen gewährleistet. Nichtsdestotrotz befinden sich auf einem NetApp Volume immernoch mehrere LUNs (und VHDs).
  • Verwendung der Microsoft Volume GUIDs, um jeder Child-Partition einen eindeutigen Identifier zuzuweisen.
    Da wir viele Virtual Machines auf unseren Hyper-V Clustern betreiben, gingen uns schnell die Laufwerksbuchstaben aus. Bereitstellungspunkte konnten wir nicht verwenden, denn das hätte unerwünschte Abhängigkeiten zwischen den Festplatten zur Folge gehabt. Wir entschieden uns dafür, die Festplatten auf unseren Clustern über die Volume GUIDs zu identifizieren. Statt eine LUN auf einem Laufwerk mit Laufwerksbuchstaben zu speichern (z. B. Laufwerk E:), vergaben wir überhaupt keine Laufwerksbuchstaben. Wenn Sie keinen Laufwerksbuchstaben vergeben, erhalten Sie eine GUID-Zuordnung, die ungefähr folgendermaßen aussieht:  \\?\Volume{c9612f6f-702e-11dc-b79a-00123f769676}\.

In den folgenden Abschnitten wird die aktuelle Speicherkonfiguration unserer Produktions-, Entwicklungs- und Testumgebungen beschrieben.

Speicherkonfiguration der Hyper-V Produktionsumgebung
Zwei flexible NetApp Volumes (FlexVol) speichern Daten zu jeder Child-Partition. Zur Performance-Maximierung sind die VHD-Dateien der Child-Partition in Hyper-V als „fixed VHD“-Dateien konfiguriert. Wir wussten, dass wir durch die Deduplizierungstechnologie von NetApp immernoch Speicherplatz einsparen können, entsprechend den Kundenerwartungen bei der Verwendung dynamischer VHDs.

Volume 1:

  • Speichert Daten von sieben Windows Server 2003 Child-Partitionen (Virtual Machines), wobei die Daten jeder Child-Partition auf einer eigenen iSCSI LUN gespeichert werden.
  • Dem Volume sind 500 GB Speicherkapazität zugeordnet.
  • Das Volume ist derzeit zu 48 % belegt.

Volume 2:

  • Speichert Daten von 20 Windows Server 2008 Child-Partitionen, wobei die Daten jeder Child-Partition auf einer eigenen iSCSI LUN gespeichert werden.
  • Dem Volume sind 1,25 TB Gesamtspeicherkapazität zugeordnet.
  • Das Volume ist derzeit zu 76 % belegt.

Speicherkonfiguration der Hyper-V Entwicklungs- und Testumgebung
Mehr als 30 flexible NetApp Volumes (FlexVol) speichern Entwicklungs- oder Testdaten zu Child-Partitionen. Die VHD-Dateien der Child-Partition sind in Hyper-V als „Dynamic VHD“-Dateien konfiguriert, um sie in der Test- und Entwicklungsphase leichter vergrößern bzw. verkleinern zu können.

Volume 1: Verwendung durch das Entwicklungsteam

  • Speichert Daten von 25 Windows Server 2008 Child-Partitionen.
  • Die Daten jeder Child-Partition sind auf einer eigenen iSCSI LUN gespeichert.
  • Die Größe von LUNs reicht von 40 bis 100 GB.
  • Dem Volume sind 600 GB Gesamtspeicherkapazität zugeordnet.
  • Das Volume ist derzeit zu 39 % belegt.

~32 Volumes: Verwendung durch das Entwicklungsteam und das Testteam

  • Volumes speichern zusammen Daten von mehr als 100 Windows Server 2008 Hyper-V Child-Partitionen.
  • Die Daten jeder Child-Partition sind auf einer eigenen iSCSI LUN gespeichert.
  • LUNs sind im Schnitt 20 GB groß.
  • Auf jedem Volume befinden sich im Schnitt drei LUNs.
  • Den Volumes sind zusammen 2,5 TB der gesamten Speicherkapazität zugeordnet.

Schnelle Bereitstellung von neuen LUNs und VHDs
Was wir ebenfalls an NetApp schätzen, ist die Flexibilität des Back-End Storage Arrays. So war es einfach, eine Methode zur Bereitstellung neuer LUNs zu entwickeln und eine brandneue Festplatte (VHD) in nur fünf Minuten an einen Hyper-V Node anzuschließen. Wir entwickelten eine Reihe von Skripten zur Ergänzung von Secure Shell-Befehlen (SSH). Die Skripte erstellen die LUN und verknüpfen sie automatisch mit unserem Hyper-V Cluster. Durch diesen Prozess können wir nun die LUN-Bereitstellung automatisieren. Sobald der Prozess vollständig dokumentiert ist, werden wir voraussichtlich so weit sein, ihn an alle unsere Applikationsmitarbeiter zu übergeben, damit sie ihn selbst durchführen können. Der Prozess sieht vor, über den Host die Befehle auszuführen, und schon ist die Verknüpfung erstellt. So einfach ist das!

Was steht noch an?

Basierend auf unseren bisherigen Erfahrungen gehen wir stark davon aus, dass von nun an alles virtualisiert wird. Wenn Sie mich nach unserer Ziel-Architektur fragen: Ich sehe eine Verbindung zwischen NetApp Storage sowohl zu unserem Hyper-V Cluster als auch zu unserem SQL Server Cluster Unsere Front-End Anwendungen werden schließlich alle auf den Hyper-V Cluster migriert; wir gehen davon aus, dass er von gegenwärtig vier Nodes auf acht Nodes anwachsen wird. Aktuell sind wir auch dabei, die NetApp Firmware auf unserer Produktionsumgebung zu aktualisieren, so dass wir letztlich die NetApp Deduplizierung anwenden können und damit den aufgrund unserer VMs stetig wachsenden Speicherbedarf reduzieren können.

Pläne zur Virtualisierung
Wir planen, unsere SharePoint Implementierung zu virtualisieren, und wir gehen davon aus, dass sogar unser SQL-Server Cluster virtualisierungsfähig ist. In Anbetracht des stetig wachsenden Hyper-V Support seitens Microsoft ziehen wir sogar in Betracht, unsere Edge Server, Firewall ISA Server und IIS Web Front-End-Server zu virtualisieren. Über die nächsten sechs bis neun Monate wollen wir viele der Single-Box- und Single-Application-Server virtualisieren. Diese nehmen aktuell eine ganze Menge Rack-Platz im Datacenter ein. Dabei handelt es sich um Anwendungen, die von gerade mal zehn bis zwanzig Personen verwendet werden, z.B. in der HR- oder Finanz-Abteilung. Wir betrachten die Virtualisierung dieser Anwendungen als "Easy-Wins" auf unserem Weg zu einer weitgehenden Virtualisierung.

Viele unserer Hyper-V Einsatzfelder werden immer noch weiterentwickelt. Unser Vorgehen wird dabei von Produktreleases durch Microsoft beeinflusst, die eine engere Integration von Microsoft Lösungen mit Hyper-V – z. B. Service Center Virtual Machine Manager (SCVMM) und Microsoft Data Protection Manager (DPN) – ermöglichen. Wir haben sogar bereits mit Tests der Funktion P-to-V (physical to virtual) des SCVMMs begonnen. Erste Ergebnisse lassen erhoffen, dass diese Funktion eine schnelle Konvertierung vieler unserer physikalischen Server in Virtual Machines erlaubt. Außerdem untersuchen wir, wie neue NetApp Datensicherungstechnologien am besten eingebunden werden können, d. h. Technologien, die VSS für Microsoft Hyper-V nutzen, um schnelle Snapshots einer Basis-Virtual Machine zu erstellen. Dabei denken wir daran, diese Art von NetApp Technologie für Management- und Datensicherungszwecke einzusetzen, in Verbindung mit dem Data Protection Manager.

Datensicherungs- und DR-Pläne
Wir arbeiten auch an Prozessen für eine gestufte Datensicherung.

  • Einige Hyper-V Daten würden durch den Einsatz des Microsoft Data Protection Manager gesichert werden, oder durch eine Kombination aus den Datensicherungstechnologien DPM und NetApp. Hierfür würde VSS genutzt werden.
  • Aktuell verwenden wir DPM in unserer Produktionsumgebung, die innerhalb jeder Child-Partition einen Agenten erfordert.
  • Einige Daten würden mittels NetApp Snapshot gesichert werden.  (Snapshot wird derzeit in unseren Entwicklungs- und Testumgebungen eingesetzt.)
  • Einige kritische Daten würden unter Verwendung von NetApp SnapMirror zwischen unserem Datacenter in Seattle und einem anderen externen DR-Standort in einer unserer Niederlassungen im Osten der USA repliziert werden.

Schlussfolgerung

Bei der Arbeit mit Microsoft Hyper-V und NetApp haben wir ausgezeichnete Erfahrungen gemacht. Wir haben wertvollen Speicherplatz hinzu gewonnen (mittels NetApp Deduplizierung) und sind nun in der Lage, mindestens vier Server in weniger als einer Stunde automatisch bereitzustellen. Wir rechnen damit, dass sich dieser Prozess mithilfe von SCVMM (System Center Virtual Machine Manager) sogar beschleunigen lässt. Unsere Virtual Machines bleiben hochverfügbar. Außerdem konnten wir bei Hyper-V und NetApp eine hohe Performance feststellen.

© 2009 Avanade Inc. Alle Rechte vorbehalten. Name und Logo von Avanade sind eingetragene Marken in den USA und in anderen Ländern. Andere Marken- oder Produktnamen sind Marken ihrer jeweiligen Inhaber.

Ihre Meinung zu dieser Kundenreferenz?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Online Community!
Andy Schneider

Andy Schneider
Senior Systems Engineer
Avanades

Andy Schneider begann seine Karriere bei Avanade vor dreieinhalb Jahren als Gebietsberater. Seit den letzten zwei Jahren ist er im zentralen IT-Infrastrukturteam des Unternehmens tätig, in das er seine Außendiensterfahrungen einbringt. Andy Schneider und sein Team entscheiden über optimale Einsatzmöglichkeiten für neue Technologien in der Produktionsumgebung von Avanade.

Explore