15. 장애 대응 — 스토리지 트러블슈팅 실전

  장애 시 행동 순서:
  
  ① 상황 파악     "뭐가 어떻게 됐는가?"
       │            알람 내용, 영향 범위, 시작 시각
       ▼
  ② 영향 확인     "서비스에 영향이 있는가?"
       │            IO 중단 여부, 성능 저하 여부
       ▼
  ③ 1차 대응      "당장 할 수 있는 건?"
       │            경로 전환, 페일오버 확인, 서비스 정상화
       ▼
  ④ 원인 분석     "왜 이렇게 됐는가?"
       │            로그 분석, 벤더 서포트 콜
       ▼
  ⑤ 근본 조치     "재발을 막으려면?"
       │            부품 교체, 설정 변경, 펌웨어 패치
       ▼
  ⑥ 후속 조치     "기록과 개선"
                    RCA 작성, 재발 방지 대책
  
  핵심: ②와 ③이 먼저다.
  원인 분석(④)은 서비스가 정상화된 후에 해도 된다.
  새벽 3시에 "왜 이런 거지?"를 고민하느라 서비스 복구가 늦어지면 안 된다.

  단일 디스크 장애:
  
  알람: "Disk 0a.01.5 failed"
       │
       ▼
  확인: RAID 상태
  · RAID Degraded 상태인가?
  · Hot Spare가 자동으로 투입됐는가?
  · 리빌드가 시작됐는가?
       │
       ├── Hot Spare 투입 + 리빌드 시작됨 → 정상 동작
       │   서비스 영향 없음 (올플래시: 레이턴시 미세 증가)
       │   → 벤더에 디스크 교체 요청 (SR 오픈)
       │   → 리빌드 완료 후 교체 디스크를 새 Hot Spare로
       │
       └── Hot Spare 없음 → 주의!
           RAID는 Degraded 상태. 추가 디스크 장애 시 데이터 유실 위험.
           → 벤더에 긴급(Sev1) 교체 요청
           → 리빌드 완료까지 모니터링 강화
  
  서비스 영향:
  ┌──────────────────────────────────────────────────────┐
  │ 올플래시 + 분산 RAID (Dell ADAPT, Pure 등):          │
  │   리빌드가 전체 디스크에 분산. 영향 미미.            │
  │   레이턴시 5~15% 증가 정도.                         │
  │                                                      │
  │ 전통 RAID + HDD:                                     │
  │   리빌드 시간 수시간~수일. 리빌드 중 성능 저하 큼.   │
  │   레이턴시 2~5배 증가 가능.                          │
  │   → 리빌드 중에는 배치 작업을 미루는 게 좋다.       │
  └──────────────────────────────────────────────────────┘

  이중 디스크 장애 (RAID 5에서 2번째 디스크 장애):
  
  이건 비상 상황이다.
  
  RAID 5: 디스크 1개 장애 허용. 2개째 나가면 데이터 유실.
  RAID 6 / RAID-DP / RAID-TEC: 2~3개까지 허용. 여유 있음.
  분산 RAID (Dell ADAPT, Pure): 내부적으로 이중 패리티 이상.
  
  ┌──────────────────────────────────────────────────────┐
  │ RAID 5에서 리빌드 중 2번째 장애:                      │
  │ → 데이터 유실. 복구 불가.                            │
  │ → 백업에서 복원해야 한다.                            │
  │ → 이게 5편에서 "RAID 5가 위험하다"고 한 이유.        │
  │                                                      │
  │ RAID 6 / RAID-DP에서 리빌드 중 2번째 장애:           │
  │ → 아직 버틸 수 있다. 하지만 3번째가 나가면 끝.      │
  │ → 벤더에 최우선(Sev1) 요청. 즉시 교체.              │
  └──────────────────────────────────────────────────────┘

  컨트롤러 장애 발생:
  
  알람: "Controller A offline" / "Storage failover takeover"
       │
       ▼
  자동 페일오버가 됐는가?
       │
       ├── Yes → Controller B가 인수
       │   · IO 중단 시간 확인 (수초~수십초)
       │   · 서비스 영향 확인 (DB 타임아웃 발생 여부)
       │   · multipath -ll에서 경로 상태 확인
       │   · 벤더에 SR 오픈
       │   · Controller A 원인 분석 (벤더와 함께)
       │   · 복구 후 Giveback 실행
       │
       └── No → 수동 대응 필요!
           · HA Interconnect가 끊어져 있을 수 있음
           · 수동 Takeover 시도
           · 안 되면 벤더 긴급 콜
  
  페일오버 후 주의사항:
  ┌──────────────────────────────────────────────────────┐
  │ · 페일오버 상태에서는 성능이 떨어진다.                │
  │   Controller B가 자기 볼륨 + A의 볼륨을 다 처리.    │
  │   CPU/캐시 부하가 2배. 평소 대비 레이턴시 증가.      │
  │                                                      │
  │ · 페일오버 상태에서 추가 장애가 나면 더 위험하다.     │
  │   Controller B도 죽으면 전체 IO 중단.                │
  │   → 페일오버 상태를 오래 유지하지 않는다.            │
  │     원인 해결 후 빨리 Giveback.                      │
  │                                                      │
  │ · Giveback(원복) 시에도 순간 IO 영향이 있을 수 있다. │
  │   NDG(Non-Disruptive Giveback)를 지원하는지 확인.    │
  └──────────────────────────────────────────────────────┘

  FC 경로 단절:
  
  알람: "FC link down on port 0a" / multipath에서 faulty
       │
       ▼
  몇 개 경로가 끊겼는가?
       │
       ├── 1~2개 (4개 중) → 서비스 영향 없음 (멀티패스 동작)
       │   · multipath -ll로 상태 확인
       │   · 끊긴 경로 원인: 케이블? Switch 포트? SFP?
       │   · FC Switch에서 해당 포트 로그 확인
       │   · 물리적으로 케이블/SFP 점검
       │   · 교체 후 경로 자동 복구 확인
       │
       └── 전체 경로 단절 → 서비스 중단!
           · 모든 IO가 멈춤. 즉시 대응.
           · 원인: Switch 전체 장애? 스토리지 포트 전체 장애?
           · 두 Fabric이 동시에 죽었으면 → PDU/전원 문제?
           · 호스트에서 no_path_retry 설정에 따라
             IO가 큐에 쌓이거나(queue) 에러를 리턴(fail)
           · 경로 복구 후 IO 자동 재개 확인
  
  iSCSI 경로 단절:
  
  · FC보다 감지가 느리다 (TCP 타임아웃 의존)
  · ping으로 네트워크 연결 확인
  · iscsiadm -m session으로 세션 상태 확인
  · MTU 불일치가 간헐적 단절의 원인인 경우가 있다
    → ping -M do -s 8972 <target_ip>로 Jumbo Frame 확인

  "스토리지가 갑자기 느려졌어요"
       │
       ▼
  11편의 성능 병목 분석 흐름을 따른다:
  호스트 → 네트워크 → 컨트롤러 → 디스크
  
  장애 상황에서 추가로 확인할 것:
  ┌──────────────────────────────────────────────────────┐
  │ · 페일오버 중인가?                                    │
  │   한쪽 컨트롤러가 양쪽 볼륨을 다 처리하면 느려진다.  │
  │                                                      │
  │ · RAID 리빌드 중인가?                                 │
  │   리빌드 IO가 서비스 IO와 경합.                      │
  │                                                      │
  │ · 특정 볼륨이 IO를 독점하고 있는가? (Noisy Neighbor) │
  │   QoS로 상한을 걸어야 한다 (11편 참고).              │
  │                                                      │
  │ · 씬 프로비저닝 공간이 부족한가?                      │
  │   물리 공간 90% 이상이면 성능 저하가 발생할 수 있다.  │
  │   컨트롤러가 공간 확보를 위해 내부 작업을 하면서 느려짐│
  │                                                      │
  │ · 백업/복제가 동시에 돌고 있는가?                     │
  │   야간 백업이 아침까지 밀려서 서비스와 겹치는 경우.   │
  └──────────────────────────────────────────────────────┘

  "DB가 멈췄어요. 쓰기가 안 돼요."
       │
       ▼
  볼륨 상태 확인
       │
       ├── 볼륨 오프라인 → 왜?
       │   · 씬 프로비저닝 물리 공간 소진 (12편)
       │   · 스냅샷 공간 초과
       │   · 컨트롤러 장애
       │   · LUN Masking 변경 실수
       │
       └── 볼륨 온라인인데 쓰기 안 됨 → 왜?
           · 파일시스템 Full (호스트 측)
           · Read-Only로 변경됨 (파일시스템 에러)
           · 스토리지 측 볼륨 Full (씬 프로비저닝)
  
  공간 부족 긴급 대응 (11편에서 상세히 다뤘지만 여기서 재정리):
  ┌──────────────────────────────────────────────────────┐
  │ 즉시 할 수 있는 것 (시간 벌기):                       │
  │ 1. 오래된 스냅샷 삭제 → 공간 회수                    │
  │ 2. 미사용 볼륨 오프라인 → 공간 확보                  │
  │ 3. UNMAP/TRIM 실행 → 호스트가 삭제한 공간 회수       │
  │ 4. QoS로 쓰기 속도 제한 → 급격한 증가 억제           │
  │                                                      │
  │ 근본 해결:                                           │
  │ · 디스크/쉘프 증설                                   │
  │ · 데이터 이전 (다른 스토리지로)                       │
  │ · 아카이빙 (오래된 데이터를 저비용 매체로 이동)       │
  └──────────────────────────────────────────────────────┘

  서포트 콜 전에 준비할 것:
  
  ┌──────────────────────────────────────────────────────┐
  │ 기본 정보:                                            │
  │ · 장비 모델, 시리얼, 펌웨어 버전                      │
  │ · 유지보수 계약 번호                                  │
  │ · 장애 발생 시각 (정확히)                              │
  │ · 장애 증상 (에러 메시지, 알람 내용)                   │
  │ · 서비스 영향 여부와 범위                              │
  │                                                      │
  │ 로그:                                                │
  │ · 스토리지 이벤트 로그 (최근 24시간)                   │
  │ · AutoSupport / Call Home 데이터                      │
  │   (벤더가 원격으로 받을 수 있으면 가장 빠름)          │
  │ · 호스트 측: /var/log/messages, dmesg, multipath -ll  │
  │ · FC Switch: errshow, porterrshow                    │
  │                                                      │
  │ 벤더별 로그 수집:                                     │
  │ NetApp: autosupport invoke -node * -type all         │
  │ Dell:   서포트 어시스트 자동 수집 또는 GUI에서 다운로드│
  │ Pure:   phonehome 자동 전송 (기본)                   │
  │ HPE:    InfoSight 연동 또는 수동 로그 번들            │
  └──────────────────────────────────────────────────────┘

  ┌──────────┬────────────────────────┬──────────────────┐
  │ 심각도   │ 상황                    │ 벤더 대응        │
  ├──────────┼────────────────────────┼──────────────────┤
  │ Sev 1    │ 서비스 중단.            │ 24x7 즉시 대응. │
  │ (긴급)   │ 데이터 유실 위험.       │ 4시간 현장 대응. │
  │          │ 우회 방법 없음.         │                  │
  ├──────────┼────────────────────────┼──────────────────┤
  │ Sev 2    │ 서비스 성능 심각 저하.  │ 4시간 내 원격    │
  │ (높음)   │ 이중화 Degraded.        │ 대응 시작.       │
  │          │ 우회 가능하지만 불안정. │                  │
  ├──────────┼────────────────────────┼──────────────────┤
  │ Sev 3    │ 기능 일부 문제.         │ 익일 대응.       │
  │ (보통)   │ 서비스 영향 없음.       │ 이메일/전화.     │
  ├──────────┼────────────────────────┼──────────────────┤
  │ Sev 4    │ 문의, 정보 요청.        │ 일반 대응.       │
  │ (낮음)   │                        │                  │
  └──────────┴────────────────────────┴──────────────────┘
  
  Sev를 낮게 잡으면 대응이 느려진다.
  서비스 중단인데 Sev 3으로 열면 "내일 연락드리겠습니다."
  서비스 중단이면 반드시 Sev 1. 과장할 필요 없지만 축소도 안 된다.
  
  벤더 대응이 느릴 때:
  ┌──────────────────────────────────────────────────────┐
  │ · 에스컬레이션 요청: "매니저와 통화하겠다."          │
  │ · 계약서의 SLA를 근거로 대응 시간 요구.             │
  │ · 영업 담당에게 동시에 연락. 영업 채널이 기술 지원   │
  │   에스컬레이션에 효과적인 경우가 있다.               │
  │ · 로그를 최대한 수집해서 먼저 보내둔다. 벤더가      │
  │   "로그 보내주세요"로 시간을 끄는 걸 방지.           │
  └──────────────────────────────────────────────────────┘

  펌웨어 업그레이드 절차:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 업그레이드 매트릭스 확인                           │
  │    현재 버전 → 목표 버전으로 직접 업그레이드 가능?   │
  │    중간 버전을 거쳐야 하는 경우가 있다.              │
  │    (예: 9.8 → 9.12 직접 불가. 9.8 → 9.10 → 9.12)  │
  │                                                      │
  │ 2. 호환 매트릭스 재확인                               │
  │    목표 펌웨어와 호스트 OS/HBA 드라이버 호환?        │
  │    호환 안 되면 호스트 업데이트를 먼저 해야 할 수 있음│
  │                                                      │
  │ 3. 릴리스 노트 확인                                   │
  │    알려진 이슈(Known Issues) 확인. 우리 환경에        │
  │    해당하는 버그가 있는지.                            │
  │                                                      │
  │ 4. 사전 건강 체크                                     │
  │    · HA 상태 정상?                                   │
  │    · RAID 상태 정상? (Degraded면 업그레이드 금지)     │
  │    · 디스크 장애 없는가?                              │
  │    · 페일오버 가능 상태인가?                          │
  │    · 충분한 여유 공간 (펌웨어 이미지 저장용)?        │
  │                                                      │
  │ 5. 백업/스냅샷                                        │
  │    설정 백업 (스토리지 구성 export)                   │
  │    중요 볼륨 스냅샷                                  │
  │                                                      │
  │ 6. 업그레이드 실행 (NDU)                              │
  │    보통 Controller A 업그레이드 → 페일오버 → 복구    │
  │    → Controller B 업그레이드 → 페일오버 → 복구      │
  │    전체 소요: 30분~2시간 (벤더/버전에 따라)          │
  │                                                      │
  │ 7. 업그레이드 후 확인                                 │
  │    · 펌웨어 버전 확인                                │
  │    · HA/RAID 상태 정상                               │
  │    · 모든 서비스 IO 정상                             │
  │    · 모니터링 알람 없는지                             │
  └──────────────────────────────────────────────────────┘
  
  NDU의 장단점:
  ┌──────────────────────────────────────────────────────┐
  │ 장점: 서비스 중단 없이 업그레이드 가능.               │
  │                                                      │
  │ 단점/리스크:                                          │
  │ · "Non-Disruptive"가 "Zero-Impact"는 아니다.         │
  │   페일오버/Giveback 과정에서 순간 레이턴시 증가.     │
  │   민감한 DB에서 체감할 수 있다.                      │
  │                                                      │
  │ · 업그레이드 중 추가 장애가 나면 대응이 복잡해진다.  │
  │   한쪽 컨트롤러가 업그레이드 중인데 다른 쪽도 문제?  │
  │   → 업그레이드 시간대에 다른 변경 작업을 금지한다.   │
  │                                                      │
  │ · 롤백이 안 되는 경우가 있다.                        │
  │   일부 벤더/버전에서 다운그레이드 불가.              │
  │   → 업그레이드 전에 "롤백 가능한가?" 벤더에 확인.   │
  │   → 불가능하면 그 사실을 승인권자에게 고지.          │
  └──────────────────────────────────────────────────────┘

  사례 1: 케이블 한 가닥 때문에
  
  ┌──────────────────────────────────────────────────────┐
  │ 상황: 데이터센터 정리 작업 중 FC 케이블 1개를         │
  │       실수로 뽑음. Fabric A의 경로가 끊김.           │
  │                                                      │
  │ 영향: 멀티패스가 동작해서 서비스 영향은 없었음.       │
  │       하지만 이 상태에서 Fabric B마저 문제가 생기면   │
  │       전체 IO 중단이었음.                            │
  │                                                      │
  │ 발견: 2주 뒤 모니터링 점검에서 "경로 1개 degraded"    │
  │       를 발견. 그 사이 이중화가 깨진 채로 운영.      │
  │                                                      │
  │ 교훈:                                                │
  │ · 경로 장애 알람이 즉시 오도록 설정해야 한다.        │
  │ · "이중화니까 괜찮아"가 아니라 "이중화가 깨졌으니    │
  │   빨리 복구해야"가 맞는 대응이다.                    │
  │ · 케이블에 라벨이 없어서 어떤 케이블인지 찾는 데     │
  │   1시간 걸렸다. 라벨링의 중요성 (8편 참고).          │
  └──────────────────────────────────────────────────────┘
  
  사례 2: 펌웨어 버그로 인한 데이터 정합성 문제
  
  ┌──────────────────────────────────────────────────────┐
  │ 상황: 특정 펌웨어 버전에서 드물게 발생하는            │
  │       Silent Data Corruption 버그.                   │
  │       데이터가 깨졌는데 에러가 안 나옴.               │
  │                                                      │
  │ 발견: DB 체크섬 검증에서 불일치 발견.                 │
  │                                                      │
  │ 교훈:                                                │
  │ · 벤더 보안 권고(Security Advisory)를 정기 확인.     │
  │ · AutoSupport/Call Home를 켜놓으면 벤더가 먼저       │
  │   "이 버전에 알려진 이슈가 있으니 업그레이드하세요"  │
  │   라고 알려준다.                                     │
  │ · 체크섬(Data at Rest integrity)이 있는 파일시스템   │
  │   (ZFS, ONTAP WAFL)이 이런 문제를 잡아줄 수 있다.  │
  └──────────────────────────────────────────────────────┘
  
  사례 3: 리빌드 중 두 번째 디스크 장애
  
  ┌──────────────────────────────────────────────────────┐
  │ 상황: HDD 환경. RAID 5 구성. 디스크 1개 장애 후      │
  │       리빌드 중(36시간째)에 두 번째 디스크 장애.     │
  │                                                      │
  │ 결과: RAID 그룹 전체 데이터 유실. 백업에서 복원.     │
  │       복원에 18시간. 총 서비스 중단 20시간+.          │
  │                                                      │
  │ 교훈:                                                │
  │ · 대용량 HDD에서 RAID 5는 위험하다 (5편).            │
  │ · RAID 6 / RAID-DP / RAID-TEC를 써야 한다.          │
  │ · 올플래시로 전환하면 리빌드 시간이 수 분으로 줄어든다│
  │ · 백업이 없었으면 데이터를 완전히 잃을 뻔했다.       │
  └──────────────────────────────────────────────────────┘

  RCA 보고서 구조:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 개요                                              │
  │    장애 일시, 영향 범위, 서비스 중단 시간              │
  │                                                      │
  │ 2. 타임라인                                           │
  │    장애 발생 → 감지 → 1차 대응 → 원인 파악 → 복구   │
  │    각 단계의 시각과 소요 시간                          │
  │                                                      │
  │ 3. 근본 원인 (Root Cause)                             │
  │    "왜 이 장애가 발생했는가?"                         │
  │    직접 원인 + 근본 원인 구분                          │
  │    (직접: 디스크 장애, 근본: RAID 5 구성 + 대용량 HDD)│
  │                                                      │
  │ 4. 대응 과정                                          │
  │    뭘 했고, 뭐가 효과가 있었고, 뭐가 안 됐는지        │
  │                                                      │
  │ 5. 재발 방지 대책                                     │
  │    · 단기: 즉시 적용 (모니터링 임계치 조정 등)       │
  │    · 중기: 계획 수립 (RAID 레벨 변경, 증설 등)       │
  │    · 장기: 구조 개선 (장비 교체, 아키텍처 변경 등)   │
  │                                                      │
  │ 6. 담당자 / 이행 기한                                 │
  │    대책별 담당자와 완료 기한을 명시.                   │
  │    기한 없는 대책은 안 한다.                          │
  └──────────────────────────────────────────────────────┘
  
  장애 이력을 기록해두면 패턴이 보인다.
  "매달 같은 디스크 쉘프에서 장애가 난다" → 환경 문제(열, 진동)?
  "특정 벤더 펌웨어에서만 이 에러가 난다" → 벤더에 보고.
  장애 이력 DB(스프레드시트라도)를 유지하면 장기적으로 큰 도움이 된다.