More from: NFS

NFSがつながらない・・・(解決編)

先日、「nfsがつながらない・・・」という記事を書いた。
その時にはクライアント側のサーバー(ややこしいな)の再起動をすれば解決するのでは無いかと考えていた。
今週に入って再起動の機会がある筈だったので、その時までなんとか我慢して運用かと思っていたところ、土曜の夜にトラブルで再起動の必要なサーバが止まってしまい、図らずも再起動となってしまった。
このことを知ったのは月曜になってからだったんだけど、早速nfsマウントを試してみるとやっぱり接続できないorz。
つまり、nfsサーバを先に停止したことが障害の原因では無かったということになる。
クライアント側に出るエラーは
”ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
と以前と同じものなので、やはりnfsサーバ側との通信が出来ていないことになる。
portmapperでは無いかとの指摘もあったが、nfsサーバ側のrpcinfoの結果を見る限りportmapperは動作している(ディストリビューションの関係で”portmap”ではなく”rpcbind”だったが)。
いろいろ考えた結果、ファイアウォール(iptables)に思い当たり、試しに/etc/rc.d/init.d/iptables stopで止めてみると、クライアント側からのrpcinfoコマンドにnfsサーバ側が応答してくるようになり、さらにnfsマウントも試したところ無事にマウント出来た。
つまり、先週から悩んでいたのはiptablesが原因だったということだ(汗)。
そこで、iptablesの設定で必要なポートを開けようとポート番号を調べてみたところ、現状で使っているポートが以下のようになっていた。
(rpcinfoの出力)
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 60503 mountd
100005 1 tcp 35344 mountd
100005 2 udp 48471 mountd
100005 2 tcp 42678 mountd
100005 3 udp 50205 mountd
100005 3 tcp 41105 mountd
100024 1 udp 56315 status
100024 1 tcp 57525 status
これを見るとmountdとstatusの二つは任意のポートを使っているようだ。
これではiptablesで沢山のポートを開けなくてはならず、セキュリティ的に不安なので使用するポートを固定する方法を調べた。
ポートを固定するにはnfsの設定ファイル(/etc/sysconfig/nfs)でコメントアウトされているポート番号(*_PORT)の項目のコメントアウトを外してnfsを再起動すれば良いとのこと。
早速実行してクライアント側でrpcinfoを実行してみた結果が下。
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 892 mountd
100005 1 tcp 892 mountd
100005 2 udp 892 mountd
100005 2 tcp 892 mountd
100005 3 udp 892 mountd
100005 3 tcp 892 mountd
100024 1 udp 662 status
100024 1 tcp 662 status
mountdが892、statusが662で固定されたので、それらを含む必要なポートをiptablesで開けるように設定したところ、iptablesを動作させてもnfsでのマウントもファイルへのアクセスも可能になった。
※当然ながらportmapperのポート(111)も開けるように設定した。
いやぁ、良かった良かった(汗)。

←クリックしてくれると嬉しいです。

mount解除は出来たものの・・・

仕事場のサーバの更新で、作業担当者がNFSサーバを先に止めてしまい、クライアント側でアクセス出来なくなってしまった。
クライアント側も一度止めて起動しなおせば良かったんだけど、こっちは止める予定が無かったのでそのままになっていた。
このことに気付いたのは作業が終了して運用に入ってから(汗)。
クライアント側でdfコマンドでマウント状況を見ようして途中で帰って来なくなって気付いた。
プロセスがディスク待ちとなってしまってシグナルを受け付けない状態で止められない。
こうなってしまっては一度再起動するしか手段は無いようだけど、すでに運用に入っているうえ、4年近く止めていないので起動時にfsckがかかるのが確実で起動にかかる時間が読めない。
mtabを見るとOS自体はNFSサーバの一部をマウントしたままと認識しているが、実際にはアクセス出来ない状態。
少なくとも、一度マウントを解除して再度マウントし直さなくてはならないんだけど、普通にumountコマンドで解除しようとしてもエラーが出て解除できない。
仕方がないので”umount -f”でやってみても駄目で、最後の手段”umoount -l”で試すとエラーは出たけどmtabからはエントリーが消えたので解除出来、df-kで見ても問題なく解除されていた。
後は再度マウントすれば良いんだけど、昨日の記事に書いたように再マウントできない状態になっている。
やっぱり再起動しないと駄目なんだろうなぁ・・・(汗)。

