ストレージの壁：単一サーバーの限界
かつて私が担当したWordPressプロジェクトでは、アクセス数が数百件から月間5万PVへと一晩で急増したことがありました。3つのウェブノードとロードバランサーを追加して水平スケーリングを行いましたが、すぐに「メディアアップロード」という壁に突き当たりました。
rsyncのcronジョブを使用するとサーバー間で60秒のラグが発生し、ユーザーがノードAでアップロードした写真が、ノードBで表示しようとすると404エラーになるという問題が起きました。そこで中央のNFSサーバーに切り替えましたが、カーネルアップデートのためにそのVPSを再起動しただけで、プラットフォーム全体が5分間停止してしまいました性能と引き換えに、巨大な単一障害点（SPOF）を作ってしまったのです。
成長を続けるインフラの多くは、最終的にこのボトルネックに直面します。ディスクの故障やサーバーのメンテナンス中でもオンラインを維持でき、拡張可能なストレージが必要です。従来のローカルストレージは「データのサイロ化」を招きます。これはハードウェアが故障した瞬間に消滅してしまう情報の島です。アプリケーションに高可用性（HA）を求めるなら、単一マシンの稼働率に頼ることはできません。
標準的なNFSが正解ではない理由
NFSはLinux界の古き良き定番ですが、限界があります。NFSは本質的に分散型ではなく、「1対多」のアーキテクチャだからです。
NFSマスターがダウンすると、接続されているすべてのクライアントがハングし、I/O待機時間の増大や、手動での再起動が必要な「stale file handle（古いファイルハンドル）」エラーが発生することがよくあります。さらに、ウェブサーバーを増やすと、NFSホストの単一ネットワークインターフェースがボトルネックになります。必要なのは、ストレージ自体がクラスター化され、データを複数のノードに分散して負荷を分散し、冗長性を確保できるシステムです。
選択肢の比較：Ceph vs. GlusterFS
分散ファイルシステムの選択は、通常2つの大きな名前に集約されます：
- Ceph: エンタープライズ界の強力なツールです。非常に堅牢ですが、学習曲線が非常に険しいです。ペタバイト級のデータを管理し、CRUSHマップを監視する専門チームがいない限り、Cephを使うのは芝刈り機にロケットエンジンを積むような過剰装備に感じられるかもしれません。
- GlusterFS: ほとんどのDevOpsエンジニアにとって現実的な選択肢です。既存のファイルシステム（「ブリック」と呼びます）を集約して、単一の仮想ボリュームを作成します。デプロイが容易で、線形にスケールし、特殊なカーネルなしで標準的なハードウェア上で動作します。
過去数年間にわたり数十のプロダクション環境を管理してきた経験から、中規模プロジェクトの90%においてGlusterFSが最高のROI（投資対効果）を提供することを確認しています。現代のアプリケーションが求める「ネットワーク越しのRAID-1」という安全網を提供しながらも、管理の手間はかかりません。
黄金の標準：3ノード・レプリケート・ボリューム
2つのノード間でデータの不整合が起き、ボリュームが破損する「スプリットブレイン」という悪夢のようなシナリオを避けるためには、3ノードクラスターが最小の安全な構成です。今回は3台のUbuntuサーバーを使用して、レプリケート・ボリューム（複製ボリューム）を作成します。これにより、すべてのバイトが3つのノードすべてに同時に書き込まれ、2ノードまでの故障に耐えられるようになります。
1. ネットワークと準備
一貫性が重要です。DNSサーバーの調子が悪い日でもノード同士が通信できるように、/etc/hostsを設定します。
# 全ノードの /etc/hosts に以下を追加
10.0.0.10 storage01
10.0.0.11 storage02
10.0.0.12 storage03プロのヒント：ブリックには必ず専用のディスクまたはパーティションを使用してください。Glusterのデータをルートパーティションに保存すると、ストレージがいっぱいになった時にOSごとクラッシュする原因になります。ここでは、専用ディスクが /data/gluster にマウントされていると仮定します。
2. ソフトウェアのインストール
公式のGluster PPAを使用しましょう。Ubuntuのデフォルトリポジトリにあるバージョンは、メジャーリリースがいくつか遅れていることが多く、重要なバグ修正が含まれていないことがあります。
sudo add-apt-repository ppa:gluster/glusterfs-11
sudo apt update
sudo apt install glusterfs-server -y
sudo systemctl enable --now glusterd3. 信頼済みストレージプールの構築
storage01 から、他の2台のサーバーをクラスターに招待します。このハンドシェイクにより、信頼済みストレージプール（Trusted Storage Pool）が確立されます。
sudo gluster peer probe storage02
sudo gluster peer probe storage03sudo gluster peer status を実行して、状態が「Connected（接続済み）」であることを確認します。
4. ボリュームの作成
ボリューム名を shared_data とします。レプリカ数を3に設定すると、2台のサーバーが同時に故障してもデータは維持されます。
# 全ノードでブリックディレクトリを作成
sudo mkdir -p /data/gluster/gv0
# storage01 でのみ実行
sudo gluster volume create shared_data replica 3 \
storage01:/data/gluster/gv0 \
storage02:/data/gluster/gv0 \
storage03:/data/gluster/gv0
sudo gluster volume start shared_data5. クライアントからの接続
ボリュームのマウントは簡単です。Glusterクライアントの素晴らしい点は、そのインテリジェンスにあります。たとえ storage01 を指定してマウントしても、すべてのノードのアドレスが含まれた「volfile」を取得します。後で storage01 がダウンしても、クライアントは自動的に他のノードへフェイルオーバーします。
sudo apt install glusterfs-client -y
sudo mount -t glusterfs storage01:/shared_data /var/www/html/media現場で学んだ運用の教訓
デプロイは最初の一歩に過ぎません。クラスターを健全に保つために、以下のルールを覚えておきましょう：
- クォーラムの強制: ネットワークの瞬断によりノードが孤立することがあります。サーバーサイド・クォーラム（定足数）を有効にして、過半数のノードと通信できない「孤立した」ノードが書き込みを受け付けないようにします。これによりデータの乖離を防げます。
sudo gluster volume set shared_data cluster.server-quorum-type server - ネットワーク速度의 重要性: Glusterは同期レプリケーションを使用します。バックエンドネットワークが100Mbpsのボトルネックになっていると、ファイルへの書き込みは泥沼を歩くように遅くなります。ストレージトラフィックには、専用の10Gbpsプライベートネットワークが理想的です。
- 再起動テスト: 実際に壊してみるまでは、構成を信用しないでください。ノードを1台強制再起動し、ウェブアプリケーションが支障なく画像を表示し続けられるかを確認します。もしハングする場合は、タイムアウト設定を確認してください。
分散ストレージは単に容量を増やすためのものではありません。ハードウェア故障が発生しても、深夜3時に緊急のサポート電話がかかってこないという安心感を得て、ぐっすり眠るためのものです。GlusterFSは、インフラを「脆弱な単独サーバー」から「堅牢なクラスター」へと進化させる架け橋となります。
