EC2 Linux 인스턴스의 상태 확인 실패 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

Amazon EC2는 세 가지 상태 확인을 사용하여 EC2 인스턴스의 상태를 모니터링합니다.

시스템 상태 확인

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

인스턴스 상태 확인

인스턴스에 연결할 수 없는 경우 인스턴스 상태 확인이 실패합니다. 인스턴스 상태 확인은 다음과 같은 이유로 실패할 수 있습니다.

• 운영 체제(OS) 부팅 실패
• Amazon Elastic Block Store(Amazon EBS) 볼륨이 제대로 마운트되지 않음
• CPU와 메모리가 소진됨
• 커널 패닉
• 네트워크 장애
• 루트 EBS 볼륨 파라미터의 스로틀링

연결된 EBS 상태 확인

연결된 EBS 상태 확인은 인스턴스에 연결된 EBS 볼륨에 도달할 수 있고 I/O 작업을 완료할 수 있는지 여부를 모니터링합니다. 자세한 내용은 연결된 EBS 상태 확인을 참조하십시오.

해결 방법

인스턴스 상태 확인 또는 시스템 상태 확인의 실패 여부를 확인하려면 인스턴스의 상태 확인 지표를 참조하십시오.

시스템 상태 확인에 실패한 경우, EC2 Linux 인스턴스가 시스템 상태 확인에 실패한 이유는 무엇입니까?를 참조하십시오.

인스턴스 상태 확인에 실패한 경우, 인스턴스의 시스템 로그를 확인하여 실패 원인을 파악합니다. 그 후 다음 해결 옵션 중 하나를 선택하여 문제를 해결하십시오.

중요: 다음 해결 방법 중 일부는 인스턴스를 중지했다가 시작해야 합니다. 인스턴스를 중지하면 인스턴스 저장소 볼륨의 데이터가 손실됩니다. 인스턴스에 EBS 지원 볼륨이 없는 경우 인스턴스를 중지하기 전에 데이터를 백업하십시오. 또한 인스턴스를 중지하고 시작한 후 인스턴스의 퍼블릭 IPv4 주소가 변경될 수 있습니다. 동일한 퍼블릭 IPv4 주소를 유지하려면 탄력적 IP 주소를 사용하십시오. 자세한 내용은 Amazon EC2 인스턴스 중지 및 시작을 참조하십시오.

OS 부팅 실패

시스템 로그에 부팅 오류가 포함되어 있으면, 운영 체제 문제로 인해 인스턴스 상태 확인에 실패한 EC2 Linux 인스턴스의 문제를 해결하려면 어떻게 해야 합니까?를 참조하하십시오.

EBS 볼륨이 제대로 마운트되지 않음

마운트 지점 실패로 인해 인스턴스 상태 확인이 실패할 수 있습니다.

마운트 지점 실패 출력 예시:

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

이러한 오류에 대한 자세한 내용은 EC2 Linux 인스턴스를 부팅하려고 할 때 비상 모드로 전환되는 이유는 무엇입니까?를 참조하십시오. 또한 운영 체제 문제로 인해 인스턴스 상태 확인에 실패한 EC2 Linux 인스턴스의 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

인스턴스 유형을 Xen에서 Nitro 기반 인스턴스로 변경하면 볼륨 마운트가 실패할 수 있습니다. 마운트 실패는 Nitro 기반 인스턴스에서 EBS 볼륨이 NVMe 블록 디바이스로 노출되어 있기 때문에 발생합니다. 예를 들어 디바이스 이름은 /dev/nvme0n1과 /dev/nvme1n1입니다. 블록 디바이스 매핑에서 지정한 디바이스 이름은 NVMe 디바이스 이름으로 변경됩니다. 예를 들어 /dev/nvme[0-26]n1입니다.

참고: 블록 디바이스 드라이버는 사용자가 블록 디바이스 매핑에 지정한 순서와 다른 순서로 NVMe 디바이스 이름을 할당할 수 있습니다. Nitro 기반 인스턴스에서 마운트 실패를 방지하려면 디바이스 이름에 레이블 또는 UUID를 사용하는 것이 가장 좋습니다. 자세한 내용은 Amazon EBS 볼륨을 사용하도록 설정을 참조하십시오.

