Replikation (Computing)

"Replag" leitet hier weiter. Informationen zur Replikationsverzögerung von Wikipedia -Datenbanken finden Sie in Wikipedia: Replag.

Reproduzieren in Computer beinhaltet das Austausch von Informationen, um eine Konsistenz zwischen redundanten Ressourcen zu gewährleisten, wie z. Software oder Hardware- Komponenten, um die Zuverlässigkeit zu verbessern, Fehlertoleranz, oder Zugänglichkeit.

Terminologie

Die Replikation im Computer kann sich beziehen:

  • Datenreplikation, wobei die gleichen Daten auf mehreren gespeichert sind Speichergeräte
  • Berechnungsreplikation, wo die gleiche Computeraufgabe viele Male ausgeführt wird. Berechnungsaufgaben können sein:
    • Im Raum repliziert, wo Aufgaben auf separaten Geräten ausgeführt werden
    • Rechtzeitig repliziert, wo Aufgaben wiederholt auf einem einzigen Gerät ausgeführt werden

Die Replikation im Raum oder in der Zeit wird häufig mit Planungsalgorithmen verknüpft.[1]

Der Zugriff auf eine replizierte Entität ist in der Regel einheitlich mit Zugriff auf eine einzelne nicht replikierte Entität. Die Replikation selbst sollte sein transparent an einen externen Benutzer. In einem Versagenszenario a Failover von Repliken sollten in Bezug auf so weit wie möglich verborgen sein Servicequalität.[2]

Informatiker beschreiben die Replikation weiter als beide:

  • Aktive Replikation, die durch Bearbeitung der gleichen Anfrage bei jeder Replik ausgeführt wird
  • Passive Replikation, bei der die Bearbeitung jeder Anfrage auf einem einzigen Replikum bearbeitet und das Ergebnis auf die anderen Replikate übertragen wird

Wenn eine Anführerin replik Führungswahlen Um alle Anfragen zu verarbeiten, verwendet das System einen Primär-Backup oder Primärreplik Schema, das vorherrscht Hochverfügbarkeitscluster. Im Vergleich dazu verwendet das System, wenn eine Replik eine Anforderung bearbeiten und einen neuen Zustand verteilen kann Multi-Master planen. Im letzteren Fall irgendeine Form von Verteilte Parallelitätskontrolle muss verwendet werden, wie z. Verteilter Lock -Manager.

Lastverteilung Unterscheidet sich von der Aufgabenreplikation, da sie eine Last verschiedener Berechnungen über Maschinen verteilt und eine einzelne Berechnung im Falle eines Ausfalls fallen lassen kann. Lastausgleich verwendet jedoch manchmal die Datenreplikation (insbesondere die Datenreplikation Multi-Master-Replikation) intern, um ihre Daten auf Maschinen zu verteilen.

Backup Unterscheidet sich von der Replikation darin, dass die gespeicherte Kopie der Daten über einen langen Zeitraum unverändert bleibt.[3] Repliken dagegen werden häufig aktualisiert und verlieren schnell jeden historischen Zustand. Die Replikation ist eines der ältesten und wichtigsten Themen im Gesamtbereich von verteilte Systeme.

Datenreplikation und Berechnungsreplikation erfordert beide Prozesse, um eingehende Ereignisse zu verarbeiten. Prozesse für die Datenreplikation sind passiv und arbeiten nur, um die gespeicherten Daten zu verwalten, antworten zu lesen, um Anforderungen zu lesen und Aktualisierungen anzuwenden. Die Rechenreplikation wird normalerweise durchgeführt, um Fehlertoleranz bereitzustellen und einen Betrieb zu übernehmen, wenn eine Komponente fehlschlägt. In beiden Fällen besteht die zugrunde liegende Bedürfnisse darin, sicherzustellen, dass die Repliken dieselben Ereignisse in gleichwertigen Bestellungen erkennen, damit sie in konsistenten Staaten bleiben und jede Replik auf Fragen reagieren kann.

Replikationsmodelle in verteilten Systemen

