こちらのページは、Guochun Shiさんが作成し、現在はデーブ・ダイクストラ(Dave Dykstra)が中心となって管理しています。
次のいずれかをご参照ください。
アラン・ローバトソン(Alan Robertson)著「 Highly-Affordable High-Availability」 (米国版Linux Magazine 2003年11月号に掲載)
アンドレ・ボンホート(Andre Bonhote)著のHA-NFSに関する「High-Availability NFS Server with Linux Heartbeat」(pdf)(欧州版Linux Magazine 2003年8月号に掲載)
Falko Timmeさんの「Setting Up A Highly Available NFS Server」も役立ちます
手際よくセットアップを完了させるには、以下の手順に従ってください(Heartbeatのセットアップ方法について、すでに理解していることが前提です)。
2台のサーバー間のハードウェア、またはDRBDによって共有された共有ディスクデバイスを使用していることを確認します。
いずれかのマシンで共有デバイスをマウントします。例えば、デバイスが/dev/sdb1で、マウント先のディレクトリが/dataである場合には、次のコマンドを実行します。
mount -t ext3 /dev/sdb1 /data エクスポートするディレクトリが/data/userdataであり、このディレクトリがない場合は、作成してください。
mkdir /data/userdata
/var/lib/nfsを共有ディスクに移動し、リンク(/var/lib/nfs)を作成します。
mv /var/lib/nfs /data ln -s /data/nfs /var/lib/nfs
もう一方のマシンで、/var/lib/nfsディレクトリを削除し、リンクを作成します。
rm -fr /var/lib/nfs ln -s /data/nfs /var/lib/nfs
rpc.statd クラスタ名(ホスト名またはIPアドレス)を入力する必要があります。Debianでは、ロックサービスは/etc/init.d/nfs-commonで開始されます。/etc/default/nfs-commonにSTATDOPTS="-n <cluster_host_name>"を入力して、コモンファイルを編集する必要がありません。それ以外のLinuxシステムでは、/etc/init.d/nfslockスクリプトにロックサービスが含まれています。
start() { ... echo -n $"Starting NFS statd: " ... daemon rpc.statd "$STATDARG" -n <cluster_host_name> .... }
ユーザーディレクトリをエクスポートします。/etc/exportsに次の行を追加します。
/data/userdata *(rw,sync)
exportfs -a
NFSサーバー上でファイルシステムをNFSマウントすることはお勧めできません。かつて、デーブ・ダイクストラ(Dave Dykstra)が、両方のサーバーでアクティブサーバーの複製ファイルシステムをNFSマウントするという構成を試み、何とか動作するようになりました。しかし、「NFSサーバーが応答しない」という問題が起こり、Heartbeatがフェイルオーバしないケースが無くならなかったため、この構成での運用は最終的に断念しました。最大の問題は、fuserコマンドのハングです。詳細については、メーリングリストのここからここまでの議論のアーカイブをご参照ください。
注: デバイスのメジャー/マイナー番号はNFSファイルハンドルに埋め込まれるので、フェイルオーバの実行に合わせてメジャー/マイナー番号が変更されると、ファイルハンドルが無効になってしまいます。DRBDを使用しているときには、構成を変更して番号を合わせていただくか、または共有ディスクを使用しているときには、EVMSやLVMを使用して同じメジャー/マイナー番号を持つ共有ボリュームを作成してください。
EVMSはhttp://evms.sourceforge.net/から、 LVMはhttp://www.sistina.com/products_lvm.htmからダウンロードできます。
NFSデバイスの番号割り当て問題に対処する別の方法は、新バージョンのNFS(2.6 Linuxカーネルに含まれる)で提供されています。これらのバージョンでは、マウントしたデバイスのメジャー/マイナー番号の代わりに、fsidパラメータによって整数を指定できます。詳細については、exports(5)をご参照ください。
NFSロックの動作確認のために、Heartbeatが動作するHA環境でNFSの広範にわたるテストを行いました。ここでは、テストとその結果についてご説明します。Bonnie++でNFS I/Oをテストし、Connectathonスイートおよび独自設計の複数クライアントNFSロックテストでNFSをテストしました。
以下のha.cfファイルを使用
debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 10 warntime 10 initdead 20 udpport 694 bcast eth0 # Linux auto_failback off node posic066 node posic067 apiauth ping gid=haclient uid=gshi,hacluster apiauth ccm gid=haclient uid=hacluster apiauth evms gid=haclient uid=root apiauth ipfail gid=haclient uid=gshi,hacluster
ロックを使用していない場合、NFSはLinux-HAとともに順調に動作します。Bonnie++(バージョン1.03a、http://www.coker.com.au/bonnie++/からダウンロード可能)は、2台のNFSサーバーで2分ごとにフェイルオーバを交互に繰り返しながら、約6時間動作しました。
テスト手順は、以下のとおりです。
両方のサーバー(posic066およびposic067)でHeartbeatを起動します。
5分ごとにposic066/posic067を再起動します。auto_failbackがoffに設定されているため、NFSサーバースイッチが5分ごとに実行されます。
posic067 xxx.xxx.61.111 Filesystem::/dev/sdb1::/data::ext3 nfslock nfsテスト結果:何度か繰り返した後、障害が発生し、errno=37「no lock record avaiable」が表示された。
posic067 Filesystem::/dev/sdb1::/data::ext3 nfslock nfs xxx.xxx.61.111テスト結果:障害が発生し、errno=37が表示された。
複数クライアントのロックテストコードのソースコードは、Linux-HA Mercurialレポジトリのcontrib/mlock/ディレクトリに含まれています。
テスト手順は、以下のとおりです。
両方のサーバー(posic066およびposic067)でHeartbeatを起動します。
5分ごとにposic066/posic067を再起動します。ja/ha.cf/AutoFailbackDirective_ja auto_failbackがoffに設定されているため、NFSサーバースイッチが5分ごとに実行されます。
posic067 xxx.xxx.61.111 Filesystem::/dev/sdb1::/data::ext3 nfslock nfsテスト結果:障害が発生し、errno=37が表示された。
posic067 Filesystem::/dev/sdb1::/data::ext3 nfslock nfs xxx.xxx.61.111テスト結果:一度は成功したものの、2004年5月18日に行われたテストでは新たに障害が発生し、errno=11が表示された。
posic067 portblock::tcp::111::block portblock::udp::111::block xxx.xxx.61.111 \ Filesystem::/dev/sdb1::/data::ext3 nfslock nfs \ portblock::tcp::111::unblock portblock::udp::111::unblock
テスト結果:障害が発生し、failed with errno=37
が表示された。
さらに、ラッパー関数を使用してfnctlを無効にしてみました。そのラッパー関数では、1回目に障害を起こすと、fcntlが2回呼び出されます。このラッパー関数を使用すると、成功することもありますが、障害が発生することもあります。
クライアントがロックテストを実行している最中に、サーバーのフェイルオーバが実行されると、ファイルシステムのマウント解除が失敗する恐れがあります。実行したロックテストはConnectathonです。これは、2台のマシン(サーバーとクライアント)だけを使用して、以下の手順を実行することで、簡単に再現できます。
====> 「the device is busy」のエラーが返されます。
サーバーとクライアントの両方で、常に同じカーネルバージョンを使用しました。Red Hat 9では、カーネル2.4.20、2.4.26、2.6.5-1.339を使用しました。いずれのカーネルでも、同様に障害が発生しました。
ただし、Linux-HA(バージョン1.2.1以降)では、この障害の発生時には自動的にマシンを再起動してサービスを自動的に続行するために、これは重大な問題ではありません。サービスは中断されることなく続行されますので、ロックとデータの整合性に影響は生じません。
2004年5月付のlinux-NFSメーリングリストに、ジェフ・レイトン(Jeff Layton)が、この問題に対する修正を発見しました。ディストリビューションに、NFSシャットダウンスクリプトを組み込む必要があります。Jeffによると、lockdカーネルスレッドにSIGKILLシグナルを送信すると、全てのロックが解放され、ファイルシステムをマウント解除することができます。以前に、lkmlでもこれについて議論がなされています。
クライアントアプリケーションがファイルロックを使用しなければ、HA NFSは正常に動作します。しかし、クライアントアプリケーションがロックを使用すると、単一のNFSサーバーに到達できないエラーが発生します。NFSにはこのような問題を引き起こすバグが複数あります。 -- Guochun Shiさん
しかし、NFSカーネルを適切に実行してさえいれば、大部分の問題は修正ができるものです。それでもなお、集中的なロックが行われると、ロック障害が発生する恐れがあります。解決方法はまだ確認されていません。 -- アラン・ロバートソン(Alan Robertson)
上記の手順やコメントは、主にアクティブ/パッシブ配置に適用されるものです。アクティブ/アクティブ構成については、マット・シリンガー(Matt Schillinger)のNFSページをご参照ください。