17. 마이그레이션과 폐기

  마이그레이션 프로젝트 흐름:
  
  ① 인벤토리 작성      "뭘 옮길 건가?"
       │                 볼륨 목록, 호스트 매핑, 용량, 서비스 중요도
       ▼
  ② 방식 결정          "어떻게 옮길 건가?"
       │                 호스트 기반 / 스토리지 기반 / 가상화 기반
       ▼
  ③ 일정 계획          "언제 옮길 건가?"
       │                 작업 윈도우, 우선순위, 롤백 여유 시간
       ▼
  ④ 사전 동기화        "미리 복사해둔다"
       │                 대량 데이터를 먼저 옮겨서 컷오버 시간 최소화
       ▼
  ⑤ 컷오버 (최종 전환) "서비스를 신규로 전환한다"
       │                 서비스 중지 → 최종 동기화 → 경로 전환 → 서비스 시작
       ▼
  ⑥ 검증               "제대로 옮겨졌는가?"
       │                 데이터 무결성, 성능, 애플리케이션 정상 동작
       ▼
  ⑦ 구 장비 정리/폐기  "안전하게 지우고 처분한다"

┌──────────────────────────────────────────────────────────┐
│           마이그레이션 방식 비교                           │
├───────────────┬──────────────────────────────────────────┤
│ ① 호스트 기반 │                                          │
│               │ [구 스토리지] ←─ 서버 ─→ [신 스토리지]   │
│               │                                          │
│               │ 서버에서 데이터를 읽어서 다시 쓴다.       │
│               │ rsync(Linux), robocopy(Windows),         │
│               │ OS 레벨 미러링(LVM mirror, dd)           │
│               │                                          │
│               │ 장점: 벤더 무관. 이기종 간 가능.          │
│               │       추가 라이선스 없음.                 │
│               │ 단점: 서버 CPU/네트워크 부하 큼.          │
│               │       대용량이면 시간이 매우 오래 걸림.   │
│               │       서비스 중 rsync는 일관성 보장 어려움│
│               │       (DB라면 정지 후 복사해야 정합성 보장)│
│               │                                          │
│               │ 적합: 소규모, NAS 파일 서버, 이기종 환경  │
├───────────────┼──────────────────────────────────────────┤
│ ② 스토리지    │                                          │
│    기반       │ [구 스토리지] ══복제══► [신 스토리지]     │
│               │                                          │
│               │ 스토리지 간 직접 데이터를 복제한다.       │
│               │ 같은 벤더: SnapMirror(NetApp), 복제 기능  │
│               │ 이기종: ForeignLUN Import, SAN Copy 등   │
│               │                                          │
│               │ 장점: 서버 부하 없음. 블록 레벨 복제라    │
│               │       빠르고 정확함. 사전 동기화 가능.    │
│               │ 단점: 같은 벤더끼리만 잘 된다.            │
│               │       이기종은 제한적이거나 추가 라이선스. │
│               │       구/신 스토리지를 동시에 운영해야 함. │
│               │                                          │
│               │ 적합: 같은 벤더 교체, 대용량 블록 스토리지│
├───────────────┼──────────────────────────────────────────┤
│ ③ 패브릭     │                                          │
│    기반       │ [구] ──SAN──[중간 장비]──SAN── [신]      │
│               │                                          │
│               │ SAN Fabric 사이에 중간 장비(VPLEX, SVC)  │
│               │ 를 놓고 투명하게 데이터를 이동한다.       │
│               │                                          │
│               │ 장점: 호스트가 모른다. 서비스 중단 없이   │
│               │       백그라운드에서 이동. 이기종 가능.   │
│               │ 단점: 중간 장비 도입 비용. 복잡도 높음.   │
│               │       중간 장비가 SPOF가 될 수 있음.      │
│               │       SAN 환경에서만 가능.                │
│               │                                          │
│               │ 적합: 대규모 이기종, 무중단 필수 환경     │
├───────────────┼──────────────────────────────────────────┤
│ ④ 가상화     │                                          │
│    기반       │ Storage vMotion / Live Migration         │
│               │                                          │
│               │ VMware Storage vMotion으로 VM의           │
│               │ 데이터스토어를 구→신으로 이동.           │
│               │ Hyper-V의 Live Migration도 동일 개념.    │
│               │                                          │
│               │ 장점: VM 단위 이동. 서비스 무중단.        │
│               │       GUI에서 드래그 앤 드롭 수준.       │
│               │ 단점: VMware 환경에서만 가능.             │
│               │       VM 수가 많으면 일괄 이동 스크립트   │
│               │       필요 (PowerCLI).                    │
│               │       대용량 VM은 이동 시간이 긺.         │
│               │       베어메탈 서버에는 적용 불가.        │
│               │                                          │
│               │ 적합: VMware 가상화 환경, VM 단위 이동    │
└───────────────┴──────────────────────────────────────────┘

  ┌──────────────┬───────────────────────────────────────┐
  │ NetApp       │ XCP: NAS(NFS/SMB) 데이터 마이그레이션 │
  │              │ SnapMirror: 같은 ONTAP 간 블록 복제   │
  │              │ 7MTT: 7-Mode → cDOT 전환 (레거시)    │
  │              │ ForeignLUN Import: 이기종 LUN 가져오기 │
  │              │ 장점: 도구가 성숙. 이기종도 일부 지원. │
  │              │ 단점: 이기종 Import는 지원 벤더 제한적.│
  ├──────────────┼───────────────────────────────────────┤
  │ Dell         │ PowerStore 내장 마이그레이션 기능      │
  │ PowerStore   │ (특정 이전 모델에서 Import 지원)      │
  │              │ 장점: GUI에서 간단히 실행 가능.        │
  │              │ 단점: 지원 소스 모델이 제한적.         │
  ├──────────────┼───────────────────────────────────────┤
  │ Pure Storage │ Pure Migrate (구 장비 → Pure로 이동)  │
  │              │ 장점: 이기종에서 Pure로의 이동에 특화.  │
  │              │ 단점: Pure → 다른 벤더 이동은 미지원.  │
  │              │       벤더 종속 방향.                  │
  ├──────────────┼───────────────────────────────────────┤
  │ 이기종       │ 현실적으로 완벽한 이기종 마이그레이션  │
  │ 일반        │ 도구는 없다. 대부분 호스트 기반(rsync)  │
  │              │ 또는 가상화 기반(Storage vMotion)으로  │
  │              │ 해결한다.                              │
  └──────────────┴───────────────────────────────────────┘

  사전 동기화 + 컷오버 패턴:
  
  [1단계: 사전 동기화] — 서비스 운영 중
  ┌──────────────────────────────────────────────────────┐
  │ 구 스토리지 ════ 전체 데이터 복제 ═══► 신 스토리지   │
  │                                                      │
  │ 10TB 복사에 5시간 걸린다고 하면, 서비스 운영 중에     │
  │ 백그라운드로 복사한다. 이 동안 서비스에 영향 없음.    │
  │ (스토리지 기반 복제는 서버 부하 없음.                 │
  │  호스트 기반이면 네트워크/CPU 부하 고려 필요.)        │
  └──────────────────────────────────────────────────────┘
       │
       ▼
  [2단계: 변경분 동기화] — 서비스 운영 중
  ┌──────────────────────────────────────────────────────┐
  │ 1단계 이후 변경된 데이터만 추가 동기화.               │
  │ 변경분이 500GB라면 30분이면 됨.                      │
  │ 이걸 반복하면 변경분이 점점 줄어든다.                │
  └──────────────────────────────────────────────────────┘
       │
       ▼
  [3단계: 컷오버] — 서비스 중지 (최소 다운타임)
  ┌──────────────────────────────────────────────────────┐
  │ ① 서비스 중지 (애플리케이션/DB 정지)                 │
  │ ② 최종 변경분 동기화 (수GB → 수분)                  │
  │ ③ 호스트 경로 전환 (구→신 스토리지)                  │
  │    · FC: Zoning 변경, LUN Masking 변경               │
  │    · iSCSI: 타겟 IP 변경, 재로그인                   │
  │    · NFS: 마운트 변경 (umount → mount 신규)          │
  │    · VMware: 데이터스토어 변경 (Storage vMotion 완료) │
  │ ④ 서비스 시작                                       │
  │ ⑤ 정상 동작 확인                                    │
  │                                                      │
  │ 컷오버 소요 시간: 보통 30분~2시간                     │
  │ (사전 동기화를 잘 했으면 30분 이내도 가능)            │
  └──────────────────────────────────────────────────────┘
  
  컷오버 시간 = 최종 동기화 시간 + 경로 전환 시간 + 검증 시간
  
  컷오버를 짧게 하려면:
  · 사전 동기화를 여러 번 반복해서 변경분을 최소화
  · 경로 전환 절차를 사전에 리허설
  · 검증 스크립트를 미리 준비 (자동화)

  마이그레이션 실패 시 롤백:
  
  ┌──────────────────────────────────────────────────────┐
  │ 컷오버 후 문제가 발견되면?                            │
  │                                                      │
  │ · 구 스토리지를 아직 살려놓은 상태여야 한다.          │
  │   컷오버 직후 구 장비를 끄면 안 된다!                │
  │                                                      │
  │ · 경로를 다시 구 스토리지로 전환 (역방향 작업)       │
  │ · 서비스 재시작 후 정상 확인                          │
  │                                                      │
  │ 롤백이 안 되는 경우:                                  │
  │ · 컷오버 후 신규 스토리지에 새 데이터가 쓰여졌으면   │
  │   구 스토리지에는 없는 데이터가 생긴다.              │
  │   → 컷오버 후 "안전 기간"을 정하고 (1~2주),          │
  │     그 기간 동안 구 장비를 유지한다.                 │
  │     안전 기간이 지나면 구 장비 정리.                  │
  │                                                      │
  │ · 롤백 계획이 없는 마이그레이션은 하면 안 된다.      │
  └──────────────────────────────────────────────────────┘

  인벤토리 작성 (맨 먼저 해야 할 것):
  
  ┌──────────────────────────────────────────────────────┐
  │ 볼륨명      │ 용량 │ 호스트    │ 서비스    │ 중요도 │
  ├─────────────┼──────┼──────────┼──────────┼────────┤
  │ prd_erp_data│ 2TB  │ erp_db01 │ ERP      │ 미션   │
  │ prd_erp_log │ 500G │ erp_db01 │ ERP      │ 미션   │
  │ prd_web_data│ 1TB  │ web01~04 │ 웹서비스 │ 일반   │
  │ dev_test_01 │ 500G │ dev01    │ 개발     │ 낮음   │
  │ ...         │      │          │          │        │
  └─────────────┴──────┴──────────┴──────────┴────────┘
  
  이 목록이 없으면 "뭘 옮겨야 하지?"부터 삽질한다.
  As-Built 문서(8편)와 볼륨 할당 대장(10편)이 여기서 빛을 발한다.
  이 문서들이 없으면 스토리지 CLI에서 전수 조사해야 한다.

  우선순위 결정:
  
  ┌──────────────────────────────────────────────────────┐
  │ 방법 1: 비중요 서비스부터 (안전한 방식)              │
  │   개발/테스트 → 파일 서버 → 일반 앱 → 미션 크리티컬 │
  │   장점: 실수해도 영향 적음. 경험 쌓으면서 진행.     │
  │   단점: 시간이 오래 걸림. 미션 크리티컬이 마지막이라 │
  │         긴장이 끝까지 유지됨.                        │
  │                                                      │
  │ 방법 2: 중요 서비스 먼저 (빠른 방식)                 │
  │   미션 크리티컬 → 일반 앱 → 파일 서버 → 개발/테스트 │
  │   장점: 가장 중요한 걸 빨리 해결. 이후는 부담 적음.  │
  │   단점: 첫 작업이 가장 위험. 경험 없이 큰 것 먼저.   │
  │                                                      │
  │ 권장: 방법 1. 비중요 1~2개로 절차 검증 후 중요 진행. │
  └──────────────────────────────────────────────────────┘

  누구에게 뭘 알려야 하는가:
  
  ┌──────────────────────────────────────────────────────┐
  │ · 서버팀/DBA: 컷오버 일정, 다운타임, 호스트 변경사항│
  │ · 애플리케이션팀: 서비스 재시작 순서, 확인 항목      │
  │ · 네트워크팀: Zoning/VLAN 변경이 필요한 경우         │
  │ · 경영진: 마이그레이션 일정, 리스크, 롤백 계획       │
  │ · 벤더: 구/신 양쪽 벤더 SE 대기 (장애 시 즉시 대응) │
  │                                                      │
  │ 컷오버 당일에 "오늘 마이그레이션하는 거 몰랐는데?"   │
  │ 라는 말이 나오면 커뮤니케이션 실패다.                │
  └──────────────────────────────────────────────────────┘

  검증 항목:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 데이터 무결성                                      │
  │    · NAS: 파일 수 비교, 디렉토리 구조 비교           │
  │      $ find /data -type f | wc -l (구 vs 신)         │
  │      $ md5sum으로 샘플 파일 체크섬 비교               │
  │    · 블록: 볼륨 크기 비교, DB 체크섬                  │
  │      DB: 테이블 카운트, 체크섬 쿼리                   │
  │                                                      │
  │ 2. 성능 비교                                          │
  │    · 신규 스토리지에서 fio로 Baseline 측정 (9편 참고) │
  │    · 구형 대비 성능이 기대대로인지 확인               │
  │    · 성능이 오히려 떨어지면? 설정 확인.               │
  │      multipath, QoS, 데이터스토어 유형 등.           │
  │                                                      │
  │ 3. 애플리케이션 레벨                                  │
  │    · DB: 기동 → 쿼리 실행 → 결과 확인                │
  │    · 웹서버: 기동 → 페이지 로딩 → 기능 테스트        │
  │    · "스토리지 옮겼는데 앱이 이상해요"가 나오면       │
  │      마운트 포인트, 권한(NFS uid/gid), 경로가        │
  │      달라진 건 아닌지 확인.                          │
  │                                                      │
  │ 4. 경로/이중화 확인                                   │
  │    · multipath -ll: 경로 수 정상?                    │
  │    · 구 스토리지로의 경로가 남아있진 않은지?          │
  │    · Zoning에 구 스토리지 엔트리가 정리됐는지?       │
  └──────────────────────────────────────────────────────┘

  구 장비 정리 체크리스트:
  
  ┌──────────────────────────────────────────────────────┐
  │ □ 구 장비에 IO가 더 이상 발생하지 않는지 확인        │
  │   모니터링에서 IOPS = 0 상태가 지속되는지.           │
  │   혹시 잊고 남겨둔 호스트가 아직 접근하고 있진 않은지.│
  │                                                      │
  │ □ 호스트에서 구 스토리지 마운트 해제                  │
  │   fstab에서 제거. multipath에서 구 경로 제거.        │
  │   NFS umount 확인.                                   │
  │                                                      │
  │ □ FC Zoning에서 구 스토리지 관련 Zone 제거           │
  │   안 지우면 Zoning 테이블이 점점 더러워진다.         │
  │                                                      │
  │ □ 모니터링/알림에서 구 장비 해제                      │
  │   안 하면 "스토리지 다운!" 알람이 폐기 후에도 울린다. │
  │                                                      │
  │ □ 자산 대장 업데이트 (16편)                           │
  │   상태를 "운영 중" → "폐기 예정"으로 변경.           │
  │                                                      │
  │ □ 벤더 유지보수 계약 해지                              │
  │   구 장비 유지보수를 안 끊으면 계속 과금된다.        │
  │   계약 해지 통보 기한(보통 30~90일 전)을 확인.       │
  │                                                      │
  │ □ 라이선스 이전/반환                                   │
  │   이전 가능한 라이선스가 있으면 신규 장비로 이전.    │
  │   벤더에 반환해야 하는 라이선스는 반환 절차 진행.    │
  └──────────────────────────────────────────────────────┘

  데이터 삭제 방법:
  
  ┌──────────────────────────────────────────────────────────┐
  │ ① Crypto Erase (권장)                                    │
  │                                                          │
  │   SED(Self-Encrypting Drive)의 암호화 키를 폐기한다.     │
  │   키가 없으면 디스크의 데이터는 복호화 불가능 = 읽을 수  │
  │   없음. 수초만에 완료.                                   │
  │                                                          │
  │   장점: 가장 빠르고 확실. 디스크를 재사용할 수 있음.     │
  │   단점: SED가 아닌 일반 디스크에서는 불가.               │
  │         소프트웨어 암호화만 썼다면 키 관리가 확실해야 함. │
  ├──────────────────────────────────────────────────────────┤
  │ ② Secure Erase (소프트웨어 덮어쓰기)                     │
  │                                                          │
  │   디스크 전체를 0 또는 랜덤 데이터로 여러 번 덮어쓴다.   │
  │   NIST 800-88 가이드라인: 최소 1회 덮어쓰기 권장.        │
  │   (과거에는 3회, 7회 등 여러 번이었으나 현대 디스크에서는 │
  │    1회로 충분하다는 게 NIST 입장.)                       │
  │                                                          │
  │   장점: SED 아니어도 가능. 표준화된 방법.                │
  │   단점: 대용량이면 시간이 오래 걸린다.                   │
  │         HDD 10TB × 수십 개 = 수일 소요 가능.            │
  │         SSD는 Wear Leveling 때문에 덮어쓰기만으로는      │
  │         100% 삭제가 보장되지 않을 수 있다.               │
  │         → SSD는 Crypto Erase 또는 물리 파쇄 권장.       │
  ├──────────────────────────────────────────────────────────┤
  │ ③ 물리적 파쇄                                            │
  │                                                          │
  │   디스크를 물리적으로 파쇄(shredding)한다.               │
  │   인증된 파쇄 업체에 위탁. 파쇄 인증서 수령.            │
  │                                                          │
  │   장점: 가장 확실. 복구 불가능.                          │
  │   단점: 디스크를 재사용할 수 없다 (자원 낭비).           │
  │         파쇄 업체 비용.                                  │
  │         디스크를 외부에 반출해야 하므로 보안 정책 확인.   │
  └──────────────────────────────────────────────────────────┘
  
  어떤 방법을 쓸 것인가:
  ┌──────────────────────────────────────────────────────┐
  │ · 내부 재사용/매각: Crypto Erase 또는 Secure Erase   │
  │ · 민감 데이터(금융, 의료, 공공): 물리 파쇄 권장      │
  │ · 반납/폐기: Crypto Erase + 파쇄 인증서 확보        │
  │                                                      │
  │ "그냥 포맷하면 되지 않나?"                            │
  │ → 안 된다. 포맷은 파일시스템만 초기화하는 거지        │
  │   데이터 자체는 디스크에 남아있다. 복구 가능하다.     │
  └──────────────────────────────────────────────────────┘

  장비 폐기 절차:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 데이터 완전 삭제 (위 방법 중 택 1)                │
  │    삭제 완료 기록 남기기 (삭제 방법, 일시, 담당자)   │
  │                                                      │
  │ 2. 자산 처분 결정                                     │
  │    · 벤더 Trade-in → 신규 장비 할인 (16편)           │
  │    · 중고 매각 → IT 자산 처분 업체 활용              │
  │    · 폐기 → 파쇄 업체 위탁                           │
  │    · 기부/이관 → 개발/테스트 환경으로 내부 재활용    │
  │                                                      │
  │ 3. 자산 대장에서 제거                                 │
  │    상태를 "폐기 완료"로 변경.                        │
  │    폐기 일자, 방법, 증빙(파쇄 인증서 등) 첨부.      │
  │                                                      │
  │ 4. 회계 처리                                          │
  │    감가상각 완료 확인. 잔존가치 처리.                │
  │    재무팀과 협의.                                    │
  └──────────────────────────────────────────────────────┘
  
  폐기 시 놓치기 쉬운 것:
  ┌──────────────────────────────────────────────────────┐
  │ · 디스크만 지우고 컨트롤러의 설정(IP, 계정 등)을     │
  │   안 지우는 경우. 중고로 나간 장비에 관리자 비밀번호가│
  │   남아있으면 보안 문제.                              │
  │   → 공장 초기화(Factory Reset) 실행.                 │
  │                                                      │
  │ · FC Switch의 Zoning에 폐기 장비 정보가 남아있는 경우.│
  │   → 폐기 후 Zoning 정리.                             │
  │                                                      │
  │ · 벤더 포털에 장비가 등록된 채로 남아있는 경우.       │
  │   → 벤더에 장비 등록 해제 요청.                      │
  └──────────────────────────────────────────────────────┘