前回（ GlusterFSで成長 ）ニーズに合わせてGlusterFS 3.0.xを構成する方法を説明しました。 最近、GlusterFSを3.2.xにアップグレードしましたが、これらのバージョン間で構成に多くの違いがあったため、一般的なITマインドのプロセスを説明することにしました。
すぐに、新しいバージョンへの移行が古いバージョンのグリッチによるものであることを予約してください。
Amazon EBSの別の失敗の後です。 2番目のマスターのディスクが劣化し、勇敢なAWSエンジニアが問題を修正している間、サービスをオフにしました。 すべてが正常に戻った後、2番目のマスターをバックスキームに含めようとしましたが、取り返しのつかない事態が発生し、すべてのクライアントがハングアップし、ネットワークドライブが正常に応答しませんでした。 クライアントにエラーがあり、長いグーグルでフォーラムの「ヒント」につながり、そのようなハングが新しいバージョンで修正されたことがわかりました。
最初に明らかになったのは、古いバージョンの設定が機能しないことです。さらに、それらはもはや必要ではなく、すべてがコマンドラインから設定されます。
マスター-マスターのセットアップは以前とはまったく異なる方法で行われます。これは新しいスキームの最初のマイナスです。記事の最後でそれらについて説明します。
ピアの初期化：
root@files1.domain.com:~# gluster peer probe files2.domain.com Probe successful
私たちはチェックします：
root@files1.domain.com:~# gluster peer status Number of Peers: 1 Hostname: files2.domain.com Uuid: c8f2fg43-ch7e-47f3-9ec5-b4b66f81101d State: Peer in Cluster (Connected)
次に、ディスク（ボリューム）を作成します。
root@files1.domain.com:~# gluster volume create volume_data replica 2 transport tcp files1.domain.com:/data files2.domain.com:/data Creation of volume volume_data has been successful. Please start the volume to access data.
ディスクを起動します。
root@files1.domain.com:~# gluster volume start volume_data Starting volume volume_data has been unsuccessful
両方のマスターで実行します。
/etc/init.d/glusterfs-server restart
すべてがエラーなしで完了した場合、次のコマンドの出力は次のようになります。
root@files1.domain.com:~# gluster volume info Volume Name: volume_data Type: Replicate Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: files1.domain.com:/data Brick2: files2.domain.com:/data
この方法でボールへのアクセスを制限します。
root@files1.domain.com:~# gluster volume set volume_data auth.allow 10.*
情報をもう一度確認します。
Volume Name: volume_data Type: Replicate Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: files1.domain.com:/data Brick2: files2.domain.com:/data Options Reconfigured: auth.allow: 10.*
サーバーでのセットアップが完了したら、クライアントに移動します。 クライアントに適切なバージョンのパッケージをインストールでき、すでにシステムにインストールされていると思います。
root@client.domain.com:~# mkdir /data root@client.domain.com:~# mount -t glusterfs files1.domain.com:/volume_data /data
結果を見てみましょう：
root@client.domain.com:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.9G 6.6G 987M 88% / none 3.4G 112K 3.4G 1% /dev none 3.6G 0 3.6G 0% /dev/shm none 3.6G 64K 3.6G 1% /var/run none 3.6G 0 3.6G 0% /var/lock none 3.6G 0 3.6G 0% /lib/init/rw /dev/sdb 414G 6.1G 387G 2% /mnt tmpfs 10M 8.0K 10M 1% /tmp/tmpfs files1.domain.com:/ volume_data 200G 109G 92G 55% /data
client.domain.comで/ etc / fstabに書き込みます。
files1.domain.com:/volume_data /data glusterfs defaults,_netdev 0 0
また、再起動時に神経を節約するために、このような場合に通常のトリックを試します。
root@client.domain.com:~# umount /data root@client.domain.com:~# mount -a
すべてが正常であることを確認します。
root@client.domain.com:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.9G 6.6G 987M 88% / none 3.4G 112K 3.4G 1% /dev none 3.6G 0 3.6G 0% /dev/shm none 3.6G 64K 3.6G 1% /var/run none 3.6G 0 3.6G 0% /var/lock none 3.6G 0 3.6G 0% /lib/init/rw /dev/sdb 414G 6.1G 387G 2% /mnt tmpfs 10M 8.0K 10M 1% /tmp/tmpfs files1.domain.com:/ volume_data 200G 109G 92G 55% /data
以上です。
また、新しいGlusterFSの短所についても説明します。
1）セットアップ時に両方のウィザードがオンラインになっていない場合、最初のコマンドで停止します。
2）以前のバージョンでは、ボールにパスワードを設定していましたが、新しいパスワードでは、上記のauth.allow：10. *でしかできなかったことができます。これは、理解できるように、常に良い習慣ではありません。
3）
/etc/fstab: files1.domain.com:/volume_data /data glusterfs defaults,_netdev 0 0
Glasterワーカーは、単一サーバーへのこのようなリンクは、ピアやその他のものの構成を引き出すためだけのものだと言っていますが、！
実際、1つのマスターが消えた場合、クライアントは2番目のマスターがどこにあるかを認識し、すべてが既にマウントされている場合はすべてうまくいきますが、残念ながら、再構築が必要な場合は、fstabで指定されたホストが横たわっている間にイメージからマシンを上げます。 構成を引き出すことができないため、ボールは起動しません。 そして、新しいバージョンのこの変更は、分散ファイルシステムIMHOにとって非常に間違っています。