7-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)

  데이터베이스 워크로드 LUN 분리 예시:
  
  ┌──────────────────────────────────────────────────┐
  │  DB 서버                                          │
  │                                                  │
  │  /data    ←── LUN 001 (500GB, Tier 0)            │
  │               데이터 파일. 랜덤 IO 집중           │
  │                                                  │
  │  /log     ←── LUN 002 (100GB, Tier 0)            │
  │               리두 로그. 순차 쓰기 집중           │
  │               데이터와 분리해야 IO 경합 방지       │
  │                                                  │
  │  /temp    ←── LUN 003 (200GB, Tier 1)            │
  │               임시 공간. 중요도 낮음              │
  │                                                  │
  │  /backup  ←── LUN 004 (1TB, Tier 2)              │
  │               로컬 백업. 용량 위주                │
  └──────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│           LUN 분리 vs 통합 비교                           │
├────────────────┬─────────────────┬────────────────────────┤
│                │ LUN 분리 (여러개)│ LUN 통합 (큰 1개)     │
├────────────────┼─────────────────┼────────────────────────┤
│ IO 경합        │ 용도별 격리 가능│ 데이터+로그+백업이     │
│                │ → 로그가 데이터 │ 한 LUN에서 경쟁       │
│                │   IO에 영향 안줌│                        │
├────────────────┼─────────────────┼────────────────────────┤
│ 스냅샷         │ 데이터만 따로   │ 전체를 한꺼번에       │
│                │ 스냅샷 가능     │ → 스냅샷 크기 증가    │
│                │                 │ → 복원 시간 증가      │
├────────────────┼─────────────────┼────────────────────────┤
│ 성능 모니터링  │ "데이터가 느린지│ "이 LUN이 느린데       │
│                │  로그가 느린지" │  뭐가 원인인지" 구분   │
│                │  즉시 구분      │  어려움                │
├────────────────┼─────────────────┼────────────────────────┤
│ 관리 복잡도    │ LUN이 많아짐    │ 단순                   │
│                │ Zoning, Masking │                        │
│                │ 관리 포인트 증가│                        │
├────────────────┼─────────────────┼────────────────────────┤
│ 장애 영향      │ LUN 하나 문제시 │ 하나 문제면 전부       │
│                │ 해당 용도만 영향│ 영향                   │
├────────────────┼─────────────────┼────────────────────────┤
│ 권장           │ 미션 크리티컬 DB│ 개발/테스트 환경       │
│                │ 성능 민감 워크로드│ 단순 파일 서버        │
└────────────────┴─────────────────┴────────────────────────┘

  나쁜 예:
  vol1, vol2, test_new, backup_old, db_temp_2, prod_final_v3
  → 6개월 후 이게 뭔지 아무도 모른다. 만든 사람도 모른다.
  
  좋은 예:
  {환경}_{서비스}_{용도}_{번호}
  
  볼륨:
  prd_erp_data_001    운영 ERP DB 데이터 볼륨 1
  prd_erp_log_001     운영 ERP DB 로그 볼륨 1
  dev_crm_data_001    개발 CRM 데이터 볼륨 1
  
  호스트 그룹:
  hg_prd_erp_db01     운영 ERP DB 서버 1
  
  Zoning Alias:
  srv_prd_erp_db01_hba0  서버 (환경_서비스_호스트_포트)
  stg_netapp01_0a        스토리지 (장비_포트)
  
  규칙:
  ┌──────────────────────────────────────────────────────┐
  │ · 영문 소문자 + 숫자 + 언더스코어만                  │
  │ · 환경(prd/stg/dev) → 서비스명 → 용도 → 일련번호   │
  │ · 팀 전체 합의 + 문서화. 예외 없음.                 │
  │ · "한번만 대충" → 영원히 대충이 된다                │
  └──────────────────────────────────────────────────────┘

  스냅샷 정책 예시 (서비스 등급별):
  
  ┌───────────────────────────────────────────────────────┐
  │ 등급       │ 스냅샷 주기    │ 보관         │ 용량예약 │
  ├────────────┼────────────────┼──────────────┼──────────┤
  │ Gold (DB)  │ 매 1시간       │ 24시간분     │ 20~30%  │
  │            │ + 매일 1회     │ + 7일분      │          │
  │            │ + 매주 1회     │ + 4주분      │          │
  ├────────────┼────────────────┼──────────────┼──────────┤
  │ Silver     │ 매 4시간       │ 24시간분     │ 15~20%  │
  │ (일반 앱)  │ + 매일 1회     │ + 7일분      │          │
  ├────────────┼────────────────┼──────────────┼──────────┤
  │ Bronze     │ 매일 1회       │ 7일분        │ 10~15%  │
  │ (파일서버) │                │              │          │
  └────────────┴────────────────┴──────────────┴──────────┘

  스냅샷 동작 (Copy-on-Write):
  
  [원본 데이터]  블록 A  블록 B  블록 C  블록 D
                  │       │       │       │
  [스냅샷 시점]  ─┴───────┴───────┴───────┴─── 포인터 저장
  
  이후 블록 B가 수정되면:
  1. 기존 블록 B를 스냅샷 영역으로 복사
  2. 원본 위치에 새 블록 B' 기록
  
  → 변경된 블록만 보관. 초기에는 공간을 거의 안 씀.
  → 변경이 많을수록 스냅샷 공간이 커진다.

