調整 Amazon OpenSearch 服務域 - Amazon OpenSearch 服務
計算儲存需求選擇碎片數選擇執行個體類型並進行測試

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

調整 Amazon OpenSearch 服務域

沒有完美的方法來調整 Amazon OpenSearch 服務域的大小。不過，從瞭解您的儲存需求、服務及 OpenSearch 本身開始，您就可以針對硬體需求做出明智的初步估計。此預估可以做為調整網域大小最關鍵環節的實用起點：使用代表性工作負載進行測試和監控其效能。

計算儲存需求

大多數 OpenSearch 工作負載分為兩大類別之一：

  • 長壽命索引：您撰寫的程式碼會將資料處理成一或多個 OpenSearch 索引，然後在來源資料變更時定期更新這些索引。一些常見的範例是網站、文件和電子商務搜尋。

  • 動態索引：資料持續流入一組臨時索引，具有建立索引期和保留時段 (例如一組保留兩週的每日索引)。一些常見的範例是日誌分析、時間序列處理和點擊流分析。

對於長效索引的工作負載，您可以在磁碟上檢查來源資料並輕鬆判斷它會消耗多少儲存空間。如果資料來自多個來源，只要一起新增這些來源。

對於動態索引，您可以保留期乘上在代表時段產生的資料量。例如，若您每小時產生 200 MiB 的日誌資料，也就是每天 4.7 GiB，假設您的保留期間為兩週，則在任何指定時間的資料為 66 GiB。

您的來源資料的大小，不過是您的儲存需求的一個面向。您還必須有考量：

  • 複本數量：每個複本是索引的完整副本且需要相同的磁碟空間量。依預設，每個 OpenSearch 索引都有一個複本。建議您至少有一個以防資料遺失。複本也可提升搜尋效能，因此如果您的讀取工作負載繁重，您也許想要更多複本。使用 PUT /my-index/_settings 以更新索引的 number_of_replicas 設定。

  • OpenSearch 索引開銷：索引的磁盤上大小各不相同。來源資料加上索引的總大小通常是來源的 110%，索引最多可達來源資料的 10%。在您對資料編製索引之後，您可以使用 _cat/indices?v API 和 pri.store.size 值計算確切的負荷。_cat/allocation?v 也提供實用的摘要。

  • 作業系統預留空間：在預設情況下，Linux 會保留 5% 的檔案系統供 root 使用者用於關鍵程序、系統復原，以及防止磁碟分段問題。

  • OpenSearch 服務額外負荷： OpenSearch 服務會保留每個執行個體 20% 的儲存空間 (最多 20 GiB)，用於區段合併、記錄和其他內部作業。

    由於此 20 GiB 上限，預留空間的總量可能依您網域內的執行個體數目而大不相同。例如，網域可能有三個 m6g.xlarge.search 執行個體，各有 500 GiB 的儲存空間，總計 1.46 TiB。在這種情況下，總預留空間僅 60 GiB。另一網域可能有 10 個 m3.medium.search 執行個體，各有 100 GiB 的儲存空間，總計 0.98 TiB。在這種情況下，總預留空間是 200 GiB，即使第一個網域大 50%。

    在以下公式中，我們對開銷套用「最壞情況」預估值。此預估值包含額外的可用空間，有助於將節點故障和可用區域中斷的影響降到最低。

總之，如果您在任何指定的時間有 66 GiB 的資料，並且想要一個複本，您的最低儲存需求為接近 66 * 2 * 1.1 / 0.95 / 0.8 = 191 GiB。您可以將此計算一般化，如下所示：

來源資料 * (1 + 複本數目) * (1 + 索引開銷)/(1-Linux 保留空間)/(1- OpenSearch 服務額外負荷) = 最低儲存需求

或者，您可以使用此簡化版本：

來源資料 * (1 + 複本的數量) * 1.45 = 最低儲存需求

儲存空間不足是造成叢集不穩定的最常見原因之一。因此，您應在選擇執行個體類型、執行個體計數和儲存磁碟區時反復檢查數字。

也存在其他儲存考量事項：

選擇碎片數

在您了解您的儲存需求之後，您可以調查您的索引策略。根據預設，在 OpenSearch 服務中，每個索引分為五個主要碎片和一個複本（總共 10 個碎片）。這種行為與開源不同 OpenSearch，默認為一個主分片和一個副本分片。由於您無法輕易變更現有索引的主要碎片數，所以您應該在建立第一個文件的索引之前，決定好碎片計數。

選擇一些碎片的整體目標是要將索引平均分佈到叢集中的所有資料節點。不過，這些碎片不應該是太大或太多。一般指導方針是，針對搜尋延遲是關鍵效能目標的工作負載，嘗試將碎片大小保持在 10-30 GiB 之間，對於寫入操作繁重的工作負載 (例如日誌分析)，保持在 30-50 GiB。

較大的碎片可能會使得很難從故障中恢復，但是由於 OpenSearch 每個碎片使用一定數量的 CPU 和內存，因此具有太多的小碎片可能會導致性能問題和內存不足錯誤。換句話說，碎片應該足夠小，以至於底層的 OpenSearch Service 實例可以處理它們，但不是那麼小，以至於它們對硬件造成不必要的壓力。

例如，假設您有 66 GiB 的資料。您不希望該數量隨著時間增加，並且您想要保持每個碎片大約在 30 GiB 的大小。因此，您的碎片數應該大約為 66 * 1.1 / 30 = 3 個。您可以將此計算一般化，如下所示：

(來源資料 + 成長空間) * (1 + 索引負荷) / 所需碎片大小 = 主要碎片的大約數量