CPU와 메모리가 소진됨

높은 CPU 사용률

CPUUtilization 지표가 100%이거나 이에 근접한 경우 인스턴스에 커널을 실행하기에 충분한 컴퓨팅 용량이 없는 것입니다.

T2 또는 T3 인스턴스의 경우 Amazon CloudWatch CPU 크레딧 지표를 확인하여 CPU 크레딧이 0이거나 거의 0에 가까운지 확인합니다. CPU 크레딧이 0인 경우 CPUUtilization 지표는 인스턴스의 기준 성능에서 포화 정체 상태를 나타냅니다. 예를 들어 기준 성능은 20% 또는 40%일 수 있습니다. CPU 사용률이 100%이거나 이에 가까운 경우 또는 T2나 T3 인스턴스가 포화 정체 상태에 도달한 경우, 리소스 과다 사용률로 인해 상태 확인이 실패한 것으로 표시됩니다.

이 문제를 해결하려면 리소스 과다 사용으로 인해 상태 확인에 실패하는 EC2 Linux 인스턴스 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

블록 디바이스 오류, 소프트웨어 버그 또는 커널 패닉으로 인해 비정상적인 CPU 사용량 급증이 발생할 수 있습니다. CPU 사용률이 100%인 경우, 시스템 로그에서 블록 디바이스 또는 메모리 문제 오류나 기타 비정상적인 시스템 오류가 있는지 확인하십시오. 그런 다음, 인스턴스를 재부팅하거나 중지했다가 시작하십시오.

메모리 부족

메모리 압력이 높으면 인스턴스 상태 확인에 실패할 수 있습니다. 다음 예제 로그 추출에서는 OS의 메모리가 부족하여 OOM-killer가 시작됩니다. 이 오류를 해결하려면 메모리를 가장 많이 사용하는 프로세스를 중지합니다.

[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 에이전트를 사용하여 지표, 로그 및 추적 수집을 참조하십시오.

메모리 부족 문제를 해결하려면 더 큰 인스턴스 유형으로 인스턴스를 업그레이드합니다. 또는 인스턴스에 스왑 스토리지를 추가하여 메모리 압력을 완화하십시오. 자세한 내용은 Amazon EC2 인스턴스에서 스왑 파일로 사용할 메모리를 할당하려면 어떻게 해야 합니까?를 참조하십시오. 또한 하드 드라이브의 파티션을 사용하여 Amazon EC2 인스턴스에서 스왑 공간으로 사용할 메모리를 할당하려면 어떻게 합니까?를 참조하십시오.

디스크 가득 참 오류

시스템 로그에 디스크 가득 참 오류가 있으면 루트 디바이스가 가득 차서 인스턴스가 비상 모드에 있는 것입니다.

시스템 로그 예시:

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

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.serviceError: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

자세한 내용은 리소스 과다 사용으로 인해 상태 확인에 실패하는 EC2 Linux 인스턴스 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오. 또한 파일 시스템에 남은 공간이 없다는 오류가 표시되는 경우, EBS 볼륨의 크기를 늘리려면 어떻게 해야 합니까?를 참조하십시오.

커널 패닉

커널 패닉은 커널이 작동 중에 치명적인 내부 오류를 감지하면 발생합니다. 커널이 제대로 로드되지 않으면 OS 부팅 중에 오류가 발생합니다. 커널 로드 실패로 인해 인스턴스 부팅이 실패합니다.

커널 패닉 오류 출력 예시:

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)

자세한 내용은 EC2 인스턴스의 ‘Kernel panic - not syncing’ 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오. 또한 업데이트로 인해 EC2 인스턴스 재부팅이 차단된 후 알려진 안정적인 커널로 되돌리려면 어떻게 해야 합니까?를 참조하십시오.

네트워크 장애

