Kategorie:StandBy: Unterschied zwischen den Versionen

IES Standby (noch in der frühen Entwicklungsphase )

Konzept

Das Konzept zur Realisierung eines Warm-StandBy-Systems basiert auf den Regeln zum 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. 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.

IES StandBy Mechanismen sind jedoch noch in der frühen Entwicklungsphase.

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

expire_logs_days

sollte gesetzt sein (siehe StandBy als Notfallsystem)

StandBy als Notfallsystem

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.

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 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 -p. 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 0 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';"

StandBy für ein IES-Testsystem

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:

1. 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.
2. 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:

1. 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.
2. Das StandBy-System würde jedes Recover mit dem Einspielen des vollständigen Dumps beginnen. Das führt u.U. zu einer hohen Last.
3. 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

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.