☰

호스트 검색과 관련된 autofs 설치 지연을 해결하는 방법은 무엇입니까?

tag-icon • tag-icon nfs autofs
호스트 검색과 관련된 autofs 설치 지연을 해결하는 방법은 무엇입니까?

저는 autofs를 사용하여 조직 내 다른 곳의 서비스에서 내보낸 다양한 NFS 파일 시스템을 자동으로 마운트하는 CentOS 6 및 CentOS 7 클라이언트 시스템의 인프라를 보유하고 있습니다. 최근 클라이언트는 이러한 파일 시스템의 자동 마운트가 매우 느려지는 문제가 있는 동작을 보이기 시작했습니다. 이전에는 몇 초밖에 걸리지 않았던 마운트가 이제 거의 2분 정도 걸리기 시작합니다.

나는 문제를 다양한 요인으로 분류했다고 생각합니다.

  • 서버의 호스트 이름에는 다양한 해상도가 있습니다(32).
  • 호스트 이름에 대한 해결 방법이 여러 개인 경우 autofs는 각 해결 방법을 감지하고 응답하지 않는 해결 방법을 거부한 다음 나머지 해결 방법 중에서 현재 응답 시간이 가장 좋은 해결 방법을 선택합니다.
  • autofs가 각 서버에 발행한 두 개의 프로브 RPC 중 하나가 계속 시간 초과되는 것 같습니다.모두내 서버.

다음은 디버그 로그에서 발췌한 대표적인 내용입니다.

Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 6 version 0x20
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: nfs v3 rpc ping time: 0.000290
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: host nfs.my.org cost 289 weight 0
Jul 13 15:48:18 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.68) proto 17 version 0x20
Jul 13 15:48:21 myclient automount[17485]: get_nfs_info: called with host nfs.my.org(10.220.8.84) proto 6 version 0x20

이는 완전한 프로브와 3초 후 다음 프로브의 시작을 보여줍니다. 지연 외에 두 번째 RPC 응답에 대해서는 아무것도 표시되지 않습니다. 이것은 나에게 "시간 초과"입니다. 시간 초과 자체는 3초에 불과하지만 이를 32개의 머신으로 곱하면 실제로 마운트를 시도하기 전에 1분 30초 이상의 시간 초과가 필요하다는 의미입니다.

클라이언트는 CentOS 6 및 7용 표준 NFS 클라이언트 스택(nfs-utils 1.2.3 및 autofs 5.0.5 또는 nfs-utils 1.3.0 및 autofs 5.0.7)을 실행하며 각각 CentOS에서 패키지됩니다. 클라이언트가 구성 관리를 받고 있으므로 문제가 시작되기 전부터 소프트웨어나 구성을 변경한 적이 없을 것입니다.

서버가 Ganesha 사용자 공간 NFS 스택을 실행하고 있다는 사실, 특히 NFS4를 지원하지 않는다는 사실은 과거에는 문제가 되지 않았지만 이와 관련이 있을 수 있습니다. 서버 관리에서는 의도적인 구성 변경이 이루어지지 않았지만 정기적인 소프트웨어 업데이트가 설치되도록 허용했다고 주장합니다.

따라서 결국 질문은 제목에서 알 수 있듯이 호스트 프로빙으로 인한 마운트 지연을 해결하는 방법입니다. Ganesha에 기본값이 변경되었을 수 있는 관련 구성 설정이 있습니까? 또는 실패한 RPC 시도를 방지하기 위해 autofs를 구성하는 방법이 있습니까? 아니면 제가 문제를 잘못 인식한 것일까요?

autofs 구성 매개변수를 켜면 use_hostname_for_mounts문제가 해결되는 것 같지만, 내가 이해한 바에 따르면 이는 개별 서버 오류 및 과부하에 대한 복원력을 잃는 대가를 치르게 됩니다. 더 좋은 방법은 없을까요?

답변1

로그 메시지의 핵심 단서는 "proto 6"으로 기록된 프로브는 성공한 반면, "proto 17"로 기록된 프로브는 실패했다는 것입니다. 6과 17은 각각 TCP와 UDP를 나타내는 IP 전송 프로토콜 번호입니다.

NFS는 전통적으로 UDP를 통해 제공되었지만 대부분의 스택은 TCP를 통한 서비스를 지원하며 이 예의 서버는 항상 TCP를 통해서만 NFS를 제공하도록 구성됩니다. 그러나 서버에 대한 아직 특성화되지 않은 변경으로 인해 nfs/udp 트래픽이 적절한 ICMP 응답으로 거부되는 대신 자동으로 삭제되기 전까지는 문제가 발생하지 않았습니다. 이는 방화벽 변경으로 인해 발생할 가능성이 높지만 현재로서는 서버의 애플리케이션 수준 변경을 배제할 수 없습니다.

어쨌든, proto=tcpautofs 맵 파일에 영향을 받은 각 파일 시스템에 대한 마운트 옵션을 추가하여 클라이언트 측의 문제를 해결했습니다. 이 옵션이 적용되면 Autofs는 UDP 스타일 검색을 중단할 만큼 똑똑해집니다. 문제가 해결되었을 뿐만 아니라, 이제 타임아웃 문제가 발생하기 전보다 마운트 성능도 좋아진 것 같습니다.

관련 정보