SQL-Clustering auf Hyper-V – ist ein Cluster innerhalb eines Clusters ein Vorteil?

Question

Dies ist eine Neuauflage einesFrageIch habe vor einiger Zeit gefragt – nachdem ein Berater hereinkam und anderen Teams in der Abteilung Ideen vorschlug, wurde das ganze Thema erneut aufgeworfen, daher suche ich nach detaillierteren Antworten.

Wir beabsichtigen, einen SQL-Cluster mit mehreren Instanzen auf mehreren physischen Blades einzurichten, auf denen auf jeder SQL-Instanz verschiedene Systeme ausgeführt werden. Im Normalbetrieb wird auf jedem VM-Host eine virtuelle SQL-Instanz ausgeführt. Im Normalbetrieb wird jeder VM-Host wiederum auf einem dedizierten zugrunde liegenden Blade ausgeführt. Das Setup sollte uns viel Flexibilität für die Wartung jeder einzelnen VM oder jedes zugrunde liegenden Blades bieten, wobei alle SQL-Instanzen bei Bedarf ein Failover durchführen können.

Mein ursprünglicher Plan war, Folgendes zu tun:

1. Installieren Sie 2008 R2 auf jedem Blade
2. Fügen Sie jedem Blade Hyper V hinzu
3. Installieren Sie eine 2008 R2 VM auf jedem Blade
4. Erstellen Sie innerhalb der VMs einen Failovercluster und installieren Sie dann SQL Server-Clustering.

Der Berater hat vorgeschlagen, dass wir stattdessen Folgendes tun:

1. Installieren Sie 2008 R2 auf jedem Blade
2. Fügen Sie jedem Blade Hyper V hinzu
3. Installieren Sie eine 2008 R2 VM auf jedem Blade
4. Erstellen Sie auf den HOST-Rechnern einen Cluster, der alle VMs hostet.
5. Erstellen Sie innerhalb der VMs einen Failovercluster und installieren Sie dann SQL Server-Clustering.

Der große Unterschied besteht in der Hinzufügung von Schritt 4, bei dem wir auch alle Gast-VMs clustern. Das Argument ist, dass dies die Wartung weiter verbessert, da wir keinerlei Verbindungen zwischen dem SQL-Cluster und der physischen Hardware haben. Theoretisch können wir die Gast-VMs live zwischen den Hosts migrieren, ohne den SQL-Cluster überhaupt zu beeinträchtigen, sodass wir für die routinemäßige Wartung physischer Blades den SQL-Cluster ohne Unterbrechung und ohne Failover verschieben können.

Das klingt nach einer netten Idee, aber ich habe im Internet noch nichts gefunden, wo Leute sagen, dass sie das gemacht haben und es funktioniert. Kann ich die Live-Migrationen der Gäste tatsächlich durchführen, ohne dass der darin gehostete SQL-Cluster gestört wird?

Hat jemand Erfahrungen mit dieser Konfiguration, ob gut oder schlecht? Gibt es Vor- und Nachteile, die ich nicht bedacht habe?

Ich weiß, dass auch die Spiegelung eine sinnvolle Option ist, die in Betracht gezogen werden sollte. In diesem Fall bevorzugen wir die Clusterung, da sie jede Instanz vollständig abdeckt und wir über eine gute Anzahl von Datenbanken verfügen. Einige Datenbanken dienen dazu, Systeme von Drittanbietern zu belasten, die möglicherweise nicht einmal gut mit der Spiegelung funktionieren (und mein Verständnis von Clusterung ist, dass Failover für die Clients völlig transparent sind).

Danke.

Answer 1

Wenn diese Blades ausschließlich für die Ausführung von SQL Server vorgesehen sind, warum beschäftigen Sie sich dann überhaupt mit der Virtualisierung?

Warum installieren Sie nicht einfach Windows Server und SQL Server auf jedem dieser Server und richten Ihren Cluster entsprechend ein, ohne den zusätzlichen Virtualisierungsaufwand?

Answer 2

Klingt kompliziert.

