8. 구축 — 초기 설정과 호스트 연결

  스토리지 구축 전체 흐름:
  
  ① 물리 설치 → ② 초기 설정 → ③ 펌웨어 확인
       → ④ 호스트 연결 → ⑤ multipath/마운트
            → ⑥ 성능 테스트 → ⑦ As-Built 문서화
                 → 다음: 인수시험 (9편)

  랙 설치 체크리스트:
  
  ┌──────────────────────────────────────────────────────┐
  │ □ 전원 이중화                                         │
  │   PSU A → PDU A (분전반 A 계통)                      │
  │   PSU B → PDU B (분전반 B 계통)                      │
  │   ⚠ 같은 PDU에 두 전원 꽂으면 이중화 의미 없음       │
  │   ⚠ 전원 용량(KVA) 초과하면 브레이커가 내려간다      │
  │                                                      │
  │ □ 케이블 레이블링                                      │
  │   양쪽 끝에 라벨 부착. 안 붙이면 6개월 뒤 추적 불가.  │
  │   형식: STG01-FC0a ↔ SWA-Port03                      │
  │                                                      │
  │ □ FC 케이블링                                         │
  │   SFP 호환성 확인 (벤더 호환 목록 필수!)              │
  │   → 비호환 SFP: 링크 불안정, 간헐적 CRC 에러         │
  │   OM4 (100m) vs OM3 (70m). 32Gbps는 OM4 권장.       │
  │   이중화: Ctrl A → Switch A, Ctrl B → Switch B       │
  │   ⚠ 같은 Switch에 두 컨트롤러 다 연결하면 안 됨      │
  │                                                      │
  │ □ 네트워크 케이블링                                    │
  │   관리: 1GbE 전용 VLAN / 데이터: 10G~100G 전용 VLAN  │
  └──────────────────────────────────────────────────────┘

  올바른 FC 이중화 케이블링:
  
  [스토리지]                          [FC Switch]
  Ctrl A ── Port 0a ──────────────── Switch A (Fabric A)
  Ctrl A ── Port 0c ──────────────── Switch B (Fabric B)
  Ctrl B ── Port 0a ──────────────── Switch A (Fabric A)
  Ctrl B ── Port 0c ──────────────── Switch B (Fabric B)
  
  [서버]
  HBA Port 0 ────────────────────── Switch A (Fabric A)
  HBA Port 1 ────────────────────── Switch B (Fabric B)
  
  → 경로 최소 4개. Switch 1개 죽어도, Ctrl 1개 죽어도 접근 가능.

  초기 설정 순서:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 관리 IP / DNS / NTP                               │
  │    → 관리 접속 없이는 이후 설정 불가                  │
  │    ⚠ NTP 필수! 시간 안 맞으면 로그 시간이 뒤죽박죽,  │
  │      장애 분석 시 "뭐가 먼저였는지" 추적 불가.       │
  │      복제/스냅샷 시각도 부정확해짐.                   │
  ├──────────────────────────────────────────────────────┤
  │ 2. 클러스터 구성 (듀얼 컨트롤러 결합)                │
  │    HA Pair 구성. HA Interconnect 링크 상태 확인.     │
  │    ⚠ HA 케이블 빠져있으면 페일오버가 안 된다.        │
  ├──────────────────────────────────────────────────────┤
  │ 3. 디스크 확인 / 스토리지 풀 생성                    │
  │    디스크 전수 확인 (수량, 용량, 상태). RAID 설정.   │
  │    벤더별: NetApp=aggregate, Dell=자동 풀, Pure=자동  │
  ├──────────────────────────────────────────────────────┤
  │ 4. 네트워크 인터페이스 설정                           │
  │    FC 포트 속도, iSCSI IP/MTU, NFS/SMB 데이터 LIF   │
  ├──────────────────────────────────────────────────────┤
  │ 5. 볼륨/LUN 프로비저닝 (설계 문서 기준)              │
  ├──────────────────────────────────────────────────────┤
  │ 6. 관리자 계정 / RBAC                                │
  │    ⚠ 기본 admin 비밀번호 변경 필수                   │
  │    ⚠ RBAC 없으면 "누가 뭘 했는지" 추적 불가          │
  ├──────────────────────────────────────────────────────┤
  │ 7. 알림 설정 (SNMP Trap, Email, AutoSupport)         │
  │    ⚠ 알림 안 하면 디스크 죽은 걸 모르고 두 번째가    │
  │      나가서야 발견                                   │
  ├──────────────────────────────────────────────────────┤
  │ 8. 스냅샷/복제 정책 적용                             │
  └──────────────────────────────────────────────────────┘

  벤더별 호환 매트릭스 도구:
  
  NetApp  → IMT (mysupport.netapp.com/matrix)
  Dell    → SolVe / E-Lab
  HPE     → SPOCK
  Pure    → support.purestorage.com
  
  ┌──────────────────────────────────────────────────────┐
  │ 초기 구축 시 최신 펌웨어를 적용할 것인가?             │
  ├─────────────────────────────┬────────────────────────┤
  │ 출하 펌웨어가 안정 버전이고 │ 그대로 유지.           │
  │ 호환 매트릭스에 문제 없음   │                        │
  ├─────────────────────────────┼────────────────────────┤
  │ 알려진 버그가 있거나        │ 업그레이드.            │
  │ 호스트 OS와 비호환          │                        │
  ├─────────────────────────────┼────────────────────────┤
  │ 최신 GA 버전이 나옴         │ GA 직후는 숨은 버그    │
  │                            │ 가능. 벤더 권장 확인.  │
  └─────────────────────────────┴────────────────────────┘
  
  ⚠ 호환 매트릭스에 없는 조합으로 운영하면, 장애 시
    벤더가 "호환되지 않는 구성" 이라며 지원을 거부할 수 있다.

  FC 호스트 연결 절차:
  
  Step 1: FC Switch에서 Zoning 설정
  ─────────────────────────────────
  
  # Brocade FC Switch CLI 예시
  
  # Alias 생성 (WWPN에 이름 붙이기)
  alicreate "srv_prd_erp_db01_hba0", "10:00:00:00:c9:xx:xx:01"
  alicreate "stg_netapp01_0a",       "50:00:0a:xx:xx:xx:xx:0a"
  
  # Zone 생성 (서버 HBA ↔ 스토리지 포트)
  zonecreate "z_erp_db01_netapp01", \
    "srv_prd_erp_db01_hba0; stg_netapp01_0a"
  
  # Zoneset에 추가 후 활성화
  cfgadd "cfg_production", "z_erp_db01_netapp01"
  cfgenable "cfg_production"
  cfgsave
  
  ⚠ cfgenable 실행 순간에 Zoning이 적용된다.
    잘못된 Zoneset을 활성화하면 기존 서비스가 끊길 수 있다.
    → 변경 전 cfgshow 결과를 반드시 백업
    → "cfgclear"는 전체 Zoning이 날아간다. 프로덕션에서 금지.
  
  
  Step 2: 스토리지에서 LUN Masking
  ────────────────────────────────
  
  # NetApp ONTAP
  igroup create -vserver svm01 -igroup ig_erp_db01 \
    -protocol fcp -ostype linux
  igroup add -vserver svm01 -igroup ig_erp_db01 \
    -initiator 10:00:00:00:c9:xx:xx:01
  lun map -vserver svm01 -path /vol/prd_erp_data/lun01 \
    -igroup ig_erp_db01 -lun-id 0
  
  # Dell PowerStore — Host 생성 → WWPN 등록 → Volume 매핑
  # Pure Storage — Host 생성 → WWPN 등록 → Volume connect
  
  ⚠ OS Type(linux/windows)을 잘못 설정하면
    LUN 사이즈가 다르게 보이거나 ALUA가 오동작한다.
  
  
  Step 3: 서버에서 LUN 인식
  ─────────────────────────
  
  $ echo "1" > /sys/class/fc_host/host0/issue_lip
  $ echo "- - -" > /sys/class/scsi_host/host0/scan
  $ multipath -ll
  
  
  LUN이 안 보일 때 확인 순서:
  ┌──────────────────────────────────────────────────────┐
  │ 1. FC Switch: Zoning에 WWPN이 제대로 들어갔는가?     │
  │    $ zoneshow | grep "erp_db01"                      │
  │                                                      │
  │ 2. FC Switch: 서버/스토리지 둘 다 FLOGI 됐는가?      │
  │    $ fcns database                                   │
  │                                                      │
  │ 3. 스토리지: igroup에 WWPN 등록됐는가?               │
  │    LUN이 igroup에 매핑됐는가?                        │
  │                                                      │
  │ 4. 서버: HBA 링크 상태가 Online인가? 속도 맞는가?    │
  │    $ systool -c fc_host -v                           │
  │                                                      │
  │ 위에서 아래로 순서대로 확인하면 대부분 원인이 잡힌다. │
  └──────────────────────────────────────────────────────┘

  iSCSI 호스트 연결 절차:
  
  # 서버 IQN 확인
  $ cat /etc/iscsi/initiatorname.iscsi
  
  # 스토리지에서: IQN 등록 + 볼륨 매핑 (벤더 CLI/GUI)
  
  # 타겟 검색
  $ iscsiadm -m discovery -t st -p 10.10.1.100:3260
  
  # 타겟 로그인
  $ iscsiadm -m node -T iqn.1992-08.com.netapp:sn.xxxx -l
  
  # 자동 로그인 설정 (재부팅 대비)
  $ iscsiadm -m node -T iqn... \
    --op update -n node.startup -v automatic
  
  iSCSI 주의사항:
  ┌──────────────────────────────────────────────────────┐
  │ · 전용 VLAN 필수. 서비스 트래픽과 섞으면 성능 불안정 │
  │                                                      │
  │ · Jumbo Frame 쓸 거면 경로 전체 MTU 확인             │
  │   $ ping -M do -s 8972 10.10.1.100                   │
  │   실패하면 어딘가 MTU가 안 맞는 거다                  │
  │                                                      │
  │ · 세션 타임아웃(replacement_timeout) 벤더 권장값으로  │
  │   변경. 기본 120초면 경로 장애 시 2분간 IO 멈춤.     │
  │                                                      │
  │ · FC보다 경로 장애 감지가 느리다 (TCP 타임아웃 의존). │
  │   미션 크리티컬 환경에서는 이 점을 감안해야 한다.     │
  └──────────────────────────────────────────────────────┘

  NFS 호스트 연결 절차:
  
  # 스토리지에서 Export 설정 (NetApp 예시)
  export-policy rule create -vserver svm01 \
    -policyname exp_erp -clientmatch 10.10.0.0/24 \
    -rorule sys -rwrule sys -superuser sys
  
  # 서버에서 마운트
  $ mount -t nfs -o rw,hard,rsize=1048576,wsize=1048576,\
  tcp,vers=3,bg 10.10.1.100:/vol_share /mnt/share
  
  # fstab 등록
  10.10.1.100:/vol_share /mnt/share nfs \
    rw,hard,rsize=1048576,wsize=1048576,tcp,vers=3,\
    _netdev,nofail,bg 0 0
  
  NFS 마운트 옵션 — 핵심만:
  ┌──────────────┬───────────────────────────────────────┐
  │ rsize/wsize  │ 1MB로 올려야 처리량 개선.             │
  │              │ 기본값이 작은 경우가 많다.             │
  ├──────────────┼───────────────────────────────────────┤
  │ hard         │ 서버 응답까지 무한 대기. 데이터 무결성│
  │              │ 위해 권장. 단, NFS 서버 장애 시       │
  │              │ 프로세스가 hang에 빠질 수 있다.       │
  ├──────────────┼───────────────────────────────────────┤
  │ bg           │ 마운트 실패 시 백그라운드 재시도.     │
  │              │ 없으면 NFS 서버 안 될 때 부팅 멈춤.   │
  ├──────────────┼───────────────────────────────────────┤
  │ _netdev      │ 네트워크 활성화 후 마운트.            │
  │ nofail       │ 마운트 실패해도 부팅 계속.            │
  │              │ ⚠ 둘 다 빠뜨리면 스토리지 장애 시     │
  │              │   서버 부팅이 영원히 멈춘다.          │
  ├──────────────┼───────────────────────────────────────┤
  │ actimeo      │ 속성 캐시. DB용=0, 일반=60.           │
  │              │ 0이면 메타데이터 요청 많아져 NAS 부하.│
  └──────────────┴───────────────────────────────────────┘

  벤더별 multipath.conf 핵심 차이:
  
  ┌──────────────┬──────────────────────────────────────────┐
  │ NetApp ONTAP │ prio: ontap (전용 모듈)                  │
  │              │ no_path_retry: queue                     │
  │              │ → 모든 경로 끊겨도 IO를 큐에 보관.      │
  │              │   장점: IO 유실 방지                     │
  │              │   단점: 경로 안 돌아오면 프로세스 hang   │
  ├──────────────┼──────────────────────────────────────────┤
  │ Dell         │ prio: alua                               │
  │ PowerStore   │ no_path_retry: 벤더 문서 확인            │
  ├──────────────┼──────────────────────────────────────────┤
  │ Pure Storage │ multipath.conf를 거의 안 건드려도 됨    │
  │              │ 장점: 단순함. 단점: 세밀한 제어 제한적.  │
  ├──────────────┼──────────────────────────────────────────┤
  │ HPE Alletra  │ prio: alua                               │
  │              │ 벤더 제공 설치 스크립트 사용 권장         │
  └──────────────┴──────────────────────────────────────────┘

  multipath -ll 출력 읽는 법:
  
  $ multipath -ll
  
  3600a09803831...(dm-0) NETAPP,LUN
  size=500G features='3 queue_if_no_path pg_init_retries 50'
  ├─ policy='round-robin' prio=50 status=active
  │  ├─ 1:0:0:0 sda 8:0   active ready  running  ← Optimized
  │  └─ 2:0:0:0 sdb 8:16  active ready  running  ← Optimized
  └─ policy='round-robin' prio=10 status=enabled
     ├─ 1:0:1:0 sdc 8:32  active ready  running  ← Non-Optimized
     └─ 2:0:1:0 sdd 8:48  active ready  running  ← Non-Optimized
  
  ┌──────────────────────────────────────────────────────┐
  │ prio=50       │ ALUA Optimized 경로 (우선)           │
  │ prio=10       │ Non-Optimized 경로 (대기)            │
  │ active ready  │ 정상                                 │
  │ faulty        │ ← 경로 장애! 원인 확인 필요          │
  └──────────────────────────────────────────────────────┘
  
  정상: 4개 모두 active ready running
  경고: 1~2개 faulty → 이중화 중이지만 원인 확인
  위험: 전부 faulty → IO 중단! 즉시 대응
  
  faulty일 때: Switch 포트 → 케이블 → 스토리지 컨트롤러 순으로 확인

  ┌──────────────┬───────────────────┬───────────────────┐
  │              │      ext4         │      XFS          │
  ├──────────────┼───────────────────┼───────────────────┤
  │ 대용량 성능  │ 보통              │ 우수              │
  ├──────────────┼───────────────────┼───────────────────┤
  │ 온라인 축소  │ O (가능)          │ X (불가!)         │
  ├──────────────┼───────────────────┼───────────────────┤
  │ 복구 속도    │ fsck 빠름         │ xfs_repair 느릴 수│
  ├──────────────┼───────────────────┼───────────────────┤
  │ 권장         │ 소~중규모, 부트   │ 대용량(1TB+), DB  │
  └──────────────┴───────────────────┴───────────────────┘
  
  스토리지 볼륨용은 XFS가 주류 (RHEL 7+ 기본).
  XFS는 축소 불가이므로, 줄일 가능성 있으면 ext4 고려.
 
  $ mkfs.xfs /dev/mapper/3600a09803831...
  $ mkdir -p /data/erp
  
  # fstab
  /dev/mapper/3600a09803831... /data/erp xfs _netdev,nofail 0 0

  $ fio --name=randread --filename=/data/erp/fio_test \
    --ioengine=libaio --direct=1 --bs=4k \
    --iodepth=32 --rw=randread --size=1G \
    --runtime=60 --time_based --group_reporting
  
  결과 읽는 법:
  ┌──────────────────────────────────────────────────────┐
  │ read: IOPS=85.2k, BW=333MiB/s                       │
  │   lat (usec): avg=372.15                             │
  │   clat percentiles: 99.00th=[ 1172]                  │
  │                                                      │
  │ → IOPS=85,200, 평균 0.37ms, p99=1.17ms              │
  │                                                      │
  │ 기대보다 낮으면:                                      │
  │ 1. direct=1 확인 (OS 캐시 우회 여부)                  │
  │ 2. multipath 경로 수 확인 (1개면 절반 성능)           │
  │ 3. 컨트롤러 CPU 확인 / 네트워크 대역폭 확인          │
  └──────────────────────────────────────────────────────┘
  
  ⚠ 쓰기 테스트는 빈 볼륨에서만! 프로덕션 데이터를 덮어쓴다.
  ⚠ 씬 프로비저닝 환경에서 대량 쓰기 → 물리 공간 급소비. 테스트 후 삭제.

  As-Built 문서 필수 항목:
  
  ┌──────────────────────────────────────────────────────┐
  │ 1. 장비 정보 (모델, 시리얼, 펌웨어, 디스크 구성)     │
  │ 2. 네트워크 (관리IP, 데이터IP, FC WWPN, VLAN)       │
  │ 3. 포트 맵핑 (스토리지↔스위치↔서버 연결 테이블)      │
  │ 4. Zoning 테이블 (Zone명, Alias, WWPN, Zoneset)     │
  │ 5. 볼륨 할당 현황 (이름, 크기, Tier, 호스트, 마운트) │
  │ 6. 관리 도구 접속 정보 (URL, SSH, 계정)              │
  │ 7. 초기 성능 측정 결과 (fio Baseline)                │
  │ 8. 벤더 지원 정보 (계약번호, SE 연락처)              │
  │ 9. 설계 대비 변경 사항 + 변경 사유                   │
  └──────────────────────────────────────────────────────┘
  
  안 만들면 벌어지는 일:
  · 담당자 퇴사 시 인수인계 불가
  · 장애 시 구성 파악에만 30분~1시간 소요
  · 벤더 서포트 콜에서 "구성이 어떻게 되나요?"에 못 답함
  · 증설/마이그레이션 시 현재 상태 전수 조사부터 다시

  벤더별 관리 도구:
  
  ┌──────────────┬──────────────────────────────────────┐
  │ NetApp       │ CLI(ssh) + System Manager(GUI)       │
  │              │ + Active IQ(클라우드)                 │
  │              │ CLI가 강력. 학습 곡선 높음.           │
  ├──────────────┼──────────────────────────────────────┤
  │ Dell         │ PowerStore Manager(GUI) + CLI        │
  │              │ + CloudIQ(클라우드)                   │
  │              │ GUI가 직관적.                        │
  ├──────────────┼──────────────────────────────────────┤
  │ Pure Storage │ Pure1(클라우드 기반 GUI) + CLI        │
  │              │ 관리가 매우 단순. 세밀한 튜닝 제한적. │
  ├──────────────┼──────────────────────────────────────┤
  │ HPE Alletra  │ Management Console + InfoSight        │
  │              │ InfoSight 예측 분석이 강점.           │
  └──────────────┴──────────────────────────────────────┘