Eksplorowanie fazy pilotażowej

  • 20 min

Pilotaż może działać równolegle do planowania i przygotowywania projektu. Ta faza może być również używana do testowania opcji zidentyfikowanych w fazie planowania i przygotowania. W ramach pilotażu zaleca się skonfigurowanie i zweryfikowanie pełnego rozwiązania wysokiej dostępności/odzyskiwania po awarii oraz projektu zabezpieczeń. W niektórych przypadkach może być również możliwe użycie tej fazy do przeprowadzania testów skalowalności lub wdrażania systemów piaskownicy SAP. Aby uruchomić pilotaż, klienci powinni rozpocząć od zidentyfikowania niekrytycznego systemu, który chce przeprowadzić migrację na platformę Azure i kontynuować, wykonując następujące zadania:

1. Optymalizowanie transferu danych na platformę Azure

Podejście i wynik są bardzo zależne od łączności klienta z platformą Azure. W zależności od ilości danych może być możliwe użycie w tym celu usługi ExpressRoute, sieci VPN typu lokacja-lokacja lub usług transferu danych offline, takich jak Azure Data Box lub Azure Import/Export Service.

2. Migracja platformy heterogenicznej SAP

W przypadku migracji platformy heterogenicznej SAP, która obejmuje eksportowanie i importowanie danych bazy danych, testowanie i optymalizowanie faz eksportowania i importowania. W przypadku dużych heterogenicznych migracji przeznaczonych dla programu SQL Server zapoznaj się z często zadawanymi pytaniami dotyczącymi migracji systemu SAP OS/DB do programu SQL Server. Możesz użyć monitora migracji/narzędzia SWPM, jeśli nie musisz łączyć migracji z uaktualnieniem wersji lub opcją migracji bazy danych SAP (DMO) w przeciwnym razie. Aby uzyskać szczegółowe informacje, zobacz Opcja migracji bazy danych (DMO) sumy — wprowadzenie. W obu przypadkach wykonaj następujące czynności:

  • Mierzenie czasu eksportowania ze źródła, przekazywania wyeksportowanej zawartości na platformę Azure i wykonywania importu. Maksymalizuj nakładanie się między eksportowaniem i importowaniem.
  • Użyj porównania między źródłowymi i docelowymi bazami danych, aby prawidłowo określać rozmiar infrastruktury docelowej.
  • Weryfikowanie i optymalizowanie chronometrażu.

3. Przeprowadzanie weryfikacji technicznej

Typy maszyn wirtualnych

  • Zapoznaj się z informacjami o obsłudze oprogramowania SAP, katalogem sprzętu sap HANA i macierzą dostępności produktów SAP (PAM), aby zapewnić dokładność informacji dotyczących obsługiwanych jednostek SKU maszyn wirtualnych platformy Azure, obsługiwanych wydań systemu operacyjnego dla tych jednostek SKU maszyn wirtualnych platformy Azure oraz obsługiwanych wydań oprogramowania SAP i DBMS.
  • Weryfikowanie rozmiaru infrastruktury i składników aplikacji wdrażanych na platformie Azure. Podczas migrowania istniejących aplikacji powinno być możliwe uzyskanie niezbędnego systemu SAPS na podstawie istniejącej telemetrii. Pobierz test porównawczy SAP i porównaj go z numerami SAPS wymienionymi w temacie SAP Note #1928533. Ponadto zapoznaj się z informacjami podanymi w ocenach systemu SAPS na maszynach wirtualnych platformy Azure — gdzie szukać i gdzie można się pomylić.
  • Oceń i przetestuj rozmiar maszyn wirtualnych platformy Azure w odniesieniu do maksymalnej przepływności magazynu i przepływności sieci różnych typów maszyn wirtualnych wybranych w fazie planowania. Te dane można znaleźć w temacie Rozmiary maszyn wirtualnych na platformie Azure. Jeśli system operacyjny gościa maszyny wirtualnej platformy Azure to Windows, należy wziąć pod uwagę maksymalną przepływność dysku bez buforowania na potrzeby określania rozmiaru. W przypadku systemu Linux ważne jest również rozważenie maksymalnej przepływności dysku bez buforowania na potrzeby ustalania rozmiaru.

