Was gehört ins Cluster Shared Volume? Wo liegen die Nutzdaten?

[TPok 11]

Hallo,

 

ich möchte mich ein wenig mit den Themen Windows Server 2012, Hyper-V und Cluster beschäftigen und habe dazu eine Demoumgebung mit folgender Konfiguration aufgesetzt: 2 Virtualisierungshosts mit Windows Server 2012 und 1 Windows Server 2012 mit iSCSI-Target als SAN-Ersatz.

Auf den Hosts ist bereits Hyper-V und Failover-Clustering installiert und konfiguriert. Außerdem habe ich ein Cluster Shared Volume erstellt und eingebunden.

 

Ich möchte nun mehrere virtuelle Maschinen mit verschiedenen Funktionen (Fileserver, SQL-Server, ...) erstellen und mit diesen Funktionen wie Live-Migration und anderes testen.

 

Allerdings bin ich mir nicht sicher, wie ich die Datenablage gestalten soll. Ich finde dazu immer nur so allgemeine Formulierungen wie "die VM gehört ins Cluster Shared Volume", mit denen ich nicht wirklich etwas anfangen kann. Bei einem physischen Server habe ich es bis jetzt so gehalten, dass die Betriebssystem-Partition auf den internen Platten lagen und die Nutzdaten auf einer oder mehrerer LUNs auf dem SAN.

 

Bei der Virtualisierung habe ich ja nun im Prinzip 3 Komponenten, die ich sinnvoll platzieren muss:

1. Die Definition der VM, also die Hyper-V Files - Diese sollten wohl auf das Cluster Shared Volume.

 

2. Die OS-Partition - Diese wird wohl in einer VHD liegen. Auch aufs CSV?

 

3. Die Nutzdaten - Hier sehe ich mehrere Alternativen:

- In eine VHD, die in dem CSV liegt

- In eine VHD, die auf eine separaten LUN des SAN liegt

- auf einer separaten LUN des SAN, die direkt über den iSCSI-Initiator innerhalb der VM eingebunden wird.

 

Gefühlt würde ich hier die 3. Variante bevorzugen, da dies von der Leistung her wohl optimal sein sollte und man so auch die Features des SAN (Snapshots usw.) nutzen kann.

 

Aber wie mach man das ganze "richtig"? Wenn es dazu ein Whitepaper, Howto, etc. gibt, nehme ich auch gerne einen Link.

 

Gruß

Stephan

[Dukel 436]

Du meinst die OS Daten von den Virtuellen Maschinen?

 

Ich würde alle Virtuellen Disks in VHD's legen und diese auf das CSV (außer bei speziellen Anforderungen).

Bei deiner 3. Variante verlierst du andere Features (Snapshots der VM) und von der Leistung wird das wohl nicht besser sein (da alles über das Virtuelle LAN geht) wie mit iSCSI Initiator.

bearbeitet 7. Januar 2013 von Dukel

[Lian 2.332]

Zu dem Thema Cluster Shared Volumes unter Windows Server 2012 kann ich folgenden TechNet Artikel empfehlen: http://technet.microsoft.com/en-us/library/jj612868.aspx

[Necron 71]

Hi,

 

die Daten der VM gehören auf das CSV. Das Betriebssystem welches du auf der VM installierst, wird dabei in die VHD der VM installiert und diese liegt wiederum auf dem CSV.

 

Was verstehst du unter Nutzdaten?

[Dukel 436]

Vermutlich Datenpartition des Fileservers oder Datendisks für SQL Server.

[TPok 11]

Danke für den Technet-Artikel. Den habe ich auch vorhin gefunden. Der ist wirklich gut.

 

Dukel hat recht. Mit Nutzdaten meine ich die Datenpartition des Fileservers, Daten- und Log-Partition des SQL-Servers, usw.

Diese werde ich ja wohl nicht mit in die selbe VHD packen, in der auch das Betriebssystem der VM installiert ist. Außerdem haben diese ja auch teils sehr unterschiedliche Zugriffscharakteristika. Bei einem physischen SQL-Server nehme ich ja z.B. auch unterschiedliche Platten (und. ggf. RAID-Level) für DB-Daten und Logs.

 

Im Technet-Artikel steht dazu folgendes:

 

 

Consider a physical server for which you would organize the disks and files as follows:

• System files, including a page file, on one physical disk
• Data files on another physical disk
   

For an equivalent clustered virtual machine, you should organize the volumes and files in a similar way:

• System files, including a page file, in a VHD file on one CSV
• Data files in a VHD file on another CSV 

 

