GlusterFS ブリック追加・再分散の I/O 帯域制御と本番検証

再分散（rebalance）が本番帯域に与える影響の全体像

GlusterFS でブリックを追加しても、既存データは新しいブリックへ自動では移動しません。gluster volume rebalance を実行することで、ハッシュレイアウトの再計算とデータ移行が始まります。この処理は内部的にファイルをコピー・削除する実 I/O を発生させるため、同じノードを利用する本番ワークロードとネットワーク帯域やディスク I/O を奪い合う状態になります。

再分散は単なるメタデータ操作ではなく、各ファイルをブリック間で実際に転送します。ギガバイト規模のボリュームでは数時間から数十時間かかるケースもあり、その間ずっと I/O 負荷がかかり続けます。ピーク時間帯に無制御で走らせると本番サービスのレイテンシが悪化することが一般的に知られています。

帯域制御の仕組みを理解したうえで手順を組むことで、サービスへの影響を最小化しながら安全に再分散を完了させられます。

ブリック追加前の確認と準備

ブリックを追加する前に、現在のボリューム構成を確認します。

gluster volume info <ボリューム名>

出力の Type と Number of Bricks を確認してください。Distributed-Replicate 構成の場合、ブリックはレプリカセット単位で追加しなければなりません。たとえばレプリカ数が 2 のボリュームに追加するときは 2 ブリックを同時に指定します。1 ブリックだけ指定するとコマンドがエラーを返します。

次に、追加予定のノードで対象ディレクトリが存在し、既存ボリュームのブリックパスと重複していないことを確認します。

ls -la /data/glusterfs/brick2
df -h /data/glusterfs/

追加先ノードがまだ Trusted Storage Pool に参加していない場合は、gluster peer probe <ホスト名> で招待しておきます。

gluster peer probe node3
gluster peer status

State: Peer in Cluster (Connected) と表示されれば準備完了です。自己修復キューが残っている場合は、先に自己修復を完了させてから作業を進めると I/O 負荷の重複を避けられます。

gluster volume heal <ボリューム名> info

ブリック追加コマンドと再分散の開始

準備が整ったらブリックを追加します。以下はレプリカ 2 の Distributed-Replicate ボリュームに 1 セット（2 ブリック）を追加する想定例です。

gluster volume add-brick <ボリューム名> replica 2 \
  node3:/data/glusterfs/brick1 \
  node4:/data/glusterfs/brick1

成功すると volume add-brick: success と表示されます。この時点では既存データはまだ移動していません。

再分散を開始する前に、次のセクションで説明する throttle を先に設定しておくことをおすすめします。設定はホットで反映されるため再分散中でも変更できますが、開始前に済ませておくほうが確実です。設定後に再分散を開始します。

gluster volume rebalance <ボリューム名> start

fix-layout オプションを付けると、データ移行を行わずレイアウト情報だけを更新します。既存ファイルを新ブリックへ再配置する必要がなく、今後の書き込みを新ブリックにも分散させるだけでよい場合はこちらが軽量です。既存データを均等化したい場合は通常の start を使います。

cluster.rebal-throttle による I/O 帯域制御

GlusterFS には再分散の処理強度を 3 段階で調整できる cluster.rebal-throttle というボリュームオプションがあります。

• lazy：移行スレッドをほぼ休眠させ、I/O 負荷を最小限に抑えます。再分散完了まで長くかかりますが、本番への影響が最も小さくなります。
• normal（デフォルト）：バランスの取れた速度で動作します。
• aggressive：CPU・ネットワーク・ディスクを最大限に使い高速に移行します。本番ワークロードと競合しやすくなります。

本番時間帯は lazy に設定し、夜間メンテナンスウィンドウ中だけ aggressive または normal に切り替えるという運用が広く行われています。

# 業務時間帯：負荷を絞る
gluster volume set <ボリューム名> cluster.rebal-throttle lazy

# メンテナンスウィンドウ中：速度を上げる
gluster volume set <ボリューム名> cluster.rebal-throttle aggressive

設定変更はボリュームを停止せず即時反映されます。再分散の途中で何度でも変更可能です。

