EFS 파일 시스템을 탑재할 때 “nfs: 서버 127.0.0.1이 응답하지 않음” 오류를 해결하려면 어떻게 해야 합니까?

간략한 설명

서버가 응답하지 않음 오류가 표시되는 일반적인 이유는 다음과 같습니다.

• NFS 클라이언트가 EFS 서버에 연결할 수 없습니다.
• 인스턴스가 재부팅되거나 종료되었습니다. 또는, EC2 인스턴스와의 다른 연결 끊김이 발생했습니다. 이러한 경우 NFS 클라이언트와 EFS 서버 간의 네트워크 연결이 끊깁니다. 이 동작은 TCP RFC를 준수하지 않습니다. 연결이 끊기면 Amazon EFS에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 또는 NFS 클라이언트에 대한 응답이 몇 분 동안 차단될 수 있습니다.
• NFS 클라이언트를 사용하여 파일 시스템을 탑재할 때는 noresvport 탑재 옵션이 사용되지 않았습니다.
• 커널 버전에 문제가 있어 EFS 탑재 실패가 발생할 수 있습니다. 예를 들어, 응답하지 않는 파일 시스템과 유사한 증상을 유발하는 RHEL6 관련 알려진 NFS 클라이언트 문제가 많이 있습니다. 이전 커널 버전의 RHEL6.X에서는 파일 시스템을 사용할 수 없게 되어 다시 탑재하지 못할 수 있습니다. 다음을 실행하는 경우 Amazon EFS에서 NFS 연결이 중단될 수 있습니다.

• RHEL 또는 CentOS 7.6 이상(커널 버전 3.10.0-957).
• 커널 버전 4.16부터 4.19까지의 다른 모든 Linux 배포판.

해결 방법

1.    파일 시스템을 탑재할 때 noresvport 탑재 옵션을 사용합니다. 이 옵션은 네트워크 연결을 다시 설정해야 할 때 NFS 클라이언트가 새 TCP 소스 포트를 사용하도록 합니다. noresvport를 사용하면 네트워크 복구 이벤트 후 EFS 파일 시스템을 중단 없이 사용할 수 있습니다.

$   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

EFS 탑재 도우미를 사용하는 경우 noresvport 옵션이 기본적으로 제공됩니다. NFS를 사용하여 탑재하는 경우 이 파라미터를 명시적으로 추가해야 합니다. 자세한 내용은 권장 NFS 탑재 옵션 단원을 참조하세요.

2.    커널 버전을 확인합니다. RHEL 또는 CentOS 7.6 이상(커널 버전 3.10.0-957)과 같은 특정 커널 버전에 파일 시스템 탑재 실패의 원인이 될 수 있는 문제가 있을 수 있습니다. 이러한 커널 버전 중 하나를 실행 중인 경우 재부팅하여 파일 시스템에 대한 액세스를 복구합니다. 커널 버전이 문제인지 확인하려면 ls를 실행할 수 없을 때 ps 명령의 출력을 확인하십시오.

$ ps auxwwwm | grep <mount_point_IP>

커널 버전에 결함이 있으면 커널을 업그레이드합니다. 성능 향상을 위해 현재 세대의 Linux NFS4v.1 클라이언트 이상을 사용하는 것이 좋습니다.

3.    다음 명령을 실행하여 클라이언트가 서버에 연결할 수 있는지 확인합니다.

telnet <ip-of-efs> 2049

/var/log/messages 아래의 NFS 클라이언트 로그(EC2 인스턴스 OS 로그)에서 오류를 검토합니다. 로그는 OS에 따라 /var/log/syslog 또는 /var/log/dmesg 디렉터리 아래에 있을 수 있습니다.

또한 EFS 탑재 도우미를 사용하여 파일 시스템을 탑재한 경우 /var/log/amazon/efs 디렉터리 아래의 EFS 유틸리티 로그를 검토합니다. EFS 탑재 도우미에는 로깅 메커니즘이 내장되어 있습니다.

