Så här kör du AEM med TARMK Cold Standby

Introduktion

Tack vare kapaciteten för vänteläge i kallt läge för Tjärmikrokärnan kan en eller flera AEM ansluta till en primär instans. Synkroniseringsprocessen är bara ett sätt, vilket innebär att den bara utförs från den primära instansen till standby-instansen.

Syftet med standby-instanserna är att garantera en live-datakopia av den överordnad databasen och säkerställa en snabb växling utan dataförlust om den överordnad inte är tillgänglig av någon anledning.

Innehållet synkroniseras linjärt mellan den primära instansen och standby-instansen utan några integritetskontroller för att filer eller databaser är skadade. På grund av den här designen är standby-instanser exakta kopior av den primära instansen och kan inte bidra till att minska inkonsekvenser i primära instanser.

Så här fungerar det

På den primära AEM öppnas en TCP-port och lyssnar på inkommande meddelanden. För närvarande finns det två typer av meddelanden som slavarna skickar till överordnad:

• ett meddelande som begär det aktuella huvudets segmend-ID
• ett meddelande som begär segmentdata med ett angivet ID

Vänteläge begär regelbundet segment-ID:t för den primära huvuddelen. Om segmentet är lokalt okänt hämtas det. Om den redan finns jämförs segmenten och om det behövs efterfrågas även refererade segment.

En typisk STAMK Cold Standby-driftsättning:

Andra egenskaper

Robusta

Dataflödet är utformat för att automatiskt upptäcka och hantera anslutnings- och nätverksrelaterade problem. Alla paket är paketerade med kontrollsummor och så snart problem med anslutningen eller skadade paket uppstår aktiveras återförsöksmekanismer.

Prestanda

Om du aktiverar TonaMK Cold Standby på den primära instansen påverkas prestanda nästan inte. Den extra processorförbrukningen är mycket låg och den extra hårddisk- och nätverks-I/O-funktionen bör inte ge upphov till prestandaproblem.

I vänteläge kan du förvänta dig hög processorförbrukning under synkroniseringsprocessen. Eftersom proceduren inte är flertrådig går det inte att öka hastigheten genom att använda flera kärnor. Om inga data ändras eller överförs blir det ingen mätbar aktivitet. Anslutningshastigheten varierar beroende på maskinvara och nätverksmiljö, men beror inte på storleken på databasen eller SSL-användningen. Du bör tänka på detta när du beräknar den tid som krävs för en inledande synkronisering eller när mycket data har ändrats under tiden på den primära noden.

Dokumentskydd

Om man utgår ifrån att alla instanser körs i samma säkerhetszon för intranätet minskar risken för säkerhetsöverträdelse avsevärt. Du kan dock lägga till extra säkerhetslager genom att aktivera SSL-anslutningar mellan slavarna och överordnad. På så sätt minskar risken för att data äventyras av en man-in-the-middle.

Du kan dessutom ange vilka standby-instanser som tillåts ansluta genom att begränsa IP-adressen för inkommande begäranden. Detta bör bidra till att garantera att ingen i intranätet kan kopiera databasen.

Skapa en AEM Stjärtöverläge i Cold

För att kunna skapa en kallig TjärMK-standby-inställning måste du först skapa standby-instanserna genom att utföra en kopia av hela installationsmappen för den primära till en ny plats. Du kan sedan starta varje instans med ett körningsläge som anger dess roll ( primary eller standby).

Nedan visas proceduren som måste följas för att skapa en konfiguration med en överordnad och en standby-instans:

1. Installera AEM.

2. Stäng instansen och kopiera installationsmappen till den plats där instansen av kallstart ska köras. Även om du kör från olika datorer måste du ge varje mapp ett beskrivande namn (som aem-primär eller aem-standby) för att skilja mellan förekomsterna.