這個方程式有助於補償資料隨時間的成長。如果您預期同樣皆為 66 GiB 的資料到明年成為四倍，大約碎片數則會是 (66 + 198) * 1.1 / 30 = 10 個。不過請記住，您尚未擁有那些額外的 198 GiB 資料。請進行檢查以確保這個對未來的準備不會產生不必要的微小碎片，大量消耗眼前的 CPU 和記憶體。在這種情況下，66 * 1.1 / 10 個碎片 = 每個碎片 7.26 GiB，這會消耗額外的資源且低於建議的大小範圍。您可能會考慮六個碎片的更多 middle-of-the-road 方法，這使您今天擁有 12-GiB 碎片，並在 future 使用 48-GiB 碎片。接著，您可能希望再次以三個碎片開始並在碎片超過 50 GiB 時重新建立資料的索引。

有個較不常見的問題包含限制每個節點的碎片數量。如果您適當地調整碎片大小，通常要過很久一段時間才會用完磁碟空間，然後達到此限制。例如，一個 m6g.large.search 執行個體具有最大 512 GiB 的磁碟大小。如果您保持在低於 80% 的磁碟用量並將碎片大小調整為 20 GiB，即可容納大約 20 個碎片。彈性搜索 7. x 和更新版本，以及的所有版本 OpenSearch，每個節點都有 1,000 個碎片的限制。若要調整每個節點的最大碎片，請設定 cluster.max_shards_per_node 設定。如需範例，請參閱叢集設定。

只要適當地調整碎片大小，幾乎一律可保持低於此限制，但您也可以考慮 Java 堆積的每個 GiB 的碎片數量。在指定的節點上，Java 堆積的每 GiB 擁有不超過 25 個碎片。例如，一個 m5.large.search 執行個體具有 4 GiB 堆積，因此每個節點都應擁有不超過 100 個碎片。在該碎片計數，每個碎片的大小約為 5 GiB，這遠低於我們的建議。

選擇執行個體類型並進行測試

在您計算您的儲存需求並選擇所需的碎片數之後，您可以開始做出硬體的決策。硬體需求會依工作負載而大大不同，但是我們仍然可以提供一些基本建議。

一般而言，每個執行個體類型的儲存限制都會對應到您對於輕量型工作負載可能需要的 CPU 和記憶體量。例如，某個 m6g.large.search 執行個體具有最大 512 GiB 的 EBS 磁碟區大小、2 個 vCPU 核心和 8 GiB 的記憶體。如果您的叢集有許多碎片，執行課稅彙總、頻繁更新文件或處理大量的查詢，這些資源可能不足以滿足您的需求。如果您的叢集是這些類別之一，請嘗試針對您的每個 100 GiB 的儲存需求從組態較接近 2 個 vCPU 核心和 8 GiB 的記憶體開始。

提示

如需分配給每個執行個體類型的硬體資源摘要，請參閱 Amazon OpenSearch 服務定價。

然而，即使這些資源可能會也不夠。一些 OpenSearch 用戶報告說，他們需要很多次這些資源來滿足他們的要求。若要尋找適用於您的工作負載的合適硬體，您必須有明智的初始預估、測試代表的工作負載、進行調整並再次執行測試。

步驟 1：進行初步預估

首先，我們建議至少使用三個節點來避免潛在的 OpenSearch問題，例如腦部分裂狀態（當通訊失效導致叢集具有兩個主節點時）。如果您有三個專用主節點 ，我們仍然建議您至少有兩個資料節點用於複寫。

步驟 2：計算每個節點的儲存需求

如果您有 184 GiB 的儲存需求和建議的至少三個節點，請使用方程式 184 / 3 = 61 GiB 算出每個節點所需的儲存量。在此範例中，您可以選取三個 m6g.large.search 執行個體，其中每個執行個體都分別使用 90 GiB 的 EBS 儲存磁碟區，讓您對於隨時間的成長擁有安全網路以及一些空間可供因應。這種組態提供 6 個 vCPU 核心和 24 GiB 的記憶體，所以適合較輕量型的工作負載。

針對更高額度的範例，則假設是儲存需求為 14 TiB (14,336 GiB) 的繁重工作負載。在這種情況下，您可以選擇開始測試 2 * 144 = 288 個 vCPU 核心和 8 * 144 = 1152 GiB 的記憶體。這些數字運作大約 18 個 i3.4xlarge.search 執行個體。如果您不需要快速的本機儲存，也可以測試 18 個 r6g.4xlarge.search 執行個體，各使用 1 TiB 的 EBS 儲存磁碟區。

如果您的叢集包含數百 TB 的資料，請參閱 Amazon 服務中的 PB 規模 OpenSearch 。

步驟 3：執行代表性測試

設定叢集之後，您可以使用先前計算的碎片數量來新增索引、使用實際資料集執行一些代表性的用戶端測試，以及監視 CloudWatch 指標以查看叢集如何處理工作負載。

步驟 4：成功或反覆

如果效能滿足您的需求、測試成功，且 CloudWatch 指標正常，則叢集已準備就緒可供使用。請記得設定 CloudWatch 警示以偵測健全狀況不良的資源使用量。

如果無法接受該效能，表示測試失敗或者 CPUUtilization 或 JVMMemoryPressure 偏高，您可能需要選擇不同的執行個體類型 (或新增執行個體)，並繼續進行測試。當您新增執行個體時， OpenSearch 會自動重新平衡整個叢集中的碎片分佈。

由於這在動力過強的叢集中測量過剩容量比在動力不足的叢集中測量欠缺容量來得容易，我們建議您從比您所需較大的叢集開始。接著，進行測試並縮減到有額外資源可確保在增加活動期間有穩定操作的有效率叢集。

生產叢集或狀態複雜的叢集受益於專用主節點，可提升效能和叢集可靠性。