beautifulsoups.dev
Published on

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

Authors

서버가 갑자기 부팅이 안 되면(SSH/RDP 불가, 상태는 Running인데 접속 불가) 대부분은 OS 레벨 부팅 단계에서 막히거나 네트워크/에이전트가 올라오지 않은 상황입니다. 이때 가장 먼저 해야 할 일은 “재부팅을 반복”하는 게 아니라, 부팅 과정에서 무슨 메시지가 찍혔는지 증거를 확보하는 것입니다.

Azure에서는 그 역할을 **Boot Diagnostics(부팅 진단)**가 해줍니다. 콘솔 스크린샷과 시리얼 로그를 통해 커널 패닉, 파일시스템 오류, init 실패, cloud-init 문제, Windows 부트로더 문제 등을 빠르게 확인할 수 있고, 조건이 맞으면 Serial Console로 직접 로그인해 응급 조치도 가능합니다.

이 글은 “15분 복구”를 목표로, 실제 운영에서 많이 터지는 케이스를 기준으로 진단 → 분기 → 복구 플로우를 제공합니다.

> 장애 대응은 네트워크든 애플리케이션이든 결국 ‘증거 확보 → 가설 축소 → 최소 변경으로 복구’의 반복입니다. 이 접근은 예를 들어 OpenAI Responses API 504 Timeout 재현·해결 같은 케이스에서도 동일하게 통합니다.

1) 0~3분: “부팅 불가”를 정확히 정의하기

먼저 증상을 분류해야 시간 낭비가 줄어듭니다.

체크리스트

  • Azure Portal에서 VM 상태: Running/Stopped(Deallocated)
  • 부팅 후 에이전트 상태: VM Agent ready 여부
  • 접속 실패 형태
    • SSH: timeout / connection refused / key auth fail
    • RDP: black screen / credential fail / timeout
  • 최근 변경: 커널 업데이트, fstab 수정, 디스크 확장, NSG 변경, cloud-init 수정, 드라이버 설치 등

여기서 “Running인데도 SSH timeout”이면 네트워크/NSG/라우팅일 수도 있지만, “Running인데도 콘솔 화면이 부팅 단계에서 멈춤”이면 OS 부팅 문제일 확률이 큽니다. Boot Diagnostics는 후자를 빠르게 가려냅니다.

2) 3~7분: Boot Diagnostics 켜고 스크린샷/로그 확보

Boot Diagnostics 활성화

  1. Azure Portal → VM → Boot diagnostics
  2. Enable
  3. 진단 스토리지(Managed storage 또는 Storage Account) 선택

활성화 후 다음 두 가지를 봅니다.

  • Screenshot: 현재 콘솔 화면(부팅 단계에서 멈췄는지 확인)
  • Serial log: 부팅 로그(커널/시스템 메시지)

자주 보이는 패턴(스크린샷/로그)

  • fsck/EXT4-fs error/XFS (sda1): log I/O error
  • Kernel panic - not syncing
  • Gave up waiting for root filesystem device
  • Failed to mount /... (특히 / 또는 /var)
  • A start job is running for ... (systemd unit hang)
  • Windows: INACCESSIBLE_BOOT_DEVICE, BOOTMGR is missing

이 단계에서 목표는 “원인이 OS 부팅인지/네트워크인지”를 확정하는 것입니다.

3) 7~12분: Serial Console로 응급 조치(가능한 경우)

Boot Diagnostics가 켜져 있고, VM이 Serial Console 조건을 만족하면(일반적으로 VM Agent/부트 설정, 권한, OS 지원 등) Portal에서 Serial console을 열 수 있습니다.

Linux: fstab 오타로 부팅 멈춤(가장 흔함)

증상: 부팅 로그에 Failed to mount ... 또는 Dependency failed for Local File Systems.

조치(예시):

# 1) 루트 권한 확보(환경에 따라 바로 root이거나 sudo 필요)
sudo -i

# 2) 최근 수정된 fstab 확인
cat /etc/fstab

# 3) 문제가 되는 마운트 라인 임시 주석 처리
# (예: UUID가 틀렸거나 디스크 이름이 바뀐 경우)
cp /etc/fstab /etc/fstab.bak
sed -i 's/^UUID=deadbeef-.*\/data/#&/' /etc/fstab

# 4) systemd가 멈춘 상태라면 재시도
systemctl daemon-reload
reboot

운영 팁:

  • 데이터 디스크 마운트는 장애 전파를 줄이기 위해 nofail,x-systemd.device-timeout=10s 옵션을 고려합니다.
UUID=xxxx-xxxx  /data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2

Linux: 파일시스템 오류로 fsck 대기

부팅 로그에 fsck 관련 메시지가 나오고 멈춰 있으면, Serial Console에서 직접 fsck를 수행하거나(루트 파티션은 제한적) 복구 VM로 오프라인 fsck가 더 안전합니다(아래 4절).

Windows: 부팅 로더/디스크 접근 문제

Windows는 Serial Console로 할 수 있는 범위가 제한적입니다. 이 경우는 빠르게 복구 VM(디스크 분리/재부착) 플로우로 넘어가는 편이 15분 목표에 유리합니다.

4) 12~15분: 안 되면 “복구 VM”로 오프라인 수정(가장 확실)

