Sie sehen sich Hilfeinhalte der folgenden Version an:

Überblick

Durch die Verarbeitung großer Dateien und Ausführung von Workflows in Adobe Experience Manager (AEM) Assets kann ein erheblicher Teil von CPU, Speicher und I/O-Ressourcen in Beschlag genommen werden. Insbesondere die Größe der Assets, die Workflows, die Anzahl der Benutzer und die Häufigkeit der Asset-Aufnahme können sich auf die Gesamtleistung des Systems auswirken. Zu den ressourcenintensivsten Vorgängen gehören die AEM-Workflows zur Asset-Aufnahme und Replikation. Eine intensive Nutzung dieser Workflows in einer AEM-Autoreninstanz kann die Bearbeitungseffizienz beeinträchtigen.

Werden diese Aufgaben auf dedizierte Worker-Instanzen abgeladen, kann sich der CPU-, Speicher- und I/O-Mehraufwand reduzieren. Im Allgemeinen lautet die Idee hinter der Abladung, dass Aufgaben mit hohem CPU-/Speicher-/Ressourcenverbrauch auf dedizierte Worker-Instanzen verteilt werden. In den folgenden Abschnitten werden empfohlene Anwendungsbeispiele für die Assets-Abladung beschrieben. 

AEM Assets-Abladung

AEM Assets implementiert eine native Asset-spezifische Workflow-Erweiterung zur Abladung. Als Basis dient hierbei die generische Workflow-Erweiterung des Abladeframeworks, wobei allerdings zusätzliche Asset-spezifische Funktionen in der Implementierung enthalten sind. Das Ziel der Assets-Abladung besteht darin, den Workflow „DAM-Update-Asset“ auf einem hochgeladenen Asset effizient auszuführen. Mittels Assets-Abladung erlangen Sie eine größere Kontrolle über die Aufnahmeworkflows.

Komponenten der AEM Assets-Abladung

Die folgende Abbildung zeigt die Hauptkomponenten des Asset-Abladeprozesses:

chlimage_1

Workflow „Asset-Abladung für DAM-Update“

Der Worfklow „Asset-Abladung für DAM-Update“ wird auf dem Master (Autor) ausgeführt, auf dem der Benutzer die Assets hochlädt. Dieser Workflow wird von einem regulären Workflowstarter ausgelöst. Statt das hochgeladene Asset zu verarbeiten, erstellt der Abladeworkflow einen neuen Auftrag mit dem Thema com/adobe/granite/workflow/offloading. Der Abladeworkflow fügt den Namen des Zielworkflows – in diesem Fall den DAM-Update-Asset-Workflow – und den Pfad des Assets der Nutzlast des Auftrags hinzu. Nach Erstellung des Abladeauftrags wartet der Abladeworkflow auf dem Master, bis der Abladeauftrag ausgeführt wurde.

Job Manager

Der Job Manager verteilt neue Aufträge an Worker-Instanzen. Beim Design des Verteilungsmechanismus muss an die Themenaktivierung gedacht werden. Aufträge können Instanzen nur dann zugewiesen werden, wenn das Thema des entsprechenden Auftrags aktiviert ist. Deaktivieren Sie das Thema com/adobe/granite/workflow/offloading auf dem Master und aktivieren Sie es auf dem Worker, um sicherzustellen, dass der Auftrag dem Worker zugewiesen ist.

AEM-Abladung

Das Abladeframework identifiziert Aufträge zur Workflow-Abladung, die Worker-Instanzen zugewiesen sind, und transportiert diese physisch, einschließlich Nutzlast (etwa aufzunehmende Bilder), an Worker.

Job Consumer „Workflow-Abladung“

Sobald ein Auftrag auf den Worker geschrieben wurde, ruft der Job Manager den für das Thema com/adobe/granite/workflow/offloading zuständigen Job Consumer auf. Der Job Consumer führt dann den Workflow „DAM-Update-Asset“ auf dem Asset aus.

Sling-Topologie

