□ 개요
- 서버 장애는 기업 운영에 큰 영향을 미칠 수 있으며, 예기치 않은 다운타임은 생산성 저하와 비즈니스 손실로 이어질 수 있습니다. 따라서 효과적
인 장애 대응 프로세스를 구축하면 신속한 장애 감지, 원인 분석 및 복구가 가능하여 시스템의 안정성을 유지할 수 있습니다. 본 문서에서는 서버
장애 감지, 로그 분석, 백업 및 복구 계획을 포함한 대응 프로세스를 설명하고, 실제 명령어 예시를 제공합니다.
□ 장애 감지
1. 모니터링 도구 활용
a. PRTG Network Monitor
- 네트워크 및 서버 성능을 모니터링하는 상용 솔루션으로, SNMP, WMI, SSH 등을 활용하여 데이터를 수집하고 실시간 대시보드를
제공합니다.
- 사용 예시: 실시간 네트워크 대역폭, CPU 및 메모리 사용량을 모니터링하여 경고 설정을 통해 장애를 미리 감지할 수 있습니다.
b. Zabbix
- 오픈소스 기반 서버, 네트워크, 애플리케이션 모니터링 도구로, Agent 기반 및 Agentless 방식 지원.
- 간단한 설정 예시: Zabbix 서버와 클라이언트 간의 SNMP를 통해 데이터를 수집하고, 알림을 설정하여 장애 발생 시 경고 알림을 받을 수
있습니다.
c. Prometheus
- 시계열 데이터 저장소 기반 모니터링 도구로, HTTP Pull 방식을 통해 메트릭 데이터를 수집.
- 사용 예시: Prometheus로 CPU, 메모리 등의 메트릭을 모니터링하고, Grafana를 통해 시각화하여 실시간 상태를 확인할 수 있습니다.
d. SNMP
- 네트워크 장치 상태 모니터링에 사용되는 표준 프로토콜.
- 사용 예시: SNMP를 사용하여 네트워크 장비의 상태를 감지하고, snmpwalk 명령어로 장비의 상세 상태를 확인합니다.
예) snmpwalk -v 2c -c public 192.168.1.1
e. iLO
- HPE 서버의 원격 관리 기능을 제공하여 하드웨어 상태 모니터링 가능.
- 사용 예시: iLO를 통해 서버 상태를 실시간으로 모니터링하며, 하드웨어 오류 발생 시 경고 메시지를 수신할 수 있습니다.
f. IPMI
- 서버 하드웨어 상태 관리 인터페이스로, 원격에서 서버 전원을 제어할 수 있음.
- 사용 예시: ipmitool 명령어를 사용하여 서버 전원 상태를 원격으로 관리하거나, 하드웨어 이상을 감지할 수 있습니다.
예: ipmitool power status
g. Linux 시스템 로그
- 시스템 로그를 통해 장애 감지 가능. 주요 로그 파일: /var/log/messages, /var/log/syslog
2. 주요 장애 유형 및 감지 방법
장애 유형 | 감지 방법 |
CPU 과부하 | top, htop, vmstat 활용 |
메모리 부족 | free -m, sar -r 활용 |
디스크 가득참 | df -h, du -sh 활용 |
네트워크 문제 | ping, netstat, tcpdump 활용 |
RAID 장애 | megacli -LDInfo -Lall -aALL 활용 |
□ 로그 분석
1. 로그 분석 개요
• /var/log/messages, /var/log/syslog:
운영 체제 전반적인 이벤트 기록(시스템 오류, 서비스 시작/종료 등).
• /var/log/httpd/access.log, /var/log/mysql/error.log:
웹 서버 및 데이터베이스 관련 로그 확인(접속 기록, 쿼리 오류 등).
• /var/log/secure, /var/log/auth.log:
로그인 시도 및 사용자 인증 관련 로그 기록(비정상 로그인 시도, 계정 잠금 등).
2. 로그 분석 도구
• journalctl:
- systemd 환경에서 사용되는 로그 분석 도구.
- 사용 예시: journalctl --since "2025-01-01" --until "2025-01-02" 명령어로 특정 기간의 로그를 조회하여 장애 발생 시점을
확인할 수 있습니다.
• grep, awk, sed:
- 특정 패턴을 포함한 로그 필터링.
- 예시: grep "ERROR" /var/log/syslog로 오류 메시지를 필터링하여 분석.
• ELK Stack (Elasticsearch, Logstash, Kibana):
- 로그를 수집하고 시각화하여 분석.
- 사용 예시: Logstash로 다양한 로그를 수집하고, Kibana를 통해 대시보드 형태로 시각화하여 실시간 로그 분석.
□ 백업 및 복구 계획
1. 백업 개요 및 방식
- 백업은 데이터 손실 및 시스템 장애 발생 시 복구를 위해 필수적인 과정입니다.
- 백업 전략을 수립할 때는 백업 주기, 저장소 용량, 복구 속도를 고려해야 합니다.
- 주요 백업 방식에는 **전체 백업(Full), 증분 백업(Incremental), 차등 백업(Differential)**이 있으며, 필요에 따라 조합하여
활용할 수 있습니다.
• 전체 백업 (Full Backup):
- 시스템의 모든 데이터를 백업하는 방식. 주 1회 이상 수행하며 용량이 크고 시간이 오래 걸림.
- 주의사항: 데이터 복구 시 전체 시스템을 복원해야 하므로 복구 시간이 길어질 수 있습니다.
• 증분 백업 (Incremental Backup):
- 마지막 백업 이후 변경된 데이터만 저장하여 공간을 절약할 수 있지만 복구 과정이 복잡.
- 예시: 5일 주기로 전체 백업을 수행하고, 그 사이에는 매일 증분 백업을 진행합니다.
• 차등 백업 (Differential Backup):
- 마지막 전체 백업 이후 변경된 모든 데이터를 백업하여 복구 속도가 빠름.
- 예시: 전체 백업 후 3일 간격으로 차등 백업을 실행하여 복구 시 더 빠른 결과를 얻을 수 있습니다.
2. 백업 도구 활용
• Bacula:
- 네트워크 기반 오픈소스 백업 솔루션. 전체, 증분, 차등 백업 지원.
- 설정 예시: Bacula를 사용해 백업 스케줄을 자동화하고, 주기적인 백업을 설정합니다.
• Amanda:
- 네트워크를 통해 여러 클라이언트의 데이터를 중앙 서버에 백업하는 오픈소스 백업 솔루션.
• AWS S3:
- 아마존 웹 서비스에서 제공하는 클라우드 객체 스토리지.
- 주요 기능: S3 버전 관리를 활용하여 백업 파일을 암호화하고 안전하게 저장할 수 있습니다.
3. 복구 절차
• tar 명령어를 사용하여 백업 데이터 복구:
tar -xvzf backup_full.tar.gz -C /data
복구 후 데이터 무결성 확인을 위해 체크섬(checksum)을 사용하는 것이 좋습니다.
• RAID 장애 발생 시 디스크 복구:
megacli -CfgRestore -aALL 명령어를 사용하여 RAID 배열을 복구할 수 있습니다.
□ 결론 및 권장 사항
- 서버 장애를 최소화하고 신속한 복귀를 위해 다음과 같은 조치를 권장합니다.
• 장애 발생 시 표준 운영 절차(SOP)를 마련하고 주기적으로 직원 교육 실시
• 정기적인 백업 및 복구 테스트 수행하여 데이터 복원 가능 여부 확인
• 자동화된 모니터링 및 알림 시스템 구축하여 실시간 장애 감지 강화
• 장애 이력 관리 및 분석을 통한 예방 조치 적용하여 반복적인 문제 해결
⭐발표자 : 박태진님
□ 개요
- 서버 장애는 기업 운영에 큰 영향을 미칠 수 있으며, 예기치 않은 다운타임은 생산성 저하와 비즈니스 손실로 이어질 수 있습니다. 따라서 효과적
인 장애 대응 프로세스를 구축하면 신속한 장애 감지, 원인 분석 및 복구가 가능하여 시스템의 안정성을 유지할 수 있습니다. 본 문서에서는 서버
장애 감지, 로그 분석, 백업 및 복구 계획을 포함한 대응 프로세스를 설명하고, 실제 명령어 예시를 제공합니다.
□ 장애 감지
1. 모니터링 도구 활용
a. PRTG Network Monitor
- 네트워크 및 서버 성능을 모니터링하는 상용 솔루션으로, SNMP, WMI, SSH 등을 활용하여 데이터를 수집하고 실시간 대시보드를
제공합니다.
- 사용 예시: 실시간 네트워크 대역폭, CPU 및 메모리 사용량을 모니터링하여 경고 설정을 통해 장애를 미리 감지할 수 있습니다.
b. Zabbix
- 오픈소스 기반 서버, 네트워크, 애플리케이션 모니터링 도구로, Agent 기반 및 Agentless 방식 지원.
- 간단한 설정 예시: Zabbix 서버와 클라이언트 간의 SNMP를 통해 데이터를 수집하고, 알림을 설정하여 장애 발생 시 경고 알림을 받을 수
있습니다.
c. Prometheus
- 시계열 데이터 저장소 기반 모니터링 도구로, HTTP Pull 방식을 통해 메트릭 데이터를 수집.
- 사용 예시: Prometheus로 CPU, 메모리 등의 메트릭을 모니터링하고, Grafana를 통해 시각화하여 실시간 상태를 확인할 수 있습니다.
d. SNMP
- 네트워크 장치 상태 모니터링에 사용되는 표준 프로토콜.
- 사용 예시: SNMP를 사용하여 네트워크 장비의 상태를 감지하고, snmpwalk 명령어로 장비의 상세 상태를 확인합니다.
예) snmpwalk -v 2c -c public 192.168.1.1
e. iLO
- HPE 서버의 원격 관리 기능을 제공하여 하드웨어 상태 모니터링 가능.
- 사용 예시: iLO를 통해 서버 상태를 실시간으로 모니터링하며, 하드웨어 오류 발생 시 경고 메시지를 수신할 수 있습니다.
f. IPMI
- 서버 하드웨어 상태 관리 인터페이스로, 원격에서 서버 전원을 제어할 수 있음.
- 사용 예시: ipmitool 명령어를 사용하여 서버 전원 상태를 원격으로 관리하거나, 하드웨어 이상을 감지할 수 있습니다.
예: ipmitool power status
g. Linux 시스템 로그
- 시스템 로그를 통해 장애 감지 가능. 주요 로그 파일: /var/log/messages, /var/log/syslog
2. 주요 장애 유형 및 감지 방법
장애 유형
감지 방법
CPU 과부하
top, htop, vmstat 활용
메모리 부족
free -m, sar -r 활용
디스크 가득참
df -h, du -sh 활용
네트워크 문제
ping, netstat, tcpdump 활용
RAID 장애
megacli -LDInfo -Lall -aALL 활용
□ 로그 분석
1. 로그 분석 개요
• /var/log/messages, /var/log/syslog:
운영 체제 전반적인 이벤트 기록(시스템 오류, 서비스 시작/종료 등).
• /var/log/httpd/access.log, /var/log/mysql/error.log:
웹 서버 및 데이터베이스 관련 로그 확인(접속 기록, 쿼리 오류 등).
• /var/log/secure, /var/log/auth.log:
로그인 시도 및 사용자 인증 관련 로그 기록(비정상 로그인 시도, 계정 잠금 등).
2. 로그 분석 도구
• journalctl:
- systemd 환경에서 사용되는 로그 분석 도구.
- 사용 예시: journalctl --since "2025-01-01" --until "2025-01-02" 명령어로 특정 기간의 로그를 조회하여 장애 발생 시점을
확인할 수 있습니다.
• grep, awk, sed:
- 특정 패턴을 포함한 로그 필터링.
- 예시: grep "ERROR" /var/log/syslog로 오류 메시지를 필터링하여 분석.
• ELK Stack (Elasticsearch, Logstash, Kibana):
- 로그를 수집하고 시각화하여 분석.
- 사용 예시: Logstash로 다양한 로그를 수집하고, Kibana를 통해 대시보드 형태로 시각화하여 실시간 로그 분석.
□ 백업 및 복구 계획
1. 백업 개요 및 방식
- 백업은 데이터 손실 및 시스템 장애 발생 시 복구를 위해 필수적인 과정입니다.
- 백업 전략을 수립할 때는 백업 주기, 저장소 용량, 복구 속도를 고려해야 합니다.
- 주요 백업 방식에는 **전체 백업(Full), 증분 백업(Incremental), 차등 백업(Differential)**이 있으며, 필요에 따라 조합하여
활용할 수 있습니다.
• 전체 백업 (Full Backup):
- 시스템의 모든 데이터를 백업하는 방식. 주 1회 이상 수행하며 용량이 크고 시간이 오래 걸림.
- 주의사항: 데이터 복구 시 전체 시스템을 복원해야 하므로 복구 시간이 길어질 수 있습니다.
• 증분 백업 (Incremental Backup):
- 마지막 백업 이후 변경된 데이터만 저장하여 공간을 절약할 수 있지만 복구 과정이 복잡.
- 예시: 5일 주기로 전체 백업을 수행하고, 그 사이에는 매일 증분 백업을 진행합니다.
• 차등 백업 (Differential Backup):
- 마지막 전체 백업 이후 변경된 모든 데이터를 백업하여 복구 속도가 빠름.
- 예시: 전체 백업 후 3일 간격으로 차등 백업을 실행하여 복구 시 더 빠른 결과를 얻을 수 있습니다.
2. 백업 도구 활용
• Bacula:
- 네트워크 기반 오픈소스 백업 솔루션. 전체, 증분, 차등 백업 지원.
- 설정 예시: Bacula를 사용해 백업 스케줄을 자동화하고, 주기적인 백업을 설정합니다.
• Amanda:
- 네트워크를 통해 여러 클라이언트의 데이터를 중앙 서버에 백업하는 오픈소스 백업 솔루션.
• AWS S3:
- 아마존 웹 서비스에서 제공하는 클라우드 객체 스토리지.
- 주요 기능: S3 버전 관리를 활용하여 백업 파일을 암호화하고 안전하게 저장할 수 있습니다.
3. 복구 절차
• tar 명령어를 사용하여 백업 데이터 복구:
tar -xvzf backup_full.tar.gz -C /data
복구 후 데이터 무결성 확인을 위해 체크섬(checksum)을 사용하는 것이 좋습니다.
• RAID 장애 발생 시 디스크 복구:
megacli -CfgRestore -aALL 명령어를 사용하여 RAID 배열을 복구할 수 있습니다.
□ 결론 및 권장 사항
- 서버 장애를 최소화하고 신속한 복귀를 위해 다음과 같은 조치를 권장합니다.
• 장애 발생 시 표준 운영 절차(SOP)를 마련하고 주기적으로 직원 교육 실시
• 정기적인 백업 및 복구 테스트 수행하여 데이터 복원 가능 여부 확인
• 자동화된 모니터링 및 알림 시스템 구축하여 실시간 장애 감지 강화
• 장애 이력 관리 및 분석을 통한 예방 조치 적용하여 반복적인 문제 해결
⭐발표자 : 박태진님