☰

Windows PEから再起動するたびにsmb-share接続時間が長くなります。

tag-icon • tag-icon debian samba performance smb
Windows PEから再起動するたびにsmb-share接続時間が長くなります。

私たちは現在、コンピュータのBIOSを自動的に更新するシステムを開発しています。

システムは、PXE-Bootから起動したWindows 10 PEで実行されます。最初のステップは、必要なデータがすべて保存されたSMB共有に接続することです。

共有自体は、Debian 4.9.88-1+deb9u1 (smbd バージョン 4.5.12-Debian) でホストされています。

質問

このプロセスを実行するには、複数回再起動してWindows PEを再起動する必要があります。

各システムは最初の起動時に正しく動作しましたが、Windows PEで再起動するたびにSMB共有への接続に時間がかかり、時にはWindowsエラー63のためにタイムアウトすることもありました。

Windows PEは再起動するたびにRAMに「新しい」として保存され、持続しないため、問題はサーバー側にあると考えられます。

Sambaのログファイルには、ホスト接続に関連するエラーは含まれていません。

PEへのマウントコマンド

NET USE B: \\SERVER\buffet \user:user password

Windows 10では、匿名ゲストログインやパスワードのない共有を許可していないため、ログイン資格情報を使用しないことはオプションではありませんが、個人的にはこの問題が認証に関連しているとは限りません。

サンバ構成

ご覧のとおり、さまざまなタイムアウト設定を試しました。

[global]
    workgroup = WORKGROUP
    security = user
    server role = standalone
    disable netbios = no
    server string = %h
    map to guest = Bad User
    obey pam restrictions = Yes
    passdb backend = tdbsam
    pam password change = Yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    unix password sync = Yes
    log file = /var/log/samba/log.%m
    log level = 10 winbind:5 auth:3
    max log size = 1000
    dns proxy = No
    usershare allow guests = Yes
    panic action = /usr/share/samba/panic-action %d
    create mask = 0777
    directory mask = 0777
    map hidden = no
    map system = no
    map archive = no
    store dos attributes = yes
    dos filemode = Yes
    acl map full control = Yes
    server min protocol = SMB3_10
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    read raw = yes
    write raw = yes
    server signing = no
    strict locking = no
    min receivefile size = 16384
    use sendfile = Yes
    aio max threads = 250
    aio read size = 1
    aio write size = 1
    ldap timeout = 3
    deadtime = 1
    winbind request timeout = 10
    name cache timeout = 0
    winbind max domain connections = 50
    winbind max clients = 750
    inherit owner = No

[buffet]
    path = /share/buffet
    public = yes
    writeable = no
    browseable = yes
    guest ok = yes
    force user = nobody
    force group = nogroup
    read only = yes
    case sensitive = no
    default case = lower
    preserve case = yes
    short preserve case = yes

ホストが無期限に再起動し、共有にすぐに接続できるように設定を変更するにはどうすればよいですか？

それを修正しようとする

上記のように、いくつかのタイムアウト設定を試しましたが、smb.confどちらも問題には影響しませんでした（結論は問題にならないということです）。

また、私たちが避けようとした多くのSambaログファイルを抽出して分析しました。どの「失敗」、「タイムアウト」、または誤った設定が原因でエラーを引き起こす可能性があるすべてのエントリを最終的にすべて修正しましたが、問題は引き続き解決されます。

また、デフォルトのリース時間を非常に小さい値（10秒など）に設定するなど、いくつかの異なるDHCPサーバーを設定しようとしましたが、これは問題には影響しませんでした。

また、SambaがS​​MB2またはSMB3_11を使用するように強制しようとしましたが、使用されているSMBプロトコルを固定値に設定しても問題は解決しませんでした。 winPEクライアントを3〜4回再起動した後、SMB共有はすぐに接続されなくなります。

クイック ping が成功した後は、共有マウントの試行中にサーバーに高い CPU/メモリ負荷が発生しません。また、スピードメーターを使用してネットワーク帯域幅を監視し、接続への非常に低い負荷しか表示できません（わずか数KB / sの上下）。共有をマウントしようとするこれらの遅い試みの間、ping時間自体は増加しません。

ベストアンサー1

さらなるフォローアップとして、今日私たちは、遅延がサービス（Samba）から来ているか、ホスト/ネットワークから来ているかを確認するために、ファイル転送アーキテクチャをSambaからHTTPに移動していることをお知らせしたいと思います。私たちはアプリケーションに必要なファイルをホストするためにapache2を使用することに決めたので、半日の間にSambaに関連する同じ問題に直面しましたが、成功しませんでした。 4時間以上のテスト中（Apache共有からペイロードを正常にダウンロードした後にクライアントを自動的に再起動した場合）、失敗した接続試行は見つかりませんでした！

そこで、私たちが作ったさまざまな設定間の干渉を防ぐために、Samba構成を実際に次のベアメタル構成に減らすことにしました。

[global]
workgroup = WORKGROUP
security = user
server role = standalone
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
map to guest = Bad Password
log file = /var/log/samba/log.%m

ただし、これらの非常に制限された構成にもかかわらず、非常に制限された回数の再起動後にサーバーへのpingの成功（可用性の確認）とsmb共有接続の間の遅延が最終的な再起動まで増加し始めるという問題がまだ発生します。時間が経つと、「ネットワークパスが見つかりません」というエラーが発生します。

この場合、興味深いのは、利用可能なすべてのクライアントに対してこの動作を繰り返すことができることです。 WinPEを起動し、サーバーにpingを実行し、pingが可能な場合はSamba共有に接続し、いくつかの必須ファイル（わずか数MB）をダウンロードしてクライアントを再起動します。 2回の再起動を遅らせる複数のクライアントで並列テストを実行しても、1つのクライアントが「停止」すると、別の新しいクライアントがすぐに起動することがわかります。結論として、問題は、クライアント/Samba干渉または特定のクライアントからSamba共有への同時接続が多すぎるために発生することです。

半日にApacheを使用すると、問題が発生する可能性が低いため、問題を完全にSambaに絞り込んだと思います。また、Apacheを使用するすべてが期待どおりに機能するため、サーバーやネットワーク構成ではそうではないと思います。

あなたも同じ考えをしてこれがサンバイムに間違いないと言ったのでしょうか？

役に立つアイデアがあれば、よろしくお願いします。私たちはこの特定のケースを解決したので（私たちの解決策はSambaを使用しないことです）、この問題の根本的な原因を知りたいです。他の工場部門でも同様の問題があり、ネットワークを介してファイルを共有するためにSambaを使用することを避けることができないからです。 。したがって、より多くの意見がある場合は、この問題を引き続きデバッグする予定です。

これ以上の混乱を避けるために、Marcel Kohlmeyerと私は同じ問題を同時に研究している同僚であることをお伝えしたいと思います。

おすすめ記事