Migracja oprogramowania SAP HANA na platformę Azure — duże wystąpienie na maszyny wirtualne platformy Azure

W tym artykule opisano możliwe scenariusze wdrażania dużych wystąpień platformy Azure i oferuje podejście do planowania i migracji z zminimalizowanymi przestojami przejścia.

Omówienie

Duże wystąpienia platformy Azure dla platformy SAP HANA (HLI) zostały ogłoszone po raz pierwszy 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 przestojów przejścia.

Założenia

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

• Rozważymy tylko jednorodną migrację usługi obliczeniowej bazy danych HANA z dużego wystąpienia platformy Hana (HLI) na maszynę wirtualną platformy Azure bez znaczącego uaktualnienia oprogramowania lub stosowania poprawek. Te aktualizacje pomocnicze obejmują użycie nowszej wersji systemu operacyjnego lub jawnie określonej wersji HANA jako obsługiwanej przez odpowiednie uwagi 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 wskazówki dotyczą jednostek SKU Rev3 i Rev4 biblioteki HLI.
• Architektura wdrażania platformy HANA pozostaje przede wszystkim niezmieniona podczas migracji. Oznacza to, że system z odzyskiwaniem po awarii pojedynczego wystąpienia pozostanie w tym samym miejscu docelowym.
• Zapoznaliśmy się z umową dotyczącą poziomu usług (SLA) architektury docelowej (to-be).
• 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 wraz z lokacją główną. Nie można użyć HLI jako węzła odzyskiwania po awarii dla lokacji głównej uruchomionej na maszynach wirtualnych po migracji.
• Skopiowano wymagane pliki kopii zapasowej do docelowych maszyn wirtualnych na podstawie wymagań dotyczących możliwości odzyskiwania i zgodności firmy. Dzięki dostępnym kopiom zapasowym maszyny wirtualnej umożliwia odzyskiwanie do punktu w czasie w okresie przejściowym.
• W przypadku wysokiej dostępności replikacji systemu SAP HANA (HA) należy skonfigurować i skonfigurować urządzenie ogrodzeniowe na przewodniki 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 magazynu	Nie.	Replikacja magazynu nie jest dostępna w przypadku platformy wirtualnej platformy Azure; zmień bieżące rozwiązanie odzyskiwania po awarii na HSR lub tworzenie kopii zapasowej/przywracanie.
100	Pojedynczy węzeł z odzyskiwaniem po awarii (multipurpose) przy użyciu replikacji magazynu	Nie.	Replikacja magazynu nie jest dostępna w przypadku platformy wirtualnej platformy Azure; zmień bieżące rozwiązanie odzyskiwania po awarii na HSR lub tworzenie kopii zapasowej/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 zarówno dla systemów RHEL, SLES, jak i SBD.
6	Wysoka dostępność z modułem HSR, odzyskiwanie po awarii z replikacją magazynu	Nie.	Zastąp replikację magazynu na potrzeby odzyskiwania po awarii za pomocą modułu HSR lub kopii zapasowej/przywracania.
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 z rezerwą	Tak	BW/4HANA z maszynami wirtualnymi M128, M416s, M416ms używającymi funkcji ANF tylko do magazynowania.
9	Skalowanie w poziomie bez wstrzymania	Tak	BW/4HANA z maszynami wirtualnymi M128, M416s, M416ms (z funkcją ANF do magazynowania lub bez użycia jej).
10	Skalowanie w poziomie przy użyciu odzyskiwania po awarii przy użyciu replikacji magazynu	Nie.	Zastąp replikację magazynu na potrzeby odzyskiwania po awarii za pomocą modułu HSR lub kopii zapasowej/przywracania.
11	Pojedynczy węzeł z odzyskiwaniem po awarii przy użyciu modułu HSR	Tak	-
12	Moduł HSR z jednym węzłem do odzyskiwania po awarii (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 w poziomie przy użyciu odzyskiwania po awarii przy użyciu modułu 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 dołączania serwera HLI ty i microsoft Service Management przeprowadziliśmy planowanie ustawień obliczeniowych, sieci, magazynu i systemu operacyjnego do uruchamiania bazy danych SAP HANA. Podobne planowanie wymaga migracji do maszyny wirtualnej platformy Azure.

Przechowywanie domów w oprogramowaniu 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

We 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 nowy element docelowy migracji maszyny wirtualnej znajduje się w istniejącej sieci wirtualnej z zakresami adresów IP, które już mogą łączyć się z interfejsem HLI? Następnie nie jest wymagana żadna dalsza aktualizacja łączności.
• Czy nowa maszyna wirtualna platformy Azure znajduje się w nowej usłudze Microsoft Azure Virtual Network, być może w innym regionie, i jest równorzędna 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 warstwy aplikacji, strefy dostępności i grupa umieszczania 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 grupy PPG, zapoznaj się z późniejszą sekcją tego artykułu, zestawami dostępności, strefami dostępności i grupami umieszczania w pobliżu.

Proces przerwania replikacji magazynu (jeśli jest używany)

Jeśli używasz replikacji magazynu jako rozwiązania odzyskiwania po awarii, zakończ ją po zamknięciu aplikacji SAP. Przed wykonaniem tej czynności upewnij się, że ostatni katalog SAP HANA, plik dziennika i kopie zapasowe danych są replikowane na zdalnych woluminach magazynu odzyskiwania po awarii. 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. Czy te kopie zapasowe zostały skopiowane na konto usługi Azure Storage dostępne przez nową maszynę wirtualną SAP HANA. W okresie wczesnego przejścia przed utworzeniem kopii zapasowej opartej na platformie Azure wystarczająco dużo historii, aby spełnić wymagania dotyczące odzyskiwania do 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 bilet z witryny Azure Portal na podstawie 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, koordynować zakończenie kontraktu i zamykanie jednostki.

Planowanie docelowe

Staranne planowanie ma zasadnicze znaczenie w wdrażaniu nowej infrastruktury w celu wdrożenia istniejącej infrastruktury. 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 z jednej strefy do dwóch stref i używa ppg, nakłada 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. Widoki systemowe platformy HANA z programem HANA Studio umożliwiają zrozumienie zużycia zasobów systemowych , co pozwala na odpowiednie ustalanie rozmiaru w celu zwiększenia wydajności wydatków.

Storage

Wydajność magazynu jest jednym z czynników wpływających na środowisko 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 operacji we/wy dla nowej maszyny wirtualnej HANA.

Czy skonfigurujesz grupę PPG dla nowej maszyny wirtualnej HANA i skojarzonych z nią serwerach? Następnie prześlij bilet pomocy technicznej, aby sprawdzić i upewnić się, że współlokowanie magazynu i maszyny wirtualnej. Ponieważ rozwiązanie do tworzenia kopii zapasowych może wymagać zmiany, ponownie zapoznaj się z kosztem magazynu, aby uniknąć niespodzianek wydatków operacyjnych.

Replikacja magazynu na potrzeby odzyskiwania po awarii

W przypadku wystąpienia 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 umieszczania 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ą bazy danych i bieżące serwery aplikacji SAP w usłudze PPG. Aby uzyskać więcej informacji na temat współdziałania zestawu dostępności platformy Azure i stref dostępności z grupą 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 i przywracanie ich na nowej maszynie wirtualnej jest najprostszą i najmniej kosztowną strategią odzyskiwania po awarii.

Na dużej platformie wystąpień odzyskiwanie po awarii platformy HANA jest zwykle wykonywane przy użyciu modułu 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, replika infrastruktury źródłowej jest wymagana w regionie odzyskiwania po awarii. Ta replika odzyskiwania 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, gorące poprawki, poprawki, jądro i poprawki zabezpieczeń w bazie danych 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ą objaśniać różnicę w umowie SLA dotyczącej dostępności między biblioteką HLI i 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 ogólne kroki.

Maszyna wirtualna z dyskami w warstwie Premium/Ultra dla 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 modułu HSR do migracji działa prawidłowo, ale powoduje, że każda z nich zawiera wiele maszyn wirtualnych HANA z jedną bazą danych dzierżawy. Ten model sprawia, że bardziej ruchliwy krajobraz niż to, co możesz preferować. Domyślne wdrożenie oprogramowania SAP HANA 2.0 to MDC. Alternatywą jest przeniesienie dzierżawy platformy HANA po migracji modułu HSR. Przenoszenie dzierżawy platformy HANA łączy te niezależne bazy danych HANA w 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 migracji jednorazowej

Chociaż ta migracja jest prosta, wiąże się z likwidacją istniejącej bazy danych. Staranne planowanie zachowania systemu źródłowego z jego zawartością i obrazami kopii zapasowych ma krytyczne znaczenie w przypadku, gdy konieczne jest powrót. 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.

Likwidowanie 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 jest przeszłości, należy zlikwidować duże wystąpienie HANA. Następnie zakończ zobowiązania umowy HLI z firmą Microsoft, kontaktując się z przedstawicielami firmy Microsoft.

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ć przechowywana tak długo, jak długo trwa proces HLI. Po pełnym zlikwidowaniu likwidowania usługi należy zamknąć usługę.

Usuwanie globalnego zasięgu dla interfejsu HLI

Usługa Global Reach służy do łączenia bramy usługi ExpressRoute klientów z bramą usługi ExpressRoute HLI. Dzięki niej ruch lokalny klientów może bezpośrednio dotrzeć do dzierżawy 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

Planowanie wdrożenia sap.

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