SAP HANA 작업자 노드의 오류 검사

호스트 자동 장애 조치(Host auto-failover)는 시스템 복제 외에도 또는 시스템 복제 대신 사용할 수 있는 로컬 오류 복구 솔루션입니다. 하나 이상의 대기 호스트가 SAP HANA 시스템에 추가되어 대기 모드에서 작동하도록 구성되어 있습니다. 대기 모드인 경우 이러한 호스트의 데이터베이스에는 데이터가 포함되지 않고 요청이나 쿼리가 허용되지 않습니다. 즉, 품질 시스템이나 테스트 시스템과 같은 다른 용도로는 사용할 수 없습니다.

기본(작업) 호스트가 실패하면 대기 호스트가 자동으로 실행됩니다. (인스턴스가 중지되었거나 OS가 종료되었거나 전원이 꺼져 있어서) 이름 서버 프로세스 hdbnameserver 또는 hdbdaeman이 네트워크 요청에 응답하지 않으면 호스트가 비활성 상태로 표시되고 자동 장애 조치가 트리거됩니다. 대기 호스트는 기본 호스트의 작업을 넘겨받을 수 있기 때문에 모든 데이터베이스 볼륨에 공유 액세스를 할 수 있어야 합니다. 분산 파일 시스템을 사용하거나 SAP HANA 프로그램 인터페이스인 Storage Connector API를 사용하는 공급업체별 솔루션을 사용하여 장애 조치 시 네트워크로 연결된 공유 스토리지 서버를 동적으로 분리하고 연결(마운트)할 수 있습니다.

항상 데이터 일관성을 보장하기 위해, 실패한 호스트에서 여전히 데이터를 쓸 수 있는 경우 장애 조치가 발생하지 않거나 최소한 성공하지 못하여 손상된 데이터를 발생시키지 않아야 합니다. 이를 위해 SAP HANA 호스트 자동 장애 조치에는 하트비트(heartbeat)와 펜싱(fencing)이 사용됩니다.

다음 유형의 하트비트는 현재 호스트를 코디네이터로 시작하거나 장애 조치를 수행하기 전에 다른 호스트가 코디네이터로 활성화되어 있는지 확인하는 데 사용됩니다.

• TCP 통신 기반 하트비트:

  • SAP HANA 내부 통신 프로토콜을 사용하여 이름 서버에서이름 서버로의 Ping

  • SAP HANA 내부 통신 프로토콜을 사용하여 nameserver에서hdbdaeman으로 Ping

• 저장소 기반 하트비트:

  현재 코디네이터 이름 서버는 정기적으로 다른 저장 파티션에 위치한 하트비트 파일을 업데이트합니다:

  • SAP HANA 이진을 위한 공유 저장소

  • 코디네이터 노드의 데이터에 대한 저장소 파티션 1

  이러한 유형의 스토리지는 일반적으로 서비스-서비스 통신에 사용되는 노드 간 네트워크(예: SAN용 파이버 채널 또는 NFS용 전용 이더넷)가 아닌 네트워크와 연결되므로 이러한 하트비트는 추가적인 가치를 제공합니다.

드문 경우, 심장 박동이 다른 숙주가 살아 있는지 여부를 감지할 수 없습니다. 예를 들어 호스트 간의 통신이 불가능한 분할 뇌 상황 등입니다. I/O 펜싱은 상대방이 더 이상 데이터 또는 로그 저장소에 액세스하지 않도록 합니다.

SAP HANA Storage Connector API는 특정 Storage Connector와 함께 다음 유형의 저장소 및 네트워크 아키텍처를 사용하여 적절한 I/O 펜싱을 보장합니다.

• SAN 스토리지: SCSI-3 영구 예약(SCSI-3 PGR)을 사용하는 SAP HANA Fiber Channel Storage Connector [2].

• NFSv3: 파일 잠금 없이 사용되지만 인증된 저장소 공급업체가 제공하는 Storage Connector와 함께 사용됩니다. 이 유형의 스토리지 커넥터는 실패한 호스트를 재부팅하기 위해 헤드에있는 다른 노드 (STONITH) 호출을 촬영합니다.

  NFSv3 클라이언트가 종료되면(즉, SAP HANA 서버) 파일 잠금이 NFS 서버 측에서 해제되지 않아 이러한 파일에 액세스하려는 호스트에 대한 교착 상태가 발생합니다. 노록 마운트 옵션을 사용하면 잠금 문제가 해결되지만, 이 옵션을 사용하면 데이터가 병렬 읽기 및 다른 호스트로부터의 쓰기로부터 보호되지 않습니다. 이를 해결하려면 STONITH를 구현해야 합니다.

