|
서버관리 |
세부관리항목 |
|
성능관리 |
CPU 성능분석, 메모리 성능분석, 디스크 성능분석, 네트워크 성능 분석 |
|
장애관리 |
웹서버 장애 (예시) |
|
백업관리 |
서버 백업 장애 증상, 서버 백업 장애 시 복구방법 |
|
보안관리 |
보안관리활동, 보안점검, 계정관리 |
<4대 주요 서버관리>
5.1 성능관리
Server의 성능분석은 성능분석 자동화 도구를 이용하거나, 성능관리자에 의해 OS에서 제공하는 도구를 이용하여 CPU, Memory, Disk I/O, Network Device 등에 대한 수집된 성능측정 Data를 각 항목별로 권장하는 기준치에 대한 성능과 비교 분석한다 Server의 주요 성능 관리 항목에 대한 분석 방법 예시는 다음과 같다.
l CPU 성능분석
성능 자동화 도구나 OS 기본 명령어인 vmstat 나 sar 명령어를 이용하여 System 의 CPU 자원 사용현황을 분석한다.
: CPU 사용율(%), Run Queue Size
l Memory 성능분석
성능 자동화 도구나 OS 기본 명령어인 vmstat 명령어를 이용하여 System의 Memory 자원 사용 현황을 분석한다.
: 물리적 Memory 사용량, Swap 사용율(%)
l Disk 성능분석
성능 자동화 도구나 OS 기본 명령어인 iostat 명령어를 이용하여 System의 Disk I/O 현황을 분석한다.
: Disk 사용 시간 (%), Disk 장치별 사용율(%)
l Network 성능 분석
성능 자동화 도구나 OS 기본 명령어인 netstat 명령어를 이용하여 System의 Network Device에 대한 현황을 분석한다.
: Network Packet 비율 (%), Network 병합 비율(%), Network Traffic
5.1.1 성능저하의 원인
| 원인 | 내용 |
| 서버 자원의 부족 | 충분하지 않은 Processor, Power, 속도, 부족한 Memory (Memory 누수현상 포함) 느린 Input/Output 부품들이 원인이 된다. |
| 성능조정의 부족 | 부정확한 Parameter Setting, 성능 조정을 안하거나, 잘못된 성능 조정이 원인이 되기도 한다. |
| I/O 조각화 현상 | 연속적이지 못하고 조각조각 깨진 형태로 File이 저장되면, 찾는 작업의 횟수가 기하급수적으로 증가하여서 전체적인 응답 시간이 증가한다. |
| Data 이동 | Data 전송 Packet의 크기 등 전체적인 성능상의 Issue를 제공한다. 이러한 Parameter 값들의 부조화는 종종 심각한 성능저하를 일으킨다. |
| Programming 오류 | 설계, Programming, 구현, Script 등이 원인이 된다. 가장 주요한 원인 중에 하나는 Platform에 맞지 않는 잘못된 사용으로 인한 성능저하이다. |
| Database | Database는 구조적으로 설계되므로 Database의 재설계 및 구현에 많은 지식과 통찰력, 노력을 요한다. 주요 Database에 대한 성능 조정을 통해서 비약적인 Server 성능 효과를 얻을 수도 있다. |
| 악성코드 | Virus, Worm, 트로이목마, Hacking Tool 등은 의도적이든, 의도적이지 않든 성능에 악영향을 끼친다. |
| Bug | 대부분의 Application, Script, Program 등은 Bug (Program의 잘못된 사용)을 가지고 있다. Programmer, Compiler, Code 생성기, Linker (연결 Program), Interpretor(해석기), 운영체제는 그들 안에 어느 정도의 Error를 가지고 있다. 이것이 원치 않는 오동작을 일으키기도 한다. |
| Hardware Down | Hardware는 급격히 보다는 서서히 Down되는 특징이 있다. 내부 Error 수정 Mechanism에 대해서 요청이 증가하기도 하며, 정품이 아닌 대체 용품의 사용으로 인해서 성능 저하를 초래할 수도 있다. |
| 외부적 요인 | 사용자들은 가끔 Error를 발생시켜서 성능을 떨어뜨리곤 한다, 이것은 사용자들에 의해 Application이 비효율적이고, 잘못 사용된다는 것을 의미한다. 이러한 요인에 대해서는 사용자의 교육과 훈련으로 극복할 수 있다. |
| 구성요소의 부조화 | Application은 구조적으로 한정된 수량의 Thread를 구동시킬 수 있다. Application이 Multi-Processor Server로 Migration 될 때, Application Architecture상 병목 현상을 일으킬 수 있다. 예를 들어, System이 40%의 CPU 부하를 나타내고, 30%의 Memory를 사용하고 있다. 이 경우, 두개까지만 Thread를 동시에 처리하도록 한계가 설저오디었다면 더 이상의 부하처리가 안될 수 있다. |
5.1.2 성능개선
성능저하의 원인은 System의 다양한 연관관계 속에서 발생하므로, 이러한 점들을 고려하여 성능을 조정해야 한다.
구성 요소 별 성능 조정 방법 예시
|
구성요소 |
조치내용 |
|
CPU |
- 사용자 Process 상태분석 - 불필요한 Process 종료 (KILL) - 처리가 늦어도 되는 Process Priority 조정 - Job 처리시간 조정 |
|
Memory |
- Memory 이용상태 분석 - Memory를 많이 사용하는 Process 확인 후 조치 - BUFFER CACHE 사용률 분석 후 상호 조정 - SWAPPING 발생시 Memory 확장 |
|
Disk |
- Disk I/O상태 분석 - Disk 간 I/O 부하 분산여부 파악 - Memory 여유율 파악 후 BUFFER CACHE 증가 - Disk 자원 재배치를 통한 부하 분산‘( /’가 포함된 Disk의 병목현상은 전체 System에 영향을 줌) - 특정 I/O CHANNEL에 부하 집중 시 I/O CHANNEL 증설 후 분산 실시 |
|
Buffer Cache |
- Memory 사용률을 고려하여 BUFFER SIZE 증가 |
|
기타 |
- 성능향상을 위한 PATCH 존재 시 적용 - System 간 Service 분산 고려 - Disk I/O 단위를 고려하여 Application의 I/O 단위를 설정 - System Kernel은 연관된 Parameter를 고려하여 수정 |
5.2 장애관리
웹 서버 장애 (예시)
|
장애 원인 |
장애 조치 순서 |
담당자 |
목표복구시간 |
|
Web Server Disk 한 개 불량 |
1) 교체해야 할 Disk를 파악 2) Server를 정지 3) 새로운 Disk로 교체 4) Server를 기동 5) Parity data를 바탕으로 Data를 조치 6) Service 정상 가동 여부를 확인 |
서버관리팀 홍길동 |
1 시간 |
|
Web Server Disk 두 개 이상 불량 |
1) 교체해야 할 Disk를 파악 2) Server를 정지 3) 새로운 Disk로 교체 4) Ghost Disk Image가 저장된 Swappable Disk를 삽입한 후, Boot Disk를 사용하여 Server를 Booting 5) Ghost 응용 Software를 실행하여 Disk Image를 Local Dis k로 조치 6) 작업이 완료되면, Booting Disk 및 Swappable Disk를 제거 후 재부팅 7) Service 정상 가동 여부를 확인 |
서버관리팀 홍길동 |
2 시간 |
|
Process 별 Resource (CPU, Memory, Disk) 점유율 과다 |
1) Resource 과다 점유 프로세스 kill 2) 오류 원인 제거 3) Process 재실행 |
서버관리팀 홍길동 |
5분 |
|
운영체제 손상 |
* OS Backup이 있는 경우 1) Backup Data Restore 2) System Reboot 3) Database Process 기동
* OS Backup이 없는 경우 1) System CD로 Booting 2) 운영체제 재설치 및 Patch 적용 3) System Reboot |
서버관리팀 홍길동 |
5분 |
|
LAN card 불량 |
1) 교체해야 할 LAN Card를 파악 2) LAN Card Driver를 제거 3) Server를 정지 4) 새로운 LAN Card로 교체 5) Server를 기동 6) Service 정상 가동 여부를 확인 |
서버관리팀 홍길동 |
30분 |
5.3 백업관리
Server Backup 장애 증상
|
Step |
장애 증상 |
확인 방법 |
결과 |
|
1 |
- 모든 Backup (Media Server, Client Backup) 실패 및 불가 - Backup Software 제어 불가 |
- Backup Daemon 확인 (Software 별 Daemon 확인 명령어 이용) - Backup Software 기동 불가 |
Server Backup 장애 시 복구 방법
|
Step |
복구 단계 |
복구 확인 방법 |
결과 |
|
1 |
Backup Software 재설치 |
- OS 상에서 Backup Software 설치 확인 - Backup Daemon 구동 확인 |
|
|
2 |
Catalog Database Restore |
- Catalog Database Tape Backup 확인 - Tape Backup 존재 시 해당 Catalog 정보 Restore |
|
| 3 |
Backup Software 정상 설치 확인 |
- 기존 Backup Data 에 대한 정보 인식 확인 - Backup 장비 인식 여부 확인 - Backup 및 Restore Test |
5.4 보안관리
UNIX 계열의 운영체제는 Internet의 발달과 개방화에 따라 많은 부분에서 보안의 취약성을 가지고 있다 이러한 보안 취약성으로부터 주요 운영 시스템에 대한 보호를 위해 다음과 같은 보안관리 활동이 요구된다.
5.4.1 보안관리활동
- 신규 임용된 임직원의 계정등록 요구 시 System 관리자에게 사용목적, 사용기간 및 연락처 등을 제출하도록 한다.
- 휴직자의 계정은 휴직기간 동안 잠정 폐쇄를 원칙으로 한다
- 퇴직자는 사직원 제출 시 사용자 계정을 반납하도록 한다
- System 관리자는 최소 월 단위로 사용자의 비밀번호를 체크해 취약한 Password가 발견될 경우 당사자에게 통보하여 변경을 요구할 수 있다. 취약한 Password를 사용한 계정에 대해서는 경고를 하되, 수회 이상의 경고를 받고도 변경하지 않을 경우에는 일정 기간 동안 계정을 폐쇄할 수 있다.
- System 개발 및 운영부서의 장은 응용 Program 개발 계획 단계에서 보안정책에 근거한 응용 Program 개발을 지시하고, 이를 위반할 경우에는 개발을 중지시킬 수 있다.
- 특수계정 권한에 대한 관리: Super User의 권한은 정보보안업무 담당자/시스템 관리자로 제한한다.
- 장애복구나 점검을 위해 Root 권한을 위임할 경우에는 시스템 관리자 입회 하에 작업을 실시하고, 작업종료 후 Root 계정과 Password를 변경한다.
- Backup 지침은 별도로 정하며, 반드시 지침에 따라 주기적인 Backup을 실시한다.
- 각 부서는 Backup Meda 별로 적절한 사용연수를 정하여 노후된 Backup Media에 대해서는 사용하지 아니 한다
5.4.2 보안점검
- 전체 시스템에 대한 보안관리와 전반적인 방향설정 및 주기적인 보안점검은 정보보안팀에서 실시한다
- 개별 서버에 대한 보안관리는 각 서버의 관리자가 담당한다
5.4.3 계정관리
- 사용자 계정 분류는 그 사용목적에 따라 분류하고 그 기준은 따로 정한다
- 사용자 별 또는 그룹별로 접근권한을 부여한다
- 외부사용자 계정관리 : 예) 외부 사용자의 계정은 유효기간을 설정한다.
- 미사용 계정에 대한 말소관리 : 특별한 사유 없이 일정 기간 이상 사용하지 않는 계정은 일정 기간 이내에 말소한다.
- 비밀번호가 없는 계정은 사용을 금지한다
- 일정회수 접속 실패 시 사용을 금지한다.
- Super User는 Console 및 특정 단말에서만 접속을 허용한다.
- 사용자 계정절차의 등록 및 변경 및 폐기에 업무절차 명시
|
1. 사용자 계정 업무 절차 |
|
1. 사용자 계정은 사용자 등록이나 변경 또는 폐기 신청서를 작성한 후에 시스템 관리자에게 통보하되, 외부사용자는 반드시 사용기간 및 목적 등의 사유를 명확히 해야 한다.
2. 시스템 관리자는 내용을 검토한 후에 사용자 계정을 등록이나 변경 또는 폐기하고 사용자에게 그 사실을 통보한다
3. 사용자 계정을 등록하거나 변경 또는 폐기할 경우에 일반적인 사항은 월 단위로 부서장에게 사후 보고한다. 다만, 특별한 상황이 발생할 경우에 한하여 부서장의 허가를 받은 후에 작업을 실시한다. |
6. 관련 양식 (예시)
● 서버정기 점검일지
|
서 버 정 기 점 검 일 지 | |||
|
점검자 |
확인자 |
||
|
점검일자 |
|||
|
Model 명 |
Sun Ultra 60 |
OS Version |
Solaris 7 |
|
점 검 사 항 |
점 검 방 법 |
결 과 |
비고 |
|
1. Mechanism |
|||
|
1.1 System board |
|||
|
1.2 CPU |
mpstat |
||
|
1.3 Memory |
prtdiag –v |
||
|
1.4.Monitor & keyboard |
육안점검 |
||
|
1.5 모든 I/O cable 연결 상태 |
육안점검 |
||
|
1.6 Fan / LED lamp status |
육안점검 |
||
|
2. OS |
|||
|
2.1 Error messages 점검 |
(/var/adm/messages) |
||
|
2.2 Process status |
ps –ef |
||
|
2.3 OS/kernel version status |
uname –a |
||
|
2.4 정상 booting check |
dmesg |
||
|
3. Disk |
|||
|
3.1 I/O traffic status |
iostat –xct |
||
|
3.2 File System 사용량 |
df –k |
||
|
4. Network |
|||
|
4.1 H/W interface |
ifconfig –a |
||
|
4.2 Routing table |
netstat –nr |
||
|
4.3 Ping/Broadcast test |
ping –s |
||
|
4.4 I/O Traffic status |
netstat –i |
||
|
<종합의견> | |||
|
위와 같이 시스템 예방정비를 실시하였음을 확인합니다. | |||
[참고 자료]
LG CNS 내부자료