3. Gå till installationsmappen för den primära instansen och:

   1. Kontrollera och ta bort tidigare OSGi-konfigurationer som du har under aem-primary/crx-quickstart/install

   2. Skapa en mapp med namnet install.primary under aem-primary/crx-quickstart/install

   3. Skapa de konfigurationer som krävs för det önskade nodarkivet och datalagret under aem-primary/crx-quickstart/install/install.primary

   4. Skapa en fil med namnet org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config på samma plats och konfigurera den därefter. Mer information om konfigurationsalternativen finns i Konfiguration.

   5. Om du använder en AEM tarMK-instans med ett externt datalager skapar du en mapp med namnet crx3 under aem-primary/crx-quickstart/install namngiven crx3

   6. Placera konfigurationsfilen för datalagret i crx3 mapp.

   Om du till exempel kör en AEM tarMK-instans med ett externt fildatalager behöver du följande konfigurationsfiler:

   • 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

   Här nedan hittar du exempelkonfigurationer för den primära instansen:

   Exempel på org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

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

   Exempel på org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

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

   Exempel på 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. Starta det primära läget och kontrollera att du anger det primära körningsläget:

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

5. Skapa en ny loggningslogg för Apache Sling för org.apache.jackrabbit.oak.segment paket. Ställ in loggnivån på "Felsök" och peka loggutdata på en separat loggfil, som /logs/tarmk-coldstandby.log. Mer information finns i Loggning.

6. Gå till platsen för vänteläge och börja med att köra burken.

7. Skapa samma loggningskonfiguration som för den primära. Stoppa sedan instansen.

8. Förbered sedan standby-instansen. Du kan göra detta genom att utföra samma steg som för den primära instansen:

   1. Ta bort alla filer du har under aem-standby/crx-quickstart/install.

   2. Skapa en ny mapp med namnet install.standby under aem-standby/crx-quickstart/install

   3. Skapa två konfigurationsfiler med namnet:

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

   4. Skapa en ny mapp med namnet crx3 under aem-standby/crx-quickstart/install

   5. Skapa datalagerkonfigurationen och placera den under aem-standby/crx-quickstart/install/crx3. I det här exemplet måste du skapa följande fil:

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

   6. Redigera filerna och skapa de konfigurationer som behövs.

   Nedan visas exempel på konfigurationsfiler för en vanlig standby-instans:

   Exempel på 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"
   

   Exempel på 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"
   

   Exempel på 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. Starta vänteläge instans med vänteläge:

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

Tjänsten kan även konfigureras via webbkonsolen genom att:

1. Gå till webbkonsolen på: https://serveraddress:serverport/system/console/configMgr
2. Söker efter en tjänst som anropats Apache Jackrabbit Oak Segment tar i vänteläge och dubbelklicka på den för att redigera inställningarna.
3. Spara inställningarna och starta om instanserna så att de nya inställningarna kan börja gälla.

Första synkroniseringen

När beredningen är klar och standby-läget startas för första gången kommer det att uppstå en kraftig nätverkstrafik mellan instanserna när standby-läget fångar upp till primärt läge. Du kan läsa loggarna för att se synkroniseringens status.

I vänteläge tarmk-coldstandby.log kommer du att se bl.a. följande:

    *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

I vänteläget error.log bör du se en sådan här post:

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

I loggfragmentet ovan 10.20.30.40 är den primära IP-adressen.

I primär tarmk-coldstandby.log kommer du att se bl.a. följande:

    *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

I det här fallet är "klienten" som anges i loggen vänteläge -instans.

När de här posterna inte längre visas i loggen kan du anta att synkroniseringsprocessen är slutförd.

Ovanstående poster visar att avsökningsfunktionen fungerar som den ska, men det är ofta bra att förstå om det finns data som synkroniseras när avsökningen sker. Om du vill göra det söker du efter poster som följande:

*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

Dessutom, vid körning med en ej delad FileDataStore, som följande kommer att bekräfta att de binära filerna överförs på rätt sätt:

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

Konfiguration

Följande OSGi-inställningar är tillgängliga för tjänsten Cold Standby:

