Migracja dużych instancji SAP HANA na platformie Azure do maszyn wirtualnych na platformie Azure

W tym artykule opisano możliwe scenariusze wdrażania instancji dużej skali w Azure i oferuje podejście do planowania i migracji przy minimalizacji przestojów.

Omówienie

Duże instancje Azure dla SAP HANA (HLI) zostały po raz pierwszy ogłoszone we wrześniu 2016 roku. Od tego czasu wielu przyjęło ten sprzęt jako usługę dla swojej platformy obliczeniowej w pamięci. Jednak w ostatnich latach rozszerzenie rozmiaru maszyny wirtualnej platformy Azure i obsługa wdrożenia skalowalnego w poziomie platformy HANA przekroczyły zapotrzebowanie na pojemność bazy danych ERP klientów korporacyjnych. Wiele osób wyraża zainteresowanie migracją obciążenia SAP HANA z serwerów fizycznych do maszyn wirtualnych platformy Azure.

Ten artykuł nie jest dokumentem konfiguracji krok po kroku. Opisuje on typowe modele wdrażania i oferuje porady dotyczące planowania i migracji. Naszym celem jest objaśnienie niezbędnych zagadnień dotyczących przygotowania w celu zminimalizowania czasu przestojów okresu przejściowego.

Założenia

W tym artykule przyjęto następujące założenia:

• Rozważymy tylko homogeniczną migrację usługi obliczeniowej bazy danych HANA z Hana Large Instance (HLI) do maszyny wirtualnej Azure bez istotnych aktualizacji czy poprawek oprogramowania. Te drobne aktualizacje obejmują użycie nowszej wersji systemu operacyjnego lub wyraźnie wskazanej wersji HANA jako obsługiwanej przez odpowiednie noty SAP.
• Przed migracją lub po migracji wykonasz wszystkie działania dotyczące aktualizacji/uaktualnień. Na przykład platforma SAP HANA MCOS konwertuje na wdrożenie MDC.
• Podejście do migracji, które oferuje najmniejszy przestój, to replikacja systemu SAP HANA. Inne metody migracji nie są częścią zakresu tego dokumentu.
• Te wytyczne są aplikowalne zarówno dla jednostek SKU Rev3, jak i Rev4 HLI.
• Architektura wdrażania platformy HANA pozostaje przede wszystkim niezmieniona podczas migracji. Oznacza to, że system z pojedynczym odzyskiwaniem po awarii (DR) pozostanie niezmieniony w miejscu docelowym.
• Zapoznałeś się i zrozumiałeś umowę dotyczącą poziomu usług (SLA) dla przyszłej architektury docelowej.
• Warunki komercyjne między HLI i maszynami wirtualnymi są różne. Monitorowanie użycia maszyn wirtualnych na potrzeby zarządzania kosztami.
• Rozumiesz, że biblioteka HLI jest dedykowaną platformą obliczeniową, podczas gdy maszyny wirtualne działają na udostępnionej, ale izolowanej infrastrukturze.
• Sprawdzono, że docelowe maszyny wirtualne obsługują przeznaczoną architekturę. Aby uzyskać listę obsługiwanych jednostek SKU maszyn wirtualnych certyfikowanych do wdrożenia oprogramowania SAP HANA, zobacz katalog sprzętu SAP HANA.
• Sprawdzono projekt i plan migracji.
• Zaplanuj maszynę wirtualną odzyskiwania po awarii razem z główną lokalizacją. Nie można użyć HLI jako węzła odzyskiwania po awarii dla głównej lokalizacji działającej na maszynach wirtualnych po migracji.
• Skopiowano wymagane pliki kopii zapasowej do docelowych maszyn wirtualnych na podstawie wymagań firmy dotyczących odzyskiwalności i zgodności. Dzięki dostępnym kopiom zapasowym maszyny wirtualnej możliwe jest odzyskiwanie danych do konkretnego punktu w czasie w okresie przejściowym.
• W przypadku wysokiej dostępności replikacji systemu SAP HANA (HA) należy ustawić i skonfigurować urządzenie do grodzenia zgodnie z przewodnikami SAP HANA HA dla systemów SLES i RHEL. Nie jest ona wstępnie skonfigurowana tak jak przypadek HLI.
• To podejście do migracji nie obejmuje jednostek SKU HLI z konfiguracją Optane.

