Couchbase Serverクラスタにデータを格納したあとで、アプリケーションの負荷、RAM、ディスクI / Oやネットワークの性能要件の変化に対応するために、クラスタ内のノードの数を変更する必要があるかもしれません。
CouchbaseServerは、それらの変更に対応するために、クラスタを止めることなくアプリケーションのリクエストを実行しながらノード数の変更をすることができるよう設計されています。このプロセスは、クラスタ内のノードの増減、ノード間での情報のリバランス の2段階に分かれています。
追加及び除去プロセスは、単純に新しいノードをクラスタに追加するよう設定するか、クラスタから除去するノードをマークするかです。新しいノードを追加したり、ノードを除去する設定をした時点では、クラスタやデータに対して実際の変更は行われません。
リバランス操作中：
新しいCouchbase Serverクラスタ構造に従って、データが変更前の構造から、各ノード上のvBuckets間で移動されます。このプロセスは、クラスタ全体で各ノード上のvBucketsに保持されたデータを交換することによって動作します。 これには二つの効果があります。
クラスタから除去されるマシンからのデータを削除します。これらのマシン上のデータをすべて削除することで、クラスタの動作に影響を与えることなく、クラスタから取り出される各ノードの除去を可能にします。
クライアントに情報を提供できるように、データを追加し、新しいノードを利用可能にします。アクティブなデータを新しいノードに移動すると、そのノードは移動したvBucketと、それにアクセスするクライアントリクエストの処理を担当することになります。
リバランスは、各ノードと各バケットごとのRAMに保存されたデータとディスクに保存されたデータの両方をクラスタ間で移動します。移動にかかる時間は、格納されている情報の量とクラスタの活動レベルに依存しています。
クラスタは起動したまま、クライアントからのリクエスト処理を継続します。移行プロセス中に保存されたデータへの更新や変更はチェックされ、リバランスが要求された時点に存在していたデータと一緒に更新され、移行されます。既存のものと、アクティブに更新された情報の両方をコピーすることで実現されます。
クラスタ内のどのノードがクライアントからのリクエストを処理するかを示すvBucketマップは、各vBucketが移動される毎に差分更新されます。更新されたvBucketマップは、Couchbaseクライアントライブラリと連携し、スマートクライアント (Moxiなど）を有効化し、クライアントに対し、リバランス完了後の更新された構造を使うことを許可します。このことにより、負荷を分散するためできるだけ早く新しい構造を使えるよう、リバランス操作中に新しい構造を展開することが可能となっています。
クラスタが稼働状態のまま、リバランスのプロセス全体を通してアクティブなので、クライアントは情報を格納および取得し続けることができますし、リバランス操作が行われていることを意識する必要はありません。
大きく4つの場合に、リバランス操作を実行します。
クラスタにノードを追加するとき
クラスタからノードを除去するとき
フェイルオーバ後にクラスタを正常な状態に戻すとき
ソフトウェアやOSやハードウェアのアップグレードのため、一時的に複数のノードを除去するとき
リバランスの理由に関わらず、リバランスの目的はノード、バケット、及びレプリカの設定値と実際の状態が一致した正常な状態へとクラスタを移行することです。
クラスタをリバランスするタイミングと方法については、以下を御覧ください「リバランスが必要な状況」 。ここでは、リバランスを実行するタイミングや、クラスタ内のノードの設定を変更すべき典型的なトリガー・指標について言及します。
クラスタの拡大・縮小、リバランス操作の始め方については以下を御覧ください「リバランスの開始」 。
リバランス操作が開始されたら、リバランス操作や進捗状況を監視する必要があります。 モニター機能を通じて、統計やイベントに関する情報を取得できます。「リバランス中のモニタリング」
リバランス操作に関する一般的な質問はこちらを参照してください「一般的なリバランスに関する質問」 。
リバランスに関する詳細な情報や仕組みについては以下を御覧ください「バックエンドでのリバランス」 。