단일 Azure 지역 내 SAP HANA 가용성
이 문서에서는 한 Azure 지역 내 SAP HANA의 여러 가용성 시나리오에 대해 설명합니다. Azure에는 전 세계에 걸쳐 많은 지역이 있습니다. Azure 지역 목록은 Azure 지역을 참조하세요. Azure 지역 내의 VM에 SAP HANA를 배포하는 경우 Microsoft는 HANA 인스턴스가 있는 단일 VM의 배포를 제공합니다. 가용성을 높이기 위해 FD=1이 있는 유연한 확장 집합, 가용성 영역 또는 가용성을 위해 HANA 시스템 복제를 사용하는 가용성 집합을 사용하여 두 개의 HANA 인스턴스가 있는 두 개의 VM을 배포할 수 있습니다.
가용성 영역을 제공하는 Azure 지역은 각각 자체 전원, 냉각 및 네트워크 인프라가 있는 여러 데이터 센터로 구성됩니다. 단일 Azure 지역 내 다른 영역을 제공하는 목적은 제공되는 2~3개 가용성 영역에서 애플리케이션을 배포할 수 있도록 하기 위함입니다. 애플리케이션 배포를 영역에 분산하면 특정 Azure 가용성 영역 인프라에 영향을 미치는 전원 또는 네트워킹 문제가 Azure 지역 내에서 애플리케이션의 기능을 완전히 방해하지는 않습니다. 한 영역에서 VM의 잠재적 손실과 같은 일부 감소된 용량이 있을 수 있지만 나머지 영역의 VM은 중단 없이 계속 작동합니다. 서로 다른 영역에 걸쳐 있는 별도의 VM에 두 개의 HANA 인스턴스를 설정하려면 FD=1이 있는 유연한 확장 집합 또는 가용성 영역 배포 옵션을 사용하여 VM을 배포하는 옵션이 있습니다 .
지역 내에서 가용성을 높이려면 가용성 집합을 사용하여 두 개의 HANA 인스턴스가 있는 두 개의 VM을 배포하는것이 좋습니다. Azure 가용성 집합은 가용성 집합 내에 구성된 VM 리소스를 Azure 데이터 센터에 배포할 때 서로 간에 오류가 격리되도록 할 수 있는 논리적 그룹화 기능입니다. Azure는 가용성 집합 내에 배치한 VM을 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치에서 실행되도록 합니다. 일부 Azure 문서에서 이 구성은 다른 업데이트 및 장애 도메인의 배치라고 합니다. 이러한 배치는 일반적으로 Azure 데이터 센터 내에 있습니다. 전원 및 네트워크 문제가 배포하는 데이터 센터에 영향을 미친다고 가정하면, 한 Azure 지역의 모든 용량에 영향을 미칩니다.
Azure 가용성 영역을 나타내는 데이터 센터의 배치는 여러 영역에 배포된 서비스 간 배달 네트워크 대기 시간과 데이터 센터 간 특정 거리 사이의 절충안입니다. 이상적으로 자연 재해는 이 지역의 모든 가용성 영역에 대한 전원, 네트워크 공급 및 인프라에 영향을 주지 않습니다. 그러나 엄청난 자연 재해가 발생하면 가용성 영역이 한 지역 내에서 필요한 가용성을 제공하지 못할 수도 있습니다. 2017년 9월 20일 푸에르토리코 섬에 발생한 Maria 허리케인에 대해 생각해 보세요. 기본적으로 이 허리케인으로 인해 90마일 너비의 섬에서 거의 100%에 이르는 정전이 발생했습니다.
단일 VM 시나리오
단일 VM 시나리오에서는 SAP HANA 인스턴스에 대한 Azure VM을 만듭니다. Azure Premium Storage를 사용하여 운영 체제 및 모든 데이터 디스크를 호스팅합니다. 99.9%의 Azure 가동 시간 SLA와 다른 Azure 구성 요소의 SLA는 고객을 위한 가용성 SLA를 충족시키는 데 충분합니다. 이 시나리오에서는 DBMS 레이어를 실행하는 VM에 대해 Azure 가용성 집합을 활용할 필요가 없습니다. 여기서는 서로 다른 두 가지 기능을 사용합니다.
- Azure VM 자동 다시 시작(Azure 서비스 복구라고도 함)
- SAP HANA 자동 다시 시작
Azure VM 자동 다시 시작 또는 서비스 복구는 다음 두 수준에서 작동하는 Azure 기능입니다.
- Azure 서버 호스트에서 호스팅되는 VM의 상태를 확인합니다.
- Azure 패브릭 컨트롤러에서 서버 호스트의 상태 및 가용성을 모니터링합니다.
상태 검사 기능은 Azure 서버 호스트에서 호스트되는 모든 VM의 상태를 모니터링합니다. VM이 비정상 상태에 놓이게 되면 VM 상태를 확인하는 Azure 호스트 에이전트에서 VM 다시 부팅을 시작할 수 있습니다. 패브릭 컨트롤러는 호스트 하드웨어와 관련된 문제를 나타낼 수 있는 여러 다른 매개 변수를 검사하여 호스트의 상태를 확인합니다. 또한 네트워크를 통해 호스트의 액세스 가능성도 확인합니다. 호스트 관련 문제가 표시되면 다음과 같은 이벤트가 발생할 수 있습니다.
- 호스트에서 잘못된 상태에 대한 신호를 보내는 경우 호스트를 다시 부팅하고 호스트에서 실행 중이었던 VM을 다시 시작합니다.
- 성공적으로 다시 부팅한 후 호스트가 정상 상태가 아니면 원래 비정상 노드에 있던 VM을 정상 호스트 서버에 다시 배포하는 작업이 시작됩니다. 이 경우 원래 호스트가 비정상으로 표시됩니다. 이 호스트는 삭제하거나 대체할 때까지 추가 배포에 사용되지 않습니다.
- 다시 부팅하는 동안 비정상 호스트에 문제가 발생하면 정상 호스트에서 VM 재시작이 즉시 트리거됩니다.
Azure에서 제공하는 호스트 및 VM 모니터링을 사용하면 정상 Azure 호스트에서 호스트 문제가 발생한 Azure VM을 자동으로 다시 시작합니다.
Important
Azure 서비스 복구 과정에서 게스트 OS의 커널이 비상 상태인 Linux VM은 다시 시작되지 않습니다. 일반적으로 사용되는 Linux 릴리스의 기본 설정은 Linux 커널이 비상 상태인 VM 또는 서버를 자동으로 다시 시작하지 않는 것입니다. 대신 커널 디버거를 연결하여 분석할 수 있도록 OS의 커널 비상 상태를 유지할 것을 예상합니다. Azure는 이러한 동작을 인식하여 게스트 OS가 이러한 상태인 VM을 자동으로 다시 시작하지 않습니다. 이러한 경우가 매우 드물다는 가정입니다. VM 다시 시작을 사용하도록 설정하는 기본 동작을 덮어쓸 수 있습니다. 기본 동작을 변경하려면 /etc/sysctl.conf에 'kernel.panic' 매개 변수를 사용합니다. 이 매개 변수에 설정하는 시간은 초 단위입니다. 일반적인 권장 값은 이 매개 변수를 통해 재부팅을 트리거하기 전에 20~30초 동안 기다리는 것입니다. 자세한 내용은 sysctl.conf를 참조하세요.
이 시나리오에서 사용하는 두 번째 기능은 VM을 다시 부팅한 후 다시 시작한 VM에서 실행되는 HANA 서비스가 자동으로 시작된다는 것입니다. HANA 서비스 자동 다시 시작은 다양한 HANA 서비스의 Watchdog 서비스를 통해 설정할 수 있습니다.
이 단일 VM 시나리오는 SAP HANA 구성에 콜드 장애 조치 노드를 추가하여 향상시킬 수 있습니다. SAP HANA 설명서에서 이 설정은 호스트 자동 장애 조치라고 합니다. 이 구성은 서버 하드웨어가 제한되어 있고 프로덕션 호스트 집합에 대한 단일 서버 노드를 호스트 자동 장애 조치 노드로 전용하는 온-프레미스 배포 상황에서 의미가 있습니다. 그러나 Azure의 기본 인프라에서 성공적인 VM 다시 시작을 위해 정상 대상 서버를 제공하는 Azure에서는 SAP HANA 호스트 자동 장애 조치를 배포할 필요가 없습니다. Azure 서비스 복구로 인해 HANA 호스트 자동 장애 조치를 위한 대기 노드를 예상하는 참조 아키텍처가 없습니다.
Azure SAP HANA 스케일 아웃 구성의 특별 사례
대기 노드 또는 HANA 시스템 복제를 기반으로 하는 고가용성 아키텍처는 다음 문서에서 찾을 수 있습니다. SAP HANA 스케일 아웃 구성에서 대기 노드 또는 HANA 시스템 복제 고가용성이 사용되지 않는 경우 VM이 다시 작동하면 Azure VM의 서비스 복구 기능 및 SAP HANA 인스턴스의 자동 다시 시작을 사용할 수 있습니다.
- RedHat Enterprise Linux
- SUSE Linux Enterprise Server
두 개의 서로 다른 VM에 대한 가용성 시나리오
특정 지역 내에서 HANA 시스템의 가용성을 보장하기 위해 지역 또는 지역 내의 가용성 영역에서 두 개의 VM을 구성하는 옵션이 있습니다. 이 목표를 달성하기 위해 유연한 확장 집합, 가용성 영역 또는 가용성 집합 배포 옵션을 사용하여 VM을 구성할 수 있습니다. Azure의 기본 설정은 다음과 같습니다.
다양한 SAP HANA 가용성 시나리오를 설명하기 위해 다이어그램의 일부 레이어가 생략되었습니다. 다이어그램에는 VM, 호스트, 가용성 집합 및 Azure 지역을 나타내는 계층만 표시됩니다. Azure Virtual Network 인스턴스, 리소스 그룹 및 구독은 이 섹션에서 설명하는 시나리오에서 역할을 수행하지 않습니다.
두 번째 가상 머신에 백업 복제
가장 기본적인 설정 중 하나는 백업을 사용하는 것입니다. 특히 한 VM에서 다른 Azure VM으로 트랜잭션 로그 백업을 제공해야 할 수도 있습니다. Azure Storage 유형을 선택할 수 있습니다. 이 설정에서는 첫 번째 VM에서 수행된 예약된 백업 복사본을 두 번째 VM에 스크립팅해야 합니다. 두 번째 VM의 인스턴스를 사용해야 하는 경우 전체, 증분/차등 및 트랜잭션 로그 백업을 필요한 시점으로 복원해야 합니다.
아키텍처는 다음과 같습니다.
이 설정은 중요한 RPO(복구 지점 목표) 및 RTO(복구 시간 목표) 시간을 달성하는 데 적합하지 않습니다. 특히 RTO 시간은 복사된 백업을 사용하여 전체 데이터베이스를 완전히 복원해야 하므로 어려움을 겪습니다. 그러나 이 설정은 주 인스턴스에서 의도하지 않은 데이터 삭제를 복구하는 데 유용합니다. 이 설정을 사용하면 언제든지 특정 시점으로 복원하고, 데이터를 추출하며, 삭제된 데이터를 주 인스턴스로 가져올 수 있습니다. 따라서 다른 고가용성 기능과 함께 백업 복사본 방법을 사용해야 합니다.
백업이 복사되는 동안 SAP HANA 인스턴스가 실행되는 주 VM보다 더 작은 VM을 사용할 수 있습니다. 적은 수의 VHD를 더 작은 VM에 연결할 수 있다는 점에 유의해야 합니다. 개별 VM 유형의 제한에 대한 자세한 내용은 Azure에서 Linux 가상 머신에 대한 크기를 참조하세요.
자동 장애 조치가 없는 SAP HANA 시스템 복제
이 섹션에서 설명하는 시나리오에서는 SAP HANA 시스템 복제를 사용합니다. SAP 설명서는 시스템 복제를 참조하세요. 자동 장애 조치(failover)가 없는 시나리오는 하나의 Azure 지역 내 구성에 일반적이지 않습니다. 자동 장애 조치가 없는 구성은 Pacemaker 설치가 필요 없지만 수동으로 모니터링하고 장애 조치해야 합니다. 이 작업에도 노력이 필요하므로 대부분의 고객은 이 구성 대신 Azure 서비스 복구를 사용합니다. 이 구성이 오류 시나리오와 관련하여 도움이 될 수 있는 몇 가지 중요한 경우가 있습니다. 또는 경우에 따라 고객이 더 많은 효율성을 실현할 수도 있습니다.
자동 장애 조치 및 데이터 미리 로드가 없는 SAP HANA 시스템 복제
이 시나리오에서는 SAP HANA 시스템 복제를 사용하여 RPO가 0이 되도록 데이터를 동기 방식으로 이동합니다. 반면에, HANA 인스턴스 캐시에 장애 조치 또는 데이터 미리 로드가 필요하지 않을 정도로 충분히 긴 RTO가 있습니다. 이 경우 다음 작업을 수행하여 구성에서 경제적 효과를 추가로 달성할 수 있습니다.
- 두 번째 VM에서 다른 SAP HANA 인스턴스를 실행합니다. 두 번째 VM의 SAP HANA 인스턴스에서 가상 머신 메모리의 대부분을 사용합니다. 두 번째 VM으로 장애 조치하는 경우, 복제된 데이터가 두 번째 VM의 대상 HANA 인스턴스 캐시로 로드될 수 있도록 실행 중인 SAP HANA 인스턴스(데이터가 두 번째 VM에 완전히 로드됨)를 종료해야 합니다.
- 두 번째 VM에서 더 작은 VM 크기를 사용합니다. 장애 조치가 발생하면 수동 장애 조치 전에 추가 단계를 수행해야 합니다. 이 단계에서는 VM을 원본 VM의 크기로 조정합니다.
시나리오는 다음과 같습니다.
참고 항목
HANA 시스템 복제 대상에서 데이터 미리 로드를 사용하지 않는 경우에도 64GB 이상의 메모리가 필요합니다. 또한 64GB 외에도, rowstore 데이터를 대상 인스턴스의 메모리에 유지하기 위해 충분한 메모리가 필요합니다.
자동 장애 조치는 없지만 데이터 미리 로드가 있는 SAP HANA 시스템 복제
이 시나리오에서는 두 번째 VM의 HANA 인스턴스에 복제된 데이터가 미리 로드됩니다. 이렇게 하면 데이터를 미리 로드하지 않는 두 가지 장점이 없어집니다. 이 경우 두 번째 VM에서 다른 SAP HANA 시스템을 실행할 수 없습니다. 또한 더 작은 VM 크기를 사용할 수 없습니다. 따라서 고객은 이 시나리오를 거의 구현하지 않습니다.
자동 장애 조치가 있는 SAP HANA 시스템 복제
하나의 Azure 지역 내의 표준 및 가장 일반적인 가용성 구성에서 HA 패키지와 함께 Linux를 실행하는 두 개의 Azure VM에는 장애 조치(failover) 클러스터가 정의되어 있습니다. HA Linux 클러스터는 예로 fencing device SLES 또는 RHEL과 함께 SLES 또는 RHEL을 사용하는 Pacemaker 프레임워크를 기반으로 합니다.
SAP HANA 측면에서 볼 때, 사용되는 복제 모드가 동기화되고 자동 장애 조치가 구성됩니다. 두 번째 VM에서 SAP HANA 인스턴스는 핫 대기 노드로 작동합니다. 대기 노드는 주 SAP HANA 인스턴스에서 변경 레코드의 동기 스트림을 받습니다. 트랜잭션이 HANA 주 노드에서 애플리케이션을 통해 커밋되면, 보조 SAP HANA 노드에서 커밋된 레코드를 받았음을 확인할 때까지 주 HANA 노드는 애플리케이션에 대한 커밋 확인을 기다립니다. SAP HANA는 두 개의 동기 복제 모드를 제공합니다. 이러한 두 동기 복제 모드에 대한 자세한 내용 및 차이점에 대한 설명은 SAP HANA 시스템 복제에 대한 복제 모드 문서를 읽어보세요.
전체 구성은 다음과 같습니다.
이 솔루션은 RPO=0 및 낮은 RTO를 달성할 수 있기 때문에 선택할 수 있습니다. SAP HANA 클라이언트에서 가상 IP 주소를 사용하여 HANA 시스템 복제 구성에 연결하도록 SAP HANA 클라이언트 연결을 구성합니다. 이러한 구성은 보조 노드에 장애 조치하는 경우 애플리케이션을 다시 구성할 필요가 없습니다. 이 시나리오에서는 주 VM 또는 보조 VM에 대한 Azure VM SKU가 동일해야 합니다.
다음 단계
Azure에서 이러한 설정을 구성하는 단계별 지침은 다음을 참조하세요.
Azure 지역 간 SAP HANA 가용성에 대한 자세한 내용은 다음을 참조하세요.