對 Amazon OpenSearch Service 叢集進行組態變更時會發生什麼?

上次更新日期:2021 年 8 月 5 日

我嘗試在組態變更期間盡量縮短停機時間。若對 Amazon OpenSearch Service 叢集進行組態變更會發生什麼?

解析度

當您變更 OpenSearch Service 叢集組態時,可能會觸發藍/綠部署。在藍/色部署期間,叢集狀態會在建立新的 OpenSearch Service 網域時變更為「正在處理」。建立新網域時,會發生下列情況:

  • 節點總數增加一倍。或,節點總數等於新舊網域中的節點計數。
  • 節點數目會增加一倍,直到舊的網域節點終止為止。
  • 如果碎片分配終於在進行中,叢集狀態會返回「作用中」。

注意:在藍/綠部署期間,您可能會觀察到一些延遲。為了避免任何延遲問題,最佳實務是在叢集處於運作狀態且網路流量低時執行藍/綠部署。

組態變更持續時間

您的組態變更可能需要更長時間才能完成,時間長短取決於叢集大小、工作負載、碎片大小和碎片計數。請使用 cat 復原命令來監控碎片遷移的狀態。

若要查看哪些碎片仍在遷移,請使用以下命令語法:

Curl  -X GET "cluster_endpoint/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | grep -v 100\.0\%

若要依位元組百分比列出碎片遷移,請使用下列命令語法:

Curl -X GET "https://<end_point>/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | tr -d "%" | sort -k 5 -n

注意:若要按位元組百分比(位於第五欄)排序資料,您必須為 -k 指定「5」。

如果您觀察到碎片遷移呈現最小進度,您的叢集可能停滯了。

藍/綠部署程序停滯的原因

您的藍/綠部署程序可能會停滯,原因如下:

  • 叢集在組態變更前的運作狀態不良。
  • 維持高 JVM 記憶體壓力。旨在將 JVM 記憶體壓力保持在 75% 以下,以避免記憶體不足 (OOM) 的問題。
  • 維持高 CPU 使用率。目標是讓您的 CPU 使用率低於 80%。
  • 叢集上的碎片太多,或碎片規模調整不正確。最佳實務是將碎片計數保持在 10 GiB 和 50 GiB 之間。如需索引策略的詳細資訊,請參閱選擇碎片數目
  • 無效的組態設定或同時進行過多的組態變更。請務必確認您的組態設定,並等待傳送組態變更,直到第一個組態變更完成為止。
  • 磁碟空間或容量不足,無法執行遷移程序或要求的執行個體類型。
  • Virtual Private Cloud (VPC) 內的叢集所要求的子網路上無可用 IP。
  • 使用磁碟區大小做為執行個體類型。您的磁碟區大小必須在限制範圍內。
  • 使用如 "index.routing.allocation.require._name" 或 "NODE_NAME" 或 "index.blocks.write": true" 等索引設定。這些設定表示寫入區塊。在繼續之前,請務必從索引設定中移除這些設定。

如需詳細資訊,請參閱為何我的 Amazon OpenSearch Service 網域停留在「正在處理」狀態?

Amazon OpenSearch Service 是 Amazon Elasticsearch Service 的後繼者。


此文章是否有幫助?


您是否需要帳單或技術支援?