Fullmoon System

GlusterFS構築ガイド：Replica 3・マウント・Healと運用確認

EdwardMoon

GlusterFSは、複数サーバーのディスクを1つのファイルシステムのように提供します。ただし、パッケージを入れて2ノードを接続するだけで高可用性が完成するわけではありません。複製数、quorum、障害ドメイン、バックアップ、パッケージのサポート期間まで設計し、データ損失とsplit-brainのリスクを減らします。

この記事は、3サーバーへデータ全体を複製するReplica 3の演習を基準に構築手順を説明します。コマンドと設定をコードブロックに分け、各段階に確認方法と中止条件を示しています。本番では貼り付けて実行する前に、デバイス名、ネットワーク帯、パッケージ提供元のサポート範囲を検証してください。

GlusterFSの構成とReplica 3のファイル複製・quorumの流れ
GlusterFSはファイル単位で複数brickへ複製し、Replica 3では3つのデータコピーによる過半数の判定を利用できます。

現在のバージョンとサポート範囲を確認する

公式ダウンロードディレクトリで確認できる最新のコミュニティリリースは11.1です。ただし、公式方針ではメジャーバージョンの保守期間を約12か月としているため、2026年の新規本番システムへ11.1を無条件に推奨はできません。ディストリビューションや商用ベンダーがセキュリティ更新を提供するか確認し、サポート経路がなければCeph、NFS HA、クラウドファイルサービスなども評価してください。以下は、検証済みのEL9系リポジトリが準備されていることを前提にした演習です。

公式のコミュニティパッケージ一覧、GlusterFS 11.1リリースノート、Quick Start Guideを併せて確認してください。

構成例

役割ホスト管理IPbrickパス
Glusterサーバー1gluster0110.20.30.11/bricks/brick1/gv0
Glusterサーバー2gluster0210.20.30.12/bricks/brick1/gv0
Glusterサーバー3gluster0310.20.30.13/bricks/brick1/gv0
クライアントclient0110.20.30.21/mnt/gv0
  • 3サーバーを異なる障害ドメインへ置き、時刻同期と正引き・逆引きを確認する。
  • OSとbrickデータを別ディスクまたは別論理ボリュームに分離する。
  • Replica 3は完全なコピーを3つ保存するため、元データの約3倍の容量を必要とする。
  • 削除、暗号化、アプリケーションエラーも伝わるため、別のバックアップが不可欠。

全ノードで名前解決と時刻同期を確認する

getent hosts gluster01 gluster02 gluster03
chronyc tracking
timedatectl status

ホストマッピングの例

10.20.30.11  gluster01
10.20.30.12  gluster02
10.20.30.13  gluster03

手順1：専用brickディスクを準備する

次の作業では既存データを消す可能性があります。各サーバーで実デバイス名とマウント状態を確認し、バックアップと変更承認を確保します。例の/dev/sdbは実環境に合わせて置き換えてください。

lsblk -f
findmnt --real
sudo wipefs --no-act /dev/sdb

次のmkfsは対象デバイスの既存ファイルシステムを破壊します。lsblk、findmnt、wipefs –no-actの結果を人が確認するまで実行しないでください。

sudo mkfs.xfs -f -i size=512 /dev/sdb
sudo mkdir -p /bricks/brick1
sudo blkid /dev/sdb

blkidで確認したUUIDを使い、各サーバーの/etc/fstabへ次の形式で追加します。

UUID=<각-서버의-실제-UUID> /bricks/brick1 xfs defaults,noatime 0 2
sudo mount -a
findmnt /bricks/brick1
df -hT /bricks/brick1
sudo mkdir -p /bricks/brick1/gv0

手順2：パッケージとglusterdを確認する

EL9系では、リポジトリが実際にglusterfs-serverを提供するか先に照会します。パッケージがない、または提供元・署名が不明な場合は、古いRPMを任意の場所から取得せず、ここで中止してください。

