硬體尺寸建議 hardware-sizing-reco
概覽
本檔案提供在內部部署資料中心或虛擬雲端環境進行Adobe Campaign Classic v7部署的一般建議。 此型別的部署（稱為 混合 或 中間來源）會將Campaign行銷執行個體和行銷資料庫置於您的營運控制之下，同時使用Adobe雲端傳訊服務來傳送電子郵件、簡訊或SMPP訊息，並收集電子郵件開啟、彈回和點選追蹤資料。
行銷執行個體是Adobe Campaign架構的一部分，可驅動所有行銷活動，並儲存行銷活動傳回的所有收件者資料和分析資料。 行銷執行個體是一組執行Adobe Campaign服務的內部部署伺服器，以及一個關聯式資料庫。
軟體相容性在相容性矩陣中有詳細說明。
情境
針對下列三種代表性案例，提供部署圖表和硬體調整建議：
- 中等大小 — 系統中有500萬個使用中的收件者
- 大型 — 系統中有2,000萬個使用中的收件者
- Enterprise - 5,000萬名使用中的收件者，包含交易式訊息
假設
本檔案也會假設以下三種情況的使用型別：
- 大型電子郵件行銷活動每週傳送兩次，大約傳送給50%活躍的收件者
- 系統每個收件者每月會產生一次直接郵件
- SMS訊息每月會傳送給約10%的有效收件者
- 定義每個收件者的資料庫結構描述已擴充一個額外的表格，包含每個收件者的約200位元組資料
- Adobe Campaign互動模組用於將優惠方案新增至傳出電子郵件
- 電子郵件追蹤資料會在Campaign系統中保留90天
一般准則
Campaign是以資料庫為中心的應用程式，資料庫伺服器效能至關重要。 執行工作流程、細分、追蹤資料上傳、傳入互動、分析和其他活動都會產生資料庫活動。 一般而言，這些作業的大小和頻率會決定資料庫伺服器的大小。
行銷執行個體中的應用程式伺服器需要足夠的CPU和記憶體來執行工作流程並回應SOAP API呼叫，包括Campaign主控台使用者的請求。 對於使用具有複雜選件規則的對外互動的工作流程、執行自訂Javascript的工作流程以及具有高流量層級的網頁應用程式，CPU需求可能會相當高。
Campaign網頁應用程式也可以部署在行銷執行個體的應用程式伺服器上，或部署在個別的網頁伺服器系統上。 由於Web應用程式工作負載會與關鍵工作流程和Campaign Console使用者發生衝突，因此Web應用程式和傳入互動可部署至個別伺服器，以確保核心Campaign功能以良好的效能可靠地執行。
為了安全性和可用性，Adobe建議將網際網路流量與業務使用者產生的流量分開。 因此，圖表包含兩組伺服器：網頁伺服器（面對網際網路的Web1和Web2）以及應用程式伺服器（業務流程App1和App2）。
對於商業電子郵件寄件者，法律規定必須有功能性的選擇退出網頁。 Adobe建議在容錯移轉情況中，於每個群組伺服器中配置備援電腦。 如果Adobe Campaign託管選擇退出頁面，情況尤其如此。
反向代理
Campaign架構會使用HTTP上的SSL (HTTPS)來在行銷執行個體與Adobe雲端訊息之間通訊，以強化高安全性。 在「非軍事區域」(DMZ)子網路中使用反向代理來隔離行銷執行個體伺服器和資料庫，確保安全性、可靠性和可用性。
負載平衡器
應用程式伺服器的負載平衡器是以主動/被動設定來設定，且HTTPS會在Proxy終止。 Web伺服器的負載平衡器是以主動/主動設定來設定，且HTTPS會在Proxy終止。
Adobe提供可在您的部署環境中轉送至Adobe Campaign伺服器的URL路徑專屬清單。
架構
無論磁碟區為何，一般架構幾乎完全相同。 安全性和高可用性需求要求至少有四台伺服器；若未使用WebApps，則有兩台伺服器。 組態差異主要在於硬體組態，例如CPU核心和記憶體。
案例1：中型部署 scenario-1
預估數量：
針對這些磁碟區，一對Adobe Campaign應用程式伺服器系統為Adobe Campaign使用者端使用者和工作流程執行提供所有功能。 對於500萬使用中的收件者及此電子郵件容量而言，應用程式伺服器工作負載不會耗費大量的CPU或I/O；大部分的壓力都在於資料庫。
Adobe Campaign Web伺服器會顯示在安全區域中。
Web與應用程式伺服器
此情境建議您在四部機器上安裝Adobe Campaign，規格如下：
3Ghz+四核心CPU、8-GB RAM、RAID 1或10、2 x 80-GB固態硬碟
這些系統會建立行銷執行個體應用程式伺服器，直接支援您的Campaign Console使用者並執行行銷活動工作流程。
在DMZ中反向代理，以平衡流量至Adobe Campaign Web伺服器。 不需要在Proxy機器上安裝Adobe Campaign軟體棧疊；可以使用任何反向Proxy軟體或網路裝置。
訂閱選擇加入/選擇退出和偏好設定中心功能可由Campaign或您自己的網站提供。 如果您選擇在您的網站上實作此功能，您必須確保偏好設定和訂閱資訊會傳播至Campaign行銷資料庫。 通常透過建立由Campaign工作流程自動上傳的擷取檔案來完成。
應用程式伺服器的磁碟空間耗用量取決於與協力廠商服務提供者（例如直接郵件的列印廠商）交換的檔案保留時間，以及匯入的平面檔案大小和保留，例如您網站的訂閱或偏好設定更新，或是從您自己的CRM或行銷系統擷取。
資料庫
資料庫伺服器的硬體建議如下：
3Ghz+ 4核心CPU，16-GB RAM，RAID 1或10,128GB固態硬碟，最低
記憶體預估值假設大型行銷活動啟動時會完全快取約500,000個收件者，加上RDBMS緩衝區空間，以執行工作流程、匯入追蹤資料和其他並行活動。
根據三個月的保留期，估計資料庫儲存所有Adobe Campaign技術資料（行銷活動、追蹤、工作表等）所需的磁碟空間約為35 GB。 如果您選擇保留6個月的追蹤資料，資料庫大小會增加到大約40 GB，而12個月的保留會將資料庫大小增加到大約45 GB。 此環境的收件者資料消耗約5 GB。
另外也考慮到由於每天處理的資訊量大，資料庫伺服器的IOPS非常關鍵。 例如，在高峰日，您可以部署目標為總計500,000位收件者的行銷活動。 為了執行每個行銷活動，Adobe Campaign會將500,000筆記錄插入包含約1,200萬筆記錄的表格（傳送記錄表格）。 為了在行銷活動部署期間提供可接受的效能，Adobe建議此情境下至少60,000個4-KB隨機讀取/寫入IOPS。
案例2：大型部署 scenario-2
預估數量：
Web與應用程式伺服器
在此案例中，Adobe建議您在四部電腦、兩部應用程式伺服器和兩部Web伺服器上安裝Adobe Campaign，規格如下：
3Ghz+四核心CPU、8-GB RAM、RAID 1或10、80-GB固態硬碟
應用程式伺服器會直接支援Campaign Console使用者以及行銷活動工作流程的執行。 此功能部署在兩台相同的伺服器上，以提供高可用性，共用網路連線儲存(NAS)檔案系統以啟用容錯移轉。
網頁伺服器託管Campaign網頁應用程式，支援系統中的1000萬作用中收件者。
請參閱案例1：中等大小部署，以取得代理程式、喜好設定中心/訂閱處理及磁碟空間使用量的更多註解。
資料庫
資料庫伺服器的硬體建議如下：
3Ghz+ 8核心CPU、64GB RAM、RAID 1或10、2個320GB固態硬碟或RAID 10、640GB固態硬碟，最少
記憶體預估值假設大型行銷活動啟動時，約有5,000,000位收件者會完全快取，加上用於執行工作流程、匯入追蹤資料和其他並行活動的RDBMS緩衝區空間。
根據3個月的保留期，估計資料庫儲存所有Adobe Campaign技術資料（行銷活動、追蹤、工作表等）所需的磁碟空間約為280 GB。 如果您選擇保留6個月的追蹤資料，資料庫大小會增加到大約450 GB，而12個月的保留會將資料庫大小增加到大約900 GB。 此環境的收件者資料消耗約15 GB。
案例3：使用訊息中心的企業部署 scenario-3
預估數量：
支援5000萬收件者的部署基本上與案例2中所示相同：行銷活動網頁應用程式流量會路由至Campaign網頁伺服器，所以大型行銷活動啟動後爆發的網頁流量不會影響Campaign工作流程和Client Console使用者。
此部署還包括從您自己的網站和應用程式驅動的訊息中心呼叫。
Web與應用程式伺服器
在此案例中，Adobe建議在四部機器上安裝Adobe Campaign，如下所示：
-
應用程式伺服器
兩個系統，3Ghz+四核心CPU，8-GB RAM，RAID 1或10,80-GB固態硬碟 -
Web 伺服器
兩個系統，3Ghz+四核心CPU，16-GB RAM，RAID 1或10,80-GB固態硬碟
應用程式伺服器會直接支援Campaign Console使用者以及行銷活動工作流程的執行。 此功能部署在兩台相同的伺服器上，以提供高可用性，共用網路連線儲存(NAS)檔案系統以啟用容錯移轉。
網頁伺服器託管Campaign網頁應用程式，支援系統中的1000萬作用中收件者。
請參閱案例1：中等大小部署，以取得代理程式、喜好設定中心/訂閱處理及磁碟空間使用量的更多註解。
資料庫
資料庫伺服器的硬體建議如下：
3Ghz+ 8核心CPU，96-GB RAM，RAID 1或10,1.5TB固態硬碟，最少
記憶體預估值假設大型行銷活動啟動時，約有12,500,000位收件者會完全快取，加上RDBMS緩衝區空間，以用於執行工作流程、匯入追蹤資料和其他並行活動。
根據3個月的保留期，估計資料庫儲存所有Adobe Campaign技術資料（行銷活動、追蹤、工作表等）所需的磁碟空間約為700 GB。 如果您選擇保留6個月的追蹤資料，資料庫大小會增加到大約1.2TB，而12個月的保留會將資料庫大小增加到大約2TB。 此環境的收件者資料消耗約50 GB。
變更假設的准則
針對這些情況所做的假設都會對硬體建議和部署架構產生重大影響。 本節將討論不同假設的相關指引。 如需符合您需求的特定建議，請聯絡Adobe Campaign諮詢團隊。
-
收件者數目
作用中的收件者同時需要儲存空間與資料庫緩衝區空間，因此較多的收件者通常需要資料庫伺服器上的更多記憶體與CPU容量。 收件者的儲存空間增加相對較小，但對於保留用於電子郵件促銷活動的事件追蹤資料而言，可能十分重要。 -
電子郵件行銷活動大小
行銷活動啟動的頻率會影響資料庫伺服器CPU需求。 結合直接郵寄、傳入互動和其他工作流程，電子郵件促銷活動的細分作業會對資料庫伺服器造成大量負載。 -
直接郵件頻率
直接郵寄的頻率會影響資料庫伺服器CPU需求。 結合行銷活動啟動和其他工作流程，直接郵件的分段作業會對資料庫伺服器造成大量負載。 -
SMS訊息音量
就像電子郵件促銷活動大小一樣，SMS訊息數量不會大幅增加位於內部部署的Campaign伺服器上的負載；負載大多位於雲端上的Adobe雲端傳訊伺服器上。 SMS行銷活動（例如電子郵件和直接郵件）的區段可能會對行銷資料庫造成大量負載。 因此，SMS行銷活動的啟動頻率和區段的複雜性比SMS訊息的數量更相關。 -
資料庫結構描述複雜性
每個作用中收件者的資料量需要儲存空間與資料庫緩衝區空間，因此較多的收件者通常需要資料庫伺服器上的記憶體與CPU。 複雜的結構描述也需要聯結更多表格才能進行分段，因此分段作業的執行速度會更慢，而且當資料散佈在多個表格時，需要更多資料庫CPU和記憶體。資料庫伺服器記憶體的預估方法是，確保資料庫緩衝區集區足夠大，可以包含所有收件者資料，再加上執行工作流程的臨時表格，以及其他資料庫作業的利潤。
-
傳出互動使用量
在將所有計算複雜性移交給資料庫的工作流程中，會評估批次模式下的互動規則。 資料庫上主要的成果是在一個引擎呼叫期間計算的合格優惠方案總數（目標大小X每個收件者的平均優惠方案數，之後保留N個最佳優惠方案）。 資料庫伺服器CPU速度是效能的第一個因素。 -
傳入互動或SOAP API使用量
傳入互動規則和選件會在行銷資料庫中評估，需要大量的資料庫伺服器資源，特別是CPU。 大量使用傳入互動或SOAP API需要個別的網頁伺服器，以將工作負載和執行行銷活動工作流程分開。 -
追蹤資料保留期間
若要將追蹤資料的保留時間延長到90天以上，需要更多的資料庫儲存空間，而且插入新的追蹤資料會進入大型資料表，因此會拖慢系統速度。 90天後的行銷活動分段不適用追蹤資料，因此建議使用較短的保留期間。如果您需要長期分析收件者的行銷體驗，應將追蹤資料移至Adobe Analytics或其他Analytics系統。
虛擬化
所有Campaign伺服器都是適合虛擬化的候選伺服器。 必須解決幾個問題，以確保適當的可用性和效能。
-
容錯移轉組態
叢集伺服器（例如負載平衡Proxy下的備援應用程式伺服器）必須部署在個別的硬體上，以確保在硬體故障時，兩個VM都不會停機。 -
I/O組態
必須維護任何建議的RAID組態，以確保儲存裝置遺失不會造成資料遺失。 -
I/O效能
必須遵循資料庫儲存的建議的IOPS評等。 Amazon EC2等雲端服務可能無法提供所需的效能，必須仔細評估。 例如，Amazon EC2布建的SSD磁碟區目前每個的評等為20,000 IOPS。 在Amazon檔案)中瞭解更多，因此4磁區RAID組態的評等為80,000 IOPS，這可能還不夠。
Adobe建議在投入生產之前，針對Adobe Campaign的任何虛擬化部署進行效能測試。