┌──────────────────────────────────────────────────────────┐
│ 장점                                                      │
│ · 즉시 생성 (수초). 서비스 영향 없음                      │
│ · 즉시 복원 가능. 테라바이트 볼륨도 수 분이면 복원       │
│ · 공간 효율적 (변경된 블록만 저장)                        │
├──────────────────────────────────────────────────────────┤
│ 단점 / 리스크                                             │
│ · 스냅샷은 백업이 아니다. 원본과 같은 스토리지에 있기    │
│   때문에, 스토리지 자체가 죽으면 스냅샷도 같이 사라진다. │
│ · 스냅샷이 수십 개 이상 쌓이면 쓰기 성능 저하            │
│ · 스냅샷 공간 부족 → 볼륨 오프라인 가능 (서비스 중단!)   │
│ · 일부 벤더: 볼륨 삭제 시 스냅샷도 같이 삭제             │
│ · 물리적 재해(화재, 지진)는 못 막음 → DR 복제 병행 필수  │
└──────────────────────────────────────────────────────────┘

  동기 복제 (Synchronous):
  
  [사이트A]                        [사이트B (DR)]
  스토리지 ───── 쓰기 ────────────► 스토리지
             완료 확인 ◄──────────
  
  양쪽 모두 기록 완료되어야 호스트에 응답.
  
  장점: RPO = 0 (데이터 유실 제로)
  단점:
  · 쓰기 레이턴시 증가 (원격 왕복 시간 추가, 1~3ms)
  · 원격 사이트 장애 시 운영 사이트 쓰기도 멈출 수 있음!
    → 타임아웃 후 자동 비동기 전환 기능 확인 필수
  · 대역폭 비용: 쓰기량만큼의 전용 대역폭 필요
  · 거리 제한: 보통 100km 이내
  
  
  비동기 복제 (Asynchronous):
  
  [사이트A]                        [사이트B (DR)]
  스토리지 ───── 쓰기 완료 ──────►
             (바로 호스트에 응답)
                  ···나중에···
             ────── 복제 ────────► 스토리지
  
  장점: 쓰기 성능 영향 없음, 거리 제한 없음
  단점:
  · RPO > 0 — 마지막 복제 이후 데이터 유실 가능
  · 네트워크 부족 시 복제 지연(Lag) 누적 → RPO 초과
  · DR 전환 시 미복제 데이터 유실 감수

  RPO 요구사항 → 복제 방식 매핑:
  
  ┌──────────────┬──────────────────┬──────────┬─────────┐
  │ RPO 요구     │ 복제 방식        │ 비용     │ 복잡도  │
  ├──────────────┼──────────────────┼──────────┼─────────┤
  │ RPO = 0      │ 동기 복제        │ 높음     │ 높음    │
  │              │ + 메트로 클러스터│          │         │
  ├──────────────┼──────────────────┼──────────┼─────────┤
  │ RPO < 15분   │ 빈번한 비동기    │ 중~높    │ 중간    │
  ├──────────────┼──────────────────┼──────────┼─────────┤
  │ RPO < 1시간  │ 비동기 복제      │ 중간     │ 낮음    │
  ├──────────────┼──────────────────┼──────────┼─────────┤
  │ RPO < 24시간 │ 일 1회 백업 복제 │ 낮음     │ 낮음    │
  └──────────────┴──────────────────┴──────────┴─────────┘

  Active-Passive (가장 흔함):
  [사이트A] ════복제════► [사이트B]
  운영 중                  대기
  · 장점: 단순, 데이터 충돌 없음
  · 단점: DR 사이트 자원이 평소에 놀고 있음 (비용 낭비)
  
  Active-Active (메트로 클러스터):
  [사이트A] ◄══양방향══► [사이트B]
  운영 중                  운영 중
  · 장점: 양쪽 모두 활용, RTO 극소화
  · 단점: 매우 복잡, 동기 복제 필수, Split-Brain 리스크
          → Quorum/Tiebreaker 3번째 사이트 필요
  
  3-사이트:
  [사이트A] ──동기──► [사이트B]
      └──비동기──────► [사이트C (원격)]
  · A,B 동시 피해 시에도 C에서 복구 가능
  · 단점: 장비×3, 비용 최고, 운영 복잡도 최고

┌──────────────────────────────────────────────────────────┐
│          스토리지 설계 문서 필수 항목                       │
├──────────────────────────────────────────────────────────┤
│ □ 구성도 (물리/논리 토폴로지, 포트 연결 맵)              │
│ □ 용량 설계 (RAW→실효, Tier별, 3~5년 성장)              │
│ □ 성능 설계 (워크로드 프로파일, IOPS/Latency 목표)      │
│ □ 이중화 설계 (듀얼 Fabric/VLAN, 멀티패스, 장애 시나리오)│
│ □ 데이터 보호 (RAID, 스냅샷, 복제/DR, DR 전환 절차서)   │
│ □ 네이밍 컨벤션 (볼륨, 호스트 그룹, Zoning Alias)       │
│ □ 보안 (RBAC, 암호화, 관리 네트워크 격리)               │
│ □ 운영 기준 (모니터링 임계치, 알림, 백업 연동, 변경 관리)│
└──────────────────────────────────────────────────────────┘