Ich müsste die „Komplexität“ Ihrer Lösung gegen die Zuverlässigkeit und relative Einfachheit einer standardmäßigen physischen Cluster-SQL-Serverimplementierung abwägen.

Sind ALLE Datenbanken unternehmenskritisch? Meiner Erfahrung nach normalerweise nicht. Daher hoste ich die wichtigsten Datenbanken eher auf Servern, die mit voller Ausfallsicherheit eingerichtet sind, und den Rest (normalerweise ein großer Teil) auf einfachen SQL-Servern.

Dadurch können Sie sich darauf konzentrieren, die wichtigsten Systeme am Laufen zu halten, und müssen nicht versuchen, „alle Bälle gleichzeitig in der Luft zu halten“.

Alle Server müssen regelmäßig gewartet werden. Angesichts der Regelmäßigkeit, Dringlichkeit und Wichtigkeit von Sicherheitspatches haben wir uns von dem Versuch entfernt, eine theoretische Verfügbarkeit von 9 ...

Answer 3

Von den aufgelisteten Optionen würde ich Nr. 2 wählen, aber ich würde SQL nicht clustern (Schritt 5), da dies eine zusätzliche Komplexitätsebene hinzufügt, von der Sie nicht viel profitieren. Das Hyper-V-Clustering ermöglicht es Ihnen bereits, diese VM auf beiden Hosts auszuführen, sodass Sie gegen Hardwarefehler abgesichert sind.

Ich gehe davon aus, dass Sie VHDs mit fester Größe für die SQL-Protokoll- und Datenbank-Volumes verwenden möchten.

Ich verstehe die Kommentare anderer, die Hyper-V ganz überspringen und nur die beiden Blades als normalen SQL-Cluster verwenden möchten, vollkommen – das wäre sicherlich der traditionelle Ansatz. Die Flexibilitätsvorteile der Virtualisierung von Workloads sind jedoch im Hinblick auf Wartung, Upgrades und Hardwarefehler enorm. Die Portabilität von VMs ist sehr ansprechend.

Beachten Sie jedoch, dass der Wert dieser Lösung auch von Ihrer Umgebung abhängt. Wenn Sie keine anderen Hyper-V-Server haben und Ihre Mitarbeiter nicht viel Erfahrung mit Hyper-V haben, ist die Virtualisierung einer Ihrer kritischsten Workloads möglicherweise keine gute Idee. Wenn Sie jedoch wie viele IT-Shops mit der Virtualisierung weniger kritischer Server begonnen haben, einige Hosts aufgebaut haben und über die Fähigkeiten und Verfahren verfügen, um Hyper-V zuverlässig auszuführen, ist es durchaus sinnvoll, diesen Fokus auf kritischere Workloads auszuweiten. Persönlich würde ich Clustering lieber auf Hostebene als auf SQL-Ebene verwalten, und ich denke, wir werden sehen, dass dies immer häufiger gemacht wird, auch wenn es noch nicht so üblich ist.

Und abschließend noch Ihre Fragen zum Ausführen von SQL auf Hyper-V: Ja, die Livemigration funktioniert mit SQL problemlos, ohne dass es auffällt – UND – die Spiegelung von SQL-Datenbanken ist großartig, wird aber nicht überall unterstützt und ist daher nicht für jede Situation geeignet.

Answer 4

Ich denke, Ihr Berater hat recht. Ich habe genau die gleiche Idee wie er, die ich in meiner aktuellen Umgebung umsetzen möchte. 2 physische Hardwareteile, auf jedem davon läuft Hyper-V mit 2x W2k8-Installationen.

1. Installieren Sie 2x VMs auf dem 1. physischen Host.
2. Installieren Sie SQL auf VM1 und spiegeln Sie es oder erstellen Sie ein Cluster zu/mit VM2 mit einer Fehlertoleranzeinrichtung auf Betriebssystemebene für ein Failover zur replizierten Umgebung.
3. Installieren Sie W2k8 auf dem zweiten physischen Server und dem Failovercluster Hyper-V.

Dadurch erhalten Sie ein vollständiges Failovers-Clustering-Niveau und vollständige H/A in Ihrer SQL-Umgebung.

Oder ist meine Idee vielleicht dumm?