Serial Console이 안 열리거나, 루트 디스크/부트 영역 문제로 손을 못 대는 경우는 OS 디스크를 다른 VM에 붙여서 오프라인으로 수정하는 방식이 정석입니다.

복구 절차(공통 개념)

  1. 장애 VM Stop (deallocate)
  2. 장애 VM의 OS Disk를 분리(Detach)
  3. 같은 리전/서브넷의 “복구용 VM(정상 부팅되는 VM)”에 데이터 디스크로 Attach
  4. 복구 VM에서 디스크 마운트 후 설정 수정
  5. 원래 VM에 OS Disk를 다시 붙이고 부팅

> 실제 UI 버튼/용어는 포털에서 조금씩 다를 수 있지만, 개념은 동일합니다.

Linux 오프라인 수정 예시: fstab/네트워크/SSH 설정

복구 VM에 디스크가 /dev/sdc1로 붙었다고 가정합니다.

# 복구 VM에서
sudo -i
lsblk
mkdir -p /mnt/rescue
mount /dev/sdc1 /mnt/rescue

# 1) fstab 수정
nano /mnt/rescue/etc/fstab

# 2) 네트워크 설정 확인(예: NetworkManager, systemd-networkd)
ls -al /mnt/rescue/etc/netplan || true

# 3) SSH 설정 확인
grep -n "^PermitRootLogin\|^PasswordAuthentication" /mnt/rescue/etc/ssh/sshd_config || true

umount /mnt/rescue

Windows 오프라인 수정 방향

  • BCD/부트로더 이슈: Windows 복구 환경(WinRE) 또는 Azure의 복구 옵션을 활용하는 편이 빠를 수 있습니다.
  • 드라이버/업데이트 꼬임: 오프라인에서 문제 업데이트 제거, 드라이버 롤백 등의 접근이 필요합니다.

5) “부팅은 되는데 접속이 안 됨”일 때의 분기

Boot Diagnostics에서 부팅이 정상으로 보이는데도 SSH/RDP가 안 되면, OS 부팅 문제가 아니라 다음을 의심합니다.

네트워크/보안 그룹(NSG) 우선 확인

  • NIC에 연결된 NSG 인바운드 규칙에 22/3389 허용 여부
  • 서브넷 NSG/UDR(사용자 정의 라우트)로 인해 우회/차단되는지
  • Public IP 변경/삭제 여부, Bastion 경유 필요 여부

VM Agent/확장(Extension) 문제

  • VM Agent가 죽어 있으면 Run Command/확장 기능이 실패할 수 있습니다.
  • 이 경우에도 Boot Diagnostics로 “에이전트가 올라오는지” 단서를 얻습니다.

애플리케이션 장애 대응과 동일한 원칙

장애를 네트워크로 단정하고 NSG만 만지다가 시간을 쓰는 경우가 많습니다. 부팅 로그로 OS 레벨 문제를 먼저 배제하면 분기 비용이 줄어듭니다. 이런 ‘가설 축소’는 예를 들어 EKS Pod에서 Kinesis 403 AccessDenied 10분 진단처럼 원인을 빠르게 좁히는 방식과 동일합니다.

6) 재발 방지: Boot Diagnostics를 “항상 켜두기”

장애가 난 뒤에 켜도 되지만, 다음 이유로 평상시 활성화를 추천합니다.

  • 장애 시점에 이미 콘솔 로그가 필요함
  • 원인 추적 시간(Mean Time To Identify)을 크게 단축
  • 팀 내 표준 런북(진단 절차) 작성이 쉬워짐

운영 런북 템플릿(추천)

  • 증상: Running/접속 불가/최근 변경
  • 1차 증거: Boot Diagnostics screenshot/serial log 캡처
  • 1차 조치: Serial Console에서 fstab, 디스크, systemd hang 확인
  • 2차 조치: 복구 VM로 OS 디스크 오프라인 수정
  • 사후: 변경 관리(커널 업데이트/디스크 확장/설정 변경) 기록

7) 빠른 결론: 15분 복구 플로우 요약

  • 0~3분: “부팅 불가”인지 “부팅 후 접속 불가”인지 분류
  • 3~7분: Boot Diagnostics로 스크린샷/시리얼 로그 확보 → 원인 범주 확정
  • 7~12분: Serial Console 가능하면 즉시 응급 조치(fstab, systemd, 간단 설정)
  • 12~15분: 안 되면 OS 디스크 분리 → 복구 VM에 Attach → 오프라인 수정 후 재부팅

부팅 장애는 당황하면 재부팅만 반복하게 되지만, Boot Diagnostics로 부팅 단계의 증거를 먼저 확보하면 복구 시간이 체감적으로 줄어듭니다. 특히 fstab/마운트/파일시스템 계열 이슈는 이 루틴만 익혀도 ‘15분 복구’가 현실적인 목표가 됩니다.

추가로, 장애 대응 전반에서 “재현/관측 → 가설 축소 → 최소 변경”을 습관화하면 인프라뿐 아니라 애플리케이션 장애에서도 효과가 큽니다. 예를 들어 OpenAI API 429 폭탄 대응 실전 가이드 지수 백오프 큐잉 토큰 버짓으로 비용과 지연을 함께 줄이기처럼 ‘원인에 맞는 제어 지점’을 찾는 방식이 결국 같은 문제 해결 패턴입니다.

Discuss on Twitter • View on GitHub