EC2 Linux 인스턴스가 부팅되지 않고 비상 모드로 전환되는 이유는 무엇입니까?

최종 업데이트 날짜: 2020년 4월 22일

Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스를 부팅하면 인스턴스가 비상 모드로 전환되고 부팅 프로세스가 실패합니다. 그러면 인스턴스에 액세스할 수 없습니다. 이 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

인스턴스가 비상 모드에서 부팅되는 가장 일반적인 이유는 다음과 같습니다.

  • 커널이 손상되었습니다.
  • /etc/fstab의 잘못된 항목으로 인해 자동 탑재 실패.

어떤 유형의 오류가 발생하는지 확인하려면 인스턴스의 콘솔 출력을 확인합니다. 커널이 손상된 경우 콘솔 출력에 커널 패닉이라는 오류 메시지가 표시될 수 있습니다. 자동 탑재 실패가 발생하면 종속성 실패 메시지가 콘솔 출력에 표시됩니다.

​해결 방법

커널 패닉 오류

GRub 구성 또는 initramfs 파일이 손상되면 커널 패닉 오류 메시지가 발생합니다. 커널에 문제가 있는 경우 콘솔 출력에 "커널 패닉 – 동기화 되지 않음 : VFS: 알 수 없는 블록(8,1)에 루트 fs를 탑재할 수 없음" 오류가 표시될 수 있습니다.

커널 패닉 오류를 해결하려면:

1.    커널을 이전의 안정적인 커널로 되돌립니다. 이전 커널로 되돌리는 방법에 대한 지침은 업데이트로 인해 Amazon EC2 인스턴스가 성공적으로 재부팅되지 않고 이후 알려진 안정적인 커널로 되돌리려면 어떻게 해야 합니까?를 참조하십시오.

2.    이전 커널로 되돌린 후 인스턴스를 재부팅합니다. 그런 다음 손상된 커널에서 문제를 해결합니다.

종속성 실패 오류

/etc/fstab 파일의 구문 오류로 인한 자동 탑재 실패 때문에 인스턴스가 비상 모드로 전환될 수 있습니다. 또한 파일에 나열된 Amazon Elastic Block Store(Amazon EBS) 볼륨이 인스턴스에서 분리되면 인스턴스 부팅 프로세스가 비상 모드로 전환될 수 있습니다. 이러한 문제 중 하나가 발생하면 콘솔 출력은 다음과 같습니다.

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

앞의 예제 로그 메시지는 부팅 시퀀스 중에 /mnt 탑재 지점에 탑재되지 않았음을 보여 줍니다.

탑재 실패로 인해 부팅 시퀀스가 비상 모드로 전환되는 것을 방지하려면:

  • 보조 파티션(이전 예제에서는 /mnt)에 대해 nofail 옵션을 /etc/fstab 파일에 추가합니다. nofail 옵션이 있으면 볼륨 또는 파티션 탑재에 실패하더라도 부팅 시퀀스가 중단되지 않습니다.
  • 각 탑재 지점에 대한 /etc/fstab 파일의 마지막 열로 0을 추가합니다. 0 열을 추가하면 파일 시스템 검사가 비활성화되어 인스턴스가 성공적으로 부팅될 수 있습니다.

/etc/fstab 파일을 수정하는 데 사용할 수 있는 방법은 두 가지입니다.

중요:

  • 이 절차를 수행하려면 EC2 인스턴스를 중지했다가 다시 시작해야 합니다. 인스턴스가 중지되었다가 다시 시작되면 인스턴스 스토어 데이터가 손실됩니다. 사용하는 인스턴스가 인스턴스 스토어로 지원되거나 인스턴스에 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스를 중지할 때 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하십시오.
  • 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부이거나 Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk 등과 같이 AWS Auto Scaling을 사용하는 서비스에서 인스턴스를 시작한 경우 인스턴스를 중단하면 인스턴스가 종료될 수 있습니다. 이 시나리오에서 인스턴스 종료는 Auto Scaling 그룹에 대한 인스턴스 축소 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스 제거합니다.
  • 인스턴스를 중지하고 다시 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때에는 퍼블릭 IP 주소 대신, 탄력적 IP 주소를 사용하는 것이 모범 사례입니다.

방법 1: AWSSupport-ExecuteEC2Rescue 자동화 문서 실행

인스턴스가 AWS Systems Manager에 대해 구성된 경우 AWSSupport-ExecuteEC2Rescue 자동화 문서를 실행하여 부팅 문제를 수정할 수 있습니다. 이 방법을 사용할 때는 수동 개입이 필요하지 않습니다. 자동화 문서 사용에 대한 자세한 내용은 시연: 연결할 수 없는 인스턴스에서 EC2Rescue 도구 실행을 참조하십시오.

방법 2: 복구 인스턴스를 사용하여 수동으로 파일 편집

1.    Amazon EC2 콘솔을 엽니다.

2.    탐색 창에서 [인스턴스]를 선택한 다음 비상 모드 상태에 있는 인스턴스를 선택합니다.

3.    인스턴스를 중지합니다.

4.    중지된 인스턴스에서 Amazon EBS 루트 볼륨(/dev/xvda 또는 /dev/sda1)을 분리합니다.

5.    손상된 인스턴스와 동일한 가용 영역에서 새 EC2 인스턴스를 시작합니다. 새 인스턴스가 복구 인스턴스가 됩니다.

6.    4단계에서 분리한 루트 볼륨을 보조 디바이스로 복구 인스턴스에 연결합니다.

참고: 보조 볼륨을 연결할 때 다른 디바이스 이름을 사용할 수 있습니다.

7.    SSH를 사용하여 복구 인스턴스에 연결합니다.

8.    6단계에서 복구 인스턴스에 연결된 새 볼륨의 탑재 지점 디렉터리를 생성합니다. 다음 예제에서 탑재 지점 디렉터리는 /mnt/rescue입니다.

$ sudo mkdir /mnt/rescue

9.    8단계에서 생성한 디렉터리에 볼륨을 탑재합니다.

$ sudo mount /dev/xvdf /mnt/rescue

참고: 디바이스(이전 예제에서는 /dev/xvdf1)가 다른 디바이스 이름으로 복구 인스턴스에 연결될 수 있습니다. lsblk 명령을 사용하여 사용 가능한 디스크 디바이스와 탑재 지점을 보고 올바른 디바이스 이름을 확인하십시오.

10.    볼륨이 탑재된 후 다음 명령을 실행하여 /etc/fstab 파일을 엽니다.

$ sudo vi /mnt/rescue/etc/fstab

11.    필요에 따라 /etc/fstab의 항목을 편집합니다. 다음 예제 출력은 UUID로 정의된 3개의 EBS 볼륨, 두 보조 볼륨 모두에 대해 추가된 nofail 옵션, 각 항목의 마지막 열로 0을 보여줍니다.

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.    파일을 저장한 다음 umount 명령을 실행하여 볼륨의 탑재를 해제합니다.

$ sudo umount /mnt/rescue

13.    임시 인스턴스에서 볼륨을 분리합니다.

14.    볼륨을 원본 인스턴스에 연결한 다음 인스턴스를 시작하여 성공적으로 부팅되는지 확인합니다.


이 문서가 도움이 되었습니까?

AWS에서 개선해야 할 부분이 있습니까?


도움이 필요하십니까?