• NFSv4 또는 GPFS와 같은 클러스터 파일 시스템: 파일 잠금 사용. 이러한 파일 잠금으로 인해 잘못된 액세스가 방지되므로 여기에 스토리지 커넥터가 필요하지 않습니다. 그러나 일부 스토리지 공급업체에서 장애 조치 속도를 높이기 위해 STONITH 유형의 스토리지 커넥터를 제공합니다.

SAP HANA 다중 호스트 구성은 운영 체제 레벨에서도 볼 수 있습니다. $DIR_INSTANCE/exe/python_support폴더에 landscapeHostConfiguration.py 라는 Python 스크립트가 있습니다. 앞의 그림과 같이 스크립트를 실행하면 구성에 대한 개요가 표시됩니다.

이 스크립트에서는 SAP HANA 콕피트 2.0 뷰 외에 다음과 같은 호스트 열이 표시됩니다.

• STORAGE_CONFIG_PARTITION / Storage Partition (Configured - new in SPS 12): 장애 발생 후 동일한 저장소 파티션을 다시 할당할 수 있는 안정적인 하위 경로입니다.

• WORKER_CONFIG_GROUPS / Worker Groups(구성됨 - HANA 2 SPS 00의 신규): 호스트를 논리 작업자 그룹에 지정하기 위한 안정적인 분류 값입니다.

• WORKER_ACTUAL_GROUPS / 작업자 그룹(실제 - HANA 2 SPS 00의 새로운 기능): 논리 작업자 그룹에 호스트를 지정할 현재 분류 값입니다.

리턴 코드는 클러스터 관리자(예: SAP HANA 시스템 복제)가 다음과 같이 시스템 상태를 결정하는 데 사용할 수 있습니다.

• 0 = 심각 예를 들어, 데이터베이스가 오프라인입니다.

• 1 = 오류. 예를 들어, 사용 가능한 대기 호스트가 없기 때문에 장애 조치가 수행되지 않았습니다.

• 2 = 경고. 예를 들어 장애 조치가 가능합니다.

• 4 = OK

• 5 = 무시. 예를 들어, 시스템이 역할(failover)을 전환했지만 기능이 완전히 작동합니다.

리턴 코드 >= 4 는 일반 시스템 운영을 나타냅니다. 시스템이 중지되면 이 스크립트도 사용할 수 있지만 열의 하위 세트만 채웁니다.

호스트 실패는 분산 SAP HANA 시스템의 호스트 간 통신에 영향을 주는 호스트의 기능 장애 상태입니다. 호스트의 기능 상태를 확인하기 위해 이름 서버는 내부 네트워크 통신 계층에 대한 ping을 다른 호스트의 서버 이름으로 정기적으로 보냅니다. 원격 이름 서버가 반복적으로 회신하지 않는 경우 hdbdaemon 프로세스에 대한 추가 ping이 실행됩니다. 두 서비스가 제 시간에 응답하지 않는 경우에만 호스트가 실패한 것으로 간주됩니다.

서비스가 일반적으로 hdbdaemon에 의해 재시작되기 때문에 단일 서비스가 충돌해도 장애 조치가 트리거되지 않습니다. 어떤 이유로든 서비스를 재시작할 수 없는 경우 다른 호스트에서도 시작할 수 없는 것으로 간주됩니다.

스토리지 커넥터가 오류를 반환하는 경우 시작 중에 이름 서버가 중단되는 경우는 예외입니다. 그런 다음 hdbdaeman이hdbdaemon 자체를 포함하여 호스트의 전체 데이터베이스 인스턴스를 종료하도록 지시하며, 이를 통해 다른 호스트에서 오류 감지 및 장애 조치 처리를 수행할 수 있습니다.

• 이름 서버 통신 하트비트: 현재 코디네이터 이름 서버는 10초마다 다른 모든 이름 서버를 Ping합니다. 이름 서버가 활성화되어 있고 5개의 ping에 실패한 경우(즉시 또는 60초 Ping 시간 초과 후) 이름 서버는 비활성 상태로 간주됩니다. SAP HANA는 여러 번 Ping을 수행하여 장애 조치를 트리거하지 않고도 짧은 네트워크 중단에서 복구할 수 있습니다.

• hdbdaemon 통신 하트비트: 작업자 이름 서버가 비활성으로 간주되거나 비활성 상태로 설정된 경우 코디네이터 이름 서버는 작업자 hdbdaemon 프로세스를 Ping합니다. hdbdaemon ping에 실패하면(즉시 또는 60초 Ping 시간 초과 후) 호스트가 비활성 상태로 간주되고 장애 조치가 시작됩니다.

