Ausführen von AEM mit der TarMK-Cold-Standby-Funktion

Einführung

Durch die Cold-Standby-Funktionalität des Tar-Mikrokernels können eine oder mehr AEM-Standby-Instanzen eine Verbindung mit einer primären Instanz herstellen. Die Synchronisierung ist dabei unidirektional, d. h. sie verläuft nur von der primären zur Standby-Instanz.

Die Standby-Instanz dient dazu sicherzustellen, dass eine Live-Datenkopie des Master-Repositorys vorhanden ist und ein schneller Wechsel ohne Datenverluste durchgeführt wird, wenn das Master-Repository aus irgendeinem Grund nicht verfügbar ist.

Inhalte werden linear zwischen der primären Instanz und den Standby-Instanzen synchronisiert. Dabei werden keine Integritätsprüfungen auf mögliche Datei- oder Repository-Beschädigungen durchgeführt. Aufgrund dieser Konfiguration sind die Standby-Instanzen exakte Kopien der primären Instanz. Sie können nicht dazu beitragen, Inkonsistenzen auf primären Instanzen zu verhindern.

Hinweis

Die Cold-Standby-Funktion ist für Szenarien bestimmt, in denen eine hohe Verfügbarkeit für author-Instanzen erforderlich ist. In Situationen, in den eine hohe Verfügbarkeit für publish-Instanzen unter Verwendung des Tar-Mikrokernels erforderlich ist, empfiehlt Adobe den Einsatz einer Veröffentlichungsfarm.

Weitere Informationen zu verfügbaren Implementierungen finden Sie auf der Seite Verfügbare Implementierungen.

Funktionsweise

Auf der primären AEM-Instanz ist ein TCP-Port geöffnet, der eingehende Nachrichten überwacht. Derzeit senden die Slaves zwei Arten von Nachrichten an den Master:

  • Eine Nachricht, die die Segment-ID des aktuellen Heads anfordert.
  • Eine Nachricht, die Segmentdaten mit einer angegebenen ID anfordert.

Die Standby-Instanz fordert regelmäßig die Segment-ID des aktuellen Heads der primären Instanz an. Wenn das Segment ein lokal unbekanntes Segment ist, wird es abgerufen. Ist es bereits vorhanden, werden die Segmente verglichen und referenzierte Segmente werden bei Bedarf ebenfalls angefordert.

Hinweis

Standby-Instanzen empfangen keine Anforderungen, da sie nur im Synchronisierungsmodus ausgeführt werden. Der einzige auf einer Standby-Instanz verfügbare Bereich ist die Web-Konsole, um die Konfiguration von Bundles und Diensten zu vereinfachen.

Eine typische TarMK-Cold-Standby-Implementierung:

chlimage_1-86

Weitere Merkmale

Stabilität

Der Datenfluss soll Verbindungs- und Netzwerkprobleme automatisch erkennen und beheben. Alle Pakete sind mit Prüfsummen gebündelt und sobald Verbindungsprobleme oder beschädigte Pakete auftreten, werden Wiederholungsmechanismen ausgelöst.

Leistung

Die Aktivierung der TarMK-Cold-Standby-Funktion auf der primären Instanz hat fast keine messbaren Auswirkungen auf die Leistung. Der zusätzliche CPU-Verbrauch ist äußerst gering und die zusätzliche Festplatte bzw. die zusätzlichen Netzwerk-I/O dürften keine Leistungsprobleme verursachen.

Auf der Standby-Instanz muss während des Synchronisierungsvorgangs mit einer hohen CPU-Nutzung gerechnet werden. Da es sich nicht um einen Multithread-Prozess handelt, kann dieser nicht durch mehrere Kerne beschleunigt werden. Werden keine Daten geändert oder übertragen, tritt keine messbare Aktivität auf. Die Verbindungsgeschwindigkeit variiert je nach Hardware und Netzwerkumgebung. Sie hängt jedoch nicht von der Größe des Repositorys oder der SSL-Nutzung ab. Dies sollte berücksichtigt werden, wenn die erforderliche Zeit für die Erstsynchronisierung geschätzt wird oder wenn zwischenzeitlich auf dem primären Knoten eine große Menge von Daten geändert wurde.

