96246
Goto Top

SQL Server 2012 AlwaysOn

Hallo zusammen,

dieses Szenario geht an alle Erfahrenen SQL Administratoren.
Ich bin in einem Projekt auf der Suche nach einer SQL Server 2012 Enterprise Lösung die das Szenario in der Zeichnung abbilden kann.
Zur Information zu dem Bild:


19a73a81485d58baa5416917dde219aa

Einsatz von:
Server 2008R2 Enterprise
SQL Server 2012 Enterprise

Es gibt 2 Datenbanken.
Ich stelle mir vor es gibt Mitarbeiter die arbeiten auf der CRM Datenbank und andere auf der wawi DB.
Jeder von ihnen hat dafür einen eigenen Server zur Verfügung.
Mitarbeiter A schreibt tagsüber Daten in die CRM DB, der andere Wawi Daten.
Zum Zeitpunkt X sollen beide Server beide Stände der Datenbanken austauschen, falls einer ausfällt man dann umstellen kann auf den anderen.
Jetzt kommt bei SQL 2012 das Always On dazu. Ich habe aber noch nicht verstanden ob bei always on auf 2 Seiten in die DB geschrieben werden kann oder auf einer nur lesend.
Im Prinzip brauche ich ja 2 active Server um meinen Anforderungen gerecht zu werden richtig?

Ich hoffe ihr könnt mir dabei weiter helfen und mir eure Erfahrungen und Ratschläge ( auch wenn noch nicht mit SQL 2012) erzählen.

Als Bonusfrage:
Ist in euren Augen eine virtualisierung dort sinnvoll? ( es kommt kein weiterer Server hinzu, rein SQL)

Ich freue mich über eine gute Diskussion

Content-Key: 183803

Url: https://administrator.de/contentid/183803

Ausgedruckt am: 28.03.2024 um 13:03 Uhr

Mitglied: NetWolf
NetWolf 19.04.2012 um 17:31:59 Uhr
Goto Top
Moin Moin,

eine Frage hab ich noch: "Zum Zeitpunkt X sollen beide Server beide Stände der Datenbanken austauschen" soll bedeuten, dass nur die geänderten Datensätze ausgetauscht werden sollen, oder kompletter Export/Import?

Grüße aus Rostock
Wolfgang
(Netwolf)
Mitglied: 96246
96246 19.04.2012 um 17:57:11 Uhr
Goto Top
Hallo Netwolf,

ja geänderte wäre ausreichend.
Mitglied: NetWolf
NetWolf 19.04.2012 um 19:20:06 Uhr
Goto Top
ok, das würde eine Synchronisierung bedeuten.

Als Hausmittel gibt es beim MS SQL die Datenbank-Replikation.

Dabei gibt es mehrere Varianten:

- Snapshot-Repl: Geht in eine Richtung Verleger => Abonnent, wobei aber jedesmal der ganze Datenbestand übertragen wird (wolltest du nicht)
- Transactions-Repl: Auch nur in eine Richtung, wobei nur Änderungen übertragen werden. (gut für den Normalfall = Sicherung)
- Merge-Repl: Überträgt Änderungen bidirektional, also auch von Server B nach A (gut wenn dann nach wechselseitiger Nutzung wieder alles zurück-übertragen werden soll)

Grüße aus Rostock
Wolfgang
(Netwolf)
Mitglied: 96246
96246 19.04.2012 um 21:21:35 Uhr
Goto Top
- Merge-Repl: Überträgt Änderungen bidirektional, also auch von Server B nach A (gut wenn dann nach wechselseitiger
Nutzung wieder alles zurück-übertragen werden soll

Zum Verständnis für mich, heißt die merge repl. das ich die Server
dann im active-active betreibe oder hat das in dem Fall nichts damit zu tun?
Mitglied: NetWolf
NetWolf 20.04.2012 um 13:47:29 Uhr
Goto Top
Beide Server laufen ja sowieso mit einer Instanz des SQL-Servers, wenn ich das richtig verstanden habe. Also CRM auf Server 1, und WAWI auf Server 2.
Dann kannst du ohne weiteres eine zusätzlich Instanz hinzufügen.

Ein interessanter Beitrag zum Thema active/active vs. active/passive Cluster.

Grüße aus Rostock
Wolfgang
(Netwolf)
Mitglied: 96246
96246 20.04.2012 um 14:10:41 Uhr
Goto Top
Zitat von @NetWolf:
Beide Server laufen ja sowieso mit einer Instanz des SQL-Servers, wenn ich das richtig verstanden habe. Also CRM auf Server 1,
und WAWI auf Server 2.
Dann kannst du ohne weiteres eine zusätzlich Instanz hinzufügen.


Hi Ja stimmt, aber wenn der Server1 mit CRM ausfällt habe ich ja keinen abgleich der DB (CRM) auf Server2.
Mitglied: 96246
96246 23.04.2012 um 15:23:06 Uhr
Goto Top
Hi,

jetzt habe auch ich das Pinzip verstanden, ich werde das ganze wohl mit HyperV machen und sowohl das Gastsystem als natürlich auch die DB im Storage haben.
Somit ist natürlich jeder einzelne SQL Server Active!
Vorher habe ich angenommen ich könnte eine DB nochmal teilen und irgendwann zusammenfügen, aber das ist ja Quatsch.