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 스케일 아웃 설치에 대한 HANA 고가용성을 달성하는 한 가지 방법은 HANA 시스템 복제본(replica)tion을 구성하고 자동 장애 조치(failover)를 허용하도록 Pacemaker 클러스터를 사용하여 솔루션을 보호하는 것입니다. 활성 노드에 오류가 발생하면 클러스터는 HANA 리소스를 다른 사이트로 장애 조치(failover)합니다.
제시된 구성은 각 사이트에 세 개의 HANA 노드와 분할 브레인 시나리오를 방지하기 위한 대다수 작성자 노드를 보여 줍니다. 더 많은 VM을 HANA DB 노드로 포함하도록 지침을 조정할 수 있습니다.

제시된 아키텍처의 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 파일 시스템을 배포하는 경우 SAP HANA용 Azure NetApp Files 애플리케이션 볼륨 그룹을 평가하고 사용하는 것이 좋습니다.

Warning

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

SAP HANA scale-out with HSR and Pacemaker cluster on SLES

앞의 다이어그램에서는 SAP HANA 네트워크 권장 사항에 따라 3개의 서브넷이 하나의 Azure 가상 네트워크 내에 표시됩니다.

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

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

Azure NetApp Files를 사용하는 경우 NFS 볼륨 /hana/shared은 별도의 서브넷 에 배포되고 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 복제본(replica)tion 사이트 2의 HANA DB 노드로 사용할 가상 머신 3개: hana-s2-db1, hana-s2-db2 및 hana-s2-db3
    • 대다수 작성자로 사용할 작은 가상 머신: hana-s-mm

    SAP DB HANA 노드로 배포된 VM은 SAP HANA 하드웨어 디렉터리에 게시된 HANA용 SAP에서 인증해야 합니다. 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 플랫폼 사이트로 이동하세요. 나열된 VM 유형의 세부 정보를 클릭하여 해당 형식에 대한 SAP HANA 지원 OS 릴리스의 전체 목록을 가져옵니다.
    • Azure Files의 NFS에 배포 /hana/shared 하도록 선택하는 경우 SLES 15 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. 네트워킹을 선택하고 네트워크 인터페이스를 연결합니다. 네트워크 인터페이스 연결 드롭다운 목록에서 이미 만든 네트워크 인터페이스와 hsr 서브넷을 inter 선택합니다.
    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. 다음 명령을 실행하여 서브넷 및 hsr 서브넷에 연결된 추가 네트워크 인터페이스에 대해 가속화된 네트워킹을 inter 사용하도록 설정합니다.

      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 데이터베이스의 고가용성 설정을 위해 표준 Load Balancer를 설정하려면 아래 단계를 따릅니다.

참고 항목

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

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

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

참고 항목

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

Important

부동 IP는 부하 분산 시나리오의 NIC 보조 IP 구성에서 지원되지 않습니다. 자세한 내용은 Azure Load Balancer 제한 사항을 참조하세요. VM에 대한 추가 IP 주소가 필요한 경우 두 번째 NIC를 배포합니다.

참고 항목

공용 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 파일은 NFSv4.1 프로토콜을 지원하며, Azure NetApp 파일의 NFS는 NFSv4.1 및 NFSv3을 모두 지원합니다.

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

팁

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

Azure NetApp Files 인프라 배포

/hana/shared 파일 시스템에 대한 ANF 볼륨을 배포합니다. 각 HANA 시스템 복제본(replica) 사이트에 대해 별도의 /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 시스템 복제본(replica) 사이트에 대해 별도의 /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] Azure용 Microsoft 구성 설정을 사용하여 구성 파일 /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] NFS를 사용하여 NetApp Systems에서 SAP HANA를 실행하기 위한 OS를 준비합니다. SAP 참고 3024346 - NetApp NFS용 Linux 커널 설정 설명합니다. 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처럼 do기본 구성되었는지기본 defaultv4iddomain.com 매핑이 아무도로 설정되지 않았는지 확인합니다.
    이 단계는 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 가상 머신에 두 개의 볼륨을 만드는 데 사용되는 세 개의 데이터 디스크가 연결되어 있다고 가정합니다.

  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 클러스터 만들기

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

Important

두 노드 클러스터가 아니으므로 2로 설정 quorum expected-votes 하지 마세요.
노드 펜싱이 역직렬화되도록 클러스터 속성 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. HANA 설치 소프트웨어 디렉터리에서와 같이 root hdblcm 프로그램을 시작합니다. 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) 암호 확인: 암호 입력
    • System 관리istrator(hn1adm) 암호의 경우: 암호를 입력합니다.
    • System 관리istrator Home Directory [/usr/sap/HN1/home]의 경우: Enter 키를 눌러 기본값을 적용합니다.
    • System 관리istrator Login Shell [/bin/sh]의 경우 Enter 키를 눌러 기본값을 적용합니다.
    • System 관리istrator 사용자 ID [1001]의 경우: Enter 키를 눌러 기본값을 적용합니다.
    • 사용자 그룹의 ID 입력(sapsys)[79]: Enter 키를 눌러 기본값을 적용합니다.
    • 시스템 데이터베이스 사용자(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 note 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'에 대한 호스트 장애 조치 그룹 입력[기본값]: 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 키를 눌러 기본값 적용
    • System 관리istrator(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] 복제본(replica)tion 상태 확인

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

    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 시스템 복제본(replica)tion에 대한 호스트 매핑을 추가합니다. 서브넷의 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 시스템 복제본(replica)용 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)가 가능한 경우 클러스터와의 통합 및 검색을 최적화하는 것입니다. SAPHanaSrMultiTarget Python 후크를 구성하는 것이 좋습니다. HANA 2.0 SP5 이상의 경우 SAPHanaSrMultiTarget 및 susChkSrv 후크를 모두 구현하는 것이 좋습니다.

참고 항목

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

SAPHanaSrMultiTarget 후크에 대한 제공된 단계는 새 설치를 위한 것입니다. 기존 환경을 SAPHanaSR에서 SAPHanaSrMultiTarget 공급자로 업그레이드하려면 몇 가지 변경이 필요하며 이 문서에서는 설명하지 않습니다 . 기존 환경에서 재해 복구에 세 번째 사이트를 사용하지 않고 HANA 다중 대상 시스템 복제본(replica)tion을 사용하지 않는 경우 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] 두 시스템 복제본(replica) 사이트에서 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) 테스트가 성공적으로 완료되면 인수 시스템 복제본(replica)tion이 자동으로 다시 시작될 수 있도록 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] HANA HA 후크와 클러스터 간의 통신을 확인하여 SID에 대한 상태 SOK와 상태 P(rimary) 또는 S(econdary)를 사용하는 복제본(replica)tion 사이트 모두를 보여 줍니다.

    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 시스템 복제본(replica)tion이 동기화되어 있는지 확인합니다.

    # 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에 대한 실패를 시뮬레이션하려면:

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

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

    이 예제에서는 ANF 볼륨 /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 시스템 복제본(replica)tion을 구성해야 합니다. 이 경우 이러한 명령을 실행하여 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

다음 단계