←クリックしてくれると嬉しいです。

nfsがつながらない・・・

仕事場のサーバ(群)を更新したら、nfsでのマウントが出来なくなった。
元々全てのサーバを仮想環境で動かしていて、その基盤自体を更新したので一部のサーバを除いて再起動となった。
それぞれのサーバの環境そのものは古い基盤からコピーしたので設定そのものに変化は無いが、一部の古い基盤上に残したサーバからnfsでの接続が上手く出来なくなってしまった。
もちろん両サーバの間の疎通確認は取れていて、pingやsshでの接続は問題無い。
ところが”mount -t nfs NFSサーバ:ディレクトリ マウントポイント”コマンドを実行すると,
“mount: RPC: ポートマッパーの失敗です – RPC: 受け取れません”
というエラーが表示されマウントできない。
nfsサーバ側ではnfsデーモンは動作させているのだけど、クライアント側からもチェックしてみようと思って、
”/usr/sbin/rpcinfo -p NFSサーバ”を実行すると、
”rpcinfo: ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
となってしまう。
つまりpingは通るけど、rpcinfoコマンドは通信できないらしい。
NFSサーバ側でrpcinfoコマンドを実行するとnfsもmountdも動作していると出る。
”arp -d NFSサーバ”でarpテーブルのエントリを削除しても変化無いので、今のところはお手上げ状態。
スタックさせたL3スイッチのトラブルがあったので、その影響らしいが再起動するしか無いのかなぁ?

←クリックしてくれると嬉しいです。

WIndows7でNFSを使おうと思ったら・・・

職場のPCはファイルサーバーへの接続にSMBを使っている。
SMBでは接続時の転送速度の問題があって、これをNFS接続に切り替えられないか?と思って調べてみると、クライアントOSとして使っているWindows7 ProにはNFSクライアントが実装されていなかった。
同じWindows7でもUltimate及びEnterpriseには実装されているので、そちらではNFS接続が可能。
WindowsXP Proなら「Windows Services for UNIX」をインストールすれば可能らしいが、サポートの終了したOSを業務で使うわけにもいかないのでボツ。
うーん、なんか良い手段は無いかなぁ?

←クリックしてくれると嬉しいです。

NFSマウントしたファイルシステムをsambaでクライアントに公開するには?

現場にあるPCサーバ(Linux)にはクライアントPCで共有するファイルを置くためのディレクトリを用意して、そこをsambaで公開している。
数年前に設置した当初はそれほど容量を必要としない筈だったので、用意したパーティションの容量は10GB程度。
ところが運用が始まると画像データの置き場にされてしまい、あっと言う間に容量不足となってしまった。
なので現在はクライアントPCの一台をファイルサーバとして使っている状態。
本当はサーバにファイルを置きたいのだが物理的にHDDの容量が足りず、かといって現場が遠隔地なので気軽にHDDを増設しに行くことも出来ない。
そこで思いついたのは他の現場にあるHDD容量の多いサーバにNFSでつないで、その領域をsambaで開放するという手段。
早速調べてみるとsambaユーザー会辺りのMLで「速度が実用に耐えない」との投稿があったorz
そのMLではSANとSANサーバをNFSで接続して(ネットワークはGbit)、SANサーバがsambaで領域を公開しているが、クライアントからのファイルコピーで実測1kBps未満の速度しか出なかったとのことだ。
やり取りを読んでみると最終的にはなんとか使えそうな速度にはなった(マウントオプションに”nolock”を付ける)とのことが書かれていたが、安易に行うと痛い目を見ることになりそうだ。
それでもやりかたによってはなんとかなりそうな気がしてきたので、今度じっくり試してみようかと思う。

←クリックしてくれると嬉しいです。