Korzystanie z ponownego uruchamiania maszyny wirtualnej infrastruktury platformy Azure w celu osiągnięcia "wyższej dostępności" systemu SAP

Ta sekcja dotyczy:

Windows i Linux

Jeśli zdecydujesz się nie używać funkcji, takich jak klaster trybu failover systemu Windows Server (WSFC) lub Pacemaker w systemie Linux (obecnie obsługiwane tylko w przypadku systemu SUSE Linux Enterprise Server [SLES] 12 i nowszych), ponowne uruchomienie maszyny wirtualnej platformy Azure jest używane. Chroni systemy SAP przed zaplanowanym i nieplanowanym przestojem infrastruktury serwera fizycznego platformy Azure i ogólnej podstawowej platformy Azure.

Uwaga

Ponowne uruchomienie maszyny wirtualnej platformy Azure chroni przede wszystkim maszyny wirtualne, a nie aplikacje. Mimo że ponowne uruchomienie maszyny wirtualnej nie oferuje wysokiej dostępności dla aplikacji SAP, oferuje określony poziom dostępności infrastruktury. Pośrednio oferuje również "wyższą dostępność" systemów SAP. Nie ma również umowy SLA na czas potrzebny do ponownego uruchomienia maszyny wirtualnej po planowanej lub nieplanowanej awarii hosta, co sprawia, że ta metoda wysokiej dostępności jest nieodpowiednia dla krytycznych składników systemu SAP. Przykłady krytycznych składników mogą być wystąpieniem USŁUGI ASCS/SCS lub systemem zarządzania bazami danych (DBMS).

Innym ważnym elementem infrastruktury na potrzeby wysokiej dostępności jest magazyn. Na przykład umowa SLA usługi Azure Storage wynosi 99,9% dostępności. Jeśli wdrożysz wszystkie maszyny wirtualne i ich dyski na jednym koncie usługi Azure Storage, potencjalna niedostępność usługi Azure Storage spowoduje niedostępność wszystkich maszyn wirtualnych umieszczonych na tym koncie magazynu i wszystkich składnikach SAP uruchomionych wewnątrz maszyn wirtualnych.

Zamiast umieszczać wszystkie maszyny wirtualne na jednym koncie usługi Azure Storage, możesz użyć dedykowanych kont magazynu dla każdej maszyny wirtualnej. Korzystając z wielu niezależnych kont magazynu platformy Azure, zwiększasz ogólną dostępność maszyn wirtualnych i aplikacji SAP.

Dyski zarządzane platformy Azure są automatycznie umieszczane w domenie błędów maszyny wirtualnej, do której są dołączone. Jeśli umieścisz dwie maszyny wirtualne w zestawie dostępności i użyjesz dysków zarządzanych, platforma zajmie się również dystrybucją dysków zarządzanych w różnych domenach błędów. Jeśli planujesz używać konta magazynu w warstwie Premium, zdecydowanie zalecamy używanie dysków zarządzanych.

Przykładowa architektura systemu SAP NetWeaver korzystająca z infrastruktury platformy Azure o wysokiej dostępności i kontach magazynu może wyglądać następująco:

Przykładowa architektura systemu SAP NetWeaver korzystającego z wysokiej dostępności infrastruktury platformy Azure i dysków zarządzanych może wyglądać następująco:

W przypadku krytycznych składników SAP wykonaliśmy następujące czynności:

• Wysoka dostępność serwerów aplikacji SAP

  Wystąpienia serwera aplikacji SAP są nadmiarowymi składnikami. Każde wystąpienie serwera aplikacji SAP jest wdrażane na własnej maszynie wirtualnej, która działa w innej domenie błędów i uaktualniania platformy Azure. Aby uzyskać więcej informacji, zobacz sekcje Domeny błędów i Domeny aktualizacji .

  Tę konfigurację można zapewnić przy użyciu zestawów dostępności platformy Azure. Aby uzyskać więcej informacji, zobacz sekcję Zestawy dostępności platformy Azure.

  Potencjalna planowana lub nieplanowana niedostępność błędu platformy Azure lub domeny uaktualnienia spowoduje niedostępność ograniczonej liczby maszyn wirtualnych z wystąpieniami serwera aplikacji SAP.

  Każde wystąpienie serwera aplikacji SAP jest umieszczane na własnym koncie usługi Azure Storage. Potencjalna niedostępność jednego konta usługi Azure Storage spowoduje niedostępność tylko jednej maszyny wirtualnej z wystąpieniem serwera aplikacji SAP. Należy jednak pamiętać, że istnieje limit liczby kont usługi Azure Storage w ramach jednej subskrypcji platformy Azure. Aby zapewnić automatyczne uruchamianie wystąpienia usługi ASCS/SCS po ponownym uruchomieniu maszyny wirtualnej, ustaw parametr Autostart w profilu uruchamiania wystąpienia usługi ASCS/SCS.

  Aby uzyskać więcej informacji, zobacz Wysoka dostępność serwerów aplikacji SAP.

  Nawet jeśli używasz dysków zarządzanych, dyski są przechowywane na koncie usługi Azure Storage i mogą być niedostępne w przypadku awarii magazynu.