Sicherheit

Wird davon ausgegangen, dass alle Instanzen, in derselben Intranet-Sicherheitszone ausgeführt werden, ist die Gefahr einer Sicherheitsverletzung deutlich geringer. Sie können trotzdem eine zusätzliche Sicherheitsebene hinzufügen, indem Sie SSL-Verbindungen zwischen den Slaves und dem Master aktivieren. So wird die Wahrscheinlichkeit reduziert, dass Daten durch einen Man-in-the-Middle-Angriff kompromittiert werden.

Darüber hinaus können Sie festlegen, welche Standby-Instanzen eine Verbindung herstellen dürfen, indem Sie die IP-Adressen eingehender Anforderungen beschränken. Damit dürfte sichergestellt sein, dass niemand im Intranet das Repository kopieren kann.

Hinweis

Es wird empfohlen, einen Lastenausgleich zwischen dem Dispatcher und den Servern hinzuzufügen, die Teil der Cold-Standby-Konfiguration bilden. Der Lastenausgleich sollte so konfiguriert werden, dass Benutzer-Traffic nur an die primäre Instanz weitergeleitet wird. Dies soll die Konsistenz fördern und verhindern, dass Inhalte auf der Standby-Instanz mit anderen Mitteln als dem Cold-Standby-Mechanismus kopiert werden.

Erstellen einer TarMK-Cold-Standby-Konfiguration für AEM

ACHTUNG

Die PID für den Segment-Knotenspeicher und den Standby-Speicherdienst in AEM 6.3 wurde im Vergleich zu Vorgängerversionen wie folgt geändert:

  • von org.apache.jackrabbit.oak.plugins.segment.standby.store.StandbyStoreService zu org.apache.jackrabbit.oak.segment.standby.store.StandbyStore.StandbyStoreService
  • von org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService zu org.apache.jackrabbit.oak.segment.SegmentNodeStoreService

Stellen Sie sicher, dass Sie die erforderlichen Konfigurationsanpassungen vornehmen, um dieser Änderung Rechnung zu tragen.

Um eine TarMK-Cold-Standby-Konfiguration zu erstellen, müssen Sie zuerst die Standby-Instanzen erstellen. Erstellen Sie hierzu an einem neuen Speicherort eine Dateisystemkopie des gesamten Installationsordners der primären Instanz. Anschließend können Sie jede Instanz mit einem Ausführungsmodus starten, der die Rolle der Instanz angibt (primary oder standby).

