EC2 Linux 인스턴스가 디스크 오류 때문에 부팅에 실패했을 경우 복구하려면 어떻게 해야 하나요?

간략한 설명

---

fstab 파일에 다음과 같이 잘못된 구성이 있으면 사용자 지정 AMI에서 생성된 Amazon EC2 인스턴스에 디스크 오류가 발생합니다.

• 잘못된 디바이스 ID
• 잘못된 경로 이름
• 잘못되었거나 중복된 UUID

이와 같은 오류를 해결하려면 인스턴스 운영 체제에 액세스해야 합니다. 인스턴스에 액세스할 수 없는 경우 다음 방법 중 하나를 사용해 인스턴스에 액세스하세요.

• EC2 직렬 콘솔 사용
• 수동으로 오류를 수정하는 복구 인스턴스

해결 방법

EC2 직렬 콘솔 사용

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

EC2 직렬 콘솔을 처음 사용하는 경우, 연결하기 전에 사전 요구 사항을 검토하고 액세스를 구성해야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔 액세스를 구성하지 않은 경우, 다음 섹션에 안내된 지침에 따라 수동으로 오류를 수정하는 복구 인스턴스를 사용하세요. EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔 액세스 구성을 참고하세요.

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

경고: 다음 절차를 진행하려면 인스턴스를 중지해야 합니다. 인스턴스가 중지되면 인스턴스 스토어 볼륨에 저장된 데이터가 손실됩니다. 인스턴스를 중지하기 전에 반드시 데이터 백업을 저장하세요. AAmazon Elastic Block Store(Amazon EBS) 지원 볼륨과 달리, 인스턴스 스토어 볼륨은 데이터 지속성을 지원하지 않는 임시 스토어입니다.

인스턴스가 실행하거나 시작할 때 Amazon EC2에서 자동으로 할당하는 공용 IPv4 주소는 인스턴스가 중지되고 시작한 후에 변경됩니다. 인스턴스를 중지해도 변경되지 않는 공용 IPv4 주소를 유지하려면 탄력적 IP 주소를 사용하세요.

자세한 내용은 인스턴스를 중지하면 어떻게 되나요?를 참고하세요.

1. Virtual Private Cloud(VPC)에서 디스크 오류가 있는 AMI를 사용해 새 EC2 인스턴스를 실행합니다. 새 인스턴스를 손상된 인스턴스와 동일한 가용 영역에서 실행합니다. 새 인스턴스가 복구 인스턴스가 됩니다.

또는 장애가 있는 인스턴스와 동일한 AMI를 사용하면서 동일한 가용 영역에 있는 기존 인스턴스를 사용하세요.

2.    손상된 인스턴스를 중지합니다.

3.    손상된 인스턴스에서 Amazon EBS 루트 볼륨을 분리합니다(/dev/xvda 또는 /dev/sda1). 루트 볼륨의 디바이스 이름(/dev/xvda 또는 /dev/sda1)을 기록해 둡니다.

4.    복구 인스턴스에 보조 디바이스(/dev/sdf)로 EBS 볼륨을 연결합니다.

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

6.    복구 인스턴스에 연결된 새 볼륨의 마운트 지점 디렉터리(/rescue)를 생성합니다.

$ sudo mkdir /rescue

7. 디렉터리에 볼륨을 마운트합니다.

$ sudo mount /dev/xvdf1 /rescue

참고: 디바이스(/dev/xvdf1)가 다른 디바이스 이름으로 복구 인스턴스에 연결되었을 수 있습니다. 올바른 디바이스 이름을 확인하려면 lsblk 명령을 사용해 사용 가능한 디스크 디바이스와 마운트 지점을 확인하세요.

7. 볼륨 문제 해결:

다음 명령을 실행해 fstab 항목을 확인합니다.

$ cat /rescue/etc/fstab

다음 예제에서 fstab 항목에 볼륨 두 개가 있습니다.

UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1
UUID=1b75bcf4-ee55-428e-8d68-88dca398da01 /test xfs defaults,nofail 0 2

fstab 항목에서 다음 구성을 확인하세요.

• 항목에 디바이스 ID가 포함되어 있지 않습니다. 잘못된 디바이스 ID로 인해 문제 및 불일치가 발생합니다. 디바이스 ID 대신 UUID를 사용하는 것이 좋습니다. 디바이스 ID가 파일에 있는 경우, 이를 볼륨 UUID로 바꿉니다. 올바른 UUID를 찾으려면 다음 명령을 실행합니다.

  lsblk -f

• 마운트 지점 경로가 올바르고 볼륨에 존재하는지 확인합니다.

• UUID가 중복되는 확인합니다. 또 장애가 발생한 인스턴스의 추가 볼륨이 동일한 UUID를 사용하는지 확인하세요. 추가 볼륨의 UUID를 확인하려면 위 단계를 사용해 복구 인스턴스에 연결합니다. UUID 중복이 있는 경우 볼륨을 마운트할 수 없으며 다음과 같은 오류가 발생합니다.

  mount: /rescue: wrong fs type, bad option, bad superblock on /dev/xvdg1, missing codepage or helper program, or other error

  연결된 볼륨의 UUID를 확인하려면 다음 명령을 실행합니다.

  $ lsblk -f

  UUID 중복이 있는 경우, 다음 명령을 실행해 UUID를 변경합니다.

  XFS 파일 시스템:

  $ sudo xfs_admin -U <unique UUID> /dev/xvdb1

  EXT4 파일 시스템:

  $ tune2fs -U random /dev/sdb1

  또 다음 예와 같이 fstab 항목에 nofail 옵션을 추가하세요.

  UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2

  **참고: ** 특정 볼륨을 연결하지 않고 인스턴스를 부팅할 때 nofail 마운트 옵션을 사용하면 마운트 오류가 발생해도 인스턴스를 부팅할 수 있습니다. 예를 들어 볼륨을 다른 인스턴스로 이동한 후 인스턴스 부팅을 시도할 수 있습니다. Ubuntu 16.04 이전 버전을 포함한 Debian 파생 제품에도 nobootwait 마운트 옵션을 추가해야 합니다.

8. 오류를 수정한 후 파일을 저장하고 umount 명령을 실행해 마운트된 볼륨을 마운트 해제합니다.

$ sudo umount /mnt/rescue

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

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