8
Einfache Redundanz für MS SQL Server 2008?
gibt es einen Weg eine Datenbank ohne das MS Failoverclustering redundant zu halten?
Hallo zusammen.
Ich beschäftige mich in den letzten Tagen mit der Erhöhung der Ausfallsicherheit in MS Netzen.
Ziel ist es unserem Domänencontroller (der auch gleichzeitig DB-Server für einen MS SQL 2008 Server ist) ein zweites Gerät zur Seite zu stellen dass bei Ausfall von Gerät 1 nahtlos die Funktionen übernimmt.
Die AD-Sachen sind mit einem zweiten DC ja eigentlich schon abgedeckt, so dass weiterhin eine funktionierende Domäne zur Verfügung stünde. Mein Problem ist der SQL Server.
Welche Möglichkeiten habe ich um dem SQL -Server eine Redundanz beizubringen? Ich habe viel Lektüre gewälzt (on- und offline) und kann irgendwie immernoch nicht sagen was jetzt die Technik der Wahl wäre.
Alles was ich mir vorstelle könnte ich z.B. mit einem Failovercluster erledigen - nur finde ich das ziemlich mit Atomraketen auf Spatzen geschossen.. zumal -wenn ich das richtig verstanden habe- wir zumindest für die Windows Server dann wohl Enterpriselizenzen kaufen müssten...
Gibt es noch eine Methode, um die Datenbanken des SQL-Servers redundant verfügbar zu halten? Es ist mir dabei auch erstmal egal ob ich einen Lastenausgleich, oder nur ein "Einspringen im Notfall" hätte, da es nicht so extrem viele Daten sind und der Server das auch momentan leistungsmäßig gut schafft.
Für die unterschiedlichen Installationsmodi muss ich fast immer das SQL neu installieren, das kostet ne Menge Zeit, darum versuche ich hier mit eurer Hilfe schonmal den ein oder anderen Holzweg auszuschliessen.
Nun nochmal meine Kernfrage:
Welche Möglichkeiten (ausser des Failoverclustering) habe ich, um mit 2x Serverhardware, 2 Windows 2008 Server Std und 2 SQL 2008 Server Std Lizenzen einen redundant verfügbaren DB-Server aufzubauen?
Grüße Manuel
EDIT sagt: Rechtschreibung!
Hallo zusammen.
Ich beschäftige mich in den letzten Tagen mit der Erhöhung der Ausfallsicherheit in MS Netzen.
Ziel ist es unserem Domänencontroller (der auch gleichzeitig DB-Server für einen MS SQL 2008 Server ist) ein zweites Gerät zur Seite zu stellen dass bei Ausfall von Gerät 1 nahtlos die Funktionen übernimmt.
Die AD-Sachen sind mit einem zweiten DC ja eigentlich schon abgedeckt, so dass weiterhin eine funktionierende Domäne zur Verfügung stünde. Mein Problem ist der SQL Server.
Welche Möglichkeiten habe ich um dem SQL -Server eine Redundanz beizubringen? Ich habe viel Lektüre gewälzt (on- und offline) und kann irgendwie immernoch nicht sagen was jetzt die Technik der Wahl wäre.
Alles was ich mir vorstelle könnte ich z.B. mit einem Failovercluster erledigen - nur finde ich das ziemlich mit Atomraketen auf Spatzen geschossen.. zumal -wenn ich das richtig verstanden habe- wir zumindest für die Windows Server dann wohl Enterpriselizenzen kaufen müssten...
Gibt es noch eine Methode, um die Datenbanken des SQL-Servers redundant verfügbar zu halten? Es ist mir dabei auch erstmal egal ob ich einen Lastenausgleich, oder nur ein "Einspringen im Notfall" hätte, da es nicht so extrem viele Daten sind und der Server das auch momentan leistungsmäßig gut schafft.
Für die unterschiedlichen Installationsmodi muss ich fast immer das SQL neu installieren, das kostet ne Menge Zeit, darum versuche ich hier mit eurer Hilfe schonmal den ein oder anderen Holzweg auszuschliessen.
Nun nochmal meine Kernfrage:
Welche Möglichkeiten (ausser des Failoverclustering) habe ich, um mit 2x Serverhardware, 2 Windows 2008 Server Std und 2 SQL 2008 Server Std Lizenzen einen redundant verfügbaren DB-Server aufzubauen?
Grüße Manuel
EDIT sagt: Rechtschreibung!
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: 171057
Url: https://administrator.de/contentid/171057
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
8 Kommentare
Neuester Kommentar
ja gibt es - z.B. mit Storagesystemem wo dann die DB drauf liegt, so kannst du dann, wenn der primäre SQL ausfällt einfach den zweiten starten der seine Datenbanken an der gleichen Stelle findet (wichtig ist auch, dass die SQL Protokolldatein auch so abgelegt werden (das ist mit das wichtigste neben den eigentlichen Datenbankdateien).
Eine solche Lösung kostet dich auch keine extra Lizenzen soweit ich weis - da der eine nicht als Produktivserver arbeitet.
Am leichtesten erreichst eine hohe Verfügbarkeit durch Virtuallisierung - das macht auch an sich den wenigsten stress
und dazu dann eine iSCSI oder FC Storagelösung - was die auch weitere Ausfallsicherheiten bietet.
Eine solche Lösung kostet dich auch keine extra Lizenzen soweit ich weis - da der eine nicht als Produktivserver arbeitet.
Am leichtesten erreichst eine hohe Verfügbarkeit durch Virtuallisierung - das macht auch an sich den wenigsten stress
und dazu dann eine iSCSI oder FC Storagelösung - was die auch weitere Ausfallsicherheiten bietet.
Datenbankspiegelung fällt mir dazu spontan zu ein - du spiegelst deine Datenbanken (quasi) in Echtzeit auf einen zweiten Server, der dann im Wiederherstellungsmodus läuft und explizit _keine_ zus. SQL-Lizenz benötigt. Damit das funktioniert benötigst du noch eine dritte SQL-Instanz als sog. Zeugenserver, dafür reicht ein SQL Express völlig aus, da hier _keine_ Datenbanken liegen, sondern quasi nur der Heartbeat überwacht und das Failover ausgelöst wird.
Cheers,
jsysde
Cheers,
jsysde
Zur Spiegelung an sich ist zu sagen, dass zwar ein Datenbankfailover stattfindet aber auf eine andere Maschine, deine Applikationen müssen dann
zwangsweise auf die andere Datenbankmaschine schwenken, da die Anbinung ja in der Regel per IP oder Hostname geschieht,
hat die gespiegelte Maschine zwangsweise eine andere IP.
Sollte der Failover voll automatisiert gehen sollen, brauchst du einen Loadbalancer, der den zweiten Clusterknoten als
Standby in dem Cluster der nach außen sichtbar ist hat.
Beispiel wäre Clusterip = 192.168.0.10 Server1(Clusterserver1) = 192.168.0.11 und Server2(Clusterserver2) = 192.168.0.12
Deine Applikation würde auf die 192.168.0.10 und dahinter hängen dann x Slaves
oder du brauchst auf beiden Maschinen Server 2008 Enterprise, der kann das auch abbilden.
zwangsweise auf die andere Datenbankmaschine schwenken, da die Anbinung ja in der Regel per IP oder Hostname geschieht,
hat die gespiegelte Maschine zwangsweise eine andere IP.
Sollte der Failover voll automatisiert gehen sollen, brauchst du einen Loadbalancer, der den zweiten Clusterknoten als
Standby in dem Cluster der nach außen sichtbar ist hat.
Beispiel wäre Clusterip = 192.168.0.10 Server1(Clusterserver1) = 192.168.0.11 und Server2(Clusterserver2) = 192.168.0.12
Deine Applikation würde auf die 192.168.0.10 und dahinter hängen dann x Slaves
oder du brauchst auf beiden Maschinen Server 2008 Enterprise, der kann das auch abbilden.
Hallo Intrador,
Das mit dem Failovercluster auf Basis des Enterpriseservers sollte ja aus Lizenzgründen vermieden werden (da 2000 EUR pro Serverlizenz)
zum Thema Datenbankspiegelung:
ich hatte es bisher so verstanden dass beim Ausfall des DB-Servers ein Whitness-Server automatisch die Anfragen an den Spiegelserver umleitet. So also eh ein "virtueller" Ansprechpartner zur Verfügung steht der eben normalerweise den Prinzipal, im Notfall den Spiegelserver bedient? Wenn nein ist es ja unbrauchbar, dann würde ich nach dem Umbiegen der Clients mit einer kleinen Replikation auch hinkomme. Wenn ja wäre es ja in etwa das was ich mir vorstelle..
(nebenbei: Ich freu mich jetzt schon auf die ersten "Wenn du keine Ahnung hast überlass das Feld den Profis"-Posts, aber ich bin ja lernbegierig und mit Geldern für Fortbildugnen nur spärlich ausgestattet..)
Das mit dem Failovercluster auf Basis des Enterpriseservers sollte ja aus Lizenzgründen vermieden werden (da 2000 EUR pro Serverlizenz)
zum Thema Datenbankspiegelung:
ich hatte es bisher so verstanden dass beim Ausfall des DB-Servers ein Whitness-Server automatisch die Anfragen an den Spiegelserver umleitet. So also eh ein "virtueller" Ansprechpartner zur Verfügung steht der eben normalerweise den Prinzipal, im Notfall den Spiegelserver bedient? Wenn nein ist es ja unbrauchbar, dann würde ich nach dem Umbiegen der Clients mit einer kleinen Replikation auch hinkomme. Wenn ja wäre es ja in etwa das was ich mir vorstelle..
(nebenbei: Ich freu mich jetzt schon auf die ersten "Wenn du keine Ahnung hast überlass das Feld den Profis"-Posts, aber ich bin ja lernbegierig und mit Geldern für Fortbildugnen nur spärlich ausgestattet..)
Hi manbar,
du hast die Funktion des Whitness und des Quorums falsch verstanden.
Hier ist ein ganz netter Link, der das gut erklärt:
http://msdn.microsoft.com/en-us/library/ms189902.aspx
http://msdn.microsoft.com/de-de/library/ms189590.aspx
Ja der Whitess macht failover, auf Server A läuft grade produktiv die DB, auf Server B spiegelt sie und ist im Wiederherstellungsmodus.
Der Whitness überwacht den Vorgang und wenn Server A wegfällt, setzt er auf B die Datenbank aus dem Wiederherstellungsmodus auf Aktivmidus. Genau an dem Punkt ist für ihn das Thema erledigt, der Failover auf die andere Datenbank ist erfolgt, was mit deinen Clients passiert ist dem Whitness vollkommen egal, der wird auch nie gefragt.
Für ein richtiges failover brauchst du wie gesagt 2 Server mit Windows Server Enterprise im Cluster und darauf aufgesetzt zwei SQL Server Enterprise im Failover. Wenn in dem Konstrukt Server A ausfallen würde sorgt der SQL Server sich auf dem anderen Server um die Datenbank bzw. das Failover und der Windows Enterprise sorgt dafür, dass Server B für die Clients aussieht wie Server A.
Um auch auf deine Kernfrage einzugehen, mit dem was du hast kannst du keine Lösung schaffen, die komplett automatisiert einen Failover ausführt. Man kann sicherlich was basteln aber nichts, bei dem ich als Empfehlung gut schlafen könnte
Ich hoffe das ist verständlich genug, wenn nicht, fragen hilft ;)
Gruß
Indra
du hast die Funktion des Whitness und des Quorums falsch verstanden.
Hier ist ein ganz netter Link, der das gut erklärt:
http://msdn.microsoft.com/en-us/library/ms189902.aspx
http://msdn.microsoft.com/de-de/library/ms189590.aspx
Ja der Whitess macht failover, auf Server A läuft grade produktiv die DB, auf Server B spiegelt sie und ist im Wiederherstellungsmodus.
Der Whitness überwacht den Vorgang und wenn Server A wegfällt, setzt er auf B die Datenbank aus dem Wiederherstellungsmodus auf Aktivmidus. Genau an dem Punkt ist für ihn das Thema erledigt, der Failover auf die andere Datenbank ist erfolgt, was mit deinen Clients passiert ist dem Whitness vollkommen egal, der wird auch nie gefragt.
Für ein richtiges failover brauchst du wie gesagt 2 Server mit Windows Server Enterprise im Cluster und darauf aufgesetzt zwei SQL Server Enterprise im Failover. Wenn in dem Konstrukt Server A ausfallen würde sorgt der SQL Server sich auf dem anderen Server um die Datenbank bzw. das Failover und der Windows Enterprise sorgt dafür, dass Server B für die Clients aussieht wie Server A.
Um auch auf deine Kernfrage einzugehen, mit dem was du hast kannst du keine Lösung schaffen, die komplett automatisiert einen Failover ausführt. Man kann sicherlich was basteln aber nichts, bei dem ich als Empfehlung gut schlafen könnte
Ich hoffe das ist verständlich genug, wenn nicht, fragen hilft ;)
Gruß
Indra
Okay, dann hab ich dem Zeugen wohl etwas zu viel zugetraut. Prinzipiell sorgt der also nur erstmal dafür dass die Daten integer vorgehalten werden, richtig?
Das mit dem "virtuellen Ansprechpartner" wäre auch zu schön gewesen.. Aber wir bräuchten ja eine Vollredundanz.
Gut, dann muss mich mich wohl doch erstmal mit der "richtigen" Failovermethode beschäftigen. nützt ja auch nix wenn ich wochenlang an einer Lösung bastele die nur mäßig zum Erfolg führt, nur um 1000EUR pro win-Serverlizenz zu sparen...
Ich danke dir erstmal für den Überblick. Ohne Anhaltspunkte "mal eben" in das Thema einzusteigen ist doch sehr haarig wie ich finde, man findet erstmal nur "Werbewischiwaschi" aber keine gut zugänglichen Technischen Hilfen.
Zumindest wenn man nicht weiss wo man suchen soll ;)
Danke und Gruß Manuel
Das mit dem "virtuellen Ansprechpartner" wäre auch zu schön gewesen.. Aber wir bräuchten ja eine Vollredundanz.
Gut, dann muss mich mich wohl doch erstmal mit der "richtigen" Failovermethode beschäftigen. nützt ja auch nix wenn ich wochenlang an einer Lösung bastele die nur mäßig zum Erfolg führt, nur um 1000EUR pro win-Serverlizenz zu sparen...
Ich danke dir erstmal für den Überblick. Ohne Anhaltspunkte "mal eben" in das Thema einzusteigen ist doch sehr haarig wie ich finde, man findet erstmal nur "Werbewischiwaschi" aber keine gut zugänglichen Technischen Hilfen.
Zumindest wenn man nicht weiss wo man suchen soll ;)
Danke und Gruß Manuel
Hier mal ein Link, der dir den Einstieg vielleicht erleichtert:
http://msdn.microsoft.com/de-de/library/ms189134.aspx
Bedenke, bevor du das alles aufsetzt, ob es bei 2 Knoten bleiben soll, das ist nämlich das maximum des Standard-Servers,
über 3 bis zu 8 Knoten kann nur der Enterprise-Server
Das Thema ist keinesfalls trivial, vielleicht holt ihr euch professionelle Unterstützung, das ist kein überlass das Feld den Profis post,
sondern das ist wirklich nicht einfach und es gibt hier und da Tricks und Kniffe, die findest du nicht bei google oder in Foren.
Gruß
Indra
http://msdn.microsoft.com/de-de/library/ms189134.aspx
Bedenke, bevor du das alles aufsetzt, ob es bei 2 Knoten bleiben soll, das ist nämlich das maximum des Standard-Servers,
über 3 bis zu 8 Knoten kann nur der Enterprise-Server
Das Thema ist keinesfalls trivial, vielleicht holt ihr euch professionelle Unterstützung, das ist kein überlass das Feld den Profis post,
sondern das ist wirklich nicht einfach und es gibt hier und da Tricks und Kniffe, die findest du nicht bei google oder in Foren.
Gruß
Indra
Moin,
Stimmt. Aber eine "gute" Applikation lässt sich im Connection-String mehrere SQL-Server übergeben.
Cheers,
jsysde
Zur Spiegelung an sich ist zu sagen, dass zwar ein Datenbankfailover stattfindet aber auf eine andere Maschine, deine
Applikationen müssen dann
zwangsweise auf die andere Datenbankmaschine schwenken, da die Anbinung ja in der Regel per IP oder Hostname geschieht,
hat die gespiegelte Maschine zwangsweise eine andere IP.
Applikationen müssen dann
zwangsweise auf die andere Datenbankmaschine schwenken, da die Anbinung ja in der Regel per IP oder Hostname geschieht,
hat die gespiegelte Maschine zwangsweise eine andere IP.
Stimmt. Aber eine "gute" Applikation lässt sich im Connection-String mehrere SQL-Server übergeben.
Cheers,
jsysde