Nachfolgend sind die erforderlichen Schritte zum Erstellen einer Konfiguration mit einer Master- und einer Standby-Instanz beschrieben:

  1. Installieren Sie AEM.

  2. Beenden Sie die Instanz und kopieren Sie deren Installationsordner an den Speicherort, von dem aus die Cold-Standby-Instanz ausgeführt werden soll. Selbst wenn sie auf unterschiedlichen Rechnern ausgeführt wird, müssen Sie jedem Ordner einen aussagekräftigen Namen zuweisen (z. B. aem-primary oder aem-standby), um zwischen den Instanzen zu unterscheiden.

  3. Navigieren Sie zum Installationsordner der primären Instanz und führen Sie folgende Schritte aus:

    1. Check and delete any preivous OSGi configurations you might have under aem-primary/crx-quickstart/install
    2. Create a folder called install.primary under aem-primary/crx-quickstart/install
    3. Create the required configurations for the prefered node store and data store under aem-primary/crx-quickstart/install/install.primary
    4. Erstellen Sie im selben Verzeichnis die Datei org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config und konfigurieren Sie sie entsprechend. Weitere Informationen zu den Konfigurationsoptionen finden Sie unter Konfiguration.
    5. If you are using an AEM TarMK instance with an external data store, create a folder named crx3 under aem-primary/crx-quickstart/install named crx3
    6. Speichern Sie die Konfigurationsdatei für den Datenspeicher im Ordner crx3.

    Wenn Sie beispielsweise eine AEM-TarMK-Instanz mit einer externen Datenspeicherdatei ausführen, benötigen Sie die folgenden Konfigurationsdateien:

    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    Nachfolgend finden Sie Beispielkonfigurationen für die primäre Instanz:

    Beispiel für org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    customBlobStore=B"true"
    standby=B"false"
    

    Beispiel für org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="primary"
    port=I"8023"
    

    Beispiel für org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  4. Starten Sie die primäre Instanz und stellen Sie dabei sicher, dass Sie den Ausführungsmodus „primary“ festlegen:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Erstellen Sie einen neuen Apache Sling Logging Logger für das Paket org.apache.jackrabbit.oak.segment. Set log level to “Debug” and point its log output to a separate logfile, like /logs/tarmk-coldstandby.log. Weitere Informationen finden Sie unter Protokollierung.

  6. Navigieren Sie zum Speicherort der Instanz standby und starten Sie diese durch Ausführen der JAR-Datei.

  7. Erstellen Sie dieselbe Protokollierungskonfiguration wie für die primäre Instanz. Beenden Sie anschließend die Instanz.

  8. Bereiten Sie dann die Standby-Instanz vor. Hierzu können Sie dieselben Schritte wie für die primäre Instanz ausführen:

    1. Delete any files you might have under aem-standby/crx-quickstart/install.

    2. Create a new folder called install.standby under aem-standby/crx-quickstart/install

    3. Erstellen Sie zwei Konfigurationsdateien mit den folgenden Namen:

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    4. Create a new folder called crx3 under aem-standby/crx-quickstart/install

    5. Create the data store configuration and place it under aem-standby/crx-quickstart/install/crx3. Für dieses Beispiel müssen Sie die folgende Datei erstellen:

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    6. Bearbeiten Sie die Dateien und erstellen Sie die erforderlichen Konfigurationen.

    Nachfolgend finden Sie Beispiel-Konfigurationsdateien für eine typische Standby-Instanz:

    Beispiel für org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    name="Oak-Tar"
    service.ranking=I"100"
    standby=B"true"
    customBlobStore=B"true"
    

    Beispiel für org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="standby"
    primary.host="127.0.0.1"
    port=I"8023"
    secure=B"false"
    interval=I"5"
    standby.autoclean=B"true"
    

    Beispiel für org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  9. Starten Sie die standby-Instanz über den Ausführungsmodus „standby“:

    java -jar quickstart.jar -r standby,crx3,crx3tar
    

Der Dienst kann auch über die Web-Konsole konfiguriert werden. Führen Sie hierzu folgende Schritte aus:

  1. Going to the Web Console at: https://serveraddress:serverport/system/console/configMgr
  2. Looking for a service called Apache Jackrabbit Oak Segment Tar Cold Standby Service and double click it to edit the settings.
  3. Speichern Sie die Einstellungen und starten Sie die Instanzen neu, damit die neuen Einstellungen übernommen werden.
Hinweis

Sie können die Rolle einer Instanz jederzeit überprüfen, indem Sie in der Web-Konsole für die Sling-Einstellungen prüfen, ob die Ausführungsmodi primary oder standby vorhanden sind.

Wechseln Sie hierfür zu http://localhost:4502/system/console/status-slingsettings und überprüfen Sie die Zeile „Run Modes“.

Erstsynchronisierung

Wenn die Vorbereitung abgeschlossen ist und die Standby-Instanz zum ersten Mal gestartet wird, tritt erhöhter Netzwerk-Traffic zwischen den Instanzen auf, da die Standby-Instanzen mit der primären Instanz synchronisiert werden. Anhand der Protokolle können Sie den Status der Synchronisierung überprüfen.

Im Protokoll tarmk-coldstandby.log werden dabei Einträge wie die folgenden angezeigt:

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

Im Protokoll error.log der Standby-Instanz wird folgender Eintrag angezeigt:

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

Im obigen Protokollausschnitt ist 10.20.30.40 die IP-Adresse der primären Instanz.

Im Protokoll tarmk-coldstandby.log der Instanz primary werden Einträge wie die folgenden angezeigt:

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

In diesem Fall ist der im Protokoll genannte „Client“ die Instanz standby.