Wenn ich das also richtig verstehe, lege ich also mehrere CSVs an, die ggf. unterschiedliche Platten, RAID-Level, etc. des SAN nutzen und damit auf unterschiedliche Zugriffscharakteristika optimiert sind und packe da die Datenpartitionen der VMs als VHD-Files drauf.

 

Damit liegt alles, was die VMs benötigen in CSVs und trotzdem habe ich eine Optimierung des Storage Systems hinsichtlich der verschiedenen Anforderungen. Richtig?

[RHaneberg 10]

Danke für den Technet-Artikel. Den habe ich auch vorhin gefunden. Der ist wirklich gut.

 

Dukel hat recht. Mit Nutzdaten meine ich die Datenpartition des Fileservers, Daten- und Log-Partition des SQL-Servers, usw.

Diese werde ich ja wohl nicht mit in die selbe VHD packen, in der auch das Betriebssystem der VM installiert ist. Außerdem haben diese ja auch teils sehr unterschiedliche Zugriffscharakteristika. Bei einem physischen SQL-Server nehme ich ja z.B. auch unterschiedliche Platten (und. ggf. RAID-Level) für DB-Daten und Logs.

 

Im Technet-Artikel steht dazu folgendes:

 

 

Wenn ich das also richtig verstehe, lege ich also mehrere CSVs an, die ggf. unterschiedliche Platten, RAID-Level, etc. des SAN nutzen und damit auf unterschiedliche Zugriffscharakteristika optimiert sind und packe da die Datenpartitionen der VMs als VHD-Files drauf.

 

Damit liegt alles, was die VMs benötigen in CSVs und trotzdem habe ich eine Optimierung des Storage Systems hinsichtlich der verschiedenen Anforderungen. Richtig?

 

Genau so kann man es ausdrücken. Unterschiedliche Anforderungen an die Systeme benötigen oft unterschiedliche Konfigurationen. Im SAN bedeutet das zum Beispiel separate Spindel/Arrays/LUNs/RAID Level für einen SQL Server weil durch die evtl hohen IO Anforderungen ein RAID 5 nicht optimal wäre und schon garnicht die Datenbank zusammen mit 15 anderen Systemen im auf der gleichen physischen Platte laufen soll. Daher generiert man verschiedene "Bereiche" im SAN die diesen Anforderungen entsprechen und wo die Daten/OS Daten (VHDs) etc drauf kommen und bindet diese als CSV in den Cluster ein.

In Praxis könnte es also bedeuten man hat ein CSV für Low Performance Systeme (RAID 5, großes Array, große LUNs) und ein CSV für DB1 (RAID 10 oder 50 oder whatever, separates Array um die platten physikalisch zu trennen, eine LUN) und so weiter.

Hmmm liest sich dann doch wieder verwirrend ;)

Aber kurz gefasst ja so ists richtig :D

[NilsK 2.785]

Moin,

 

die Aufteilung auf verschiedene CSVs würde ich nicht pauschal vornehmen, wenn alle auf demselben SAN liegen. Das ist dann schon eine Frage des Feindesigns - kann man machen, ist aber nicht automatisch besser.

 

In Windows Server 2012 sind sowohl die CSV selbst leistungsfähiger als auch das neue VHDX-Format. Microsoft spricht davon, dass Pass-through Disks und direkt in die VM eingebundene LUNs nur noch selten nötig sind. Für die meisten "üblichen" Systeme sollten VHDX-Dateien im Hinblick auf Performance ausreichen.

 

Ein "richtig" oder "falsch" gibt es da nicht. Am Ende spielt ja auch noch eine Rolle (wenn nicht "die" Rolle), ob der SQL Server überhaupt unter so hoher Last steht, dass es eine Aufteilung der Speicherbereiche braucht.

 

Schöne Grüße, Nils

bearbeitet 8. Januar 2013 von NilsK

[TPok 11]

Erstmal danke für die wertvollen Antworten. Ich denke, ich hab das Prinzip inzwischen verstanden und der Testcluster läuft auch schon mit einigen VMs.

 

Die "Optimierung" der Storage in einer Echtumgebung ist sowieso ein eigenes Thema. Nicht jeder manuelle Eingriff trägt zur Leistungssteigerung bei und auch nicht jede Annahme bei der Planung bewahrheitet sich in der Realität. Soviel ist mir klar. Glücklicherweise bekommt man durch die verschiedenen Abstraktionsebenen eine Menge Spielraum auch im Produktivsystem nachzuoptimieren, wenn sich Ressourcenengpässe zeigen.

 

Gruß

Stephan

bearbeitet 8. Januar 2013 von TPok