4.    EC2 인스턴스에 연결할 수 있는지 확인합니다.

5.    리소스 과다 사용률로 인해 EC2가 오버로드되고 있는지 확인합니다. CPUUtilization 및 네트워크 관련 지표와 같은 Amazon CloudWatch의 EC2 지표를 모니터링하여 이를 수행할 수 있습니다. 리소스에는 CPU, 메모리, 애플리케이션 수준 문제 등이 포함될 수 있습니다.

• 메모리 과다 사용률: RAM이 과도하게 사용될 때 발생할 수 있습니다. 과다 사용률은 예를 들어 애플리케이션이 더 많은 RAM을 사용하기 시작하는 경우 인스턴스의 메모리 공간이 부족하다는 것을 의미합니다. 과도하게 사용하면메모리 부족(OOM) 오류가 발생합니다. 이러한 오류가 시작되면 OOM 점수가 높거나 더 많은 메모리를 사용하는 프로세스가 종료됩니다. OOM 오류가 시작되면 인스턴스에 액세스할 수 없는 상태로 유지하는 것이 이상적입니다.
  일시적으로 OOM 오류를 해결하려면 시스템을 재부팅하여 메모리 공간을 확보하십시오.
  장기적인 솔루션의 경우 “atop” 및 “top”과 같은 도구를 사용하여 시스템 리소스 사용량을 모니터링하십시오. 그런 다음 워크로드에 더 적합한 다른 인스턴스 유형으로 이동합니다. 자세한 내용은 리소스의 과도한 사용률로 인해 EC2 Linux 인스턴스가 응답하지 않는 이유는 무엇입니까?를 참조하세요.
• 네트워크 성능: 인스턴스의 네트워크 성능을 검토합니다. 경우에 따라 CloudWatch 지표의 네트워크 사용률이 낮더라도 마이크로버스트가 발생할 수 있습니다. 마이크로버스트는 몇 초 내에 워크로드에서 많은 양의 트래픽을 전송합니다. 마이크로버스트는 일반적으로 1분 미만 동안 지속됩니다. 이러한 도구 내에서 사용되는 최소 간격이 1분이므로 CloudWatch 그래프 및 Amazon Elastic Block Store(Amazon EBS) 통계에서 이러한 버스트가 가려집니다. sar, nload, iftop과 같은 도구를 사용하여 마이크로버스트 동작을 모니터링합니다. 자세한 내용은 평균 사용률이 낮을 때 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 네트워크 제한을 초과하는 이유는 무엇입니까?를 참조하세요.

6.    EFS CloudWatch 지표를 검토하고 제한이 EFS 수준에서 발생하는지 확인합니다. 이는 EFS가 용량 이상으로 성능을 발휘하고 있음을 의미합니다. 버스팅 처리량 모드를 사용하는 경우 BurstBalance CloudWatch 지표를 검토하여 버스트 밸런스가 고갈되었는지 확인합니다. 또한 허용된 처리량 CloudWatch 지표를 검토하여 프로비저닝된 양보다 높은 처리량을 사용하고 있는지 확인합니다. 버스트 크레딧에 대한 자세한 내용은 Amazon EFS 버스트 크레딧은 어떻게 작동합니까?를 참조하세요.

애플리케이션에 거의 연속적인 처리량이 필요한 경우 프로비저닝된 처리량 모드를 사용합니다. 버스팅 처리량에서 프로비저닝된 처리량 모드로 전환하기 전에, 프로비저닝할 처리량을 고려하십시오. 필요한 프로비저닝된 처리량의 최소 양을 결정하려면 지난 2주 동안의 파일 시스템의 평균 처리량 사용량을 확인합니다. 최대 피크 양을 다음 MB로 반올림합니다. 자세한 내용은 EFS에서 사용할 수 있는 처리량 모드는 무엇이며, 워크로드에 적합한 처리량 모드는 무엇입니까?를 참조하세요.

---

관련 정보

탑재 문제 해결

Amazon EFS 문제 해결