Wenn diese Einträge nicht mehr im Protokoll angezeigt werden, können Sie davon ausgehen, dass der Synchronisierungsvorgang abgeschlossen ist.

Obwohl die obigen Einträge zeigen, dass der Abrufmechanismus ordnungsgemäß funktioniert, ist es häufig hilfreich festzustellen, ob bei Abrufvorgängen Daten synchronisiert werden. Suchen Sie hierzu nach Einträgen wie den folgenden:

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

Darüber hinaus werden bei der Ausführung über einen nicht freigegebenen FileDataStore Meldungen wie die folgenden angezeigt, die bestätigen, dass die Binärdateien ordnungsgemäß übertragen werden:

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

Konfiguration

Die folgenden OSGi-Einstellungen sind für den Cold-Standby-Dienst verfügbar:

  • Konfiguration beibehalten: Bei Aktivierung dieser Option wird die Konfiguration im Repository anstatt wie üblich in den OSGi-Konfigurationsdateien gespeichert. Es wird empfohlen, diese Einstellung auf Produktionssystemen zu deaktivieren, damit die Konfiguration der primären Instanz nicht von der Standby-Instanz abgerufen wird.

  • Modus (mode): wird der Ausführungsmodus der Instanz ausgewählt.

  • Port (port): Der für die Kommunikation zu verwendende Port. Der Standardwert lautet 8023.

  • Primär Host (primary.host): - der Host der primären Instanz. Diese Einstellung gilt nur für die Standby-Instanz.

  • Synchronisierungsintervall (interval): - Diese Einstellung bestimmt das Intervall zwischen der Synchronisierungsanforderung und gilt nur für die Standby-Instanz.

  • Zulässige IP-Bereiche (primary.allowed-client-ip-ranges): - die IP-Bereiche, von denen die primären Verbindungen zulassen.

  • Sicher (secure): Aktivieren Sie SSL-Verschlüsselung. Damit Sie die Einstellung nutzen können, muss sie auf allen Instanzen aktiviert werden.

  • Standby Read Timeout (standby.readtimeout): Timeout für Anforderungen, die von der Standby-Instanz in Millisekunden ausgegeben werden. Die empfohlene Timeout-Einstellung lautet 43200000. In der Regel wird empfohlen, einen Timeout-Wert von mindestens 12 Stunden festzulegen.

  • Automatische Standby-Bereinigung (standby.autoclean): Rufen Sie die Bereinigungsmethode auf, wenn die Größe des Speichers bei einem Synchronisierungszyklus zunimmt.

Hinweis

Es wird dringend empfohlen, den primären und Standby-Instanzen unterschiedliche Repository-IDs zuzuweisen, damit sie für Dienste wie die Abladung einzeln identifizierbar sind.

Am einfachsten geschieht dies durch Löschen der Datei sling.id auf der Standby-Instanz und Neustarten der Instanz.

Failover-Verfahren

Für den Fall, dass die primäre Instanz aus irgendeinem Grund ausfällt, können Sie festlegen, dass eine der Standby-Instanzen die Rolle der primären Instanz übernimmt. Hierzu müssen Sie den Ausführungsmodus für den Start wie nachfolgend beschrieben ändern:

Hinweis

Auch die Konfigurationsdateien müssen so modifiziert werden, dass sie den Einstellungen der Primärinstanz entsprechen.

  1. Navigieren Sie zum Speicherort der installierten Standby-Instanz und beenden Sie sie.

  2. Wenn Sie bei der Einrichtung einen Lastenausgleich konfiguriert haben, können Sie jetzt die primäre Instanz aus der Konfiguration des Lastenausgleichs entfernen.

  3. Erstellen Sie eine Sicherungskopie des Ordners crx-quickstart, der im Installationsordner der Standby-Instanz zu finden ist. Sie kann als Basis für die Konfiguration einer neuen Standby-Instanz verwendet werden.

  4. Starten Sie die Instanz über den Ausführungsmodus primary neu:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Fügen Sie die neue primäre Instanz zum Lastenausgleich hinzu.

  6. Erstellen und starten Sie eine neue Standby-Instanz. Weitere Informationen finden Sie im oben beschriebenen Verfahren Erstellen einer TarMK-Cold-Standby-Konfiguration für AEM.

