ネットワーク接続は100%OKです。ベンチマークは、LACPが完全に機能し、理論上の最大値である20GBpsに近づいていることを確認しています。
systemdは、シャットダウン中にネットワークスタックが停止していることを検出せず、NFS共有をアンマウントするには遅すぎるまで待機するため、アンマウントに失敗し、NFSサーバーが応答するまで無期限にハングします。
「systemctlstopnetwork.service」を実行した後も、network.targetとnetwork-online.targetの両方がactiveと見なされます。
/etc/fstab
ファイルを介して追加されたNFSマウントは、*.mount
systemdユニットに変換されます。これらのユニットは、 `network-online.targetに依存するremote-fs.target
に自動的に依存します。
ドキュメント から、network * .targetは、ネットワークが稼働しているかどうかなどを検出するためにネットワーク管理ツールに依存しているようです。これは、NetworkManager
、systemd-nerworkd
、またはその他のものにすることができます(ただし、何ですか?)。ジャンプスタートテンプレートがインターフェイスを管理するために古いinitスクリプトに依存しているように見えるので、私の問題はここにあると思います。そして、systemdがネットワークがアップまたはダウンしていることを通知するためにsystemdと対話できるとは思えません(systemctl stop network
でネットワークスタックを停止するために使用されているにもかかわらず)
私の2番目の仮説は、ifcfg- *ファイルを介してもlibteam/teamdを使用するネットワークチーミングは、systemdnetwork.targetスコープ外であるというものです。 teamd systemdユニット([email protected]を含む)とネットワークユニットの間に依存関係はないようです。これは、この問題を表示するシステムがLACP対応システムのみであり、通常のボンディングを使用する場合は以前は問題がなかった理由を説明します。
だから私の質問:ネットワークスタックがダウンする前に、通常はシステムを再起動するときに、NFS共有がアンマウントされていることを確認する必要がある解決策は何ですか?
PS:上記のソリューションがNFSマウントを作成する方法から来ていない場合は、このサーバーに共有を追加する必要がある人に特別な手順を通知する必要がないので、より良いでしょう。私たちの生産プロセスを考えると、これはほぼ不可能に思えます。
残念ながら、この問題に対する唯一の「正しい」答えは、現時点ではNetworkManager
(Red Hatのベストプラクティス)またはsystemd-networkd
のいずれかであるネットワーク管理ツールを使用しているようです。
NetworkManagerの使用を回避するために使用した回避策は次のとおりです。
編集/etc/systemd/system/[email protected]/override.conf
[Unit]
Before=remote-fs.target
[Install]
WantedBy=network-online.target
[Service]
ExecStop=/bin/bash -c "while grep ' nfs ' /proc/mounts; do sleep 5; done"
TimeoutStopSec=30
teamd@<teamname>.service
ファイルは/etc/systemd/system/*
よりも優先されるため、このファイルは/usr/lib/systemd/system/
のシステムテンプレートに連結されます。
停止すると、systemdは最初にNFSのアンマウントを開始しますが、デフォルトでは、NFSのアンマウントが完了するのを待ちません。次に、ネットワーク接続を担当するteamd @ .serviceに、NFS共有がマウント解除されるまで最大30秒待機させてから、teamdデーモンを強制終了してシャットダウンプロセスを続行します。
参照: