Skip to main content
BeeGFS on NetApp with E-Series Storage
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

문제 해결

기여자

BeeGFS HA 클러스터 문제 해결

개요

이 섹션에서는 BeeGFS HA 클러스터를 운영할 때 발생할 수 있는 다양한 장애 및 기타 시나리오를 조사하고 해결하는 방법을 설명합니다.

문제 해결 설명서

예상치 못한 장애 조치 조사

노드가 예기치 않게 펜싱되고 해당 서비스가 다른 노드로 이동된 경우 첫 번째 단계는 클러스터가 하단에 리소스 장애를 나타내는지 확인하는 것입니다 pcs status. 펜싱이 성공적으로 완료되고 리소스가 다른 노드에서 다시 시작된 경우에는 일반적으로 아무 것도 표시되지 않습니다.

일반적으로 다음 단계는 를 사용하여 시스템 로그를 검색하는 것입니다 journalctl 나머지 파일 노드 중 하나에서(심장박동기 로그는 모든 노드에서 동기화됨) 오류가 발생한 시간을 알고 있는 경우 장애가 발생하기 바로 직전에 검색을 시작할 수 있습니다(일반적으로 10분 이상 전에 검색을 시작하는 것이 좋습니다).

journalctl --since "<YYYY-MM-DD HH:MM:SS>"

다음 섹션에서는 조사 범위를 더욱 좁히기 위해 로그에 표시할 수 있는 일반적인 텍스트를 보여 줍니다.

조사/해결 단계

1단계: BeeGFS 모니터에서 장애를 감지했는지 확인합니다.

BeeGFS 모니터에 의해 페일오버가 트리거된 경우 오류가 표시됩니다(다음 단계로 진행되지 않는 경우).

journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i unexpected
[...]
Jul 01 15:51:03 ictad22h01 pacemaker-schedulerd[9246]:  warning: Unexpected result (error: BeeGFS service is not active!) was recorded for monitor of meta_08-monitor on ictad22h02 at Jul  1 15:51:03 2022

이 경우 BeeGFS 서비스 META_08이 어떤 이유로 중지되었습니다. 문제 해결을 계속하려면 ictad22h02를 부팅하고 의 서비스 로그를 검토해야 합니다 /var/log/beegfs-meta-meta_08_tgt_0801.log. 예를 들어, BeeGFS 서비스에서 노드의 내부 문제 또는 문제로 인해 애플리케이션 오류가 발생했을 수 있습니다.

팁 페이스 메이커의 로그와 달리 BeeGFS 서비스의 로그는 클러스터의 모든 노드에 배포되지 않습니다. 이러한 유형의 장애를 조사하려면 장애가 발생한 원래 노드의 로그가 필요합니다.

모니터에서 보고할 수 있는 문제는 다음과 같습니다.

  • 대상에 액세스할 수 없습니다!

    • 설명: 블록 볼륨을 액세스할 수 없음을 나타냅니다.

    • 문제 해결:

      • 대체 파일 노드에서 서비스도 시작하지 못한 경우 블록 노드가 정상 상태인지 확인합니다.

      • 이 파일 노드에서 블록 노드에 액세스하지 못하게 하는 물리적 문제(예: InfiniBand 어댑터 또는 케이블 장애)가 있는지 확인합니다.

  • 네트워크에 연결할 수 없습니다!

    • 설명: 클라이언트가 이 BeeGFS 서비스에 연결하는 데 사용하는 어댑터 중 온라인 어댑터가 없습니다.

    • 문제 해결:

      • 여러 파일 노드/모든 파일 노드에 영향을 받은 경우 BeeGFS 클라이언트 및 파일 시스템을 연결하는 데 사용된 네트워크에 장애가 있는지 확인합니다.

      • 이 파일 노드에서 클라이언트에 액세스하지 못하게 하는 물리적 문제(예: InfiniBand 어댑터 또는 케이블 장애)가 있는지 확인합니다.

  • BeeGFS 서비스가 활성 상태가 아닙니다.

    • 설명: BeeGFS 서비스가 예기치 않게 중지되었습니다.

    • 문제 해결:

      • 오류를 보고한 파일 노드에서 영향을 받는 BeeGFS 서비스의 로그를 확인하여 충돌이 보고되었는지 확인합니다. 이 경우 NetApp Support에서 케이스를 접수하여 충돌을 조사하십시오.

      • BeeGFS 로그에 보고된 오류가 없는 경우 저널 로그를 확인하여 시스템이 서비스가 중지된 이유를 기록했는지 확인합니다. 일부 시나리오에서 BeeGFS 서비스는 프로세스가 종료되기 전에(예: 누군가 를 실행한 경우) 메시지를 기록할 수 있는 기회를 제공하지 않았을 수 있습니다 kill -9 <PID>)를 클릭합니다.