Anwenden von Hotfixes auf eine Cold-Standby-Konfiguration

Die empfohlene Methode zum Anwenden von Hotfixes auf eine Cold-Standby-Konfiguration besteht darin, sie auf der primären Instanz zu installieren und diese dann mit den installierten Hotfixes als neue Cold-Standby-Instanz zu klonen.

Führen Sie hierzu die nachfolgend beschriebenen Schritte aus:

  1. Stop the synchronization process on the cold standby instance by going to the JMX Console and using the org.apache.jackrabbit.oak: Status ("Standby") bean. For more information on how to do this, see the section on Monitoring.
  2. Beenden Sie die Cold-Standby-Instanz.
  3. Installieren Sie den Hotfix auf der primären Instanz. For more details on how to install a hotfix, see How to Work With Packages.
  4. Testen Sie die Instanz nach der Installation auf mögliche Probleme.
  5. Entfernen Sie die Cold-Standby-Instanz durch Löschen des entsprechenden Installationsordners.
  6. Beenden Sie die primäre Instanz und klonen Sie sie. Erstellen Sie hierzu eine Dateisystemkopie des gesamten Installationsordners am Speicherort der Cold-Standby-Instanz.
  7. Konfigurieren Sie den neu erstellten Klon so, dass er als Cold-Standby-Instanz fungiert. Weitere Einzelheiten hierzu finden Sie unter Erstellen einer TarMK-Cold-Standby-Konfiguration für AEM.
  8. Starten Sie die primäre und die Cold-Standby-Instanzen.

Überwachung

Diese Funktion stellt Informationen mithilfe von JMX oder MBeans bereit. So können Sie den aktuellen Status der Standby- und Master-Instanz mithilfe der JMX-Konsole überprüfen. The information can be found in an MBean of type org.apache.jackrabbit.oak:type="Standby"named Status.

Standby-Instanz

Beim Überwachen einer Standby-Instanz wird ein Knoten angezeigt. Die ID ist normalerweise eine generische UUID.

Dieser Knoten verfügt über fünf schreibgeschützte Attribute:

  • Running: Ein boolescher Wert, der angibt, ob der Synchronisierungsvorgang ausgeführt wird oder nicht.
  • Mode: Client: gefolgt von der UUID, die zur Identifizierung der Instanz verwendet wird. Beachten Sie, dass sich die UUID bei jeder Aktualisierung der Konfiguration ändert.
  • Status: eine Textdarstellung des aktuellen Status (wie running oder stopped).
  • FailedRequests:Die Anzahl aufeinanderfolgender Fehler.
  • SecondsSinceLastSuccess: die Anzahl der Sekunden seit der letzten erfolgreichen Kommunikation mit dem Server. It will display -1 if no successful communication has been made.

Darüber hinaus gibt es drei aufrufbare Methoden:

  • start(): Der Synchronisierungsprozess wird Beginn.
  • stop(): beendet den Synchronisierungsprozess.
  • cleanup(): Führt den Bereinigungsvorgang auf der Standby-Instanz durch.

Primäre Instanz

Beim Überwachen der primären Instanz wird eine Reihe allgemeiner Informationen über ein MBean angezeigt, dessen ID-Value die Port-Nummer ist, die vom TarMK-Standby-Dienst verwendet wird (standardmäßig 8023). Die meisten Methoden und Attribute sind dieselben wie für die Standby-Instanz, mit einigen Ausnahmen:

  • Mode: wird immer der Wert angezeigt primary.

Desweiteren können Informationen für bis zu 10 Clients (Standby-Instanzen) abgerufen werden, die mit der Master-Instanz verbunden sind. Die MBean-ID ist die UUID der Instanz. Für diese MBeans sind keine aufrufbaren Methoden vorhanden, jedoch einige nützliche, schreibgeschützte Attribute:

  • Name: Dies ist die ID des Clients.
  • LastSeenTimestamp: Der Zeitstempel der letzten Anforderungen in Textform.
  • LastRequest: Die letzte Anforderung des Clients.
  • RemoteAddress: Die IP-Adresse des Clients.
  • RemotePort: Der vom Client für die letzte Anforderung verwendete Port.
  • TransferredSegments: Die Gesamtanzahl der an diesen Client übertragenen Segmente.
  • TransferredSegmentBytes:Die Gesamtzahl der an diesen Client übertragenen Byte.

