(하드웨어 진단 → 커널 튜닝 → 스토리지/네트워크 → HA/DR까지, 운영자가 바로 쓰는 체크리스트 중심)

목차

• [서론]  왜 지금도 HP-UX 운영 역량이 중요할까
• [본론]
  • 1. 하드웨어 아키텍처/무결성 진단: machinfo / ioscan / cstm
    2. 커널 파라미터 최적화: kctune + “수학적 모델링” 실전 적용
    3. 스토리지/LVM/VxFS: vgdisplay / lvdisplay / vxfsstat / bdf
    4. SAN/FC 진단: fcmsutil / scsimgr
    5. 메모리 병목 분석: vmstat + dbc_max_pct
    6. 네트워크 진단: nwmgr / lanadmin 에러 카운터 해석
    7. 성능 모니터링: glance(gpm) / sar 로 병목 분해
    8. 고가용성/재해복구: cmviewcl / make_tape_recovery
    9. 로그 기반 장애 예측: syslog 패턴 운영
• [결론] 운영 철학 3요소 + 3줄 요약
• [치트 시트] 한 장으로 끝내는 명령어/정상기준/이상징후

[서론] 왜 지금도 HP-UX 운영 역량이 중요할까

이 장이 왜 중요한지: 운영자의 판단이 곧 다운타임 비용을 좌우해요.

HP-UX는 RAS(신뢰성·가용성·서비스 용이성)를 목표로 설계됐습니다.
그래서 “명령어를 아는 수준”을 넘어서, 출력값의 행간을 읽고 선제 대응하는 운영 방식이 중요해요.

• HP-UX 11i v1(11.11) → v2(11.23) → v3(11.31)로 오면서
  Native Multipathing, 동적 커널 튜닝, 통합 네트워크 관리가 강화됐습니다.
• 이 글은
  진단 → 해석 → 조치가 이어지는 “운영자 플레이북”입니다.

[본론]

1) 하드웨어 아키텍처/무결성 진단 (machinfo / ioscan / cstm)

이 장이 왜 중요한지: 하드웨어가 흔들리면 커널/스토리지/네트워크 튜닝은 의미가 없고, 장애는 결국 물리 계층에서 터져요.

1-1. 플랫폼 정체성 확인: uname/model/machinfo

가장 먼저 “내가 뭘 운영 중인지”를 확인합니다.
유지보수 계약, 패치 레벨, 호환성 검증의 시작점이에요.

uname -a
model
machinfo

uname -a
model
machinfo

• uname -a: OS/커널/노드 기본값 확인
• model: 서버 모델명 확인(자산/계약/호환성)
• machinfo: CPU/메모리/펌웨어까지 디테일 확인(특히 Integrity/IA64 계열)

🧠 엔지니어의 한 끗 차이 노하우
machinfo “Memory” 섹션은 ‘장착 용량’이 아니라 ‘OS가 신뢰하는 용량’이에요.
표시 용량이 물리 장착보다 작으면, 특정 DIMM이 펌웨어 레벨에서 Deconfigured(PDT 기반 비활성화) 됐을 가능성이 높습니다.
👉 조치: “OS 튜닝”부터 하지 말고, 즉시 하드웨어 교체/점검 플로우로 전환하세요.

1-2. I/O 디바이스 트리/경로 확인: ioscan

I/O는 HP-UX 운영에서 자주 무너지는 축입니다.
디스크, HBA, FC, NIC 모두 여기서 출발해요.

ioscan -fn

ioscan -fn

• -f: Full listing
• -n: 디바이스 파일 노드까지 출력

Legacy View vs Agile View 핵심 비교

운영 난이도를 크게 바꾸는 포인트라 표로 고정해두는 게 좋아요.

ioscan -N

ioscan -N

• LUN 재할당, HBA 교체 후에는 커널 인식 상태를 다시 확인합니다.
• 특수 디바이스 파일 노드 동기화가 필요하면 아래를 씁니다.

insf -e

insf -e

1-3. STM(cstm)로 “OS 밖의 디테일”을 긁어오기

OS 명령에서 안 보이는 저수준 신호는 STM이 잡습니다.

