Sprawdzanie możliwości wysokiej dostępności infrastruktury platformy Azure
Następujące zasady mają zastosowanie do maksymalizacji wysokiej dostępności systemu SAP NetWeaver na platformie Azure:
- Kompletny system jest wdrażany na platformie Azure (wymagana — warstwa DBMS, wystąpienie (A)SCS i pełna warstwa aplikacji musi działać w tej samej lokalizacji).
- Kompletny system działa w ramach jednej subskrypcji platformy Azure (wymagane).
- Kompletny system działa w ramach jednej sieci wirtualnej platformy Azure (wymagane).
- Każda warstwa (na przykład DBMS, ASCS, serwery aplikacji) musi używać dedykowanego zestawu dostępności.
- Wszystkie maszyny wirtualne z uruchomionymi wystąpieniami systemu DBMS jednego systemu SAP znajdują się w jednym zestawie dostępności. Natywne funkcje wysokiej dostępności systemu DBMS, takie jak sql Server Always On lub Oracle Data Guard, umożliwiają uruchamianie więcej niż jednej maszyny wirtualnej hostowania wystąpień DBMS na system.
- Wszystkie maszyny wirtualne używają dysków zarządzanych.
- Pliki danych i dziennika dbMS są replikowane przy użyciu funkcji wysokiej dostępności systemu DBMS, które synchronizują dane.
- (A) Pliki wystąpień scS i folder globalny SAP są przechowywane w udziale plików o wysokiej dostępności lub synchronicznie replikowane między dyskami dwóch maszyn wirtualnych platformy Azure, które są częścią tego samego zestawu dostępności (na przykład przy użyciu usługi SIOS DataKeeper).
Opcje wysokiej dostępności maszyny wirtualnej platformy Azure
Wysoką dostępność maszyn wirtualnych platformy Azure należy wziąć pod uwagę w następujących trzech głównych scenariuszach:
- Pojedyncze maszyny wirtualne platformy Azure (umowa SLA o 99,9% czasu pracy)
- Co najmniej dwie maszyny wirtualne w tym samym zestawie dostępności (umowa SLA na 99,95% czasu pracy)
- Co najmniej dwie maszyny wirtualne w różnych Strefy dostępności w tym samym regionie świadczenia usługi Azure (umowa SLA o 99,99% czasu pracy)
W przypadku wszystkich maszyn wirtualnych, które mają co najmniej dwa wystąpienia wdrożone w tym samym zestawie dostępności, platforma Azure gwarantuje łączność maszyny wirtualnej z co najmniej jednym wystąpieniem co najmniej 99,95% czasu. Gdy co najmniej dwie maszyny wirtualne są częścią tego samego zestawu dostępności, każda maszyna wirtualna w zestawie dostępności ma przypisaną domenę aktualizacji i domenę błędów przez podstawową platformę Azure.
- Domeny aktualizacji gwarantują, że wiele maszyn wirtualnych nie zostanie uruchomionych ponownie w tym samym czasie podczas planowanej konserwacji infrastruktury platformy Azure. Tylko jedna maszyna wirtualna jest uruchamiana ponownie naraz.
- Domeny błędów gwarantują, że maszyny wirtualne są wdrażane na składnikach sprzętowych, które nie współużytkują wspólnego źródła zasilania i przełącznika sieciowego. Gdy serwery, przełącznik sieciowy lub źródło zasilania przechodzą nieplanowany przestój, dotyczy to tylko jednej maszyny wirtualnej.
Zestawy dostępności mogą być używane w następujących scenariuszach w systemach SAP:
- Architektura wysokiej dostępności dla serwerów aplikacji SAP
- Architektura wysokiej dostępności dla wystąpienia sap ASCS/SCS w systemie Windows i Linux
- Wystąpienie systemu DBMS o wysokiej dostępności
Zagadnienia dotyczące konfigurowania zestawu dostępności:
- Każda maszyna wirtualna w zestawie dostępności ma przypisaną domenę aktualizacji i domenę błędów przez podstawową platformę Azure.
- Każdy zestaw dostępności może mieć dwie lub trzy domeny błędów; informacje o tym, kiedy należy używać poszczególnych (dopasuj topologię aplikacji). i 20 domen aktualizacji.
- Jeśli w ramach jednego zestawu dostępności skonfigurowano więcej niż pięć maszyn wirtualnych, szósta maszyna wirtualna zostanie umieszczona w tej samej domenie aktualizacji co pierwsza maszyna wirtualna. Siódma maszyna wirtualna jest umieszczana w tej samej domenie aktualizacji co druga maszyna wirtualna itd.
- Maszyny wirtualne są również dopasowane do domen błędów dysku. To wyrównanie gwarantuje, że wszystkie dyski zarządzane dołączone do maszyny wirtualnej znajdują się w tych samych domenach błędów.
- Poznaj różnicę w umowie SLA między klastrami zestawu dostępności, klastrami zestawu dostępności i Strefy dostępności.
- Pamiętaj, aby zrozumieć interakcję z grupami umieszczania w pobliżu.
Scenariusz z pojedynczą maszyną wirtualną
W scenariuszu z jedną maszyną wirtualną tworzysz maszynę wirtualną platformy Azure dla wdrożenia sap. Usługa Azure Premium Storage służy do hostowania dysku systemu operacyjnego i wszystkich dysków danych. Umowa SLA dotycząca czasu działania platformy Azure w wysokości 99,9% i umowy SLA innych składników platformy Azure są wystarczające, aby spełnić umowy SLA dotyczące dostępności dla klientów. W tym scenariuszu nie trzeba używać zestawu dostępności platformy Azure. Zamiast tego polegasz na dwóch różnych funkcjach:
- Automatyczne ponowne uruchamianie maszyny wirtualnej platformy Azure (nazywane również naprawianiem usługi platformy Azure)
- Automatyczne ponowne uruchamianie systemu SAP
Automatyczne ponowne uruchamianie maszyny wirtualnej platformy Azure lub naprawianie usługi to funkcja platformy Azure, która działa na dwóch poziomach:
- Host serwera sprawdza kondycję maszyn wirtualnych gościa.
- Kontroler sieci szkieletowej platformy Azure monitoruje kondycję i dostępność hosta serwera.
Funkcja sprawdzania kondycji monitoruje kondycję każdej maszyny wirtualnej hostowanej na hoście serwera platformy Azure. Jeśli maszyna wirtualna wpadnie w stan złej kondycji, ponowne uruchomienie maszyny wirtualnej może zostać zainicjowane przez agenta hosta platformy Azure, który sprawdza kondycję maszyny wirtualnej. Kontroler sieci szkieletowej sprawdza kondycję hosta, sprawdzając wiele różnych parametrów, które mogą wskazywać na problemy ze sprzętem hosta. Sprawdza również dostępność hosta za pośrednictwem sieci. Wskazanie problemów z hostem może prowadzić do następujących zdarzeń:
- Jeśli host sygnalizuje nieprawidłowy stan kondycji, zostanie wyzwolony ponowny rozruch hosta i ponowne uruchomienie maszyn wirtualnych, które były uruchomione na hoście.
- Jeśli host nie jest w dobrej kondycji po pomyślnym ponownym uruchomieniu, zainicjowano ponowne wdrożenie maszyn wirtualnych, które pierwotnie znajdowały się w węźle w złej kondycji na serwerze hosta w dobrej kondycji. W takim przypadku oryginalny host jest oznaczony jako nie w dobrej kondycji. Nie jest on używany do dalszych wdrożeń, dopóki nie zostanie wyczyszczone lub zastąpione.
- Jeśli host w złej kondycji ma problemy podczas procesu ponownego uruchamiania, zostanie wyzwolone natychmiastowe ponowne uruchomienie maszyn wirtualnych na hoście w dobrej kondycji.
Dzięki monitorowaniu hostów i maszyn wirtualnych udostępnianych przez platformę Azure maszyny wirtualne platformy Azure, które napotykają problemy z hostem, są automatycznie uruchamiane ponownie na hoście platformy Azure w dobrej kondycji.
Naprawianie usługi platformy Azure nie spowoduje ponownego uruchomienia maszyn wirtualnych z systemem Linux, na których system operacyjny gościa znajduje się w stanie paniki jądra. Zamiast tego platforma Azure utrzymuje system operacyjny w stanie paniki jądra, aby umożliwić dołączanie debugera jądra do analizy. Założenie polega na tym, że takie wystąpienia są rzadkie. Możesz zastąpić domyślne zachowanie, aby włączyć ponowne uruchomienie maszyny wirtualnej. Aby zmienić zachowanie domyślne, włącz parametr "kernel.panic" w pliku /etc/sysctl.conf. Czas ustawiony dla tego parametru wynosi w sekundach. Typowe zalecane wartości to odczekanie 20–30 sekund przed wyzwoleniem ponownego uruchomienia. Aby uzyskać więcej informacji, zobacz https://gitlab.com/procps-ng/procps/blob/master/sysctl.conf.
Platforma SAP HANA umożliwia skonfigurowanie automatycznego ponownego uruchamiania usługi HANA po ponownym uruchomieniu maszyny wirtualnej. Chociaż potencjalnie można skonfigurować zimny węzeł trybu failover (w dokumentacji platformy SAP HANA, ta konfiguracja jest nazywana automatycznym trybem failover hosta), taka konfiguracja ma sens w sytuacji wdrożenia lokalnego, w której sprzęt serwera jest ograniczony i dedykujesz węzeł pojedynczego serwera jako węzeł automatycznego trybu failover hosta dla zestawu hostów produkcyjnych. Jednak na platformie Azure, gdzie podstawowa infrastruktura platformy Azure zapewnia serwer docelowy w dobrej kondycji na potrzeby pomyślnego ponownego uruchomienia maszyny wirtualnej, nie ma sensu wdrażać automatycznego trybu failover hosta SAP HANA. Ze względu na naprawianie usługi platformy Azure nie ma architektury referencyjnej, która przewiduje węzeł rezerwowy dla automatycznego trybu failover hosta HANA.
Automatyczne rozpoczynanie pracy z oprogramowaniem SAP
Program SAP Autostart oferuje funkcje uruchamiania wystąpień SAP natychmiast po uruchomieniu systemu operacyjnego na maszynie wirtualnej. Jednak system SAP nie zaleca już używania tego ustawienia, ponieważ nie zapewnia żadnej kontroli nad kolejnością ponownych uruchomień wystąpień, zakładając, że więcej niż jedna maszyna wirtualna została ponownie uruchomiona. Aby uzyskać więcej informacji, zobacz Korzystanie z ponownego uruchamiania maszyny wirtualnej infrastruktury platformy Azure w celu osiągnięcia "wyższej dostępności" systemu SAP.
Ponadto parametr wyzwala rozpoczęcie wystąpienia SAP ABAP lub Java po uruchomieniu powiązanej usługi systemu Windows/Linux wystąpienia, istnieją scenariusze, w których należy unikać automatycznego ponownego uruchamiania. Na przykład ponowne uruchomienia usług SAP są typowe w przypadku korzystania z funkcji zarządzania cyklem życia oprogramowania SAP, takich jak SUM lub podczas aktualizacji i uaktualnień. W tych scenariuszach ponowne uruchomienia mogą być destrukcyjne. Parametr Autostart również nie powinien być używany dla wystąpień SAP, które są klastrowane.