Scenariusze wdrażania

Możesz przeprowadzić migrację do maszyn wirtualnych platformy Azure dla wszystkich scenariuszy HLI. Typowe modele wdrażania dla biblioteki HLI zostały podsumowane w poniższej tabeli. Aby skorzystać z uzupełniających usług platformy Azure, może być konieczne wprowadzenie drobnych zmian architektury.

Identyfikator scenariusza	Scenariusz HLI	Czy przeprowadzić migrację do maszyny wirtualnej?	Uwaga
1	Jeden węzeł z jednym identyfikatorem SID	Tak	-
2	Jeden węzeł z wieloma składnikami w jednym systemie (MCOS)	Tak	-
3	Pojedynczy węzeł z odzyskiwaniem po awarii przy użyciu replikacji pamięci masowej	Nie.	Replikacja magazynu nie jest dostępna w przypadku platformy wirtualnej Azure; zmień swoje obecne rozwiązanie do odzyskiwania po awarii na HSR lub tworzenie kopii zapasowej i przywracanie.
4	Pojedynczy węzeł z odtwarzaniem po awarii (wielozadaniowy) wykorzystujący replikację pamięci	Nie.	Replikacja magazynu nie jest dostępna w przypadku platformy wirtualnej Azure; zmień swoje obecne rozwiązanie do odzyskiwania po awarii na HSR lub tworzenie kopii zapasowej i przywracanie.
5	HsR z ogrodzeniami w celu zapewnienia wysokiej dostępności	Tak	Brak wstępnie skonfigurowanego identyfikatora SBD dla docelowych maszyn wirtualnych. Wybierz i wdróż rozwiązanie ogrodzenia. Możliwe opcje: Agent usługi Azure Fencing (obsługiwany dla systemów RHEL, SLES oraz SBD).
6	Wysoka dostępność przy użyciu HSR, zarządzanie odzyskiwaniem po awarii z replikacją magazynu	Nie.	Zastąp replikację magazynu na potrzeby DR systemem HSR lub kopią zapasową/przywracaniem.
7	Automatyczne przełączanie hosta w tryb failover (1+1)	Tak	Użyj usługi Azure NetApp Files (ANF) na potrzeby magazynu udostępnionego z maszynami wirtualnymi platformy Azure.
8	Skalowanie w poziomie w trybie gotowości	Tak	BW/4HANA z maszynami wirtualnymi M128s, M416s, M416ms używającymi ANF tylko do przechowywania.
9	Skalowanie poziome bez trybu oczekiwania	Tak	BW/4HANA z maszynami wirtualnymi M128s, M416s, M416ms (z wykorzystaniem ANF do magazynowania lub bez niego).
10	Skalowanie w poziomie z odzyskiwaniem po awarii i replikacją magazynu	Nie.	Zastąp replikację magazynu na potrzeby DR systemem HSR lub kopią zapasową/przywracaniem.
11	Pojedynczy węzeł z odzyskiwaniem po awarii przy użyciu modułu HSR	Tak	-
12	Jednowęzłowy HSR do DR (zoptymalizowany pod kątem kosztów)	Tak	-
13	Wysoka dostępność i odzyskiwanie po awarii z modułem HSR	Tak	-
14	Wysoka dostępność i odzyskiwanie po awarii z modułem HSR (zoptymalizowane pod kątem kosztów)	Tak	-
15	Skalowanie horyzontalne z użyciem DR i HSR	Tak	BW/4HANA z M128s. M416s, maszyny wirtualne M416ms (z lub bez użycia rozwiązania ANF do magazynowania).

Planowanie źródła (HLI)

Podczas włączania serwera HLI ty i Microsoft Service Management przeprowadziliście planowanie ustawień obliczeniowych, sieci, magazynu i systemu operacyjnego do uruchamiania bazy danych SAP HANA. Podobne planowanie powinno mieć miejsce w przypadku migracji do maszyny wirtualnej na platformie Azure.

Zarządzanie systemem SAP HANA

Dobrym rozwiązaniem operacyjnym jest uporządkowanie zawartości bazy danych, więc niechciane, nieaktualne dane lub nieaktualne dzienniki nie są migrowane do nowej bazy danych. Przechowywanie danych zwykle wiąże się z usunięciem lub archiwizowaniem starych, wygasłych lub nieaktywnych danych. Ta "higiena danych" powinna być testowana w systemach nieprodukcyjnych, aby zweryfikować poprawność przycinania danych przed użyciem produkcyjnym.

