EC2 Linux 인스턴스에 연결할 수 없고 상태 확인 중 하나 또는 둘 다에 실패하는 이유는 무엇입니까?

최종 업데이트 날짜: 2022년 9월 7일

Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스에 연결할 수 없어 상태 확인 중 하나 또는 둘 다에 실패합니다.

간략한 설명

Amazon EC2는 두 가지 상태 확인을 통해 각 EC2 인스턴스 상태를 모니터링합니다.

시스템 상태 확인

시스템 상태 확인은 인스턴스가 실행되는 기본 호스트에서의 문제를 탐지합니다. 네트워크, 하드웨어 또는 소프트웨어 문제로 인해 기본 호스트가 응답하지 않거나 이에 연결할 수 없는 경우 이 상태 확인에 실패합니다.

인스턴스 상태 확인

인스턴스 상태 확인 실패는 인스턴스의 연결 가능성에 문제가 있음을 나타냅니다. 이 문제는 다음과 같은 운영 체제 수준 오류로 인해 발생합니다.

  • 운영 체제 부팅 실패
  • 올바른 볼륨 탑재 실패
  • CPU 및 메모리 소진
  • 커널 패닉
  • 네트워크가 작동하지 않음

경고: 다음 해결 방법 중 일부에서는 인스턴스를 중지하고 시작해야 합니다. 인스턴스를 중지하고 시작하기 전에 다음 조건을 확인합니다.

  • 인스턴스를 중지하면 인스턴스 스토어 데이터가 손실됩니다. 사용하는 인스턴스가 인스턴스 스토어 지원 인스턴스이거나 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스를 중지할 때 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
  • 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인 경우 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 인스턴스를 시작한 경우 인스턴스가 AWS Auto Scaling 그룹의 일부일 수 있습니다. 이 시나리오에서 인스턴스 종료는 오토 스케일링 그룹에 대한 인스턴스 확장 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스를 제거합니다.
  • 인스턴스를 중지하고 시작하면 퍼블릭 IP 주소가 AWS 동적 IP 풀에 다시 릴리스됩니다. 외부 트래픽을 인스턴스로 라우팅할 때는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 좋습니다. Amazon Route 53를 사용하는 경우 퍼블릭 IP가 변경될 때 Route 53 DNS 레코드를 업데이트해야 할 수 있습니다.

자세한 내용은 인스턴스 중지 및 시작을 참조하세요.

해결 방법

1.    인스턴스 상태 확인 지표를 확인하여 인스턴스 상태 확인 또는 시스템 상태 확인이 실패했는지 확인합니다.

2.    시스템 상태 확인에 실패한 경우 EC2 Linux 인스턴스에서 시스템 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

인스턴스 상태 확인이 실패하면 인스턴스의 시스템 로그를 확인하여 실패의 원인을 확인합니다. 시스템 로그에 있는 데이터에 따라 다음 해결 방법 중 하나를 사용합니다.

운영 체제 부팅 실패

올바른 볼륨 탑재 실패

이 예시와 같이 올바르게 탑재할 수 없는 탑재 지점으로 인해 인스턴스 상태 확인이 실패할 수 있습니다.

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

CPU 및 메모리 소진

높은 CPU 사용률

CPUUtilization 지표가 100%이거나 이에 가까운 경우, 인스턴스에 커널을 실행하기에 충분한 컴퓨팅 파워가 없는 것일 수 있습니다.

T2 또는 T3 인스턴스의 경우 Amazon CloudWatch 지표 표에서 CPU 크레딧 지표를 확인하여 CPU 크레딧이 0이거나 0에 가까운지 확인합니다. CPU 크레딧이 0인 경우 CPUUtilization 지표에서 포화도 상태가 인스턴스의 기준 성능으로 표시됩니다. 기준 성능은 인스턴스 유형에 따라 20%, 40% 등이 될 수 있습니다.

CloudWatch 지표에서 CPU 사용률이 100% 또는 거의 100%로 표시되거나 T2 또는 T3 인스턴스의 포화도 상태로 표시되는 경우 인스턴스 리소스의 과다 사용으로 인해 상태 확인이 실패한 것을 나타냅니다. 이 문제를 해결하는 방법에 대한 지침은 EC2 Linux 인스턴스가 리소스 과다 사용으로 인해 인스턴스 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

블록 디바이스 오류, 소프트웨어 버그 또는 커널 패닉으로 인해 비정상적인 CPU 사용량 스파이크가 발생할 수 있습니다. CPUUtilization 지표가 100%이고 시스템 로그에 블록 디바이스, 메모리 문제 또는 기타 비정상적인 시스템 오류와 관련된 오류가 포함되어 있는 경우 인스턴스를 재부팅하거나 중지하고 인스턴스를 시작합니다.

