建議的部署
本頁參考AEM的建議拓撲。 如需叢集功能以及如何設定的詳細資訊，請參閱Apache Sling Discovery API檔案。
從AEM 6.2開始，MicroKernels就是永續性管理程式。選擇符合您需求的項目取決於您實例的用途以及您考慮的部署類型。
下列範例旨在指出他們在最常見AEM設定中的建議用途。
部署方案
單一TarMK實例
在此案例中，單一TarMK執行個體會在單一伺服器上執行。
這是作者例項的預設部署。
優點：
- 簡單
- 輕鬆維護
- 良好的效能
缺點是：
- 不能超出伺服器容量的限制
- 無故障切換容量
TarMK冷備用
一個TarMK實例用作主實例。 主系統中的儲存庫被複製到備用故障切換系統。
冷備用機制也可用作備份，因為完整的儲存庫會不斷複製到故障切換伺服器。 故障轉移伺服器以冷備用模式運行，這意味著只運行實例的HttpReceiver。
優點：
- 簡單
- 可維護性
- 效能
- 故障切換
缺點是：
- 不能超出伺服器容量的限制
- 大部分時間內，一個伺服器處於空閒狀態
- 故障切換不是自動的。 必須在外部檢測到它，故障切換系統才能開始服務請求。
如需如何使用TarMK Cold Standby設定AEM的詳細資訊，請參閱this文章。
此TarMK示例中的Cold Standby部署要求主實例和備用實例都分別獲得許可，因為故障切換伺服器會不斷複製。 如需授權的詳細資訊，請參閱Adobe一般授權條款。
TarMK Farm
每個Oak例項會以一個TarMK例項執行。 TarMK儲存庫是獨立的，需要保持同步。
使儲存庫保持同步的前提是作者伺服器正在向每個群成員發佈相同的內容。 有關詳細資訊，請參見Replication。
對於AEM Communities，使用者產生的內容(UGC)不會複製。 如需支援TarMK農場的UGC，請參閱 AEM Communities的考量事項。
這是發佈環境的預設部署。
優點：
- 效能
- 讀取存取的可擴充性
- 故障切換
具有MongoMK故障轉移的Oak Cluster，在單個資料中心中實現高可用性
此方法表示在單一資料中心記憶體取MongoDB複製集的多個Oak例項，實際上為AEM作者環境建立作用中叢集。 MongoDB中的複製副本集用於在發生硬體或網路故障時提供高可用性和冗餘。
優點：
- 可使用新的AEM作者例項水準縮放
- 資料層的高可用性、冗餘和自動故障切換
缺點是：
- 在某些情況下，效能可能低於TarMK
Oak Cluster，具有跨多個資料中心的MongoMK故障切換
此方法意味著多個Oak實例訪問跨多個資料中心的MongoDB複製副本集，實際上是為AEM作者環境建立活動——活動群集。 MongoDB複製具有多個資料中心，可提供相同的高可用性和冗餘，但現在還包括了處理資料中心停機的能力。
優點：
- 可使用新的AEM作者例項水準縮放
- 資料層的高可用性、冗餘和自動故障切換（包括資料中心停機）
有關本節中介紹的MongoDB體系結構概念的其他資訊，請參見 MongoDB Replication。
微內核：哪一個使用
在兩個可用的微內核之間選擇時需要考慮的基本規則是TarMK是為效能而設計，而MongoMK是為可擴充性而設計。
您可以使用這些決策表來建立最適合您需求的部署類型。
Adobe強烈建議TarMK為所有部署案例（AEM Author和Publish執行個體）中客戶使用的預設永續性技術，但下列使用案例除外。
在作者例項上選擇AEM MongoMK而非TarMK的例外
選擇MongoMK持久性後端而非TarMK的主要原因是水準縮放實例。 這表示有兩個或兩個以上的活動作者實例始終運行，並使用MongoDB作為持久性儲存系統。 執行多個作者執行個體的需求，通常是因為單一伺服器的CPU和記憶體容量支援所有並行編寫活動，已不再持續。
在新網站上線後，幾乎無法預測確切的並行模式。 因此，Adobe建議您在評估是否使用MongoMK和兩個或兩個以上「作者」活動節點時，考慮下列准則：
- 一天中連接的指名用戶數：數以千計。
- 並行用戶數：數以百計。
- 每日資產收錄量：數十萬甚至更多。
- 每天編輯的頁數量：數以十萬計（例如透過多網站管理員或新聞摘要擷取的自動更新）。
- 每日搜尋量：數以萬計甚至更多。
Tough Day can be used to evaluate the performance of the customer's application in the context of the hardware configuration deployed. 有關此工具的詳細資訊，請參閱此處。
使用MongoDB的最低部署通常涉及以下拓撲：
- 一個MongoDB複製副本集由一個主節點、兩個輔助節點組成，每個MongoDB實例在可用區中運行，每個節點的延遲低於15毫秒；
- 一個作者實例群集，其中一個領導節點、一個非領導節點，並且兩者始終處於活動狀態，每個作者實例在每個資料中心中運行，其中MongoDB主實例和輔助實例正在運行。
此外，強烈建議在共用檔案系統或Amazon S3上配置資料儲存，這樣資產或二進位檔案就不會儲存在MongoDB中。 這將確保部署中的最佳效能。
部署具有兩個或多個作者實例的群集的MongoDB複製副本集的額外好處之一是，在作者實例、MongoDB複製副本或完全資料中心故障的情況下，具有自動恢復情形，停機時間最短。 不過，選擇MongoMK而不是TarMK不應僅由恢復要求驅動，因為TarMK還可以提供具有受控故障切換機制的最短停機時間解決方案。
如果上述標準預期在部署的前18個月內未達成，建議您先使用TarMK部署AEM，然後在日後適用上述標準時重新評估您的設定，最後決定是要保留在TarMK上或移轉至MongoMK。
在發佈例項上選擇AEM MongoMK而非TarMK的例外
不建議為發佈例項部署MongoMK。 部署的發佈層幾乎總是部署為運行TarMK的完全獨立的發佈實例群，這些實例通過從作者實例複製內容保持同步。 此「無共用」架構適用於發佈例項，可讓發佈層的部署以線性方式水準縮放。 農場拓撲還提供了以滾動方式應用任何更新或升級來發佈實例的好處，這樣對發佈層的任何更改都不需要停機。
當發佈層有多個發佈者時，這不適用於使用MongoMK叢集的AEM Communities。 如果選擇JSRP（請參閱社群內容儲存），則MongoMK叢集將適合，與任何發佈端叢集一樣，不論選擇的MK如MongoDB或RDB。
部署AEM與MongoMK時的先決條件和建議
如果您正在考慮針對AEM部署MongoMK，則可使用一組先決條件和建議：
MongoDB部署的必要先決條件：
- 在熟悉AEM的Adobe Consulting或MongoDB Architects的協助下，MongoDB部署架構和規模調整必須是專案實作的一部分；
- MongoDB的專業知識必須存在於合作夥伴或客戶團隊中，以便有信心能夠維持和維護現有或新的MongoDB環境；
- 您可以選擇部署MongoDB（AEM支援兩者）的商業版或開放原始碼版本，但必須直接向MongoDB Inc;
- 整體AEM和MongoDB架構與基礎架構應由Adobe AEM Architect妥善定義與驗證；
- 您必須檢閱包含MongoDB的AEM部署支援模型。
MongoDB部署的強烈建議：
有關這些准則、先決條件和建議的所有其他問題，請聯絡Adobe客戶服務。
AEM Communities的考量事項
對於計畫部署AEM Communities的網站，建議選擇最佳化部署，以處理社群成員從發佈環境張貼的UGC。
通過使用公共儲存,UGC不需要在作者和其他發佈實例之間複製，以獲得UGC的一致視圖。
以下是一組決策矩陣，可協助您選擇部署的最佳永續性類型：
選擇作者實例的部署類型
選擇發佈實例的部署類型
MongoDB是協力廠商軟體，不包含在AEM授權套件中。 如需詳細資訊，請參閱MongoDB授權政策頁面。
為了充份運用您的AEM部署，Adobe建議您授權MongoDB企業版，以便從專業支援中獲益。
該許可證包括一個標準副本集，該副本集由一個主實例和兩個輔助實例組成，可用於作者或發佈部署。
如果您想要在MongoDB上執行作者和發佈，則需要購買兩個不同的授權。
如需詳細資訊，請參閱MongoDB for Adobe Experience Manager頁面。