Zezwalaj na łączność sieciową dla nowych maszyn wirtualnych i sieci wirtualnej

W twoim wdrożeniu HLI sieć została skonfigurowana na podstawie informacji opisanych w artykule Architektura sieci SAP HANA (Duże Wystąpienia). Ponadto routing ruchu sieciowego odbywa się w sposób opisany w sekcji Routing na platformie Azure.

• Czy nowe docelowe miejsce migracji maszyny wirtualnej znajduje się w istniejącej sieci wirtualnej z zakresami adresów IP już dozwolonymi do łączenia się z HLI? Następnie nie jest wymagana żadna dalsza aktualizacja łączności.
• Czy nowa maszyna wirtualna platformy Azure znajduje się w nowej sieci wirtualnej Microsoft Azure, może w innym regionie, i jest połączona równorzędnie z istniejącą siecią wirtualną? Następnie możesz użyć klucza usługi ExpressRoute i identyfikatora zasobu z oryginalnej aprowizacji HLI, aby zezwolić na dostęp do tego nowego zakresu adresów IP sieci wirtualnej. Koordynuj zarządzanie usługami firmy Microsoft, aby umożliwić łączność sieci wirtualnej z interfejsem HLI.

  Uwaga

  Aby zminimalizować opóźnienie sieci między warstwami aplikacji i bazy danych, warstwy aplikacji i bazy danych muszą znajdować się w tej samej sieci wirtualnej.

Istniejący zestaw dostępności dla warstwy aplikacji, strefy dostępności i grupa rozmieszczania w pobliżu (PPG)

Zaprojektowaliśmy bieżący model wdrażania, aby spełnić określone cele dotyczące poziomu usług. W tym przeniesieniu upewnij się, że infrastruktura docelowa spełni lub przekroczy określone cele.
Najprawdopodobniej serwery aplikacji SAP znajdują się w zestawie dostępności. Jeśli bieżący poziom usługi wdrażania jest zadowalający, a docelowa maszyna wirtualna przyjmuje nazwę hosta nazwy logicznej HLI, aktualizowanie rozpoznawania adresów usługi nazw domen (DNS) wskazujące na adres IP maszyny wirtualnej będzie działać bez aktualizowania żadnych profilów SAP.

• Jeśli nie używasz ppg, pamiętaj, aby umieścić wszystkie serwery aplikacji i baz danych w tej samej strefie, aby zminimalizować opóźnienie sieci.
• Jeśli używasz PPG, zapoznaj się z późniejszą sekcją tego artykułu, zestawy dostępności, strefy dostępności i grupy umieszczania w pobliżu.

Proces zaprzestania replikacji systemu przechowywania (jeśli jest używany)

Jeśli używałeś replikacji danych jako rozwiązania do odzyskiwania po awarii, zakończ ją po wyłączeniu aplikacji SAP. Przed wykonaniem tej czynności upewnij się, że ostatni katalog SAP HANA, plik dziennika i kopie zapasowe danych są replikowane na zdalne wolumeny pamięci masowej DR. Ta replikacja jest ważna w przypadku awarii podczas przejścia z serwera fizycznego do maszyny wirtualnej platformy Azure.

Zagadnienia dotyczące zachowywania kopii zapasowych danych

Po przejściu na platformę SAP HANA na maszynie wirtualnej platformy Azure kopie zapasowe danych i dzienników oparte na migawkach nie będą łatwo dostępne ani przywracane do maszyny wirtualnej. Zalecamy wykonywanie kopii zapasowych i migawek na poziomie plików na poziomie HLI nawet kilka tygodni przed przecięciem. Skopiuj te kopie zapasowe na konto usługi Azure Storage dostępne dla nowej maszyny wirtualnej SAP HANA. W początkowym okresie przejściowym, zanim kopia zapasowa oparta na platformie Azure zbuduje wystarczającą historię, aby spełnić wymagania dotyczące odtwarzania do określonego punktu w czasie, wykonaj kopie zapasowe na poziomie plików.

