本頁面說明AEM的建議拓撲。 如需叢集功能及設定方式的詳細資訊,請參閱 Apache Sling Discovery API檔案.
從AEM 6.2開始,MicroKernels會充當持續性管理員。選擇符合您需求的部署型別,取決於執行個體的用途以及您考慮的部署型別。
以下範例旨在指出最常見的AEM設定中,建議使用哪些功能。
在此案例中,單一TarMK執行個體在單一伺服器上執行。
這是作者執行個體的預設部署。
優點:
缺點:
一個TarMK執行個體作為主要執行個體。 從主要儲存庫複製到待命容錯移轉系統。
冷待命機制也可以用作備份,因為完整的存放庫會持續複製到容錯移轉伺服器。 容錯移轉伺服器正在冷待命模式下執行,這表示只有執行個體的HttpReceiver在執行。
優點:
缺點:
如需如何設定AEM與TarMK冷待命的詳細資訊,請參閱 此 文章。
這個TarMK範例中的「冷待命」部署要求主要和待命執行個體都要分別授權,因為容錯移轉伺服器會持續進行復寫。 如需有關授權的詳細資訊,請參閱 Adobe一般授權條款.
多個Oak執行個體使用一個TarMK執行個體來執行。 TarMK存放庫是獨立的,需要保持同步。
製作伺服器會向每個伺服器陣列成員發佈相同的內容,因此可以保持存放庫同步。 如需詳細資訊,請參閱 復寫.
對於AEM Communities,永遠不會復寫使用者產生的內容(UGC)。 如需在TarMK伺服器陣列上支援UGC,請參閱 AEM Communities的考量事項.
這是發佈環境的預設部署。
優點:
此方法表示多個Oak執行個體在單一資料中心記憶體取MongoDB復本集,實際上為AEM製作環境建立主動 — 主動叢集。 MongoDB中的復本集用於在硬體或網路故障時提供高可用性和備援。
優點:
缺點:
此方法表示多個Oak執行個體可跨多個資料中心存取MongoDB復本集,實際上會為AEM製作環境建立主動 — 主動叢集。 MongoDB復寫功能具有多個資料中心,提供相同的高可用性和備援能力,但現在包括處理資料中心中斷的能力。
優點:
在上圖中,假設資料中心2的AEM伺服器與資料中心1的MongoDB主要節點之間的網路延遲高於記錄的需求,AEM Server 3和AEM Server 4會顯示非使用中狀態 此處. 如果最大延遲符合需求(例如透過使用可用區域),則資料中心2中的AEM伺服器也可以作用中,以建立跨多個資料中心作用中 — 作用中AEM叢集。
如需本節所述的MongoDB架構概念的其他資訊,請參閱 MongoDB復寫.
在兩個可用的微核心之間進行選擇時,需要考慮的基本規則是,TarMK是針對效能而設計,而MongoMK則是針對擴充性而設計。
您可以使用這些決策矩陣,以建立適合您需求的最佳部署型別。
Adobe強烈建議客戶在AEM Author和Publish例項的所有部署情境中,將TarMK設為預設持續性技術,但下列使用案例除外。
選擇MongoMK持續性後端而非TarMK的主要原因是要水平縮放執行個體。 這表示需讓兩個或多個作用中的製作執行個體隨時執行,並使用MongoDB作為持續性儲存系統。 執行多個製作執行個體的需求通常源自於單一伺服器的CPU和記憶體容量(支援所有並行製作活動)已無法持續。
幾乎無法預測新網站上線後確切的並行模式。 因此,Adobe建議您在評估是否使用MongoMK和兩個或更多「創作」作用中節點時,考慮以下標準:
在部署硬體設定的情況下,可使用嚴苛日來評估客戶應用程式的效能。 有關此工具的更多資訊,請檢視 此處.
使用MongoDB的最低部署通常涉及以下拓撲:
此外,強烈建議您在共用檔案系統或Amazon S3上設定資料存放區,好讓資產或二進位檔不會儲存在MongoDB中。 這將確保部署中的最佳效能。
部署具有兩個或多個製作執行個體叢集的MongoDB復本集的額外優點之一,是在製作執行個體、MongoDB復本或完整資料中心故障的情況下,具有自動化復原案例,停機時間最短。 儘管如此,選擇MongoMK而非TarMK不應完全由復原需求所驅動,因為TarMK也可以提供具備受控容錯移轉機制的最小停機解決方案。
如果在部署的前18個月中不符合上述標準,建議先使用TarMK部署AEM,稍後當上述標準適用時重新評估您的設定,最後決定是否留在TarMK上或移轉至MongoMK。
不建議為發佈執行個體部署MongoMK。 部署的發佈層級幾乎總是部署為執行TarMK的完全獨立發佈執行個體的陣列,透過從製作執行個體複製內容來保持同步。 這種「不共用」架構適用於發佈執行個體,可讓發佈層級的部署以線性方式水準擴展。 伺服器陣列拓撲還提供滾動式套用任何更新或升級至發佈執行個體的優點,因此對發佈層級的任何變更都不需要停機。
只要有一個以上的發佈者,這不適用於在發佈層級上使用MongoMK叢集的AEM Communities。 若選擇JSRP (請參閱 社群內容儲存),則MongoMK叢集將是合適的,就像任何已選擇MK的發佈端叢集(例如MongoDB或RDB)一樣。
如果您考慮使用AEM的MongoMK部署,有一組必要條件和建議可供使用:
MongoDB部署的必要先決條件:
MongoDB部署的強大建議:
如需這些指引、先決條件和建議的所有其他問題,請聯絡 Adobe客戶服務.
針對計畫部署的網站 AEM Communities,建議 選擇部署 針對處理發佈環境中的社群成員張貼的UGC進行最佳化。
透過使用 公用存放區,不需要在作者和其他發佈執行個體之間復寫UGC就能取得UGC的一致檢視。
以下是一組決策矩陣,可協助您為部署選擇最佳型別的持續性:
MongoDB是協力廠商軟體,未包含在AEM授權套件中。 如需詳細資訊,請參閱 MongoDB授權原則 頁面。
為了充分利用AEM部署,Adobe建議授權MongoDB Enterprise版本,以受益於專業支援。
授權包含標準復本集,該復本集由一個主要和兩個次要執行個體組成,可用於作者或發佈部署。
如果您想要在MongoDB上同時執行author和publish,則需要購買兩個不同的授權。
如需詳細資訊,請參閱 適用於Adobe Experience Manager的MongoDB頁面.