• Beständig konfiguration: om det är aktiverat lagras konfigurationen i databasen i stället för de traditionella OSGi-konfigurationsfilerna. Vi rekommenderar att den här inställningen är inaktiverad på produktionssystem så att den primära konfigurationen inte hämtas i vänteläge.

• Läge (mode): Då väljs instansens körningsläge.

• Port (port): den hamn som ska användas för kommunikation. Standardvärdet är 8023.

• Primär värd (primary.host): - den primära instansens värd. Den här inställningen gäller endast för vänteläge.

• Synkroniseringsintervall (interval): - den här inställningen avgör intervallet mellan synkroniseringsbegäranden och gäller endast för standby-instansen.

• Tillåtna IP-intervall (primary.allowed-client-ip-ranges): - IP-intervallen som den primära servern tillåter anslutningar från.

• Säker (secure): Aktivera SSL-kryptering. För att den här inställningen ska kunna användas måste den vara aktiverad i alla instanser.

• Timeout för vänteläsning (standby.readtimeout): Timeout för begäranden som utfärdas från standby-instansen i millisekunder. Standardvärdet är 60000 (en minut).

• Automatisk rensning i vänteläge (standby.autoclean): Anropa rensningsmetoden om storleken på butiken ökar under en synkroniseringscykel.

Redundansprocedurer

Om den primära instansen av någon anledning inte fungerar kan du ställa in en av standby-instanserna så att den tar rollen som primär genom att ändra start-runmode enligt beskrivningen nedan:

1. Gå till den plats där standby-instansen är installerad och stoppa den.

2. Om du har konfigurerat en belastningsutjämnare med konfigurationen kan du ta bort den primära från belastningsutjämnarens konfiguration nu.

3. Säkerhetskopiera crx-quickstart från installationsmappen i vänteläge. Den kan användas som utgångspunkt när du skapar ett nytt vänteläge.

4. Starta om instansen med primary runmode:

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

5. Lägg till den nya primära till belastningsutjämnaren.

6. Skapa och starta en ny standby-instans. Mer information finns i proceduren ovan på Skapa en AEM väntelägesinställning för TARMK.

Använda snabbkorrigeringar i en konfiguration för vänteläge i kallt format

Det rekommenderade sättet att tillämpa snabbkorrigeringar på en kallstartsinstallation är att installera dem på den primära instansen och sedan klona den i en ny kallig standby-instans med snabbkorrigeringarna installerade.

Du kan göra detta genom att följa stegen nedan:

1. Stoppa synkroniseringsprocessen på den kalla standby-instansen genom att gå till JMX-konsolen och använda org.apache.jackrabbit.oak: Status ("Standby")​bean. Mer information om hur du gör detta finns i avsnittet om Övervakning.
2. Stoppa kallstartsinstansen.
3. Installera snabbkorrigeringen på den primära instansen. Mer information om hur du installerar en snabbkorrigering finns i Så här arbetar du med paket.
4. Testa instansen efter problem efter installationen.
5. Ta bort instansen av det kalla vänteläget genom att ta bort installationsmappen.
6. Stoppa den primära instansen och klona den genom att utföra en kopia av hela installationsmappen i filsystemet till platsen för det kalla vänteläget.
7. Konfigurera om den nyligen skapade klonen så att den fungerar som en instans i kallt vänteläge. Mer information finns i Skapa en AEM väntelägesinställning för TARMK Cold.
8. Starta både det primära och det kalla vänteläget.

Övervakning

Funktionen visar information med JMX eller MBeans. Det gör att du kan kontrollera det aktuella läget för standby och överordnad med hjälp av JMX-konsol. Informationen finns i MBean av type org.apache.jackrabbit.oak:type="Standby"namngiven Status.

Standby

Om du observerar en standby-instans visas en nod. ID:t är vanligtvis ett generiskt UUID.

Den här noden har fem skrivskyddade attribut:

• Running: booleskt värde som anger om synkroniseringsprocessen körs eller inte.

• Mode: Klient: följt av det UUID som används för att identifiera instansen. Observera att detta UUID ändras varje gång konfigurationen uppdateras.

