다음을 통해 공유

SUSE Linux Enterprise Server에서 HSR를 사용하는 SAP HANA 스케일 아웃 시스템의 고가용성

  • 아티클

이 문서에서는 Azure SUSE Linux Enterprise Server VM(가상 머신)에서 HSR(HANA 시스템 복제) 및 Pacemaker를 사용하는 스케일 아웃 구성에서 고가용성 SAP HANA 시스템을 배포하는 방법을 설명합니다. 제시된 아키텍처의 공유 파일 시스템은 NFS 탑재이며 Azure NetApp Files 또는 Azure Files의 NFS 공유에서 제공됩니다.

예제 구성, 설치 명령 등에서 HANA 인스턴스는 03이고 HANA 시스템 ID는 HN1입니다.

시작하기 전에 다음 SAP Note와 문서를 참조하세요.

개요

HANA 스케일 아웃 설치용 HAHA 고가용성을 달성하는 방법 중 하나는 HANA 시스템 복제를 구성하고 Pacemaker 클러스터로 솔루션을 보호하여 자동 장애 조치(failover)를 허용하는 것입니다. 활성 노드에 오류가 발생하면 클러스터는 HANA 리소스를 다른 사이트로 장애 조치(failover)합니다.
제시된 구성은 각 사이트에 세 개의 HANA 노드가 표시되어 있고, 스플릿 브레인 시나리오를 방지하기 위해 주 결정자 노드도 있습니다. HANA DB 노드로 VM을 더 포함하도록 지침을 수정할 수 있습니다.

제시된 아키텍처의 HANA 공유 파일 시스템 /hana/shared는 Azure NetApp Files 또는 Azure Files의 NFS 공유에서 제공할 수 있습니다. HANA 공유 파일 시스템은 동일한 HANA 시스템 복제 사이트의 각 HANA 노드에 NFS 탑재됩니다. 파일 시스템 /hana/data 및 /hana/log는 로컬 파일 시스템이며 HANA DB 노드 사이에서 공유되지 않습니다. SAP HANA는 비공유 모드로 설치됩니다.

권장 SAP HANA 저장소 구성은 SAP HANA Azure VM 저장소 구성을 참조하세요.

Important

Azure NetApp Files의 모든 HANA 파일 시스템을 배포하는 경우, 성능이 핵심인 프로덕션 시스템의 경우 Azure NetApp Files에 모든 HANA 파일 시스템을 배포하는 경우 SAP HANA용 Azure NetApp Files 애플리케이션 볼륨 그룹을 평가하고 사용하는 것이 좋습니다.

Warning

Azure Files의 NFS에서 /hana/data 및 /hana/log 배포는 지원되지 않습니다.

SLES에서 HSR 및 Pacemaker를 사용하여 SAP HANA 스케일 아웃

위의 다이어그램에서 3개의 서브넷은 단일 Azure 가상 네트워크 내에 표시되며, SAP HANA 네트워크 권장 사항을 따릅니다.

  • 클라이언트 통신 - client 10.23.0.0/24
  • 내부 HANA 노드 간 통신 - inter 10.23.1.128/26
  • HANA 시스템 복제 - hsr 10.23.1.192/26

/hana/data 및 /hana/log는 로컬 디스크에 배포되기 때문에 스토리지와 통신하기 위해 별도의 서브넷 및 별도의 가상 네트워크 카드를 배포할 필요가 없습니다.

Azure NetApp Files를 사용하는 경우 /hana/shared의 NFS 볼륨은 Azure NetApp Files에 위임된 별도의 서브넷에 배포됩니다. anf 10.23.1.0/26.

인프라 준비

다음 지침에서는 리소스 그룹, 즉 3개의 Azure 네트워크 서브넷 client, inter 및 hsr가 있는 Azure 가상 네트워크를 만들었다고 가정합니다.

