Kategorie:StandBy: Unterschied zwischen den Versionen

Version vom 3. November 2009, 13:17 Uhr

IES StandBy (IES Backup) (ab Version 2.1.1)

Konzept

Ein IES StandBy System kann für unterschiedliche Anforderungen auf unterschiedliche Weise umgesetzt werden. Nach allgemeiner Definition spricht man häufig von Warm-/Hot-StandBy und Cold-StandBy. Dabei beschreibt das Hot-StandBy eine Technologie, mit deren Hilfe ein IES-System hochverfügbar gehalten werden könnten. Speziell bei Einsatz des IES gibt es aber noch zwei weitere StandBy-Varianten für spezielle Anforderungen:

Manual-StandBy
ReadOnly-StandBy

Technische Voraussetzungen

Da das IES StandBy auf den binären Logs von MySQL basiert sind auf dem Master-System noch folgende Konfigurationen vorzunehmen:

log_bin: muss aktiviert sein
server-id: muss auf einen Wert >1 gesetzt sein

StandBy für ein IES-Testsystem (Manual-StandBy)

Ein IES-Testsystem wird häufig bei komplexen Systemen installiert, um Weiterentwicklungen und Anpassungen zunächst mit aktuellen Daten zu testen. Auch für Schulungszwecke wird häufig ein solches Testsystem installiert. Hierzu wird ein paralleler IES installiert, der über eine nahezu identische Konfiguration verfügt. Dann werden die Daten des Master-Systems eingespielt. Dabei gibt es zwei unterschiedliche Ansätze:

regelmäßige Synchronisation: z.B. einmal wöchentlich werden alle Daten des Testsystems durch aktuelle Daten des Master-Systems ersetzt. Nicht gesicherte Templates oder Eingaben gehen hierbei bewusst verloren.
manuelle Synchronisation: durch einen Administrator wird zu einem beliebigen Zeitpunkt der Datenstand des Master-Systems auf das Testsystem übertragen. Anschließend werden Entwicklungen durchgeführt und getestet. Nach Abschluss der Arbeiten werden die Anpassungen manuell in das Master-System übernommen. Bei der nächsten manuellen Übertragung werden wieder alle Daten überschrieben

Der Vorteil dieser Vorgehensweisen mit einem Testsystem ist, dass nicht zu viel Müll entsteht, dass die Weiterentwicklungen und Tests aussagekräftig bzgl. der Auswirkungen auf den Master sind und dass das Master-System nicht beeinträchtigt wird.

Der Nachteil ist, dass alle Arbeiten auf dem Testsystem selbständig (u.U. regelmäßig) gesichert werden müssen. Beispielsweise über XIP-Exporte aller neuen oder geänderten Elemente.

Vorgehen für die Synchronisation:

Das IES-Backup-Verzeichnis des Master-Systems wird transparent über das Netzwerk auf dem StandBy-System eingebunden
Der Master generiert in regelmäßigen Zyklen automatisch Snapshots
Das StandBy-System importiert (u.U. automatisch in regelmäßigen Zyklen) den jeweils letzten Snapshot

Folgende Punkte sind dabei zu beachten:

Das Master-System legt während des Backups/Snapshots ein Lock-File an ($SITEPARK_BACKUP/.iesadmin_backup.lock). Dieses wird beim Einspielen ausgewertet, damit nicht parallel neue Backups erstellt werden können.
Das StandBy-System würde jedes Recover mit dem Einspielen des vollständigen Dumps beginnen. Das führt u.U. zu einer hohen Last.
Das StandBy-System würde die Datei mit den Backup-Definitionen schreiben. Das hat indirekt auch Einfluss auf die Routinen des Master-Systems

Der Aufruf auf dem StandBy-System könnte wie folgt aussehen:

iesadmin recover <client> -d /network/sitepark/backup current

StandBy für ein IES-Liveabfragen (ReadOnly-StandBy)

Ein StandBy-System, welches unabhängig vom Master-System für Webzugriffe über Live-Abfragen verwendet werden soll, lässt sich mit den aktuellen Mechanismen noch nicht sinnvoll abbilden. Eine Synchronisation hätte immer auch eine - vermutlich kurze - Deaktivierungsphase zur Folge. Das ist Live-Abfragen problematisch. Daher dürfte die Synchronisation auch nicht in den normalen Betriebszeiten erfolgen. Diese Anforderung lässt sich am besten über Funktionen wie Lucene-Indices sinnvoll lösen. Um dennoch ein solches ReadOnly-StandBy-System zu realisieren, müssen noch Erweiterungen am IES vorgenommen werden. Ein Mandant müsste dafür in einem Read-Only-Mode betrieben werden. Das gilt sowohl für Redakteur, als auch für die Schnittstellen (z.B. XIP) und die Services (z.B. ConterService). Der Read-Only-Mode hätte weiterhin den Vorteil ein Warm-StandBy-System während Wartungsarbeiten als Ausfallsystem für Live-Abfragen zu verwenden. Lediglich Counter würden in dieser Zeit nicht synchronisiert.

