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

7분 분량

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

간략한 설명

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

시스템 상태 확인

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

인스턴스 상태 확인

인스턴스 상태 확인 실패는 인스턴스에 연결할 수 없음을 나타냅니다. 다음과 같은 일반적인 문제로 인해 인스턴스 상태 확인이 실패합니다:

운영 체제(OS)를 부팅하지 못함
볼륨을 올바르게 마운트하지 못함
CPU 및 메모리 소진
커널 패닉
네트워크 장애

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

인스턴스가 중지되면 인스턴스 스토어 볼륨에 저장된 데이터가 손실됩니다. 인스턴스를 중지하기 전에 데이터를 백업해야 합니다. Amazon Elastic Block Store(Amazon EBS) 지원 볼륨과 달리, 인스턴스 스토어 볼륨은 임시적이며 데이터 지속성을 지원하지 않습니다.
Amazon EC2가 시작 또는 시작 시 인스턴스에 자동으로 할당하는 정적 퍼블릭 IPv4 주소는 중지 및 시작 후에 변경됩니다. 인스턴스가 중지될 때 변경되지 않는 퍼블릭 IPv4 주소를 유지하려면 Elastic IP 주소를 사용하세요.

자세한 내용은 인스턴스 중지를 위한 전제 조건을 참조하세요.

해결 방법

인스턴스 상태 확인 또는 시스템 상태 확인이 실패했는지 확인하려면 인스턴스의 상태 확인 지표를 확인하세요.

시스템 상태 확인에 실패한 경우, 내 EC2 Linux 인스턴스가 시스템 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 하나요?

인스턴스 상태 확인에 실패한 경우, 인스턴스의 시스템 로그를 확인하여 실패의 원인을 파악합니다. 그런 다음, 다음 해결 방법 중 하나를 사용하여 문제를 해결합니다.

OS 부팅 실패

시스템 로그에 부팅 오류가 포함되어 있으면, 운영 체제 문제로 인해 인스턴스 상태 확인에 실패한 EC2 Linux 인스턴스 문제 해결 방법을 참조하세요.

볼륨을 올바르게 마운트하지 못함

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

마운트 지점 실패 예시:

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

자세한 내용은 다음 AWS 지식 센터 문서를 참조하세요:

"종속성 실패" 오류: EC2 Linux 인스턴스를 부팅하려고 할 때, 비상 모드로 전환되는 이유는 무엇인가요?
"마운트하지 못했습니다" 또는 "종속성 실패" 오류: 운영 체제 문제로 인해 인스턴스 상태 확인에 실패한 EC2 Linux 인스턴스의 문제를 해결하려면 어떻게 해야 하나요?

인스턴스 유형을 Xen에서 Nitro로 변경하면 볼륨 탑재가 실패할 수 있습니다. 마운트 실패가 발생한 이유는 Amazon EBS 볼륨이 Nitro 기반 인스턴스에서 NVMe 블록 디바이스로 노출되어 있기 때문입니다. 장치 이름은 /dev/nvme0n1, /dev/nvme1n1와 같은 유형입니다. 블록 디바이스 매핑에서 지정한 디바이스 이름은 NVMe 디바이스 이름(/dev/nvme[0-26]n1)으로 변경됩니다. 블록 디바이스 드라이버는 사용자가 블록 디바이스 매핑에 지정한 원래 순서와 다른 순서로 NVMe 디바이스 이름을 할당할 수 있습니다. Nitro 기반 인스턴스에서 마운트 실패를 방지하려면, 장치 이름에 레이블 또는 UUID를 사용하는 것이 가장 좋습니다. 자세한 내용은 Linux에서 사용할 수 있는 Amazon EBS 볼륨 만들기를 참조하세요.

CPU 및 메모리 소진

높은 CPU 사용률

CPU사용률 지표가 100%이거나 이에 근접한 경우, 인스턴스에 커널을 실행하기에 충분한 컴퓨팅 용량이 없을 수 있습니다.

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

CPU 사용률이 100% 또는 거의 100%이거나 T2 또는 T3 인스턴스의 포화 정점에 도달하면, 리소스 초과 사용률로 인해 상태 확인에 실패했음을 나타냅니다. 이 문제를 해결하려면, “리소스 과다 사용으로 인해 EC2 Linux 인스턴스가 인스턴스 상태 확인에 실패했습니다” 섹션을 참조하세요. 이 문제를 해결하려면 어떻게 해야 하나요?

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

메모리 부족

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

[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 인스턴스 메모리 및 디스크 지표는 Amazon CloudWatch로 전송되지 않습니다. 그러나 CloudWatch 에이전트를 사용하여 추가 지표를 수집하고 모니터링할 수 있습니다.

메모리 부족 문제를 해결 및 개선하려면, 더 큰 인스턴스 유형으로 인스턴스를 업그레이드합니다. 또는 인스턴스에 스왑 스토리지를 추가하여 메모리 압박을 완화하세요. 자세한 내용은 다음 AWS 지식 센터 문서를 참조하세요:

디스크 용량 부족 오류

시스템 로그에 디스크 용량 부족 오류가 포함되어 있으면, 루트 디바이스 용량이 가득 차서 인스턴스가 비상 모드에 있는 것입니다.

시스템 로그 예시:

$: 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% /

디스크 용량 부족 오류의 문제를 해결하고 해결하는 방법에 대한 자세한 지침은 다음 AWS 지식 센터 문서를 참조하세요:

커널 패닉

커널 패닉은 커널이 작동 중에 내부 치명적인 오류를 감지할 때 발생합니다. OS 부팅 중에 오류가 발생하면 커널이 제대로 로드되지 않을 수 있습니다. 이로 인해 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)

커널 패닉 오류의 문제를 해결하고 해결하는 방법에 대한 자세한 내용은 다음 AWS 지식 센터 문서를 참조하세요:

네트워크 장애

다음과 같은 일반적인 이유로 인해 네트워크가 실패할 수 있습니다.

클라우드 초기화 패키지가 인스턴스에 설치되지 않았습니다.

cloud-init 패키지는 시작할 때 네트워크 구성을 업데이트하는 데 사용됩니다.

이 오류를 해결하려면, 다음 명령을 실행하여 인스턴스에 cloud-init 패키지를 설치하세요:

$ sudo yum install cloud-init

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 주소가 있는 인스턴스에서 Amazon Machine Image(AMI)를 생성하는 경우, 구성 파일에 하드코딩된 IP 주소가 포함될 수 있습니다.

이 오류를 수정하려면 네트워크 인터페이스에서 DHCP를 사용하도록 설정하세요.

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

누락된 ENA 또는 Intel 강화 네트워크 드라이버가 있습니다

누락된 Elastic Network Adapter(ENA) 또는 Intel 지원 네트워크 드라이버에 대한 자세한 내용은 Linux의 향상된 네트워킹을 참조하세요.

시작 시 네트워크 인터페이스의 이름이 변경되었습니다

이 문제를 해결하려면, 커널 명령줄에 net.ifnames=0를 추가하여 예측 가능한 네트워크 인터페이스 이름을 비활성화하세요. 이 변수를 사용하려면, ENA를 사용하여 향상된 네트워킹을 활성화해야 합니다.

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