Azure Portal을 통한 Linux 가상 머신 배포

  1. Azure VM을 배포합니다.

    이 문서에 제시된 구성은 다음 7개의 가상 머신을 배포합니다.

    • HANA 복제 사이트 1용 HANA DB 노드로 사용될 가상 머신 3개: hana-s1-db1, hana-s1-db2 및 hana-s1-db3
    • HANA 복제 사이트 2용 HANA DB 노드로 사용될 가상 머신 3개: hana-s2-db1, hana-s2-db2 및 hana-s2-db3
    • 주 결정자 역할을 하는 작은 가상 머신: hana-s-mm

    SAP DB HANA 노드로 배포된 VM은 SAP HANA 하드웨어 디렉터리에 게시된 대로 SAP에서 HANA용으로 인증해야 합니다. HANA DB 노드를 배포할 때는 가속화된 네트워크를 선택해야 합니다.

    주 결정자 노드는 이 VM이 SAP HANA 리소스를 실행하지 않으므로 작은 VM을 배포할 수 있습니다. 주 결정자 VM은 스플릿 브레인 시나리오에서 홀수 클러스터 노드를 얻기 위해 클러스터 구성에 사용됩니다. 이 예제에서는 주 결정자 VM이 client 서브넷에서 하나의 가상 네트워크 인터페이스만 필요로 합니다.

    /hana/data 및 /hana/log용 로컬 관리 디스크를 배포합니다. /hana/data 및 /hana/log의 최소 권장 스토리지 구성에 관한 설명이 SAP HANA Azure VM 스토리지 구성에 나옵니다.

    client 가상 네트워크 서브넷의 각 VM별 기본 네트워크 인터페이스를 배포합니다.
    Azure Portal을 통해 VM을 배포하는 경우 네트워크 인터페이스 이름이 자동으로 생성됩니다. 편의를 위해 이 지침에서는 자동으로 생성된 기본 네트워크 인터페이스를 참조합니다. 이 인터페이스는 client Azure 가상 네트워크 서브넷에 hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client 등으로 연결됩니다.

    Important

    • 선택하는 OS가 사용 중인 특정 VM 유형에서 SAP HANA용으로 인증된 SAP인지 반드시 확인하세요. SAP HANA 인증 VM 유형과 이러한 유형의 OS 릴리스 목록은 SAP HANA 인증 IaaS 플랫폼 사이트에서 확인할 수 있습니다. 특정 유형의 SAP HANA 지원 OS 릴리스 전체 목록을 보려면 목록에 있는 VM 유형의 세부 정보를 클릭하세요.
    • Azure Files의 NFS에 /hana/shared 배포를 선택하는 경우 SLES15 SP2 이상에 배포하는 것이 좋습니다.

  2. inter 가상 네트워크 서브넷에 HANA DB 가상 머신마다 하나씩 총 6개의 네트워크 인터페이스를 만듭니다(이 예에서는 hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter, hana-s2-db3-inter).

  3. hsr 가상 네트워크 서브넷에 HANA DB 가상 머신마다 하나씩 총 6개의 네트워크 인터페이스를 만듭니다(이 예에서는 hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr, hana-s2-db3-hsr).

  4. 새로 만든 가상 네트워크 인터페이스를 해당 가상 머신에 연결합니다.

    1. Azure Portal에서 가상 머신으로 이동합니다.
    2. 왼쪽 창에서 Virtual Machines를 선택합니다. 가상 머신 이름(예: hana-s1-db1)을 필터링한 다음, 가상 머신을 선택합니다.
    3. 개요 창에서 중지를 선택하여 가상 머신의 할당을 취소합니다.
    4. 네트워킹을 선택하고 네트워크 인터페이스를 연결합니다. 네트워크 인터페이스 연결 드롭다운 목록에서 inter 및 hsr 서브넷용으로 이미 생성된 네트워크 인터페이스를 선택합니다.
    5. 저장을 선택합니다.
    6. 나머지 가상 머신도 b~e단계를 반복합니다(이 예에서는 hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2, hana-s2-db3).
    7. 지금은 가상 머신을 중지 상태로 둡니다. 이제 새로 연결된 모든 네트워크 인터페이스에 대해 가속화된 네트워킹을 사용하도록 설정합니다.

  5. 다음 단계를 수행하여 inter 및 hsr 서브넷의 추가 네트워크 인터페이스에 가속화된 네트워킹을 사용하도록 설정합니다.

    1. Azure Portal에서 Azure Cloud Shell을 엽니다.

    2. 다음 명령을 실행하여 inter 및 hsr 서브넷에 연결된 추가 네트워크 인터페이스에 가속화된 네트워킹을 사용하도록 설정합니다.

      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

  6. HANA DB 가상 머신 시작

Azure Load Balancer 구성

VM 구성 중에 네트워킹 섹션에서 기존 부하 분산 장치를 만들거나 선택할 수 있는 옵션이 있습니다. HANA 데이터베이스의 고가용성 설정을 위해 표준 부하 분산 장치를 설정하려면 아래 단계를 따릅니다.

참고 항목

  • HANA 스케일 아웃의 경우 백 엔드 풀에 가상 머신을 추가할 때 client 서브넷에 대한 NIC를 선택합니다.
  • Azure CLI 및 PowerShell의 전체 명령 집합은 백 엔드 풀에 기본 NIC가 있는 VM을 추가합니다.

Azure Portal을 사용하여 고가용성 SAP 시스템용 표준 Load Balancer를 설정하려면 부하 분산 장치 만들기의 단계를 따릅니다. 부하 분산 장치를 설정하는 동안 다음 사항을 고려합니다.

  1. 프런트 엔드 IP 구성: 프런트 엔드 IP를 만듭니다. 데이터베이스 가상 머신과 동일한 가상 네트워크 및 서브넷 이름을 선택합니다.
  2. 백 엔드 풀: 백 엔드 풀을 만들고 데이터베이스 VM을 추가합니다.
  3. 인바운드 규칙: 부하 분산 규칙을 만듭니다. 두 부하 분산 규칙 모두에 대해 동일한 단계를 수행합니다.
    • 프런트 엔드 IP 주소: 프런트 엔드 IP를 선택합니다.
    • 백 엔드 풀: 백 엔드 풀을 선택합니다.
    • 고가용성 포트: 이 옵션을 선택합니다.
    • 프로토콜: TCP를 선택합니다.
    • 상태 프로브: 다음 세부 정보를 사용하여 상태 프로브를 만듭니다.
      • 프로토콜: TCP를 선택합니다.
      • 포트: 예, 625<instance-no.>.
      • 간격: 5를 입력합니다.
      • 프로브 임계값: 2를 입력합니다.
    • 유휴 시간 제한(분): 30을 입력합니다.
    • 부동 IP 사용: 이 옵션을 선택합니다.

참고 항목

포털에서 비정상 임계값이라고도 알려진 상태 프로브 구성 속성 numberOfProbes는 준수되지 않습니다. 성공하거나 실패한 연속 프로브 수를 제어하려면 probeThreshold 속성을 2로 설정합니다. 현재 Azure Portal을 사용하여 이 속성을 설정할 수 없으므로 Azure CLI 또는 PowerShell 명령을 사용합니다.

참고 항목

공용 IP 주소가 없는 VM이 내부(공용 IP 주소 없음) 표준 Azure 부하 분산 장치의 백 엔드 풀에 배치되는 경우 공용 엔드포인트로 라우팅을 허용하기 위해 추가 구성을 수행하지 않는 한 아웃바운드 인터넷 연결이 없습니다. 아웃바운드 연결을 설정하는 방법에 대한 자세한 내용은 SAP 고가용성 시나리오에서 Azure 표준 Load Balancer를 사용하는 Virtual Machines에 대한 퍼블릭 엔드포인트 연결을 참조하세요.