StandBy als Notfallsystem (Cold-StandBy)

Ein Cold-StandBy-System sollte stets über (relativ) aktuelle Daten verfügen und bei vollständigem Ausfall des Master-System innerhalb kürzester Zeit dessen Funktionen vollständig übernehmen. Hierfür ist es nicht zwingend notwendig, dass der IES-Prozess gestartet ist. Eine Synchronisation ist somit sehr gut realisierbar, indem alle Daten eines Master-Systems regelmäßig über übliche Mechanismen abgeglichen werden.

Durch Aktivierung eines solchen StandBy-Systems würde dieses zum neuen Master werden. In diesem Fall muss die weitere Synchronisation dauerhaft abgebrochen werden und kann nur durch manuelle Synchronisation (via Vollbackup) mit dem Master-System aufgebaut werden. Entsprechende Tasks (z.B. CRON) müssen deaktiviert werden.

StandBy als Parallelsystem (Hot-StandBy)

Zur Realisierung eines Hot-StandBy-IES-Systems müsste ein Server inkl. aller Konfigurationen synchronisiert werden. Für die schnelle (automatische) Aktivierung wäre es notwendig, dass der IES-Prozess inkl. aller Daten, dem Repository, der Datenbank, der BinDB und der Konfiguration konsistent synchron gehalten würden.

Aktuell gibt es hierfür noch keine technische Lösung.

Diese Kategorie enthält zurzeit keine Seiten oder Medien.

@@ Zeile 1: / Zeile 1: @@
-''IES Standby (noch in der frühen Entwicklungsphase )''
+''IES StandBy (IES Backup) (ab Version 2.1.1)''
 ==Konzept==
-<!--
+Ein ''IES StandBy'' System kann für unterschiedliche Anforderungen auf unterschiedliche Weise umgesetzt werden. Nach allgemeiner Definition spricht man häufig von ''Warm-/Hot-StandBy'' und ''Cold-StandBy''. Dabei beschreibt das ''Hot-StandBy'' eine Technologie, mit deren Hilfe ein IES-System ''hochverfügbar'' gehalten werden könnten.
-Das Konzept zur Realisierung eines ''Warm-StandBy''-Systems basiert auf den Regeln zum [[:Kategorie:Backup| IES Backup]]. Im Prinzip gibt es ein System, welches für unterschiedliche Mandanten als sog. ''Warm-StandBy''-System agiert. Das bedeutet, dass dort alle Daten eines ''Master''-Systems regelmäßig synchronisiert werden. Dieses ''Warm-StandBy''-System kann zwar gestartet sein, aber die entsprechenden Mandanten müssen deaktiviert sein, da sonst Inkonsistenten auf Datenbank-Ebene entstehen würden.
+Speziell bei Einsatz des IES gibt es aber noch zwei weitere StandBy-Varianten für spezielle Anforderungen:
-Im Bedarfsfall (z.B. Ausfall des ''Master''-Systems, oder umfangreiche Wartungsarbeiten) kann das ''Warm-StandBy''-System (z.B. über Änderung des NATing) verwendet werden. Dabei sind jedoch die entsprechenden Mandanten zu aktivieren.
+# Manual-StandBy
--->
+# ReadOnly-StandBy
-''IES StandBy'' Mechanismen sind jedoch noch in der frühen Entwicklungsphase.
@@ Zeile 14: / Zeile 12: @@
 ;<code>log_bin</code>: muss aktiviert sein
 ;<code>server-id</code>: muss auf einen Wert >1 gesetzt sein
