beautifulsoups.dev
Published on

Azure VM 부팅불가? Boot Diagnostics로 10분 복구

Authors

운영 중인 Azure VM이 갑자기 접속 불가 상태가 되면 보통 두 가지 반응이 나옵니다.

  • “네트워크 문제겠지” 하고 NSG, 라우팅, 공인 IP부터 뒤진다
  • “VM이 죽었나?” 하고 재부팅을 반복한다

문제는 VM이 실제로는 부팅 단계에서 멈췄거나, OS 레벨에서 네트워크가 깨졌거나, 파일시스템이 read-only로 올라가 서비스가 뜨지 않는 상황에서는 위 두 접근이 시간을 크게 낭비하게 만든다는 점입니다.

Azure에서 이럴 때 가장 먼저 봐야 하는 것이 Boot Diagnostics 입니다. 부팅 스크린샷과 시리얼 로그를 통해 “OS가 어디까지 올라왔는지”를 확인하고, 경우에 따라 Serial Console 로 바로 들어가 복구까지 진행할 수 있습니다. 이 글은 “10분 내 1차 복구”를 목표로, 현장에서 자주 나오는 패턴과 커맨드 중심으로 정리합니다.

참고로 더 긴 버전의 케이스 기반 가이드는 아래 글도 함께 보시면 좋습니다.

1) Boot Diagnostics가 정확히 뭘 주는가

Boot Diagnostics는 크게 3가지를 제공합니다.

  1. Boot screenshot: 부팅 화면 캡처(커널 패닉, initramfs, fsck 멈춤 등 시각적 단서)
  2. Serial log: 부팅 시 콘솔 출력 로그(커널 메시지, systemd 유닛 실패, cloud-init 실패 등)
  3. Serial Console 접속(가능한 경우): 부팅 후 로그인 프롬프트까지 도달하면 콘솔로 직접 진입 가능

여기서 핵심은 “접속 불가” 상태가 네트워크 장애인지, OS 부팅/서비스 장애인지를 1~2분 내로 갈라낼 수 있다는 점입니다.

2) 10분 복구를 위한 초단기 체크리스트

장애 상황에서 바로 따라 하는 순서입니다.

2.1 Azure Portal에서 부팅 단계 확인

  1. VM 선택
  2. Boot diagnostics 메뉴 진입
  3. 스크린샷과 시리얼 로그 확인

여기서 분기합니다.

  • 스크린샷이 커널 패닉, initramfs, fsck 등에서 멈춤 = OS 부팅 문제 가능성 큼
  • 로그인 프롬프트까지 보이는데 SSH/RDP만 안 됨 = 네트워크 또는 서비스 문제 가능성 큼
  • 아예 화면이 초기 BIOS 수준에서 멈춤 = 호스트/디스크 계층 문제 가능성

2.2 Serial Console이 된다면 바로 들어가 1차 복구

Serial Console 접속이 가능하면, “네트워크가 죽었어도” OS 내부를 만질 수 있습니다.

Linux 기준으로 아래부터 확인합니다.

# 부팅 후 systemd 상태
systemctl --failed
journalctl -xb --no-pager | tail -n 200

# 디스크/파일시스템 상태
lsblk
df -h
mount | head

dmesg -T | tail -n 200

Windows라면 SAC 및 cmd 채널에서 네트워크/서비스 상태를 확인하고, 필요 시 안전 모드 부팅이나 드라이버 롤백을 고려합니다.

2.3 Serial Console이 안 된다면 “OS 디스크 오프라인 복구”로 전환

로그인 프롬프트까지 못 가거나 콘솔이 활성화되지 않으면, 다음 플랜은 OS 디스크를 분리해서 다른 VM에 붙여 고치는 방식입니다.

  • 문제 VM 중지
  • OS 디스크 분리
  • 정상 복구용 VM(Rescue VM)에 OS 디스크를 데이터 디스크로 연결
  • 마운트 후 설정/부트로더/네트워크 수정
  • 다시 원래 VM에 OS 디스크 연결

이 방식은 다소 번거롭지만, “부팅 자체가 안 되는” 케이스에서 가장 확실합니다.

3) Boot Diagnostics 로그에서 자주 보는 장애 패턴 6가지

아래는 시리얼 로그에서 자주 보이는 키워드와, 바로 적용 가능한 복구 방향입니다.

3.1 파일시스템 오류 또는 read-only 마운트

증상

  • 부팅 중 fsck 단계에서 멈춤
  • EXT4-fs error 같은 메시지
  • 부팅은 되는데 서비스가 안 뜨고 로그에 Read-only file system

Serial Console에서 가능한 조치

# 루트가 read-only면 우선 remount 시도
mount -o remount,rw /

# 디스크 확인
lsblk -f

# 필요 시 단일 사용자 모드/복구 모드에서 fsck
# (실제 디바이스는 환경에 맞게)
fsck -fy /dev/sda2
reboot

주의: 루트 파티션에 대해 온라인 fsck 는 위험할 수 있습니다. 상황에 따라 OS 디스크를 분리해 오프라인으로 검사하는 편이 안전합니다.

3.2 디스크 100%로 부팅 후 서비스 실패

증상

  • 부팅은 되는데 SSH가 느리거나 로그인 직후 튕김
  • No space left on device 로 서비스/로그인 실패

조치