Important

  • Azure Load Balancer 뒤에 배치되는 Azure VM에서 TCP 타임스탬프를 사용하도록 설정하면 안 됩니다. TCP 타임스탬프를 사용하도록 설정하면 상태 프로브에 오류가 발생합니다. 매개 변수 net.ipv4.tcp_timestamps를 0으로 설정합니다. 자세한 내용은 Load Balancer 상태 프로브 및 SAP Note 2382421을 참조하세요.
  • saptune이 수동으로 설정된 net.ipv4.tcp_timestamps 값을 0에서 다시 1(으)로 변경하지 못하게 하려면 saptune 버전을 3.1.1 이상으로 업데이트합니다. 자세한 내용은 saptune 3.1.1 – 업데이트가 필요하나요?를 참조하세요.

NFS 배포

/hana/shared에 대한 Azure 네이티브 NFS 배포에는 두 가지 옵션이 있습니다. Azure NetApp Files 또는 Azure Files의 NFS 공유에 NFS 볼륨을 배포할 수 있습니다. Azure Files는 NFSv4.1 프로토콜을 지원하며, NFS on Azure NetApp Files는 NFSv4.1 및 NFSv3을 모두 지원합니다.

다음 섹션에서는 NFS를 배포하는 단계에 대해 설명합니다. 옵션 중 하나만 선택해야 합니다.

팁

Azure Files의 NFS 공유 또는 Azure NetApp Files의 NFS 볼륨에 /hana/shared를 배포하도록 선택했습니다.

Azure NetApp Files 인프라 배포

/hana/shared 파일 시스템에 대한 Azure NetApp Files 볼륨을 배포합니다. HANA 시스템 복제 사이트마다 별도의 /hana/shared 볼륨이 필요합니다. 자세한 내용은 Azure NetApp Files 인프라 설정을 참조하세요.

