BLOG
온 프레미스 데이터 센터에 배포된 시스템에서 작업할 때 응답이 없는 서버를 디버깅해야 하는 경우가 있었습니다. 보통 물리적으로 고정된 서버에 마스크 불가능 인터럽트 (NMI) 버튼을 누르거나 직렬 인터페이스(RS-232와 같은)를 통해 커맨드 컨트롤러에 신호를 송신하도록 누군가에게 의뢰할 필요가 있습니다. 이 명령 트리거 시스템은 추가 분석을 위해 고정된 커널의 상태를 파일로 덤프 합니다. 이러한 파일을 일반적으로 코어 덤프 또는 크래시 덤프 라고 합니다. 크래시 덤프에는 크래시 된 프로세스의 메모리 이미지, 시스템 레지스터, 프로그램 카운터 및 프리즈의 근본 원인을 확인하는 데 유용한 기타 정보가 포함됩니다.
이제 EC2 인스턴스에서 커널 패닉 생성을 원격으로 트리거 할 수 있는 새로운 Amazon Elastic Compute Cloud (EC2) API가 출시되었습니다. EC2:SendDiagnosticInterrupt API는 실행 중인 EC2 인스턴스에 물리적 시스템에 NMI 버튼을 눌러 유사한 진단 인터럽트를 보냅니다. 인스턴스의 하이퍼바이저가 마스크 불가능 인터럽트 (NMI)를 운영 체제로 전송합니다. NMI 인터럽트가 수신될 때 운영 체제의 동작은 구성에 따라 다릅니다. 일반적으로 커널 패닉이 발생합니다. 커널 패닉 동작은 운영 체제 구성에 따라 다릅니다. 크래시 덤프 데이터 파일 생성을 트리거 하거나 역 추적을 얻거나 대체 커널을 로드하거나 시스템을 다시 시작할 수 있습니다.
조직의 IAM 정책을 통해 해당 API를 사용 권한이 있는 사람을 제어 할 수 있습니다. 아래와 같이 예를 들어 보겠습니다.
클라우드 및 시스템 엔지니어 또는 커널 진단 및 디버깅 전문가는 크래시 덤프에서 유용한 정보를 찾아 커널 정지 원인을 분석합니다. WinDbg (Windows) 및 crash(Linux) 와 같은 도구를 사용하여 덤프를 검사 할 수 있습니다.
진단 인터럽트 사용
이 API를 사용하는 것은 3단계 프로세스입니다. 먼저 인터럽트를 받을 때 OS의 동작을 설정해야 합니다.
기본적으로 Windows Server AMI에는 메모리 덤프가 이미 설정되어 있습니다. 메모리 덤프가 저장된 후 자동 재시작도 선택됩니다. 메모리 덤프 파일의 기본 위치는 %SystemRoot%이며, C:\Windows.에 상응합니다.
이러한 옵션에 액세스하기 위해서는
Start > Control Panel > System > Advanced System Settings > Startup and Recovery
Amazon Linux 2 에서는 kdump & kexec 를 설치 및 구성해야 합니다. 이것은 일회성 설정입니다.
$ sudo yum install kexec-tools
그런 다음 파일 /etc/default/grub을 편집하여 충돌 커널에 예약할 메모리양을 할당합니다. 이 예시에서는 crashkernel=160M 을 추가하여 160M을 예약 합니다. 할당할 메모리양은 인스턴스의 메모리 크기에 따라 다릅니다. 일반적으로 추천하는 것은 kdump로, 할당된 메모리가 충분한지 테스트하는 것이 좋습니다. 커널 문서는 crashkernel커널 매개 변수의 전체 구문을 가집니다.
GRUB_CMDLINE_LINUX_DEFAULT=”crashkernel=160M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0″
그리고 grub 구성을 다시 빌드 합니다.
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
마지막으로 /etc/sysctl.conf을 편집 하고 kernel.unknown_nmi_panic=1 을 추가하십시오. 이것은 인터럽트를 수신할 때 커널 패닉을 트리거하도록 커널에 지시합니다.
이제 인스턴스를 재부팅 할 준비가 되었습니다. 모든 인스턴스에서 자동으로 구성하려면 사용자 데이터 스크립트 또는 AMI에 이 명령을 포함시켜야 합니다. 인스턴스가 재부팅되면 kdump 가 올바르게 시작되었는지 확인하십시오 .
$ systemctl status kdump.service
● kdump.service – Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled) Active: active (exited) since Fri 2019-07-05 15:09:04 UTC; 3h 13min ago
Process: 2494 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 2494 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/kdump.service
Jul 05 15:09:02 ip-172-31-15-244.ec2.internal systemd[1]: Starting Crash recovery kernel arming…
Jul 05 15:09:04 ip-172-31-15-244.ec2.internal kdumpctl[2494]: kexec: loaded kdump kernel
Jul 05 15:09:04 ip-172-31-15-244.ec2.internal kdumpctl[2494]: Starting kdump: [OK]
Jul 05 15:09:04 ip-172-31-15-244.ec2.internal systemd[1]: Started Crash recovery kernel arming.
설명서에는 다른 운영 체제에 대한 지침이 포함되어 있습니다.
이 일회성 구성이 완료되면 두 번째 단계인 API를 트리거 할 준비가 된 것 입니다 . AWS CLI 또는 SDK가 구성된 모든 머신에서 이 작업을 수행 할 수 있습니다. 예를 들면 다음과 같습니다.
$ aws ec2 send-diagnostic-interrupt –region us-east-1 –instance-id <value>
CLI에서 리턴 값이 없는데, 이는 예상 된 것입니다. 해당 인스턴스에서 터미널 세션이 열려 있으면 연결이 끊어집니다. 인스턴스가 재부팅됩니다. 인스턴스에 다시 연결하면 /var/crash에서 크래시 덤프를 찾을 수 있습니다.
세 번째와 마지막 단계는 크래시 덤프의 내용을 분석하는 것입니다. Linux 시스템에서는 crash커널 버전에 맞는 유틸리티 및 디버깅 기호 를 설치 해야 합니다 . 커널 버전은 kdump에서 캡처 한 버전과 같아야 합니다. 현재 실행중인 커널을 찾으려면 uname -r명령을 사용합니다.
$ sudo yum install crash
$ sudo debuginfo-install kernel
$ sudo crash /usr/lib/debug/lib/modules/4.14.128-112.105.amzn2.x86_64/vmlinux /var/crash/127.0.0.1-2019-07-05-15\:08\:43/vmcore
crash 7.2.6-1.amzn2.0.1
… output suppressed for brevity …
KERNEL: /usr/lib/debug/lib/modules/4.14.128-112.105.amzn2.x86_64/vmlinux
DUMPFILE: /var/crash/127.0.0.1-2019-07-05-15:08:43/vmcore [PARTIAL DUMP]
CPUS: 2
DATE: Fri Jul 5 15:08:38 2019
UPTIME: 00:07:23
LOAD AVERAGE: 0.00, 0.00, 0.00
TASKS: 104
NODENAME: ip-172-31-15-244.ec2.internal
RELEASE: 4.14.128-112.105.amzn2.x86_64
VERSION: #1 SMP Wed Jun 19 16:53:40 UTC 2019
MACHINE: x86_64 (2500 Mhz)
MEMORY: 7.9 GB
PANIC: “Kernel panic – not syncing: NMI: Not continuing”
PID: 0
COMMAND: “swapper/0”
TASK: ffffffff82013480 (1 of 2) [THREAD_INFO: ffffffff82013480]
CPU: 0
STATE: TASK_RUNNING (PANIC)
커널 크래시 덤프 수집은 종종 커널 디버깅 정보를 수집하는 유일한 방법입니다. 특히 운영 체제를 업데이트한 후 또는 새 AMI를 생성할 때 이 절차를 자주 테스트해야 합니다.
진단 인터럽트 송신 허가자의 컨트롤
아래 예와 같이 리소스 수준 권한이 있는 IAM 정책을 통해 조직에서 진단 인터럽트를 보낼 권한이 있는 사람과 인스턴스를 제어 할 수 있습니다.
{ “Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “ec2:SendDiagnosticInterrupt”,
“Resource”: “arn:aws:ec2:region:account-id:instance/instance-id” }
]
}
가격
이 기능을 사용하는 데 대한 추가 비용은 없습니다. 그러나 진단 인터럽트를 수신한 후 인스턴스가 계속 ‘실행 중’ 상태에 있으면 평소처럼 인스턴스 청구가 계속됩니다.
가용성
A1 (Arm 기반)을 제외하고 AWS Nitro 시스템으로 구동되는 모든 EC2 인스턴스에 진단 인터럽트를 보낼 수 있습니다. 이것은C5, C5d, C5n, i3.metal , I3en, M5, M5a, M5ad, M5d, p3dn.24xlarge , R5, R5a, R5ad, R5d, T3, T3a 및 Z1d입니다.
이러한 진단 인터럽트 API는 지난 8월 15일부터 모든 공공 AWS 지역 및 GovCloud (미국)에서 이용 가능합니다.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.