なお、cluster.rebal-throttle はファイル移行の並列数とスリープ間隔を制御するパラメータであり、ネットワーク帯域を MB/s 単位で上限指定する仕組みではありません。より細かいネットワーク帯域制御が必要な場面では、OS 側の tc（Traffic Control）やネットワークスイッチの QoS と組み合わせる構成を検討してください。

進捗モニタリングと完了確認

再分散の進捗は次のコマンドで確認します。

gluster volume rebalance <ボリューム名> status

出力には各ノードで処理済みのファイル数・移行済みバイト数・失敗数・経過時間が表示されます。最終行の status フィールドが completed になれば再分散は完了です。

status の確認だけでは不十分な場合があります。ボリューム全体のブリック使用率も確認し、各ブリックの使用量が均等になっていることを合わせて確かめます。

gluster volume status <ボリューム名> detail

個々のファイルが期待するブリックに配置されているかを確認するには getfattr でハッシュキーを調べます。

getfattr -n trusted.glusterfs.pathinfo /mnt/glusterfs/<任意のファイル>

pathinfo の出力にブリックのホスト名が含まれるため、旧ブリックか新ブリックかを目視で確認できます。大量のファイルを対象に自動検証する場合は、スクリプトで繰り返し getfattr を呼び出して集計する方法が一般的です。

再分散中は gluster volume heal <ボリューム名> info も定期的に確認し、自己修復キューが増え続けていないかを監視します。自己修復と再分散が同時に走ると I/O 負荷が重なるため、自己修復キューが空になってから再分散を開始するスケジューリングが安全です。

切り戻し手順と 2026 年現行環境での注意点

再分散を途中で停止したい場合は次のコマンドを使います。

gluster volume rebalance <ボリューム名> stop

停止後、移行の途中だったファイルは元のブリックにロールバックされず、移行済みの分だけが新ブリックに残ります。再度 start を実行すると未移行のファイルから処理が再開されます。途中停止しても一貫性は保たれますが、ブリック間の使用量の偏りは残ります。

追加したブリックをボリュームから取り外したい場合（ロールバック）は remove-brick コマンドを使います。start を実行すると対象ブリック上のデータを残りのブリックへ退避させる処理が走り、完了後に commit で取り外しが確定します。

# 退避処理を開始
gluster volume remove-brick <ボリューム名> replica 2 \
  node3:/data/glusterfs/brick1 \
  node4:/data/glusterfs/brick1 start

# 状態確認
gluster volume remove-brick <ボリューム名> \
  node3:/data/glusterfs/brick1 \
  node4:/data/glusterfs/brick1 status

# 完了後にコミット（ここで初めてブリックが切り離される）
gluster volume remove-brick <ボリューム名> replica 2 \
  node3:/data/glusterfs/brick1 \
  node4:/data/glusterfs/brick1 commit

commit を実行するとブリックの切り離しは確定し、元に戻せません。status で退避が完了していることを確認してからコミットする手順を徹底してください。

2026 年時点の環境差分

GlusterFS は Red Hat / IBM によるコミット縮小以降、コミュニティ主導の開発体制が続いています。2024～2026 年にかけてリリースされた GlusterFS 11 系では、rebalance 関連のログ出力が整理され、status コマンドの出力フォーマットが一部変更されています。スクリプトで出力をパースしている場合は、バージョンアップ後の出力形式を事前に確認してください。

RHEL 9 / Rocky Linux 9 / AlmaLinux 9 環境では、公式リポジトリ経由で提供される GlusterFS パッケージのバージョンが OS のサポートライフサイクルに縛られるケースがあります。コミュニティ版の最新機能を利用する場合は GlusterFS プロジェクト公式リポジトリからインストールし、OS 付属パッケージとの混在には注意が必要です。

Kubernetes 環境との統合においては、Heketi の開発停滞を背景に Rook-Ceph や Longhorn へ移行する動きが広がっています。新規構築で Kubernetes 統合が主目的の場合は、GlusterFS を選択する前に代替ソリューションとの比較検討を行うことが現実的です。既存の GlusterFS ボリュームを継続運用する場面では、今回説明した rebalance 手順はバージョン 10・11 系でも基本的に同じ流れで利用できます。