5
SQL Server Synchronisation - Möglichkeiten
Hallo Forum,
vielleicht kennt ja jemand die Problematik und kann Tipps oder externe Software empfehlen.
Es sollen zwei Standorte A und B mit einer Software auf Basis des MS SQL Datenbankservers betrieben werden. Die Daten sollten wenn möglich ohne größeren Wartungsaufwand in beiden Standorten zur Verfügung stehen, d.h. sowohl A als auch B nutzt die Datenbank lesend als auch schreibend.
Zudem ist B relativ schwach ans Internet angebunden, d.h. regelmäßige Verbindungsabbrüche oder längere Ausfälle treten tagtäglich auf. Ein Standortwechsel von B kommt nicht in Frage, bessere WAN-Provider oder Standleitungen sind nicht verfügbar.
Im Moment sehe ich folgende Möglichkeiten:
- 2 Server (in jedem Standort, einer), die sich über "Web Synchronisation for Merge Replication" replizieren. Vorteil: Es kann ohne WAN gearbeitet werden. Nachteil: Es ist fraglich, ob die Replikation regelmäßig läuft, oder Fehler und Wartungsaufwände produziert.
- Terminal Services: Die bestmögliche Lösung für synchronen Daten ohne regelmäßige Aussetzer der WAN-Verbindung? Kommt die VPN-Verbindung (ssl-vpn) damit klar?
- eine Zwischenlösung mit manuellen Datenabgleichen bei 2 Servern (in jedem Standort einen).
Kennt jemand die Problematik? Gibt es eventuell Drittsoftware, die das Thema Replikation vereinfacht / automatisiert? Gibt es Ansätze, die nicht bedacht wurden? Was würdet ihr im Falle einer guten WAN Anbindung beider Standorte vorziehen?
Gruss Grinskeks
vielleicht kennt ja jemand die Problematik und kann Tipps oder externe Software empfehlen.
Es sollen zwei Standorte A und B mit einer Software auf Basis des MS SQL Datenbankservers betrieben werden. Die Daten sollten wenn möglich ohne größeren Wartungsaufwand in beiden Standorten zur Verfügung stehen, d.h. sowohl A als auch B nutzt die Datenbank lesend als auch schreibend.
Zudem ist B relativ schwach ans Internet angebunden, d.h. regelmäßige Verbindungsabbrüche oder längere Ausfälle treten tagtäglich auf. Ein Standortwechsel von B kommt nicht in Frage, bessere WAN-Provider oder Standleitungen sind nicht verfügbar.
Im Moment sehe ich folgende Möglichkeiten:
- 2 Server (in jedem Standort, einer), die sich über "Web Synchronisation for Merge Replication" replizieren. Vorteil: Es kann ohne WAN gearbeitet werden. Nachteil: Es ist fraglich, ob die Replikation regelmäßig läuft, oder Fehler und Wartungsaufwände produziert.
- Terminal Services: Die bestmögliche Lösung für synchronen Daten ohne regelmäßige Aussetzer der WAN-Verbindung? Kommt die VPN-Verbindung (ssl-vpn) damit klar?
- eine Zwischenlösung mit manuellen Datenabgleichen bei 2 Servern (in jedem Standort einen).
Kennt jemand die Problematik? Gibt es eventuell Drittsoftware, die das Thema Replikation vereinfacht / automatisiert? Gibt es Ansätze, die nicht bedacht wurden? Was würdet ihr im Falle einer guten WAN Anbindung beider Standorte vorziehen?
Gruss Grinskeks
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: 181117
Url: https://administrator.de/forum/sql-server-synchronisation-moeglichkeiten-181117.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
5 Kommentare
Neuester Kommentar
Hi Grinskeks,
ich halte die Replication für fragwürdig. Wird denn eine Repli von Hersteller der Software auch supportet?!
Ich würde mir Sorgen machen, dass irgendwann doppelte IDs oder ähnliches gibt. Ich würde den SQL-Server an einem Standort aufstellen und über RDS arbeiten. Evtl. kannst du mit Riverbeds noch etwas an Performance rausholen.
Grüße,
Dani
ich halte die Replication für fragwürdig. Wird denn eine Repli von Hersteller der Software auch supportet?!
Ich würde mir Sorgen machen, dass irgendwann doppelte IDs oder ähnliches gibt. Ich würde den SQL-Server an einem Standort aufstellen und über RDS arbeiten. Evtl. kannst du mit Riverbeds noch etwas an Performance rausholen.
Grüße,
Dani
Also wenn Du die Möglichkeit hast, dann ja besser TS. Ob die Bndbreite der WAN-Strecke reicht, hängt von der Anzahl User ab, die da parallel drüber arbeiten würden. Und ja, VPN sollte gehen.
Hallo,
üblicherweise greift man bei solchen Anforderungen zu einem Terminalserver. Wenn die Verbindung dafür zu schlecht ist, hast du ein Problem.
Was die Merge Replication angeht: Sofern die Anwendung dieses Setup nicht explizit unterstützt, wird es höchstwahrscheinlich nicht funktionieren. Das ist kein Feature was vollautomatisch mit jeder Anwendung funktioniert, wenn auf beiden Seiten Updates passieren sollen. Das liest sich in den ersten paar Google-Treffern vielleicht so, wenn es dann aber ans Eingemachte geht, sieht die Welt anders aus, z.B. passieren Änderungen immer auf dem Publisher einer Tabelle und das kann nur einer sein, etc.pp. Details unter http://msdn.microsoft.com/en-us/library/bb500348.aspx und Folgende.
MfG
üblicherweise greift man bei solchen Anforderungen zu einem Terminalserver. Wenn die Verbindung dafür zu schlecht ist, hast du ein Problem.
Was die Merge Replication angeht: Sofern die Anwendung dieses Setup nicht explizit unterstützt, wird es höchstwahrscheinlich nicht funktionieren. Das ist kein Feature was vollautomatisch mit jeder Anwendung funktioniert, wenn auf beiden Seiten Updates passieren sollen. Das liest sich in den ersten paar Google-Treffern vielleicht so, wenn es dann aber ans Eingemachte geht, sieht die Welt anders aus, z.B. passieren Änderungen immer auf dem Publisher einer Tabelle und das kann nur einer sein, etc.pp. Details unter http://msdn.microsoft.com/en-us/library/bb500348.aspx und Folgende.
MfG
wir arbeiten bei uns in den Niederlassungen mit der RemoteApp von MS, funktioniert bei 5 Usern und einer 2Mbit SDSL an sich tadellos und auch die Geschwindigkeit ist akzeptabel zum arbeiten
Hallo und danke für die vielen Antworten.
Replikation wäre theoretisch möglich, da wir die Software selbst entwickelt haben und keine autoincrements sondern uniqueidentifier nutzen. Aber der Wartungsaufwand und vor allem die Reinitialisierung nach DB-Updates, was in einer Warenwirtschaft öfter mal vorkommt, haben vorab schon für Bauchschmerzen gesorgt. Das wesentliche Problem hierbei ist insbesondere der Zeit- und damit auch finanzielle Aufwand, um die Replikation im Gange zu halten. Denn der Kunde hat wie so oft keinen eigenen Admin.
Riverbeds kannte ich nicht, das schaue ich mir auf jeden Fall mal an.
Die RemoteApp-Funktion ist schon nett, da unsere Software aber auch auf Word, Outlook und weitere Schnittstellen zugreift, müsste eine contentt redirection her und dann wären wir gleich wieder bei citrix, sofern nicht alle Software serverseitig läuft.
Wir werden dem Kunden wohl eine Zwischenlösung anbieten. Er kann über TS arbeiten und sollte das Wan ausfallen, kann er lokal mit einem alten Stammdatenbestand (z.B. wöchentlicher Upload) weiterhin Korrespondenz etc. nutzen. Eventuell werden noch Nummernkreise für die Belege in Absprache mit dem Steuerberater definiert, sodaß die Belege über eine Sonderfunktion extrahiert und auf dem Hauptserver importiert werden können.
Weitere Ideen werden gerne angenommen
Gruss
Grinskeks
Replikation wäre theoretisch möglich, da wir die Software selbst entwickelt haben und keine autoincrements sondern uniqueidentifier nutzen. Aber der Wartungsaufwand und vor allem die Reinitialisierung nach DB-Updates, was in einer Warenwirtschaft öfter mal vorkommt, haben vorab schon für Bauchschmerzen gesorgt. Das wesentliche Problem hierbei ist insbesondere der Zeit- und damit auch finanzielle Aufwand, um die Replikation im Gange zu halten. Denn der Kunde hat wie so oft keinen eigenen Admin.
Riverbeds kannte ich nicht, das schaue ich mir auf jeden Fall mal an.
Die RemoteApp-Funktion ist schon nett, da unsere Software aber auch auf Word, Outlook und weitere Schnittstellen zugreift, müsste eine contentt redirection her und dann wären wir gleich wieder bei citrix, sofern nicht alle Software serverseitig läuft.
Wir werden dem Kunden wohl eine Zwischenlösung anbieten. Er kann über TS arbeiten und sollte das Wan ausfallen, kann er lokal mit einem alten Stammdatenbestand (z.B. wöchentlicher Upload) weiterhin Korrespondenz etc. nutzen. Eventuell werden noch Nummernkreise für die Belege in Absprache mit dem Steuerberater definiert, sodaß die Belege über eine Sonderfunktion extrahiert und auf dem Hauptserver importiert werden können.
Weitere Ideen werden gerne angenommen
Gruss
Grinskeks
