☰

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그 중 어느 것도 문제에 영향을 미치지 않았습니다(결론은 문제가 될 수 없다는 것입니다).

또한 우리가 피하려고 했던 다수의 삼바 로그 파일을 추출하고 분석했습니다.어느"실패" 또는 "시간 초과" 또는 잘못된 구성으로 인해 오류를 일으킬 수 있는 모든 항목을 마침내 모두 수정했지만 문제는 여전히 지속됩니다.

또한 기본 임대 시간을 매우 작은 값(예: 10초)으로 설정하는 등 몇 가지 다른 DHCP 서버 설정을 시도했지만 이는 문제에 아무런 영향을 미치지 않았습니다.

또한 Samba가 SMB2 또는 SMB3_11을 사용하도록 강제하려고 시도했지만 사용된 SMB 프로토콜을 고정 값으로 설정해도 문제가 해결되지 않았습니다. winPE 클라이언트를 3~4회 다시 시작한 후 SMB 공유가 더 이상 즉시 연결되지 않습니다.

빠른 ping이 성공한 후에는 공유 마운트를 계속 시도하는 동안 서버에 높은 CPU/메모리 로드가 발생하지 않습니다. 또한 우리는 속도계를 사용하여 네트워크 대역폭을 모니터링하고 연결에 대한 매우 낮은 로드만 볼 수 있습니다(단 몇 KB/s의 위아래). 공유를 마운트하려는 이러한 느린 시도 동안에는 핑 시간 자체가 증가하지 않습니다.

답변1

추가 후속 조치로, 오늘 우리는 지연이 서비스(Samba)에서 오는지 아니면 호스트/네트워크에서 오는지 확인하기 위해 파일 전송 아키텍처를 삼바에서 HTTP로 옮기고 있음을 알려드리고 싶습니다. 우리는 애플리케이션에 필요한 파일을 호스팅하기 위해 apache2를 사용하기로 결정했기 때문에 반나절 동안 Samba와 관련된 동일한 문제에 직면했지만 성공하지 못했습니다. 4시간이 넘는 테스트(아파치 공유에서 페이로드를 성공적으로 다운로드한 후 클라이언트를 자동으로 다시 시작한 경우) 동안 실패한 연결 시도는 발견되지 않았습니다!

그래서 우리는 우리가 만든 다양한 설정 간의 간섭을 방지하기 위해 삼바 구성을 실제로 다음과 같은 베어 메탈 구성으로 줄이기로 결정했습니다.

[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)을 다운로드한 후 클라이언트를 재부팅합니다. 두 번의 재시작을 지연시키는 여러 클라이언트에서 병렬 테스트를 실행하더라도 한 클라이언트가 "정지"되면 다른 새 클라이언트가 즉시 시작된다는 것을 알 수 있습니다. 결론적으로 문제는 클라이언트/Samba 간섭 또는 특정 클라이언트에서 Samba 공유로의 동시 연결이 너무 많기 때문에 발생한다는 것입니다.

반나절 동안 아파치를 사용하면 문제가 발생할 가능성이 낮기 때문에 문제를 완전히 삼바로 좁혔다고 생각합니다. 또한 Apache를 사용하는 모든 것이 예상대로 작동하므로 서버나 네트워크 구성에서는 그렇지 않을 것이라고 생각합니다.

당신도 같은 생각을 하고 이것이 삼바임에 틀림없다고 말했을까요?

도움이 될만한 아이디어가 있다면 대단히 감사하겠습니다. 우리는 이 특정 사례를 해결했으므로(우리의 솔루션은 삼바를 사용하지 않는 것임) 이 문제의 근본 원인을 알고 싶습니다. 왜냐하면 다른 공장 부서에서도 비슷한 문제가 있고 네트워크를 통해 파일을 공유하기 위해 삼바를 사용하는 것을 피할 수 없기 때문입니다. . 따라서 더 많은 의견이 있으시면 이 문제를 계속해서 디버깅할 의향이 있습니다.

더 이상의 혼란을 피하기 위해 Marcel Kohlmeyer와 나는 같은 문제를 동시에 연구하는 동료라는 점을 말씀드리고 싶습니다.

관련 정보