web-dev-qa-db-ja.com

クラスター化されたサーバーのブート時にglusterfsマウント-RHEL 7

サーバーのペアでgluserfsを構成しましたが、これをクライアントマシンにマウントできます。また、両方のマシンをオフラインにして最初から起動するときに、ブート時に両方のglusterfsサーバーにglusterfsファイルシステムをマウントできるようにしたいと考えています。

これらのサーバーは、pacemakerを使用してクラスターとしてセットアップされます。共有データベースに加えて、pacemakerはglusterファイルシステムのマウント元となる仮想IPアドレスも提供しています。

次のコマンドを使用して、両方のサーバーが起動した後、ファイルシステムを手動でそれぞれにマウントできます。

mount -t glusterfs nodea:/gv0 /data

それは素晴らしいです。しかし、これは起動時に自動的に行われるようにします。

だから私はfstabにエントリを追加しようとしました：

nodea:/gv0  /data       glusterfs   _netdev 0 0

これは、クラスターの稼働後に「mount -a」コマンドを実行すると機能します。ただし、起動時には機能しません。 （これは、クライアントマシンがブート時にglusterfsをマウントする方法ですが、クラスターは稼働中です。したがって、もちろんそれらはブートで機能します。）

ブート時にglusterfsのマウントを処理するsystemdユニットファイルの作成も試みました。私のユニットファイルは「data.mount」という名前の/ etc/systemd/systemにあり、次のようになります。

# Mounting gluster fs at /data

[Unit]
Description = Automount gluster filesystem
After=pcsd.service

[Mount]
What=nodea:/gv0
Where=/data
Type=glusterfs

[Install]
WantedBy = pcsd.service

繰り返しますが、これは、コマンド「systemctl start data.mount」を実行して、両方のサーバーが稼働しているときに機能します。また、クラスター内のマシンの1つだけを再起動した場合にも機能します。ただし、両方のサーバーの再起動では機能しません。

クラスター内の両方のノードがダウンした場合、または何らかの理由で両方を同時に再起動したい場合は、両方のマシンが再起動したときに、glusterfsが/ dataにマウントされていることを確認します。

回避策として、両方のマシンのrootのcrontabに次の行を追加しました。

@reboot sleep 60 && mount -t glusterfs nodea:/gv0 /data
@reboot sleep 300 && mount -t glusterfs nodea:/gv0 /data

これは、両方のサーバーを最初から起動した場合に機能します。しかし、私の懸念は、pacemakerサービスの起動に5分以上かかる場合でも、/ dataのサーバーにglusterファイルシステムがマウントされていないことです。

Systemdユニットのファイルで実際にファイルシステムがマウントされているかどうかを確認し、マウントされるまで再試行しない方法はありますか？

ブート時にglusterfsをマウントして、実際にマウントされていることを確認する他の方法はありますか？

glusterfs
3
user5807441

必要なときにsystemdを自動マウントできるはずです。起動時のUbuntu 16.04のマウントにも問題がありました。 このメッセージ に基づいて追加しましたnoauto,x-systemd.automountからfstab行へ：

gluster1:/volume1   /storage-pool   glusterfs   defaults,_netdev,noauto,x-systemd.automount 0 0

アプリサーバーを数回再起動し、すべて正常にマウントしました。これもお役に立てば幸いです。

13
Dave Lozier

LPの態度を考慮して、この問題をハッキングしてきました。

ファイル：/etc/systemd/system/glusterfsmounts.service：

[Unit]
Description=Glustermounting
Requires=glusterfs-server.service

[Service]
Type=simple
RemainAfterExit=true
ExecStartPre=/usr/sbin/gluster volume list
ExecStart=/bin/mount -a -t glusterfs
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

それからあなたは：

systemctl daemon-reload

systemctl enable glusterfsmounts

そして再起動...これまでのところ私にとって最高/安定でした

6
Hvisage

スクリプトを使用して、ボリュームが実際に準備ができるまで、systemdのglusterfsサービスの「開始済み」ステータスを保持できます。

systemctl edit glusterd.service

[Service]
ExecStartPost=/usr/local/sbin/glusterfs-wait

次のようにファイル/usr/local/sbin/glusterfs-waitを作成します。

#!/bin/bash 
FAIL=1
until [ $FAIL -eq 0 ]; do
    gluster volume status all
    FAIL=$?
    test $FAIL -ne 0 && sleep 1
    done
exit 0

このファイルが実行可能であることを確認してください。

次に、マウントオーバーライドを作成します。たとえば、/mnt/storageの場合、mnt-storage.mountになります。スラッシュはハイフンになります。

systemctl edit mnt-storage.mount

これが機能せず、fstabエントリーを追加しただけの場合は、systemdを再ロードして、更新（systemctl daemon-reload）を認識させます。

[Unit]
After=glusterd.service
Wants=glusterd.service
0
Geoffrey