10. 일상 운영 1: 볼륨 할당과 변경 관리

  볼륨 할당 워크플로우:
  
  요청자 (서버팀/DBA)          스토리지팀
  ──────────────────          ──────────
  
  ① 요청 접수
     ITSM 티켓 생성 ─────────► 티켓 확인
     (ServiceNow, Jira 등)     │
                                ▼
  ② 요청 검토                  용도/용량/프로토콜 확인
                               용량 여유 확인
                               네이밍 규칙에 따라 이름 결정
                                │
                                ▼
  ③ 승인                       변경 위험도에 따라
                               · Low → 팀 내 승인
                               · Medium → 팀장 승인
                                │
                                ▼
  ④ 프로비저닝                 스토리지에서 볼륨 생성
                               LUN Masking / Export 설정
                                │
                                ▼
  ⑤ 호스트 연결                Zoning 추가 (FC)
                               또는 이니시에이터 등록 (iSCSI)
                               또는 Export Policy 설정 (NFS)
                                │
                                ▼
  ⑥ 검증                      요청자 측 마운트 확인
     마운트 확인 ◄──────────── IO 테스트 확인
     "잘 되네요" ──────────────► │
                                ▼
  ⑦ 완료                      볼륨 할당 대장 업데이트
                               ITSM 티켓 종료

  프로세스를 안 지키면 벌어지는 일:
  
  ┌──────────────────────────────────────────────────────┐
  │ "티켓 없이 구두로 요청받고 만들어줌"                   │
  │ → 6개월 뒤 이 볼륨의 용도를 아무도 모름               │
  │ → 삭제해도 되는지 판단 불가 → 고아 볼륨으로 용량 낭비 │
  │                                                      │
  │ "요청서에 호스트 WWPN을 안 받고 대충 매핑"            │
  │ → 다른 서버의 WWPN에 매핑 → 그 서버가 mkfs 실행      │
  │ → 기존 데이터 날아감. 복구 불가.                      │
  │                                                      │
  │ "용량 여유 확인 안 하고 프로비저닝"                    │
  │ → 씬 프로비저닝 환경에서 물리 용량 초과 상태에서 할당 │
  │ → 실제 쓰기 시 다른 볼륨까지 오프라인. 서비스 장애.   │
  │                                                      │
  │ "검증 단계 건너뛰고 '만들었습니다' 회신"              │
  │ → 서버에서 마운트 안 됨 (Zoning 누락, OS Type 오류)   │
  │ → 서버팀 "안 되는데요?" → 다시 처음부터. 시간 낭비.   │
  └──────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│              볼륨 할당 요청서 필수 항목                     │
