Brücke für die Georeplikation
Bei umfangreichen Anwendungen werden verteilte Caches verwendet, um die Leistung, Zuverlässigkeit und Laufzeitskalierbarkeit Ihrer Anwendungen zu verbessern. Daher können verteilte Caches ein sehr wichtiger Bestandteil Ihres Notfallwiederherstellungsplans sein, der von Naturkatastrophen bis hin zu internen Hardware-Katastrophen oder Softwarefehlern reichen kann.
Der beste und am häufigsten verwendete Disaster-Recovery-Plan ist die Live-Datenreplikation auf andere Backup-Standorte. So können Sie Ihre Live-Benutzer bei Bedarf fehlerfrei auf Ihre Backup-Site umleiten. Dazu muss jedoch sichergestellt werden, dass sowohl Ihr aktiver Cache als auch Ihr Backup-Cache jederzeit synchronisiert sind. Wenn sie nicht synchronisiert sind, kann dies Auswirkungen auf die Cache-Clients Ihrer Anwendungen haben.
NCache Bietet Ihnen WAN-Replikation über die Bridge-Funktion. Zwischen mehreren Cluster-Caches wird eine Brücke erstellt und Daten werden über diese Brücke von der Quelle zum anderen Standort repliziert.
Wenn Sie nicht nur Disaster-Recovery-Pläne haben, sondern Ihre Anwendung auch in geografisch getrennten Regionen für weit verstreute Kunden bereitstellen möchten, löst die Datenreplikation auch das Problem für Sie. Hier können Sie zwei oder mehr aktive Sites haben, die sich um Benutzer verwandter Regionen kümmern und auch als Backup für andere Regionssites verwendet werden können.
Die Remote-Datenreplikation ist eine entscheidende Komponente für jeden Plan, um einen effektiven und effizienten Schutz der Daten und eine schnelle Wiederherstellung nach einer größeren Unterbrechung zu gewährleisten. Die synchrone Replikation von Daten ist für den Cluster intern gut, ihre Auswirkung auf die Leistung wird jedoch zu einem wichtigen Faktor, wenn Cache-Cluster geografisch getrennt sind. Die Bridge ist für Szenarien konzipiert, die die Replikation von Daten von On-Site-Cache(s) zu anderen On-Site/Offsite-Cache(s) über das WAN zur Notfallwiederherstellung beinhalten. Aufgrund der asynchronen Replikation erhalten alle mit dem/den aktiven Cache(s) verbundenen Clients den Eindruck, dass die Vorgänge im aktiven Cache ausgeführt werden, während eine vollständige Sicherung nahtlos in den/die anderen Cache(s) übernommen wird.
Wenn eine Operation am Quellcache ausgeführt wird, wird sie asynchron an die Bridge übergeben. Dieser Vorgang wird dann in einer von der Brücke verwalteten Warteschlange eingereiht. Vorgänge aus der Warteschlange werden an den Zielcache übertragen, wenn die Bridge feststellt, dass der Zielcache verfügbar und bereit ist, Vorgänge anzunehmen. Mit der Brücke wird sichergestellt, dass:
- Es gibt keinen Leistungsabfall.
- Vorgänge werden in derselben Reihenfolge ausgeführt wie im ursprünglichen Cache.
- Operationen gehen bei einem Verbindungsausfall nicht verloren.
Pluggable Caching-Architektur: Caches sind sich gegenseitig nicht bewusst; Sie kennen die Brücke einfach und replizieren ihre Daten auf der Brücke. Aufgrund dieser losen Kopplung können Sie eine Brücke zwischen mehreren Caches konfigurieren, unabhängig von ihrer Cache-Topologie. Sie können mit einer Bridge konfigurierte Caches frei entfernen.
Datenintegrität: Im Quellcache ausgeführte Vorgänge werden von der Bridge in die Warteschlange gestellt, wobei die tatsächliche Reihenfolge beibehalten wird, in der sie im Quellcache ausgeführt wurden. Die Bridge führt Vorgänge für den Zielcache in derselben Reihenfolge aus. Konflikte werden im Zielcache gelöst. Auf diese Weise werden Caches schließlich konsistent.
Dedizierter Bridge-Service: Die Bridge ist wie der Cache-Dienst auch ein eigenständiger und dedizierter Dienst, sodass Ihre Cache-Vorgänge nicht beeinträchtigt werden, wenn Bridge-Vorgänge aufgrund von Latenz im Netzwerk verzögert werden.
Bridge konfigurieren: Sie können Ihre Bridge auf demselben Server konfigurieren, auf dem sich Ihr Cluster-Cache befindet, oder Sie können sie auf einem separaten Serverknoten erstellen. Anschließend können Sie beliebige Ihrer Cluster-Caches zur Bridge hinzufügen und die Daten werden zwischen ihnen repliziert.
Katastrophale Erholung: Sie können eine Brücke zwischen einem aktiven und einem passiven Rechenzentrum für die Notfallwiederherstellung konfigurieren.
Handel mit geografisch verteilten Kunden: Sie können über zwei oder mehr aktive Websites verfügen, die sich auf die Benutzer verwandter Regionen beziehen und auch als Backup für Websites anderer Regionen verwendet werden können.
Asynchrone Replikation: Für die WAN-Replikation wird asynchrone Replikation verwendet, damit Cache-Vorgänge nicht unter Verzögerungen bei Bridge-Vorgängen leiden.
Warteschlangensicherung: Bei der Bridge handelt es sich um eine Cluster-Warteschlange mit mehreren Knoten, in der ein Knoten aktiv und der andere passiv ist und über ein Backup der aktiven Warteschlange verfügt, um Datenverluste auf der Bridge zu vermeiden.
Verbindungsversuche: Die Bridge versucht außerdem, alle Vorgänge zu replizieren, indem sie es erneut versucht, wenn ein Verbindungsfehler auftritt.
Bridge-Replikator-Warteschlange: Die Größe der Bridge-Replikator-Warteschlange ist in der Cache-Größe enthalten. Wenn der Cache keine Verbindung zur Bridge herstellen kann, werden die Vorgänge im Cache in die Warteschlange gestellt, bis der Cache voll ist. Wenn der Cache voll ist, werden Cache-Elemente entfernt, um Platz für die Vergrößerung der Bridge-Warteschlange zu schaffen.
Zwischenspeicher: Sie können jede Topologie für Cluster-Caches verwenden, die Teil der Bridge sein werden. Sie können auch an jedem Standort in einer Bridge unterschiedliche Topologie-Caches verwenden. Es wird jedoch dringend empfohlen, auf beiden Seiten die gleiche Topologie zu verwenden.
Cache-Synchronisierungsmodi für die Georeplikation
Das NCache Mit Bridge können mehrere Caches verbunden sein, und Sie können dem Cache einen der folgenden Synchronisierungsmodi für die Notfallwiederherstellung bereitstellen:
Aktiver Cache:
Ein aktiver Cache kann eine beliebige Topologie aufweisen, bei der alle Clients eine Verbindung herstellen und Lese- und Schreibvorgänge ausführen, die über eine Brücke zu den anderen verbundenen Caches repliziert werden.Passiver Cache:
Ein passiver Cache kann eine beliebige Topologie haben, es wird jedoch empfohlen, dass er mit einem aktiven Cache identisch ist. Allerdings werden alle auf dem aktiven Cache ausgeführten Vorgänge auf den passiven Cache repliziert. Clients können eine Verbindung zum passiven Cache herstellen und sowohl Lese- als auch Schreibvorgänge ausführen, diese Vorgänge werden jedoch nicht auf den aktiven Cache repliziert. Bei Bedarf können Änderungen am passiven Cache vorgenommen werden.Wenn die aktive Site aus irgendeinem Grund ausfällt, können Sie Ihre Anfragen auf Ihre passive Site umleiten, indem Sie sie aktivieren. Ihre passive Site verhält sich wie aktiv und verarbeitet alle Anfragen ohne Fehler.
Wenn Ihre alte aktive Site bereit und neu gestartet ist, können Sie Ihre Konfiguration wie zuvor ändern. Machen Sie beide Sites aktiv und dadurch werden alle Daten von der alten passiven auf die alte aktive Site übertragen. Wenn alle Daten übertragen sind, können Sie Konfigurationen an Ihrer passiven Site vornehmen und alle Anfragen an die aktive Site umleiten.
Bei der Kommunikation zwischen zwei aktiven Caches können dieselben zwischengespeicherten Daten in beiden Caches fast gleichzeitig aktualisiert werden, was zu einem Konflikt führt. Um diesen Konflikt zu lösen, NCache Bietet eine konfigurierbare Konfliktlöser Dadurch wird der Betriebskonflikt zur Bridge-Zeit gelöst. Standardmäßig „gewinnt“ die letzte Operation und wird im Konfliktfall auf den Cache angewendet.
Wenn eine Site ausfällt, können Sie alle Anfragen an andere aktive Sites umleiten. Wenn die heruntergefahrene Site wieder verfügbar ist, werden Daten von der bereits aktiven Site an diese Site übertragen und können die Anfrage dieser Region an diese Site umleiten.
Note
Um Probleme zu vermeiden, wird empfohlen, dass die Caches bis auf die Topologie dieselben Konfigurationen aufweisen. Wenn die Datenquelle beispielsweise in einem Cache konfiguriert ist, sollten Sie sie auch im anderen Cache konfigurieren. Dies liegt daran, dass dieselben Betriebsspezifikationen aus dem Cache einer Site auf die andere Site repliziert werden.
Staatliche Übertragung
Eine Statusübertragung zwischen zwei Caches kann manuell ausgelöst werden, wenn Sie den Status des Quellcaches mit dem Zielcache synchronisieren möchten. Dies geschieht über eine Brücke.
Die Zustandsübertragungsoperationen werden am Cache-Ende in eine Warteschlange gestellt, und sobald es sich mit der Brücke verbindet, beginnt es, seine Operationen an die Brücke zu senden, die an den Ziel-Cache weitergeleitet werden. Sobald eine Zustandsübertragung zwischen den Caches initiiert wurde, können Sie keine weitere Zustandsübertragung initiieren – um die Stabilität des Systems zu gewährleisten.
Fall 1: Cache in der Statusübertragung tritt auf:
Wenn zwischen Cache A und Cache B eine Statusübertragung läuft, fällt Cache A aus und kommt nicht zurück. Da sich die Brücke im Statustransfer befindet, kann jeder andere eingehende Statustransferantrag aus diesem Grund abgelehnt werden. Um diesem Umstand Rechnung zu tragen, ermittelt die Bridge auf intelligente Weise, ob sie nach einem bestimmten Intervall den Empfang der Vorgänge aus Cache A eingestellt hat. Somit gilt diese Statusübertragung als beschädigt und die Bridge lässt die neue Statusübertragungsanforderung zu.
Fall 2: Cache und Bridge haben einen Netzwerkfehler, trennen sich aber nicht:
Falls bei der Cache- und Bridge-Verbindung ein Netzwerkfehler auftritt und die Verbindung teilweise unterbrochen ist, sind die Betriebs- und Statusübertragungswarteschlangen weiterhin intakt. Daher kann die Zustandsübertragung wieder aufgenommen werden, da keine Vorgänge verloren gegangen sind.
Bridge-Warteschlangen
Cache A ist der aktive Cache, während Cache B passiv ist. Cache A sendet Vorgänge über die Bridge an Cache B, aber Cache B fällt für einige Zeit aus. Dies bedeutet, dass sich die Bridge-Warteschlange durch von Cache A gesendete Vorgänge füllt, aber nicht aus der Warteschlange entfernt wird, da Cache B ausgefallen ist. Irgendwann wird die Bridge-Warteschlange vollständig gefüllt sein und keinen Platz mehr zum Speichern weiterer Vorgänge haben. Daher weist es Cache A an, die Vorgänge an seinem Ende zu halten, bis etwas Platz vorhanden ist. Die Vorgänge werden dann nur am Cache-Ende in die Warteschlange gestellt. Nehmen wir an, dass Cache B wieder hochgefahren wird und die Bridge-Replikator-Warteschlange beginnt, die Vorgänge an ihn zu senden, und somit aus der Warteschlange entfernt wird. Sobald eine konfigurierbare Menge an Speicherplatz (standardmäßig 20 MB) freigegeben ist, teilt die Bridge Cache A mit, dass sie nun ihre in der Warteschlange befindlichen Vorgänge senden kann.
Falls sich die Cache-Warteschlange jedoch füllt und die Räumung aktiviert ist, entfernt der Cache seine zwischengespeicherten Elemente, jedoch nicht die Vorgänge in der Warteschlange. Dies verhindert Betriebsausfälle.
Siehe auch
Cache-Topologien
Cache-Cluster
Lokaler Cache
Cache-Client
Client-Cache