SQL Cluster auf ESX4.1

Hallo,

wir möchten einen SQL 2008 Aktive/Passive Cluster machen.

Jetzt ist die Überlegung das ganze auf VMware zu machen.

Hat damit jemand Erfahrung?

Ich bin mir nicht sicher, ob es das richtige ist den SQL Cluster auf VMware zu machen.

Danke

Wieso braucht ihr einen SQL Cluster wenn ihr ein ESX Cluster machen könnt?

Für den SQL Cluster benötigt Ihr iSCSI (oder ggf. FC Weiterleitung) im Gast für die Shared Storage.

Moin

wir möchten einen SQL 2008 Aktive/Passive Cluster machen.

Einfach nur so aus Spaß, oder was ist die konkrete Anforderung, der ihr euch stellen müsst?

Jetzt ist die Überlegung das ganze auf VMware zu machen.

Warum sollte man eine Cluster virtualisieren? Passt die Virtualisierung überhaupt zur gestellten Anforderung?

Ich bin mir nicht sicher, ob es das richtige ist den SQL Cluster auf VMware zu machen.

Also wenn du als Kundiger der Anforderungen das nicht beurteilen kannst, solltest du dir jemanden hinzuziehen, der weiß was er tut.

Gruß

Carsten

Hallo,

danke für Eure Antworten.

Wir möchten mit dem SQL Cluster einfach ausfallsicher sein.

Falls wir ein Problem mit dem Server haben, dass wir einfach keine Ausfallzeiten haben.

Wir haben eine VMware Farm mit mehreren ESX Servern.

Dukel: Wie meinst Du das für was braucht Ihr einen SQL Cluster, wenn Ihr einen ESX Cluster machen könnt.

Wie würdet Ihr das lösen?

Vielen Dank

Hallo,

Wird VMotion eingesetzt?

Kommt darauf an, was Du vorhast: Host Clustering (ESX) oder Guest Clustering (VMs) oder beides. Nicht immer ist das eine oder andere oder beides sinnvoll ;)

Hallo,

ja VMotion wird eingesetzt.

Ich würde einen SQL Cluster machen also das müßte dann ein Guest Cluster sein(VMs).

Was hälst Du von einem SQL Cluster auf VMware?

Danke für die Hilfe

Was wollt Ihr eigentlich erreichen ? Normalerweise konfiguriert man in einen DRS-Cluster auch VMWare HA. Für Standard-Anwendungen + Datensicherung sollte das genügen.

-Zahni

Wir möchten erreichen, dass wir mit unseren SQL Datenbanken keine Ausfallzeit bzw. nur eine geringe Ausfallzeit haben, falls mit dem SQL Server ein Problem wäre.

Ja ich könnte zum Beispiel auch mit Datarecovery die VM Maschine sichern und falls der Server ein Problem hätte, dann mittels Datarecovery zurückspielen. Das kann dann auch eine Weile dauern.

@stronzo75

Mehr Infos zur Umgebung wären nicht schlecht. Von welcher Anwendung wird der/die SQL Server verwendet? Wie groß ist die ESX Farm? Welche VMware Produkte sind im Einsatz? Welches SAN? Und wie angebunden? Welche Netzwerkinfrastruktur? Welche Backup Software?

Beschaäftige Dich mal mit VmWare HA

-Zahni

Wenn du einen SQL Server Cluster aufbaust und ein Knoten stürzt ab wird die DB auf dem anderen Knoten hochgefahren.

Wenn du ein ESX Cluster hast und ein Knoten stürzt ab wird die VM (incl. der DB) auf dem anderen Knoten hochgefahren.

Bei beidem hast du Ausfallzeiten, aber im prinzip machen sie das selbe.

Bei einem SQL Cluster (vorallem in VMWare) hast du sehr viel mehr komplexität und das ganze doppelt gemoppelt.

Ich würde das Szenario mit VMware HA erschlagen. (Hatte einer meiner Vorredner schon gesagt) Nahezu keine Ausfallzeit beim Failover.

Hallo,

danke für alle Eure Antworten.

Wenn ich aber bei der VM Maschine einen Blue Sreen habe oder irgend ein anderes Problem am Betriebsystem habe dann nützt mir doch HA auch nichts.

HA nützt mir doch erst wirklich etwas, wenn der ESX Server selber ein Problem hat. In dem link von substyle steht zwar, dass eine Maschine bei der ein Betriebsystemausfall erkannt wird neu gestartet wird aber ob dadurch dann wirklich der Server dann ohne Probleme funktioniert?

So wie ich es in Euren Kommentaren gelesen habe, würdet Ihr wenn Ihr einen SQL Cluster macht den nicht auf VMware machen weil der Aufwand zu groß ist.

Stimmt, ein BSOD würde nur der HA VM Monitor mitbekommen und dann zuerst die Primary VM Rebooten und danach dann die 2. VM.

Moin,

was ist denn das hier wieder für eine unglaubliche Diskussion? :confused:

Der TO weiß offensichtlich nicht so genau, was er überhaupt will und welches Ziel er denn genau erreichen will. Daraufhin werden ihm wild irgendwelche Techniken vorgeschlagen. Und am Ende heißt es noch, sei ja eh alles dasselbe.

Leute, Leute, Leute. Mir wird immer ganz anders bei sowas. Jede der genannten Techniken erfüllt ganz bestimmte Anforderungen und versagt bei anderen. Welche davon für den TO geeignet sein könnte, lässt sich anhand seiner Anfrage schlicht nicht sagen.

Stronzo, du musst zuerst festlegen, was genau die Anforderungen sind und vor welchen Schäden du dein System schützen willst. Bedenke dabei auch die Umgebung (Infrastruktur) und die Tatsache, dass ein SQL Server kein Selbstzweck ist, sondern von Applikationen verwendet wird, die auch ein Problem haben können.

Erst wenn du auf derartige Fragen ausreichende Antworten hast, kannst du beginnen, über konkrete Techniken nachzudenken. Vorher nicht.

Gruß, Nils