운영 체제 문제로 인해 인스턴스 상태 확인에 실패한 EC2 Linux 인스턴스의 문제를 해결하려면 어떻게 해야 하나요?

7분 분량

Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스가 운영 체제 문제로 인해 인스턴스 상태 확인에 실패했습니다. 지금 정상적으로 부팅되지 않습니다.

간단한 설명

다음과 같은 이유로 EC2 Linux 인스턴스가 인스턴스 상태 검사에 실패할 수 있습니다.

커널을 업데이트했는데 새 커널이 부팅되지 않았습니다.
/etc/fstab의 파일 시스템 항목이 올바르지 않거나 파일 시스템이 손상되었습니다.
인스턴스의 네트워크 구성이 잘못되었습니다.

해결 방법

중요: 다음 절차 중 일부는 인스턴스를 중지해야 합니다. 인스턴스를 중지하면 인스턴스 스토어 볼륨에 저장된 데이터가 손실됩니다. 인스턴스를 중지하기 전에 데이터 백업을 저장세요. Amazon Elastic Block Store(Amazon EBS) 지원 볼륨과 달리, 인스턴스 스토어 볼륨은 임시적이며 데이터 지속성을 지원하지 않습니다. 자세한 내용을 보려면 Amazon EC2 인스턴스 중지 및 시작을 참조세요.

Amazon EC2가 인스턴스에 자동으로 할당하는 정적 퍼블릭 IPv4 주소는 중지 및 시작 후에 변경됩니다. 인스턴스가 중지될 때 변경되지 않는 퍼블릭 IPv4 주소를 유지하려면 Elastic IP 주소를 사용하세요.

참고: 다음 메서드는 Amazon Linux 2를 기반으로 하는 예제를 사용합니다. 그러나 이러한 개념은 일반적으로 Linux 배포판에 적용됩니다. Amazon Linux 2가 아닌 다른 Linux 배포판을 사용하는 경우 명령, 경로 및 출력이 다를 수 있습니다.

Linux 인스턴스용 EC2 직렬 콘솔 사용

Linux 인스턴스용 EC2 직렬 콘솔을 사용하도록 설정한 경우, 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형 및 베어 메탈 인스턴스 문제를 해결할 수 있습니다. 직렬 콘솔은 부팅 문제와 네트워크 및 SSH 구성 문제를 해결하는 데 도움이 됩니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이도 해당 인스턴스에 연결할 수 있습니다. 직렬 콘솔에 액세스하려면 Amazon EC2 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하세요.

EC2 직렬 콘솔을 처음 사용하는 경우 연결하기 전에 사전 요구 사항을 검토하고 액세스를 구성하세요.

인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 EC2Rescue for Linux 도구 실행 섹션을 참조하세요. 또는 복구 인스턴스 사용의 지침을 따르세요. Linux 인스턴스용 EC2 직렬 콘솔을 구성하려면 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우, AWS CLI 오류 문제 해결을 참조하세요. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

EC2Rescue for Linux 도구 실행

EC2Rescue for Linux는 연결할 수 없는 인스턴스에서 운영 체제를 자동으로 진단하고 문제를 해결합니다. 자세한 내용은 운영 체제 수준 문제를 해결하기 위해 EC2Rescue for Linux를 사용하려면 어떻게 합니까?를 참조하세요.

수동으로 오류를 수정하는 복구 인스턴스 사용

Virtual Private Cloud(VPC)에서 새 EC2 인스턴스를 시작합니다. 손상된 인스턴스와 동일한 Amazon Machine Image(AMI)와 가용 영역을 사용하세요. 새 인스턴스가 복구 인스턴스가 됩니다.

또는 기존 인스턴스를 사용합니다. 기존 인스턴스는 동일한 AMI를 사용해야 하며 손상된 인스턴스와 동일한 가용 영역에 있어야 합니다.
손상된 인스턴스를 중지합니다.
손상된 인스턴스에서 Amazon EBS 루트 볼륨을 분리합니다(/dev/xvda 또는 /dev/sda1). 루트 볼륨의 장치 이름을 기록해 둡니다.
볼륨을 보조 장치(/dev/sdf)로 복구 인스턴스에 연결합니다.
SSH를 통해 해당 복구 인스턴스에 연결합니다.
복구 인스턴스에 연결된 새 볼륨의 탑재 지점 디렉터리(/rescue)를 생성합니다.
```
$ sudo mkdir /rescue
```
새 디렉터리에 볼륨을 마운트합니다.
```
$ sudo mount /dev/xvdf1 /rescue
```
"Wrong Fs type or UUID duplicate, Superblock is missing or badblock found"과 같은 오류가 발생하면 Amazon EBS 볼륨을 마운트할 수 없는 이유를 참조하세요.

참고: 다른 장치 이름을 사용하여 장치(/dev/xvdf1)가 복구 인스턴스에 연결되었을 수 있습니다. 올바른 장치 이름을 확인하려면 lsblk 명령을 실행하여 마운트 지점과 함께 사용 가능한 디스크 장치를 확인합니다.
아직 수행하지 않은 경우 인스턴스의 시스템 로그를 검색하여 오류를 확인합니다. 다음 단계는 시스템 로그에 나열된 오류 메시지에 따라 달라집니다.

다음은 인스턴스 상태 확인 실패의 원인이 되는 일반적인 오류 목록입니다. 추가 오류에 대해서는 Linux 기반 인스턴스의 시스템 로그 오류 문제 해결을 참조세요.

“Kernel panic” 문제 해결

