建議的部署

MicroKernels在AEM 6.4中充當持續性管理程式。選擇一個以滿足您的需求取決於實例的用途和您考慮的部署類型。

以下範例旨在說明在最常見的AEM設定中其建議用途。

部署方案

單一TarMK例項

在此案例中，單一TarMK執行個體會在單一伺服器上執行。

這是製作例項的預設部署。

優點：

• 簡單
• 輕鬆維護
• 效能良好

缺點是：

• 無法擴展到超出伺服器容量限制
• 無故障轉移容量

TarMK冷備用

一個TarMK執行個體作為主要執行個體。 將主資料庫中的儲存庫複製到備用故障切換系統。

冷備用機制也可用作備份，因為完整的儲存庫會不斷複製到故障轉移伺服器。 故障轉移伺服器以冷待機模式運行，這意味著只運行實例的HttpReceiver。

優點：

• 簡單
• 可維護性
• 效能
• 故障轉移

缺點是：

• 無法擴展到超出伺服器容量限制
• 大部分時間，一個伺服器處於空閒狀態
• 故障轉移不是自動的。 必須在故障轉移系統開始提供請求之前從外部檢測到它。

TarMK農場

各執行多個Oak例項，並搭配一個TarMK例項。 TarMK存放庫獨立，需保持同步。

讓存放庫保持同步，是因為製作伺服器會將相同內容發佈給每個伺服器陣列成員。 如需詳細資訊，請參閱 復寫.

若為AEM Communities，則不會復寫使用者產生的內容(UGC)。 如需在TarMK伺服器陣列上支援UGC，請參閱 AEM Communities的考量事項.

這是發佈環境的預設部署。

優點：

• 效能
• 讀取訪問的可擴充性
• 故障轉移

具有MongoMK故障切換的Oak群集，在單個資料中心實現高可用性

此方法表示有多個Oak執行個體會存取單一資料中心內的MongoDB復本集，實際上會為AEM製作環境建立作用中叢集。 MongoDB中的副本集用於在發生硬體或網路故障時提供高可用性和冗餘。

優點：

• 可使用新的AEM製作例項水準縮放
• 資料層的高可用性、冗餘和自動故障切換

缺點是：

• 某些情況下的效能可能低於TarMK

具有跨多個資料中心的MongoMK故障轉移的Oak群集

此方法表示有多個Oak執行個體會存取跨多個資料中心的MongoDB復本集，實際上會為AEM製作環境建立作用中叢集。 MongoDB複製具有多個資料中心，可提供相同的高可用性和冗餘，但現在包括了處理資料中心中斷的能力。

優點：

• 可使用新的AEM製作例項水準縮放
• 資料層的高可用性、冗餘和自動故障切換（包括資料中心停機）

微內核：使用

在兩個可用的微內核之間進行選擇時需要考慮的基本規則是TarMK是為效能而設計，而MongoMK是為可擴充性而設計。

您可以使用這些決策矩陣來建立最適合您需求的部署類型。

Adobe強烈建議，除下列使用案例外，TarMK為客戶在所有部署案例（AEM製作和發佈執行個體）中使用的預設永續性技術。

在製作執行個體上選擇AEM MongoMK而非TarMK的例外

選擇MongoMK永續性後端而不選擇TarMK的主要原因是橫向縮放執行個體。 這表示有兩個或多個活動的作者實例始終運行，並使用MongoDB作為持久性儲存系統。 執行多個製作執行個體的需求，一般是因為單一伺服器的CPU和記憶體容量（支援所有同時編寫活動）已無法持續。

很難預測新網站上線後的確切並行模型。 因此，Adobe建議您在評估是否使用MongoMK和兩個或兩個以上製作作用中節點時，考慮下列條件：

1. 一天內連接的指定用戶數：數以千計。
2. 同時使用者人數：數以百計甚至更多。
3. 每日資產擷取量：數十萬甚至更多。
4. 每天編輯頁面的數量：數十萬或更多（包括透過多網站管理員或新聞摘要擷取的自動更新）。
5. 每天的搜索量：數以萬計甚至更多。

使用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），任何發佈端叢集都適用。

使用MongoMK部署AEM時的必要條件和Recommendations

如果您考慮為AEM部署MongoMK，則可使用一組必要條件和建議：

MongoDB部署的必要條件：

1. 在熟悉AEM的Adobe諮詢或MongoDB架構師的協助下，MongoDB部署架構和規模調整必須是專案實作的一部分；
2. MongoDB的專業知識必須存在於合作夥伴或客戶團隊中，以便有信心能夠維持和維護現有的或新的MongoDB環境；
3. 您可以選擇部署商業或開放原始碼版本的MongoDB(AEM支援兩者)，但必須直接從MongoDB公司購買MongoDB維護和支援合同；
4. 總的AEM和MongoDB體系結構和基礎架構應由AdobeAEM Architect進行明確定義和驗證；
5. 您必須檢閱包含MongoDB之AEM部署的支援模型。

強大的MongoDB部署建議：

• 請參閱Adobe Experience Manager適用的MongoDB 文章;
• 查看MongoDB生產 清單;
• 參加線上提供的MongoDB認證課程 此處.

AEM Communities考量事項

針對計畫部署的站點 AEM Communities，則建議 選擇部署 針對處理社群成員從發佈環境張貼的UGC而最佳化。

使用 公用商店，就不需要在製作執行個體與其他發佈執行個體之間複製UGC，即可取得UGC的一致檢視。

以下是一組決策矩陣，可幫助您為部署選擇最佳類型的持久性：

選擇製作例項的部署類型

選擇發佈實例的部署類型

Business.Adobe.com 資源

Ecommerce Integrations Automated Onboarding Style System Cms Cloud Customer Communications Asset Collections