이 예제에서는 다음과 같은 Azure NetApp Files 볼륨이 사용되었습니다.

  • 볼륨 HN1-shared-s1(nfs://10.23.1.7/HN1-shared-s1)
  • 볼륨 HN1-shared-s2(nfs://10.23.1.7/HN1-shared-s2)

Azure Files의 NFS 인프라 배포

/hana/shared 파일 시스템에 대한 Azure Files NFS 공유를 배포합니다. 각 HANA 시스템 복제 사이트에 대해 별도의 /hana/shared Azure Files NFS 공유가 필요합니다. 자세한 내용은 NFS 공유를 만드는 방법을 참조하세요.

이 예에서는 다음 Azure Files NFS 공유가 사용되었습니다.

  • hn1-shared-s1 공유(sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
  • hn1-shared-s2 공유(sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

운영 체제 구성 및 준비

다음 섹션의 지침에는 다음 약어 중 하나가 접두사로 추가됩니다.

  • [A]: 대부분의 결정자를 포함한 모든 노드에 적용 가능
  • [AH]: 모든 HANA DB 노드에 적용 가능
  • [M]: 주 결정자 노드에만 적용 가능
  • [AH1]: SITE 1의 모든 HANA DB 노드에 적용 가능
  • [AH2]: SITE 2의 모든 HANA DB 노드에 적용 가능
  • [1]: SITE 1의 HANA DB 노드 1에만 적용 가능
  • [2]: SITE 2의 HANA DB 노드 1에만 적용 가능

다음 단계를 수행하여 OS를 구성하고 준비합니다.

  1. [A] 가상 머신에서 호스트 파일을 유지 관리합니다. 모든 서브넷에 대한 항목을 포함합니다. 이 예제의 /etc/hosts에 추가된 항목은 다음과 같습니다.

    # Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

  2. [A] Microsoft for Azure 구성 설정을 사용하여 구성 파일 /etc/sysctl.d/ms-az.conf를 만듭니다.

    vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10

    팁

    SAP 호스트 에이전트가 포트 범위를 관리할 수 있도록 sysctl 구성 파일에서 net.ipv4.ip_local_port_range 및 net.ipv4.ip_local_reserved_ports를 명시적으로 설정하지 마세요. 자세한 내용은 SAP Note 2382421을 참조하세요.

  3. [A] SUSE는 SAP HANA에 대한 특수 리소스 에이전트를 제공하고 SAP HANA 스케일 업에 대한 기본 에이전트를 설치합니다. 설치한 경우 스케일 업용 패키지를 제거하고 시나리오 SAP HANA 스케일 아웃 패키지를 설치합니다. 이 단계는 주 결정자를 비롯한 모든 클러스터 VM에서 수행해야 합니다.

    참고 항목

    SAPHanaSR-ScaleOut 버전 0.181 이상을 설치해야 합니다.

    # Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles

  4. [AH] VM 준비 - SAP 애플리케이션에 대한 SUSE Linux Enterprise Server의 SAP Note 2205917에 권장되는 설정을 적용합니다.

파일 시스템 준비

Azure Files의 NFS 공유 또는 Azure NetApp Files의 NFS 볼륨에 SAP 공유 디렉터리를 배포하도록 선택했습니다.

공유 파일 시스템 탑재(Azure NetApp Files NFS)

이 예에서는 공유 HANA 파일 시스템이 Azure NetApp Files에 배포되고 NFSv4.1을 통해 탑재됩니다. Azure NetApp Files에서 NFS를 사용하는 경우에만 이 섹션의 단계를 따릅니다.

  1. [AH] SAP Note 3024346 - NetApp NFS용 Linux 커널 설정에 설명된 대로 NFS를 사용하여 NetApp Systems의 SAP HANA를 실행하기 위한 OS를 준비합니다. NetApp 구성 설정에 대한 구성 파일 /etc/sysctl.d/91-NetApp-HANA.conf를 만듭니다.

    vi /etc/sysctl.d/91-NetApp-HANA.conf

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

  2. [AH] SAP Note 3024346 - NetApp NFS용 Linux 커널 설정에 권장된 대로 sunrpc 설정을 조정합니다.

    vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128

  3. [AH] HANA 데이터베이스 볼륨의 탑재 지점을 만듭니다.

    mkdir -p /hana/shared

  4. [AH] NFS 도메인 설정을 확인합니다. 도메인이 기본 Azure NetApp Files 도메인, 즉 defaultv4iddomain.com으로 구성되어 있고 매핑이 nobody로 설정되어 있는지 확인합니다.
    이 단계는 Azure NetAppFiles NFSv 4.1을 사용하는 경우에만 필요합니다.

    Important

    VM의 /etc/idmapd.conf에서 NFS 도메인을 Azure NetApp Files의 기본 도메인 구성(defaultv4iddomain.com)과 일치하도록 설정해야 합니다. NFS 클라이언트(예: VM)의 도메인 구성과 NFS 서버(예: Azure NetApp 구성)가 일치하지 않는 경우 VM에 탑재된 Azure NetApp 볼륨의 파일에 대한 사용 권한이 nobody로 표시됩니다.

    sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

  5. [AH] nfs4_disable_idmapping을 확인합니다. Y로 설정되어야 합니다. nfs4_disable_idmapping이 있는 디렉터리 구조를 만들려면 mount 명령을 실행합니다. 커널/드라이버용으로 액세스가 예약되어 있기 때문에 /sys/modules 아래에 디렉터리를 수동으로 만들 수 없습니다.
    이 단계는 Azure NetAppFiles NFSv 4.1을 사용하는 경우에만 필요합니다.

    # Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

  6. [AH1] SITE1 HANA DB VM에 공유 Azure NetApp Files 볼륨을 탑재합니다.

    sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

  7. [AH2] SITE2 HANA DB VM에 공유 Azure NetApp Files 볼륨을 탑재합니다.

    sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

  8. [AH] 해당 /hana/shared/ 파일 시스템이 NFS 프로토콜 버전 NFSv4.1을 사용하는 모든 HANA DB VM에 탑재되어 있는지 확인합니다.

    sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

공유 파일 시스템 탑재(Azure Files NFS)

이 예에서 공유 HANA 파일 시스템은 Azure Files의 NFS에 배포됩니다. Azure Files의 NFS를 사용하는 경우에만 이 섹션의 단계를 따릅니다.

  1. [AH] HANA 데이터베이스 볼륨의 탑재 지점을 만듭니다.

    mkdir -p /hana/shared

  2. [AH1] SITE1 HANA DB VM에 공유 Azure NetApp Files 볼륨을 탑재합니다.

    sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

  3. [AH2] SITE2 HANA DB VM에 공유 Azure NetApp Files 볼륨을 탑재합니다.

    sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

  4. [AH] 해당 /hana/shared/ 파일 시스템이 NFS 프로토콜 버전 NFSv4.1을 사용하는 모든 HANA DB VM에 탑재되어 있는지 확인합니다.

    sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

데이터 및 로그 로컬 파일 시스템 준비

제시된 구성에서 파일 시스템 /hana/data 및 /hana/log는 관리 디스크에 배포되고 각 HANA DB VM에 로컬로 연결됩니다. 각 HANA DB 가상 머신에서 로컬 데이터 및 로그 볼륨을 만드는 단계를 실행해야 합니다.

LVM(논리 볼륨 관리자)을 사용하여 디스크 레이아웃을 설정합니다. 다음 예제에서는 각 HANA 가상 머신에 3개의 데이터 디스크가 연결되어 있고, 이러한 데이터 디스크는 2개의 볼륨을 만드는 데 사용된다고 가정합니다.

  1. [AH] 사용 가능한 모든 디스크를 나열합니다.

    ls /dev/disk/azure/scsi1/lun*

    예제 출력:

    /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2

  2. [AH] 사용하려는 모든 디스크의 물리적 볼륨을 만듭니다.

    sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2

  3. [AH] 데이터 파일에 대한 볼륨 그룹을 만듭니다. 로그 파일에 대해 한 볼륨 그룹, SAP HANA의 공유 디렉터리에 대해 한 볼륨을 사용합니다.

    sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2

  4. [AH] 논리 볼륨을 만듭니다.

    -i 스위치 없이 lvcreate를 사용하는 경우 선형 볼륨이 만들어집니다. 더 나은 I/O 성능을 위해 스트라이프 볼륨을 만들고 SAP HANA VM 스토리지 구성에 설명된 값에 스트라이프 크기를 정렬하는 것이 좋습니다. -i 인수는 기본 실제 볼륨의 수여야 하며 -I 인수는 스트라이프 크기입니다. 이 문서에서는 2개의 물리적 볼륨이 데이터 볼륨에 사용되므로 -i 스위치 인수가 2로 설정됩니다. 데이터 볼륨의 스트라이프 크기는 256KiB입니다. 로그 볼륨에는 하나의 실제 볼륨이 사용되므로 -i 또는 -I 스위치는 로그 볼륨 명령에 명시적으로 사용되지 않습니다.

    Important

    각 데이터 또는 로그 볼륨에 대해 하나 이상의 물리적 볼륨을 사용하는 경우 -i 스위치를 사용하고 기본 물리적 볼륨 수로 설정합니다. 스트라이프 볼륨을 만들 때 -I 스위치를 사용하여 스트라이프 크기를 지정합니다.
    스트라이프 크기 및 디스크 수를 비롯한 권장되는 스토리지 구성은 SAP HANA VM 스토리지 구성을 참조하세요.

    sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log

  5. [AH] 탑재 디렉터리를 만들고 모든 논리 볼륨의 UUID를 복사합니다.

    sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

  6. [AH] 논리 볼륨에 대한 fstab 항목을 만들고 탑재합니다.

    sudo vi /etc/fstab

    /etc/fstab 파일에서 다음 줄을 삽입합니다.

    /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

    새 볼륨을 탑재합니다.

    sudo mount -a

Pacemaker 클러스터 만들기

이 HANA 서버에 대한 기본 Pacemaker 클러스터를 만들려면 Azure의 SUSE Linux Enterprise Server에서 Pacemaker 설정 단계를 따르세요. 클러스터의 주 결정자를 비롯한 모든 가상 머신을 포함합니다.

Important

quorum expected-votes를 2로 설정하지 마세요. 2노드 클러스터가 아닙니다.
노드 펜싱이 역직렬화되도록 클러스터 속성 concurrent-fencing을 사용하도록 설정해야 합니다.

설치

이 예제에서는 Azure VM에서 HSR을 사용하여 스케일 아웃 구성에 SAP HANA를 배포하기 위해 HANA 2.0 SP5를 사용했습니다.

HANA 설치 준비

  1. [AH] HANA 설치 전에 루트 암호를 설정합니다. 설치가 완료된 후 루트 암호를 사용하지 않도록 설정할 수 있습니다. root 명령 passwd로 실행합니다.

  2. [1,2] /hana/shared의 사용 권한을 변경합니다.

    chmod 775 /hana/shared

  3. [1] 암호를 입력하라는 메시지가 표시되지 않고, 이 사이트의 Hana DB VM( hana-s1-db2 및 hana- s1-db3)에 SSH를 통해 로그인할 수 있는지 확인합니다. 안 되는 경우에는 공개 키를 통해 SSH 액세스 사용의 설명대로 ssh 키를 교환합니다.

    ssh root@hana-s1-db2
ssh root@hana-s1-db3

  4. [2] 암호를 입력하라는 메시지가 표시되지 않고, 이 사이트의 HANA DB VM(hana-s2-db2 및 hana-s2-db3)에 SSH를 통해 로그인할 수 있는지 확인합니다.
    안 되는 경우에는 ssh 키를 교환합니다.

    ssh root@hana-s2-db2
ssh root@hana-s2-db3

  5. [AH] HANA 2.0 SP4 이상에 필요한 추가 패키지를 설치합니다. 자세한 내용은 SLES 버전에 대한 SAP Note 2593824 을 참조하세요.

    # In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1

각 사이트의 첫 번째 노드에 HANA 설치

  1. [1] SAP HANA 2.0 설치 및 업데이트 가이드의 지침에 따라 SAP HANA를 설치합니다. 다음 지침에서는 SITE 1의 첫 번째 노드에 SAP HANA를 설치하는 방법을 보여줍니다.

    a. hdblcm 프로그램을 HANA 설치 소프트웨어 디렉터리의 root로 시작합니다. internal_network 매개변수를 사용하고, 내부 HANA 노드 간 통신에 사용되는 서브넷의 주소 공간을 전달합니다.

    ./hdblcm --internal_network=10.23.1.128/26

    b. 프롬프트에서 다음 값을 입력합니다.

    • 작업 선택: 1 입력(설치의 경우)
    • 설치할 추가 구성요소: 2, 3 입력
    • 설치 경로: Enter 키 누르기(기본값은 /hana/shared).
    • 로컬 호스트 이름: 기본값을 적용하려면 Enter 키를 누릅니다.
    • 시스템에 호스트를 추가하시겠습니까?: n 입력
    • SAP HANA 시스템 ID: HN1 입력
    • 인스턴스 번호 [00]: 03 입력
    • 로컬 호스트 작업자 그룹 [기본값]: Enter 키를 눌러 기본값 적용
    • 시스템 사용량 선택/인덱스 입력 [4]: 4 입력(사용자 지정)
    • 데이터 볼륨의 위치 [/hana/data/HN1]: Enter 키를 눌러 기본값 적용
    • 로그 볼륨의 위치 [/hana/log/HN1]: Enter 키를 눌러 기본값 적용
    • 최대 메모리 할당을 제한하려고 하나요? [n]: n 입력
    • 호스트 hana-s1-db1의 인증서 호스트 이름 [hana-s1-db1]: Enter를 눌러 기본값 적용
    • SAP 호스트 에이전트 사용자(sapadm) 암호: 암호 입력
    • SAP 호스트 에이전트 사용자(sapadm) 암호 확인: 암호 입력
    • 시스템 관리자(hn1adm) 암호: 암호 입력
    • 시스템 관리자 홈 디렉터리 [/usr/sap/HN1/home]: Enter 키를 눌러 기본값 적용
    • 시스템 관리자 로그인 셸 [/bin/sh]: Enter 키를 눌러 기본값 적용
    • 시스템 관리자 사용자 ID [1001]: Enter 키를 눌러 기본값 적용
    • 사용자 그룹의 ID 입력(sapsys) [79]: Enter 키를 눌러 기본값 적용
    • 시스템 데이터베이스 사용자(system) 암호: 시스템 암호 입력
    • 시스템 데이터베이스 사용자(system) 암호 확인: 시스템 암호 입력
    • 컴퓨터 다시 부팅 후 컴퓨터를 다시 시작하려고 하나요? [n]: n을 입력합니다.
    • 계속하시겠습니까(y/n): 요약의 유효성을 검사하고 모든 항목이 양호하면 y 입력

  2. [2] 이전 단계를 반복하여 SITE 2의 첫 번째 노드에 SAP HANA를 설치합니다.

  3. [1,2] global.ini 확인

    global.ini를 표시하고 내부 SAP HANA 노드 간 통신에 대한 구성이 준비되었는지 확인합니다. 통신 섹션을 확인합니다. inter 서브넷의 주소 공간이 있어야 하고 listeninterface가 .internal로 설정되어야 합니다. internal_hostname_resolution 섹션을 확인합니다. inter 서브넷에 속하는 HANA 가상 머신의 IP 주소가 있어야 합니다.

      sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3

  4. [1,2] SAP 노트 2080991의 설명대로 비공유 환경에 global.ini를 설치할 준비를 합니다.

     sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no

  5. [1,2] SAP HANA를 다시 시작하여 변경 내용을 활성화합니다.

     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

  6. [1,2] 클라이언트 인터페이스에서 통신용 client 서브넷의 IP 주소를 사용하는지 확인합니다.

    # Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"

    구성을 확인하는 방법은 SAP 노트 2183363 - SAP HANA 내부 네트워크 구성을 참조하세요.

  7. [AH] HANA 설치 오류를 방지하려면 데이터 및 로그 디렉터리에 대한 사용 권한을 변경하세요.

     sudo chmod o+w -R /hana/data /hana/log

  8. [1] 보조 HANA 노드를 설치합니다. 이 단계의 예제 지침은 SITE 1에 해당합니다.

    a. 상주 hdblcm 프로그램을 root로 시작합니다.

     cd /hana/shared/HN1/hdblcm
 ./hdblcm

    b. 프롬프트에서 다음 값을 입력합니다.

    • 작업 선택: 2 입력(호스트 추가의 경우)
    • 쉼표로 구분된 호스트 이름 입력: hana-s1-db2, hana-s1-db3
    • 설치할 추가 구성요소: 2, 3 입력
    • 루트 사용자 이름 [root] 입력: Enter 키를 눌러 기본값 적용
    • 'hana-s1-db2' [1]의 역할 선택: 1(작업자의 경우)
    • 'hana-s1-db2' 호스트에 대한 호스트 장애 조치(failover) 그룹 입력 [기본값]: Enter 키를 눌러 기본값 적용
    • 호스트 'hana-s1-db2'의 스토리지 파티션 번호 입력 [<<자동 할당>>]: Enter 키를 눌러 기본값을 적용합니다.
    • 'hana-s1-db2' 호스트에 대한 작업자 그룹 입력 [기본값]: Enter 키를 눌러 기본값 적용
    • 'hana-s1-db3' [1]의 역할 선택: 1(작업자의 경우)
    • 'hana-s1-db3' 호스트에 대한 호스트 장애 조치(failover) 그룹 입력 [기본값]: Enter 키를 눌러 기본값 적용
    • 호스트 'hana-s1-db3'의 스토리지 파티션 번호 입력 [<<자동 할당>>]: Enter 키를 눌러 기본값을 적용합니다.
    • 'hana-s1-db3' 호스트에 대한 작업자 그룹 입력 [기본값]: Enter 키를 눌러 기본값 적용
    • 시스템 관리자(hn1adm) 암호: 암호 입력
    • SAP 호스트 에이전트 사용자(sapadm) 암호 입력: 암호 입력
    • SAP 호스트 에이전트 사용자(sapadm) 암호 확인: 암호 입력
    • 호스트 hana-s1-db2의 인증서 호스트 이름 [hana-s1-db2]: Enter를 눌러 기본값 적용
    • 호스트 hana-s1-db3의 인증서 호스트 이름 [hana-s1-db3]: Enter를 눌러 기본값 적용
    • 계속하시겠습니까(y/n): 요약의 유효성을 검사하고 모든 항목이 양호하면 y 입력

  9. [2] SITE 2에 보조 SAP HANA 노드를 설치하는 이전 단계를 반복합니다.

SAP HANA 2.0 시스템 복제 구성

  1. [1] SITE 1에 시스템 복제 구성

    데이터베이스를 hn1adm으로 백업합니다.

    hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"

    시스템 PKI 파일을 보조 사이트에 복사합니다.

    scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

    기본 사이트를 만듭니다.

    hdbnsutil -sr_enable --name=HANA_S1

  2. [2] SITE 2에 시스템 복제 구성

    두 번째 사이트를 등록하여 시스템 복제를 시작합니다. 다음 명령을 <hanasid>adm으로 실행합니다.

    sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

  3. [1] 복제 상태 확인

    복제 상태를 확인하고 모든 데이터베이스가 동기화될 때까지 기다립니다.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

# | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
#
# mode: PRIMARY
# site id: 1
# site name: HANA_S1

  4. [1,2] HANA 시스템 복제 가상 네트워크 인터페이스를 통해 전달된 경우 HANA 시스템 복제용 통신이 되도록 HANA 구성을 변경합니다.

    • 두 사이트에서 HANA 중지

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB

    • global.ini를 편집하여 HANA 시스템 복제용 호스트 매핑 추가: hsr 서브넷의 IP 주소를 사용합니다.

      sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3

    • 두 사이트에서 HANA 시작

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB

    자세한 내용은 시스템 복제용 호스트 이름 확인을 참조하세요.

파일 시스템 리소스 만들기

NFS 탑재 파일 시스템 /hana/shared에 액세스하는 데 문제가 있는 경우 오류를 모니터링하고 보고하는 더미 파일 시스템 클러스터 리소스를 만듭니다. 이를 통해 클러스터는 /hana/shared에 액세스하는 데 문제가 있는 경우 장애 조치를 트리거할 수 있습니다. 자세한 내용은 HANA 시스템 복제용 SUSE HA 클러스터에서 실패한 NFS 공유 처리를 참조하세요.

  1. [1] Pacemaker를 유지 관리 모드로 전환하여 HANA 클러스터 리소스 만들기를 준비합니다.

    crm configure property maintenance-mode=true

  2. [1,2] NFS가 탑재된 파일 시스템 /hana/shared에 디렉터리를 만듭니다. 이 디렉터리는 특수 파일 시스템 모니터링 리소스에 사용됩니다. 두 사이트 모두에서 디렉터리를 만들어야 합니다.

    mkdir -p /hana/shared/HN1/check

  3. [AH] 특수 파일 시스템 모니터링 리소스를 탑재하는 데 사용될 디렉터리를 만듭니다. 모든 HANA 클러스터 노드에서 디렉터리를 만들어야 합니다.

    mkdir -p /hana/check

  4. [1] 파일 시스템 클러스터 리소스를 만듭니다.

    crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm

    OCF_CHECK_LEVEL=20 특성이 모니터 작업에 추가되어 모니터 작업에서 파일 시스템의 읽기/쓰기 테스트를 수행합니다. 이 특성이 없으면 모니터 작업은 파일 시스템이 탑재되어 있는지만 확인합니다. 이는 연결이 끊어질 때 파일 시스템에 액세스할 수 없는 경우에도 탑재된 상태를 유지할 수 있기 때문에 문제가 될 수 있습니다.

    on-fail=fence 특성도 모니터 작업에 추가됩니다. 이 옵션을 사용하면 노드에서 모니터 작업이 실패하는 경우 해당 노드가 즉시 펜싱됩니다.

HANA HA 후크 SAPHanaSrMultiTarget 및 susChkSrv 구현

이 중요한 단계는 클러스터와의 통합을 최적화하고 클러스터 장애 조치(failover)가 가능한 경우 이를 감지하기 위한 단계입니다. SAPHanaSR Python 후크를 구성하는 것이 좋습니다. HANA 2.0 SP5 이상의 경우 SAPHanaSrMultiTarget 및 susChkSrv 후크를 모두 구현하는 것이 좋습니다.

참고 항목

SAPHanaSrMultiTarget HA 공급자가 HANA 스케일 아웃을 위해 SAPHanaSR을 대체합니다. SAPHanaSR은 이 문서의 이전 버전에서 설명했습니다.
새로운 HANA HA 후크의 변경 내용은 SUSE 블로그 게시물을 참조하세요.

SAPHanaSrMultiTarget 후크에 대해 나와 있는 단계는 새 설치를 위한 것입니다. 기존 환경을 SAPHanaSR에서 SAPHanaSrMultiTarget 공급자로 업그레이드하려면 몇 가지 사항을 변경해야 하며, 이는 이 문서에 설명되어 있지 않습니다. 기존 환경에서 재해 복구에 세 번째 사이트를 사용하지 않고 HANA 다중 대상 시스템 복제를 사용하지 않는 경우 SAPHanaSR HA 공급자를 계속 사용할 수 있습니다.

SusChkSrv는 기본 SAPHanaSrMultiTarget HA 공급자의 기능을 확장합니다. 이는 HANA 프로세스 hdbindexserver가 충돌하는 상황에서 작동합니다. 단일 프로세스가 충돌하는 경우 일반적으로 HANA에서 프로세스를 다시 시작하려고 시도합니다. 인덱스 서버 프로세스를 다시 시작하는 데 시간이 오래 걸릴 수 있으며 이 시간 동안 HANA 데이터베이스가 응답하지 않습니다. susChkSrv가 구현되면 hdbindexserver 프로세스가 동일한 노드에서 다시 시작될 때까지 기다리지 않고, 즉각적인 구성 가능한 작업이 실행됩니다. HANA 스케일 아웃에서 susChkSrv는 모든 HANA VM에 대해 독립적으로 작동합니다. 구성된 작업은 HANA를 종료하거나 영향을 받는 VM을 펜스합니다. 그러면 구성된 제한 시간에 장애 조치(failover)가 트리거됩니다.

두 HANA HA 후크가 모두 작동하려면 SUSE SLES 15 SP1 이상이 필요합니다. 다음 표에는 다른 종속성이 나와 있습니다.

SAP HANA HA 후크 HANA 버전 필요 SAPHanaSR-ScaleOut 필요
SAPHanaSrMultiTarget HANA 2.0 SPS4 이상 0.180 이상
susChkSrv HANA 2.0 SPS5 이상 0.184.1 이상

두 후크를 모두 구현하기 위한 단계는 다음과 같습니다.

  1. [1,2] 두 시스템 복제 사이트 모두에서 HANA를 중지합니다. <sid>adm으로 실행:

    sapcontrol -nr 03 -function StopSystem

  2. [1,2] 각 클러스터 사이트에서 global.ini를 조정합니다. susChkSrv 후크의 필수 구성 요소가 충족되지 않은 경우 전체 블록 [ha_dr_provider_suschksrv]를 구성해서는 안 됩니다.
    매개 변수 action_on_lost를 사용하여 susChkSrv의 동작을 조정할 수 있습니다. 유효한 값은 [ ignore | stop | kill | fence ]입니다.

    # add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info

    SUSE에서 제공되는 HA 후크의 기본 위치는 /usr/share/SAPHanaSR-ScaleOut입니다. 표준 위치를 사용하면 Python 후크 코드가 OS 또는 패키지 업데이트를 통해 자동으로 업데이트되고 다음 재시작 시 HANA에서 사용된다는 이점이 있습니다. /hana/shared/myHooks와 같은 자체 경로(선택 사항)를 사용하면 OS 업데이트를 사용된 후크 버전과 분리할 수 있습니다.

  3. [AH] 클러스터의 <sid>adm용 클러스터 노드에 sudoers 구성이 필요합니다. 이 예제에서는 새 파일을 만들어 수행합니다. 올바른 소문자 SID를 사용해 hn1 값을 조정하고 root 명령을 실행합니다.

    cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

  4. [1,2] 두 복제 사이트에서 SAP HANA를 시작합니다. <sid>adm으로 실행합니다.

    sapcontrol -nr 03 -function StartSystem

  5. [A] 후크 설치가 모든 클러스터 노드에 활성화되어 있는지 확인합니다. <sid>adm으로 실행합니다.

    cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

    susChkSrv 후크 설치를 확인합니다. <sid>adm으로 실행합니다.

    cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

SAP HANA 클러스터 리소스 만들기

  1. [1] HANA 클러스터 리소스를 만듭니다. 다음 명령을 root로 실행합니다.

    1. 클러스터가 이미 유지 관리 모드인지 확인합니다.

    2. 그 다음에 HANA 토폴로지 리소스를 만듭니다.

      sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

    3. 그리고 HANA 인스턴스 리소스를 만듭니다.

      참고 항목

      이 문서에는 Microsoft가 더 이상 사용하지 않는 용어에 대한 참조가 포함되어 있습니다. 해당 용어가 소프트웨어에서 제거되면 이 문서에서도 제거할 것입니다.

      sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"

      Important

      철저한 장애 조치(failover) 테스트를 수행하는 동안 AUTOMATED_REGISTER를 아니요로 설정하여 실패한 기본 인스턴스가 보조로 자동 등록되는 것을 방지하는 것이 좋습니다. 장애 조치(failover) 테스트가 성공적으로 완료되었으면 인수 후 시스템 복제가 자동으로 다시 시작할 수 있도록 AUTOMATED_REGISTER를 예로 설정합니다.

    4. 가상 IP 및 연결된 리소스를 만듭니다.

      sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

    5. 클러스터 제약 조건 만들기

      # Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

  2. [1] 추가 클러스터 속성을 구성합니다.

    sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

  3. [1] 클러스터를 유지 관리 모드에서 제외시킵니다. 클러스터 상태가 정상이며 모든 리소스가 시작되었는지 확인합니다.

    # Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

  4. [1] SID에 대한 상태 SOK와 상태 P(rimary) 또는 S(econdary)를 사용하는 복제 사이트를 둘 다 보여 주는 HANA HA 후크와 클러스터 간의 통신을 확인합니다.

    sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

    참고 항목

    위의 구성에서 시간 제한은 단지 예제이며 특정 HANA 설정에 맞게 조정해야 할 수 있습니다. 예를 들어 SAP HANA 데이터베이스를 시작하는 데 시간이 더 오래 걸리는 경우 시작 시간 제한을 늘려야 할 수 있습니다.

SAP HANA 장애 조치 테스트

참고 항목

이 문서에는 Microsoft가 더 이상 사용하지 않는 용어에 대한 참조가 포함되어 있습니다. 이러한 용어가 소프트웨어에서 제거되면 이 문서에서도 제거할 것입니다.

  1. 테스트를 시작하기 전에 클러스터와 SAP HANA 시스템 복제 상태를 확인합니다.

    a. 실패한 클러스터 작업이 없는지 확인합니다.

    #Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

    b. SAP HANA 시스템 복제가 동기화되었는지 확인

    # Verify HANA HSR is in sync
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
#| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
#|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

  2. SLES에서 Azure VM의 SAP HANA용 HA와 SLES 복제 스케일 아웃 성능 최적화 시나리오에 나오는 테스트를 실시하여 SAP HANA 클러스터 구성을 철저하게 검증할 것을 권장합니다.

  3. 노드가 NFS 공유(/hana/shared)에 대한 액세스 권한을 상실하면 장애 시나리오에 대한 클러스터 구성을 확인합니다.

    SAP HANA 리소스 에이전트는 /hana/shared에 저장된 이진 파일에 의존하여 장애 조치(failover)동안 작업을 수행합니다. 파일 시스템 /hana/shared은 제시된 구성에서 NFS를 통해 탑재됩니다. 수행할 수 있는 테스트는 주 사이트 VM 중 하나에서 /hana/shared NFS가 탑재된 파일 시스템에 대한 액세스를 차단하는 임시 방화벽 규칙을 만드는 것입니다. 이 방식은 활성 시스템 복제 사이트에서 /hana/shared에 대한 액세스 권한을 상실할 때 클러스터 장애 조치(failover)가 이루어지는지 확인합니다.

    예상 결과: 기본 사이트 VM 중 하나에서 /hana/shared NFS가 탑재된 파일 시스템에 대한 액세스를 차단하면 파일 시스템에서 읽기/쓰기를 수행하는 모니터링 작업에 실패합니다. 이는 파일 시스템에 액세스하지 못해 HANA 리소스 장애조치를 트리거하기 때문입니다. HANA 노드가 NFS 공유에 액세스할 수 없는 경우에도 동일한 결과가 예상됩니다.

    crm_mon 또는 crm status를 실행하여 클러스터 리소스 상태를 확인할 수 있습니다. 테스트 시작 전 리소스 상태:

    # Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

    /hana/shared에 대한 실패를 시뮬레이션하려면:

    • Azure NetApp Files에서 NFS를 사용하는 경우 먼저 주 사이트에서 /hana/shared Azure NetApp Files 볼륨의 IP 주소를 확인합니다. df -kh|grep /hana/shared를 실행하여 확인할 수 있습니다.
    • Azure Files의 NFS를 사용하는 경우 먼저 스토리지 계정에 대한 프라이빗 엔드포인트의 IP 주소를 확인합니다.

    그런 다음 기본 HANA 시스템 복제 사이트 VM 중 하나에서 다음 명령을 실행하여 /hana/shared NFS 파일 시스템의 IP 주소에 대한 액세스를 차단하는 임시 방화벽 규칙을 설정합니다.

    이 예에서는 Azure NetApp Files 볼륨 /hana/shared에 대한 hana-s1-db1에서 명령이 실행되었습니다.

    iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP

    클러스터 리소스가 다른 HANA 시스템 복제 사이트로 마이그레이션됩니다.

    AUTOMATED_REGISTER = "false"를 설정하는 경우 보조 사이트에 SAP HANA 시스템 복제를 구성해야 합니다. 이 경우 다음 명령을 실행하여 SAP HANA를 보조로 다시 구성할 수 있습니다.

    # Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03

    테스트 후의 리소스 상태는 다음과 같습니다.

    # Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

다음 단계