Storage

  • Użyj magazynu SSD w warstwie Standardowa platformy Azure jako minimum dla maszyn wirtualnych reprezentujących warstwy aplikacji SAP oraz w przypadku wdrożenia systemu DBMS bez wydajności i użyj usługi Azure Premium Storage dla wszystkich maszyn wirtualnych DBMS, które są wrażliwe na wydajność.
  • Unikaj używania dysków HDD w warstwie Standardowa platformy Azure.
  • Użyj dysków zarządzanych platformy Azure.
  • Włącz akcelerator zapisu platformy Azure dla dysków dziennika DBMS z maszynami wirtualnymi platformy Azure serii M. Należy pamiętać o udokumentowanych limitach akceleratora zapisu i ograniczeniach użycia.
  • Informacje o magazynie powiązanym z systemem DBMS można znaleźć w artykule Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Zagadnienia dotyczące wdrażania systemu DBMS dla obciążenia SAP) oraz dokumentację specyficzną dla systemu DBMS, do których odwołuje się ten dokument.
  • W przypadku wdrożeń sap HANA zapoznaj się z tematem Konfiguracje i operacje infrastruktury SAP HANA na platformie Azure.
  • Nigdy nie zainstaluj dysków danych platformy Azure na maszynie wirtualnej z systemem Linux platformy Azure przy użyciu identyfikatora urządzenia. Zamiast tego należy użyć identyfikatora uniwersalnego unikatowego (UUID). Podczas instalowania dysku danych platformy Azure przy użyciu narzędzi graficznych należy zachować ostrożność. Sprawdź dokładnie wpisy w pliku /etc/fstab, aby upewnić się, że dyski są zainstalowane przy użyciu identyfikatora UUID. Aby uzyskać więcej informacji, zobacz Połączenie do maszyny wirtualnej z systemem Linux w celu zainstalowania nowego dysku.

Sieć