• 이름 서버 커뮤니케이션 하트비트: 현재 코디네이터가 아닌 이름 서버 후보, 낮은 우선순위의 다른 후보를 10초마다 ping합니다. 앞서 설명한 서버 하트비트(현재 코디네이터 이름 서버는 다른 모든 이름 서버를 pings), 일반적으로 COORDINATOR 1 pings COORDINATOR 2 및 COORDINATOR 3, COORDINATOR 2 pings COORDINATOR 3. 코디네이터 후보자가 30초 이내에 ping을 받지 못하면 코디네이터 이름 서버 자체를 Ping합니다.

• hdbdaemon 통신 하트비트: 코디네이터 이름 서버에 대한 ping에 실패하면 코디네이터 호스트의 hdbdaemon 프로세스가 ping됩니다. hdbdaemon 이 60초 이내에 응답하지 않으면 현재 코디네이터 호스트는 비활성 상태로 간주됩니다.

• 이름 서버 스토리지 하트비트: 이름 서버 후보 호스트는 60초 동안 하트비트 파일에 변경 사항을 확인합니다. 이러한 파일은 호스트 이름과 임의 문자열을 사용하여 현재 코디네이터 이름 서버에 의해 10초마다 업데이트됩니다. 장애 조치는 모든 파일이 60초 동안 변경된 부호를 표시하지 않는 경우에만 시작됩니다.

오류가 발견되어 대체 호스트가 결정되면 실제 장애 조치 프로세스가 시작됩니다.

앞의 그림에는 대기 호스트로의 작업 호스트 장애 조치(failover)가 표시되어 있습니다. 왼쪽에는 시스템의 원래 상태가 표시됩니다. 오른쪽에는 두 번째 호스트가 실패하고 그 역할은 네 번째 호스트로 옮겨진다.

장애 조치 단계별:

1. 대상 호스트 선택

   • 해당하는 실제 호스트 역할이 정확히 일치하는 대기 호스트가 있는 경우 이 호스트가 사용됩니다.

   • 실패 호스트에 해당하는 역할 중 하나가 있는 대기 호스트가 있는 경우 이 호스트가 사용됩니다.

   • 호스트에 SAP HANA 작업자 역할이 있으면 지정되지 않은 대기(unassigned standby)가 모두 사용됩니다.

2. 코디네이터 이름 서버는 설치된 모든 HA/DR 공급자 후크 및 Storage Connector stonith() 메서드의stonith() 메서드를 호출합니다. 일반적으로 stonith() 메서드는 NFSv3 관련 스토리지 커넥터에서만 구현되며 실패한 호스트를 재부팅합니다.

   노트

   STONITH에 실패하면 장애 조치가 중단되고 모든 호스트가 기존 역할에 유지됩니다.

3. 토폴로지에 있는 두 호스트 간에 실제 서비스, 호스트 역할, 저장소 파티션 번호 및 모든 서비스의 볼륨 ID를 바꾸고 다른 모든 호스트에 알립니다.

4. 코디네이터 이름 서버(대체 호스트를 선택함)는 대상 호스트의 이름 서버를 호출하여 장애 조치를 수행합니다.

5. 새로운 역할로 승격된 호스트는 Storage Connectors attach() 메서드를 호출하여 올바른 저장소 파티션을 가져오고(해당하는 경우) 설치된 모든 HA/DR 공급자 후크의 failover() 메서드를 호출합니다.

   노트

   이 작업이 실패하면 호스트가 중지됩니다. 대기 호스트를 계속 사용할 수 있는 경우 다른 장애 조치가 트리거되고 이 호스트가 ERROR로 설정됩니다.

6. 실행 중인 대기 서비스를 재구성하여 새로 지정된 볼륨을 로드합니다.

   노트

   실패하면 이는 서비스 실패와 같으며 추가 장애 조치를 시작하지 않습니다.

7. 두 호스트 중 하나에서만 실행되어야 하는 서비스를 시작/중지하도록 hdbdaemon을 재구성하십시오.

   노트

   이 오류가 발생하면 서비스 실패와 같으며 추가 장애 조치가 시작되지 않습니다.

코디네이터 이름 서버는 전체 시스템에서 장애 조치 대상 호스트를 선택할 수 있는 유일한 엔티티입니다. 코디네이터에는 뇌 분할 상황을 피할 수 있는 메커니즘이 있기 때문에 개념적으로 작업자 호스트에게는 분할 뇌 상황이 불가능합니다. 작업자가 코디네이터 이름 서버와의 연결을 끊으면 기다리며 새 코디네이터가 알림을 받습니다. 작업자가 시작 중에 코디네이터에 연결할 수 없으면 자동으로 종료됩니다.