├────────────────┬─────────────────────────────────────────┤
│ 용도           │ 어떤 서비스/애플리케이션에 사용하는지     │
│                │ (예: ERP DB 데이터, 웹서버 로그)          │
├────────────────┼─────────────────────────────────────────┤
│ 용량           │ 초기 할당 용량 + 예상 월간 증가율        │
├────────────────┼─────────────────────────────────────────┤
│ 성능 등급      │ Gold/Silver/Bronze (서비스 카탈로그 기준) │
│ (Tier)         │ 또는 필요 IOPS/Latency 수치             │
├────────────────┼─────────────────────────────────────────┤
│ 프로토콜       │ FC / iSCSI / NFS / SMB                  │
├────────────────┼─────────────────────────────────────────┤
│ 호스트 정보    │ 호스트명, OS 종류/버전                   │
│                │ FC: WWPN / iSCSI: IQN / NFS: IP         │
├────────────────┼─────────────────────────────────────────┤
│ 마운트 포인트  │ /data/erp, /backup/weekly 등             │
├────────────────┼─────────────────────────────────────────┤
│ 스냅샷 정책    │ 필요 여부, 주기, 보관 기간               │
├────────────────┼─────────────────────────────────────────┤
│ 백업 정책      │ 백업 대상 여부, 백업 윈도우              │
├────────────────┼─────────────────────────────────────────┤
│ 서비스 중요도  │ 미션 크리티컬 / 일반 / 개발·테스트       │
├────────────────┼─────────────────────────────────────────┤
│ 요청자/승인자  │ 누가 요청했고 누가 승인했는지            │
└────────────────┴─────────────────────────────────────────┘

  벤더별 볼륨 생성 구조 비교:
 
  [NetApp ONTAP]
  ┌───────────────────────────────────────────┐
  │ Cluster                                   │
  │  └─ SVM (Storage Virtual Machine)         │
  │      └─ Volume                            │
  │          └─ LUN (블록) 또는               │
  │             NFS Export (파일)              │
  │                                           │
  │ 계층이 깊다. SVM이라는 가상 서버 개념이   │
  │ 있어서 멀티테넌시에 강하지만, 초기 학습    │
  │ 곡선이 높다. Volume과 LUN이 분리되어      │
  │ 있어서 LUN 크기를 Volume보다 크게 만드는  │
  │ 실수를 할 수 있다.                        │
  └───────────────────────────────────────────┘
 
  [Dell PowerStore]
  ┌───────────────────────────────────────────┐
  │ Appliance                                 │
  │  └─ Volume (블록) 또는                    │
  │     NAS Server → File System (파일)       │
  │                                           │
  │ ONTAP보다 단순하다. 볼륨을 바로 만들고    │
  │ 호스트에 매핑하면 된다. 단, NAS 기능은    │
  │ 별도 NAS Server를 먼저 생성해야 해서      │
  │ NAS 위주 환경에서는 한 단계 더 있다.      │
  └───────────────────────────────────────────┘
 
  [Pure Storage FlashArray]
  ┌───────────────────────────────────────────┐
  │ Array                                     │
  │  └─ Volume ──── Host/Host Group에 연결    │
  │                                           │
  │ 가장 단순하다. 볼륨 만들고 호스트에 연결   │
  │ 하면 끝. RAID 레벨, 애그리게이트 같은      │
  │ 하위 개념을 숨긴다. 단순함이 장점이지만,  │
  │ 세밀한 배치 제어(특정 디스크 그룹에 볼륨을 │
  │ 고정하는 등)는 불가능하다.                 │
  └───────────────────────────────────────────┘

  ┌──────────────────────────────────────────────────────────┐
  │ NetApp 실수: LUN 크기 > Volume 크기                      │
  │   Volume이 1TB인데 LUN을 1TB로 만들면?                   │
  │   → Volume 안에 메타데이터 공간이 필요해서 LUN이 꽉 차면 │
  │     Volume이 먼저 가득 찬다. 쓰기 실패.                  │
  │   → LUN은 Volume의 90% 이하로 만드는 게 안전.           │
  │                                                          │
  │ NetApp 실수: SVM을 잘못 선택                              │
  │   운영용 SVM에 개발 볼륨을 만들어버리면?                  │
  │   → 나중에 QoS 정책이 다 섞이고, Export Policy도 꼬인다.│
  │   → 볼륨 이동(vol move)으로 수정 가능하지만 번거롭다.   │
  │                                                          │
  │ 공통 실수: OS Type 잘못 설정                              │
  │   Linux 호스트인데 Windows로 설정하면?                    │
  │   → LUN이 보이긴 하지만 사이즈가 다르게 보이거나,       │
  │     ALUA가 오동작해서 성능이 떨어진다.                   │
  │   → 만든 뒤에 OS Type을 바꾸려면 LUN을 지우고           │
  │     다시 만들어야 하는 벤더도 있다.                      │
  │                                                          │
  │ 공통 실수: 씬 프로비저닝 물리 용량 미확인                 │
  │   논리 용량만 보고 "아직 여유 있네" 하고 계속 만들면     │
  │   물리 공간이 바닥나서 기존 볼륨까지 오프라인된다.       │
  │   → 프로비저닝 전에 물리 사용률을 반드시 확인.          │
  └──────────────────────────────────────────────────────────┘

  볼륨 확장 절차 (블록/LUN 기준):
  
  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
  │ 1. 스토리지  │───►│ 2. 호스트    │───►│ 3. 파일      │
  │    LUN 확장  │    │    디스크    │    │    시스템     │
  │              │    │    리스캔    │    │    확장      │
  └──────────────┘    └──────────────┘    └──────────────┘
  
  Step 1: 스토리지 측 LUN 확장
  (벤더 CLI/GUI에서 크기 변경)
  
  Step 2: 호스트에서 디스크 크기 인식
  $ echo 1 > /sys/block/sda/device/rescan    # 단일 디스크
  $ multipathd resize map <mpath_name>        # 멀티패스
  
  Step 3: 파일시스템 확장
  $ xfs_growfs /data/erp                      # XFS (마운트 상태에서)
  $ resize2fs /dev/mapper/mpath0              # ext4
  
  LVM을 쓰고 있다면:
  $ pvresize /dev/mapper/mpath0               # PV 확장
  $ lvextend -l +100%FREE /dev/vg01/lv_data   # LV 확장  
  $ xfs_growfs /data/erp                      # FS 확장
  
  주의사항:
  ┌─────────────────────────────────────────────────────┐
  │ · Step 2를 빼먹으면 호스트가 옛날 크기로 인식한다.  │
  │   "확장했는데 안 늘었어요"의 원인 90%가 이거다.     │
  │                                                     │
  │ · XFS는 축소가 불가능하다. 한번 늘리면 줄일 수 없다.│
  │   "500GB인데 200GB로 줄여주세요" → XFS면 불가.      │
  │   새 볼륨 만들고 데이터 이전해야 한다.              │
  │                                                     │
  │ · 씬 프로비저닝 환경에서 논리 크기만 늘리면 물리    │
  │   용량은 안 늘어난다. 실제 쓰기 시점에 물리 공간이  │
  │   할당되므로, 전체 물리 용량 여유를 반드시 확인.     │
  └─────────────────────────────────────────────────────┘

  볼륨 삭제 안전 절차:
  
  "삭제해 주세요" 요청 접수
         │
         ▼
  ① 요청자 재확인
     "정말 삭제해도 되는 볼륨이 맞나요?"
     → 볼륨명, 마운트 포인트, 서비스명 교차 확인
         │
         ▼
  ② 현재 사용 여부 확인
     · 호스트에서 마운트 해제되었는지
     · IO가 발생하고 있지 않은지 (스토리지 모니터링)
     · 최근 7일간 IO 히스토리 확인
         │
         ▼
  ③ 스냅샷/백업 확인
     · 삭제 전 최종 스냅샷 생성
     · 또는 삭제 대기 기간 설정 (7~30일 후 최종 삭제)
         │
         ▼
  ④ 삭제 실행
     · 즉시 삭제 대신 "오프라인" 처리 후 대기
     · 대기 기간 경과 후 최종 삭제
         │
         ▼
  ⑤ 문서 업데이트
     · 볼륨 할당 대장에서 삭제 기록
     · Zoning/LUN Masking 정리
 
  리스크:
  ┌─────────────────────────────────────────────────────┐
  │ · 잘못된 볼륨을 삭제하면 데이터 복구가 불가능하다.  │
  │   스냅샷이 있어도 볼륨 자체를 삭제하면 스냅샷도     │
  │   같이 사라지는 벤더가 있다.                        │
  │                                                     │
  │ · "오프라인 후 대기" 방식을 권장하는 이유:          │
  │   삭제 후 "사실 아직 쓰고 있었어요"가 올 수 있다.   │
  │   대기 기간이 보험이다.                             │
  │                                                     │
  │ · 실수 방지 팁: 삭제 CLI 실행 전에 "읽기 전용"으로  │
  │   변경해서 IO 에러가 발생하는지 확인. 에러가 나면   │
  │   아직 쓰고 있다는 뜻이다.                          │
  └─────────────────────────────────────────────────────┘

  스토리지 변경 작업 위험도 분류:
  
  ┌─────────┬─────────────────────────┬──────────────────┐
  │ 위험도  │ 작업 예시                │ 승인/절차         │
  ├─────────┼─────────────────────────┼──────────────────┤
  │ Low     │ · 볼륨 신규 생성         │ 팀 내 승인       │
  │         │ · 모니터링 임계치 변경   │ 작업 기록만      │
  │         │ · 스냅샷 정책 추가       │                  │
  ├─────────┼─────────────────────────┼──────────────────┤
  │ Medium  │ · 볼륨 확장              │ 팀장 승인        │
  │         │ · QoS 정책 변경          │ 작업 전후        │
  │         │ · Zoning 추가/변경       │ 체크리스트 필수  │
  │         │ · 스냅샷 정책 변경       │                  │
  ├─────────┼─────────────────────────┼──────────────────┤
  │ High    │ · 펌웨어 업그레이드      │ CAB 승인 필요    │
  │         │ · 컨트롤러 페일오버 작업 │ 야간/주말 작업   │
  │         │ · DR 복제 방향 전환      │ 롤백 계획 필수   │
  │         │ · 볼륨 삭제 (프로덕션)   │ 서비스팀 공지    │
  ├─────────┼─────────────────────────┼──────────────────┤
  │Emergency│ · 장애 복구              │ 사후 승인 가능   │
  │         │ · 긴급 용량 확보         │ 즉시 실행 후     │
  │         │ · 장애 볼륨 오프라인     │ 사후 보고        │
  └─────────┴─────────────────────────┴──────────────────┘
  
  변경 요청서(RFC)에 반드시 포함할 것:
  ┌──────────────────────────────────────────────┐
  │ · 작업 내용 (무엇을, 어디에)                  │
  │ · 영향 범위 (어떤 서비스/서버에 영향)          │
  │ · 작업 윈도우 (언제, 얼마나 걸리는지)          │
  │ · 롤백 계획 (실패 시 어떻게 원복하는지)        │
  │ · 작업 전 체크리스트                           │
  │ · 작업 후 확인 항목                            │
  └──────────────────────────────────────────────┘

  실수로 잘못된 호스트에 LUN을 매핑하면:
  
  [정상 상태]
  서버A (ERP DB) ←── LUN 001 (ERP 데이터)
  서버B (새 서버)     매핑 없음
  
  [실수: 서버B에도 LUN 001을 매핑]
  서버A (ERP DB) ←── LUN 001 ──► 서버B (새 서버)
  
  서버B가 이 LUN을 인식하고, 
  "초기화 안 된 디스크네" 하고 mkfs를 실행하면?
  → ERP 데이터 전체가 날아간다.
  
  방지책:
  ┌─────────────────────────────────────────────────────┐
  │ · LUN Masking을 Host Group 단위로 관리. 개별 호스트 │
  │   단위로 매핑하면 실수 확률이 높아진다.             │
  │                                                     │
  │ · Zoning 변경 시 반드시 "변경 전 상태"를 백업.      │
  │   FC Switch의 zoneshow 결과를 저장해둔다.           │
  │                                                     │
  │ · LUN을 매핑한 후, 서버 측에서 "이 디스크에 이미    │
  │   데이터가 있는지" 확인 후 포맷한다. 절대 무조건    │
  │   mkfs부터 하지 않는다.                             │
  │                                                     │
  │ · 가능하면 LUN에 Read-Only 속성을 먼저 매핑하고,    │
  │   확인 후 Read-Write로 변경하는 습관.               │
  └─────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│              스토리지 서비스 카탈로그 예시                   │