Es gibt drei weit verbreitete Modelle für die Datenreplikation, die jeweils eigene Eigenschaften und Leistung haben:

  • Transaktionsreplikation: zum Replikieren verwendet Transaktionsdatenwie eine Datenbank. Das Serialisierbarkeit von Einkopien Das Modell wird eingesetzt, das gültige Ergebnisse einer Transaktion auf replizierten Daten gemäß der Gesamtranglage definiert SÄURE (Atomizität, Konsistenz, Isolation, Haltbarkeit) Eigenschaften, die Transaktionssysteme garantieren möchten.
  • Statusmaschinenreplikation: Angenommen, der replizierte Prozess ist a Deterministische endliche Automaten und das atomare Sendung von jeder Veranstaltung ist möglich. Es basiert auf Verteilter Konsens und hat viel gemeinsam mit dem Transaktionsreplikationsmodell. Dies wird manchmal fälschlicherweise als Synonym für aktive Replikation verwendet. Die Replikation des Statusmaschinens wird normalerweise durch ein repliziertes Protokoll implementiert, das aus mehreren nachfolgenden Runden der Paxos -Algorithmus. Dies wurde durch Googles molliges System populär gemacht und ist der Kern hinter der Open-Source Schlüsselspeicherdatenspeicher.[4][5]
  • Virtuelle Synchronität: Beinhaltet eine Gruppe von Prozessen, die zusammenarbeiten, um In-Memory-Daten zu replizieren oder Aktionen zu koordinieren. Das Modell definiert eine verteilte Entität namens a Prozessgruppe. Ein Prozess kann einer Gruppe beitreten und wird mit einem Kontrollpunkt versehen, der den aktuellen Status der von den Gruppenmitgliedern replizierten Daten enthält. Prozesse können dann senden Multicasts an die Gruppe und wird eingehende Multicasts in der identischen Reihenfolge sehen. Änderungen der Mitgliedschaft werden als spezielles Multicast behandelt, der den Prozessen in der Gruppe eine neue "Mitgliedschaftsansicht" bietet.

Datenbankreplikation

Datenbank Replikation kann bei vielen verwendet werden Datenbankmanagementsystem (DBMS), normalerweise mit a Primär/Replik Beziehung zwischen dem Original und den Kopien. Die Primärprotokoll protokolliert die Updates, die dann zu den Repliken durchlaufen. Jedes Replikat gibt eine Nachricht aus, in der besagt, dass sie das Update erfolgreich erhalten hat, wodurch das Senden nachfolgender Aktualisierungen ermöglicht wird.

Im Multi-Master-Replikation, Updates können an jeden Datenbankknoten übermittelt werden und dann an andere Server durchlaufen. Dies ist oft gewünscht, führt jedoch erheblich erhöhte Kosten und Komplexität ein, was es in einigen Situationen unpraktisch macht. Die häufigste Herausforderung, die bei der Replikation von Multi-Master besteht Auflösung. Die meisten synchronen (oder eifrigen) Replikationslösungen führen Konfliktprävention durch, während asynchrone (oder faule) Lösungen Konfliktlösung durchführen müssen. Wenn beispielsweise derselbe Datensatz auf zwei Knoten gleichzeitig geändert wird, würde ein eifriges Replikationssystem den Konflikt erkennen, bevor er das Commit bestätigt und eine der Transaktionen abbricht. EIN faule Replikation System würde beide zulassen Transaktionen eine Konfliktlösung während der Re-Synchronisierung zu begehen und zu führen.[6] Die Lösung eines solchen Konflikts kann auf a beruhen Zeitstempel der Transaktion, auf der Hierarchie der Ursprungsknoten oder auf viel komplexere Logik, die konsistent über alle Knoten entscheidet.

Die Datenbankreplikation wird komplexer, wenn sie skaliert horizontal und vertikal. Das horizontale Scale-up verfügt über mehr Datenreplikate, während vertikales Skala Datenreplikas in größeren physikalischen Entfernungen aufweist. Probleme, die durch horizontale Skalierung aufgeworfen werden Protokoll. Die frühen Probleme des vertikalen Scale-ups wurden größtenteils durch die Verbesserung des Internets angegangen Verlässlichkeit und Leistung.[7][8]

