アクティブ/アクティブ リーダー フェイルオーバー後のワークロードの再配布
ESC アクティブ/アクティブセットアップのノードの 1 つ(リーダー/フォロワー)に障害が発生すると、ESC は、障害が発生したノードから利用可能な正常なノードに負荷の所有権を均等に配布します。障害が発生したノードが再び使用可能になっても、ESC は、過負荷状態のノードから、障害状態からアクティブ状態に戻ったノードに設定を自動的に再配布することはありません。
大規模な展開では、負荷のあるノードでパフォーマンスの問題が発生する可能性があります。ESC は、所有権の移転と所有権のポリシーに基づいて、過負荷状態のノードから使用可能なノードに設定を再配布するためにオンデマンドで呼び出すことができる新しい REST API を提供します。
リバランシング API がトリガーされると、ESC は次の機能を実行して、1 つのノードから別のノードに展開を転送します。
-
メモリ内の VM を使用した展開のアンロードにより、現在の所有者からモニターの設定を解除
-
所有権ポリシーに基づく新しい所有者の割り当て
-
所有権の記録の更新
-
新しい所有者への通知
所有権を再配布するためのリバランス API
アクティブ/アクティブセットアップで障害が発生したノードが再び使用可能になっても、ESC は過負荷状態のノードから正常なノードに所有権を再配布しません。リバランス API を手動でトリガーして、使用可能なノード間で所有権を再配布することができます。
次の URL を使用して、リバランス API をトリガーします。
http://localhost:8080/ESCManager/internal/ownership/rebalance
リバランス API がトリガーされると、ESC は最適な分散アプローチを使用して過負荷状態のノードを見つけます。ESC は、転送する設定を識別し、リモートで呼び出して、現在の所有者の設定をアンロードし、割り当てられた設定の新しい所有者にリモートで再ロードします。
次の例は、リバランスがどのように行われるかを示しています。
URL: http://localhost:8080/ESCManager/internal/ownership/rebalance
Method: PUT
Input: None
{
"esc1-uuid": --> esc node uuid
{
"previous_configs_count": 300, --> number of configs before rebalance
"requested_unload_count": 100, --> number of configs earmarked for unload
"accepted_unload_count": 100, --> number of configs actually unloaded
"current_configs_count": 200 --> number of configs after rebalance
},
"esc2-uuid":
{
"previous_configs_count": 300,
"requested_unload_count": 100,
"accepted_unload_count": 90,
"current_configs_count": 210
},
"esc3-uuid":
{
"previous_configs_count": 0, --> new esc node, no configs yet
"requested_unload_count": 0, --> previous config count is less than optimal count per esc, so no unload requested
"accepted_unload_count": 0,
"current_configs_count": 190--> 100 from esc1 and 90 from esc2 got loaded
}
}
Exception: {"error": {"error_code":500, "error_message": "Internal Error"}}
次のメッセージが表示されるまで、リバランス API を複数回トリガーできます。
リバランスのための設定が見つかりませんでした。
次のいずれかの状況が発生すると、エラーコード/メッセージが表示されます。
-
フェールオーバーが原因の所有権の継続的な転送中。
-
正常な ESC ノードが 2 つ未満の場合。
-
所有権の一時停止が有効になっている場合。
-
ESC がスタンドアロンの場合。