├────────┬──────────┬──────────┬───────────┬───────────────┤
│ 등급   │ 성능목표  │ 스냅샷   │ DR 복제   │ 대상 워크로드 │
├────────┼──────────┼──────────┼───────────┼───────────────┤
│ Gold   │ <1ms     │ 매시간   │ 동기 복제 │ 미션 크리티컬 │
│        │ 올플래시 │ + 일일   │           │ DB            │
├────────┼──────────┼──────────┼───────────┼───────────────┤
│ Silver │ <5ms     │ 4시간    │ 비동기    │ 일반 앱서버   │
│        │ 올플래시 │ + 일일   │ (15분 RPO)│ 가상화        │
├────────┼──────────┼──────────┼───────────┼───────────────┤
│ Bronze │ <10ms    │ 일일     │ 없음      │ 개발/테스트   │
│        │ QLC/하이 │          │ (백업만)  │ 파일 서버     │
│        │ 브리드   │          │           │               │
└────────┴──────────┴──────────┴───────────┴───────────────┘
 
  장점: 요청자가 "Gold 등급 500GB" 하나만 말하면 됨.
        스토리지팀도 기준이 명확해서 판단이 빠름.
  
  단점: 서비스 카탈로그를 만들고 유지하는 데 초기 공수가 든다.
        워크로드가 등급에 딱 안 맞는 경우가 있어서 예외 처리가
        필요하다. 등급이 너무 많으면 복잡해지고, 너무 적으면
        세밀한 제어가 안 된다. 3~4개가 적당하다.

  셀프서비스 도입 시 반드시 같이 만들어야 할 것:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 팀/프로젝트별 Quota (용량 상한)                    │
  │    없으면 "공짜니까" 무한정 만든다.                   │
  │    "100TB 할당 가능" → 3개월 뒤 100TB 풀 소진.       │
  │    → 팀당 월 5TB 상한 같은 제한이 필요하다.          │
  │                                                      │
  │ 2. 미사용 볼륨 자동 감지                              │
  │    30일 이상 IO가 0인 볼륨을 주기적으로 리스트업.     │
  │    요청자에게 "아직 쓰시나요?" 확인 후 정리.          │
  │    이걸 안 하면 고아 볼륨이 전체 용량의 10~20%를      │
  │    먹고 있는 경우가 실제로 있다.                      │
  │                                                      │
  │ 3. 승인 프로세스 (최소한의)                            │
  │    Bronze 등급은 자동 승인이어도 되지만,               │
  │    Gold 등급(동기 복제 포함)은 스토리지팀 승인 필수.   │
  │    Gold를 무제한 셀프서비스로 풀면 DR 대역폭이        │
  │    감당 안 될 수 있다.                               │
  │                                                      │
  │ 4. 비용 차지백 (Chargeback)                           │
  │    사용량에 비례한 비용을 부서에 배분하면              │
  │    "공짜니까 많이 만들어두자"가 줄어든다.             │
  │    단점: 차지백 시스템 구축/운영에 공수가 든다.       │
  └──────────────────────────────────────────────────────┘