Tworzenie kopii zapasowej zawartości HLI jest krytyczne. Zaleca się również, aby pełne kopie zapasowe środowiska SAP były łatwo dostępne w przypadku konieczności wycofania.

Dostosowywanie monitorowania systemu

Możesz użyć wielu różnych narzędzi do monitorowania i wysyłania powiadomień o alertach dla systemów w obrębie środowiska SAP. Pamiętaj o podjęciu odpowiednich działań w celu uwzględnienia zmian w celu monitorowania i aktualizowania adresatów powiadomień o alertach w razie potrzeby.

Zaangażowanie zespołu ds. operacji firmy Microsoft

Otwórz zgłoszenie z portalu Azure dla istniejącego wystąpienia HLI. Po utworzeniu biletu pomocy technicznej inżynier pomocy technicznej skontaktuje się z Tobą pocztą e-mail.

Angażowanie zespołu ds. kont Microsoft

Zaplanuj migrację w pobliżu rocznicowego czasu odnowienia kontraktu HLI, aby zminimalizować niepotrzebne wydatki na zasób obliczeniowy. Aby zlikwidować HLI, należy skoordynować zakończenie kontraktu oraz zamknięcie jednostki.

Planowanie docelowe

Staranne planowanie ma zasadnicze znaczenie przy wdrażaniu nowej infrastruktury, aby zastąpić istniejącą infrastrukturę. Upewnij się, że nowy dodatek spełni Twoje potrzeby w większym schemacie rzeczy. Oto kilka kluczowych kwestii, które należy wziąć pod uwagę.

Dostępność zasobów w regionie docelowym

Bieżący region wdrażania serwerów aplikacji SAP jest zwykle zbliżony do skojarzonych interfejsów HLI. Jednak HLI są oferowane w mniej lokalizacjach niż w dostępnych regionach świadczenia usługi Azure. Podczas migrowania fizycznego HLI do maszyny wirtualnej platformy Azure warto również dostosować odległość zbliżeniową wszystkich powiązanych usług na potrzeby optymalizacji wydajności. Upewnij się, że wybrany region ma wszystkie wymagane zasoby. Na przykład możesz sprawdzić dostępność określonej rodziny maszyn wirtualnych lub stref platformy Azure oferujących konfigurację wysokiej dostępności.

Sieć wirtualna

Czy chcesz uruchomić nową bazę danych HANA w istniejącej sieci wirtualnej lub utworzyć nową? Podstawowym czynnikiem decydującym jest bieżący układ sieci dla środowiska SAP. Ponadto, gdy infrastruktura przechodzi z wdrożenia jednostrefowego na dwustrefowe i używa PPG, prowadzi to do zmiany architektury. Aby uzyskać więcej informacji, zobacz artykuł Azure PPG w celu uzyskania optymalnego opóźnienia sieci w aplikacji SAP.

Zabezpieczenia

Niezależnie od tego, czy nowa maszyna wirtualna SAP HANA działa w nowej, czy istniejącej sieci wirtualnej/podsieci, jest to nowa usługa krytyczna dla Twojej firmy. Zasługuje na ochronę. Upewnij się, że kontrola dostępu jest zgodna z zasadami zabezpieczeń firmy.

Zalecenie dotyczące określania rozmiaru maszyny wirtualnej

Ta migracja jest również okazją do odpowiedniego rozmiaru aparatu obliczeniowego HANA. Systemowe widoki HANA, używane z HANA Studio, umożliwiają zrozumienie zużycia zasobów systemowych, co umożliwia odpowiednie dopasowanie rozmiaru do efektywnego zarządzania wydatkami.

Przechowywanie

Wydajność pamięci masowej jest jednym z czynników wpływających na doświadczenie użytkownika aplikacji SAP. Istnieją minimalne układy magazynu opublikowane dla poszczególnych jednostek SKU maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Konfiguracje magazynu maszyn wirtualnych platformy Azure SAP HANA. Zalecamy przejrzenie tych specyfikacji i porównanie z istniejącymi statystykami systemu HLI w celu zapewnienia odpowiedniej pojemności i wydajności IO dla nowej maszyny wirtualnej HANA.

