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.

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.

Eine typische TarMK-Cold-Standby-Implementierung:

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.

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

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. Prüfen Sie, ob unter aem-primary/crx-quickstart/install möglicherweise vorherige OSGi-Konfigurationen vorhanden sind, und löschen Sie diese.

   2. Erstellen Sie unter install.primary den Ordner aem-primary/crx-quickstart/install.

   3. Erstellen Sie unter aem-primary/crx-quickstart/install/install.primary die erforderlichen Konfigurationen für den bevorzugten Knotenspeicher und Datenspeicher.

   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. Wenn Sie eine AEM-TarMK-Instanz mit einem externen Datenspeicher verwenden, erstellen Sie unter aem-primary/crx-quickstart/install den Ordner crx3 namens 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. Setzen Sie die Protokollierungsstufe auf „Debug“ und legen Sie fest, dass die Protokollausgabe in einer separaten Datei, z. B. /logs/tarmk-coldstandby.log, gespeichert wird. 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. Löschen Sie alle Dateien, die möglicherweise unter aem-standby/crx-quickstart/install gespeichert sind.

   2. Erstellen Sie unter install.standby den neuen Ordner 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. Erstellen Sie unter crx3 den neuen Ordner aem-standby/crx-quickstart/install.

   5. Erstellen Sie die Datenspeicherkonfiguration und speichern Sie sie unter 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. Wechseln Sie zur Web-Konsole unter: https://Server-Adresse:Serverport/system/console/configMgr.
2. Suchen Sie nach einem Dienst mit dem Namen Apache Jackrabbit Oak Segment Tar Cold Standby Service und doppelklicken Sie darauf, um die Einstellungen zu bearbeiten.
3. Speichern Sie die Einstellungen und starten Sie die Instanzen neu, damit die neuen Einstellungen übernommen werden.

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): Wählt den Ausführungsmodus der Instanz aus.

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

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

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

• Zulässige IP-Bereiche (primary.allowed-client-ip-ranges): Die IP-Bereiche, in denen die primäre Instanz Verbindungen zulässt.

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

• Lese-Timeout für Standby-Instanz (standby.readtimeout): Der Timeout-Wert in Millisekunden für von der Standby-Instanz ausgegebene Anfragen. Der Standardwert ist 60000 (eine Minute).

• Automatische Bereinigung der Standby-Instanz (standby.autoclean): Ruft die Bereinigungsmethode auf, wenn die Größe des Speichers in einem Synchronisierungszyklus ansteigt.

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:

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. Beenden Sie den Synchronisierungsvorgang auf der Cold-Standby-Instanz. Wechseln Sie dazu zur JMX-Konsole und verwenden Sie das Bean org.apache.jackrabbit.oak: Status ("Standby"). Weitere Informationen finden Sie im Abschnitt Monitoring.
2. Beenden Sie die Cold-Standby-Instanz.
3. Installieren Sie den Hotfix auf der primären Instanz. Weitere Einzelheiten zum Installieren eines Hotfixes finden Sie unter Arbeiten mit Paketen.
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.

Monitoring

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. Die entsprechenden Informationen sind in einem MBean vom Typ type org.apache.jackrabbit.oak:type="Standby" namens Status enthalten.

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 die Instanz identifiziert. Beachten Sie, dass sich die UUID bei jeder Aktualisierung der Konfiguration ändert.

• Status: Der aktuelle Status in Textform (z. B. running oder stopped).

• FailedRequests: Die Anzahl aufeinanderfolgender Fehler.

• SecondsSinceLastSuccess: Anzahl der Sekunden seit der letzten erfolgreichen Kommunikation mit dem Server. War keine erfolgreiche Kommunikation möglich, wird -1 angezeigt.

Darüber hinaus gibt es drei aufrufbare Methoden:

• start(): Startet den Synchronisierungsvorgang.
• stop(): Beendet den Synchronisierungsvorgang.
• 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: Dieses Attribut zeigt immer den Wert 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

Adobe empfiehlt, regelmäßige Wartungen durchzuführen, um zu verhindern, dass das Repository im Laufe der Zeit zu groß wird. 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 zum Monitoring.

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

3. Führen Sie auf der primären Instanz das Oak-Komprimierungs-Tool aus. Weitere Informationen finden Sie unter Wartung des Repositorys.

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. Führen Sie auf der Standby-Instanz den cleanup()-Vorgang aus. Verwenden Sie dazu dasselbe JMX-Bean wie im ersten Schritt beschrieben.

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.

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. Führen Sie eine Wartung für das Repository der Cold-Standby-Instanz durch, wie im obigen Abschnitt beschrieben.

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

   • Führen Sie auf der primären Instanz die Speicherbereinigung für den Datenspeicher aus. Verwenden Sie hierzu das entsprechende JMX-Bean, wie in diesem Artikel beschrieben.
   • Auf der Standby-Instanz kann die Speicherbereinigung für den Datenspeicher nur über das BlobGarbageCollection-MBean – startBlobGC() – ausgeführt werden. Das MBean RepositoryManagement ist auf der Standby-Instanz nicht verfügbar.
   HINWEIS

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

Ressourcen für Business.Adobe.com

Style System Targeted Content Personalized Experiences Content As A Service Web Content Management Digital Asset Management