Wenn Daten zwischen Datenbankservern repliziert werden, so dass die Informationen im gesamten Datenbanksystem konsistent bleiben und Benutzer nicht mitteilen oder sogar wissen können, welchen Server in den DBMs sie verwenden, soll das System Replikationstransparenz aufweisen.

Replikationstransparenz kann jedoch nicht immer erreicht werden. Wenn Daten in einer Datenbank repliziert werden, werden sie durch eingeschränkt Cap -Theorem oder Pincelc Theorem. In der NOSQL -Bewegung wird die Datenkonsistenz normalerweise im Austausch gegen andere gewünschte Eigenschaften wie Verfügbarkeit (a), Partitionstoleranz (P) usw. geopfert Datenkonsistenzmodelle wurden auch entwickelt, um als Service Level Agreement (SLA) zwischen Dienstleister und Benutzern zu dienen.

Datenträgerspeicherreplikation

Speicherreplikation

Aktive (Echtzeit-) Speicherreplikation wird normalerweise durch Verteilung von Aktualisierungen von a implementiert Blockgerät zu mehreren physischen Festplatten. Auf diese Weise alle Dateisystem unterstützt von der Betriebssystem Kann ohne Änderung repliziert werden, da der Dateisystemcode auf einer Ebene über der Block -Gerätetreiberschicht funktioniert. Es wird entweder in Hardware (in a Disk -Array -Controller) oder in Software (in a Gerätetreiber).

Die grundlegendste Methode ist Speicherspiegelung, was typisch für lokal verbundene Scheiben ist. Die Speicherbranche verengt die Definitionen so Spiegelung ist eine lokale (Kurzstrecken-) Operation. Eine Replikation ist über a hinweg erweiterbar Computernetzwerk, so dass sich die Festplatten an physikalisch entfernten Stellen befinden können und das primäre/replikatliche Datenbankreplikationsmodell normalerweise angewendet wird. Der Zweck der Replikation besteht darin, Schäden durch Fehler zu verhindern oder Katastrophen Dies kann an einem Ort auftreten - oder falls solche Ereignisse auftreten, um die Fähigkeit zur Wiederherstellung von Daten zu verbessern. Für die Replikation ist Latenz der Schlüsselfaktor, da sie entweder feststellt, wie weit die Standorte voneinander entfernt sein können oder welche Art der Replikation verwendet werden kann.

Das Hauptmerkmal einer solchen Cross-Site-Replikation ist, wie Schreibvorgänge entweder durch asynchrone oder synchrone Replikation behandelt werden. Die synchrone Replikation muss auf die Antwort des Zielservers in einer Schreibvorlage warten, während die asynchrone Replikation dies nicht tut.

Synchron Die Replikation garantiert "Null -Datenverlust" mithilfe der Wege von Atomic Schreibvorgänge, bei denen der Schreibvorgang erst von der lokalen und entfernten Speicherung als vollständig angesehen wird. Die meisten Anwendungen warten, bis eine Schreibtransaktion abgeschlossen ist, bevor sie mit weiteren Arbeiten fortfahren, weshalb die Gesamtleistung erheblich abnimmt. Inhärent sinkt die Leistung mindestens proportional zur Entfernung Latenz wird diktiert von der Lichtgeschwindigkeit. Für 10 km Entfernung dauert der schnellstmögliche Roundtrip 67 μs, während eine gesamte lokale zwischengespeicherte Schreiben in etwa 10–20 μs abgeschlossen ist.

Im asynchron Replikation wird der Schreibvorgang als vollständig angesehen, sobald lokaler Speicher dies anerkennt. Remote -Speicher wird mit einem kleinen aktualisiert Verzögerung. Die Leistung wird stark erhöht, aber bei einem lokalen Speicherausfall ist der Fernspeicher nicht garantiert die aktuelle Kopie der Daten (die neuesten Daten können verloren gehen).

