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 Kategorie: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. In diesem Fall wird die weitere Synchronisation dauerhaft abgebrochen und kann nur durch manuelle Synchronisation (via Vollbackup) mit dem Master-System aufgebaut werden. IES StandBy Mechanismen sind jedoch noch in der frühen Entwicklungsphase.

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. 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