시스템 로그에 커널 패닉 오류 메시지가 있는 경우 커널에 vmlinuz 또는 initramfs 파일이 없을 수 있습니다. 성공적으로 부팅하려면 vmlinuz 및 initramfs 파일이 필요합니다.

다음 명령을 실행합니다.

cd /rescue/boot
ls -l

출력을 확인하여 부팅하려는 커널 버전에 해당하는 vmlinuz 및 initramfs 파일이 있는지 확인합니다.

다음 출력 예는 커널 버전이 4.14.165-131.185.amzn2.x86_64인 Amazon Linux 2 인스턴스에 대한 것입니다. /boot 디렉터리에는 성공적으로 부팅할 수 있도록 하는 initramfs-4.14.165-131.185.amzn2.x86_64.img 및 vmlinuz-4.14.165-131.185.amzn2.x86_64 파일이 있습니다.

uname -r
4.14.165-131.185.amzn2.x86_64

cd /boot; ls -l
total 39960
-rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
drwx------ 5 root root       79 Feb 12 04:08 grub2
-rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
-rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
-rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
-rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
-rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

initramfs 및 vmlinuz 파일이 없는 경우 두 파일이 모두 있는 이전 커널로 인스턴스를 부팅합니다. 지침을 보려면 업데이트로 인해 Amazon EC2 인스턴스가 성공적으로 재부팅되지 않는 경우, 알려진 안정적인 커널로 되돌리려면 어떻게 해야 하나요?를 참조하세요.
umount 명령을 실행하여 복구 인스턴스에서 보조 장치를 마운트 해제합니다.
```
$ sudo umount /rescue
```
마운트 해제 작업이 성공하지 못하면 복구 인스턴스를 중지하거나 재부팅하여 마운트 해제 작업을 새로 수행해야 할 수 있습니다.
복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리합니다. 그런 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.

커널 패닉 오류를 해결하는 방법에 대한 자세한 내용은 커널을 업그레이드하거나 EC2 Linux 인스턴스를 재부팅한 후 "Kernel panic" 오류가 표시되는 이유는 무엇입니까?를 참조하세요.

“Failed to mount” 또는 “Dependency failed” 문제 해결

시스템 로그에 "Failed to mount" 또는 "Dependency failed"와 같은 오류는 /etc/fstab 파일에 잘못된 마운트 지점 항목이 있음을 나타냅니다.

/etc/fstab의 마운트 지점 항목이 올바른지 확인합니다. /etc/fstab 파일 항목을 수정하려면 부팅하려고 할 때 EC2 Linux 인스턴스가 비상 모드로 전환되는 이유는 무엇입니까?를 참조하세요.

fsck 또는 xfs\ _repair 도구를 실행하여 파일 시스템의 불일치를 수정하는 것이 가장 좋습니다.

참고: fsck 또는 xfs_repair 도구를 실행하기 전에 파일 시스템의 백업을 만드세요.

umount 명령을 실행하여 마운트 지점을 언마운트한 후 fsck 또는 xfs_repair 도구를 실행합니다.

$ sudo umount /rescue

파일 시스템에 따라 fsck 또는 xfs_repair 도구를 실행합니다.

ext4 파일 시스템의 경우 다음 명령을 실행합니다.

$ sudo fsck /dev/sdf
fsck from util-linux 2.30.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdf: clean, 11/6553600 files,
459544/26214400 blocks

XFS 파일 시스템의 경우 다음 명령을 실행합니다.

$ sudo xfs_repair /dev/sdf
xfs_repair /dev/xvdf
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리합니다. 그런 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.

**“interface eth0: failed” 문제 해결 **

ifcfg-eth0 파일에 올바른 네트워크 항목이 있는지 확인합니다. 기본 인터페이스인 eth0에 해당하는 네트워크 구성 파일은 /etc/sysconfig/network-scripts/ifcfg-eth0에 있습니다. 기본 인터페이스의 장치 이름이 eth0이 아닌 경우 파일 이름은 ifcfg로 시작하고 그 뒤에 장치 이름이 옵니다. 이 파일은 인스턴스의 /etc/sysconfig/network-scripts 디렉터리에 있습니다.

cat 명령을 실행하여 기본 인터페이스인 eth0에 대한 네트워크 구성 파일을 확인합니다.

다음은 /etc/sysconfig/network-scripts/ifcfg-eth0에 있는 네트워크 구성 파일에 대한 올바른 항목입니다.

참고: 필요한 경우, 다음 명령에서 eth0을 기본 인터페이스의 이름으로 바꿉니다.

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no

ONBOOT가 yes로 설정되어 있는지 확인합니다. ONBOOT가 yes로 설정되지 않은 경우 eth0(또는 기본 네트워크 인터페이스)가 부팅 시 나타나도록 구성되지 않은 것입니다.

ONBOOT 값을 변경하려면 먼저 편집기에서 파일을 엽니다. 이 예제에서는 vi 편집기를 사용합니다.
```
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
```
I를 눌러 삽입합니다.

커서를 ONBOOT 항목으로 스크롤한 다음 값을 yes로 변경합니다.

파일을 저장하고 종료하려면 **:wq!**를 누르십시오.
umount 명령을 실행하여 복구 인스턴스에서 보조 장치를 마운트 해제합니다.
```
$ sudo umount /rescue
```
마운트 해제 작업이 성공하지 못하면 복구 인스턴스를 중지하거나 재부팅하여 새로 마운트 해제를 시작해야 할 수 있습니다.
복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리합니다. 그런 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.