2단계: 노드가 예기치 않게 클러스터를 종료했는지 확인합니다

노드에 심각한 하드웨어 장애가 발생하거나(예: 시스템 보드가 작동하지 않음) 커널 패닉 또는 유사한 소프트웨어 문제가 발생한 경우 BeeGFS 모니터에서 오류를 보고하지 않습니다. 대신 호스트 이름을 찾으십시오. 심장박동기에서 노드가 예기치 않게 손실되었음을 나타내는 메시지가 표시됩니다.

journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i <HOSTNAME>
[...]
Jul 01 16:18:01 ictad22h01 pacemaker-attrd[9245]:  notice: Node ictad22h02 state is now lost
Jul 01 16:18:01 ictad22h01 pacemaker-controld[9247]:  warning: Stonith/shutdown of node ictad22h02 was not expected
3단계: 심장박동기가 노드를 울타리로 만들 수 있는지 확인합니다

모든 시나리오에서 노드가 실제로 오프라인 상태인지 확인하기 위해 심장박동기 펜스(pencing)를 시도하는 것을 볼 수 있습니다(정확한 메시지는 펜싱 원인에 따라 다를 수 있음).

Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]:  warning: Cluster node ictad22h02 will be fenced: peer is no longer part of the cluster
Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]:  warning: Node ictad22h02 is unclean
Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]:  warning: Scheduling Node ictad22h02 for STONITH

펜싱 작업이 성공적으로 완료되면 다음과 같은 메시지가 표시됩니다.

Jul 01 16:18:14 ictad22h01 pacemaker-fenced[9243]:  notice: Operation 'off' [2214070] (call 27 from pacemaker-controld.9247) for host 'ictad22h02' with device 'fence_redfish_2' returned: 0 (OK)
Jul 01 16:18:14 ictad22h01 pacemaker-fenced[9243]:  notice: Operation 'off' targeting ictad22h02 on ictad22h01 for pacemaker-controld.9247@ictad22h01.786df3a1: OK
Jul 01 16:18:14 ictad22h01 pacemaker-controld[9247]:  notice: Peer ictad22h02 was terminated (off) by ictad22h01 on behalf of pacemaker-controld.9247: OK

어떤 이유로 펜싱 작업이 실패한 경우 데이터 손상을 방지하기 위해 다른 노드에서 BeeGFS 서비스를 다시 시작할 수 없습니다. 예를 들어 펜싱 장치(PDU 또는 BMC)에 액세스할 수 없거나 잘못 구성된 경우 별도로 조사하는 것이 문제입니다.

실패한 리소스 작업 해결(PCS 상태 하단에 있음)

BeeGFS 서비스를 실행하는 데 필요한 리소스에 장애가 발생하면 BeeGFS 모니터에서 페일오버가 트리거됩니다. 이 경우 하단에 "실패한 리소스 작업"이 표시되지 않을 수 있습니다 pcs status 및 에 대한 단계를 참조해야 합니다 "계획되지 않은 페일오버 후 페일백".

그렇지 않으면 일반적으로 "실패한 리소스 작업"이 표시되는 두 가지 시나리오만 있어야 합니다.

조사/해결 단계

시나리오 1: 펜싱 에이전트에서 일시적 또는 영구적인 문제가 감지되어 이를 다시 시작하거나 다른 노드로 이동했습니다.

일부 펜싱 에이전트는 다른 펜싱 장치보다 신뢰성이 높으며 각 펜싱 장치가 준비되도록 자체 모니터링 방법을 구현합니다. 특히 Redfish 펜싱 에이전트가 여전히 started로 표시되더라도 다음과 같은 실패한 리소스 작업을 보고하는 것으로 나타났습니다.

  * fence_redfish_2_monitor_60000 on ictad22h01 'not running' (7): call=2248, status='complete', exitreason='', last-rc-change='2022-07-26 08:12:59 -05:00', queued=0ms, exec=0ms