df -h
sudo du -xhd1 /var | sort -h | tail
sudo journalctl --vacuum-time=7d
sudo rm -f /var/log/*.gz

디스크가 100%인데 용량이 안 보이는 케이스(삭제했는데도 사용량이 줄지 않음)는 보통 “열려 있는 삭제 파일” 또는 inode 문제입니다. 아래 글이 같은 결의 트러블슈팅에 도움이 됩니다.

3.3 cloud-init 또는 커스텀 스크립트 확장 실패로 부팅 지연

증상

  • 부팅 로그에 cloud-init 단계가 길게 멈춤
  • VM Extension 설치/실행이 반복 실패

조치(임시로 부팅을 살리는 목적)

# cloud-init 상태 확인
cloud-init status --long

# 문제 원인 로그 확인
journalctl -u cloud-init --no-pager | tail -n 200

# 급하면 cloud-init 비활성화(재발 방지 설계는 별도)
sudo touch /etc/cloud/cloud-init.disabled
sudo reboot

이후에는 확장 스크립트의 idempotency, 재시도 정책, 네트워크 의존성 등을 점검해야 합니다.

3.4 커널 패닉 또는 드라이버/커널 업데이트 후 부팅 실패

증상

  • 스크린샷에 커널 패닉
  • 시리얼 로그에 Kernel panic - not syncing 같은 문구

조치 방향

  • GRUB 메뉴로 진입 가능한지 확인(가능하면 이전 커널로 부팅)
  • 오프라인 디스크 복구로 /boot 및 커널 패키지 롤백

Rescue VM에서 오프라인 복구 예시(개념)

# 문제 OS 디스크가 /dev/sdc 로 붙었다고 가정
sudo mkdir -p /mnt/vm
sudo mount /dev/sdc2 /mnt/vm

# chroot 준비(배포판에 따라 다름)
sudo mount --bind /dev /mnt/vm/dev
sudo mount --bind /proc /mnt/vm/proc
sudo mount --bind /sys /mnt/vm/sys
sudo chroot /mnt/vm

# 여기서 커널 패키지 롤백/재설치 등 수행

3.5 네트워크 설정 깨짐으로 SSH/RDP만 불가

증상

  • 스크린샷상 로그인 프롬프트까지 도달
  • 하지만 외부에서 SSH/RDP가 안 됨

Serial Console에서 네트워크 확인

ip a
ip r
cat /etc/resolv.conf

# systemd-networkd 또는 NetworkManager 상태
systemctl status systemd-networkd --no-pager
systemctl status NetworkManager --no-pager

Azure VM은 NIC 설정이 Azure 쪽과 OS 쪽이 함께 맞아야 합니다. 최근에 이미지 커스터마이징 과정에서 netplan 또는 udev 규칙이 꼬이면, “부팅은 정상인데 접속만 불가”가 자주 발생합니다.

3.6 메모리 압박으로 부팅 후 서비스가 연쇄 장애

증상

  • 부팅은 되지만 서비스가 자주 죽고, 간헐적으로 접속 불가
  • 로그에 OOM 관련 메시지

조치

dmesg -T | grep -i -E "oom|killed process" | tail -n 50
free -m
ps aux --sort=-%mem | head

OOM 분석 접근은 아래 글과 동일한 결로 진행하면 빠릅니다.

4) “10분 복구”를 현실로 만드는 운영 팁

단순히 Boot Diagnostics를 보는 것만으로는 복구 시간이 줄지 않습니다. 평소에 아래를 준비해 두면 실제 장애에서 10분 내 1차 복구가 가능해집니다.

4.1 Boot Diagnostics를 항상 켜 두기(스토리지 포함)

  • 진단 스토리지 계정 또는 관리형 스토리지를 미리 연결
  • 권한 문제로 로그를 못 보는 상황이 없게 RBAC 정리

장애가 난 뒤에 켜면 “장애 시점의 로그”가 이미 사라졌을 수 있습니다.

4.2 Serial Console 사용 조건을 충족시키기

Linux에서 Serial Console이 제대로 동작하려면 배포판/설정에 따라 콘솔 설정과 부팅 파라미터가 필요할 수 있습니다. 표준 이미지 사용, 커널 파라미터 변경 최소화, 접근 계정 정책 정리가 중요합니다.

4.3 Rescue VM(복구용 점프박스)을 상시 준비

  • 같은 VNet/Subnet에 작은 VM 하나를 준비
  • 자주 쓰는 툴(lvm2, xfsprogs, mdadm)을 설치
  • Managed Identity 또는 Key Vault 연동으로 비상 접근 경로 확보

OS 디스크 오프라인 복구는 “복구용 VM이 준비돼 있느냐”에 따라 10분이 40분이 되기도 합니다.

4.4 변경 작업 전 스냅샷/백업을 습관화

  • 커널 업데이트
  • 디스크 파티션 변경
  • 부트로더/암호화 설정 변경

이런 작업 전에는 OS 디스크 스냅샷 하나로 복구 난이도가 급격히 낮아집니다.

5) 빠른 결론: 먼저 부팅 단계를 확정하라

Azure VM 장애에서 가장 흔한 실수는 “접속이 안 된다”를 곧바로 네트워크 문제로 단정하는 것입니다. Boot Diagnostics로 아래만 확정해도 절반은 끝납니다.

  • OS가 커널 단계에서 죽는가
  • initramfs, fsck, cloud-init 같은 부팅 체인에서 멈추는가
  • 로그인 프롬프트까지 오지만 네트워크만 죽었는가

그리고 가능하면 Serial Console로 즉시 들어가 journalctl, systemctl --failed, dmesg, df -h 만 확인해도 대부분의 1차 복구는 10분 안에 가능합니다.

장애 대응을 더 체계화하려면, Boot Diagnostics 캡처와 시리얼 로그에서 어떤 키워드를 어떤 조치로 연결할지 “런북” 형태로 팀에 공유해 두는 것을 권장합니다.

Discuss on Twitter • View on GitHub