Semi-Synchronous Replication berücksichtigt in der Regel einen Schreibvorgang, wenn er durch lokale Speicherung bestätigt und vom Remote-Server empfangen oder protokolliert wird. Das tatsächliche Fernschreiben wird asynchron durchgeführt, was zu einer besseren Leistung führt, aber die Fernbedienung wird hinter dem lokalen Speicher zurückbleiben, so dass bei lokalem Speicherausfall keine Garantie für die Haltbarkeit (d. H. Nahtloser Transparenz) besteht.

Die Replikation der Punkte in der Zeit erzeugt regelmäßig Schnappschüsse die anstelle von primärem Speicher repliziert werden. Dies soll nur die geänderten Daten anstelle des gesamten Volumens replizieren. Da weniger Informationen unter Verwendung dieser Methode repliziert werden, kann die Replikation über weniger teurere Bandbreitenverbindungen wie ISCSI oder T1 anstelle von fiberoptischen Linien auftreten.

Implementierungen

Hauptartikel: verteilte fehlertolerante Dateisysteme und verteilte parallel fehlertolerante Dateisysteme verteilt

Viele verteilte Dateisysteme Verwenden Sie die Replikation, um eine Fehlertoleranz zu gewährleisten und einen einzelnen Fehlerpunkt zu vermeiden.

Viele kommerzielle synchrone Replikationssysteme frieren nicht ein, wenn die Fernbedienung fehlschlägt oder an Verbindung verliert - Verhalten, das keinen Datenverlust garantiert - jedoch vor Ort arbeiten und die gewünschte Null verlieren Wiederherstellungspunktziel.

Techniken von WAN-Optimierung in großer Fläche (WAN) kann angewendet werden, um die durch die Latenz auferlegten Grenzen anzugehen.

Dateibasierte Replikation

Die Dateibasierte Replikation führt die Datenreplikation auf logischer Ebene (d. H. Einzelpersonen) und nicht auf der Speicherblockebene durch. Es gibt viele verschiedene Möglichkeiten, dies auszuführen, die fast ausschließlich auf Software beruhen.

Erfassen Sie mit einem Kernelfahrer

A Kernelfahrer (speziell a Filtertreiber) kann verwendet werden, um Aufrufe der Dateisystemfunktionen abzufangen und jede Aktivität so erfassen, wie sie auftritt. Dies verwendet dieselbe Art von Technologie wie Echtzeit aktive Virus-Checker. Auf dieser Ebene werden logische Dateivorgänge wie geöffnet, schreiben, schriftlich, löschen usw. erfasst. Der Kernel -Treiber überträgt diese Befehle in einen anderen Prozess, im Allgemeinen über ein Netzwerk in ein anderes Gerät, das die Operationen der Quellmaschine nachahmt. Wie die Speicherreplikation auf Blockebene ermöglicht die Replikation auf Dateiebene sowohl synchrone als auch asynchrone Modi. Im synchronen Modus werden Schreibvorgänge auf der Quellmaschine gehalten und erst dann auftreten, wenn die Zielmaschine die erfolgreiche Replikation bestätigt hat. Der Synchronmodus ist bei Produkte von Dateireplikation seltener, obwohl einige Lösungen vorhanden sind.

Replikationslösungen auf Dateiebene ermöglichen fundierte Entscheidungen über die Replikation basierend auf dem Speicherort und dem Typ der Datei. Beispielsweise könnten temporäre Dateien oder Teile eines Dateisystems, das keinen geschäftlichen Wert enthält, ausgeschlossen werden. Die übertragenen Daten können auch körniger sein; Wenn eine Anwendung 100 Bytes schreibt, werden nur die 100 Bytes anstelle eines vollständigen Festplattenblocks (im Allgemeinen 4.096 Bytes) übertragen. Dies reduziert die vom Quellmaschine gesendete Datenmenge und die Speicherbelastung auf der Zielmaschine erheblich.

Die Nachteile dieser Nur-Software-Lösung umfassen die Anforderung für die Implementierung und Wartung auf der Ebene des Betriebssystems sowie eine erhöhte Belastung der Verarbeitungsleistung der Maschine.

Replikation des Dateisystemjournals