특정 노드에서 장애가 발생한 리소스 작업을 보고하는 펜싱 에이전트가 해당 노드에서 실행되는 BeeGFS 서비스의 페일오버를 트리거하지 않습니다. 동일한 노드 또는 다른 노드에서 자동으로 다시 시작하기만 하면 됩니다.

해결 단계:

  1. 펜싱 에이전트가 노드 전체 또는 하위 집합에서 지속적으로 실행을 거부하는 경우 해당 노드가 펜싱 에이전트에 연결할 수 있는지 확인하고 펜싱 에이전트가 Ansible 인벤토리에서 올바르게 구성되었는지 확인합니다.

    1. 예를 들어, BMC(Redfish) 펜싱 에이전트가 펜싱을 담당하는 동일한 노드에서 실행되고 있고 OS 관리 및 BMC IP가 동일한 물리적 인터페이스에 있는 경우 일부 네트워크 스위치 구성에서는 두 인터페이스 간의 통신을 허용하지 않습니다(네트워크 루프 방지). 기본적으로 HA 클러스터는 펜싱을 담당하는 노드에 펜싱 에이전트를 배치하는 것을 피하려고 하지만 일부 시나리오/구성에서는 이러한 문제가 발생할 수 있습니다.

  2. 모든 문제가 해결되거나 문제가 일시적인 것으로 나타나는 경우 를 실행합니다 pcs resource cleanup 실패한 리소스 작업을 재설정합니다.

시나리오 2: BeeGFS 모니터가 문제를 감지하여 페일오버를 트리거했지만, 어떤 이유로 보조 노드에서 리소스를 시작할 수 없습니다.

펜싱이 활성화되고 리소스가 원래 노드에서 정지하는 것을 차단하지 않은 경우("대기(장애 발생 시)"의 문제 해결 섹션 참조), 보조 노드에서 리소스를 시작하는 데 다음과 같은 문제가 원인일 수 있습니다.

  • 보조 노드가 이미 오프라인 상태입니다.

  • 물리적 또는 논리적 구성 문제로 인해 보조 시스템에서 BeeGFS 타겟으로 사용되는 블록 볼륨에 액세스하지 못했습니다.

해결 단계:

  1. 실패한 리소스 작업의 각 항목에 대해 다음을 수행합니다.

    1. 실패한 리소스 작업이 시작 작업인지 확인합니다.

    2. 표시된 리소스와 실패한 리소스 작업에 지정된 노드를 기반으로 합니다.

      1. 노드가 지정된 리소스를 시작하지 못하는 외부 문제를 찾아 해결합니다. 예를 들어 BeeGFS IP 주소(부동 IP)를 시작하지 못한 경우 필요한 인터페이스 중 하나 이상이 온라인으로 연결되어 있고 올바른 네트워크 스위치에 케이블로 연결되어 있는지 확인합니다. BeeGFS 타겟(블록 디바이스/E-Series 볼륨)에 장애가 발생한 경우 백엔드 블록 노드에 대한 물리적 접속이 예상대로 접속되어 있는지 확인하고 블록 노드가 정상 상태인지 확인합니다.

    3. 명확한 외부 문제가 없고 이 인시던트에 대한 근본 원인이 필요한 경우, 다음 단계로 인해 근본 원인 분석(RCA)이 어렵거나 불가능할 수 있으므로 계속하기 전에 NetApp Support에서 케이스를 열어 조사하는 것이 좋습니다.

  2. 외부 문제 해결 후:

    1. Anabilities inventory.yml 파일에서 작동하지 않는 노드를 모두 제거하고 전체 Ansible 플레이북을 다시 실행하여 모든 논리적 구성이 보조 노드에 올바르게 설정되었는지 확인합니다.

      1. 참고: 노드 상태가 양호하고 페일백할 준비가 되면 이러한 노드의 주석을 해제하고 플레이북을 다시 실행하십시오.

    2. 또는 클러스터를 수동으로 복구할 수도 있습니다.

      1. 다음을 사용하여 오프라인 노드를 다시 온라인 상태로 전환: pcs cluster start <HOSTNAME>

      2. 다음을 사용하여 실패한 모든 리소스 작업을 지웁니다. pcs resource cleanup

      3. PCS 상태를 실행하고 모든 서비스가 예상대로 시작되는지 확인합니다.

      4. 필요한 경우 실행합니다 pcs resource relocate run 리소스를 원하는 노드로 다시 이동하려면(사용 가능한 경우)

일반적인 문제