• Wyższa dostępność wystąpień SAP ASCS/SCS

  W tym scenariuszu użyj ponownego uruchomienia maszyny wirtualnej platformy Azure, aby chronić maszynę wirtualną przy użyciu zainstalowanego wystąpienia sap ASCS/SCS. W przypadku planowanych lub nieplanowanych przestojów serwerów platformy Azure maszyny wirtualne są ponownie uruchamiane na innym dostępnym serwerze. Jak wspomniano wcześniej, ponowne uruchomienie maszyny wirtualnej platformy Azure chroni przede wszystkim maszyny wirtualne, a nie aplikacje, w tym przypadku wystąpienie usługi ASCS/SCS. Po ponownym uruchomieniu maszyny wirtualnej pośrednio osiągniesz "wyższą dostępność" wystąpienia sap ASCS/SCS.

  Aby zapewnić automatyczne uruchamianie wystąpienia usługi ASCS/SCS po ponownym uruchomieniu maszyny wirtualnej, ustaw parametr Autostart w profilu uruchamiania wystąpienia usługi ASCS/SCS. To ustawienie oznacza, że wystąpienie usługi ASCS/SCS jako pojedynczy punkt awarii (SPOF) uruchomiony na jednej maszynie wirtualnej określi dostępność całego środowiska SAP.

• Wyższa dostępność serwera DBMS

  Podobnie jak w poprzednim przypadku użycia wystąpienia SAP ASCS/SCS, należy użyć ponownego uruchomienia maszyny wirtualnej platformy Azure, aby chronić maszynę wirtualną za pomocą zainstalowanego oprogramowania DBMS i uzyskać "wyższą dostępność" oprogramowania DBMS za pomocą ponownego uruchomienia maszyny wirtualnej.

  System DBMS działający na jednej maszynie wirtualnej jest również elementem SPOF i jest czynnikiem determinacyjnym dla dostępności całego środowiska SAP.

Korzystanie z narzędzia Autostart dla wystąpień SAP

Oprogramowanie SAP oferuje ustawienie, które umożliwia uruchamianie wystąpień SAP natychmiast po uruchomieniu systemu operacyjnego na maszynie wirtualnej. Instrukcje są udokumentowane w 1909114 artykułu bazy wiedzy SAP Knowledge Base. Jednak system SAP nie zaleca już używania tego ustawienia, ponieważ nie zezwala na kontrolę kolejności ponownego uruchamiania wystąpień, jeśli dotyczy to więcej niż jednej maszyny wirtualnej lub jeśli na maszynę wirtualną jest uruchomionych wiele wystąpień.

Przy założeniu, że typowy scenariusz platformy Azure jednego wystąpienia serwera aplikacji SAP na maszynie wirtualnej i pojedyncza maszyna wirtualna zostanie ostatecznie uruchomiona ponownie, autostart nie ma krytycznego znaczeniu. Można go jednak włączyć, dodając następujący parametr do profilu początkowego wystąpienia SAP Advanced Business Application Programming (ABAP) lub Java:

Autostart = 1

Uwaga

Parametr Autostart ma również pewne braki. W szczególności parametr wyzwala początek wystąpienia SAP ABAP lub Java po uruchomieniu powiązanej usługi systemu Windows lub Linux wystąpienia. Ta sekwencja występuje po uruchomieniu systemu operacyjnego. Jednak ponowne uruchomienia usług SAP są również typowym wystąpieniem funkcji zarządzania cyklem życia oprogramowania SAP, takich jak Software Update Manger (SUM) lub inne aktualizacje lub uaktualnienia. Te funkcje nie oczekują automatycznego ponownego uruchomienia wystąpienia. W związku z tym parametr Autostart powinien być wyłączony przed uruchomieniem takich zadań. Parametr Autostart nie powinien być również używany dla wystąpień sap, które są klastrowane, takich jak ASCS/SCS/CI.

Aby uzyskać więcej informacji na temat automatycznego startu dla wystąpień sap, zobacz następujące artykuły:

• Uruchamianie lub zatrzymywanie oprogramowania SAP wraz z uruchamianiem/zatrzymywaniem serwera Unix
• Uruchamianie i zatrzymywanie agentów zarządzania oprogramowania SAP NetWeaver

Następne kroki

Aby uzyskać informacje o wysokiej dostępności z obsługą aplikacji sap NetWeaver, zobacz Wysoka dostępność aplikacji SAP w usłudze Azure IaaS.