4
Planung IIS und MSSQL-Szenario
Hallo,
ich plane gerade den Umzug von einer IIS7+MSSQL 2005 auf eine redundante IIS8.5+MSSQL 2012 Lösung. Hauptziel soll sein, dass die Webanwendung immer online ist, auch wenn einer der Server z.B. Updatebedingt neu startet (und im Ausfall-Fall). Hardwareseitig liegt ein voll redundanter Xen-Cluster vor, der auch das Speichersystem redundant anbindet. Es werden zwei Server aufgesetzt.
Es liegt ein Hardware-Loadbalancer vor, der die Anfragen nach dem Zufallsprinzip auf die IIS verteilt. Mich treiben jetzt noch folgende Fragen um und ich möchte euch um eure Meinung hierzu bitten:
1) sollte ich die Rollen IIS und MSSQL trennen, also 2 virtuelle Maschinen mit je IIS+SQL oder 2x IIS und 2x MSSQL -> ich denke 2 reichen
2) sollten die Webserver in ein bestehendes firmeninternes AD eingebunden werden? -> ich sage nein
3) sollten die Web- und MSSQL überhaupt in eine gemeinsame Domäne eingebunden werden? -> keine Ahnung ob gut oder schlecht. Ich denk mir nur, dass ich ein Problem habe, wenn der Domänencontroller ausfällt. Dann müsste ich den auch doppelt auslegen.
4) welche Art der Hochverfügbarkeit bei MSSQL2012 wäre ideal, wenn ich die Enterprise-Edition nicht kaufen möchte
Besten Dank schon im Voraus
Peter
ich plane gerade den Umzug von einer IIS7+MSSQL 2005 auf eine redundante IIS8.5+MSSQL 2012 Lösung. Hauptziel soll sein, dass die Webanwendung immer online ist, auch wenn einer der Server z.B. Updatebedingt neu startet (und im Ausfall-Fall). Hardwareseitig liegt ein voll redundanter Xen-Cluster vor, der auch das Speichersystem redundant anbindet. Es werden zwei Server aufgesetzt.
Es liegt ein Hardware-Loadbalancer vor, der die Anfragen nach dem Zufallsprinzip auf die IIS verteilt. Mich treiben jetzt noch folgende Fragen um und ich möchte euch um eure Meinung hierzu bitten:
1) sollte ich die Rollen IIS und MSSQL trennen, also 2 virtuelle Maschinen mit je IIS+SQL oder 2x IIS und 2x MSSQL -> ich denke 2 reichen
2) sollten die Webserver in ein bestehendes firmeninternes AD eingebunden werden? -> ich sage nein
3) sollten die Web- und MSSQL überhaupt in eine gemeinsame Domäne eingebunden werden? -> keine Ahnung ob gut oder schlecht. Ich denk mir nur, dass ich ein Problem habe, wenn der Domänencontroller ausfällt. Dann müsste ich den auch doppelt auslegen.
4) welche Art der Hochverfügbarkeit bei MSSQL2012 wäre ideal, wenn ich die Enterprise-Edition nicht kaufen möchte
Besten Dank schon im Voraus
Peter
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: 275906
Url: https://administrator.de/forum/planung-iis-und-mssql-szenario-275906.html
Ausgedruckt am: 25.12.2024 um 01:12 Uhr
4 Kommentare
Neuester Kommentar
Nabend...
1. 2 VM`s reichen
2.ich sage auch nein.
3. Nein, das würde ich nicht tun!
4.
Der SQL Server 2012 kann je nach Edition mit bis zu drei Features für die Hochverfügbarkeit aufwarten:
der synchronen Datenbankspiegelung, den AlwaysOn Failover-Cluster-Instanzen und den AlwaysOn-Verfügbarkeitsgruppen (die letzte Option ist nur in der „Edition Enterprise“ zu haben). Bei der synchronen Datenbankspiegelung in SQL Server handelte es sich um eine Hochverfügbarkeitslösung; bei der asynchronen Datenbankspiegelung (nur in der Enterprise-Edition verfügbar) um eine Notfalllösung zur Datenwiderherstellung.
Bei der Datenbankspiegelung besteht die Umgebung aus zwei Instanzen mit lokalem Speicher, einem Prinzipal-Server mit der Prinzipal-Datenbank und einem Spiegel-Server mit der Spiegel-Datenbank. Im Hochsicherheitsmodus kann ein automatisches Failover stattfinden. Dies erfordert allerdings einen dritten Server, den so genannten Zeugen.
Bei der synchronen Datenbankspiegelung übergibt der Prinzipal-Server den Commit einer jeden Transaktion unmittelbar an den Spiegel-Server und erst nach Erhalt einer Bestätigung meldet er den Vorgang als abgeschlossen. Der Sekundär-Server kann die Aufgaben des Primär-Server sofort übernehmen.
Informationen von außerhalb der betreffenden Datenbank wie Jobs, Joints und Transaktionen, die mehrere Datenbanken gleichzeitig betreffen, gehen entweder verloren oder lassen sich nicht fehlerfrei übernehmen. Diese Lösung ist zudem langsam.
Asynchrone Datenbankspiegelung erfolgt mit einer erheblichen Zeitverzögerung. Daher eignet sich dieses Vorgehen zwar nicht für ein automatisches Failover, dafür aber für die Datensicherung und die Notfallwiederherstellung durch einen Administrator.
Lg
Frank
1. 2 VM`s reichen
2.ich sage auch nein.
3. Nein, das würde ich nicht tun!
4.
Der SQL Server 2012 kann je nach Edition mit bis zu drei Features für die Hochverfügbarkeit aufwarten:
der synchronen Datenbankspiegelung, den AlwaysOn Failover-Cluster-Instanzen und den AlwaysOn-Verfügbarkeitsgruppen (die letzte Option ist nur in der „Edition Enterprise“ zu haben). Bei der synchronen Datenbankspiegelung in SQL Server handelte es sich um eine Hochverfügbarkeitslösung; bei der asynchronen Datenbankspiegelung (nur in der Enterprise-Edition verfügbar) um eine Notfalllösung zur Datenwiderherstellung.
Bei der Datenbankspiegelung besteht die Umgebung aus zwei Instanzen mit lokalem Speicher, einem Prinzipal-Server mit der Prinzipal-Datenbank und einem Spiegel-Server mit der Spiegel-Datenbank. Im Hochsicherheitsmodus kann ein automatisches Failover stattfinden. Dies erfordert allerdings einen dritten Server, den so genannten Zeugen.
Bei der synchronen Datenbankspiegelung übergibt der Prinzipal-Server den Commit einer jeden Transaktion unmittelbar an den Spiegel-Server und erst nach Erhalt einer Bestätigung meldet er den Vorgang als abgeschlossen. Der Sekundär-Server kann die Aufgaben des Primär-Server sofort übernehmen.
Informationen von außerhalb der betreffenden Datenbank wie Jobs, Joints und Transaktionen, die mehrere Datenbanken gleichzeitig betreffen, gehen entweder verloren oder lassen sich nicht fehlerfrei übernehmen. Diese Lösung ist zudem langsam.
Asynchrone Datenbankspiegelung erfolgt mit einer erheblichen Zeitverzögerung. Daher eignet sich dieses Vorgehen zwar nicht für ein automatisches Failover, dafür aber für die Datensicherung und die Notfallwiederherstellung durch einen Administrator.
Lg
Frank
Moin,
Gruß,
Dani
Es liegt ein Hardware-Loadbalancer vor
Du legst den IIS und SQL-Server redudant aus, aber den LB nicht? Hmm...1) sollte ich die Rollen IIS und MSSQL trennen, also 2 virtuelle Maschinen mit je IIS+SQL oder 2x IIS und 2x MSSQL -> ich denke 2 reichen
Würde ich schon aus Sicherheit machen. Wird der IIS inflitiert ist der DB-Server noch nicht in Gefahr.2) sollten die Webserver in ein bestehendes firmeninternes AD eingebunden werden? -> ich sage nein
Wenn der IIS direkt ohne Reverse Proxy im Internet erreichbar ist, Nein. Ansonsten kann man darüber nachdenken.keine Ahnung ob gut oder schlecht. Ich denk mir nur, dass ich ein Problem habe, wenn der Domänencontroller ausfällt. Dann müsste ich den auch doppelt auslegen.
Wie würde das Problem denn ohne einen DC aussehen? Unabhängig davon, wiederspricht es deiner Grundsatzidee: Hochverfügbarkeit. Du legst Web und SQL-Server redudant an aber am DC wird wieder gespart -> SPOF.Gruß,
Dani
Danke Dani und Frank.
Der Loadbalancer ist redundant, das habe ich nicht erwähnt.
Der IIS wäre direkt am WAN, daher werde ich wohl Danis Vorschlag folgen und beide Systeme trennen.
Auf eine Domäne verzichte ich vorerst.
Grüße,
Peter
Der Loadbalancer ist redundant, das habe ich nicht erwähnt.
Der IIS wäre direkt am WAN, daher werde ich wohl Danis Vorschlag folgen und beide Systeme trennen.
Auf eine Domäne verzichte ich vorerst.
Grüße,
Peter
nabend..
am WAN ? du meinst wohl DMZ
die systeme zu trennen ist natürlich ok, und hat auch vorteile, wie Dani geschrchrieben hat.
lg
Frank
am WAN ? du meinst wohl DMZ
die systeme zu trennen ist natürlich ok, und hat auch vorteile, wie Dani geschrchrieben hat.
lg
Frank
