本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 選擇執行個體類型並進行測試
在您計算您的儲存需求並選擇所需的碎片數之後，您可以開始做出硬體的決策。硬體需求會依工作負載而大大不同，但是我們仍然可以提供一些基本建議。
一般而言，每個執行個體類型的[儲存限制](limits.md)都會對應到您對於輕量型工作負載可能需要的 CPU 和記憶體量。例如，某個 `m6g.large.search` 執行個體具有最大 512 GiB 的 EBS 磁碟區大小、2 個 vCPU 核心和 8 GiB 的記憶體。如果您的叢集有許多碎片，執行課稅彙總、頻繁更新文件或處理大量的查詢，這些資源可能不足以滿足您的需求。如果您的叢集是這些類別之一，請嘗試針對您的每個 100 GiB 的儲存需求從組態較接近 2 個 vCPU 核心和 8 GiB 的記憶體開始。
**提示**
如需分配給每個執行個體類型的硬體資源的摘要，請參閱 [Amazon OpenSearch Service 定價](https://aws.amazon.com/opensearch-service/pricing/)。
然而，即使這些資源可能會也不夠。有些 OpenSearch 使用者回報告他們很多次需要這些資源來滿足他們的需求。若要尋找適用於您的工作負載的合適硬體，您必須有明智的初始預估、測試代表的工作負載、進行調整並再次執行測試。
## 步驟 1：進行初步預估
若要開始，建議您使用至少三個節點，以避免潛在的 OpenSearch 問題，例如*大腦分割*狀態 (當通訊時間流逝導致具有兩個主節點的叢集時)。如果您有三個[專用主節點 ](managedomains-dedicatedmasternodes.md)，我們仍然建議您至少有兩個資料節點用於複寫。
## 步驟 2：計算每個節點的儲存需求
如果您有 184 GiB 的儲存需求和建議的至少三個節點，請使用方程式 184 / 3 = 61 GiB 算出每個節點所需的儲存量。在此範例中，您可以選取三個 `m6g.large.search` 執行個體，其中每個執行個體都分別使用 90 GiB 的 EBS 儲存磁碟區，讓您對於隨時間的成長擁有安全網路以及一些空間可供因應。這種組態提供 6 個 vCPU 核心和 24 GiB 的記憶體，所以適合較輕量型的工作負載。
針對更高額度的範例，則假設是儲存需求為 14 TiB (14,336 GiB) 的繁重工作負載。在這種情況下，您可以選擇開始測試 2 \$1 144 = 288 個 vCPU 核心和 8 \$1 144 = 1152 GiB 的記憶體。這些數字運作大約 18 個 `i3.4xlarge.search` 執行個體。如果您不需要快速的本機儲存，也可以測試 18 個 `r6g.4xlarge.search` 執行個體，各使用 1 TiB 的 EBS 儲存磁碟區。
如果您的叢集包含數百 TB 的資料，請參閱 [Amazon OpenSearch Service 的 PB 規模](petabyte-scale.md)。
## 步驟 3：執行代表性測試
設定叢集後，您可以使用您稍早計算的碎片數來[新增您的索引](indexing.md)、使用真實資料集來執行一些代表性的用戶端測試，以及[監控 CloudWatch 指標](managedomains-cloudwatchmetrics.md)來查看叢集處理工作負載的方式。
## 步驟 4：成功或反覆
如果效能滿足您的需求，表示測試成功且 CloudWatch 指標正常，叢集就已就緒可供使用。請記得[設定 CloudWatch 警示](cloudwatch-alarms.md)，以偵測狀況不良的資源使用。
如果無法接受該效能，表示測試失敗或者 `CPUUtilization` 或 `JVMMemoryPressure` 偏高，您可能需要選擇不同的執行個體類型 (或新增執行個體)，並繼續進行測試。在您新增執行個體時，OpenSearch 會自動重新均衡整個叢集中碎片的分佈。
由於這在動力過強的叢集中測量過剩容量比在動力不足的叢集中測量欠缺容量來得容易，我們建議您從比您所需較大的叢集開始。接著，進行測試並縮減到有額外資源可確保在增加活動期間有穩定操作的有效率叢集。
生產叢集或狀態複雜的叢集受益於[專用主節點](managedomains-dedicatedmasternodes.md)，可提升效能和叢集可靠性。