BeeGFS 서비스는 요청 시 페일오버 또는 페일백을 수행하지 않습니다

  • 가능성 높은 문제: * pcs resource relocate 실행 명령이 실행되었지만 성공적으로 완료되지 않았습니다.

  • 확인 방법: * 실행 pcs constraint --full ID가 인 위치 제약 조건이 있는지 확인합니다 pcs-relocate-<RESOURCE>.

  • 해결 방법: * 실행 pcs resource relocate clear 그런 다음 다시 실행합니다 pcs constraint --full 추가 구속조건이 제거되었는지 확인합니다.

펜싱이 비활성화된 경우 PCS 상태의 노드 중 하나에 "STANDBY(ON-FAIL)"가 표시됩니다

  • 가능성 높은 문제: * 심장박동기가 실패한 노드에서 모든 리소스가 중지되었는지 확인할 수 없습니다.

  • 해결 방법: *

    1. 실행 pcs status 그리고 출력 하단에 "시작"되지 않은 리소스 또는 오류가 표시되는지 확인하고 모든 문제를 해결합니다.

    2. 노드를 다시 온라인 상태로 전환하려면 다음을 수행합니다 pcs resource cleanup --node=<HOSTNAME>.

예기치 않은 장애 조치 후 펜싱이 활성화된 경우 PCS 상태에 "started (on-fail)"가 표시됩니다

  • 가능성 높은 문제: * 장애 조치를 트리거한 문제가 발생했지만 심장박동기가 노드 펜싱되었는지 확인할 수 없었습니다. 펜싱이 잘못 구성되었거나 펜싱 에이전트(예: 네트워크에서 PDU 연결이 끊어짐)에 문제가 있기 때문에 이 문제가 발생할 수 있습니다.

  • 해결 방법: *

    1. 노드의 전원이 실제로 꺼져 있는지 확인합니다.

      중요함 지정하는 노드가 실제로 꺼져 있지 않지만 클러스터 서비스 또는 리소스를 실행하는 경우 데이터 손상/클러스터 장애가 발생합니다.

    2. 다음을 사용하여 펜싱을 수동으로 확인합니다. pcs stonith confirm <NODE>

이 시점에서 서비스는 장애 조치를 완료하고 다른 정상 노드에서 다시 시작해야 합니다.

일반적인 문제 해결 작업

개별 BeeGFS 서비스를 다시 시작합니다

일반적으로 BeeGFS 서비스를 다시 시작해야 하는 경우(예: 구성 변경을 용이하게 함) Ansible 인벤토리를 업데이트하고 플레이북을 다시 실행하여 이 작업을 수행해야 합니다. 경우에 따라 전체 Playbook을 실행할 때까지 기다릴 필요 없이 로깅 수준을 변경하는 등 더 빠른 문제 해결을 위해 개별 서비스를 다시 시작하는 것이 좋습니다.

중요함 수동 변경 사항도 Ansible 인벤토리에 추가되지 않으면 다음 번에 Ansible 플레이북을 실행할 때 되돌릴 수 있습니다.

옵션 1: 시스템 d가 재시작을 제어했습니다

BeeGFS 서비스가 새 구성으로 제대로 재시작되지 않을 위험이 있는 경우 먼저 클러스터를 유지 관리 모드로 전환하여 BeeGFS 모니터가 서비스를 감지하지 못하게 하고 원치 않는 페일오버를 트리거하는 것을 방지하십시오.

pcs property set maintenance-mode=true

필요한 경우 에서 서비스 구성을 변경합니다 /mnt/<SERVICE_ID>/_config/beegfs-.conf (예: /mnt/meta_01_tgt_0101/metadata_config/beegfs-meta.conf) 그런 다음 systemd를 사용하여 다시 시작합니다.

systemctl restart beegfs-*@<SERVICE_ID>.service

예: systemctl restart beegfs-meta@meta_01_tgt_0101.service

옵션 2: 심장박동기 제어 재시작

새로운 구성으로 인해 서비스가 예기치 않게 중지되거나(예: 로깅 수준 변경) 유지 보수 기간에 있고 다운타임이 염려되지 않는 경우 다시 시작할 서비스에 대해 BeeGFS 모니터를 다시 시작하면 됩니다.

pcs resource restart <SERVICE>-monitor

예를 들어 BeeGFS 관리 서비스를 다시 시작하려면 pcs resource restart mgmt-monitor