Die Sling-Topologie gruppiert AEM-Instanzen und ermöglicht deren gegenseitige Erkennung, und zwar unabhängig von der zugrundeliegenden Persistenz. Dank dieser Eigenschaft der Sling-Topologie können Sie Topologien für Nicht-Cluster-, Cluster- und Mischszenarien erstellen. Eine Instanz kann Eigenschaften gegenüber der gesamten Topologie offenlegen. Das Framework bietet Callbacks für das Listening auf Änderungen in der Topologie (Instanzen und Eigenschaften). Die Sling-Topologie bildet die Grundlage für Sling-verteilte Aufträge.

Sling-verteilte Aufträge

Sling-verteilte Aufträge vereinfachen die Verteilung von Aufträgen unter Instanzen, die zur Topologie gehören. Sling-Aufträge basieren auf dem Funktionsprinzip. Ein Auftrag wird durch sein Auftragsthema definiert. Um einen Auftrag auszuführen, muss eine Instanz einen Job Consumer für ein bestimmtes Auftragsthema bereitstellen. Das Auftragsthema ist die wichtigste Triebfeder des Verteilungsmechanismus.

Aufträge werden nur an die Instanzen verteilt, die einen Job Consumer für das Thema bieten. Durch Aktivieren/Deaktivieren der Job Consumer einer Instanz können Sie die Funktionen einer Instanz definieren und den Verteilungsmechanismus beeinflussen. Die verfügbaren Job Consumer einer Instanz werden an die gesamte Topologie übertragen.

In diesem Kontext bezieht sich der Begriff Verteilung auf die Zuweisung eines Auftrags zu einer bestimmten Instanz, die einen Job Consumer bereitstellt. Die Zuweisung zu einer Instanz wird im Repository gespeichert. Anders ausgedrückt: Sling-verteilte Aufträge können standardmäßig einer beliebigen Instanz in der Topologie zugewiesen werden. Allerdings können andere Aufträge nur von den Instanzen ausgeführt werden, die dasselbe Repository nutzen. Dies bedeutet, dass diese Aufträge ausschließlich von Instanzen ein und desselben Clusters ausgeführt werden können. Aufträge, die Instanzen eines anderen Clusters zugewiesen sind, werden nicht ausgeführt.

Granite-Abladeframework

Das Granite-Abladeframework ergänzt die Sling-Auftragsverteilung, um Aufträge, die Nicht-Cluster-Instanzen zugewiesen sind, auszuführen. Eine Verteilung (Instanzzuweisung) findet nicht statt. Jedoch werden an Nicht-Cluster-Instanzen verteilte Sling-Aufträge identifiziert und zwecks Ausführung an die Zielinstanz transportiert. Derzeit wird bei der Abladung für diesen Auftragstransport auf die Replikation zurückgegriffen. Zum Ausführen eines Auftrags werden im Rahmen der Abladung die Ein- und Ausgabe definiert, die dann in Kombination mit dem Auftrag zur Auftragsnutzlast werden.

Sling-verteilte Aufträge stellen das Auftrags- und Verteilungsframework bereit. Die Granite-Abladung übernimmt den Transport nur für den Sonderfall, dass Aufträge an Nicht-Cluster-Instanzen verteilt werden.

Neben dem Transport bietet das Abladeframework eine Erweiterung für die Workflow-Engine. Damit kann das Framework verteilte Aufträge als Teil des Workflows erstellen und auf deren Fertigstellung warten, bevor der Workflow fortgesetzt wird. Implementiert wird das Framework über die Workflow-API für externe Schritte der Workflow-Engine. Eine der Erweiterungen ermöglicht die generische Verteilung von Workflows. Die Verteilung einzelner Workflowschritte wird nicht unterstützt. 

Das Abladeframework wird zudem mit einer Benutzeroberfläche bereitgestellt, um die Aktivierung von Auftragsthemen über die gesamte Topologie hinweg zu visualisieren und zu steuern. Über die Benutzeroberfläche lässt sich die Themenaktivierung Sling-verteilter Aufträge bequem konfigurieren. Die Abladung kann auch ohne die Benutzeroberfläche eingerichtet werden.

Allgemeine Leitlinien und Best Practices für die Asset-Abladung

Jede Implementierung ist einzigartig und daher gibt es auch keine Universal-Abladekonfiguration. In den folgenden Abschnitten werden Leitlinien und Best Practices zum Abladen der Asset-Aufnahme beschrieben.

