Kategorie:StandBy

IES Standby (noch in der frühen Entwicklungsphase )

Konzept

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

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