Ähnlich wie bei der Datenbank Transaktionsprotokolle, viele Dateisysteme die Fähigkeit haben Tagebuch ihre Aktivität. Das Journal kann entweder regelmäßig oder in Echtzeit durch Streaming an eine andere Maschine gesendet werden. Auf der Replik -Seite kann das Journal verwendet werden, um Dateisystemänderungen abzuspielen.

Eine der bemerkenswerten Implementierungen ist Microsoft's System Center Data Protection Manager (DPM), veröffentlicht im Jahr 2005, das regelmäßige Updates durchführt, aber keine Replikation in Echtzeit bietet.

Batch -Replikation

Dies ist der Prozess des Vergleichs der Quell- und Zieldateisysteme und der Sicherstellung, dass das Ziel der Quelle übereinstimmt. Der Hauptvorteil ist, dass solche Lösungen im Allgemeinen kostenlos oder kostengünstig sind. Der Nachteil ist, dass der Prozess der Synchronisierung sehr systemintensiv ist, und folglich läuft dieser Prozess im Allgemeinen selten.

Eine der bemerkenswerten Implementierungen ist rsync.

Replikation in der Datei

In einem Paging Betriebssystem, Seiten in einer Paging -Datei werden manchmal innerhalb einer Spur repliziert, um die Rotationslatenz zu verringern.

Im IBM's Vsam, Indexdaten werden manchmal innerhalb einer Spur repliziert, um die Rotationslatenz zu verringern.

Verteilte gemeinsame Speicherreplikation

Ein weiteres Beispiel für die Verwendung der Replikation erscheint in verteilter gemeinsamer Speicher Systeme, wo viele Knoten des Systems gleich teilen Seite des Gedächtnisses. Dies bedeutet normalerweise, dass jeder Knoten eine separate Kopie (Replik) dieser Seite hat.

Primär-Backup- und Multi-Primary-Replikation

Viele klassische Replikationsansätze basieren auf einem Primär-Backup-Modell, bei dem ein Gerät oder ein einseitiger Kontrolle über ein oder mehrere andere Prozesse oder Geräte einseitig steuern. Beispielsweise kann die Primärberechnung eine Berechnung durchführen und ein Protokoll von Aktualisierungen in einen Backup -Prozess (Standby) gestreamt werden, der dann übernehmen kann, wenn der Primär fehlschlägt. Dieser Ansatz ist üblich, um Datenbanken zu replizieren, trotz des Risikos, dass, wenn ein Teil des Protokolls während eines Fehlers verloren geht, die Sicherung möglicherweise nicht in einem Zustand ist, der mit der Primäranlage identisch ist, und Transaktionen dann verloren gehen können.

Eine Schwäche von Primär-Backup-Schemata ist, dass nur einer tatsächlich Operationen ausführt. Die Fehlertoleranz wird gewonnen, aber das identische Sicherungssystem verdoppelt die Kosten. Aus diesem Grund beginnen c.1985Die verteilte Systemforschungsgemeinschaft begann, alternative Methoden zur Replikation von Daten zu untersuchen. Ein Ergebnis dieser Arbeit war die Entstehung von Schemata, in denen eine Gruppe von Repliken zusammenarbeiten konnte, wobei jeder Prozess als Backup fungierte und gleichzeitig einen Anteil der Arbeitsbelastung abwickelte.

Informatiker Jim Gray Analysierte multiprimäre Replikationsschemata im Rahmen des Transaktionsmodells und veröffentlichte einen weit verbreiteten Papier, das den Ansatz "die Gefahren der Replikation und eine Lösung" skeptisch gegenüber dem Ansatz skeptisch war.[9][10] Er argumentierte, dass die Datenbank nicht auf natürliche Weise auf natürliche Weise spaltet, sodass die Datenbank als behandelt werden kann n n Disjunkte Unterdaten, Konflikte zur Kontrolle von Gleichzeitberufen führen zu einer ernsthaften Leistung und die Gruppe der Repliken wird wahrscheinlich in Abhängigkeit von der Funktion von verlangsamt n. Gray schlug vor, dass die häufigsten Ansätze wahrscheinlich zu einer Verschlechterung führen, die als Skala als Skala führen O (n³). Seine Lösung, die die Daten unterteilt, ist in Situationen, in denen Daten tatsächlich einen natürlichen Trennungsschlüssel haben, nur praktikabel.