Czy skonfigurujesz grupę PPG dla nowej maszyny wirtualnej HANA i skojarzonych z nią serwerów? Następnie prześlij zgłoszenie do pomocy technicznej, aby sprawdzić i upewnić się, że pamięć oraz maszyna wirtualna są współlokowane. Ponieważ rozwiązanie tworzenia kopii zapasowych może wymagać zmiany, przemyśl ponownie koszty przechowywania, aby uniknąć niespodzianek związanych z wydatkami operacyjnymi.

Replikacja magazynu na potrzeby odzyskiwania po awarii

W HLI replikacja magazynu była domyślną opcją odzyskiwania po awarii. Ta funkcja nie jest opcją domyślną dla platformy SAP HANA na maszynie wirtualnej platformy Azure. Rozważ użycie modułu HSR, tworzenia kopii zapasowej/przywracania lub innych obsługiwanych rozwiązań, które spełniają Twoje potrzeby biznesowe.

Zestawy dostępności, strefy dostępności i grupy lokalizacji w pobliżu

Możesz skrócić odległość między warstwą aplikacji a platformą SAP HANA, aby zapewnić minimalne opóźnienie sieci. Umieść nową maszynę wirtualną do obsługi bazy danych oraz bieżące serwery aplikacji SAP w PPG. Aby uzyskać więcej informacji na temat współdziałania zestawu dostępności platformy Azure i stref dostępności z PPG dla wdrożeń SAP, zobacz Grupa umieszczania w pobliżu.

Jeśli członkowie systemu HANA są wdrażani w więcej niż jednej strefie platformy Azure, należy pamiętać o profilu opóźnienia wybranych stref. Umieść składniki systemu SAP w celu zmniejszenia odległości między aplikacją SAP a bazą danych. Narzędzie do testowania opóźnienia strefy dostępności domeny publicznej ułatwia pomiar.

Strategia tworzenia kopii zapasowych

Wielu naszych klientów korzysta już z rozwiązań do tworzenia kopii zapasowych innych firm dla oprogramowania SAP HANA w systemie HLI. Jeśli tak, należy skonfigurować tylko chronione maszyny wirtualne i bazy danych HANA. Bieżące zadania tworzenia kopii zapasowej HLI można anulować, jeśli maszyna jest likwidowana po migracji.

Usługa Azure Backup dla platformy SAP HANA na maszynie wirtualnej jest teraz ogólnie dostępna. Aby uzyskać więcej informacji na temat tworzenia kopii zapasowych sap HANA na maszynach wirtualnych platformy Azure, zobacz Tworzenie kopii zapasowych, przywracanie i zarządzanie.

Strategia odzyskiwania po awarii

Jeśli cele dotyczące poziomu usługi umożliwiają dłuższy czas odzyskiwania, tworzenie kopii zapasowej może być łatwe. Tworzenie kopii zapasowej w magazynie obiektów blob oraz przywracanie danych na miejscu lub na nowej maszynie wirtualnej jest najprostszą i najmniej kosztowną strategią odzyskiwania po awarii.

Na platformie dużych instancji awaryjne odzyskiwanie danych HANA jest zazwyczaj wykonywane za pomocą HSR. Na maszynie wirtualnej platformy Azure moduł HSR jest również najbardziej naturalnym i natywnym rozwiązaniem SAP HANA DR. Niezależnie od tego, czy wdrożenie źródłowe jest pojedynczym wystąpieniem, czy klastrem, w regionie DR wymagana jest replika infrastruktury źródłowej. Ta replika odtworzenia po awarii zostanie skonfigurowana po zakończeniu podstawowej migracji HLI do maszyny wirtualnej. Baza danych DR HANA zostanie zarejestrowana w podstawowym wystąpieniu platformy SAP HANA na maszynie wirtualnej jako lokacja replikacji dodatkowej.

Zmiana miejsca docelowego łączności serwera aplikacji SAP

Migracja modułu HSR powoduje utworzenie nowego hosta bazy danych HANA, a także nową nazwę hosta bazy danych dla warstwy aplikacji. Zmodyfikuj profile SAP, aby odzwierciedlały nową nazwę hosta. Jeśli przełączanie odbywa się przez rozpoznawanie nazw zachowując nazwę hosta, nie jest wymagana żadna zmiana profilu.

System operacyjny (OS)

