EC2 Linux 인스턴스가 운영 체제 문제로 인해 인스턴스 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 하나요?
Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스가 운영 체제 문제로 인해 인스턴스 상태 확인에 실패했습니다. 이제 인스턴스가 부팅되지 않습니다. 이 문제를 해결하려면 어떻게 해야 하나요?
간략한 설명
EC2 Linux 인스턴스는 다음과 같은 이유로 인스턴스 상태 확인에 실패할 수 있습니다.
- 커널을 업데이트한 후 새 커널이 부팅되지 않았습니다.
- /etc/fstab의 파일 시스템 항목이 잘못되었거나 파일 시스템이 손상되었습니다.
- 인스턴스의 네트워크 구성이 잘못되었습니다.
해결 방법
OS 문제를 해결하는 방법에는 3가지가 있습니다.
중요:
방법 2와 3을 적용하려면 인스턴스를 중지한 후 시작해야 합니다. 다음 사항에 유의하세요.
- 인스턴스 스토어가 지원되는 인스턴스이거나 데이터가 포함된 인스턴스 스토어 볼륨이 인스턴스에 있는 경우 인스턴스 중지 시 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
- 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인 경우 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 인스턴스를 시작한 경우 인스턴스가 AWS Auto Scaling 그룹의 일부일 수 있습니다. 이 시나리오에서 인스턴스 종료는 Auto Scaling 그룹에 대한 인스턴스 확장 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스 제거합니다.
- 인스턴스를 중지했다가 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 가장 좋습니다. Amazon Route 53를 사용하는 경우 퍼블릭 IP가 변경될 때 Route 53 DNS 레코드를 업데이트해야 할 수 있습니다.
방법 1: EC2 직렬 콘솔 사용
Linux용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다.
직렬 콘솔을 사용하기 전에 계정 수준에서 액세스 권한을 부여합니다. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 방법 2의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.
참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.
방법 2: EC2Rescue for Linux 도구 실행
EC2Rescue for Linux는 연결할 수 없는 인스턴스의 운영 체제 문제를 자동으로 진단하고 해결합니다. 자세한 내용은 EC2Rescue for Linux를 사용하여 운영 체제 수준의 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.
방법 3: 복구 인스턴스를 사용하여 수동으로 오류 수정
1. 동일한 Amazon Machine Image(AMI)를 사용하여 Virtual Private Cloud(VPC)에서 새 EC2 인스턴스를 시작합니다. 손상된 인스턴스와 동일한 가용 영역에서 새 인스턴스를 시작합니다. 새 인스턴스가 복구 인스턴스가 됩니다.
또는 액세스할 수 있는 기존 인스턴스가 동일한 AMI를 사용하고 손상된 인스턴스와 동일한 가용 영역에 있는 경우 기존 인스턴스를 사용할 수 있습니다.
2. 손상된 인스턴스를 중지합니다.
3. 손상된 인스턴스에서 Amazon Elastic Block Store(Amazon EBS) 루트 볼륨(/dev/xvda 또는 /dev/sda1)을 분리합니다. 루트 볼륨의 디바이스 이름(/dev/xvda 또는 /dev/sda1)을 기록해 둡니다.
4. 복구 인스턴스에 보조 디바이스(/dev/sdf)로 볼륨을 연결합니다.
5. SSH를 사용하여 복구 인스턴스에 연결합니다.
6. 복구 인스턴스에 연결된 새 볼륨의 탑재 지점 디렉터리(/rescue)를 생성합니다.
$ sudo mkdir /rescue
7. 6단계에서 생성한 디렉터리에 볼륨을 탑재합니다.
$ sudo mount /dev/xvdf1 /rescue
참고: 디바이스(/dev/xvdf1)가 다른 디바이스 이름으로 복구 인스턴스에 연결되었을 수 있습니다. lsblk 명령을 사용하여 사용 가능한 디스크 디바이스와 탑재 지점을 보고 올바른 디바이스 이름을 확인하세요.
8. 아직 그렇게 하지 않은 경우 인스턴스의 시스템 로그를 검색하여 어떤 오류가 발생 중인지 확인합니다. 다음 단계는 시스템 로그에 나열된 오류 메시지에 따라 달라집니다. 다음은 인스턴스 상태 확인 실패의 원인이 될 수 있는 일반적인 오류 목록입니다. 추가 오류는 Linux 기반 인스턴스의 시스템 로그 오류 문제 해결을 참조하십시오.
커널 패닉
시스템 로그에 커널 패닉 오류 메시지가 있는 경우 커널에 vmlinuz 또는 initramfs 파일이 없을 수 있습니다. 성공적으로 부팅하려면 vmlinuz 및 initramfs 파일이 필요합니다.
1. 다음 명령을 실행합니다.
cd /rescue/boot ls -l
2. 출력을 확인하여 부팅하려는 커널 버전에 해당하는 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
3. initramfs 및/또는 vmlinuz 파일이 없는 경우 이 두 파일이 모두 있는 이전 커널을 사용하여 인스턴스를 부팅하세요. 이전 커널을 사용하여 인스턴스를 부팅하는 방법에 대한 지침은 업데이트로 인해 Amazon EC2 인스턴스를 재부팅하지 못하는 경우 알려진 안정적인 커널로 되돌리려면 어떻게 해야 합니까?를 참조하세요.
4. unmount 명령을 실행하여 복구 인스턴스에서 보조 디바이스의 탑재를 해제합니다.
$ sudo umount /rescue
탑재 해제 작업에 실패할 경우 복구 인스턴스를 중지하거나 재부팅하여 클린 탑재 해제를 활성화해야 할 수 있습니다.
5. 복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리한 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
6. 인스턴스 시작 후 다음 인스턴스가 응답하는지 확인합니다.
커널 패닉 오류 해결에 대한 자세한 내용은 커널을 업그레이드하거나 EC2 Linux 인스턴스의 재부팅을 시도한 후에 "Kernel panic" 오류가 발생합니다. 이 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.
탑재 실패 또는 종속성 실패
시스템 로그에 "Failed to mount" 또는 "Dependency failed"와 같은 오류가 표시되는 경우 /etc/fstab 파일에 잘못된 탑재 지점 항목이 있을 수 있습니다.
1. /etc/fstab의 탑재 지점 항목이 올바른지 확인합니다. /etc/fstab 파일 항목 수정에 대한 자세한 내용은 EC2 인스턴스가 부팅되지 않고 비상 모드로 전환되는 이유는 무엇입니까?의 /etc/fstab file 섹션의 잘못된 항목으로 인한 자동 탑재 실패 섹션을 참조하십시오.
2. 모범 사례는 fsck 또는 xfs_repair 도구를 실행하여 파일 시스템 오류를 수정하는 것입니다. 파일 시스템에 불일치가 있는 경우 fsck 또는 xfs_repair 도구가 이를 수정합니다.
참고: fsck 또는 xfs_repair 도구를 실행하기 전에 파일 시스템의 백업을 생성하세요.
fsck 또는 xfs_repair 도구를 실행하기 전에 unmount 명령을 실행하여 탑재 지점을 탑재 해제합니다.
$ sudo umount /rescue
파일 시스템에 따라 fsk 또는 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
3. 복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리한 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
4. 인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.
Bringing up interface eth0: failed
"Bringing up interface eth0: failed" 오류가 표시되는 경우**,** ifcfg-eth0 파일에 올바른 네트워크 항목이 있는지 확인합니다. 기본 인터페이스인 eth0에 해당하는 네트워크 구성 파일은 /etc/sysconfig/network-scripts/ifcfg-eth0에 있습니다. 기본 인터페이스의 디바이스 이름이 eth0이 아닌 경우 ifcfg로 시작되고 디바이스 이름이 추가된 파일이 /etc/sysconfig/network-scripts 디렉터리에 있습니다.
1. 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
2. 이전 예제에 표시된 것과 같이 ONBOOT가 yes로 설정되어 있는지 확인합니다. ONBOOT가 yes로 설정되지 않은 경우 eth0(또는 기본 네트워크 인터페이스)이 부팅 시 시작되도록 구성되지 않은 것입니다.
ONBOOT 값을 변경하려면:
편집기에서 파일을 엽니다. 여기에 주어진 예시에서는 VI 편집기를 사용합니다.
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
I 키를 눌러 삽입합니다.
커서를 ONBOOT 항목으로 스크롤한 다음 값을 yes로 변경합니다.
**:wq!**를 눌러 파일을 저장하고 종료합니다.
3. unmount 명령을 실행하여 복구 인스턴스에서 보조 디바이스의 탑재를 해제합니다.
$ sudo umount /rescue
탑재 해제 작업에 실패할 경우 복구 인스턴스를 중지하거나 재부팅하여 클린 탑재 해제를 활성화해야 할 수 있습니다.
4. 복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리한 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.
5. 인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.
관련 정보
EC2 Linux 인스턴스에 연결할 수 없고 상태 검사 중 하나 또는 둘 다 실패하는 이유는 무엇인가요?
Linux 인스턴스의 유형을 Nitro 기반 인스턴스 유형으로 변경한 후에 부팅이 되지 않는 이유는 무엇입니까?
관련 콘텐츠
- 질문됨 한 달 전
- AWS 공식업데이트됨 3달 전
- AWS 공식업데이트됨 7달 전
- AWS 공식업데이트됨 3년 전