In den Jahren 1985–1987 die Virtuelle Synchronität Das Modell wurde vorgeschlagen und als weit verbreiteter Standard entwickelt (es wurde im ISIS -Toolkit, Horus, Transis, Ensemble, Totem, verwendet, Totem, Verbreiten, C-Ensemble-, Phoenix- und Quicksilver-Systeme, und ist die Grundlage für die Corba Fehlertolerantes Computerstandard). Die virtuelle Synchronität ermöglicht einen multi-primären Ansatz, bei dem eine Gruppe von Prozessen kooperiert, um einige Aspekte der Anfrageverarbeitung parallelisieren zu können. Das Schema kann nur für einige Formen von In-Memory-Daten verwendet werden, kann jedoch lineare Beschleunigungen in der Größe der Gruppe bereitstellen.

Eine Reihe moderner Produkte unterstützen ähnliche Systeme. Zum Beispiel unterstützt das Spread Toolkit dasselbe virtuelle Synchronitätsmodell und kann verwendet werden, um ein multiprimäres Replikationsschema zu implementieren. Es wäre auch möglich, C-Ensemble oder Quicksilver auf diese Weise zu verwenden. Wandisco Ermöglicht eine aktive Replikation, bei der jeder Knoten in einem Netzwerk eine genaue Kopie oder Replik ist und daher jeder Knoten im Netzwerk gleichzeitig aktiv ist. Dieses Schema ist für die Verwendung in a optimiert Weitgebietsnetzwerk (Wan).

Siehe auch

Verweise

  1. ^ Mansouri, Najme, Gholam, Hosein Dastghaibyfard und Ehsan Mansouri. "Kombination aus Datenreplikations- und Planungsalgorithmus zur Verbesserung der Datenverfügbarkeit in Datengittern", Journal of Network- und Computeranwendungen (2013)
  2. ^ V. Andronikou, K. Mamouras, K. Tserpes, D. Kyrizis, T. Varvarigou, "Dynamic QoS-Awesare-Datenreplikation in Gitterumgebungen", Elsevier Future Generation Computer Systems - Das Internationale Journal of Grid Computing und Escience, 2012
  3. ^ "Backup und Replikation: Was ist der Unterschied?". Zerto. 6. Februar 2012.
  4. ^ Marton Trencseni, Attila Gazso (2009). "Keyspace: Ein konsequent replizierter, hochversäumter Schlüsselwertgeschäft". Abgerufen 2010-04-18.
  5. ^ Mike Burrows (2006). "Der mollige Schlossdienst für lose gekoppelte verteilte Systeme". Archiviert von das Original Am 2010-02-09. Abgerufen 2010-04-18.
  6. ^ "Replikation - Konfliktlösung". ITTIA DB SQL ™ Benutzerhandbuch. Ittia L.L.C. Archiviert von das Original am 24. November 2018. Abgerufen 21. Oktober 2016.
  7. ^ Dragan Simic; Srecko Ristic; Slobodan Obradovic (April 2007). "Messung der erreichten Leistungsniveaus der Webanwendungen mit verteilter relationaler Datenbank" (PDF). Elektronik und Energetik. Fakta Universitatis. p. 31–43. Abgerufen 30. Januar 2014.
  8. ^ Mokadem Riad; Hameurlain Abdelkader (Dezember 2014). "Datenreplikationsstrategien mit Leistungsziel in Datengittersystemen: Eine Umfrage" (PDF). Internes Journal of Grid and Utility Computing. Unterstrichverlag. p. 30–46. Abgerufen 18. Dezember 2014.
  9. ^ "Die Gefahren der Replikation und einer Lösung"
  10. ^ Proceedings der ACM Sigmod Internationalen Konferenz von 1999 zum Management von Daten: Sigmod '99, Philadelphia, PA, USA; 1. bis 3. Juni 1999, Band 28; p. 3.