設定の変更を適用したり、クラスターの例外を解決したりするために、クラスターまたはそのノードを再起動する必要がある場合があります。この操作を安全かつ効率的に実行するには、さまざまな再起動方法に関連するシナリオとリスクを理解することが重要です。
準備
スムーズな再起動を確実にするために、開始する前に次のヘルスチェックと準備を完了してください。
クラスターのヘルスステータスを確認する
Kibana を介してクラスターに接続し、GET _cluster/healthコマンドを実行します。statusフィールドの値がgreenであることを確認してください。例外: クラスターのステータスが
yellowまたはredの場合にのみ、強制再起動を実行できます。データ冗長性を確保する
GET _cat/indices?vコマンドを実行して、すべての重大なインデックスのrep(レプリカ数) フィールドの値を確認します。レプリカ数が少なくとも
1であることを確認してください。レプリカのないインデックスは、再起動中にアクセスできなくなります。マルチゾーンインスタンスの場合、どのインデックスのレプリカ数もゾーン数より少ないことを確認してください。
閉じたインデックスを確認して処理する
GET _cat/indices?vコマンドを実行して、statusがcloseのインデックスがあるかどうかを確認します。理由: 閉じたインデックスは、クラスターのヘルスチェックの失敗やシャードの割り当て妨害の原因となります。これにより、再起動プロセスがブロックされます。
アクション: 閉じたインデックスが存在する場合は、
POST /<index_name>/_openコマンドを実行して開きます。
クラスターの負荷を評価する
インスタンスのクラスターモニタリングページで、次のコアメトリックを確認します。リソース使用量が必須の制限内にあることを確認し、再起動中のシャード移行のために十分なリソースを確保します。ノードの CPU 使用率: 80% 未満である必要があります。
ノードのヒープメモリ使用率: 50% 前後である必要があります。
ノードの load_1m: データノードの CPU コア数未満である必要があります。
再起動の実行
ヘルスチェックが完了したら、次のステップに従ってインスタンスを再起動します。
Alibaba Cloud Elasticsearch コンソールにログインします。左側のナビゲーションウィンドウで、Elasticsearch クラスター をクリックします。
上部のメニューバーで、ターゲットインスタンスが配置されているリージョンを選択します。ターゲットインスタンスの ID をクリックします。基本情報 ページで、右上隅にある 再起動 をクリックします。
表示される 再起動 ダイアログボックスで、必要に応じて次のパラメーターを設定します。
操作タイプ
インスタンス: インスタンス内のすべてのノードを再起動します。このオプションは、クラスターレベルの変更に適しています。
ノードの再起動: 選択した 1 つ以上の指定されたノードを再起動します。このオプションは、個々のノードの問題を解決するのに適しています。
ノードのロール (基本管理クラスター v2 のみ): データノードや Kibana ノードなど、選択した特定のロールのノードを再起動します。
ブルーグリーンリリースの変更 と 再起動モード
再起動操作は、クラスターの安定性と可用性に影響を与える可能性があります。クラスターを再起動する前に、特定のシナリオ、クラスターのステータス、およびリスク許容度に適した再起動方法を選択してください。
再起動方法
必須のクラスターのステータス
シナリオ
サービスへの影響
適用可能なインスタンスのバージョン
ブルーグリーン変更
正常 (green)
この操作では、新しいノードをクラスターに追加し、元のノードから新しいノードにデータを移行してから、元のノードを削除します。
この方法は、クラスター内の単一ノードのパフォーマンスが低い (CPU 使用率が一貫して高いなど) シナリオに適しており、クラスターの可用性に対する要件は高いが、変更期間には敏感でない場合に適しています。
重要ブルーグリーン変更は、強制再起動と併用できません。
ノードの IP アドレスが変更されます。クラスターのパフォーマンスに一時的な変動が生じる可能性があります。
1 コア 2 GB の仕様ではサポートされていません
再起動 (標準)
正常 (green)
計画的なメンテナンスと定期的なクラスター構成。
ノードの IP アドレスは変更されません。再起動には時間がかかります。レプリカシャードが存在する場合、サービスは利用可能なままですが、一時的な変動が生じる可能性があります。
すべてのバージョン
グレースケール再起動
正常 (green)
この方法を本番環境で使用して、バッチで再起動の効果を検証し、全体的なリスクを軽減します。
このオプションを選択した場合は、まずグレースケール再起動のノードを選択する必要があります。最初のバッチのノードが再起動され、クラスターが安定した後、後続の変更を手動でトリガーして残りのノードを再起動します。
ノードの IP アドレスは変更されません。一部のノードが最初に監視のために再起動され、その後残りのノードが再起動されます。
クラウドネイティブの新しい管理 (v3) クラスターのみ
強制再起動
異常 (yellow/red)
インスタンスが異常な状態 (yellow または red) の場合、他の再起動操作は無効になります。強制再起動を実行する必要があります。
重要ディスク使用率が
cluster.routing.allocation.disk.watermark.lowしきい値を超えると、クラスターが異常な状態 (yellow または red) になることがあります。この期間中は、次の操作を避けてください:ノードのスケールアウト
ディスクのスケールアウト
再起動 (標準または強制)
パスワードの変更
その他の構成変更
これらの操作は、インスタンスが正常な状態 (green) に戻った後にのみ実行してください。
ノードの IP アドレスは変更されません。
同時実行性を高めると、強制再起動を大幅に高速化できますが、影響も大きくなります:
高い同時実行性のリスク: 100% に設定すると、すべてのノードが同時に再起動されます。これにより、完全なサービス中断が発生し、永続化されていないキャッシュデータが失われる可能性があります。
推奨事項: クラスターが異常で緊急に回復する必要がある場合は、高い同時実行性の設定を使用してください。
同時実行性: 同時に再起動されるノードの割合。デフォルト値は、クラスター内のノード総数の 10% で、少なくとも 1 ノードに切り上げられます。たとえば、同時実行性が 10% に設定されている場合、クラスター内のノードの 10% が一度に再起動されます。
このパラメーターは、強制再起動モードでのみ表示されます。
すべてのバージョン
パラメーターを確認したら、OK をクリックします。
強制再起動を実行する場合は、強制再起動してもよろしいですか。 も選択する必要があります。操作が開始されると、インスタンスのステータスが「適用中」に変わります。ページの右上隅にあるタスクリストで再起動の進行状況を表示できます。再起動が完了すると、インスタンスのステータスは「正常」に戻ります。