18. 스토리지 운영 자동화와 문서화
스토리지 100대 운영 관점의 자동화와 문서화. 시스템이 아는 것 vs 사람만 아는 것 구분, 대규모 환경에서 볼륨 대장/구성도를 유지하는 현실적 방법, 네이밍 컨벤션이 곧 문서화인 이유, 자동화할 수 있는 것과 없는 것, 런북 작성법, 4단계 운영 개선 로드맵까지.
시스템엔지니어가 알려주는 스토리지의 모든 것 시리즈19 / 19
- 112. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
- 21. 스토리지, 왜 어렵고 왜 중요한가
- 32. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 43. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 54. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 65. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 76. 도입 검토 — 요구사항 분석과 벤더 선정
- 87-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 97-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 108. 구축 — 초기 설정과 호스트 연결
- 119. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
- 1210. 일상 운영 1: 볼륨 할당과 변경 관리
- 1311. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
- 1413. 백업과 아카이빙
- 1514. 보안과 랜섬웨어 대응
- 1615. 장애 대응 — 스토리지 트러블슈팅 실전
- 1716. 유지보수 계약과 수명 관리 — EOS/EOL 대응
- 1817. 마이그레이션과 폐기
- 1918. 스토리지 운영 자동화와 문서화
글꼴
스토리지 5대를 관리하는 것과 100대를 관리하는 건 차원이 다르다.
5대면 머릿속에 다 들어간다. "A 장비에 ERP 볼륨이 있고, B 장비에 웹서버 볼륨이 있고." 볼륨 대장을 엑셀로 만들어도 유지할 수 있다. 100대면? 볼륨이 수천~수만 개다. 엑셀에 적는 순간 이미 outdated다. 누군가 볼륨을 만들거나 지울 때마다 엑셀을 업데이트하는 건 불가능하다.
그래서 "문서화"의 의미부터 다시 생각해야 한다. 문서화란 "엑셀을 잘 관리하는 것"이 아니라, "현재 상태를 언제든 파악할 수 있는 능력을 갖추는 것"이다.
운영 정보의 두 종류 — 시스템이 아는 것 vs 사람만 아는 것
이 구분이 핵심이다. 뭘 자동으로 뽑고 뭘 수작업으로 관리해야 하는지는 이 구분에서 결정된다.
┌──────────────────────────────────────────────────────────┐
│ 시스템이 아는 것 (Source of Truth = 장비 자체) │
│ │
│ · 볼륨 목록, 크기, 사용률 │
│ · LUN Masking (어떤 호스트에 매핑됐는지) │
│ · Zoning 현황 (FC Switch에 다 들어있다) │
│ · IP 할당 (스토리지 포트에 설정된 IP) │
│ · 디스크 상태, Wear Level │
│ · 성능 메트릭 (IOPS, Latency) │
│ · 스냅샷 현황 │
│ · RAID 상태, 컨트롤러 상태 │
│ │
│ → 이건 스토리지/스위치에서 API나 CLI로 뽑으면 된다. │
│ 별도 문서를 만들어서 이중 관리하면 안 맞을 때 │
│ "둘 중 뭐가 맞는 거지?"가 된다. │
│ 시스템이 진실이다. 문서는 사본일 뿐이다. │
├──────────────────────────────────────────────────────────┤
│ 사람만 아는 것 (시스템에 없는 정보) │
│ │
│ · "이 볼륨이 무슨 서비스에 쓰이는지" │
│ → 네이밍 컨벤션(7-1편)이 잘 되어 있으면 이름에서 유추 │
│ prd_erp_data_001 → "운영 ERP 데이터" │
│ vol37 → 뭔지 모른다. 영원히. │
│ │
│ · "왜 이렇게 설계했는지" (설계 의도, 히스토리) │
│ · 벤더 연락처, 계약 번호, SLA 등급 │
│ · 장애 대응 절차 (런북) │
│ · 변경 이유와 맥락 ("왜 QoS를 이 값으로 했는지") │
│ · 담당자 정보 (누가 이 장비를 관리하는지) │
│ │
│ → 이건 사람이 직접 기록해야 한다. │
│ 시스템에서 뽑을 수 없다. │
└──────────────────────────────────────────────────────────┘이 구분이 왜 중요한가:
┌──────────────────────────────────────────────────────┐
│ "볼륨 할당 대장을 엑셀로 관리하세요" │
│ │
│ 5대면 가능. 100대면 불가능. │
│ │
│ 볼륨 목록과 매핑 정보는 시스템이 알고 있다. │
│ → 스토리지 API에서 뽑으면 그게 실시간 볼륨 대장이다. │
│ 엑셀보다 정확하고, 항상 최신이다. │
│ │
│ 그런데 "이 볼륨이 ERP 서비스용"이라는 건 API에 없다. │
│ → 네이밍 컨벤션이 이 역할을 한다. │
│ 볼륨 이름 = 비즈니스 맥락. │
│ 네이밍이 개판이면? 서비스 매핑은 영원히 모른다. │
│ 그래서 7-1편에서 네이밍을 강조한 거다. │
└──────────────────────────────────────────────────────┘대규모 환경의 현재 상태 파악 — 도구별 접근
스토리지 100대의 현재 상태를 파악하는 방법은 규모에 따라 다르다.
┌──────────────────────────────────────────────────────────┐
│ 1~5대: CLI + 엑셀로 충분 │
│ 장비가 적으니 머릿속에 다 들어간다. │
│ 엑셀 볼륨 대장도 유지 가능하다. │
│ 벤더 GUI에서 수작업 확인해도 시간이 오래 안 걸린다. │
├──────────────────────────────────────────────────────────┤
│ 5~20대: 벤더 클라우드 도구 │
│ Active IQ(NetApp), Pure1, CloudIQ(Dell), InfoSight(HPE)│
│ 벤더별로 한 화면에서 여러 장비를 볼 수 있다. │
│ 단점: 벤더가 섞이면 도구가 분리된다. │
│ NetApp은 Active IQ에서, Dell은 CloudIQ에서. │
│ 통합 뷰가 없다. │
├──────────────────────────────────────────────────────────┤
│ 20~100대+: 통합 모니터링 도구 필수 │
│ STOR2RRD / XorMon: 멀티벤더 스토리지 전용 (11편) │
│ → 볼륨, 성능, 용량을 벤더 무관하게 한 화면에서. │
│ │
│ CMDB(ServiceNow, i-doit 등): 자산 + 구성 관리 │
│ → 장비 목록, 계약 정보, 담당자, 위치를 중앙 관리. │
│ → 스토리지 전용은 아니지만 자산 관리의 표준. │
│ │
│ 벤더 클라우드 도구는 여전히 쓴다. │
│ → 상세 분석, 펌웨어 권고, 사전 경고는 벤더 도구가 우위.│
│ → 통합 뷰는 STOR2RRD/CMDB, 상세 분석은 벤더 도구. │
└──────────────────────────────────────────────────────────┘100대 규모에서 "볼륨 대장"은 이런 식이 된다:
전통적 방식 (유지 불가):
엑셀에 수작업으로 볼륨 정보 입력
→ 누군가 볼륨을 만들 때마다 엑셀 업데이트
→ 3개월 뒤: 실제 볼륨 5,000개, 엑셀에는 4,200개.
800개가 어디서 생겼는지 모른다.
현실적 방식:
┌──────────────────────────────────────────────────────┐
│ · 볼륨 목록/매핑/용량 → 스토리지 API에서 자동 추출 │
│ (주기적 스크립트 또는 STOR2RRD) │
│ 이게 "살아있는 볼륨 대장"이다. │
│ │
│ · 서비스 매핑 → 네이밍 컨벤션에 의존 │
│ prd_erp_data_001이면 이름만 봐도 안다. │
│ 네이밍이 안 되어있는 레거시 볼륨은? │
│ → 한 번은 수작업으로 매핑해야 한다. (고통스럽다) │
│ 하지만 그 이후로는 네이밍 규칙을 지키면 유지된다.│
│ │
│ · 계약/담당자/설계 의도 → CMDB 또는 Wiki에 수작업 │
│ 이건 시스템에서 뽑을 수 없으니 사람이 관리해야. │
└──────────────────────────────────────────────────────┘구성도도 마찬가지다.
구성도를 수작업으로 유지하는 건 100대에서 불가능하다.
┌──────────────────────────────────────────────────────┐
│ 물리 토폴로지 (어떤 포트가 어디 연결): │
│ → FC Switch의 nameserver, Zoning 정보에서 추출 가능. │
│ Brocade: nodefind, zoneshow, nsshow │
│ Cisco: fcns database, zone name │
│ STOR2RRD/XorMon은 SAN 토폴로지를 자동으로 그린다. │
│ │
│ 논리 토폴로지 (어떤 볼륨이 어떤 호스트에): │
│ → LUN Masking/igroup 정보에서 추출 가능. │
│ │
│ "그림으로 된 예쁜 구성도"가 필요하면? │
│ → 전체 100대의 Visio 구성도를 유지하는 건 비현실적. │
│ 대신 "장비별 As-Built(8편)"는 장비 도입 때 만들고, │
│ 전체 현황은 도구에서 조회하는 구조가 현실적이다. │
└──────────────────────────────────────────────────────┘그럼 수작업으로 유지해야 하는 문서는 뭔가
시스템에서 뽑을 수 없는 것만 사람이 관리하면 된다. 핵심은 유지할 문서를 최소화하는 거다. 유지할 수 없는 문서를 만드는 건 시간 낭비다.
수작업으로 유지해야 하는 문서 (규모 무관):
┌──────────────────────────────────────────────────────────┐
│ 1. 장애 대응 런북 (Runbook) │
│ 사람이 읽는 절차서. 시스템에서 생성 불가. │
│ 시나리오별로 "이 순서대로 하면 된다"를 적어놓은 것. │
│ 장비가 100대여도 런북 시나리오는 10개 내외. │
│ (디스크 장애, 컨트롤러 장애, 용량 부족 등은 공통) │
│ 벤더가 다르면 벤더별 CLI만 다르게 적으면 된다. │
│ │
│ 2. 벤더 연락처 / 계약 정보 │
│ 서포트 전화번호, 계약 번호, 만료일, SLA 등급. │
│ 장비 100대라도 벤더는 3~4개. 유지 가능. │
│ CMDB에 넣든 Wiki에 넣든 엑셀에 넣든 상관없다. │
│ 새벽 3시에 찾을 수 있으면 된다. │
│ │
│ 3. 변경 이력과 설계 의도 │
│ "왜 이 볼륨의 QoS를 5,000 IOPS로 잡았는지" │
│ "왜 이 장비는 Tier 1에 안 넣었는지" │
│ → 변경 관리(10편)의 RFC에 사유를 적으면 자동으로 쌓임.│
│ 별도 문서가 아니라 티켓/RFC 안에 기록하는 게 유지 가능.│
│ │
│ 4. 네이밍 컨벤션 규칙서 │
│ 네이밍 규칙 자체를 문서로 남겨야 한다. │
│ 이건 한 번 만들면 거의 안 바뀐다. 유지 비용 최소. │
│ 신규 입사자가 "볼륨 이름을 어떻게 짓나요?"에 답하는 │
│ 문서. 이게 없으면 사람마다 다르게 짓는다. │
└──────────────────────────────────────────────────────────┘
수작업 문서가 필요 없는 것 (시스템이 진실):
┌──────────────────────────────────────────────────────────┐
│ · 볼륨 목록/매핑/용량 → 스토리지 API에서 추출 │
│ · Zoning 현황 → FC Switch에서 추출 │
│ · IP 할당 → 스토리지 포트 설정에서 추출 │
│ · 성능/용량 현황 → 모니터링 도구(11편) │
│ · 디스크 상태 → 스토리지 CLI/모니터링 │
│ · 스냅샷 현황 → 스토리지 API에서 추출 │
│ │
│ 이것들을 엑셀로 따로 관리하면? │
│ → 시스템과 불일치. "엑셀에는 있는데 실제로 없는 볼륨." │
│ → "둘 중 뭐가 맞나요?" → 시스템이 맞다. 항상. │
│ → 그러면 엑셀은 왜 만들었나? 시간 낭비. │
└──────────────────────────────────────────────────────────┘자동화의 현실 — 뭘 자동화할 수 있고 뭘 못 하는가
자동화의 이상은 "Ansible Playbook 하나로 모든 벤더의 볼륨을 관리"하는 거다. 현실은 그렇지 않다.
자동화가 안 되는 이유:
┌──────────────────────────────────────────────────────────┐
│ · 벤더 × 모델 × 펌웨어 버전 조합이 너무 많다. │
│ ONTAP 9.12의 API와 9.14가 다르고, │
│ PowerStore와 PowerMax는 API가 완전히 다르다. │
│ 100대에 벤더 3개, 모델 8개, 펌웨어 5개 버전이면 │
│ 조합이 수십 가지. 각각 테스트하고 유지보수? │
│ │
│ · 자동화 코드도 유지보수 대상이다. │
│ 3년 전 스크립트. 만든 사람 퇴사. Python 2. 벤더 API v1.│
│ 누가 고치나? │
│ │
│ · 스토리지 작업은 비정형이 많다. │
│ "성능이 느린데 원인이 뭔가요?" → 자동화 불가. │
│ "컨트롤러 Giveback 해도 되나요?" → 판단이 필요. │
└──────────────────────────────────────────────────────────┘그래도 자동화할 수 있는 건 있다. 읽기 전용 작업이다.
현실적으로 자동화 가능한 것 (리스크 낮음):
┌──────────────────────────────────────────────────────────┐
│ ① 조회/리포트 — 읽기 전용이라 잘못해도 안전 │
│ · 전 장비 용량 사용률 자동 수집 → 리포트 │
│ · 미사용 볼륨(IO=0) 탐지 → 리스트 발송 │
│ · 디스크 Wear Level 주기적 점검 │
│ · 스냅샷 보관 현황 점검 │
│ │
│ 도구: Python + REST API + cron │
│ 또는 STOR2RRD/XorMon이 이걸 이미 해준다. │
│ │
│ ② 알림 자동화 — 모니터링 도구에 위임 │
│ · 용량 80% 초과 → Slack/이메일 알림 │
│ · 디스크 장애 → 즉시 알림 │
│ · 이건 Zabbix/Prometheus/STOR2RRD의 알림 기능을 쓴다. │
│ 별도 스크립트를 만들기보다 도구의 기능을 활용. │
└──────────────────────────────────────────────────────────┘
자동화하기 어려운 것 (리스크 높거나 비정형):
┌──────────────────────────────────────────────────────────┐
│ · 볼륨 생성/삭제 (멀티벤더면 벤더별 코드 따로 유지보수) │
│ · Zoning 변경 (실수하면 서비스 중단. 리스크 과대) │
│ · 장애 대응 (상황 판단 필요. 자동화 불가) │
│ · 펌웨어 업그레이드 (사전 검증 필요) │
│ · QoS/성능 튜닝 (워크로드 분석 후 판단) │
│ │
│ 이런 건 수작업이 맞다. │
│ 대신 런북으로 절차를 표준화해서 실수를 줄인다. │
└──────────────────────────────────────────────────────────┘단일 벤더 환경이면 Ansible이 효과적일 수 있다. NetApp만 50대인 환경이면 netapp.ontap Collection으로 볼륨 생성을 Playbook화하는 게 의미가 있다. 하지만 NetApp + Dell + Pure가 섞인 100대면? 벤더별로 Playbook을 따로 만들고, 모델별로 분기하고, 펌웨어 버전 호환성을 추적해야 한다. 그 코드를 유지보수할 인력이 있는가? 없으면 자동화 코드 자체가 레거시가 된다.
런북 — 자동화 못 하는 것을 표준화하는 문서
런북은 규모와 상관없이 수작업 문서가 맞다. 사람이 읽는 거니까.
런북을 쓸 때의 원칙:
┌──────────────────────────────────────────────────────┐
│ · 신입 엔지니어가 따라 할 수 있는 수준 │
│ · 명령어는 복사-붙여넣기 가능하게 │
│ · 판단 기준을 숫자로 명시 │
│ "느리면 확인" (X) │
│ "Latency 10ms 이상이면 Sev2 에스컬레이션" (O) │
│ · 서포트 콜 번호를 런북 안에 적는다 │
│ · 벤더가 여러 개면 벤더별 CLI를 병기 │
└──────────────────────────────────────────────────────┘
장비 100대여도 런북 시나리오는 10개 내외:
1. 디스크 장애 (단일/이중)
2. 컨트롤러 페일오버
3. 경로 단절 (단일/전체)
4. 성능 급감
5. 용량 부족 긴급
6. 볼륨 생성 절차 (표준)
7. 볼륨 확장 절차 (표준)
8. 볼륨 삭제 절차 (안전)
9. 펌웨어 업그레이드 사전 체크
10. 벤더 서포트 콜 절차
장비 수가 늘어나도 시나리오 종류는 같다.
벤더가 다르면 같은 시나리오에 벤더별 CLI를 병기하면 된다. 런북 예시 (컨트롤러 페일오버 — 멀티벤더):
┌──────────────────────────────────────────────────────┐
│ [상황] 컨트롤러 장애 알람 │
│ │
│ [확인] │
│ NetApp: > storage failover show │
│ Dell: PowerStore Manager → System → HA Status │
│ Pure: $ purecli array list --controller │
│ │
│ [판단] │
│ · 페일오버 완료 + 서비스 정상 → Sev2 │
│ · 페일오버 안 됨 + IO 중단 → Sev1 긴급 │
│ │
│ [서포트 콜] │
│ NetApp: 1588-xxxx / 계약: SUP-NT-xxxx │
│ Dell: 1588-yyyy / 계약: SUP-DL-yyyy │
│ Pure: 1588-zzzz / 계약: SUP-PR-zzzz │
└──────────────────────────────────────────────────────┘네이밍 컨벤션이 문서화를 대신한다
100대 환경에서 "이 볼륨이 무슨 서비스인지"를 별도 문서로 관리하는 건 불가능하다. 네이밍 컨벤션이 곧 문서화다.
네이밍이 잘 되어있으면:
$ vol show | head -5
prd_erp_data_001 2TB svm_prd_01
prd_erp_log_001 500G svm_prd_01
prd_web_data_001 1TB svm_prd_02
dev_test_data_001 500G svm_dev_01
→ 이름만 봐도 "운영 ERP 데이터", "개발 테스트"가 보인다.
→ 별도 볼륨 대장이 없어도 현재 상태를 파악할 수 있다.
네이밍이 안 되어있으면:
$ vol show | head -5
vol037 2TB svm01
data_new_2 500G svm01
backup_old_final_v3 1TB svm02
test123 500G svm03
→ 이게 뭔지 아무도 모른다. 만든 사람도 모른다.
→ 별도 문서 없이는 서비스 매핑 불가.
→ 그런데 별도 문서를 만들어도 유지가 안 된다.
→ 결국 "물어봐야 아는" 상태가 영구적으로 지속.
교훈:
네이밍 컨벤션은 "처음에 잡지 않으면 영원히 못 잡는" 것이다.
이미 수천 개가 vol037 식으로 있으면?
→ 신규 볼륨부터라도 규칙을 적용한다.
→ 기존 건 서비스 매핑을 한 번 조사해서 태그/설명 필드에
넣는다 (벤더에 따라 볼륨에 comment/description 필드가 있음).
→ 이름 자체를 바꾸는 건 호스트 마운트까지 변경해야 해서
현실적으로 어렵다. 그래서 처음에 잡는 게 중요하다.현실적 운영 개선 순서
┌──────────────────────────────────────────────────────┐
│ Phase 1: 현재 상태 파악 능력 확보 │
│ │
│ · 모니터링 도구(STOR2RRD 또는 벤더 도구)로 │
│ 전 장비 현황을 한 화면에서 볼 수 있게 한다. │
│ · 이게 "살아있는 볼륨 대장"이자 "살아있는 구성도"다. │
│ · 별도 엑셀 문서를 만드는 게 아니라 │
│ 시스템에서 언제든 뽑을 수 있는 구조를 만드는 거다. │
├──────────────────────────────────────────────────────┤
│ Phase 2: 사람만 아는 정보 정리 │
│ │
│ · 런북 작성 (주요 시나리오 10개) │
│ · 벤더 연락처/계약 정보 정리 │
│ · 네이밍 컨벤션 규칙서 작성 │
│ · 레거시 볼륨 서비스 매핑 (한 번만 하면 됨) │
├──────────────────────────────────────────────────────┤
│ Phase 3: 읽기 전용 자동화 │
│ │
│ · 용량 리포트 자동 수집/발송 │
│ · 미사용 볼륨/오래된 스냅샷 탐지 │
│ · 알림 자동화 (모니터링 도구 연동) │
├──────────────────────────────────────────────────────┤
│ Phase 4: 선택적 자동화 (환경에 따라) │
│ │
│ · 단일 벤더 + 단일 모델이 대다수면 Ansible 도입 검토 │
│ · 멀티벤더면? "통합하려는 욕심을 버린다." │
│ 벤더별 스크립트 분리 관리가 현실적이다. │
│ · 자동화 코드를 유지보수할 인력이 없으면 │
│ 만들지 않는 게 낫다. 방치된 코드는 함정이다. │
└──────────────────────────────────────────────────────┘자동화와 문서화에 대해 한 마디로 정리하면 이렇다.
┌──────────────────────────────────────────────────────┐
│ · 시스템이 아는 건 시스템에서 뽑는다. 별도 문서 X. │
│ · 사람만 아는 건 사람이 적는다. 최소한만. │
│ · 유지할 수 없는 문서는 만들지 않는다. │
│ · 네이밍 컨벤션이 최고의 문서화 전략이다. │
│ · 자동화는 읽기 전용부터. 쓰기는 신중하게. │
│ · 런북은 규모와 상관없이 필수다. │
└──────────────────────────────────────────────────────┘다음 편은 시리즈의 마지막이다. 클라우드 시대에 스토리지가 어떻게 변하고 있는지, 그리고 스토리지 엔지니어가 어떻게 살아남을 것인가.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
7-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
스토리지 설계의 데이터 편. LUN 분리 장단점, 네이밍 컨벤션, 스냅샷 동작 원리와 리스크, DR 동기/비동기 복제 트레이드오프, Active-Active 메트로 클러스터의 Split-Brain 리스크까지. 인프라 위에 데이터를 배치하고 보호하는 설계의 후반부.
2026. 05. 18. PM 10:00Infrastructure17. 마이그레이션과 폐기
마이그레이션 4가지 방식(호스트/스토리지/패브릭/가상화) 비교, 사전 동기화+컷오버 패턴, 다운타임 최소화, 벤더별 도구, 롤백 계획, 데이터 검증, 구 장비 정리 체크리스트, 데이터 완전 삭제 3가지 방법(Crypto Erase/Secure Erase/물리 파쇄), 폐기 절차까지. 스토리지 라이프사이클의 마지막 단계.
2026. 07. 27. PM 10:00Infrastructure16. 유지보수 계약과 수명 관리 — EOS/EOL 대응
유지보수 계약 구조와 비용 현실, 벤더 직접/파트너/TPM 비교, EOS/EOL 관리와 3가지 선택지, EOS 전 반드시 해야 할 4가지, SSD Wear Level과 NVRAM 배터리 관리, 교체 주기(3/5/7년) 비교, 교체 시기 판단 프레임워크, 자산 대장 관리까지. 스토리지 수명의 끝을 준비하는 법.
2026. 07. 20. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...