Wartung des Cold-Standby-Repositorys

Revisionsbereinigung

ACHTUNG

Führen Sie auf der Standby-Instanz keine Offline-Revisionsbereinigung aus. Dies ist nicht erforderlich und die Größe des Segmentspeichers wird dadurch nicht reduziert.

Hinweis

Wenn Sie auf der primären Instanz die Online-Revisionsbereinigung ausführen, ist das im Folgenden vorgestellte manuelle Verfahren nicht erforderlich. Additionally, if you are using Online Revision Cleanup, the cleanup () operation on the standby instance will pe performed automatically.

Adobe empfiehlt die regelmäßige Wartung, um ein übermäßiges Repository-Wachstum im Laufe der Zeit zu vermeiden. Führen Sie zum manuellen Warten des Cold-Standby-Repositorys die folgenden Schritte aus:

  1. Beenden Sie den Standby-Prozess auf der Standby-Instanz. Wechseln Sie dazu zur JMX-Konsole und verwenden Sie das Bean org.apache.jackrabbit.oak: Status ("Standby"). Weitere Informationen finden Sie im obigen Abschnitt zur Überwachung.

  2. Beenden Sie die primäre AEM-Instanz.

  3. Führen Sie auf der primären Instanz das Oak-Komprimierungs-Tool aus. For more details, see Maintaining the Repository.

  4. Starten Sie die primäre Instanz.

  5. Starten Sie den Standby-Prozess auf der Standby-Instanz. Verwenden Sie dazu dasselbe JMX-Bean wie im ersten Schritt beschrieben.

  6. Überwachen Sie die Protokolle und warten Sie, bis die Synchronisierung abgeschlossen ist. Möglicherweise nimmt die Größe des Standby-Repositorys jetzt erheblich zu.

  7. Run the cleanup() operation on the standby instance, using the same JMX bean as described in the first step.

Es kann länger als üblich dauern, bis die Synchronisierung der Standby-Instanz mit der primären Instanz abgeschlossen ist, da bei der Offline-Komprimierung der Repository-Verlauf neu geschrieben wird und die Berechnung von Änderungen in den Repositorys deshalb länger dauert. Ebenfalls zu beachten ist, dass das Repository auf der Standby-Instanz nach Abschluss des Vorgangs etwa dieselbe Größe hat wie das Repository auf der primären Instanz.

Alternativ dazu kann das Repository der primären Instanz nach Durchführung der Komprimierung auf der primären Instanz manuell auf die Standby-Instanz kopiert werden, wodurch die Standby-Instanz bei jeder Komprimierung neu erstellt wird.

Automatische Datenspeicherbereinigung

Es ist wichtig, hin und wieder eine Speicherbereinigung (Garbage Collection) für die Dateidatenspeicher-Instanz durchzuführen, da andernfalls gelöschte Binärdateien im Dateisystem bleiben und mit der Zeit den Festplattenspeicherplatz belegen. Gehen Sie wie folgt vor, um eine Speicherbereinigung durchzuführen:

  1. Run cold standby repository maintenance as described in the section above.

  2. Wenn die Wartung abgeschlossen und die Instanz neu gestartet wurde, führen Sie die folgenden Schritte aus:

    • On the primary, run the data store garbage collection via the relevant JMX bean as described in this article.
    • On the standby, the data store garbage collection is available only via the BlobGarbageCollection MBean - startBlobGC(). The RepositoryManagement MBean is not available on the standby.
    Hinweis

    Wenn Sie keinen freigegebenen Datenspeicher verwenden, muss die Speicherbereinigung zuerst auf der primären und dann auf der Standby-Instanz ausgeführt werden.

Auf dieser Seite