7.4. 운영 체제 문제 해결

OpenShift Container Platform은 RHCOS에서 실행됩니다. 다음 절차에 따라 운영 체제와 관련된 문제를 해결할 수 있습니다.

7.4.1. 커널 크래시 조사

kexec-tools에 포함된 kdump 서비스는 크래시 덤프 메커니즘을 제공합니다. 이 서비스를 사용하여 이후 분석을 위해 시스템 메모리의 컨텐츠를 저장할 수 있습니다.

kdump 서비스는 기술 프리뷰 기능으로만 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

7.4.1.1. kdump 활성화

RHCOS는 kexec-tools와 함께 제공되지만 kdump를 사용하려면 수동으로 구성해야 합니다.

절차

RHCOS에서 kdump 를 활성화하려면 다음 단계를 수행합니다.

  1. 첫 번째 커널 부팅 중에 크래시 커널의 메모리를 예약하려면 다음 명령을 입력하여 커널 인수를 제공합니다.

    # rpm-ostree kargs --append='crashkernel=256M'
  2. 선택 사항: 기본 로컬 /var/crash 위치 대신 크래시 덤프를 네트워크 또는 다른 위치에 작성하려면 /etc/kdump.conf 구성 파일을 편집합니다.

    참고

    LUKS를 사용할 때는 네트워크 덤프가 필요합니다. kdump는 LUKS 암호화 장치에서 로컬 크래시 덤프를 지원하지 않습니다.

    kdump 서비스 구성에 대한 자세한 내용은n /etc/sysconfig/kdump, /etc/kdump.conf, kdump.conf 메뉴얼 페이지의 주석을 참조하십시오. 덤프 대상 구성에 대한 자세한 내용은 RHEL kdump 문서를 참조하십시오.

  3. kdump systemd 서비스를 활성화합니다.

    # systemctl enable kdump.service
  4. 시스템을 재부팅합니다.

    # systemctl reboot
  5. kdump.service가 성공적으로 시작 및 종료하고 cat /sys/kernel/kexec_crash_loaded1을 출력하는 것을 확인하여 kdump가 크래시 커널을 로드하는지 확인합니다.

7.4.1.2. Day-1에 kdump 활성화

kdump 서비스는 노드별로 커널 문제를 디버그하도록 사용하도록 설정되어 있습니다. kdump를 활성화하는 데 드는 비용이 있고 추가 kdump 지원 노드마다 비용이 누적되므로 필요에 따라 kdump를 각 노드에서만 사용하도록 설정하는 것이 좋습니다. 각 노드에서 kdump를 활성화할 수 있는 비용은 다음과 같습니다.

  • 크래시 커널에 대해 예약된 메모리로 인해 사용 가능한 RAM이 줄어듭니다.
  • 커널이 코어를 덤프하는 동안 노드를 사용할 수 없습니다.
  • 크래시 덤프를 저장하는 데 추가 스토리지 공간이 사용됩니다.
  • kdump 서비스가 기술 프리뷰에 있기 때문에 프로덕션에 준비가 되지 않습니다.

kdump 서비스 활성화의 단점 및 장단점을 알고 있는 경우 클러스터 전체에서 kdump를 활성화할 수 있습니다. 시스템별 머신 구성은 아직 지원되지 않지만 MachineConfig 개체의 systemd 단위를 통해 이전 단계를 day-1에 수행하고 클러스터의 모든 노드에서 kdump를 사용하도록 설정할 수 있습니다. MachineConfig 개체를 생성하고 해당 개체를 클러스터 설정 중에 Ignition에서 사용하는 매니페스트 파일 세트에 삽입할 수 있습니다. Ignition 구성 사용 방법에 대한 자세한 내용은 설치 → 설치 구성 섹션의 " 노드 정의"를 참조하십시오.

절차

클러스터 전체 구성을 위한 MachineConfig 오브젝트를 생성합니다.

  1. kdump를 구성하고 활성화하는 Butane 구성 파일 99-worker-kdump.bu를 생성합니다.

    variant: openshift
    version: 4.10.0
    metadata:
      name: 99-worker-kdump 1
      labels:
        machineconfiguration.openshift.io/role: worker 2
    openshift:
      kernel_arguments: 3
        - crashkernel=256M
    storage:
      files:
        - path: /etc/kdump.conf 4
          mode: 0644
          overwrite: true
          contents:
            inline: |
              path /var/crash
              core_collector makedumpfile -l --message-level 7 -d 31
    
        - path: /etc/sysconfig/kdump 5
          mode: 0644
          overwrite: true
          contents:
            inline: |
              KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
              KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never nokaslr novmcoredd hest_disable"
              KEXEC_ARGS="-s"
              KDUMP_IMG="vmlinuz"
    
    systemd:
      units:
        - name: kdump.service
          enabled: true
    1 2
    컨트롤 플레인 노드에 MachineConfig 개체를 생성할 때 두 위치 모두에서 workermaster로 바꿉니다.
    3
    크래시 커널용 메모리를 예약하기 위해 커널 인수를 제공합니다. 필요한 경우 다른 커널 인수를 추가할 수 있습니다.
    4
    /etc/kdump.conf의 내용을 기본값에서 변경하려면 이 섹션을 포함하고 그에 따라 inline 하위 섹션을 수정합니다.
    5
    /etc/sysconfig/kdump의 내용을 기본값에서 변경하려면 이 섹션을 포함하고 이에 따라 inline 하위 섹션을 수정합니다.
  2. Butane을 사용하여 노드에 전달할 구성이 포함된 시스템 구성 YAML 파일 99-worker-kdump.yaml을 생성합니다.

    $ butane 99-worker-kdump.bu -o 99-worker-kdump.yaml
  3. 클러스터 설정 중에 YAML 파일을 매니페스트에 배치합니다. YAML 파일을 사용하여 클러스터 설정 후 이 MachineConfig 오브젝트를 생성할 수도 있습니다.

    $ oc create -f ./99-worker-kdump.yaml

7.4.1.3. kdump 설정 테스트

kdump에 대한 내용은 RHEL 문서의 kdump 설정 테스트 섹션을 참조하십시오.

7.4.1.4. 코어 덤프 분석

kdump에 대한 내용은 RHEL 문서의 코어 덤프 분석 섹션을 참조하십시오.

참고

별도의 RHEL 시스템에서 vmcore 분석을 수행하는 것이 좋습니다.

추가 리소스

7.4.2. Ignition 실패 디버깅

머신을 프로비저닝할 수 없는 경우 Ignition이 실패하고 RHCOS가 긴급 쉘로 부팅됩니다. 디버깅 정보를 얻으려면 다음 절차를 사용하십시오.

절차

  1. 다음 명령을 실행하여 어떤 서비스 단위가 실패했는지 표시합니다.

    $ systemctl --failed
  2. 선택 사항: 개별 서비스 장치에서 다음 명령을 실행하여 자세한 정보를 확인합니다.

    $ journalctl -u <unit>.service