Przetestuj i oceń infrastrukturę sieci wirtualnej oraz dystrybucję aplikacji SAP w sieciach wirtualnych platformy Azure lub w ramach tych sieci.

  1. Oceń podejście architektury sieci wirtualnej piasty i szprych lub mikrosegmentacji w ramach jednej sieci wirtualnej platformy Azure na podstawie następujących kryteriów:

    • Koszty związane z wymianą danych między równorzędnymi sieciami wirtualnymi platformy Azure (aby uzyskać szczegółowe informacje, zapoznaj się z cennikiem sieci wirtualnej platformy Azure.
    • Porównanie możliwości przerwania komunikacji równorzędnej między sieciami wirtualnymi platformy Azure a użyciem sieciowych grup zabezpieczeń do izolowania podsieci w sieci wirtualnej w przypadkach, gdy aplikacje lub maszyny wirtualne hostowane w podsieci sieci wirtualnej stają się zagrożeniem bezpieczeństwa.
    • Centralne rejestrowanie i inspekcja ruchu sieciowego między środowiskiem lokalnym, Internetem i wirtualnym centrum danych platformy Azure.

  2. Oceń i przetestuj ścieżkę danych między warstwą aplikacji SAP i warstwą SYSTEMU SAP DBMS. W ramach oceny należy wziąć pod uwagę następujące kwestie:

    • Umieszczanie wirtualnych urządzeń sieciowych w ścieżce komunikacyjnej między aplikacją SAP a warstwą DBMS oprogramowania SAP NetWeaver, Hybris lub S/4HANA nie jest obsługiwane.
    • Umieszczanie warstwy aplikacji SAP i systemu SAP DBMS w różnych sieciach wirtualnych platformy Azure, które nie są równorzędne, nie jest obsługiwane.
    • Obsługiwane jest używanie aplikacja systemu Azure grup zabezpieczeń (ASG) i sieciowych grup zabezpieczeń w celu kontrolowania przepływu ruchu między warstwą aplikacji SAP i warstwą systemu SAP DBMS.

  3. Upewnij się, że na maszynach wirtualnych używanych w warstwie aplikacji SAP i warstwie SAP DBMS włączono przyspieszoną sieć platformy Azure. Należy pamiętać o wymaganiach systemu operacyjnego dotyczących obsługi przyspieszonej sieci na platformie Azure:

    • Windows Server 2012 R2 lub nowsze wersje
    • SUSE Linux 12 SP3 lub nowsze wersje
    • Wersje RHEL 7.4 lub nowsze
    • Oracle Linux 7.5. Jądro RHCKL wymaga wydania 3.10.0-862.13.1.el7. Jądro Oracle UEK wymaga wydania 5.

  4. Przetestuj i oceń opóźnienie sieci między maszyną wirtualną warstwy aplikacji SAP i maszyną wirtualną DBMS zgodnie z uwagami sap #500235 i sap Note #1100926. Oceń wyniki pod kątem wskazówek dotyczących opóźnienia sieci w programie SAP Note #1100926. Opóźnienie sieci powinno mieścić się w średnim lub dobrym zakresie.

  5. Upewnij się, że wdrożenia wewnętrznego modułu równoważenia obciążenia platformy Azure (ILB) zostały skonfigurowane do używania funkcji Zwrot serwera bezpośredniego. To ustawienie zmniejszy opóźnienie w przypadkach, w których usługi ILB są używane do konfiguracji wysokiej dostępności w warstwie systemu DBMS.

  6. Jeśli używasz modułu równoważenia obciążenia platformy Azure w połączeniu z systemami operacyjnymi gościa systemu Linux, sprawdź, czy parametr sieciowy systemu Linux net.ipv4.tcp_timestamps jest ustawiony na 0. Należy pamiętać, że jest to sprzeczne z ogólnymi zaleceniami oprogramowania SAP Note #2382421. Uwaga SAP została zaktualizowana, aby odzwierciedlić fakt, że parametr musi być ustawiony na 0, aby działał w połączeniu z modułami równoważenia obciążenia platformy Azure.

Wdrożenia wysokiej dostępności i odzyskiwania po awarii

  • Jeśli wdrożysz warstwę aplikacji SAP bez określania wartości docelowej dla określonej usługi Azure Strefy dostępności, upewnij się, że wszystkie maszyny wirtualne z uruchomionym wystąpieniem okna dialogowego SAP lub wystąpieniami oprogramowania pośredniczącego tego samego systemu SAP są wdrażane w tym samym zestawie dostępności.

    • Jeśli nie potrzebujesz wysokiej dostępności dla usług SAP Central Services i DBMS, te maszyny wirtualne można wdrożyć w tym samym zestawie dostępności co warstwa aplikacji SAP.

  • Jeśli musisz chronić usługi SAP Central Services i warstwę DBMS pod kątem wysokiej dostępności z replikami pasywnymi, wdróż dwa węzły dla usług SAP Central Services w jednym zestawie dostępności i dwa węzły DBMS w innym zestawie dostępności.

  • W przypadku wdrażania w usłudze Azure Strefy dostępności nie można korzystać z zestawów dostępności. Zamiast tego należy upewnić się, że węzły aktywnych i pasywnych usług centralnych są wdrażane w dwóch różnych Strefy dostępności, co zapewnia najmniejsze opóźnienie między strefami.

  • Należy pamiętać, że podczas tworzenia klastrów trybu failover opartych na systemie Windows Server lub Pacemaker dla warstwy DBMS i SAP Central Services w Strefy dostępności należy użyć usługi Azure Standard Load Balancer. Podstawowy moduł równoważenia obciążenia nie obsługuje wdrożeń strefowych.

Ustawienia limitu czasu

  • Sprawdź ślady deweloperów oprogramowania SAP NetWeaver dla wystąpień SAP i upewnij się, że między serwerem kolejki a procesami roboczymi SAP nie ma żadnych przerw w połączeniach. Te przerwy połączeń można uniknąć, ustawiając te dwa parametry rejestru.

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Aby uzyskać szczegółowe informacje, zobacz KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Aby uzyskać szczegółowe informacje, zobacz KeepAliveInterval.

  • Aby uniknąć przekroczenia limitu czasu graficznego interfejsu użytkownika między lokalnymi interfejsami GUI sap i warstwami aplikacji SAP wdrożonych na platformie Azure, ustaw następujące parametry w profilu default.pfl lub profilu wystąpienia:

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Jeśli używasz klastra trybu failover systemu Windows, upewnij się, że parametry określające tryb failover wyzwalany przez węzły nieaktywne są poprawnie ustawione. Artykuł Microsoft TechCommunity Dostrajanie progów sieci klastra trybu failover zawiera listę parametrów i ich wpływ na zachowanie trybu failover. Na przykład przy założeniu, że węzły klastra znajdują się w tej samej podsieci, upewnij się, że parametry trybu failover zostały skonfigurowane w następujący sposób:

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Testowanie procedur wysokiej dostępności i odzyskiwania po awarii:

      • Symuluj tryb failover, zamykając maszyny wirtualne platformy Azure (system operacyjny gościa systemu Windows) lub umieszczając systemy operacyjne w trybie paniki (system operacyjny gościa systemu Linux).

      • Mierzenie czasu potrzebnych do ukończenia pracy w trybie failover. Jeśli czasy są zbyt długie, rozważ następujące kwestie:

        • W przypadku systemu SUSE Linux użyj urządzeń SBD zamiast agenta usługi Azure Fencing, aby przyspieszyć tryb failover.
        • W przypadku platformy SAP HANA ponowne ładowanie danych trwa zbyt długo, rozważ zwiększenie wydajności magazynu.

      • W razie potrzeby przetestuj sekwencję tworzenia/przywracania kopii zapasowej i czas oraz dostosuj ich czas. Upewnij się, że nie tylko czas tworzenia kopii zapasowej jest wystarczający. Ponadto przetestuj przywracanie i wykonaj harmonogram działań przywracania. Upewnij się, że czasy przywracania znajdują się w ramach umów SLA celu czasu odzyskiwania, w których cel czasu odzyskiwania opiera się na procesie przywracania bazy danych lub maszyny wirtualnej.

      • Testowanie funkcjonalności i architektury odzyskiwania po awarii.

4. Przeprowadzanie kontroli zabezpieczeń

  • Przetestuj poprawność zaimplementowanego podejścia dostępu opartego na rolach (RBAC) platformy Azure. Celem jest oddzielenie i ograniczenie dostępu i uprawnień delegowanych do różnych zespołów. Na przykład członkowie zespołu SAP Basis powinni mieć możliwość wdrażania maszyn wirtualnych platformy Azure w danej sieci wirtualnej platformy Azure i przypisywania dysków do tych maszyn wirtualnych platformy Azure. Jednak zespół SAP Basis nie powinien być w stanie utworzyć nowych sieci wirtualnych ani zmienić ustawień istniejących sieci wirtualnych. Z drugiej strony członkowie zespołu ds. sieci nie powinni mieć możliwości wdrażania maszyn wirtualnych platformy Azure w sieciach wirtualnych, w których działają maszyny wirtualne sap application i DBMS. Członkowie zespołu sieciowego nie powinni również mieć możliwości zmiany atrybutów maszyn wirtualnych lub usuwania maszyn wirtualnych i ich dysków.
  • Sprawdź, czy reguły sieciowej grupy zabezpieczeń działają zgodnie z oczekiwaniami i chroń chronione zasoby.
  • Zweryfikuj szyfrowanie magazynowane i przesyłane. Definiowanie i implementowanie procesów tworzenia kopii zapasowych, przechowywania i uzyskiwania dostępu do certyfikatów oraz weryfikowania procesu przywracania zaszyfrowanych jednostek.
  • Użyj usługi Azure Disk Encryption dla dysków systemu operacyjnego.
  • Rozważ pragmatyczne podejście podczas podejmowania decyzji, czy wdrożyć mechanizm szyfrowania. Na przykład oceń, czy konieczne jest zastosowanie zarówno szyfrowania dysków platformy Azure, jak i funkcji Transparent Database Encryption w usłudze DBMS.

5. Testowanie wydajności

W scenariuszach migracji skorzystaj ze śledzenia i pomiarów sap, aby porównać pilotaż z bieżącą implementacją na podstawie:

  • 10 najważniejszych raportów online
  • 10 pierwszych zadań wsadowych
  • Transfer danych za pośrednictwem interfejsów do systemu SAP, koncentrując się na ruchu między środowiskami lokalnymi