Kategorie:StandBy: Unterschied zwischen den Versionen

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:

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

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.

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.