sudo dnf repolist
sudo dnf repoquery --info glusterfs-server
sudo dnf install -y glusterfs-server glusterfs-fuse
rpm -q glusterfs-server glusterfs-fuse
glusterfs --version
sudo systemctl enable --now glusterd
sudo systemctl --no-pager --full status glusterd
sudo journalctl -u glusterd -b --no-pager | tail -n 80

手順3：ファイアウォールをストレージネットワークに限定する

Gluster 10以降のbrickポートは、base-portからmax-portの範囲でランダムに選ばれます。管理用24007～24008と実際のbrickポート範囲を、ストレージサブネットだけに許可します。次の範囲は例であり、brick数とglusterdの設定を合わせ、変更作業時間内に適用してください。

sudo grep -E 'base-port|max-port' /etc/glusterfs/glusterd.vol
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=24007-24008 protocol=tcp accept'
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=49152-49200 protocol=tcp accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-all

SELinuxやfirewalldの無効化で問題を回避しないでください。ポリシーによる遮断が疑われる場合は監査ログとパッケージ付属のSELinuxポリシーを確認し、許可範囲をGlusterノードとクライアントネットワークに限定します。

上記を使う新規演習サーバーでは、各ノードの/etc/glusterfs/glusterd.volにある既存のvolume managementブロック内で、option base-port 49152とoption max-port 49200を設定してglusterdを再起動します。同じオプションを重複追加しないでください。本番では既存brickの実ポートと使用数を調べ、先に既存範囲を許可し、保守手順なしで範囲を縮めないでください。

sudoedit /etc/glusterfs/glusterd.vol
sudo systemctl restart glusterd
sudo systemctl status glusterd --no-pager
sudo grep -E "base-port|max-port" /etc/glusterfs/glusterd.vol

手順4：trusted storage poolを構成する

gluster01から残り2台をprobeし、ホスト名を一貫して記録するためgluster02からもgluster01を一度probeします。全peerがConnectedになるまでボリュームを作成しません。

# gluster01で実行
sudo gluster peer probe gluster02
sudo gluster peer probe gluster03
sudo gluster peer status
sudo gluster pool list
# gluster02で実行
sudo gluster peer probe gluster01
sudo gluster peer status

手順5：Replica 3ボリュームを作成・検証する

Replica 3はファイルを3つのbrickへ複製します。単純なdistributed volumeは容量を増やせますが複製がないため、1つのbrick障害でそのファイルを失う場合があります。高可用性を目的とする場合、volume createのTypeとbrickの並びを必ず確認します。

sudo gluster volume create gv0 replica 3 transport tcp \
  gluster01:/bricks/brick1/gv0 \
  gluster02:/bricks/brick1/gv0 \
  gluster03:/bricks/brick1/gv0

sudo gluster volume info gv0
sudo gluster volume start gv0
sudo gluster volume status gv0 detail

開始後は3つのbrickすべてがOnlineか確認します。forceは誤ったパスやトポロジーへの警告まで無視する場合があるため、原因を理解せずに使用しないでください。

手順6：クライアントのマウントと再起動を検証する

クライアントにglusterfs-fuseを導入します。最初のvolfileサーバーが応答しない場合に備え、残り2台をbackup-volfile-serversへ指定します。ただし、このオプションはデータ複製そのものの代わりではありません。

sudo dnf install -y glusterfs-fuse
sudo mkdir -p /mnt/gv0
sudo mount -t glusterfs gluster01:/gv0 /mnt/gv0 \
  -o backup-volfile-servers=gluster02:gluster03
findmnt /mnt/gv0
df -hT /mnt/gv0

再起動後の自動マウントが必要なら、クライアントの/etc/fstabへ以下を追加します。

gluster01:/gv0 /mnt/gv0 glusterfs defaults,_netdev,backup-volfile-servers=gluster02:gluster03 0 0
sudo umount /mnt/gv0
sudo mount -a
findmnt /mnt/gv0
sudo touch /mnt/gv0/.mount-test
stat /mnt/gv0/.mount-test

手順7：書き込み、複製、障害復旧を試験する

本番データを置く前に、専用の試験ファイルで書き込みと複製を確認します。brickへ直接アクセスするとGlusterメタデータを迂回するため、アプリケーションは必ずGlusterのマウントポイントを使ってください。

