소개
이 문서에서는 FI(Unified Computing System Fabric Interconnect) 충돌 또는 예기치 않은 재부팅 오류를 조사하는 단계를 제공합니다.
상위 레벨에서 다음 문제로 인해 FI가 재부팅될 수 있습니다.
- 커널 공간 프로세스가 crash(커널 패닉 현상이라고도 함)
- 커널에 메모리가 부족합니다( 메모리 부족 - OOM에서 메모리를 재확보하기 위해 사용자 프로세스를 죽이고 있음).
- 사용자 공간 프로세스가 crash(예:- netstack, fcoe_mgr, callhome 등 )
- FI 펌웨어 문제(드문 시나리오, 예 - CSCuq46105 ) 또는 하드웨어 구성 요소 오류(예: 스토리지에 사용되는 SSD)
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
Cisco UCS(Unified Computing System) Manager
Cisco UCS(Unified Computing System) Manager CLI(Command Line Interface)
필수 로그 파일
FI가 예기치 않게 재부팅되면 다음 로그를 수집하고 TAC 서비스 요청에 업로드합니다.
- 재부팅 이벤트 시점에 코어 덤프 파일이 생성되었는지 확인합니다.
CLI 또는 GUI를 통해 코어 덤프 파일을 확인할 수 있습니다.
UCS-FI # 범위 모니터링
UCS-FI /monitoring # scope sysdebug
UCS-FI /monitoring/sysdebug # show cores detail
- FI가 syslog 서버로 로그를 내보내도록 구성된 경우, syslog 서버에서 재부팅 타임스탬프 7일 전에 기록을 제공하는 디바이스에 대한 로그 메시지를 수집하십시오.
- 커널 스택 추적( 리부팅으로 인해 커널이 작동을 멈춘 경우 )
초기 단서용 로그 분석
1) Nexus 운영 체제(NX-OS) " show version " 명령 출력에서 재부팅 사유 및 타임스탬프를 확인합니다.
2) 리부팅 전에 로그 메시지에 대한 " show logging nvram " 명령 출력 확인
3) syslog 서버에 저장된 로그 메시지에서 추가 단서를 확인합니다.
4) 사용자 공간 프로세스 크래시에 의해 재부팅이 트리거된 경우 프로세스 이름과 일치하는 코어 덤프를 확인하고 타임스탬프를 재부팅합니다.
6) 커널 패닉 상태인 경우 " sw_kernel_trace_log라는 파일에서 커널 스택 추적 출력을 확인합니다.
UCSM 2.2.1b에서 이 파일에는 UCSM show techsupport 번들이 포함되어 있습니다.
2.2.1b 이전 UCSM 버전의 경우 다음 명령의 출력을 수집하십시오.
connect nxos
show logging onboard kernel-trace | no-more
show logging onboard obfl-history | no-more
show logging onboard stack-trace | no-more
show logging onboard internal kernel | no-more
show logging onboard internal kernel-big | no-more
show logging onboard internal platform | no-more
show logging onboard internal reset-reason | no-more
7) " topout.log "에는 2초마다 " top " 명령의 출력이 포함됩니다.재부팅 전에 UCSM은 이전 로그 세트를 /opt/sam_logs.tgz 파일로 저장합니다. 메모리, 사용률 또는 프로세스에 대한 정보를 제공할 수 있습니다.
8) 메모리 부족( OOM )과 같은 메시지가 프로세스를 종료하고 프로세스 충돌이 FI 리부팅을 트리거할 수 있으며 재설정 이유로 나열될 수 있습니다. 이러한 시나리오에서는 프로세스가 메모리 부족 상태의 피해자일 가능성이 높으며 충돌 또는 메모리 누수의 원인이 아닐 수 있습니다.
UCS 설정에 대한 정보 수집
다음 질문에 답하면 시스템 설정 및 재부팅 전의 상태를 더 잘 이해할 수 있습니다.
1) 이 문제가 전에도 발생했습니까?
2) 재부팅 시점에 특정 사용자 활동이 있었습니까?
3) FI에 대한 최근 소프트웨어/하드웨어/컨피그레이션 변경 사항이 있습니까?
4) 외부 애플리케이션( SNMP , XML API를 통해)에서 Fi를 모니터링합니까?
5) "예"인 경우 애플리케이션이 데이터를 위해 FI를 폴링하는 빈도는 얼마나 됩니까? 이러한 애플리케이션에서 정기적으로 폴링되는 정보는 무엇입니까?( 예: SNMP 쿼리 )
6) FI 관리 포트로 향하는 트래픽 폭풍이 발생했습니까?
7) 이 스케일 설정이 되어 있습니까?( 섀시, 블레이드, 가상 인터페이스 수 )
FI 사전 모니터링 제안
1) 로그를 syslog 서버로 내보내도록 UCSM 구성
2) CPU 및 메모리의 추세를 모니터링하기 위해 정기적으로 로컬 관리에서 " show processes" 출력을 수집합니다.
프로세스 사용.이는 외부 애플리케이션에서 FI를 이미 모니터링하는 경우 필요하지 않습니다.
관련 정보
Cisco UCS Manager 컨피그레이션 가이드
피드백