메모리 부족

메모리 압력이 높으면 인스턴스 상태 확인에 실패할 수 있습니다. 이 예시에서는 운영 체제의 메모리가 부족하여 대부분의 메모리를 소비하는 프로세스를 중지합니다.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

EC2 메모리 및 디스크 지표는 기본적으로 CloudWatch로 전송되지 않습니다. 하지만 CloudWatch 에이전트를 사용하여 모니터링하기 위해 CloudWatch에 추가 지표를 전송할 수 있습니다.

메모리 부족 문제를 해결하려면 인스턴스를 더 큰 인스턴스 유형으로 업그레이드하는 것이 좋습니다. 또는 인스턴스에 스왑 스토리지를 추가하여 메모리 부담을 완화합니다. 자세한 내용은 다음 주제를 참조하세요.

디스크 가득 참 오류

시스템 로그에 디스크 가득 참 오류가 포함되어 있는 경우 루트 디바이스가 가득 찼기 때문에 인스턴스가 비상 모드로 전환되었을 수 있습니다.

$: service apache2 restart
Error: No space left on device

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device
        
        
root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

커널 패닉

작동 중에 커널이 치명적인 내부 오류를 감지하면 커널 패닉 오류가 발생합니다. 운영 체제 부팅 중에 오류가 발생하면 커널을 제대로 읽어들이지 못할 수 있습니다. 이로 인해 운영 체제 부팅 오류가 발생할 수 있습니다. 다음은 커널 패닉 오류 메시지의 예입니다.

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

네트워크가 작동하지 않음

다음과 같은 이유로 네트워크가 작동하지 않을 수 있습니다.

'cloud-init' 패키지 누락

인스턴스에 cloud-init 패키지가 누락된 경우 네트워크가 작동하지 않을 수 있습니다. cloud-init 패키지는 시작 시 네트워크 구성을 업데이트하는 데 유용합니다.

이 오류를 해결하려면 인스턴스에 cloud-init 패키지를 설치합니다.

$ sudo yum install cloud-init

MAC 주소가 구성 파일에 하드코딩됨

MAC 주소가 구성 파일에 하드코딩된 경우 네트워크가 작동하지 않는 문제가 발생할 수 있습니다.

하드코딩된 MAC 주소는 Linux 구성 파일 및 'udev' 구성 파일(예: 다음 위치)에서 찾을 수 있습니다.

  • /etc/udev/rules.d/
  • /etc/udev/rules.d/70-persistent-net.rules
  • /etc/udev/rules.d/80-net-name-slot.rules

인스턴스에서 MAC 주소가 하드코딩될 때 네트워크 문제를 해결하려면 항목 또는 구성 파일을 제거해야 합니다. 예를 들어 다음과 같습니다.

mv /etc/udev/rules.d/70-persistent-net.rules/root/

IP 주소가 구성 파일에 하드코딩됨

IP 주소가 구성 파일에 하드코딩되어 있으면 네트워크가 작동하지 않는 문제가 발생할 수 있습니다. 이 문제는 정적으로 구성된 IP 주소를 가진 인스턴스에서 Amazon Machine Image(AMI)를 가져올 때 발생합니다.

이 오류를 해결하려면 네트워크 인터페이스에서 DHCP를 사용하도록 설정합니다.

참고: 기존 AMI는 업데이트할 수 없습니다. 새 AMI를 생성하기 전에 인스턴스에서 DHCP를 사용하도록 네트워크 인터페이스를 설정해야 합니다.

ENA 또는 인텔 향상된 네트워크 드라이버 누락

인스턴스에 ENA(탄력적 네트워크 어댑터) 또는 인텔 향상된 네트워크 드라이버가 없으면 네트워크가 작동하지 않을 수 있습니다.

자세한 내용은 Linux에서의 향상된 네트워킹을 참조하세요.

시작 시 네트워크 인터페이스 이름이 변경됨

인스턴스 시작 시 네트워크 인터페이스 이름을 변경하면 네트워크 문제가 발생할 수 있습니다. 이 오류를 해결하려면 커널 명령줄에 net.ifnames=0을 추가하여 예측 가능한 네트워크 인터페이스 이름을 비활성화합니다. 이렇게 하려면 ENA가 있는 향상된 네트워킹을 활성화해야 합니다.

네트워크 문제에 대한 자세한 내용은 네트워크 인터페이스 구성에 대한 모범 사례를 참조하세요.