echo "map; wait; info; wait; infolog" | cstm

echo "map; wait; info; wait; infolog" | cstm

• map: 하드웨어 맵 생성
• info: 장치 정보 수집
• wait: 단계 완료 대기(여기서 안정성 갈립니다)
• infolog: 로그 형태 출력

주의사항(실수 포인트)

• 운영 중 과도한 진단은 지연(Latency)을 만들 수 있어요.
• 특히 I/O 부하가 큰 시간대면, wait 없이 연쇄 실행하는 습관이 사고로 이어집니다.

2) 커널 파라미터 최적화 (kctune) + 수학적 모델링

이 장이 왜 중요한지: HP-UX 성능은 “커널 테이블의 크기”에서 무너지고, 그 신호는 장애로 먼저 나타나요.

2-1. 동적 튜닝의 기본: kctune

11i v3에서 운영 난이도가 내려간 이유가 동적 변경이에요.

kctune -v maxfiles

kctune -v maxfiles

예시 출력에서 꼭 봐야 하는 줄:

• Current Value
• Value at Next Boot
• Capabilities: dynamic (즉시 적용 가능)

동적 vs 정적 파라미터 운영 규칙(요약 표)

2-2. “수학적 모델링”을 운영 언어로 번역하기

값을 크게 잡는다고 안정적이지 않습니다.
커널 메모리를 태워서 다른 병목을 만들 수 있어요.

🧠 엔지니어의 한 끗 차이 노하우
커널 튜닝은 “희망값”이 아니라 워크로드 기반 추정값이어야 해요.
nproc만 보고 끝내지 말고, Java/WAS라면 nkthread가 먼저 병목이 됩니다.
또한 ncallout 부족은 성능 저하가 아니라 패닉으로 튀기 때문에 우선순위가 높아요.

(1) 프로세스/스레드: nproc, nkthread

• 멀티스레드 워크로드는 nkthread가 먼저 부족해집니다.
• 가이드라인(운영자용 표현):
  • “프로세스 수 × 평균 스레드 수 + 시스템 오버헤드” 정도는 확보해야 안전합니다.
• nkthread 부족 시:
  • fork() 실패
  • "Resource temporarily unavailable" 류의 오류가 등장합니다.

(2) 파일 디스크립터: maxfiles, maxfiles_lim, nfile

웹/소켓 중심 워크로드는 파일 디스크립터가 곧 연결 수입니다.

• maxfiles: 프로세스당 소프트 제한
• maxfiles_lim: 하드 제한
• nfile: 시스템 전체 오픈 파일 테이블

운영 감각:

• maxfiles는 최소 4096 이상을 기본선으로 보고,
• nfile은 nproc에 비례해 충분히 크게 잡습니다.

(3) 타이머 테이블: ncallout

• 스레드/네트워크/I/O가 많을수록 타이머가 늘어납니다.
• 부족하면:
  • "Callout Table Overflow"
  • 커널 패닉으로 이어질 수 있어요.

즉시 점검 체크리스트

• ( ) 장애 로그에 fork 실패/FD 부족/Callout overflow가 있는가
• ( ) kctune로 현재값/부팅값/동적 여부를 분리해 확인했는가
• ( ) 변경 근거(트래픽/접속수/스레드 수)를 숫자로 남겼는가

2-3. 구성 문서화: print_manifest

튜닝 시스템은 “기억”으로 운영하면 복구가 늦습니다.
문서가 곧 DR(재해복구) 속도예요.

print_manifest
# 결과 예시 경로:
# /var/opt/ignite/local/manifest/manifest.html

print_manifest
# 결과 예시 경로:
# /var/opt/ignite/local/manifest/manifest.html

3) 스토리지/LVM/VxFS 엔지니어링

이 장이 왜 중요한지: 스토리지는 “느림”으로 시작해서 “데이터 손상”으로 끝나기 때문에, 상태 기준을 고정해야 해요.

3-1. VG 건강 상태: vgdisplay -v

vgdisplay -v vg00

vgdisplay -v vg00

