RHCS 5NFSクラスターノードが解放されないTCP 2049再配置時
2ノードのRedHatNFSクラスターがあると想像してみてください。各ノードはRHEL5.464ビットであり、データ用にSAN LUNを共有します。各サーバーのプライマリインターフェイスはHAフェイルオーバーボンディング（bond0、eth0 + eth1）であり、標準のフローティングクラスターがあります。 NFSのリソースIP。クラスター構成は標準のRedHatツールを使用してセットアップされ、NFSにはファイアウォールを通過するために/ etc/sysconfig/nfsで定義された静的ポートがあります。これまでのところ、これで十分ですよね？プラクティス–サーバーまたはクラスターのセットアップで使用されるファンキーまたは奇妙なものは何もありません。
問題の核心は、クライアントがTCPを使用してエクスポートされたNFSv4共有をマウントしている場合です。クラスターサービスで他のノードに再配置すると、新しくパッシブなノードが2049/tcp（nfsデーモン）を保持します。 ）技術的に不可能であるにもかかわらず、現在欠落しているクラスターIPを使用してクライアントに接続を確立しました（私が知る限り）。「解決策」は、クライアントからマウントするときにUDPを使用するように移行することでした。何が起こっていたのか（そしてもっと重要なのはそれを修正する方法）。理由に関する手がかりは大歓迎です。詳細は以下をご覧ください。
Cluster IP: 1.1.1.10
Client IP: 2.2.2.100
最初は、NFSサービスはノードAで実行されており、ノードAにはbond0：0としてエイリアスされたクラスターIPがあり、SANマウントされています。NFSクライアントはNFSv4を介して接続されていますTCPで、問題なく動作しています。ノードAのnetstatには、次のように表示されます。
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
すべてが本来あるべき姿です。ノードAで、標準の「clusvcadm -r nfs-svc -m node-B」コマンドを実行して、NFSをノードBに移動します。ノードAとノードBの両方のsyslogで、適切なメッセージが表示されます– NFSの停止、IPの解放/移動、SANアンマウント/マウントなど）。NFSクライアントに表示されます。 NFSサーバーに関するいくつかのsyslogメッセージが応答しなくなった後、正常に戻り、すべてが正常です。基本的に、NFSはノードBに再配置されます。
ただし、クラスターIP 1.1.1.10を所有しなくなったノードAに戻ると、2049の接続がnetstatに表示されます。簡単な「rcpinfo -p」は、そのポートでまだnfsdであることを確認します。
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
もちろん、ノードBでは、それが正しいのと同じことがわかります。 1000万ドルの質問は、なぜそれがまだノードAに表示されているのかということです。 IPがなくなるとすぐに、フラッシュされるはずでした…単にnfsdを再起動すると、ノードAの接続状態がFIN_WAIT1に変わり、最終的にタイムアウトになります。クラスターIPは、netstatだけで、ノードAのインターフェイスとして表示されなくなりました。
そして、ここで重要になります–このTCPファントム2049接続がまだノードAにあり、NFSサービスをノードAに再配置した場合（そのクラスターIPを再び取得します） 、ファントム接続がESTABLISHEDまたはFIN_WAIT1状態であるかどうかに関係なく、すべてのクライアントはNFSマウントでストールして停止します。そのファントム接続が最終的にノードAから消えた場合にのみ、NFSクライアントはNFSマウントを取り戻すことができます。これは5のオーダーです。 15分まで。
これを何度もテストし、ファイアウォールに関連しておらず、問題として再現可能であり、単なるまぐれではないことを確認しました。多くの時間の終わりに、唯一の実行可能な解決策は、クライアントをUDPに移動し、問題を完全に回避することでした。何が壊れているのか、そしてそれを修正する方法を本当に知りたいです。
NFS over TCPでは、A-> B-> Aから短時間で移動できないという印象を受けました。たとえば、 http：// www .spinics.net/lists/cluster/msg08758.html
使用する netstat -pリッスンしているプロセスのPIDを把握し（または、nfsdだと言ったので、psからPIDを見つけます）、それに対してstraceを実行します。多分それで何が起こっているのか理解することができます。または、straceコマンドを実行する前にclusvcadmを実行して、シグナルなどを取得するかどうかを確認することもできます（シグナルハンドラーにぶら下がっていたり、システムコールを待っている可能性があります）。戻る...）。
最悪の事態が発生した場合は、nfsdのデバッグバージョンをビルドしてgdbで実行し、clusvcadmを実行して、正確に何をしているのかを確認できます。