|
|
|
|
 |
HOME > 통합유지보수 > IBM |
|
 |
|
| |
 |
IBM 장비에 대한 가용도 향상과 효율적인 관리 운영 및 최적의
운영 시스템 환경을 지원하며 담당 관리자의 유지보수 서비스에 대한 전반적인 이해와 아울러 신속한 서비스
체계를 도모하고자 합니다 |
|
|
♠ 대상
- 적용 가능 장비: IBM RS/6000 System OS 환경 : AIX 4.3.3
- 유지보수 대상장비
|
| 제조원 |
모델명 |
수량 |
대상 서버 |
비고 |
| IBM |
7026-M80 |
1 |
host_A |
10FCD4D |
| 1 |
host_A |
10FCD5D |
| 7133-D40 |
3 |
Attach to dbdev |
37개 Disk module |
|
|
|
| ♠ 유지보수 및 점검 |
| 정기 예방 점검 |
| 시기 |
월 1회 실시를 기본으로 하며 일요일을 포함하는 주를 한
주로 계산하여 매월 셋째 주 목요일에 실시한다. 불가피한 사정 등으로 변경이 요구될
때에는 담당자 및 관리자와 협의하여 시기를 조정할 수 있다.
|
| 방법 |
담당 서비스 엔지니어의 방문 점검이 이루어지며 점검항목에 기재된 내용에 따라 Hardware
및 OS 환경 등에 대한 점검을 수행하고, 그 외에 이슈가 되는 부분에 대한 정밀
점검을 실시한다.
|
| 범위 |
System Hardware 및 OS |
| 기술적 변경 |
| 시기 |
System에 대한 중대한 Bug 가 발견되었거나, Critical
한 OS patch 또는 new firmware 가 발표되고 이에 대한 고객 차원의
요구가 발생하였을 때에는 이에 대한 작업을 지원한다. |
| 방법 |
변경사항 및 적용으로 인한 문제점, 예상 downtime 등을 검토한 후 관리자와
협의 하여 진행한다. |
| 장애 지원 |
| 시기 |
유지보수 기간 중 24시간 Call Service 지원 |
| 방법 |
장애 신고 접수 후 계약상 요구시간 이내 현장에 도착하여 점검 및 장애원인을 파악
하여야 하며 서비스 down time이 발생하였다면 가능한 빠른 시간에 서비스복구가
이루어 지도록 한다. Hardware 등의 부품 교체가 필요할 시에는 관리자에게 보고
후 빠른 방법을 통해 지원 받도록 한다. |
| 대상 |
System Hardware 및 OS 기본 구성에 대한 천재지변이 아닌 장애. |
|
|
|
| ♠ 예방 점검 항목 |
| 매일 점검 (관리자 참고) |
육안 점검
(시스템 하드웨어적인 위험요소 및 장애 파악) |
- 시스템 Front Panel LED Code
- 시스템 Power Supply LED |
Hardware 운용상태
(시스템 하드웨어적인 위험요소 및 장애 파악) |
- Network
- Login Console (monitor keyboard) |
| OS 환경 (OS 및 서비스운용상의 장애파악) |
- file system
- 로그 확인
- 서비스 운용 상태 |
| 정기 점검 |
Hardware 운용상태
(시스템 하드웨어의 위험요소 파악 및 제거) |
- CPU, Memory, Disk, Adapter 등의 가용상태
- External Device 가용상태
- Network 상태
- Console login 상태
- 시스템 로그 |
OS 환경
(OS 및 운용 APP 에 대한 문제점 파악) |
- volume group 및 LV sync 상태
- file system
- 시스템 로그
- OS 설정 파일
- 백업 수행 여부
- OS 및 서비스 가용성을 위한 설정 |
성능
(성능 저하여부 및 저하 요소 파악) |
- CPU
- Memory 및 Paging space
- Disk
- Network |
|
|
| ♠ 점검 방법 |
| 하드웨어 |
| CPU - 수량 및 사용 가능상태 확인 |
| Command |
Description |
| lsdev-Cc processor |
Processor 수량 및 Available 한 가용상태 확인 |
| Sar-P ALL 5 10 |
각 Processor의 사용률을 확인하여 문제되는 Processor 유무 확인 |
|
|
| Memory - 수량 및 사용 가능상태 확인 |
| Command |
Description |
| lsdev-Cc Memory |
Memory(Card) 수량 및 Available 한 가용상태 확인 |
| lsattr-El mem(n) |
메모리 타입 및 Size 확인 |
|
|
| Disk - 수량 및 사용 가능상태 확인 |
| Command |
Description |
| lsdev-Cc disk |
disk 수량 및 Available 한 가용상태 확인 |
| lspv |
디스크 할당 상태 확인 |
| lspv hdisk(n) |
디스크 할당 상태 및 가용 Size 확인 |
|
|
| Adapter - 구성된 종류 및 수량, 가용상태 확인 |
| Command |
Description |
| lsdev-Cc adapter |
adapter 별 Available 한 가용상태 확인 |
| ssaraid-(option) |
SSA Adapter의 구성상태 확인 |
| diag |
구성 장치들의 문제점 진단 |
|
|
| OS 및 환경 |
| Storage - 저장공간으로 할당된 영역에 대한 가용상태 확인 |
| Command |
Description |
| lsvg-o |lsvg -il |
시스템에서 activity 한 volume group 및 vg에 할당되어 있는 LV 들의 sync 상태 확인 |
| lspv |
디스크의 volume group 할당 정보확인 |
| df -k |
파일 시스템 사용량 및 가용 Size 확인 |
| ssaraid , ssaxlate |
SSA Disk RAID 구성상태 확인 |
| datapath , lsvpcfg |
SAN Disk 구성 상태 확인 |
|
|
| Environment - OS 최적 환경을 위한 구성 확인 |
| Command |
Description |
| bootlist |
System normal 또는 service 부팅 시 부트순서 확인.
mirroring 시에 미러 디스크가 리스트에 존재하는지 확인. |
| sysdumpdev |
System dump를 위해 지정된 device 및 요구 size 를
충족하는지 여부 확인 |
| lsattr-El sys0 |
system 전반적인 설정상태 확인 |
| lslpp |
Install 된 fileset 들의 체크섬 정보와 링크 상태에 대한
진단. |
| lssrc |
System resource controller 의 daemon 수행
상태 확인 |
|
|
| Log 점검 - 오류에 대한 로그 및 시스템에 설정된 로그파일 확인 |
| Command |
Description |
| errpt |
System 에서 발생된 기본적인 로그를 확인하고 Class:H (Hardware)와
type:P(PEND, PERF, PERM) 부분의 발생여부 중점으로 점검 |
| syslog |
/etc/syslog.conf 파일에 설정된 정보에 따른 로그파일을
분석하여 문제점 여부 파악. |
| alog |
console에 Display 된 오류 정보나 booting 시 문제
되었던 부분, dump 정보에 대한 부분 등을 점검 |
| vi /var/spool/mail/root |
root 메일을 점검하여 관리자에게 통지된 에러 확인 |
| find / -name core |
core 파일 생성 여부 확인하여 잘못 수행된 APP 프로세스 및 OS
Base Processor의 존재 여부 확인 |
|
|
| 성능 |
| CPU - CPU의 병목 여부 파악 |
| Command |
Description |
| sar |
Processor 별로 사용률 점검 |
| vmstat |
processor 의 used, idle, wait 등을 파악 |
| topas |
processor load average 를 검토 |
| bindprocessor |
processor bind 의 존재여부 확인 및 필요 시 binding |
| ps aux |
문제가 되거나 문제의 소지가 있는 process의 유무 점검 |
|
|
| Memory - Memory의 과부하 여부 파악 |
| Command |
Description |
| vmstat |
충분한 Free memory가 있는지 확인하고 paging in, out
여부를 파악하여 Memory 의 병목 여부 판단. |
| lsps |
Paging 공간의 사용률을 파악하여 메모리 병목 판단에 활용 |
| topas |
Memory의 caching 사용여부와 사용률을 파악 |
| ps aux |
프로세스 별로 메모리 사용률 파악 |
| svmon |
프로세스 사용률 순 또는 Memory 사용률에 따른 순서로 상세한 사용에
대한 세부 내역파악. |
|
|
| Disk - Disk I/O 에 대한 병목 여부 파악 |
| Command |
Description |
| iostat |
각 Disk의 초당 read-write 및 busy율 을 파악하여 과도한
action이 이루어지는지 또는 I/O가 원할하게 이루어 지는지 여부 확인.
|
|
|
| Etc - 기타
성능 분석을 위한 명령 실행 |
| Command |
Description |
| netstat |
네트?p 송수신에 이용되는 Memory의 overflow 현상이나 Collision
등의 발생 여부 확인 |
| tprof |
프로세스당 Processor 사용률 확인 |
| netpmon |
네트?p과 관련된 Process 사용률 확인 |
| filemon |
특정 Storage resource(LV, FS, Disk) 에 대한
집중적인 access 파악. |
|
|
|
|
| |
| ♠ 장애유형별 조치 |
| 시스템
운용 중 장애 (서비스 가능상태) |
| 장치 디바이스 장애 |
| 장애유형 |
조치사항 |
| Processor , Memory fault |
점검 방법 : lsdev -Cc processor, lsdev -Cc
memory 를 실행시켜 Defined 상태임이 확인되었을 때 장애로 판단.
조치 방법 : 서비스 담당자에게 통보 |
| Internal Disk Error |
점검 방법 : errpt 명령으로 Disk Operation Error
를 확인 할 수 있으며 지속적인 에러는 Disk 장애임을 말해준다. 또한
lsvg -l rootvg 명령을 이용하여 LV STATUS 부분에 open/syncd
가 아닌 open/staled 가 확인된다면 디스크 장애가 발생했다고 판단할
수 있다.
조치 방법 : 만일을 위해 OS 백업을 수행하고, 서비스 엔지니어에게 통보한다. |
| External Disk Error |
점검 방법: errpt 명령의 Disk Operation Error를
통해 장애를 확인 할 수 있다. host_A system 의 경우 Fiber
Channel 을 통한 SAN Network Storage를 사용하므로“datapath
query adapter” 명령의 Link Error 통계를 확인하여 SAN
문제를 감지할 수 있으며 SSA를 사용하는 host_B System의 경우
ssaraid -Izl ssa0 (ssa0는 Adapter 명) 명령을
사용하여 RAID Disk의 장애 유무를 파악할 수 있다.
조치 방법 : Disk 및 Volume 들이 사용 가능한 상태인지 #lsvg
-ㅣdatavg 와 같은 명령으로 모든 LV들이 정상 Sync 되어 있고
mount 되어 있는지 검사한다. |
| Power Fault |
점검 방법: Redundancy Power로 구성된 System에서
Power Error는 errpt에 Display 안 되는 경우가 종종
있기 때문에 root 메일을 살펴보는 것으로 점검 하거나, 직접 System을
육안으로 살펴 전면부의 I/O Power 및 후면부의 CES Power
Supply LED lamp 를 확인하여 판별할 수 있다.
조치 방법 : 담당 엔지니어에게 통보한다. |
| Network 장애 |
점검 방법: errpt를 통해 Network Adapter 관련 Error를
살펴 보고 tracert 명령을 통해 어느 부분에서 Network 문제가
있는지 파악한다. Local 문제인 것으로 판단되었다면 후면부의 Adapter
Link 및 Act Lamp 를 살펴 Adapter 문제 또는 Cable
이나 router 이상인지를 판별할 수 있다.조치 방법: 점검 결과에 따라
Cable을 교체하거나 router를 살피는 작업 또는 Adapter 교체작업이
수행되어야 하며 Adapter 를 rmdev 명령을 통해 삭제 한 후 재구성하여
Hardware 적인 문제가 발견되는지를 확인한다. |
|
|
| 설정 또는 성능상의 장애 |
| 장애유형 |
조치사항 |
| CDE Login 장애 |
* Login 창의 Option에서 Command Interface
Mode 로 로그인 한다. 확인 사항은 다음과 같다*/etc/hosts
파일 네트워크 파일을 검사한다. 퍼미션 문제이거나 파일에 잘못된 IP가
셋팅 되어 있을 경우가 많다
*DNS 등의 Network 구성을 점검한다.
*/home 디렉토리가 Full 인지 확인한다.
*X11, DT 관련 파일셋에 이상이 있는지 확인한다. |
| Telnet 접속 장애 |
* ping TEST 및 Gateway, router 장비 점검
* lssrc -a 로 inetd 데몬의 실행여부 확인
* /etc/inetd.conf 파일에서 telnetd 확인
* /etc/services 파일에서 telnet 서비스 확인
* /etc/resolv.conf 파일에서 DNS 정의 확인
* paging space 80%이상 사용시 Memory를 과다 점유하는
Process를 Kill 및 restart.
* telnetd 파일의 퍼미션이 바뀌었는지 확인 |
| Keyboard 입력 안됨 |
Keyboard lock Key를 눌러 keyboard 이상유무를 파악하고
System hang up 을 판단하기 위해 remote 접속을 시도해본다.
hang up 판단 시에는 reset key를 3~5초간 눌러 dump
및 재 부팅을 수행하고 엔지니어에게 통보한다 |
| CDE 화면 이상 |
Remote 접속을 시도하여 X11, DT 관련 Process 를 stop
시키고 dtlogin 을 재시작 한다. |
그 외 Network
장애 |
netstat -v 명령을 사용하여 해당 Adapter에서 collision이
많이 발생하는 지 여부와 CRC 에러 또는 packet Drop 이 발생하는지
여부를 확인한다. |
명령
실행 에러 |
명령 실행 시 Not enough memory 혹은 Fork function
Failed 메시지 출력 시 paging space 부족이 원인이 되므로
lsps -a 명령으로 사용량 확인 후 size를 늘리거나 메모리를 과다
점유한 Process를 Stop 시킨다. 조치 불가능한 상황이라면 rebooting
하거나, 프로세스가 메모리를 반환할 때 까지 기다려야 한다. |
| File 이상 |
입출력이 많은 파일시스템에서는 불특정 디렉토리 내의 파일들이 보이지
않거나 이상현상을 보이는 경우가 있는데 이는 File system 의 super
block 이나 inode map 등에 이상이 있는 경우에 발생한다. 이때에는
File system을 unmount 하고 fsck -y 를 수행하여 복구하여야
한다 |
|
|
|
서비스 불가능 장애 |
| 장애
유형 |
조 치 사 항 |
| File System access 불가 |
File System 의 corruption으로 인해 file system access 불가한
상태에서는 unmount 후 fsck -y 명령으로 복구 및 수정한 후 mount 하여 사용한다.
데이터 손실이 있을 수 있음을 인지 하여야 한다. |
| Hang up |
System Service 및 접근이 전혀 되지 않는 경우 서비스 재가동을 위해서 Reset
button을 3~5초간 눌러 Dump를 진행하고 dump 완료 후 자동 재 부팅을 기다린다.
service 재가동이 우선시 된다면 Power button 을 눌러 종료 후 다시 부팅 시켜
dump 진행을 Skip 할 수 도 있다. |
| Dump |
System Front Panel에 0c9 또는 0c0 등의 dump code가 발견되었다면
덤프가 진행 중 이거나 완료된 상황이므로 자동 재부팅 되기를 기다리고 엔지니어에게 통보한다. |
| Booting 중 에러 |
시스템 부팅 중에 4-digit Error 나 8-digit Code 에서 진행이 멈추었을
때에는 Code에 따른 장애 내용을 확인해야 하므로 메모 후 담당 엔지니어에게 통보한다. |
| OS File System corruption |
OS CD 혹은 mksysb image backup Media 를 이용하여 Service
부팅을 시도한 후 fsck 명령을 수행하여 파일시스템을 복구 하거나 경우에 따라서는 image
backup 으로부터 restore를 수행한다. |
| Booting image corruption |
OS CD 혹은 mksysb image backup Media로부터 Service 부팅을
시도하여 maintenance mode 에서 bosboot 명령과 bootlist 명령을 사용하여
복구 한 후 재부팅 한다. |
| Power 장애 |
시스템이 전혀 가동하지 않는다면 전원 코드의 접속 상태를 확인 하고 Power Supply의
LED lamp 를 확인하여 점등 여부를 파악 하고 담당 엔지니어에게 통보한다 |
|
|
|
|
| |
|
|
|
|
 |
|