-;<code>expire_logs_days</code>: sollte gesetzt sein (siehe [[:Kategorie:StandBy#StandBy als Notfallsystem|StandBy als Notfallsystem]])
@@ Zeile 46: / Zeile 43: @@
 Um dennoch ein solches ''ReadOnly-StandBy''-System zu realisieren, müssen noch Erweiterungen am IES vorgenommen werden. Ein Mandant müsste dafür in einem Read-Only-Mode betrieben werden. Das gilt sowohl für Redakteur, als auch für die Schnittstellen (z.B. XIP) und die Services (z.B. ConterService). Der Read-Only-Mode hätte weiterhin den Vorteil ein ''Warm-StandBy''-System während Wartungsarbeiten als Ausfallsystem für Live-Abfragen zu verwenden. Lediglich Counter würden in dieser Zeit nicht synchronisiert.
-<!--
 ==StandBy als Notfallsystem (Cold-StandBy)==
-Ein klassisches StandBy-System sollte stets über aktuelle Daten verfügen und bei vollständigem Ausfall des Master-System innerhalb kürzester Zeit dessen Funktionen vollständig übernehmen. Durch Aktivierung eines solchen StandBy-Systems würde dieses zum neuen Master werden. In diesem Fall wird die weitere Synchronisation dauerhaft abgebrochen und kann nur durch manuelle Synchronisation (via Vollbackup) mit dem ''Master''-System aufgebaut werden. Entsprechende Tasks (z.B. CRON) müssen deaktiviert werden.
+Ein ''Cold-StandBy''-System sollte stets über (relativ) aktuelle Daten verfügen und bei vollständigem Ausfall des Master-System innerhalb kürzester Zeit dessen Funktionen vollständig übernehmen. Hierfür ist es nicht zwingend notwendig, dass der IES-Prozess gestartet ist. Eine Synchronisation ist somit sehr gut realisierbar, indem alle Daten eines ''Master''-Systems regelmäßig über übliche Mechanismen abgeglichen werden.
-Da bei dieser Form des StandBy Backups des Masters '''nicht''' vorausgesetzt werden, ist es zwingend erforderlich, dass das Master-System für BINLOGs konfiguriert wurde. Details hierzu finden Sie unter [[:Kategorie:Backup|Backup]]. Wird auf dem Master-System ein regelmäßiges Backup über den IES betrieben, dürfen auf keinen Fall die BINLOGs gelöscht werden. Dies geschieht über die Option <code>-p</code>. Stattdessen ist für den MySQL-Server folgende Setzung vorzunehmen:
- expire_logs_days=xxx
-Wobei hier ein Wert deutlich größer als der Zeitraum zwischen zwei vollständigen Backup sein muss.
-z.B. bei wöchentlichen Backups mit stündlichen Snapshots:
- expire_logs_days=10
-Ein Neustart von MySQL ist nach Änderung natürlich notwendig. (Es gab MySQL-Versionen, in denen diese Einstellung fehlerhaft ausgewertet wurde. Bitte prüfen Sie vor produktiven Einsatz die Funktion)
-Der Wert <code>0</code> deaktiviert diese Funktion. Wenn die Funktion deaktiviert wurde kann man die LogFiles jederzeit manuell über
- mysql -u user -ppassword -E -e "PURGE BINARY LOGS TO 'mysql-bin.010';"
-oder
- mysql -u user -ppassword -E -e "PURGE BINARY LOGS BEFORE '2009-10-01 22:46:26';"
-Es gelten für die Konfiguration dieser StandBy Form folgende Regeln:
-* IES kann gestartet sein, Mandant muss deaktiviert sein
-* In regelmäßigen Abständen werden eigene Snaphot's pro Mandant vom jeweiligen Master ermittelt, übertragen und eingespielt
-# Der Warm-StandBy Server muss sich merken, welcher Stand schon eingespielt wurde
+Durch Aktivierung eines solchen StandBy-Systems würde dieses zum neuen Master werden. In diesem Fall muss die weitere Synchronisation dauerhaft abgebrochen werden und kann nur durch manuelle Synchronisation (via [[:Kategorie:Backup|Vollbackup]]) mit dem ''Master''-System aufgebaut werden. Entsprechende Tasks (z.B. CRON) müssen deaktiviert werden.
-# Es werden entsprechend der konfigurierten Synchronisation die SQL-Statements ermittelt und eingespielt
-# BinDB-Änderungen werden übertragen
-# Mandantenspezifische Konfigurationen werden '''nicht''' aktualisiert (z.B. wg. Änderungen der Publisher und den notwendigen DocumentRoots).
-: Soll die Konfiguration ebenfalls synchronisiert werden, so ist der IES zu stoppen und die entsprechenden Ordner (Konfiguration, DocumentRoots) über übliche Netzwerkmechanismen zu synchronisieren.
-* Alternativ kann das gesamte Verzeichnis <code>$SITEPARK_HOME</code> über Mechanismen wie ''rsync'' synchronisiert werden. Dann ist lediglich die Aktualisierung der Datenbank über regelmäßigen Abständen erforderlich. (Je nach Konfiguration mit oder ohne BinDB)
-'''Bei Update des IES müssen das ''Warm-StandBy''-System ebenfalls aktualisiert werden. In jedem Fall ist aber nach dem Update des ''Master''-Systems und vor dem Update des ''Warm-StandBy''-Systems eine Synchronisation auszuführen, da sonst die SQL-Statements des Updates zu Fehlern führen würden!'''
+==StandBy als Parallelsystem (Hot-StandBy)==
+Zur Realisierung eines ''Hot-StandBy''-IES-Systems müsste ein Server inkl. aller Konfigurationen synchronisiert werden. Für die schnelle (automatische) Aktivierung wäre es notwendig, dass der IES-Prozess inkl. aller Daten, dem Repository, der Datenbank, der BinDB und der Konfiguration konsistent synchron gehalten würden.
-'''Wird das gesamte Verzeichnis <code>$SITEPARK_HOME</code> mit dem ''Warm-StandBy''-System synchronisiert, so ist ein Update des IES nur auf dem ''Master''-System notwendig. Der IES aktualisiert sich dann automatisch und die Datenbank-Anpassungen erfolgen mit der nächsten Synchronisation.'''
+Aktuell gibt es hierfür noch keine technische Lösung.
--->
 <noinclude>
 [[Kategorie:Administration| 300]]
 </noinclude>