date -Is | sudo tee /mnt/gv0/healthcheck.txt
sha256sum /mnt/gv0/healthcheck.txt
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary

障害試験はバックアップと復旧計画を確認した保守時間内に実施します。1ノードを隔離している間に試験ファイルを追加し、復帰後にheal待ちが0へ収束することを確認します。過半数を失った状態で書き込みを強制したり、複数の分断区間へ同時に書いたりしないでください。

sudo gluster peer status
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
sudo gluster volume heal gv0 info
sudo gluster volume heal gv0 info split-brain

手順8：healとsplit-brainを安全に処理する

heal待ちは自動復旧の対象ですが、split-brainはGlusterが正本を選べない状態です。最新の更新時刻や大きなファイルを無条件に選ぶと、正常データを上書きするおそれがあります。まずアプリケーションの書き込みを止め、バックアップを作成し、ファイルの意味とチェックサムを比較してください。

sudo gluster volume heal gv0 info split-brain
sudo getfattr -d -m . -e hex /bricks/brick1/gv0/<문제-파일>
sudo stat /bricks/brick1/gv0/<문제-파일>
sudo sha256sum /bricks/brick1/gv0/<문제-파일>

運用者とアプリケーション担当者が正本brickを確認した後にのみ、source-brick方式で該当ファイルを復旧します。以下のホスト、brick、ファイルパスは実際に確認した値へ変更してください。

sudo gluster volume heal gv0 split-brain \
  source-brick gluster01:/bricks/brick1/gv0 /<문제-파일>

sudo gluster volume heal gv0 info split-brain
sudo gluster volume heal gv0 info summary

latest-mtimeやbigger-fileは便利ですが、データの意味を保証しません。DBファイルやVMイメージなど、アプリケーションの整合性が必要なファイルでは、サービスを停止し、その製品の復旧手順を優先します。

手順9：ログと状態を併せて診断する

マウントエラーだけでサーバーを再起動せず、peer、volume、brickポート、heal、容量、inode、ログを同じ時点で収集します。特に/var/lib/glusterdが満杯になると、管理デーモンが正常に動かない場合があります。

sudo gluster pool list
sudo gluster volume info gv0
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
df -hT /var/lib/glusterd /bricks/brick1
df -i /var/lib/glusterd /bricks/brick1
sudo ss -lntp | grep -E ':(2400[78]|4915[2-9]|491[6-9][0-9]|49200)\b'
sudo journalctl -u glusterd -b --no-pager | tail -n 200

healコマンド自体が失敗したら、glfshealと対象brickのログを確認します。ログパスとプロセスのポートはバージョンやパッケージ構成によって異なるため、volume statusの結果と照合してください。

sudo ls -1 /var/log/glusterfs/
sudo tail -n 200 /var/log/glusterfs/glfsheal-gv0.log
sudo find /var/log/glusterfs/bricks -maxdepth 1 -type f -name '*.log' -print

手順10：運用チェックリスト

  1. 提供元のセキュリティサポート期間と更新経路を文書化する。
  2. 3サーバーを独立した電源、ラック、ネットワークの障害ドメインへ置く。
  3. 管理・brickポートを必要な接続元だけに許可し、SELinuxを維持する。
  4. peer、brick、heal、split-brain、容量、inode、遅延を継続的に監視する。
  5. 削除とランサムウェアに備えて別のバックアップを作成し、定期的に復元試験を行う。
  6. ノード交換、パッケージ更新、split-brain時の正本選択を、変更前に練習する。

毎日または監視システムで収集する最小項目

sudo gluster peer status
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary
df -P /bricks/brick1
df -Pi /bricks/brick1

関連記事

まとめ

安全な構築で重要なのはコマンドの数ではなく、失敗条件を先に設計することです。Replica 3で過半数の判断が可能な構成を作り、専用brick、限定したファイアウォール、一貫した名前解決、状態検証、heal監視を一連の運用にします。独立バックアップと復元試験、サポートされるパッケージ供給経路まで備えて、運用可能なファイルサービスになります。