Die Asset-Abladung bedeutet einen Mehraufwand für das System, auch für den Betrieb. Wenn die Asset-Aufnahme zu einer Belastung mit entsprechenden Problemen führt, empfiehlt Adobe, zunächst die Konfiguration ohne Abladung zu optimieren. Ziehen Sie die folgenden Möglichkeiten in Betracht, bevor Sie sich für eine Asset-Abladung entscheiden:

  • Skalierung der Hardware
  • Optimierung von Workflows
  • Nutzung von Verlaufsworkflows
  • Beschränkung der für Workflows verwendeten Kernanzahl

Wenn Sie zu dem Schluss kommen, dass die Assets-Abladung ein für Sie geeigneter Ansatz ist, sollten Sie die folgenden Adobe-Leitlinien berücksichtigen:

  • Es wird eine TarMK-basierte Bereitstellung empfohlen.
  • Die TarMK-basierte Assets-Abladung ist nicht für eine übermäßige horizontale Skalierung vorgesehen.
  • Stellen Sie sicher, dass die Netzwerkleistung zwischen Autor und Workern zufriedenstellend ist.

Empfohlene Bereitstellung zur Assets-Abladung

Mit AEM und Oak sind verschiedene Bereitstellungszenarien möglich. Zur Assets-Abladung wird eine TarMK-basierte Bereitstellung mit freigegebenem Datenspeicher empfohlen. Die folgende Grafik zeigt die empfohlene Bereitstellung:

chlimage_1

Details zum Konfigurieren von Datenspeichern finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern in AEM.

Deaktivieren der automatischen Agentenverwaltung

