Höhere Verfügbarkeit mit einem 2. SQL-Server 2008 R2?

[martins 11]

Hallo Gemeinde,

 

wir haben einen SQL-Server Standard 2008 R2 (auf W2K8R2 Std.) mit 3 Datenbanken (Sage, Buchhaltung, ERP) / Instanzen. Der SQL-Server ist auf HyperV (W2K8R2) virtualisiert.

 

Nun habe ich eine zweite Lizenz von SQL-Server Standard 2008 R2 entdeckt, die ich ggf. nutzen möchte, mit dem Ziel eine höhere Verfügbarkeit des „primären“ SQL-Servers zu erreichen. Derzeit wird der SQL-Server täglich mit Backup Exec 2010 gesichert. Die vom SQL Server-Agent gesicherten Transaktionsprotokolle und die Datenbanken werden täglich auf einen anderen Server kopiert, einmal wöchentlich wird der virtualisierte SQL-Server automatisch exportiert. Zusätzlich läuft jeden Abend ein Backup mit Backup Exec.

 

Im Disaster-Fall, also dass der virtualisierte SQL-Server nicht mehr zur Verfügung stehen würde, würde ich z.B. die exportierte Maschine auf einem anderen HyperV-Host starten und die gesicherten Datenbanken + Transaktionsprotokolle wiederherstellen.

 

Da ich aber eine zweite SQL-Server Lizenz besitze, möchte ich von euch wissen, ob ich diese irgendwie nutzbringend einsetzen kann, um die Ausfallzeit zu minimieren. Ergänzend muss ich sagen, dass ich von SQL nur rudimentäre Kenntnisse besitze. :rolleyes:

 

Vielen Dank für das Lesen, Verstehen und Supporten. :wink2:

 

Gruß

Martin

[Dukel 454]

Es gibt diverse Mechanismen (Cluster; Logshipping; Mirror; Replikation) mit allen ihren entsprechenden Vor- und Nachteilen.

Ohne Know-How würde ich das aber nicht einfach so implementieren und ggf. muss das auch von den Anwendungen unterstützt werden (Mirroring so viel ich weiß) oder benötigt extra Hard und Software (Cluster -> Shared Storage).

[martins 11]

Hallo Dukel,

 

es wäre ein zweiter HyperV-Host vorhanden, auf dem dann noch eine Maschine mit SQL installiert werden könnte. Ich möchte allerdings keine großen Klimmzüge machen (Cluster, Shared Storage) und dachte, dass es da eine "Quickie-Variante" gäbe, um einfach eine etwas höhere Verfügbarkeit zu haben.

 

Wenn ich einen möglichen Ausfall der SQL Datenbanken kurz halten möchte (durch Ausfall des Servers selbst oder des HyperV-Hosts), was könnte ich in der Umgebung optimieren?

 

(...) Derzeit wird der SQL-Server täglich mit Backup Exec 2010 gesichert. Die vom SQL Server-Agent gesicherten Transaktionsprotokolle und die Datenbanken werden täglich auf einen anderen Server kopiert, einmal wöchentlich wird der virtualisierte SQL-Server automatisch exportiert. (...)

 

Im Disaster-Fall, also dass der virtualisierte SQL-Server nicht mehr zur Verfügung stehen würde, würde ich z.B. die exportierte Maschine auf einem anderen HyperV-Host starten und die gesicherten Datenbanken + Transaktionsprotokolle wiederherstellen (...)

 

 

Gruß

martins

[Dukel 454]

Sind die beiden Hyper-V Hosts nicht in einem Cluster?

[martins 11]

Nein, jeder HyperV-Host beherbergt 5 unterschiedliche virtuelle Maschinen. Beide Hosts wären aber in der Lage, im Notfall die 5 Maschinen des anderen Hosts temporär aufzunehmen. Ein zusätzlicher dritter Host soll in den nächsten Wochen angeschafft werden und in einem anderen Brandabschnitt stehen. Als Standby oder ggf. auch um einige Maschinen zu hosten.

 

Warum fragst du?

[Dukel 454]

Ich würde erst mal die Hyper-V Hosts zu einem Cluster machen, da hast du Live Migration und HA ohne irgendwas am SQL zu machen.

[martins 11]

Hmmm... ich wollte einfach nur eine kleinere Ausfallzeit mit der bereits bestehenden Hard- / Software erreichen. Über einen Hostcluster, bzw. die notwendige Hardware wollte ich eigentlich drumrum kommen! ;)

[Dukel 454]

Du weißt, wenn ein Hyper-V Host ausfällt stehen 5 VM's. In einer Produktiven Umgebung würde ich nie nur einen Virtualisierungshost hinstellen, immer min. 2 Hosts.

[martins 11]

Ich weiß dass das nicht optimal ist. :shock:

 

Was benötige ich für die HA-Lösung, außer 2 SANs?

 

 

Edit: Der zweite HyperV-Host könnte (zumindest kurzfristig) die 5 Maschinen zusätzlich aufnehmen.

bearbeitet 21. Juli 2012 von martins
Ergänzung

[Dukel 454]

Wir haben teilweise ESX Cluster laufen mit nur einer Storage.

 

Du brauchst einfach nur ne Shared Storage, am besten genug Netzwerkkarten und ein bisschen Planung.

[martins 11]

Und wenn mir das Storage abraucht? Dann stehen nicht nur 5 VMs sondern 10! :(

[Dukel 454]

Klar kann man auch die Storage redundant auslegen. Macht das ganze auch komplexer und teurer.

 

Vernünftige Storage hat sowieso alle Komponenten doppelt. 2 Controller, gerade Anzahl an Netzteilen, mehrere Interfaces, ...

[martins 11]

60 User

2x VM RDS (= 150 GB),

1x VM SQL (= 200 GB)

1x VM Exchange (= 200 GB)

6x VM sonstiges Gedöhns [kaum ausgelastete Server (= 1 TB)]

 

und noch 6 physische Systeme (ISDN, Fileserver, 2x DC, etc.) die unabhängig vom Storage wären. Das Storage für die VMs (NAS?) würde ich mit ~ 3 TB dimensionieren.

 

Reicht dir das für eine Empfehlung à la Pi mal Daumen? ;)

[bla!zilla 10]

es wäre ein zweiter HyperV-Host vorhanden, auf dem dann noch eine Maschine mit SQL installiert werden könnte. Ich möchte allerdings keine großen Klimmzüge machen (Cluster, Shared Storage) und dachte, dass es da eine "Quickie-Variante" gäbe, um einfach eine etwas höhere Verfügbarkeit zu haben.

 

HA und Quickie-Lösungen sind keine sinnvolle Kombination. Mangels zentralem Storage und SQL Enterprise Version fällt ein Cluster eh bei dir raus. Database Mirroring würde gehen, sofern deine Anwendungen mitspielen. Nutzen diese den SQL Native Client, sehe ich eigentlich kein Problem (außer evtl. das Knowhow)

 

Das Storage für die VMs (NAS?) würde ich mit ~ 3 TB dimensionieren.

 

Nee, die Infos reichen nicht für ein Sizing. Wie viele IOPS brauchst du? Welches Verfügbarkeitslevel strebst du an? Kapazitätsangaben alleine sind nicht brauchbar.

 

Du brauchst einfach nur ne Shared Storage, am besten genug Netzwerkkarten und ein bisschen Planung.

 

Ach wenn es nur immer so einfach wäre... Leider kenne ich genug Installationen, an die so herangegangen wurde. Etwas mehr Planung darf es schon sein...

[Dukel 454]

Klar war das etwas lapidar ausgedrückt. Man darf auch nicht die billigste Storage nutzen.

 

 

Reicht bei SQL Cluster nicht die Standardversion? Zwar nur bis 2 Knoten, aber gehen sollte es.