Konfigurowanie połączonej wysokiej dostępności i odzyskiwania po awarii
Firma Microsoft nie udostępnia żadnych informacji na temat odległości geograficznych między obiektami hostujących różne Strefy dostępności Azure w regionie świadczenia usługi Azure. Mimo to niektórzy klienci używają stref dla połączonej konfiguracji wysokiej dostępności i odzyskiwania po awarii, która obiecuje cel punktu odzyskiwania (RPO) zera. Oznacza to, że nie należy tracić żadnych zatwierdzonych transakcji bazy danych nawet w przypadku odzyskiwania po awarii.
Firma Microsoft zaleca konfigurację strefy dostępności tylko w określonych okolicznościach. Możesz na przykład użyć go, gdy dane nie mogą opuścić regionu świadczenia usługi Azure ze względów bezpieczeństwa lub zgodności.
Mają zastosowanie następujące kwestie:
Zakładasz, że istnieje znaczna odległość między obiektami obsługującymi strefę dostępności lub musisz pozostać w określonym regionie świadczenia usługi Azure. Nie można wdrożyć zestawów dostępności w usłudze Azure Strefy dostępności. W takim przypadku masz jedną domenę aktualizacji i błędów dla warstwy aplikacji. Dzieje się tak, ponieważ jest on wdrażany tylko w jednej strefie. Ta konfiguracja jest nieco mniej pożądana niż architektura referencyjna, co sugeruje wdrożenie warstwy aplikacji w zestawie dostępności platformy Azure.
W przypadku korzystania z tej architektury należy uważnie monitorować stan i starać się zachować aktywne wystąpienia usług DBMS i SAP Central Services w tej samej strefie co wdrożona warstwa aplikacji. Jeśli istnieje tryb failover usługi SAP Central Service lub wystąpienia systemu DBMS, chcesz upewnić się, że możesz ręcznie powrócić po awarii do strefy przy użyciu warstwy aplikacji SAP wdrożonej tak szybko, jak to możliwe.
Wstępnie zainstalowane wystąpienia aplikacji produkcyjnych powinny znajdować się na maszynach wirtualnych z uruchomionymi aktywnymi wystąpieniami aplikacji QA.
Jeśli wystąpi awaria strefy, zamknij wystąpienia aplikacji QA i zamiast tego uruchom wystąpienia produkcyjne. Aby wykonać tę pracę, należy użyć nazw wirtualnych dla wystąpień aplikacji.
W przypadku modułów równoważenia obciążenia klastrów trybu failover usług SAP Central Services i warstwy DBMS należy użyć modułu równoważenia obciążenia platformy Azure jednostki SKU w warstwie Standardowa. Moduł równoważenia obciążenia w warstwie Podstawowa nie działa w różnych strefach.
Sieć wirtualna platformy Azure wdrożona w celu hostowania systemu SAP wraz z jej podsieciami jest rozciągana między strefami. Nie potrzebujesz oddzielnych sieci wirtualnych dla każdej strefy.
W przypadku wszystkich wdrożonych maszyn wirtualnych należy użyć usługi Azure Dyski zarządzane. Dyski niezarządzane nie są obsługiwane w przypadku wdrożeń strefowych.
Usługa Azure Premium Storage i magazyn SSD w warstwie Ultra nie obsługują żadnego typu replikacji magazynu między strefami. Aplikacja (DBMS lub SAP Central Services) musi replikować ważne dane.
To samo dotyczy udostępnionego katalogu sapmnt, który jest dyskiem udostępnionym (Windows), udziałem CIFS (Windows) lub udziałem NFS (Linux). Należy użyć technologii, która replikuje te dyski udostępnione lub udziały między strefami. Obsługiwane są następujące technologie:
- W przypadku systemu Windows rozwiązanie klastra korzystające z usługi SIOS DataKeeper, zgodnie z dokumentacją w temacie Cluster an SAP ASCS/SCS instance on a Windows failover cluster using a cluster shared disk in Azure ( Klaster ASCS/SCS w klastrze trybu failover systemu Windows przy użyciu udostępnionego dysku klastra na platformie Azure).
- W przypadku systemu SUSE Linux udział NFS utworzony zgodnie z dokumentacją w artykule Wysoka dostępność systemu plików NFS na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server.
Obecnie rozwiązanie korzystające z serwera plików skalowalnego w poziomie firmy Microsoft nie jest obsługiwane w różnych strefach.
Trzecia strefa służy do hostowania urządzenia SBD w przypadku tworzenia klastra pacemaker systemu SUSE Linux lub innych wystąpień aplikacji