9. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
스토리지 인수시험(SAT)의 전체 절차. 하드웨어/라이선스 검증, 스냅샷 복원 테스트, 컨트롤러 페일오버 IO 중단 시간 판정 기준(30초 근거), 경로/전원/디스크 장애 시뮬레이션, fio 레이턴시 프로파일 해석법, 벤더 스펙 대비 실측 비교 방법, 성능 저하 시 5단계 원인 추적, 인수 결과 문서와 조건부 합격의 실무적 의미, 초기 안정화 기간 활용법까지.
시스템엔지니어가 알려주는 스토리지의 모든 것 시리즈10 / 10
- 11. 스토리지, 왜 어렵고 왜 중요한가
- 22. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 33. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 44. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 55. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 66. 도입 검토 — 요구사항 분석과 벤더 선정
- 77-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 87-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 98. 구축 — 초기 설정과 호스트 연결
- 109. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
글꼴
구축이 끝났다고 끝이 아니다.
벤더 SE가 "설정 완료했습니다, 정상입니다"라고 말하면, 그 말을 곧이곧대로 믿으면 안 된다. 물론 대부분의 벤더 SE는 유능하고 성실하다. 하지만 "정상"의 기준이 다를 수 있다. 벤더에게 "정상"은 장비가 에러 없이 켜져 있고 볼륨이 보이는 것이다. 우리에게 "정상"은 이중화가 실제로 동작하고, 기대한 성능이 나오고, 장애 상황에서 데이터가 안전한 것이다. 그 차이를 확인하는 게 인수시험이다.
인수시험을 제대로 안 하면 두 가지를 잃는다. 하나는 하자 주장의 근거다. 인수시험을 통과시키고 나면 "이후 문제는 운영 이슈"로 넘어간다. 다른 하나는 성능 Baseline이다. 인수시험 때 잡은 숫자가 향후 모든 성능 비교의 기준이 된다. "느려졌다"를 증명하려면 "원래는 이 정도였다"를 보여줘야 하는데, 그 "원래"가 없으면 아무 말도 할 수 없다.
FAT vs SAT
┌──────────────────────────────────────────────────────────┐
│ FAT (Factory Acceptance Test) │
│ 공장 출하 전 테스트. 벤더 공장에서 진행. │
│ → 하드웨어 불량 선별. 대형 프로젝트에서 고객 참관. │
│ → 참관 시 확인할 것: 시리얼 대조, 디스크 전수, │
│ 컨트롤러 HA 동작, 기본 성능 측정 │
│ → 소규모 도입이면 FAT 없이 SAT만 하는 경우가 많다. │
│ │
│ SAT (Site Acceptance Test) │
│ 현장 설치 후 테스트. 고객 환경에서 진행. │
│ → 실제 네트워크, 실제 호스트, 실제 워크로드 환경에서 │
│ → 이게 우리가 반드시 해야 하는 인수시험 │
│ → SAT를 안 하면? 구축 당시에는 멀쩡해 보였는데 │
│ 한 달 뒤 페일오버가 안 되는 걸 발견. 벤더에 말하면 │
│ "인수 후 발생한 이슈입니다." → 교섭력을 잃는다. │
└──────────────────────────────────────────────────────────┘인수시험 전체 흐름
인수시험 5개 영역:
① 하드웨어 검증 "주문한 대로 왔는가?"
│
▼
② 기본 기능 검증 "기능이 정상 동작하는가?"
│
▼
③ 이중화/HA 검증 "장애 나면 살아남는가?" ← 가장 중요
│
▼
④ 성능 검증 (Baseline) "기대한 성능이 나오는가?" ← 나중을 위해 필수
│
▼
⑤ 호스트 연결 검증 "서비스가 실제로 돌아가는가?"
│
▼
→ 결과 문서 작성 → 인수 판정 → 초기 안정화1. 하드웨어 검증 — 주문한 게 맞는지 확인
당연한 것 같지만, 의외로 빠뜨리는 경우가 있다.
하드웨어 검증 항목:
┌───────────────────┬───────────────────────┬──────────────┐
│ 항목 │ 확인 방법 │ 주의사항 │
├───────────────────┼───────────────────────┼──────────────┤
│ 모델명/시리얼 │ 장비 라벨 + CLI │ 계약서와 대조│
│ │ (system show 등) │ │
├───────────────────┼───────────────────────┼──────────────┤
│ 컨트롤러 수/상태 │ CLI: system/cluster │ HA Pair 확인 │
│ │ status │ Interconnect │
│ │ │ 링크 상태 │
├───────────────────┼───────────────────────┼──────────────┤
│ 디스크 수/용량 │ CLI: disk show │ 전수 확인! │
│ /타입 │ 물리 슬롯 확인 │ 빈 슬롯 없는 │
│ │ │ 지 육안 확인 │
├───────────────────┼───────────────────────┼──────────────┤
│ 메모리/캐시 │ CLI: system memory │ 스펙과 대조 │
├───────────────────┼───────────────────────┼──────────────┤
│ FC 포트 │ CLI: port show │ 링크 상태, │
│ │ │ 속도(16/32G) │
├───────────────────┼───────────────────────┼──────────────┤
│ iSCSI/관리 포트 │ CLI: net port show │ IP, MTU 확인 │
├───────────────────┼───────────────────────┼──────────────┤
│ 펌웨어 버전 │ CLI: version │ 호환 매트릭스│
│ │ │ 대조 (8편) │
├───────────────────┼───────────────────────┼──────────────┤
│ 라이선스 │ CLI: license show │ 계약한 기능이│
│ │ │ 다 활성화? │
└───────────────────┴───────────────────────┴──────────────┘
디스크 전수 확인이 중요한 이유:
100개 주문했는데 98개만 인식되는 경우가 실제로 있다.
배송 중 불량이거나, 슬롯 접촉 불량이거나.
인수시험 때 안 잡으면 나중에 "원래 98개였나요?"가 된다.
라이선스도 빠뜨리기 쉽다:
스냅샷, 복제, 암호화, 티어링 등의 기능이 라이선스 별도인
벤더가 있다. 계약서에 포함된 기능이 실제로 활성화됐는지
확인 안 하면, 나중에 "복제 기능 쓰려는데 라이선스가 없네?"가 된다.2. 기본 기능 검증 — 되는지 안 되는지 확인
기본 기능 테스트 시나리오:
┌──────────────────┬────────────────────┬───────────────────┐
│ 테스트 │ 방법 │ 실패 시 대응 │
├──────────────────┼────────────────────┼───────────────────┤
│ 볼륨 생성 │ CLI/GUI로 테스트 │ 스토리지 풀 상태 │
│ │ 볼륨 1개 생성 │ 확인, 디스크 상태 │
├──────────────────┼────────────────────┼───────────────────┤
│ 볼륨 온라인 확장 │ 생성한 볼륨 크기 │ 씬 프로비저닝 │
│ │ 변경 → 호스트 인식 │ 설정 확인 │
├──────────────────┼────────────────────┼───────────────────┤
│ 스냅샷 생성 │ 스냅샷 생성 후 │ 스냅샷 예약 공간 │
│ │ 데이터 변경 │ 확인 │
├──────────────────┼────────────────────┼───────────────────┤
│ 스냅샷 복원 │ 스냅샷으로 복원 후 │ 복원이 안 되면 │
│ ← 꼭 해야 함! │ 데이터 정합성 확인 │ 벤더에 즉시 보고 │
│ │ (md5sum 비교 등) │ │
├──────────────────┼────────────────────┼───────────────────┤
│ 복제 설정 │ DR 구성 시: 초기 │ 네트워크 대역폭, │
│ (DR 환경) │ 동기화 완료 확인 │ 복제 상태 확인 │
├──────────────────┼────────────────────┼───────────────────┤
│ NAS Export/Share │ 클라이언트에서 │ Export Policy, │
│ │ 마운트 + 읽기쓰기 │ 네트워크 방화벽 │
├──────────────────┼────────────────────┼───────────────────┤
│ 씬 프로비저닝 │ 1TB 볼륨에 100GB만 │ 물리 사용량이 │
│ │ 쓰고 물리 사용량 │ 100GB 근처인지 │
│ │ 확인 │ (1TB면 문제) │
└──────────────────┴────────────────────┴───────────────────┘
스냅샷 복원 테스트를 반드시 해야 하는 이유:
"스냅샷 찍기"만 테스트하고 "복원"은 안 하는 경우가 많다.
복원이 안 되는 스냅샷은 의미가 없다. 보험에 가입만 하고
보험금이 나오는지 확인 안 하는 것과 같다.
구체적으로:
1. 테스트 파일 생성 → md5sum 기록
2. 스냅샷 생성
3. 테스트 파일 삭제 또는 내용 변경
4. 스냅샷으로 복원
5. md5sum 비교 → 일치하면 성공3. 이중화/HA 검증 — 인수시험의 핵심
인수시험에서 가장 긴장되는 파트다. 실제로 케이블을 뽑고, 전원을 끄고, 디스크를 제거해 본다. 여기서 문제가 나오면 인수를 보류해야 한다.
이 테스트를 하는 이유는 단순하다. "이중화가 설계대로 동작하는가"를 장애가 터지기 전에 확인하는 거다. 프로덕션에 데이터가 올라간 뒤에 "사실 페일오버가 안 되는 구성이었다"를 발견하면 늦는다.
테스트 1: 컨트롤러 페일오버
┌──────────────────────────────────────────────────────────┐
│ 컨트롤러 페일오버 테스트 │
│ │
│ 사전 준비: │
│ · 서버에서 fio로 IO 부하를 걸어둔다 (테스트 볼륨 대상) │
│ · 스토리지 모니터링 화면을 열어둔다 │
│ · IO 카운터를 기록할 스크립트를 준비한다 │
│ (iostat -xmt 1 > failover_test.log &) │
│ │
│ 실행: │
│ · Ctrl A 강제 페일오버 실행 │
│ │
│ 벤더별 CLI: │
│ NetApp: storage failover takeover -ofnode ctrl-a │
│ Dell: GUI에서 Failover 또는 서비스 모드 전환 │
│ Pure: 컨트롤러 takeover (CLI) │
│ │
│ 측정: │
│ · IO 중단 시간 (fio 출력에서 gap 확인) │
│ · 레이턴시 변화 (페일오버 중/후) │
│ · 에러 발생 여부 (IO error, timeout) │
│ │
│ 판정 기준: │
│ ┌──────────────────────────────────────────────────┐ │
│ │ IO 중단 < 30초 │ 양호. 대부분의 벤더가 │ │
│ │ │ 이 범위를 목표로 함 │ │
│ ├──────────────────────┼──────────────────────────┤ │
│ │ IO 중단 30초~120초 │ 확인 필요. 벤더에 원인 │ │
│ │ │ 규명 요청. ALUA 설정, │ │
│ │ │ multipath 타이머 확인 │ │
│ ├──────────────────────┼──────────────────────────┤ │
│ │ IO 중단 > 120초 │ 불합격. 벤더에 시정 요구 │ │
│ │ │ → 원인 해결 후 재시험 │ │
│ ├──────────────────────┼──────────────────────────┤ │
│ │ IO 에러 발생 │ 불합격. multipath 설정, │ │
│ │ │ 타임아웃 값 재검토 │ │
│ └──────────────────────┴──────────────────────────┘ │
│ │
│ 복구 (Giveback/Failback): │
│ · Ctrl A 복구 실행 │
│ NetApp: storage failover giveback -ofnode ctrl-a │
│ · 복구 중 IO 영향 확인 (NDU라면 영향 없어야 함) │
│ · 복구 후 양쪽 컨트롤러 정상 상태 확인 │
│ · multipath -ll에서 경로가 원래대로 돌아왔는지 확인 │
│ │
│ 왜 30초가 기준인가: │
│ · 대부분의 DB(Oracle, MySQL)는 IO 타임아웃이 60초. │
│ 30초 이내면 DB가 IO 에러를 내지 않는다. │
│ · 30초를 넘기면 애플리케이션 레벨에서 타임아웃이 │
│ 발생할 수 있고, DB 인스턴스가 죽을 수 있다. │
│ · 벤더가 "10초 이내"라고 하면 실측으로 확인하라. │
│ 마케팅 숫자와 실제 환경은 다를 수 있다. │
└──────────────────────────────────────────────────────────┘테스트 2: 경로 장애
┌──────────────────────────────────────────────────────────┐
│ 경로 장애 테스트 (케이블 1개 제거) │
│ │
│ IO 부하 발생 중 │
│ │ │
│ ▼ │
│ FC 케이블 1개 물리적 제거 (또는 Switch 포트 disable) │
│ │ │
│ ▼ │
│ 확인 사항: │
│ · multipath -ll → 경로 1개가 faulty로 변경됐는가? │
│ · IO가 중단 없이 계속 흐르는가? │
│ (fio가 에러 없이 계속 돌고 있는가?) │
│ · 스토리지에서 경로 단절 알람이 발생했는가? │
│ · FC Switch에서 해당 포트가 offline으로 표시되는가? │
│ │ │
│ ▼ │
│ 케이블 재연결 │
│ │ │
│ ▼ │
│ 확인: 경로가 자동으로 active ready running으로 복구되는가?│
│ ⚠ 자동 복구가 안 되면 multipath 설정 문제. │
│ failback 옵션(immediate/manual/숫자)을 확인한다. │
│ │
│ 이 테스트에서 IO가 끊기면 안 된다. │
│ 끊기면 멀티패스가 제대로 동작하지 않는 거다. │
│ → multipath.conf, ALUA 설정, 벤더 호스트 유틸리티 확인 │
└──────────────────────────────────────────────────────────┘테스트 3: 전원 장애
┌──────────────────────────────────────────────────────────┐
│ 전원 장애 테스트 (PSU 1개 제거) │
│ │
│ PSU A 전원 케이블 제거 │
│ │ │
│ ▼ │
│ 확인: │
│ · 장비 정상 동작 유지 (IO 영향 없음) │
│ · PSU 장애 알람 발생 │
│ · 컨트롤러 상태 변화 없음 │
│ │ │
│ ▼ │
│ PSU A 전원 복구 │
│ · 알람 자동 해소 확인 │
│ · PSU 이중화 상태 복구 확인 │
│ │
│ ⚠ 이 테스트에서 장비가 꺼지면 전원 이중화가 안 되어있다. │
│ 같은 PDU에 두 전원을 꽂지 않았는지 확인 (8편 참고). │
└──────────────────────────────────────────────────────────┘테스트 4: 디스크 장애
┌──────────────────────────────────────────────────────────┐
│ 디스크 장애 시뮬레이션 │
│ │
│ 방법: CLI로 디스크 장애 주입 (물리 제거보다 안전) │
│ NetApp: disk fail -disk 0a.01.5 │
│ 또는 벤더 SE와 협의 하에 디스크 물리 제거 │
│ │ │
│ ▼ │
│ 확인: │
│ · RAID 리빌드(또는 reconstruct) 시작 여부 │
│ · Hot Spare 자동 투입 여부 │
│ · 리빌드 중 IO 성능 영향 측정 │
│ (레이턴시가 얼마나 올라가는가?) │
│ · 장애 알람 발생 여부 │
│ │ │
│ ▼ │
│ 디스크 복구 (CLI로 unfail 또는 물리 재삽입) │
│ · 리빌드 완료 확인 │
│ · RAID 상태 정상 복구 확인 │
│ │
│ 리빌드 중 IO 성능 영향이 클 수 있다: │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 올플래시: 영향 적음. 레이턴시 10~30% 증가 수준 │ │
│ │ HDD: 영향 큼. 레이턴시 2~5배 증가 가능. │ │
│ │ 리빌드 완료까지 수시간~수일 │ │
│ │ │ │
│ │ 벤더별 분산 RAID(Dell ADAPT, Pure 등)는 리빌드가 │ │
│ │ 전체 디스크에 분산되어 영향이 적다. │ │
│ │ 전통 RAID는 Hot Spare 1개에 집중되어 영향이 크다. │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘벤더가 "이 테스트는 안 해도 됩니다"라고 하는 항목이 있다면, 그게 사실 가장 해봐야 할 테스트일 수 있다. "안 해도 된다"는 건 "해보면 불편한 결과가 나올 수 있다"는 뜻일 때가 있다. 물론 벤더와 사전에 합의하고, 데이터가 없는 초기 상태에서 진행해야 한다.
4. 성능 검증 — Baseline을 잡아둬야 나중에 비교할 수 있다
인수시험에서 잡은 성능 수치가 앞으로 모든 성능 비교의 기준이 된다. 6개월 뒤 "스토리지가 느려진 것 같아요"라고 할 때, 이 Baseline과 비교해야 원인을 판단할 수 있다.
성능 테스트 매트릭스:
┌──────────────────┬─────────┬─────────────────────────────┐
│ 테스트 항목 │ 도구 │ 파라미터 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 4K 랜덤 읽기 │ fio │ bs=4k, rw=randread, │
│ │ │ iodepth=32, direct=1 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 4K 랜덤 쓰기 │ fio │ bs=4k, rw=randwrite, │
│ │ │ iodepth=32, direct=1 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 4K 혼합 70/30 │ fio │ bs=4k, rw=randrw, │
│ │ │ rwmixread=70 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 128K 순차 읽기 │ fio │ bs=128k, rw=read, │
│ │ │ iodepth=16 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 128K 순차 쓰기 │ fio │ bs=128k, rw=write, │
│ │ │ iodepth=16 │
├──────────────────┼─────────┼─────────────────────────────┤
│ 레이턴시 │ fio │ iodepth를 1→4→8→16→32→64 │
│ 프로파일 │ │ 단계별로 올리면서 측정 │
└──────────────────┴─────────┴─────────────────────────────┘
기록해야 할 수치:
· IOPS (avg)
· Latency: avg / p95 / p99
· Throughput (MB/s)
· 스토리지 컨트롤러 CPU 사용률레이턴시 프로파일이 특히 중요하다. iodepth를 올리면서 IOPS와 레이턴시가 어떻게 변하는지를 기록하면, 스토리지의 "한계점"이 보인다.
레이턴시 프로파일 예시:
iodepth │ IOPS │ Avg Lat │ p99 Lat │ 해석
────────┼─────────┼──────────┼──────────┼──────────────────
1 │ 5,200 │ 0.19ms │ 0.31ms │ 최저 레이턴시
4 │ 18,500 │ 0.21ms │ 0.45ms │ 선형 증가
8 │ 34,000 │ 0.23ms │ 0.52ms │ 선형 증가
16 │ 58,000 │ 0.27ms │ 0.68ms │ 효율 구간
32 │ 85,000 │ 0.37ms │ 1.20ms │ IOPS 증가율 둔화 시작
64 │ 95,000 │ 0.67ms │ 2.50ms │ 레이턴시 급증
128 │ 98,000 │ 1.30ms │ 5.80ms │ 컨트롤러 포화 근접
이 그래프에서 읽을 수 있는 것:
┌──────────────────────────────────────────────────────┐
│ · 최대 IOPS: ~98K (iodepth 128 근처에서 포화) │
│ · 실용 한계: ~85K (iodepth 32. 여기서부터 레이턴시 │
│ 대비 IOPS 효율이 떨어짐) │
│ · 최저 레이턴시: 0.19ms (iodepth 1) │
│ │
│ 6개월 뒤 "iodepth 32에서 1.5ms가 나와요"라고 하면 │
│ Baseline(0.37ms)과 비교해서 4배 느려진 것. │
│ → 뭔가 변한 거다. 원인 추적 시작. │
└──────────────────────────────────────────────────────┘벤더 제안서 스펙과 비교하는 방법:
벤더 제안서: "최대 200,000 IOPS"
실측 (4K 랜덤 읽기, iodepth 32): 85,000 IOPS
"절반도 안 나오는데?" → 당황하지 말 것.
┌──────────────────────────────────────────────────────┐
│ 벤더 스펙은 보통: │
│ · 100% 읽기 기준 (쓰기 섞으면 절반 이하) │
│ · 최대 iodepth (128+)에서 측정 │
│ · 워킹셋이 캐시에 다 들어가는 조건 │
│ · 여러 호스트에서 동시에 돌린 합산값 │
│ │
│ 우리 테스트는 보통: │
│ · 단일 호스트, 단일 볼륨 │
│ · 혼합 워크로드 (읽기+쓰기) │
│ · 실제 워크로드에 가까운 iodepth │
│ │
│ 판정 기준: │
│ · 단일 호스트에서 제안서의 40~60%면 정상 범위 │
│ · 20% 미만이면 설정 문제 가능 → 벤더에 확인 요청 │
│ · 멀티호스트 테스트를 하면 합산값이 제안서에 근접 │
└──────────────────────────────────────────────────────┘성능이 기대보다 낮을 때 확인 순서:
┌──────────────────────────────────────────────────────┐
│ 1. fio 옵션 확인 │
│ direct=1인가? (0이면 OS 캐시가 개입) │
│ ioengine=libaio인가? (sync이면 느림) │
│ │
│ 2. 멀티패스 확인 │
│ 경로가 4개 다 active인가? │
│ 1~2개만 active면 대역폭이 절반 │
│ ALUA Non-Optimized 경로로만 IO가 가고 있진 않은가? │
│ │
│ 3. 스토리지 컨트롤러 확인 │
│ CPU가 이미 높은가? (다른 워크로드가 돌고 있는가?) │
│ 캐시 워밍업이 안 됐는가? (첫 테스트는 느릴 수 있음)│
│ │
│ 4. 네트워크 확인 (iSCSI/NFS) │
│ 대역폭 포화? Jumbo Frame MTU 불일치? │
│ iSCSI 전용 VLAN에서 다른 트래픽이 흐르고 있진 않나?│
│ │
│ 5. 볼륨 설정 확인 │
│ QoS 상한이 걸려있진 않은가? │
│ 씬 프로비저닝 + 리덕션 동시 동작으로 CPU 부하? │
└──────────────────────────────────────────────────────┘5. 호스트 연결 검증 — 실제 서비스 관점
호스트 연결 최종 확인:
┌──────────────────────────────────────────────────────┐
│ □ 멀티패스 경로 수 확인 │
│ $ multipath -ll | grep "status" │
│ → 모든 경로 active ready running │
│ → 설계한 경로 수(보통 4개)와 일치하는지 │
│ │
│ □ 파일시스템 마운트 확인 │
│ $ df -h | grep /data │
│ → 용량이 설계대로인지 │
│ │
│ □ 실제 서비스 연동 테스트 │
│ · DB: 기동 → 테이블 생성 → 데이터 INSERT/SELECT │
│ · 웹서버: 기동 → 파일 업로드/다운로드 │
│ · "스토리지 위에서 실제 서비스가 돌아가는가?" │
│ │
│ □ 서버 재부팅 테스트 │
│ · 서버 재부팅 후 자동 마운트 확인 │
│ · fstab의 _netdev, nofail이 제대로 동작하는지 │
│ · 멀티패스 경로가 재부팅 후에도 정상 복구되는지 │
│ │
│ ⚠ 재부팅 테스트를 안 하면? │
│ 운영 중 서버를 재부팅했더니 스토리지 마운트가 │
│ 안 되어서 부팅이 멈추는 걸 그때 발견한다. │
│ 인수시험 때 한 번 해보면 이런 사고를 막을 수 있다. │
│ │
│ □ NFS 환경: stale file handle 안 나는지 │
│ Export 재설정 후 마운트 해제/재마운트 테스트 │
└──────────────────────────────────────────────────────┘인수시험 결과 문서 — 서명이 곧 책임의 이전
인수시험 결과서 구조:
┌──────────────────────────────────────────────────────┐
│ 1. 개요 │
│ 시험 일시, 참여자 (고객측 + 벤더측), 장비 정보 │
│ │
│ 2. 하드웨어 검증 결과 [합격 / 불합격] │
│ 미비사항: │
│ │
│ 3. 기본 기능 검증 결과 [합격 / 불합격] │
│ 미비사항: │
│ │
│ 4. 이중화 검증 결과 [합격 / 불합격] │
│ 페일오버 IO 중단 시간: ___초 │
│ 경로 장애 시 IO 영향: 없음 / 있음(__초) │
│ 미비사항: │
│ │
│ 5. 성능 검증 결과 (Baseline) │
│ 4K Random Read IOPS: ______ │
│ 4K Random Write IOPS: ______ │
│ 4K Mixed 70/30 IOPS: ______ │
│ 128K Seq Read Throughput: ______ MB/s │
│ Latency Profile: (별지 첨부) │
│ │
│ 6. 호스트 연결 검증 결과 [합격 / 불합격] │
│ 미비사항: │
│ │
│ 7. 종합 판정 │
│ □ 합격 → 인수 확인 │
│ □ 조건부 합격 → 미비사항 조치 후 재확인 │
│ □ 불합격 → 원인 해결 후 재시험 │
│ │
│ 서명: 고객측 ____________ 벤더측 ____________ │
│ 날짜: ______년 ____월 ____일 │
└──────────────────────────────────────────────────────┘조건부 합격의 실무적 의미:
┌──────────────────────────────────────────────────────┐
│ 조건부 합격이란: │
│ · 핵심 기능은 통과했지만 일부 미비사항이 있는 경우 │
│ · 예: "라이선스 1개 미활성", "알림 설정 미완료" 등 │
│ · 미비사항 목록 + 조치 기한을 명시한다 │
│ · 기한 내 조치 완료 → 최종 합격 확인서 서명 │
│ │
│ 조건부 합격의 리스크: │
│ · "나중에 하겠습니다" → 안 한다. 영원히. │
│ · 미비사항 추적을 안 하면 흐지부지 된다. │
│ · 조건부 합격은 최대한 피하고, │
│ 가능하면 현장에서 바로 해결하는 게 좋다. │
│ │
│ 인수 거부(불합격) 시: │
│ · 벤더에 공식적으로 불합격 사유를 서면 전달 │
│ · 재시험 일정 합의 │
│ · 불합격 사유가 벤더 귀책이면 유지보수 개시일이 │
│ 뒤로 밀린다 (비용 절약) │
└──────────────────────────────────────────────────────┘
인수 확인서 서명일 = 유지보수 개시일인 경우가 많다.
서명 전에 미비 사항을 모두 해결해야 한다.
서명 = "이 장비를 받아들이겠다"는 공식 선언이다.초기 안정화 기간 — 인수시험 후 1~2주
인수시험이 끝나고 바로 프로덕션을 올리는 건 아니다. 1~2주의 안정화 기간을 두고 모니터링을 강화한다.
초기 안정화 기간에 할 것:
┌──────────────────────────────────────────────────────┐
│ □ 모니터링 강화 │
│ · 평소보다 짧은 간격으로 성능 메트릭 확인 │
│ · 알람 임계치를 약간 낮게 설정 (민감하게) │
│ · 이상 징후 조기 발견이 목적 │
│ │
│ □ 벤더 SE 상주 기간 활용 │
│ · 대부분의 벤더가 구축 후 1~2주 SE 상주를 제공 │
│ · 이 기간에 운영 관련 궁금한 것을 다 물어본다 │
│ "이 로그가 뭘 의미하나요?" │
│ "이 설정을 바꾸면 어떤 영향이 있나요?" │
│ "장애 시 어떤 순서로 확인하면 되나요?" │
│ · SE가 떠난 후에는 서포트 콜로 물어야 한다. │
│ 새벽 3시에 "이 옵션 뭐였더라?"를 전화로 │
│ 물어보는 건 아무래도 다르다. │
│ │
│ □ 운영 문서 정비 │
│ · As-Built 문서 최종 확인 (8편) │
│ · 장애 대응 런북 초안 작성 │
│ · 벤더 서포트 콜 절차 확인 (전화번호, 계약번호) │
│ │
│ □ 소규모 워크로드로 시작 │
│ · 비핵심 서비스부터 올려서 실 운영 환경에서 검증 │
│ · 문제 없으면 점진적으로 핵심 서비스 이전 │
│ · 한꺼번에 전부 올리지 않는다 │
└──────────────────────────────────────────────────────┘안정화 기간이 끝나면 본격적인 일상 운영이 시작된다. 다음 편부터는 스토리지 운영의 70%를 차지하는 실제 업무 — 볼륨 할당, 변경 관리 이야기다.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
8. 구축 — 초기 설정과 호스트 연결
물리 설치 체크리스트, 초기 설정 8단계의 이유와 주의사항, FC/iSCSI/NFS 각각의 호스트 연결 절차와 트러블슈팅, 벤더별 multipath 차이, fio 결과 해석법, As-Built 문서화까지. 설계를 현실로 바꾸는 구축 실무.
2026. 05. 25. PM 10:00Infrastructure7-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
스토리지 설계의 데이터 편. LUN 분리 장단점, 네이밍 컨벤션, 스냅샷 동작 원리와 리스크, DR 동기/비동기 복제 트레이드오프, Active-Active 메트로 클러스터의 Split-Brain 리스크까지. 인프라 위에 데이터를 배치하고 보호하는 설계의 후반부.
2026. 05. 18. PM 10:00Infrastructure7-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
스토리지 설계의 인프라 편. FC/iSCSI 네트워크 이중화와 장애 시나리오, VMware 데이터스토어 선택(VMFS/NFS/vVols)과 장애 리스크, K8s PV/PVC/CSI 설계, Tier 구조와 자동 티어링 리스크까지. 물리적 뼈대를 먼저 세우는 설계의 전반부.
2026. 05. 11. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...