1
SQL Cluster an zwei Standorten und mögliche Virtualisierung
Hallo,
ich muss ein SQL-Cluster entwerfen und hab da so meine Probleme.
Ausgangslage:
-zwei Standorte
-W2K3 Server an beiden Standorten
-Glasfaserverbindung
-Einsatz eines Diskarrays / SAN
-möglicherweise Virtualisierung
Also, die Aufgabe ist, einen 2-Knoten-SQL mit je einem Server an zwei Standorten zu erstellen, die per Glasfaser verbungen sind.
Zudem sollen alle Daten für den SQL an einem der beiden Standorte in Form eines Diskarrays als Raid 5 oder 6 oder als SAN realisiert werden. D.h. doppelte Ausfallsicherheit gewünscht.
Der Cluster soll Aktiv/passiv eingerichtet werden, sodaß der User nicht wählen muss, welchen SQL Server er nehmen soll.
Ich habe bisher weder einen SQL noch einen Cluster aufgesetzt. Zum einen wäre ein Link zu einem guten HowTo toll, zum anderen ist die Frage, wie schnell reagiert denn so ein auf passiv gesetzter SQL Server? In welchen Intervallen wird der aktualisiert? Es soll so sein, dass es idealerweise KEINE Zeitverzögerung gibt, wenn der Haupt-SQL ausfällt.
Zudem ist die Frage, ob das überhaupt mit einem externen Diskarray oder SAN funtioniert....Ich hab zwar gelesen, dass man die Daten des SQL auslagern könnte, aber stimmt das?
Und ich hab gesehen, dass einige das als virtuelle Lösung haben.... nun wird es für mich leider total verwirrend, wo ist der Vorteil das auch noch virtuell zu machen? Die Server müssen doch dann enorm Power haben, um auch noch die Virtualisierung zu stemmen...oder?
Was für einen Vorteil hätte das?
Das Ziel meines Systems soll Hochverfügbarkeit der auf SQL-Basis fungierenden Software sein. Und idealerweise, um einen SPOF an einem Standort zu vermeiden, eben eine Lösung, wo der User 1) möglichst gar nichts von einem Ausfall bemerkt und 2) die Performance sehr gut ist.
Und die User sollen ebenfalls im Falle eines Ausfalls von einem der beiden Server auf alle Daten Zugriff haben. Also beide müssten dann als DC fungieren, wie sollte man das am besten einrichten/ planen?
Danke!
Viele Grüße
Django
ich muss ein SQL-Cluster entwerfen und hab da so meine Probleme.
Ausgangslage:
-zwei Standorte
-W2K3 Server an beiden Standorten
-Glasfaserverbindung
-Einsatz eines Diskarrays / SAN
-möglicherweise Virtualisierung
Also, die Aufgabe ist, einen 2-Knoten-SQL mit je einem Server an zwei Standorten zu erstellen, die per Glasfaser verbungen sind.
Zudem sollen alle Daten für den SQL an einem der beiden Standorte in Form eines Diskarrays als Raid 5 oder 6 oder als SAN realisiert werden. D.h. doppelte Ausfallsicherheit gewünscht.
Der Cluster soll Aktiv/passiv eingerichtet werden, sodaß der User nicht wählen muss, welchen SQL Server er nehmen soll.
Ich habe bisher weder einen SQL noch einen Cluster aufgesetzt. Zum einen wäre ein Link zu einem guten HowTo toll, zum anderen ist die Frage, wie schnell reagiert denn so ein auf passiv gesetzter SQL Server? In welchen Intervallen wird der aktualisiert? Es soll so sein, dass es idealerweise KEINE Zeitverzögerung gibt, wenn der Haupt-SQL ausfällt.
Zudem ist die Frage, ob das überhaupt mit einem externen Diskarray oder SAN funtioniert....Ich hab zwar gelesen, dass man die Daten des SQL auslagern könnte, aber stimmt das?
Und ich hab gesehen, dass einige das als virtuelle Lösung haben.... nun wird es für mich leider total verwirrend, wo ist der Vorteil das auch noch virtuell zu machen? Die Server müssen doch dann enorm Power haben, um auch noch die Virtualisierung zu stemmen...oder?
Was für einen Vorteil hätte das?
Das Ziel meines Systems soll Hochverfügbarkeit der auf SQL-Basis fungierenden Software sein. Und idealerweise, um einen SPOF an einem Standort zu vermeiden, eben eine Lösung, wo der User 1) möglichst gar nichts von einem Ausfall bemerkt und 2) die Performance sehr gut ist.
Und die User sollen ebenfalls im Falle eines Ausfalls von einem der beiden Server auf alle Daten Zugriff haben. Also beide müssten dann als DC fungieren, wie sollte man das am besten einrichten/ planen?
Danke!
Viele Grüße
Django
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 126395
Url: https://administrator.de/contentid/126395
Ausgedruckt am: 23.11.2024 um 21:11 Uhr
1 Kommentar
Moin,
darf ich dir nen ernstgemeinten Tipp geben? Lasse das von nem Systemhaus machen! Du hast bisher noch nie nen SQL als "Standalone" aufgesetzt - und noch nie nen Cluster... Das ist als wenn mir jemand sagt "Ich bin noch nie Motorrad gefahren" und sich auf die gute alte Doppel-Turbo-Hayabusa setzt (400 PS ;) )
Grade der Bereich Datenbanken bietet in der EDV die besten Chancen sich das Genick zu brechen - und die Verbindung "Anfänger, Cluster, Datenbank" bietet praktisch schon eine Garantie das man sich Chips, Popcorn & ne Cola holen kann. Das ding wird nämlich in schönster Manier absemmeln...
Generell: Bei einem Datenbank-System gibts eigendlich nur 2 Optionen: Entweder du hast nen Cluster der alle Nodes immer sofort aktuell hält - oder du kannst dir den Cluster sofort schenken. Nehmen wir die übliche Lager-Datenbank -> dein Master-Node aktuallisiert die Client-Nodes alle 5 Minuten. Der Master semmelt ab und die Clients arbeiten auf den Client-Node weiter. Leider ist der Master genau 4:59 Min nach dem letzten Update runtergegangen. Kollege 1 hat also grade einen Waren-Eingang eingetragen - und nu geht der Master in Urlaub. Kollege 2 weiss also nichts von dem Wareneingang - und lässt fröhlich munter (am besten vom automatischen System) auf das selbe Lagerfach etwas neues einlagern... Nen Haufen Scherben im Lager ist die Folge...
Und einen Cluster über die Standort-Grenzen hinweg - um einen SPOF (tolles Fachwort ;) ) zu verhindern? Viel Spass. Denn zum einen muss die Leitung dafür schon schnell genug sein (MySQL empfiehlt für den HA-Betrieb min. 100 MBit). Dann brauchst du ne Ersatzleitung - weil: Was machst du wenn die Leitung wegfällt? Jetzt sind plötzlich beide Server "Master" - und die Kollegen ändern fröhlich auf beiden Datenbank-Systemen die Daten. Kollege a trägt am Standort 1 ein das die Ware aus Fach X ins Fach Y geht - Kollege b trägt am Standort b ein das die Ware aus Fach X ins Fach Z geht. Jetzt kommt die Leitung wieder - und wo liegt die Ware jetzt? Welcher Server hat nun recht? Viel Spass bei der Inventur!
Also - bitte lasse das Leute mit der Erfahrung machen. Ein DB-Server ist was anderes als ein DC o.ä. Beim DC ist es egal wenn die Leitung nicht da ist -> ich lege nen User auf einen Server an und dann dauert es ggf. halt nen moment bis der sich auch am Standort 2 anmelden kann... Wenn die Internet-Leitung zu dem Zeitpunkt grad weg ist - pech... Und hier legt auch normal NUR der Admin den User an - d.h. er weiss das er den nich auf der zweiten Seite auch anlegen darf (ohne I-Net-Leitung kommt der ja auch nich aufs System um das dort zu machen ;) ). Selbst wenn ich nen User deaktivieren müsste weil der fristlos gekündigt wurde - kein Thema. Im Zweifel muss man eben am anderen Standort anrufen und sagen das die Person X ab sofort an keinen Rechner mehr darf! Auch hier gilt dass das Deaktivieren eines Users ja normal nur von 1 Person gemacht wird - und somit ist das kein Problem. DU sprichst aber von einer Datenbank-Anwendung in der ggf. einige 100 bis einige 1000 User gleichzeitig rumtoben. Hier kann man nich mehr sagen "Leute, ich ändere jetzt den Standort der Ware von X auf Y - also bitte kein anderer mehr ändern!".
Solltest du es doch versuchen empfehle ich dir das ganze mal mit MySQL (ist recht gut dokumentiert) zu probieren... Ist nämlich wirklich nen intressantes Gebiet - aber für den Produktiv-Einsatz solltest du dir dann nochmal einige Monate Zeit nehmen...
darf ich dir nen ernstgemeinten Tipp geben? Lasse das von nem Systemhaus machen! Du hast bisher noch nie nen SQL als "Standalone" aufgesetzt - und noch nie nen Cluster... Das ist als wenn mir jemand sagt "Ich bin noch nie Motorrad gefahren" und sich auf die gute alte Doppel-Turbo-Hayabusa setzt (400 PS ;) )
Grade der Bereich Datenbanken bietet in der EDV die besten Chancen sich das Genick zu brechen - und die Verbindung "Anfänger, Cluster, Datenbank" bietet praktisch schon eine Garantie das man sich Chips, Popcorn & ne Cola holen kann. Das ding wird nämlich in schönster Manier absemmeln...
Generell: Bei einem Datenbank-System gibts eigendlich nur 2 Optionen: Entweder du hast nen Cluster der alle Nodes immer sofort aktuell hält - oder du kannst dir den Cluster sofort schenken. Nehmen wir die übliche Lager-Datenbank -> dein Master-Node aktuallisiert die Client-Nodes alle 5 Minuten. Der Master semmelt ab und die Clients arbeiten auf den Client-Node weiter. Leider ist der Master genau 4:59 Min nach dem letzten Update runtergegangen. Kollege 1 hat also grade einen Waren-Eingang eingetragen - und nu geht der Master in Urlaub. Kollege 2 weiss also nichts von dem Wareneingang - und lässt fröhlich munter (am besten vom automatischen System) auf das selbe Lagerfach etwas neues einlagern... Nen Haufen Scherben im Lager ist die Folge...
Und einen Cluster über die Standort-Grenzen hinweg - um einen SPOF (tolles Fachwort ;) ) zu verhindern? Viel Spass. Denn zum einen muss die Leitung dafür schon schnell genug sein (MySQL empfiehlt für den HA-Betrieb min. 100 MBit). Dann brauchst du ne Ersatzleitung - weil: Was machst du wenn die Leitung wegfällt? Jetzt sind plötzlich beide Server "Master" - und die Kollegen ändern fröhlich auf beiden Datenbank-Systemen die Daten. Kollege a trägt am Standort 1 ein das die Ware aus Fach X ins Fach Y geht - Kollege b trägt am Standort b ein das die Ware aus Fach X ins Fach Z geht. Jetzt kommt die Leitung wieder - und wo liegt die Ware jetzt? Welcher Server hat nun recht? Viel Spass bei der Inventur!
Also - bitte lasse das Leute mit der Erfahrung machen. Ein DB-Server ist was anderes als ein DC o.ä. Beim DC ist es egal wenn die Leitung nicht da ist -> ich lege nen User auf einen Server an und dann dauert es ggf. halt nen moment bis der sich auch am Standort 2 anmelden kann... Wenn die Internet-Leitung zu dem Zeitpunkt grad weg ist - pech... Und hier legt auch normal NUR der Admin den User an - d.h. er weiss das er den nich auf der zweiten Seite auch anlegen darf (ohne I-Net-Leitung kommt der ja auch nich aufs System um das dort zu machen ;) ). Selbst wenn ich nen User deaktivieren müsste weil der fristlos gekündigt wurde - kein Thema. Im Zweifel muss man eben am anderen Standort anrufen und sagen das die Person X ab sofort an keinen Rechner mehr darf! Auch hier gilt dass das Deaktivieren eines Users ja normal nur von 1 Person gemacht wird - und somit ist das kein Problem. DU sprichst aber von einer Datenbank-Anwendung in der ggf. einige 100 bis einige 1000 User gleichzeitig rumtoben. Hier kann man nich mehr sagen "Leute, ich ändere jetzt den Standort der Ware von X auf Y - also bitte kein anderer mehr ändern!".
Solltest du es doch versuchen empfehle ich dir das ganze mal mit MySQL (ist recht gut dokumentiert) zu probieren... Ist nämlich wirklich nen intressantes Gebiet - aber für den Produktiv-Einsatz solltest du dir dann nochmal einige Monate Zeit nehmen...
