このチュートリアル シリーズでは、可用性の高い WordPress Web サイトを最初から設定します。

パート1 – 概要、考慮事項、アーキテクチャ
パート2 – VPSの注文
パート3 – Ansible
パート4 – Gluster（この記事）
パート5 – WordPressのインストール
パート6 – MariaDBマルチマスター
パート7 – ラウンドロビンDNS、Let's Encrypt、そしてまとめ

これまでにかなりの進歩がありました。Ansibleを使うことで、サーバーのセットアップが格段にスピードアップしました。次はGlusterFSの設定を始めましょう。

GlusterFSは、各ノードで全く同じディレクトリ、ファイル、権限を持つことができる複製ファイルシステムです。WebファイルはGlusterFS上にホストし、あるノードにアートなどのファイルをアップロードすると、他のノードにも即座に複製されます。また、Let's EncryptとNginxの利便性向上にも活用し、MariaDBのセットアップ時にDBバックアップの転送を容易にする仕組みとしても活用します。

とりあえず、セットアップしてインストールします。

前後の作業があるため、一部の部分に「各ノード上」と「ノード1上」というラベルを付けます。各ノードへのSSHセッションを開いておくと、切り替えが簡単にできるので便利です。

各ノード

dmesg を実行すると、次のようなものが表示されます。

 [ 1.714306] sd 0:0:0:1: [sdb] 20971520 512バイトの論理ブロック: (10.7 GB/10.0 GiB)

dmesgには通常多くの出力があるので、

 dmesg | grep sdb

これはおそらくデフォルトでマウントされているので、アンマウントします

/dev/sdb をアンマウントする

/etc/fstabからこのファイルへの参照をすべて削除します。私のノード1では、以下の行を削除しました。

 /dev/disk/by-id/scsi-0HC_Volume_100431844 /mnt/HC_Volume_100431844 xfs 破棄、nofail、デフォルト 0 0

次に、パーティション ラベルを削除して新しいものを作成し、ドライブの 100% を使用する新しいパーティションを作成し、その上に XFS ファイルシステムを作成します。

 root@node1:~# parted /dev/sdb --align opt mklabel gpt
警告: /dev/sdb 上の既存のディスク ラベルは破棄され、このディスク上のすべてのデータが失われます。
続行しますか?
はい/いいえ? はい 
情報: /etc/fstab を更新する必要がある場合があります。
root@node1:~# parted /dev/sdb mkpart xfs 0% 100% 
情報: /etc/fstab を更新する必要がある場合があります。
root@node1:~# mkfs.xfs -f -i サイズ=512 /dev/sdb1
メタデータ=/dev/sdb1 isize=512 agcount=4, agsize=655232 blks
= sectsz=512 属性=2、projid32bit=1
= crc=1 finobt=1、sparse=1、rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
データ = bsize=4096 ブロック=2620928、imaxpct=25
= sunit=0 swidth=0 blks
命名 =バージョン 2 bsize=4096 ascii-ci=0, ftype=1
ログ =内部ログ bsize=4096 ブロック=16384、バージョン=2
= sectsz=512 sunit=0 blks、lazy-count=1
リアルタイム =なし extsz=4096 ブロック = 0、rtextents = 0
ブロックを破棄しています...完了。

これで、マウント ポイントを設定してマウントできます。

 root@node1:~# mkdir -p /data/brick1
root@node1:~# echo '/dev/sdb1 /data/brick1 xfs defaults 1 2' >> /etc/fstab
root@node1:~# systemctl デーモンリロード
root@node1:~#マウント -a
root@node1:~#マウント | grep sdb1
/data/brick1 タイプ xfs 上の /dev/sdb1 (rw、relatime、attr2、inode64、logbufs=8、logbsize=32k、noquota)
root@node1:~# df -h |grep sdb1
/dev/sdb1 10G 104M 9.9G 2% /data/brick1

次に、泡立てて、すすぎ、各ノードごとに繰り返します。

各ノード

それでは、glusterd を開始しましょう。

 systemctl で glusterd.service を有効にする
systemctl で glusterd.service を開始します。

ノード1

GlusterFS クラスターをセットアップしましょう。

 root@node1:~# Gluster ピアプローブ node2.lowend.party
ピアプローブ：成功
root@node1:~# Gluster ピアプローブ node3.lowend.party
ピアプローブ：成功

ノード2

 root@node2:~# Gluster ピアプローブ node1.lowend.party
ピアプローブ：成功
root@node2:~# Gluster ピアプローブ node3.lowend.party
ピアプローブ: ホスト node3.lowend.party ポート 24007 はすでにピアリストに存在します

ノード3

 root@node3:~# Gluster ピアプローブ node1.lowend.party
ピアプローブ: ホスト node1.lowend.party ポート 24007 はすでにピアリストに存在します
root@node3:~# Gluster ピアプローブ node2.lowend.party
ピアプローブ: ホスト node2.lowend.party ポート 24007 はすでにピアリストに存在します

ノード1

 root@node1:~# Glusterピアのステータス
ピアの数: 2

ホスト名: node2.lowend.party
ユーザーID: 4fdc500b-d0dc-4853-9eac-c30f31bf80d8
状態: クラスター内のピア (接続済み)

ホスト名: node3.lowend.party
UUID: 363cac9f-5cf2-485d-ac70-37afa25cd785
状態: クラスター内のピア (接続済み)

これをノード2とノード3で実行すると、同様の情報が表示されるはずです。GlusterFSは動作しています！では、ブリックを作成して追加してみましょう。

各ノード

mkdir -p /data/brick1/gv0

ノード1

 root@node1:~# glusterボリューム gv0 レプリカ3を作成 node1.lowend.party:/data/brick1/gv0 node2.lowend.party:/data/brick1/gv0 node3.lowend.party:/data/brick1/gv0
ボリューム作成: gv0: 成功: データにアクセスするにはボリュームを起動してください
root@node1:~# glusterボリュームの開始 gv0
ボリューム開始: gv0: 成功
root@node3:~# Glusterボリューム情報

ボリューム名: gv0
タイプ: 複製
ボリューム ID: 7be70513-926d-441e-99d8-e339e59db30a
ステータス: 開始済み
スナップショット数: 0
レンガの数: 1 x 3 = 3
トランスポートタイプ: tcp
レンガ:
ブリック1: node1.lowend.party:/data/brick1/gv0
ブリック 2:node2.lowend.party:/data/brick1/gv0
ブリック3: node3.lowend.party:/data/brick1/gv0
再構成されたオプション:
クラスター.粒度エントリ修復: オン
storage.fips-mode-rchecksum: オン
トランスポート.アドレスファミリ: inet
nfs.disable: オン
パフォーマンス.クライアントIOスレッド: オフ

各ノード

mkdir /gluster

/etc/fstab に追加:

 echo "localhost:/gv0 /gluster glusterfs defaults,_netdev,noauto,x-systemd.automount 0 0" >> /etc/fstab

その後：

systemctlデーモンリロード

fstab エントリが理解できない場合は、問題を指摘している次のブログ投稿を参照してください。

GlusterFS クラスターを実行する場合、サーバー自体のボリュームを使用する必要がある場合があります。

ブートプロセス中、GlusterFS /etc/fstab起動には少し時間がかかります。/etc/fstab からのマウントポイントを処理するsystemd-mount 、 glusterfs-serverサービスの起動が完了する前に実行されます。

マウントは失敗するため、再起動後にマウントされたボリュームがなくなることになります。

そこに解決策が提示されていますが、最初のコメントの解決策の方が簡単です。

再起動して、GlusterFS が期待通りに起動しマウントされているか確認します。私の場合は正常に動作しました。

Glusterのテスト

Glusterを試してみましょう。ノード1で：

 echo "これはGlusterが動作しているかどうかを確認するためのテストファイルです。" > /gluster/testfile.txt

次にノード2に移動します。

 root@node3:~# cat /gluster/testfile.txt 
これはテストファイルです。こんにちは。お元気ですか？

やったー！

次のセクションでは、Gluster を活用して WordPress を簡単にインストールします。