이 섹션은 다음에 적용됩니다.
Windows 및
Linux
WSFC(Windows Server 장애 조치(failover) 클러스터링) 또는 Linux의 Pacemaker(현재 SUSE Linux Enterprise Server [SLES] 12 이상에서만 지원됨)와 같은 기능을 사용하지 않기로 결정한 경우 Azure VM 다시 시작이 사용됩니다. Azure 물리적 서버 인프라 및 전반적인 기본 Azure 플랫폼의 계획되거나 계획되지 않은 가동 중지 시간으로부터 SAP 시스템을 보호합니다.
비고
Azure VM 다시 시작은 주로 애플리케이션이 아닌 VM을 보호합니다. VM 다시 시작은 SAP 애플리케이션에 고가용성을 제공하지는 않지만 특정 수준의 인프라 가용성을 제공합니다. 또한 간접적으로 SAP 시스템의 "고가용성"을 제공합니다. 계획되거나 계획되지 않은 호스트 중단 후 VM을 다시 시작하는 데 걸리는 시간에 대한 SLA도 없으므로 이 고가용성 방법은 SAP 시스템의 중요한 구성 요소에 적합하지 않습니다. 중요한 구성 요소의 예는 ASCS/SCS 인스턴스 또는 DBMS(데이터베이스 관리 시스템)일 수 있습니다.
고가용성을 위한 또 다른 중요한 인프라 요소는 스토리지입니다. 예를 들어 Azure Storage SLA는 99.9% 가용성입니다. 모든 VM 및 해당 디스크를 단일 Azure Storage 계정에 배포하는 경우 잠재적인 Azure Storage를 사용할 수 없으면 해당 스토리지 계정에 배치된 모든 VM 및 VM 내에서 실행되는 모든 SAP 구성 요소를 사용할 수 없게 됩니다.
모든 VM을 단일 Azure Storage 계정에 배치하는 대신 각 VM에 전용 스토리지 계정을 사용할 수 있습니다. 여러 독립 Azure Storage 계정을 사용하면 전체 VM 및 SAP 애플리케이션 가용성을 높일 수 있습니다.
Azure 관리 디스크는 연결된 가상 머신의 장애 도메인에 자동으로 배치됩니다. 가용성 집합에 두 개의 가상 머신을 배치하고 관리 디스크를 사용하는 경우 플랫폼은 관리 디스크를 다른 장애 도메인에 배포하는 작업을 수행합니다. Premium Storage 계정을 사용하려는 경우 관리 디스크를 사용하는 것이 좋습니다.
Azure 인프라 고가용성 및 스토리지 계정을 사용하는 SAP NetWeaver 시스템의 샘플 아키텍처는 다음과 같습니다.
Azure 인프라 고가용성 및 관리 디스크를 사용하는 SAP NetWeaver 시스템의 샘플 아키텍처는 다음과 같습니다.
중요한 SAP 구성 요소의 경우 지금까지 다음을 달성했습니다.
SAP 애플리케이션 서버의 고가용성
SAP 애플리케이션 서버 인스턴스는 중복 구성 요소입니다. 각 SAP 애플리케이션 서버 인스턴스는 다른 Azure 장애 및 업그레이드 도메인에서 실행되는 자체 VM에 배포됩니다. 자세한 내용은 장애 도메인 및업데이트 도메인 섹션을 참조하세요 .
Azure 가용성 집합을 사용하여 이 구성을 보장할 수 있습니다. 자세한 내용은 Azure 가용성 집합 섹션을 참조하세요.
Azure 장애 또는 업그레이드 도메인의 잠재적인 계획 또는 계획되지 않은 사용 불가로 인해 SAP 애플리케이션 서버 인스턴스에서 제한된 수의 VM을 사용할 수 없게 됩니다.
각 SAP 애플리케이션 서버 인스턴스는 자체 Azure Storage 계정에 배치됩니다. 하나의 Azure Storage 계정을 사용할 수 없으면 SAP 애플리케이션 서버 인스턴스가 있는 하나의 VM만 사용할 수 없게 됩니다. 그러나 한 Azure 구독 내의 Azure Storage 계정 수에는 제한이 있습니다. VM을 다시 부팅한 후 ASCS/SCS 인스턴스가 자동으로 시작되도록 하려면 ASCS/SCS 인스턴스 시작 프로필에서 Autostart 매개 변수를 설정합니다.
자세한 내용은 SAP 애플리케이션 서버의 고가용성을 참조하세요.
관리 디스크를 사용하는 경우에도 디스크는 Azure Storage 계정에 저장되며 스토리지 중단 시 사용할 수 없을 수 있습니다.
SAP ASCS/SCS 인스턴스의 고가용성
이 시나리오에서는 Azure VM 다시 시작을 활용하여 설치된 SAP ASCS/SCS 인스턴스를 사용하여 VM을 보호합니다. Azure 서버의 계획되거나 계획되지 않은 가동 중지 시간의 경우 사용 가능한 다른 서버에서 VM이 다시 시작됩니다. 앞에서 언급한 것처럼 Azure VM 다시 시작은 주로 VM을 보호하며, 애플리케이션인 이 경우 ASCS/SCS 인스턴스는 보호하지 않습니다. VM 다시 시작을 통해 SAP ASCS/SCS 인스턴스의 "고가용성"에 간접적으로 도달합니다.
VM을 다시 부팅한 후 ASCS/SCS 인스턴스가 자동으로 시작되도록 하려면 ASCS/SCS 인스턴스 시작 프로필에서 Autostart 매개 변수를 설정합니다. 이 설정은 단일 VM에서 실행되는 단일 SPOF(실패 지점)로 ASCS/SCS 인스턴스가 전체 SAP 환경의 가용성을 결정한다는 것을 의미합니다.
DBMS 서버의 고가용성
이전 SAP ASCS/SCS 인스턴스 사용 사례와 마찬가지로 Azure VM 다시 시작을 활용하여 설치된 DBMS 소프트웨어로 VM을 보호하고 VM 다시 시작을 통해 DBMS 소프트웨어의 "고가용성"을 달성합니다.
단일 VM에서 실행되는 DBMS도 SPOF이며 전체 SAP 환경의 가용성을 결정하는 요소입니다.
SAP 인스턴스에 자동 시작 사용
SAP는 VM 내에서 OS가 시작된 직후 SAP 인스턴스를 시작할 수 있는 설정을 제공합니다. 지침은 SAP 기술 자료 문서 1909114 설명되어 있습니다. 그러나 둘 이상의 VM이 영향을 받거나 VM당 여러 인스턴스가 실행되는 경우 인스턴스 다시 시작 순서를 제어할 수 없으므로 SAP는 더 이상 설정을 사용하지 않는 것이 좋습니다.
VM에서 하나의 SAP 애플리케이션 서버 인스턴스와 단일 VM이 결국 다시 시작되는 일반적인 Azure 시나리오를 가정하면 자동 시작은 중요하지 않습니다. 그러나 다음 매개 변수를 SAP ABAP(Advanced Business Application Programming) 또는 Java 인스턴스의 시작 프로필에 추가하여 사용하도록 설정할 수 있습니다.
Autostart = 1
비고
Autostart 매개 변수에는 특정 단점도 있습니다. 특히 매개 변수는 인스턴스의 관련 Windows 또는 Linux 서비스가 시작될 때 SAP ABAP 또는 Java 인스턴스의 시작을 트리거합니다. 이 시퀀스는 운영 체제가 부팅되면 발생합니다. 그러나 SAP 서비스의 다시 시작은 SUM(소프트웨어 업데이트 관리자) 또는 기타 업데이트 또는 업그레이드와 같은 SAP 소프트웨어 수명 주기 관리 기능에서도 일반적으로 발생합니다. 이러한 기능은 인스턴스가 자동으로 다시 시작될 것으로 예상하지 않습니다. 따라서 이러한 작업을 실행하기 전에 Autostart 매개 변수를 사용하지 않도록 설정해야 합니다. Autostart 매개 변수는 ASCS/SCS/CI와 같이 클러스터된 SAP 인스턴스에도 사용해서는 안 됩니다.
SAP 인스턴스의 자동 시작에 대한 자세한 내용은 다음 문서를 참조하세요.
다음 단계
전체 SAP NetWeaver 애플리케이션 인식 고가용성에 대한 자세한 내용은 Azure IaaS의 SAP 애플리케이션 고가용성을 참조하세요.