Adobe empfiehlt eine Deaktivierung der automatischen Agentenverwaltung, weil diese keine Unterstützung für die nicht binäre Replikation bietet und zur Verwirrung beim Einrichten einer neuen Abladetopologie führen kann. Außerdem unterstützt sie nicht automatisch die Vorwärtsreplikation, die aber eine Voraussetzung für die nicht binäre Replikation ist.

  1. Öffnen Sie Configuration Manager über die URL http://localhost:4502/system/console/configMgr

  2. Öffnen Sie die Konfiguration für OffloadingAgentManager (http://localhost:4502/system/console/configMgr/com.adobe.granite.offloading.impl.transporter.OffloadingAgentManager).

  3. Deaktivieren Sie die automatische Agentenverwaltung.

Verwenden der Vorwärtsreplikation

Standardmäßig kommt beim Abladetransport die Rückwärtsreplikation zum Einsatz, um die abgeladenen Assets per Pull-Vorgang vom Worker zurück an den Master zu übertragen. Die Agenten für die Rückwärtsreplikation bieten keine Unterstützung für die nicht binäre Replikation. Sie sollten die Abladung zur Nutzung der Vorwärtsreplikation konfigurieren, um die abgeladenen Assets per Push-Vorgang zurück vom Worker an den Master zu übertragen.
  1. Wenn Sie von einer Standardkonfiguration mit Rückwärtsreplikation migrieren, deaktivieren oder löschen Sie alle Agenten namens „offloading_outbox“ und „offloading_reverse_*“ auf Master und Worker. Das Sternchen (*) steht dabei für die Sling-ID der Zielinstanz.

  2. Erstellen Sie auf jedem Worker einen Agenten für die Vorwärtsreplikation, der auf den Master verweist. Hierbei gehen Sie so vor wie beim Erstellen von Agenten für die Vorwärtsreplikation vom Master zum Worker. Anweisungen zum Einrichten von Replikationsagenten zur Abladung finden Sie unter Erstellen von Replikationsagenten zur Abladung.

  3. Öffnen Sie die Konfiguration für OffloadingDefaultTransporter (http://localhost:4502/system/console/configMgr/com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter).

  4. Ändern Sie den Wert der Eigenschaft default.transport.agent-to-master.prefix von offloading_reverse zu offloading.

Verwendung von freigegebenem Datenspeicher und nicht binärer Replikation zwischen Autor und Workern

Die nicht binäre Replikation wird empfohlen, um den transportbezogenen Mehraufwand bei der Asset-Abladung zu reduzieren. Weitere Informationen zum Einrichten der nicht binären Replikation für einen freigegebenen Datenspeicher finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern in AEM. Die Vorgehensweise ist bei der Assets-Abladung nicht anders, es sind lediglich andere Replikationsagenten beteiligt. Da die nicht binäre Replikation nur bei Agenten für die Vorwärtsreplikation funktioniert, sollten Sie zudem die Vorwärtsreplikation bei allen Abladeagenten einsetzen.

Deaktivieren von Transportpaketen

Standardmäßig wird beim Abladen ein Inhaltspaket erstellt, das den Abladeauftrag und die Auftragsnutzlast (das ursprüngliche Asset) enthält und dieses einzelne Abladepaket über eine einzige Replikationsanforderung transportiert. Die Erstellung dieser Abladepakete ist im Falle einer nicht binären Replikation kontraproduktiv, weil Binärdateien beim Erstellen des Pakets wieder in das Paket serialisiert werden. Die Verwendung von Transportpaketen kann deaktiviert werden, wodurch der Abladeauftrag und die Nutzlast in mehreren Replikationsanforderungen transportiert werden (jeweils eine für jeden Nutzlasteintrag). Auf diese Weise können Sie die Vorteile der nicht binären Replikation nutzen.

  1. Öffnen Sie die Komponentenkonfiguration der Komponente OffloadingDefaultTransporter unter http://localhost:4502/system/console/configMgr/com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter.

  2. Löschen Sie die Eigenschaft Replication Package (default.transport.contentpackage).

Deaktivieren des Transports von Workflow-Modellen

Standardmäßig fügt der Abladeworkflow Asset-Abladung für DAM-Update das Workflow-Modell hinzu, um den Worker für die Auftragsnutzlast aufzurufen. Da dieser Workflow standardmäßig dem vorkonfigurierten Modell DAM-Update-Asset folgt, kann diese zusätzliche Nutzlast entfernt werden.

Wenn das Workflow-Modell von der Auftragsnutzlast deaktiviert wird, achten Sie darauf, die Änderungen mithilfe anderer Tools, etwa Package Manager, an das referenzierte Workflow-Modell zu verteilen.

Um den Transport des Workflow-Modells zu deaktivieren, ändern Sie den Worfklow „Asset-Abladung für DAM-Update“.

  1. Öffnen Sie die Workflow-Konsole über http://localhost:4502/libs/cq/workflow/content/console.html.

  2. Öffnen Sie die Registerkarte „Modelle“.

  3. Öffnen die das Workflow-Modell „Asset-Abladung für DAM-Update“.

  4. Öffnen Sie die Schritteigenschaften für den Schritt „DAM-Workflow-Abladung“.

  5. Öffnen Sie die Registerkarte „Argumente“ und deaktivieren Sie die Optionen „Modell zu Eingabe hinzufügen“ und „Modell zu Ausgabe hinzufügen“.

  6. Speichern Sie die Änderungen am Modell.

Optimieren des Abrufintervalls

Die Workflow-Abladung wird über einen externen Workflow auf dem Master implementiert, der Abrufe für den Abschluss des Abladeworkflows auf dem Worker durchführt. Das standardmäßige Abrufintervall für die externen Workflowprozesse beträgt fünf Sekunden. Adobe empfiehlt, dass Sie das Abrufintervall des Assets-Abladeschritts auf mindestens 15 Sekunden erhöhen, um den abladebezogenen Mehraufwand auf dem Master zu reduzieren.

  1. Öffnen Sie die Workflow-Konsole über http://localhost:4502/libs/cq/workflow/content/console.html.

  2. Öffnen Sie die Registerkarte „Modelle“.

  3. Öffnen die das Workflow-Modell „Asset-Abladung für DAM-Update“.

  4. Öffnen Sie die Schritteigenschaften für den Schritt „DAM-Workflow-Abladung“.

  5. Öffnen Sie die Registerkarte „Allgemein“ und passen Sie den Wert der Eigenschaft „Zeitraum“ an.

  6. Speichern Sie die Änderungen am Modell.

Weitere Ressourcen

Dieses Dokument konzentriert sich auf die Asset-Abladung. Weitere Informationen zum Thema Abladung finden Sie u. a. in den folgenden Dokumenten:

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie