Cloud CMS: 4 Möglichkeiten für den Einsatz von Magnolia in der Cloud

Viele Unternehmen erwägen, sich von vor Ort installierten Content-Management-Softwarepaketen zu lösen und auf Cloud-basierte Lösungen umzusteigen. Mit Cloud-basierten CMS-Systemen können Nutzer Zeit und Geld bei der Bereitstellung sparen, die Zusammenarbeit zwischen Entwicklern und Inhaltsanbietern verbessern und den Nutzern eine zukunftssichere Lösung für die Probleme der sich weiterentwickelnden Technologien bieten.

Magnolia CMS und Amazon Web Services (AWS) bieten vier Methoden an, mit denen Sie beim Wechsel zu einer Cloud-Content-Management-Lösung optimale Einsatzbedingungen und eine nahtlose Integration mit Ihren bestehenden Systemen erreichen können.

Der Betrieb von Magnolia auf einer Cloud-Plattform unterscheidet sich nicht allzu sehr vom Betrieb von Magnolia vor Ort. Wenn Sie jedoch die leistungsstarken Funktionen von AWS zur automatischen Skalierung und Selbstheilung nutzen möchten, müssen Sie die Schritte zum Hochfahren einer neuen Magnolia-Instanz und zur Synchronisierung ihrer Inhalte mit anderen laufenden Magnolia-Instanzen automatisieren. Es gibt eine Reihe von Möglichkeiten, wie Sie dies auf AWS tun können, jede mit Vor- und Nachteilen.

Die Standard-CMS-Bereitstellungsoption funktioniert sowohl mit AWS als auch mit anderen Cloud-Anbietern. Bei dieser Option wird die Standard-Magnolia-Architektur verwendet, bei der die öffentlichen Magnolia-Instanzen bei der Magnolia-Autoreninstanz registriert sind. In dieser Struktur verwendet die Magnolia-Autoreninstanz die transaktionale Veröffentlichung, um neue Inhalte vom Inhaltsanbieter an die öffentlichen Magnolia-Instanzen zu übertragen.

Sie haben mehrere Möglichkeiten, die Inhalte einer neu gestarteten Magnolia Public Instanz zu synchronisieren. Sie können ein mit dem Magnolia-Backup-Modul erstelltes Backup wiederherstellen oder ein Backup der Datenbank und des Dateisystems des JCR-Repositorys wiederherstellen. Sie können die Inhalte des Magnolia-Autors mit dem Magnolia-Synchronisierungsmodul auf die neue öffentliche Instanz synchronisieren. Welche Lösung Sie wählen, hängt davon ab, wie viele Inhalte synchronisiert werden müssen und wie oft sie geändert oder aktualisiert werden. Sie können sogar mehrere Lösungen kombinieren: den Großteil der Inhalte aus einem Backup wiederherstellen und alle Inhalte, die seit der Erstellung des Backups geändert wurden, mit dem Magnolia-Synchronisationsmodul aktualisieren.

Diese Option minimiert die Anzahl der Magnolia-Server, die für die Bereitstellung des CMS benötigt werden, was bedeutet, dass keine Standby-Magnolia-Instanzen erforderlich sind. Obwohl die Einrichtung einer neuen öffentlichen Magnolia-Instanz einen gewissen zusätzlichen Aufwand erfordert, gibt es eine Reihe von Möglichkeiten, mit Situationen der automatischen Skalierung umzugehen.

Andererseits kann es riskant sein, eine aktive öffentliche Magnolia-Instanz, die den Datenverkehr bedient, für ein Backup zu verwenden. Wenn die Last auf einer der öffentlichen Instanzen zu hoch wird, kann die Durchführung eines Backups auf der Instanz dazu führen, dass sie nicht mehr reagiert. In diesem Fall kann die automatische Skalierung von AWS eine andere EC2-Instanz erstellen, um sie zu ersetzen, was zu einer Reihe von Ausfällen führen kann, die katastrophale Ausmaße annehmen können.

Die Standardverteilungsoption kann bei der Durchführung einer Sicherung zu Lastproblemen führen. Die Verwendung eines Content-Source-Targets kann diese Lastprobleme jedoch lindern. Das Content-Source-Target, eine Art öffentliche Magnolia-Instanz, die als Abonnent bei der Magnolia-Autoreninstanz registriert ist, bedient nur Anfragen, die innerhalb des privaten Subnetzes gestellt werden, in dem es sich befindet, und verringert so die Wahrscheinlichkeit, dass ein Backup fehlschlägt.

Für die Synchronisierung der Inhalte auf einer neuen öffentlichen Magnolia-Instanz haben Sie die gleichen Möglichkeiten wie bei Option 1. Mit dem Ziel der Inhaltsquelle können Sie nun jedoch zuverlässig und sicher Backups erstellen, ohne die öffentlichen Magnolia-Instanzen zu beeinträchtigen, die Ihre Inhalte bereitstellen.

Der Hauptvorteil dieser Option besteht darin, dass die Wahrscheinlichkeit, dass ein Backup während der automatischen Skalierung fehlschlägt, reduziert oder eliminiert wird. Die Verwendung eines Content-Source-Ziels stellt sicher, dass der Content-Backup-Prozess von der Erstellung einer neuen Magnolia-Instanz getrennt ist. Diese Robustheit eliminiert auch die Möglichkeit eines kaskadierenden Fehlers, da das Content-Source-Ziel von der Auto-Scaling-Gruppe für öffentliche Magnolia-Instanzen getrennt ist.

Die Verwendung eines Inhaltsquellen-Ziels für die Verwaltung von Backups schafft eine einzige Fehlerquelle für die automatische Skalierung. Wenn das Sicherungsziel aus irgendeinem Grund nicht verfügbar wäre, würde der Sicherungsprozess ebenso wie der Auto-Scaling-Prozess fehlschlagen. Außerdem könnte der Prozess der Wiederherstellung einer Sicherung aus dem Inhaltsquellziel mit einem großen Inhalts-Repository die maximale Ausführungszeit für eine AWS Lambda-Funktion überschreiten.

Diese Option nutzt das JCR-Clustering, um die Probleme zu umgehen, die mit der Synchronisierung der Inhalte auf einer neuen öffentlichen Magnolia-Instanz verbunden sind. Wenn die Magnolia-Instanzen ein geclustertes JCR-Repository gemeinsam nutzen, ist der gesamte Inhalt bereits im gemeinsamen JCR-Repository verfügbar. Bei einer Magnolia-Installation mit JCR-Clustering wird eine einzelne öffentliche Magnolia-Instanz als "Slave" verwendet, die das Repository aktualisiert und alle Veröffentlichungen vom Magnolia-Autor erhält, während alle anderen öffentlichen Instanzen das gleiche Repository nutzen.

Durch die Verwendung von JCR-Clustern wird das Problem der Inhaltssynchronisation vollständig umgangen. Der gesamte Inhalt ist bereits im gemeinsamen JCR-Repository vorhanden und steht einer neu gestarteten öffentlichen Magnolia-Instanz zur Verfügung.

Durch die Verwendung der öffentlichen Magnolia-Slave-Instanz entfällt die Notwendigkeit, eine neue öffentliche Magnolia-Instanz als Abonnent der Magnolia-Autoreninstanz zu registrieren. Da nur die Slave-Magnolia-Public-Instanz (und nicht alle Public-Instanzen) die Veröffentlichungen erhält, bleibt die für die Veröffentlichung von Inhalten auf der Magnolia-Autoreninstanz benötigte Zeit konstant.

Genau wie bei der Option "Content Source Target" ist das System bei einem gemeinsam genutzten JCR-Repository anfällig für einen einzelnen Fehlerpunkt. Wenn eine Magnolia-Instanz das JCR-Repository beschädigt, sind auch die anderen Magnolia-Instanzen, die das Repository gemeinsam nutzen, davon betroffen. So kann beispielsweise das unsachgemäße Herunterfahren einer öffentlichen Magnolia-Instanz das JCR-Repository beschädigen, was sich auf alle Instanzen auswirken kann, die dieses Repository gemeinsam nutzen.

Bei einem typischen Einsatz erhalten und speichern alle abonnierten öffentlichen Instanzen die veröffentlichten Inhalte von der Magnolia-Autoreninstanz. Diese "transaktionale Aktivierung" hält alle öffentlichen Abonnenten auf dem gleichen Stand. Mehr öffentliche Instanzen bedeuten jedoch, dass mehr Zeit für eine erfolgreiche Veröffentlichung benötigt wird. RabbitMQ, eine Open-Source-Software zur Verwaltung von Messaging-Warteschlangen, bietet eine Alternative zur transaktionalen Aktivierung. Magnolia nutzt RabbitMQ, um Aktivierungsnachrichten von der Magnolia-Autoreninstanz an die öffentlichen Abonnenten zu übermitteln.

Die Synchronisierung von Inhalten bei der Verwendung von RabbitMQ-Aktivierung kann mit denselben Techniken erfolgen wie bei den anderen Optionen (Wiederherstellung von Sicherungskopien und Synchronisierung von Inhalten mit dem Synchronisierungsmodul), aber mit RabbitMQ haben Sie einen weiteren Trick in petto.

Aktivierungen mit RabbitMQ werden als unabhängige "Deltas" über Warteschlangen verteilt. RabbitMQ kann diese Aktivierungen in seinen Warteschlangen speichern und darauf warten, dass neue Magnolia Public Instances gestartet werden. Sobald eine neue Magnolia-Public-Instanz gestartet wird, erhält sie alle Aktivierungs-Deltas, die in ihrer Warteschlange warten; es ist kein separater Schritt zur Synchronisierung von kürzlich geänderten Inhalten mit dem Magnolia-Synchronisationsmodul erforderlich.

Die RabbitMQ-Aktivierung erleichtert das Starten und Stoppen von öffentlichen Magnolia-Instanzen, da sich viele öffentliche Magnolia-Instanzen mit einem einzigen Magnolia-Autor verbinden können, ohne dass die Veröffentlichung von Inhalten mehr Zeit in Anspruch nimmt. Da die öffentliche Instanz bei RabbitMQ und nicht beim Magnolia-Autor registriert ist, entfällt auch die Notwendigkeit, die neue öffentliche Instanz beim Magnolia-Autor zu registrieren.

RabbitMQ kann zwar zur Erstellung von Standby-Aktivierungswarteschlangen verwendet werden, aber diese Warteschlangen können nur eine begrenzte Anzahl von Nachrichten aufnehmen, bevor sie geleert werden müssen. Da alle Veröffentlichungen, die in den Standby-Warteschlangen warten, auch im Backup enthalten sind, sollten die Standby-Aktivierungswarteschlangen zur gleichen Zeit wie das Backup geleert werden.

Die beste Option für die Nutzung von Magnolia Enterprise CMS mit einem Cloud-Anbieter hängt von zahlreichen Variablen ab. So könnten kleinere Content-Repositories gut mit einem Standard-Deployment oder einem Deployment mit einem Content-Source-Target funktionieren, während diejenigen mit mehr als fünf öffentlichen Instanzen, die eine einzelne Magnolia-Autoreninstanz abonnieren, von der Verwendung von JCR-Clustering oder RabbitMQ-Aktivierung profitieren könnten.

Entdecken Sie die Cloud-Funktionen von Magnolia.