none
File-Server Cluster auf Basis Hyper-V Cluster RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo liebe Cluster-Gemeinde,

     

    ich habe ein kleines Problem, und entschuldige mich schonmal vorab, weil die Lösung sicherlich ganz banal ist.

    Die Ausgangslage: Ich habe 3 physische Server, die als Hosts jeweils 2 VM's hosten ( 2 x DC, 2 x FS, 2 x TS, unterschiedlich verteilt natürlich).  Als Betriebssystem setze ich sowohl auf den Host's als auch den VM's Windows Server 2008 R2 ein, aktueller Patch-Stand. Hinsichtlich des Speichers setze ich 2 Infortrend RAID Systeme (eins als Daten- das andere als Backup) ein, jeweils 2 Controller, redundandte Pfade und Switche, verbunden über redudandte QLogic Switche. Die Host sind über einen QLogic FC-HBA angebunden, ebenfalls über redundante Pfade. Ich habe die physischen Server als Hyper-Cluster verbunden. Das funktioniert auch soweit.

    Jetzt würde ich gerne in einen 2. Schritt die beide Fileserver clustern. Ich hatte mir das so vorgestellt, dass den beiden FS jeweils eine Partition aus den Daten-RAID als Pass-Through Disk eingebunden bekommen und diese als Shared-Storage nutzen. Habe auf beide das Feature Failover-Cluster installiert und eben die Partiotion eingebunden. Wenn ich jetzt den Cluster-Konfig Test laufen lassen, wird mir gemeldet, das kein Shared-Storage Speicher verfügbar ist.

    Jetzt habe ich gelesen, das die FC-HBA's in Hyper-V nicht durchgeschliffen werden, sondern die Anbindung über NIC's erfolgen soll. Allerdings ist basiert das SAN auf FC und nicht auf iSCSI. Also entfällt die Möglichkeit.Das RAID ist komplett Microsoft zertifiziert, FC-HBA usw. auch. Muss ja auch funktionieren, da es ja auf Host Ebene funktioniert.

    Wie bringe ich nun die VM's dazu, die RAID-Partition als möglichen Shared Storage zu erkennen? Wie muss ich sie einbinden? Die Partition ist knapp 27 TB groß, aber ich denke das ist nicht so entscheident.

    Ich habe auch gelesen, das man mehre VHD Files auf Clusterstorage packen kann und diese dann mitwandern. Aber das erscheint wenig sinnvoll, zum einen da die Partition 27 TB groß ist und entsprechend viele VHD's dann existieren und zu anderen, müssen die beiden FS ja dann auch gleichzeitig darauf zugreifen können.

    Wäre schön, wenn ihr mir helfen könnt bzw. mal von euch erzählen könntet, wie ihr (virtuelle) FS geclustert, bzw. hochverfügbar gemacht habt.

     

    Ich danke euch im Voraus.

    Viele Grüße

    Stephan

     

    Freitag, 22. Oktober 2010 12:03
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden
    kurze Anmerkung noch: Die Partionen werden von den virtuellen FS normal als Datenträger auch erkannt. Sind an den Hosts auch offline geschaltet. Das ist also nicht das Problem.
    Freitag, 22. Oktober 2010 12:04
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Stephan

    Das was Du vorhast klappt so nicht. Du hast final 2 Möglichkeiten ...

    1. Du baust aus den 3 Hyper-V Hosts und dem Storage System einen Host-Cluster und läßt darin eine VM als "Single"-Fileserver laufen
    2. Du sorgst dafür, dass auf den VMs welche die virtuellen Cluster Hosts sein sollen (also ein Guest-Cluster) das Storage als Shares Storage auftaucht - und das geht nur im iSCSI

     

     

     

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Samstag, 23. Oktober 2010 16:05
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

     

    vielen Dank für die Antwort. Das habe ich bei meinen Recherchen bis in die Nacht hinein auch noch herausgefunden gehabt. Leider.:-(

    Ich habe auch mit dem iSCSI Target aus dem StorageServer herum experimientiert. Das wäre sicherlich ein gangbarer Weg, blos wir haben auf Ethernet-Basis nur 1 GB/s abzüglich Overhead für TCP etc. ist das im Vergleich zu den 4 GB/s zu wenig, bei den erwarteten größeren Datenmengen.

    Ein Single-Fileserver ist das, was wir am wenigsten wollen. Würde ja bedeuten, das jedes Update-Einspielen etc. mit Downtime verbunden ist. Es geht ja leider auch nicht, einen Clusterdatenträger abwechselnd an mehrere VM's zu binden. Dann hätte man wenn man FS1 wartet, den Datenträger an FS2 hängen können. Das geht nicht, weil der 2. Server die Festplatte nur mit Schreibschutz erkennt. Vermute mal, das hat wieder was mit den NTFS Besitz-Rechten zu tun?!

    Ich habe noch daran gedacht die Hosts zusätzlich zu den Hyper-V als Cluster laufen zu lassen. Aber doch verworfen, da sie wirklich nur die VM's hosten sollen und die User da nicht rankommen sollen.

    Insofern werde ich vorerst bei der bisherigen Lösung bleiben bzw. etwas erweitern. Das Daten-RAID in 2 Bereiche aufteilen, als Cluster-Disk initialisieren und dann jedem FS jeweils einen Bereich zuordnen, wobei über DFS synchronisert wird. 

    Und mittlerfristig müssen wir dann sehen ob wir 2 physische Fileserver kaufen, oder einfach nur ein weitere RAID's oder (was mit am besten gefällt) Hyper-V unterstützt SharedVolumes auf FC-Basis, was ja im professionellen Bereich doch eher weit verbreitet ist. Ist denn in Bezug auf letzteres etwas abzusehen? Vielleicht mit einem ServicePack?

     

    Viele Grüße

    Stephan

     

    Samstag, 23. Oktober 2010 17:56
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe auch mit dem iSCSI Target aus dem StorageServer herum experimientiert. Das wäre sicherlich ein gangbarer Weg, blos wir haben auf Ethernet-Basis nur 1 GB/s abzüglich Overhead für TCP etc. ist das im Vergleich zu den 4 GB/s zu wenig, bei den erwarteten größeren Datenmengen.

    Worauf basiert die Annahme, dass 1GB Full-Duplex nicht reichen könnte?
    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Sonntag, 24. Oktober 2010 09:14
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Ein Single-Fileserver ist das, was wir am wenigsten wollen. Würde ja bedeuten, das jedes Update-Einspielen etc. mit Downtime verbunden ist. Es geht ja leider auch nicht, einen Clusterdatenträger abwechselnd an mehrere VM's zu binden. Dann hätte man wenn man FS1 wartet, den Datenträger an FS2 hängen können. Das geht nicht, weil der 2. Server die Festplatte nur mit Schreibschutz erkennt. Vermute mal, das hat wieder was mit den NTFS Besitz-Rechten zu tun?!


    Wo wird was angehängt? Eine VHD an zwei VMs ... damit bekommst Du keinen Cluster gebaut.
    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Sonntag, 24. Oktober 2010 20:58
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe noch daran gedacht die Hosts zusätzlich zu den Hyper-V als Cluster laufen zu lassen. Aber doch verworfen, da sie wirklich nur die VM's hosten sollen und die User da nicht rankommen sollen.

    Insofern werde ich vorerst bei der bisherigen Lösung bleiben bzw. etwas erweitern. Das Daten-RAID in 2 Bereiche aufteilen, als Cluster-Disk initialisieren und dann jedem FS jeweils einen Bereich zuordnen, wobei über DFS synchronisert wird. 

    Und mittlerfristig müssen wir dann sehen ob wir 2 physische Fileserver kaufen, oder einfach nur ein weitere RAID's oder (was mit am besten gefällt) Hyper-V unterstützt SharedVolumes auf FC-Basis, was ja im professionellen Bereich doch eher weit verbreitet ist. Ist denn in Bezug auf letzteres etwas abzusehen? Vielleicht mit einem ServicePack?

    Ein Mischbetrieb aus Fileserver Cluster und Hyper-V Host ist nicht sonderlich sinnvoll. Wir empfehlen sowas absolut nicht!

    Cluster Shared Volumes werden von Windows Failover Clustering für iSCSI, FibreChannel und DAS unterstützt und momentan ausschließlich für Hyper-V und nichts anders. Einen Fileserver-Cluster baut man auf wie bisher ...

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Sonntag, 24. Oktober 2010 21:01
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe auch mit dem iSCSI Target aus dem StorageServer herum experimientiert. Das wäre sicherlich ein gangbarer Weg, blos wir haben auf Ethernet-Basis nur 1 GB/s abzüglich Overhead für TCP etc. ist das im Vergleich zu den 4 GB/s zu wenig, bei den erwarteten größeren Datenmengen.

    Worauf basiert die Annahme, dass 1GB Full-Duplex nicht reichen könnte?
    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Na ja zum einen auf Erfahrungswerte mit unserem iSCSI RAID's in Verbindung mit großen Datenmengen. Desweiteren habe ich das Freitag Abend noch getestet mit den ISCSI Target aus dem Storage Server 2008 R2. Da blieb nicht viel übrig. Außerdem kann ich doch die Zahlen im Vergleich zu FC vergleichen:

     

    FC 4 Gbit/s nur Storage     vs.    iSCSI 1 Gbit/s TCP-Overhead+Storage in einer schmaleren Leitung..

    habe in nem anderen technet Forum gelesen (finde gerade den Link nicht) das ca. 20 % Overhead abgezogen werden sollten.. verbleiben 0,8 GBit/s bei iSCSI vs. 4 GBit/s FC...

    Montag, 25. Oktober 2010 13:15
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ein Single-Fileserver ist das, was wir am wenigsten wollen. Würde ja bedeuten, das jedes Update-Einspielen etc. mit Downtime verbunden ist. Es geht ja leider auch nicht, einen Clusterdatenträger abwechselnd an mehrere VM's zu binden. Dann hätte man wenn man FS1 wartet, den Datenträger an FS2 hängen können. Das geht nicht, weil der 2. Server die Festplatte nur mit Schreibschutz erkennt. Vermute mal, das hat wieder was mit den NTFS Besitz-Rechten zu tun?!


    Wo wird was angehängt? Eine VHD an zwei VMs ... damit bekommst Du keinen Cluster gebaut.
    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    ja eben.. darum habe ich diese Lösung ja auch wieder verworfen....

    ich habe getest eine Cluster-Disk abwechseln mal an den einen mal an den anderen FS zu hängen... das geht, wie gesagt auch net (wenn das ginge, wäre der Single-FS vllt. doch noch ne Option gewesen)

    Montag, 25. Oktober 2010 13:17
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ich habe noch daran gedacht die Hosts zusätzlich zu den Hyper-V als Cluster laufen zu lassen. Aber doch verworfen, da sie wirklich nur die VM's hosten sollen und die User da nicht rankommen sollen.

    Insofern werde ich vorerst bei der bisherigen Lösung bleiben bzw. etwas erweitern. Das Daten-RAID in 2 Bereiche aufteilen, als Cluster-Disk initialisieren und dann jedem FS jeweils einen Bereich zuordnen, wobei über DFS synchronisert wird. 

    Und mittlerfristig müssen wir dann sehen ob wir 2 physische Fileserver kaufen, oder einfach nur ein weitere RAID's oder (was mit am besten gefällt) Hyper-V unterstützt SharedVolumes auf FC-Basis, was ja im professionellen Bereich doch eher weit verbreitet ist. Ist denn in Bezug auf letzteres etwas abzusehen? Vielleicht mit einem ServicePack?

    Ein Mischbetrieb aus Fileserver Cluster und Hyper-V Host ist nicht sonderlich sinnvoll. Wir empfehlen sowas absolut nicht!

    Cluster Shared Volumes werden von Windows Failover Clustering für iSCSI, FibreChannel und DAS unterstützt und momentan ausschließlich für Hyper-V und nichts anders. Einen Fileserver-Cluster baut man auf wie bisher ...

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Ja, dieser Mischbetrieb schien mir auch nicht sonderlich sinnvoll...  Mir war schon klar, das man die CSV nicht zur Dateiablage nimmt, hätte dann weitere LUN's gemacht extra für das FS-Clusterin. Aber wie gesagt, auch diese Lösung verworfen.

    Und ansonsten muss ich wohl zustimmen, virtualisierte FS-Cluster scheinen auf FC-Basis noch nicht möglich zu sein. Wie ich schon geschrieben habe, habe ich das RAID geteilt und jedem FS seine LUN gegeben und darüber die DFS-Sync. gepackt. Mittlefristig werden wir dann 2 Server kaufen und dann old school einen FS-Cluster einrichten.

    Montag, 25. Oktober 2010 13:21
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Stephan

    In der Theorie sind die Annahmen 100% korrekt, die Praxis hat aber sehr oft gezeigt das 1GB iSCSI (sauber mit Jumbo Frames, Offloading, Multipathing - dann sind es 2GB, ....) für sehr viele Szeanrien mehr als ausreichend ist. Im Rahmen meiner Arbeit stelle ich oft fest, dass ein sehr großer Wert auf eine schnelle Connectivity gelegt wird (was zweifelsohne wichtig ist) - und das Storage System dabei gerne vergessen wird. Sprich um einen 4GB FC voll auszulasten brauchst Du mehr als 2 Platten :-)

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Montag, 25. Oktober 2010 15:09
    |
    Moderator
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Bernd,

     

    danke für die Hinweise. Interessant deine Praxis-Erfahrung zu lesen.

    Die beiden RAID-Systeme, die ich habe, haben jeweils 24 x 2 TB Platten... jetzt verstehst du sicherlich warum ich da nicht auf 2 GBit/s runtergehen möchte (kann) und das FC dem iSCSI bei meinen Gegenbenheiten erstmal den Vorzug gebe.

     

    Viele Grüße

    Stephan

    Montag, 25. Oktober 2010 16:19
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Letztlich haben wir bei einem Kunden 4 1GB iSCSI Adapter mit MPIO gebündelt und kamen dabei auf über 200MB/s schreibend ...

     

    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.
    Mittwoch, 27. Oktober 2010 07:34
    |
    Moderator