다음과 같은 이유로 네트워크에 장애가 발생할 수 있습니다.

• cloud-init 패키지가 인스턴스에 설치되지 않았습니다.
• cloud-init 패키지는 시작 시 네트워크 구성을 업데이트하는 데 사용됩니다.

이 오류를 해결하고 인스턴스에 cloud-init 패키지를 설치하려면 터미널에서 다음 명령을 실행하십시오.

Amazon, Amazon Linux 2, Amazon Linux 2023 또는 RedHat OS:

sudo yum install cloud-init -y

Ubuntu 또는 Debian OS:

sudo apt install cloud-init -y

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 주소로 인해 발생하는 네트워크 문제를 해결하려면 해당 항목 또는 구성 파일을 제거한 후 다음 명령을 실행합니다.

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

구성 파일을 이동한 후 네트워크 서비스를 다시 시작하여 새 MAC 주소를 받는지 확인합니다.

IP 주소가 네트워크 구성 파일에 하드코딩되어 있음

정적으로 구성된 IP 주소가 있는 인스턴스에서 Amazon Machine Image(AMI)를 생성하는 경우, 구성 파일에 하드코딩된 IP 주소가 포함됩니다. 이 오류를 수정하려면 DHCP를 사용하도록 네트워크 인터페이스를 설정하십시오.

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

ENA 또는 Intel 지원 네트워크 드라이버가 누락됨

누락된 Elastic Network Adapter(ENA) 또는 Intel 지원 네트워크 드라이버에 대한 자세한 내용은 Amazon EC2 인스턴스의 향상된 네트워킹을 참조하십시오.

스타트업 시 네트워크 인터페이스의 이름이 자동으로 변경됨

예측 가능한 네트워크 인터페이스 이름 변경을 비활성화하려면 커널 명령줄에 net.ifnames=0을 추가합니다. 자리 표시자를 사용하려면 ENA를 사용하여 향상된 네트워킹을 활성화하고 grub 구성 파일을 다시 빌드하거나 업데이트해야 합니다.

루트 EBS 볼륨 파라미터의 스로틀링

루트 EBS 볼륨 파라미터에 병목 현상이 발생하면 인스턴스에 연결할 수 없고 응답하지 못하므로 인스턴스의 상태 확인에 실패할 수 있습니다.

스로틀링은 EBS 볼륨의 IOPS(초당 I/O 작업 수) 또는 처리량이 이미 프로비저닝된 한도를 초과할 때 발생할 수 있습니다. EBS 볼륨 스로틀링에 따른 성능 저하로 인해 인스턴스가 응답하지 않거나 연결이 불가능할 수 있습니다.

EBS 볼륨 스로틀링 문제를 해결하려면 다음 단계를 완료하십시오.

1. 볼륨 대기열 길이, 볼륨 읽기/쓰기 작업, 볼륨 읽기/쓰기 바이트와 같은 CloudWatch 지표를 모니터링하고 분석합니다. 자세한 내용은 CloudWatch 지표를 사용하여 EBS 볼륨이 제공하는 평균 처리량과 평균 IOPS 수를 계산하려면 어떻게 해야 합니까?를 참조하십시오.
2. 인스턴스를 중지하고 시작하거나 인스턴스를 재부팅하여 문제를 일시적으로 해결합니다.
3. EBS 볼륨의 더 많은 IOPS 또는 처리량을 프로비저닝합니다. 또는 워크로드에 더 적합한 EBS 볼륨 유형 및 크기로 업그레이드합니다. 자세한 내용은 Amazon EBS 볼륨 수정 요청을 참조하십시오.

관련 정보

상태 확인에 실패한 Amazon EC2 Linux 인스턴스 문제 해결

시스템 상태 확인 실패 또는 상태 확인 0/2로 인해 EC2 Windows 인스턴스가 다운되는 이유는 무엇입니까?

왜 인스턴스 상태 확인에 실패하여 내 EC2 Windows 인스턴스가 중단되었습니까?

상태 확인 유형