• VG Status: 반드시 available
• Act PV: Total PV보다 작으면 장애/접근 불가 PV가 있다는 뜻

3-2. LV 미러링 상태: lvdisplay -v

lvdisplay -v /dev/vg00/lvolX

lvdisplay -v /dev/vg00/lvolX

• Mirror copies: 1 이상(미러링 구성 시)
• Stale extents: 반드시 0
  • 0이 아니면 데이터 불일치/동기화 이슈 가능

필요 시:

lvsync /dev/vg00/lvolX

lvsync /dev/vg00/lvolX

3-3. VxFS 성능/메타데이터 튜닝: vxfsstat + bdf/bdf -i

vxfsstat -v /mount_point
bdf
bdf -i

vxfsstat -v /mount_point
bdf
bdf -i

• bdf: 공간(%)만 보지 마세요.
• bdf -i: 아이노드 고갈은 “공간 남았는데 파일 생성 실패”로 터집니다.

🧠  엔지니어의 한 끗 차이 노하우
“디스크가 남아있는데도 장애”는 대개 아이노드/메타데이터 쪽이에요.
작은 파일이 많은 워크로드(메일/웹)는 VxFS inode 캐시가 병목이 됩니다.
vx_iget 계열 overflow가 보이면, 커널 파라미터(vx_ninode 등)를 의심하세요.

4) SAN/FC 진단 (fcmsutil / scsimgr)

이 장이 왜 중요한지: SAN은 “링크 UP”만 보고 안심하면, 간헐 오류가 데이터/성능을 같이 갉아먹어요.

4-1. HBA 상태 확인: fcmsutil

fcmsutil /dev/fcd0
fcmsutil /dev/fcd0 stat

fcmsutil /dev/fcd0
fcmsutil /dev/fcd0 stat

정상 기준(운영자 기준):

• Topology: FABRIC 또는 PUBLIC_LOOP
• Link State: UP
• 에러 카운터:
  • Loss of Signal, Link Failures가 증가 추세면 위험

의심 우선순위:

1. 광케이블 오염/벤딩
2. SFP 불량
3. 스위치 포트 이슈

4-2. Active-Passive 환경의 path thrashing 방지: scsimgr

• Active-Passive 스토리지는 경로 전환이 잦으면 성능이 급락합니다.
• 레거시 디바이스 파일의 멀티패스 속성은 scsimgr로 제어합니다.

5) 메모리 병목 분석 (vmstat) + dbc_max_pct 튜닝

이 장이 왜 중요한지: 메모리 병목은 CPU를 “일하는 시간”이 아니라 “페이지 교체”에 쓰게 만들어요.

5-1. vmstat로 스래싱을 숫자로 판단하기

vmstat 1 10

vmstat 1 10

핵심 컬럼:

• sr(Scan Rate)
  • 0이면 여유
  • 수백~수천이면 스래싱 가능성
• po(Page Out)
  • sr이 높고 po가 지속되면 증설/구조 조정이 급합니다.

5-2. DB 서버의 이중 캐싱 방지: dbc_max_pct

DB는 자체 캐시(SGA 등)가 있습니다.
OS 버퍼 캐시가 과하면 메모리 효율이 깨져요.

• dbc_max_pct를 10~20% 이하로 낮춰
  DB가 쓸 메모리를 확보하는 전략이 자주 유효합니다.

6) 네트워크 진단 (nwmgr/lanadmin) “에러 카운터 해석”

이 장이 왜 중요한지: 네트워크 문제는 ping으로 안 잡히고, 카운터는 거짓말을 안 해요.

6-1. 관리 도구의 진화: lanadmin → nwmgr

nwmgr --st -c lan0
# 예시 설정:
nwmgr -s -A speed=1000FD -c lan0

nwmgr --st -c lan0
# 예시 설정:
nwmgr -s -A speed=1000FD -c lan0

• nwmgr은 NIC/VLAN/APA 등을 통합 관리합니다.
• 설정 지속성(재부팅 후 유지)도 운영 포인트예요.

6-2. 물리 장애를 말해주는 에러 카운터