Obrazy systemu operacyjnego dla HLI i maszyny wirtualnej, mimo że są na tym samym poziomie wydania (na przykład SLES 12 SP4), nie są identyczne. Zweryfikuj wymagane pakiety, hotfixy, poprawki, jądro systemu i aktualizacje zabezpieczeń na HLI. Następnie zainstaluj te same pakiety w lokalizacji docelowej. Za pomocą modułu HSR można replikować ze starszego systemu operacyjnego na maszynę wirtualną z nowszą wersją systemu operacyjnego. Sprawdź obsługiwane wersje, przeglądając 2763388 notatek SAP.

Nowe żądanie licencji SAP

Proste wywołanie w celu zażądania nowej licencji SAP dla nowego systemu HANA, które zostało teraz zmigrowane do maszyn wirtualnych.

Różnice w umowie dotyczącej poziomu usług (SLA)

Autorzy lubią wskazywać różnicę w umowie SLA dotyczącej dostępności między HLI a maszyną wirtualną platformy Azure. Na przykład klastrowane pary wysokiej dostępności HLI oferują dostępność 99,99%. Aby osiągnąć tę samą umowę SLA, należy wdrożyć maszyny wirtualne w strefach dostępności. Umowa SLA dla maszyn wirtualnych opisuje dostępność różnych konfiguracji maszyn wirtualnych, dzięki czemu klienci mogą planować infrastrukturę docelową.

Strategia migracji

W tym dokumencie omówiono tylko podejście replikacji systemu HANA na potrzeby migracji z biblioteki HLI do maszyny wirtualnej platformy Azure. Zależy od wdrożonego rozwiązania magazynu docelowego, proces różni się nieco. Poniżej opisano wysokopoziomowe kroki.

Maszyna wirtualna z dyskami w warstwie Premium/Ultra do przechowywania danych

W przypadku maszyn wirtualnych wdrożonych z dyskami w warstwie Premium lub Ultra standardowa konfiguracja replikacji systemu SAP HANA ma zastosowanie do konfigurowania modułu HSR. Aby zapoznać się z omówieniem kroków konfigurowania replikacji systemu, zobacz artykuł pomocy SAP. W tym artykule opisano również przejęcie systemu pomocniczego, powrót po awarii do podstawowego i wyłączenie replikacji systemu. W przypadku migracji potrzebujemy tylko konfiguracji, przejęcia i wyłączenia kroków replikacji.

Maszyna wirtualna z funkcją ANF na potrzeby woluminów danych i dzienników

Na wysokim poziomie należy skopiować najnowsze migawki magazynu HLI z pełnymi danymi i woluminami dzienników do usługi Azure Storage. Z tego miejsca są dostępne i możliwe do odzyskania przez docelową maszynę wirtualną HANA. Proces kopiowania można wykonać przy użyciu dowolnego natywnego narzędzia do kopiowania systemu Linux.

Ważne

Kopiowanie i transfer danych może potrwać kilka godzin w zależności od rozmiaru bazy danych i przepustowości sieci platformy HANA. Większość procesu kopiowania należy wykonać przed przestojem podstawowej bazy danych HANA.

Konwersja MCOS na MDC

Model wdrażania wielu składników w jednym systemie (MCOS) był używany przez niektórych naszych klientów HLI. Motywem było obejście ograniczenia migawek magazynu wielu baz danych (MDC) wcześniejszych wersji oprogramowania SAP HANA. W modelu MCOS kilka niezależnych wystąpień platformy SAP HANA jest skumulowanych w jednym dużym wystąpieniu platformy HANA. Korzystanie z HSR do migracji działa prawidłowo, ale skutkuje wieloma maszynami wirtualnymi HANA, z których każda zawiera jedną bazę danych dla lokatora. Ten model sprawia, że krajobraz jest bardziej ruchliwy niż ten, który mógłbyś preferować. Domyślne wdrożenie oprogramowania SAP HANA 2.0 to MDC. Alternatywą jest przeniesienie dzierżawy platformy HANA po migracji modułu HSR. Przeniesienie dzierżawy HANA łączy te niezależne bazy danych HANA jako współdzierżawy w jednym kontenerze HANA.

Zagadnienia dotyczące warstwy aplikacji

Serwer bazy danych jest postrzegany jako środek systemu SAP. Wszystkie serwery aplikacji powinny znajdować się w pobliżu bazy danych SAP HANA. W niektórych przypadkach, gdy chcesz użyć nowej grupy zabezpieczeń, może być konieczne przeniesienie istniejących serwerów aplikacji do grupy PPG, w której znajduje się maszyna wirtualna HANA. Tworzenie nowych serwerów aplikacji może być uznawane za łatwiejsze, jeśli masz już gotowe szablony wdrażania.

Zlokalizuj istniejące serwery aplikacji i nową maszynę wirtualną HANA optymalnie. Wtedy nie trzeba tworzyć nowych serwerów aplikacji, chyba że chcesz mieć większą pojemność.

Podczas tworzenia nowej infrastruktury w celu zwiększenia dostępności usług istniejące serwery aplikacji mogą stać się niepotrzebne. Można je zamknąć i usunąć. Jeśli docelowa nazwa hosta maszyny wirtualnej uległa zmianie i różni się od nazwy hosta HLI, dostosuj profile serwera aplikacji SAP, aby wskazać nowego hosta. Jeśli tylko adres IP bazy danych HANA uległ zmianie, zaktualizuj rekord DNS, aby prowadzić połączenia przychodzące z nową maszyną wirtualną HANA.

Test akceptacji

Migracja z biblioteki HLI na maszynę wirtualną nie powoduje istotnej zmiany zawartości bazy danych w porównaniu z migracją heterogeniczną. Mimo to zalecamy sprawdzenie wydajności nowej konfiguracji.

Plan przełączenia

Chociaż ta migracja jest prosta, wiąże się z likwidacją istniejącej bazy danych. Staranne planowanie w celu zachowania systemu źródłowego wraz z jego zawartością i obrazami zapasowymi ma kluczowe znaczenie, jeśli konieczne jest przywrócenie. Dobre planowanie oferuje przyspieszenie odwrócenia.

Po migracji

Zadanie migracji nie zostanie wykonane, dopóki nie będziemy bezpiecznie odłączać żadnych usług zależnych od HLI i łączności w celu zapewnienia integralności danych. Zalecamy również zamknięcie niepotrzebnych usług. W tej sekcji przedstawiono kilka najważniejszych elementów.

Wycofanie z eksploatacji interfejsu HLI

Po pomyślnym przeprowadzeniu migracji bazy danych HANA do maszyny wirtualnej platformy Azure upewnij się, że żadne transakcje biznesowe nie są uruchamiane w bazie danych HLI. Jednak utrzymanie uruchomionego interfejsu HLI przez długi czas lokalnego okna przechowywania kopii zapasowych zapewni przyspieszenie odzyskiwania w razie potrzeby. Tylko wtedy, gdy lokalne okno przechowywania kopii zapasowych zostanie przekroczone, należy zdezaktywować dużą instancję HANA. Następnie spełnij zobowiązania umowy HLI z Microsoft, kontaktując się z ich przedstawicielami.

Usuń dowolny serwer proxy (na przykład Iptables, BIGIP) skonfigurowany dla interfejsu HLI

Jeśli usługa proxy, taka jak IPTables, jest używana do kierowania ruchu lokalnego do i z HLI, nie jest potrzebna po pomyślnej migracji do maszyny wirtualnej. Niemniej jednak ta usługa łączności powinna być utrzymywana tak długo, jak długo HLI jest w trybie gotowości. Należy zamknąć usługę dopiero po całkowitym wycofaniu HLI.

Usuń globalny zasięg dla HLI

Usługa Global Reach służy do łączenia bramy usługi ExpressRoute klientów z bramą usługi ExpressRoute HLI. Umożliwia lokalnemu ruchowi klientów bezpośrednie dotarcie do najemcy HLI bez korzystania z usługi proxy. To połączenie nie jest już potrzebne w przypadku braku jednostki HLI po migracji. Mimo to, podobnie jak usługa serwera proxy IPTables, usługa GlobalReach powinna być również przechowywana do momentu całkowitego zlikwidowania interfejsu HLI.

Subskrypcja systemu operacyjnego — przenoszenie/ponowne używanie

W miarę wdrażania serwerów maszyn wirtualnych i likwidacji HLI subskrypcje systemu operacyjnego można zamienić lub ponownie użyć. Nie trzeba płacić dwukrotnie za licencje systemu operacyjnego.

Następne kroki

Zaplanuj swoje wdrożenie SAP.

Obciążenia SAP na platformie Azure: lista kontrolna planowania i wdrażania