• Status: en textbeteckning för det aktuella läget (som running eller stopped).

• FailedRequests:antalet på varandra följande fel.

• SecondsSinceLastSuccess: antalet sekunder som gått sedan den senaste kommunikationen med servern. Den visas -1 om ingen framgångsrik kommunikation har gjorts.

Det finns också tre anropbara metoder:

• start(): startar synkroniseringsprocessen.
• stop(): stoppar synkroniseringsprocessen.
• cleanup(): kör rensningsåtgärden i vänteläge.

Primär

När du observerar det primära exponeras viss allmän information via ett MBean vars ID-värde är det portnummer som standbytjänsten tarMK använder (8023 som standard). De flesta metoder och attribut är desamma som i vänteläge, men vissa skiljer sig åt:

• Mode: kommer alltid att visa värdet primary.

Dessutom kan information för upp till 10 klienter (standby-instanser) som är anslutna till överordnad hämtas. MBean-ID:t är instansens UUID. Det finns inga anropbara metoder för dessa MBeans, men några mycket användbara skrivskyddade attribut:

• Name: ID för klienten.
• LastSeenTimestamp: tidsstämpeln för den senaste begäran i en textbeteckning.
• LastRequest: klientens senaste begäran.
• RemoteAddress: klientens IP-adress.
• RemotePort: den port klienten använde för den senaste begäran.
• TransferredSegments: det totala antalet segment som överförts till den här klienten.
• TransferredSegmentBytes:det totala antalet byte som har överförts till klienten.

Underhåll av vänteläge, kall

Revision Cleanup

Adobe rekommenderar regelbundet underhåll för att förhindra alltför stor databastillväxt över tid. Följ stegen nedan om du vill utföra underhåll i vänteläge manuellt:

1. Stoppa standbyprocessen i standby-instansen genom att gå till JMX-konsolen och använda org.apache.jackrabbit.oak: Status ("Standby") böna. Mer information om hur du gör detta finns i ovanstående avsnitt på Övervakning.

2. Stoppa den primära AEM.

3. Kör ekkomprimeringsverktyget på den primära instansen. Mer information finns i Underhålla databasen.

4. Starta den primära instansen.

5. Starta standby-processen i standby-instansen med samma JMX-böna som i det första steget.

6. Se loggarna och vänta tills synkroniseringen är klar. Det är möjligt att en avsevärd ökning av beredskapslagringsplatsen kommer att ses just nu.

7. Kör cleanup() i standby-instansen, med samma JMX-böna som i det första steget.

Det kan ta längre tid än vanligt för standby-instansen att slutföra synkroniseringen med den primära, eftersom offlinekomprimeringen effektivt skriver om databashistoriken, vilket gör att beräkning av ändringarna i databaserna tar längre tid. Det bör också noteras att när processen är slutförd kommer storleken på databasen i vänteläge att vara ungefär lika stor som databasen på den primära databasen.

Som ett alternativ kan den primära databasen kopieras till vänteläge manuellt efter att du har kört komprimering på den primära, vilket innebär att vänteläget återskapas varje gång komprimeringen körs.

Skräpinsamling för datalager

Det är viktigt att du kör skräpinsamlingen på fildatalagrets instanser då och då, annars finns borttagna binärfiler kvar i filsystemet och fyller i enheten. Så här kör du skräpinsamlingen:

1. Kör underhåll av kalla standby-databaser enligt beskrivningen i avsnittet ovan.

2. När underhållsprocessen har slutförts och instanserna har startats om:

   • Kör skräpinsamlingen i datalagret via den relevanta JMX-böljan enligt beskrivningen i den här artikeln.
   • I vänteläge är skräpinsamlingen i datalagret bara tillgänglig via BlobGarbageCollection MBean - startBlobGC(). RepositoryManagement ​ MBean är inte tillgängligt i vänteläge.
   OBSERVERA

   Om du inte använder ett delat datalager måste skräpinsamlingen först köras på primär plats och sedan i vänteläge.

Resurser för Business.Adobe.com

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