• FCS Errors(CRC): 케이블/커넥터/EMI 의심
• Alignment Errors: 물리 매체 결함 강력 의심
• Late Collisions: 듀플렉스 미스매치/규격 초과/설정 불일치 의심

🧠 엔지니어의 한 끗 차이 노하우
“간헐적 느림”은 대부분 **카운터의 ‘증가 추세’**로 잡아요.
스냅샷 1번이 아니라, 5~10분 간격으로 3회 이상 비교하세요.
증가 추세가 확인되면, 상위 계층(라우팅/앱)으로 뛰지 말고 물리/듀플렉스부터 정리하는 게 가장 빠릅니다.

7) 성능 모니터링: glance(gpm) / sar로 병목 분해

이 장이 왜 중요한지: “느리다”는 불만을 수치로 쪼개야, 원인과 책임이 분리됩니다.

7-1. CPU 병목: sar -q (run queue)

sar -q 1 10

sar -q 1 10

• runq-sz는 CPU를 기다리는 큐입니다.
• 코어당 1 초과면 병목이 시작된다고 보는 운영 감각이 유효합니다.

7-2. glance(gpm): Top을 넘어서는 운영자 도구

• CPU(c 키): user/system/wait 분해
• Disk(d 키): 큐 대기 vs 처리 시간 분리

판단 기준(예시):

• system 비중이 비정상적으로 높으면
  스핀락 경합, 시스템콜 과다, 드라이버 비효율 등을 의심합니다.

8) 고가용성/재해복구: Serviceguard + Ignite-UX

이 장이 왜 중요한지: 장애는 발생합니다. 중요한 건 복구 속도와 재현 가능성이에요.

8-1. 클러스터 상태 점검: cmviewcl -v

cmviewcl -v

cmviewcl -v

• Node Status: 모두 Up
• Package Status: Up + Primary에서 구동 중인지 확인
• Policy Violation: 예비 노드에서 구동 중이면 과거 failover 흔적입니다.
  원인 파악 후 failback 계획이 필요해요.

8-2. 베어메탈 복구 백업: make_tape_recovery

make_tape_recovery -Av -x inc_entire=vg00 -a /dev/rmt/0mn

make_tape_recovery -Av -x inc_entire=vg00 -a /dev/rmt/0mn

• -x inc_entire=vg00은 누락하면 사고로 이어질 수 있어요.
• 완료 후 로그 검증이 “백업의 끝”입니다.

cat /var/opt/ignite/recovery/latest/recovery.log
# "Make_sys_image completed successfully" 확인

cat /var/opt/ignite/recovery/latest/recovery.log
# "Make_sys_image completed successfully" 확인

9) 로그 기반 장애 예측: syslog를 운영 루틴으로 만들기

이 장이 왜 중요한지: HP-UX는 장애가 예고 없이 오는 게 아니라, 운영자가 신호를 놓치는 경우가 많아요.

로그 루틴:

• /var/adm/syslog/syslog.log 정기 점검
• 키워드 기준 탐색: error, warning, panic, failure

주의 신호 예시:

• vmunix: SCSI: Reset detected → 스토리지 연결 불안정 의심
• LVM: pvnum=0 is POWERFAILED → 디스크 접근 실패/전원/경로 문제 가능

[결론]

이 장이 왜 중요한지: HP-UX 운영은 “명령어”가 아니라 “선제 진단 + 형상 관리 + 백업 검증”의 반복이에요.

운영 철학 3요소만 고정해도 사고 확률이 크게 줄어듭니다.

1. 선제 진단: 카운터/로그/추세 기반으로 “문제 되기 전”에 조치
2. 형상 관리: 튜닝/변경을 문서(print_manifest)와 이력으로 남김
3. 백업 검증: 백업은 성공 로그까지 확인해야 완료

3줄 요약

• HP-UX는 출력값 해석과 선제 대응이 핵심이에요.
• 병목은 하드웨어 → 커널 → 스토리지/네트워크 순으로 분해해서 봐야 해요.
• DR은 “백업 수행”이 아니라 “복구 재현”까지가 목표입니다.

[치트 시트] HP-UX 운영자용 핵심 명령어/정상 기준/이상 징후