Udostępnij za pośrednictwem

Konfiguracje infrastruktury SAP HANA i operacje na platformie Azure

  • Artykuł

Ten dokument zawiera wskazówki dotyczące konfigurowania infrastruktury platformy Azure i systemów SAP HANA wdrożonych na maszynach wirtualnych natywnych dla platformy Azure. Dokument zawiera również informacje o konfiguracji dla skalowalnego w poziomie oprogramowania SAP HANA dla jednostki SKU maszyny wirtualnej M128s. Ten dokument nie jest przeznaczony do zastąpienia standardowej dokumentacji sap, która zawiera następującą zawartość:

Wymagania wstępne

Aby skorzystać z tego przewodnika, potrzebujesz podstawowej wiedzy na temat następujących składników platformy Azure:

Aby dowiedzieć się więcej na temat oprogramowania SAP NetWeaver i innych składników SAP na platformie Azure, zobacz sekcję SAP na platformie Azure w dokumentacji platformy Azure.

Podstawowe zagadnienia dotyczące konfiguracji

W poniższych sekcjach opisano podstawowe zagadnienia dotyczące konfiguracji wdrażania systemów SAP HANA na maszynach wirtualnych platformy Azure.

Nawiązywanie połączenia z maszynami wirtualnymi platformy Azure

Jak opisano w przewodniku planowania maszyn wirtualnych platformy Azure, istnieją dwie podstawowe metody nawiązywania połączenia z maszynami wirtualnymi platformy Azure:

  • Nawiąż połączenie za pośrednictwem Internetu i publicznych punktów końcowych na maszynie wirtualnej przesiadkowej lub na maszynie wirtualnej z uruchomioną platformą SAP HANA.
  • Nawiąż połączenie za pośrednictwem sieci VPN lub usługi Azure ExpressRoute.

Łączność typu lokacja-lokacja za pośrednictwem sieci VPN lub usługi ExpressRoute jest niezbędna w scenariuszach produkcyjnych. Ten typ połączenia jest również wymagany w scenariuszach nieprodukcyjnych, które są wprowadzane do scenariuszy produkcyjnych, w których jest używane oprogramowanie SAP. Na poniższej ilustracji przedstawiono przykład łączności między lokacjami:

Łączność między lokacjami

Wybieranie typów maszyn wirtualnych platformy Azure

Oprogramowanie SAP zawiera listę typów maszyn wirtualnych platformy Azure, których można użyć w scenariuszach produkcyjnych. W przypadku scenariuszy nieprodukcyjnych dostępna jest szersza różnorodność natywnych typów maszyn wirtualnych platformy Azure.

Uwaga

W przypadku scenariuszy nieprodukcyjnych użyj typów maszyn wirtualnych wymienionych w notatce SAP #1928533. Aby uzyskać informacje na temat użycia maszyn wirtualnych platformy Azure w scenariuszach produkcyjnych, sprawdź, czy maszyny wirtualne certyfikowane na platformie SAP HANA znajdują się na liście certyfikowanych platform IaaS sap.

Wdróż maszyny wirtualne na platformie Azure przy użyciu:

  • witryny Azure Portal.
  • Polecenia cmdlet programu Azure PowerShell.
  • Interfejs wiersza polecenia platformy Azure.

Możesz również wdrożyć pełną zainstalowaną platformę SAP HANA w usługach maszyn wirtualnych platformy Azure za pośrednictwem platformy SAP Cloud. Proces instalacji został opisany w temacie Wdrażanie oprogramowania SAP S/4HANA lub BW/4HANA na platformie Azure.

Ważne

Aby używać maszyn wirtualnych M208xx_v2, należy zachować ostrożność podczas wybierania obrazu systemu Linux. Aby uzyskać więcej informacji, zobacz Rozmiary maszyn wirtualnych zoptymalizowane pod kątem pamięci.

Konfiguracja magazynu dla platformy SAP HANA

Aby uzyskać informacje o konfiguracjach magazynu i typach magazynu, które mają być używane z platformą SAP HANA na platformie Azure, przeczytaj dokument Konfiguracje magazynu maszyn wirtualnych platformy Azure SAP HANA

Konfigurowanie sieci wirtualnych platformy Azure

Jeśli masz łączność typu lokacja-lokacja z platformą Azure za pośrednictwem sieci VPN lub usługi ExpressRoute, musisz mieć co najmniej jedną sieć wirtualną platformy Azure połączoną za pośrednictwem bramy wirtualnej z siecią VPN lub obwodem usługi ExpressRoute. W prostych wdrożeniach bramę wirtualną można wdrożyć w podsieci sieci wirtualnej platformy Azure, która hostuje również wystąpienia platformy SAP HANA. Aby zainstalować platformę SAP HANA, należy utworzyć dwie kolejne podsieci w sieci wirtualnej platformy Azure. Jedna podsieć hostuje maszyny wirtualne do uruchamiania wystąpień sap HANA. Druga podsieć uruchamia maszyny wirtualne Jumpbox lub Management, aby hostować oprogramowanie SAP HANA Studio, inne oprogramowanie do zarządzania lub oprogramowanie aplikacji.

Ważne

Poza funkcjonalnością, ale ważniejsze z powodów wydajności, nie jest obsługiwane konfigurowanie wirtualnych urządzeń sieciowych platformy Azure w ścieżce komunikacji między aplikacją SAP a warstwą DBMS systemu SAP NetWeaver, Hybris lub S/4HANA. Komunikacja między warstwą aplikacji SAP a warstwą DBMS musi być bezpośrednia. Ograniczenie nie obejmuje reguł usługi Azure ASG i sieciowej grupy zabezpieczeń, o ile reguły grupy zabezpieczeń i grupy zabezpieczeń grupy zabezpieczeń zezwalają na bezpośrednią komunikację. Dalsze scenariusze, w których urządzenia WUS nie są obsługiwane, znajdują się w ścieżkach komunikacyjnych między maszynami wirtualnymi platformy Azure reprezentującymi węzły klastra Pacemaker systemu Linux i urządzenia SBD zgodnie z opisem w temacie Wysoka dostępność oprogramowania SAP NetWeaver na maszynach wirtualnych platformy Azure w systemie SUSE Linux Enterprise Server dla aplikacji SAP. Lub w ścieżkach komunikacji między maszynami wirtualnymi platformy Azure a serwerem SOFS systemu Windows skonfigurowanym zgodnie z opisem w temacie Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a file share in Azure (Klaster wystąpienia SAP ASCS/SCS w klastrze trybu failover systemu Windows przy użyciu udziału plików na platformie Azure). Urządzenia WUS w ścieżkach komunikacyjnych mogą łatwo podwoić opóźnienie sieci między dwoma partnerami komunikacyjnymi, mogą ograniczyć przepływność w krytycznych ścieżkach między warstwą aplikacji SAP a warstwą DBMS. W niektórych scenariuszach zaobserwowanych u klientów urządzenia WUS mogą spowodować awarię klastrów pacemaker systemu Linux w przypadkach, gdy komunikacja między węzłami klastra Pacemaker systemu Linux musi komunikować się z urządzeniem SBD za pośrednictwem urządzenia WUS.

Ważne

Innym projektem, który nie jest obsługiwany, jest podział warstwy aplikacji SAP i warstwy DBMS na różne sieci wirtualne platformy Azure, które nie są ze sobą równorzędne. Zaleca się segregowanie warstwy aplikacji SAP i warstwy DBMS przy użyciu podsieci w sieci wirtualnej platformy Azure zamiast używania różnych sieci wirtualnych platformy Azure. Jeśli zdecydujesz się nie postępować zgodnie z zaleceniem, a zamiast tego rozdzielisz obie warstwy na inną sieć wirtualną, dwie sieci wirtualne muszą być równorzędne. Należy pamiętać, że ruch sieciowy między dwiema równorzędną sieciami wirtualnymi platformy Azure podlega kosztom transferu. Dzięki ogromnemu ilości danych w wielu terabajtach wymienianych między warstwą aplikacji SAP i warstwą DBMS można zgromadzić znaczne koszty, jeśli warstwa aplikacji SAP i warstwa DBMS są segregowane między dwie równorzędne sieci wirtualne platformy Azure.

W przypadku wdrożenia maszyn wirtualnych Jumpbox lub zarządzania w oddzielnej podsieci można zdefiniować wiele wirtualnych kart sieciowych (vNICs) dla maszyny wirtualnej platformy HANA z każdą wirtualną kartą sieciową przypisaną do innej podsieci. Dzięki możliwości posiadania wielu wirtualnych kart sieciowych można w razie potrzeby skonfigurować separację ruchu sieciowego. Na przykład ruch klienta można kierować za pośrednictwem podstawowej wirtualnej karty sieciowej, a ruch administracyjny jest kierowany przez drugą wirtualną sieć sieciową.
Przypisujesz również statyczne prywatne adresy IP wdrożone dla obu wirtualnych kart sieciowych.

Uwaga

Statyczne adresy IP należy przypisać za pośrednictwem platformy Azure do poszczególnych wirtualnych kart sieciowych. Nie należy przypisywać statycznych adresów IP w systemie operacyjnym gościa do wirtualnej karty sieciowej. Niektóre usługi platformy Azure, takie jak Usługa Azure Backup, polegają na tym, że co najmniej podstawowa wirtualna sieć sieciowa jest ustawiona na protokół DHCP, a nie statyczne adresy IP. Zobacz również dokument Rozwiązywanie problemów z tworzeniem kopii zapasowych maszyn wirtualnych platformy Azure. Jeśli musisz przypisać wiele statycznych adresów IP do maszyny wirtualnej, musisz przypisać wiele wirtualnych kart sieciowych do maszyny wirtualnej.

Jednak w przypadku wdrożeń, które są trwałe, należy utworzyć architekturę sieci wirtualnego centrum danych na platformie Azure. Ta architektura zaleca rozdzielenie bramy sieci wirtualnej platformy Azure, która łączy się ze środowiskiem lokalnym w oddzielnej sieci wirtualnej platformy Azure. Ta oddzielna sieć wirtualna powinna obsługiwać cały ruch, który pozostawia ruch do środowiska lokalnego lub do Internetu. Takie podejście umożliwia wdrażanie oprogramowania do inspekcji i rejestrowania ruchu, który przechodzi do wirtualnego centrum danych na platformie Azure w tej oddzielnej sieci wirtualnej koncentratora. Masz więc jedną sieć wirtualną, która hostuje wszystkie oprogramowanie i konfiguracje, które odnoszą się do ruchu przychodzącego i wychodzącego do wdrożenia platformy Azure.

Artykuły Azure Virtual Datacenter: A Network Perspective and Azure Virtual Datacenter and the Enterprise Control Plane (Wirtualne centrum danych platformy Azure) zawierają więcej informacji na temat podejścia wirtualnego centrum danych i powiązanego projektu sieci wirtualnej platformy Azure.

Uwaga

Ruch przepływujący między siecią wirtualną piasty i siecią wirtualną szprych przy użyciu komunikacji równorzędnej sieci wirtualnych platformy Azure wiąże się z dodatkowymi kosztami. Na podstawie tych kosztów może być konieczne rozważenie podejmowania kompromisów między uruchomieniem ścisłego projektu sieci piasty i szprych oraz uruchomieniem wielu bram usługi Azure ExpressRoute, które łączą się z "szprychami", aby obejść komunikację równorzędną sieci wirtualnych. Jednak bramy usługi Azure ExpressRoute również wiążą się z dodatkowymi kosztami . Mogą również wystąpić dodatkowe koszty oprogramowania innych firm używanego do rejestrowania ruchu sieciowego, inspekcji i monitorowania. Zależne od kosztów wymiany danych za pośrednictwem komunikacji równorzędnej sieci wirtualnych po jednej stronie i kosztów utworzonych przez dodatkowe bramy usługi Azure ExpressRoute i dodatkowe licencje na oprogramowanie, możesz zdecydować o mikrosegmentacji w jednej sieci wirtualnej przy użyciu podsieci jako jednostki izolacji zamiast sieci wirtualnych.

Aby zapoznać się z omówieniem różnych metod przypisywania adresów IP, zobacz Typy adresów IP i metody alokacji na platformie Azure.

W przypadku maszyn wirtualnych z oprogramowaniem SAP HANA należy pracować z przypisanymi statycznymi adresami IP. Przyczyną jest to, że niektóre atrybuty konfiguracji dla adresów IP referencyjnych platformy HANA.

Sieciowe grupy zabezpieczeń platformy Azure służą do kierowania ruchu kierowanego do wystąpienia platformy SAP HANA lub serwera przesiadkowego. Sieciowe grupy zabezpieczeń i ostatecznie grupy zabezpieczeń aplikacji są skojarzone z podsiecią SAP HANA i podsiecią Zarządzania.

Aby wdrożyć platformę SAP HANA na platformie Azure bez połączenia typu lokacja-lokacja, nadal chcesz chronić wystąpienie platformy SAP HANA z publicznego Internetu i ukrywać je za serwerem proxy przekazywania dalej. W tym podstawowym scenariuszu wdrożenie opiera się na wbudowanych usługach DNS platformy Azure w celu rozpoznawania nazw hostów. W bardziej złożonym wdrożeniu, w którym są używane publiczne adresy IP, wbudowane usługi DNS platformy Azure są szczególnie ważne. Użyj sieciowych grup zabezpieczeń platformy Azure i urządzeń WUS platformy Azure do kontrolowania, monitorowania routingu z Internetu do architektury sieci wirtualnej platformy Azure na platformie Azure. Na poniższej ilustracji przedstawiono przybliżony schemat wdrażania platformy SAP HANA bez połączenia typu lokacja-lokacja w architekturze sieci wirtualnej piasty i szprych:

Przybliżony schemat wdrażania dla platformy SAP HANA bez połączenia typu lokacja-lokacja

Inny opis sposobu używania urządzeń WUS platformy Azure do kontrolowania i monitorowania dostępu z Internetu bez architektury sieci wirtualnej piasty i szprych można znaleźć w artykule Wdrażanie urządzeń wirtualnych sieciowych o wysokiej dostępności.

Opcje źródła zegara na maszynach wirtualnych platformy Azure

Platforma SAP HANA wymaga niezawodnych i dokładnych informacji o chronometrażu w celu optymalnego działania. Tradycyjnie maszyny wirtualne platformy Azure uruchomione na funkcji hypervisor platformy Azure używały tylko strony funkcji Hyper-V TSC jako domyślnego źródła zegara. Rozwój technologii w sprzęcie, systemie operacyjnym hosta i jądrach systemu operacyjnego gościa systemu operacyjnego Linux umożliwił zapewnienie "niezmiennej funkcji TSC" jako opcji źródła zegara w niektórych jednostkach SKU maszyn wirtualnych platformy Azure.

Strona TSC funkcji Hyper-V (hyperv_clocksource_tsc_page) jest obsługiwana na wszystkich maszynach wirtualnych platformy Azure jako źródło zegara. Jeśli podstawowy sprzęt, funkcja hypervisor i jądra systemu operacyjnego gościa systemu operacyjnego Linux obsługują niezmienną funkcję TSC, tsc będzie oferowana jako dostępne i obsługiwane źródło zegara w systemie operacyjnym gościa na maszynach wirtualnych platformy Azure.

Konfigurowanie infrastruktury platformy Azure dla rozwiązania SAP HANA skalowalnego w poziomie

Aby dowiedzieć się, jakie typy maszyn wirtualnych platformy Azure są certyfikowane dla skalowalnego w poziomie OLAP lub skalowalnego w poziomie S/4HANA, sprawdź katalog sprzętu sap HANA. Znacznik wyboru w kolumnie "Clustering" wskazuje obsługę skalowania w poziomie. Typ aplikacji wskazuje, czy jest obsługiwane skalowanie W poziomie OLAP, czy skalowanie W poziomie S/4HANA. Aby uzyskać szczegółowe informacje na temat węzłów certyfikowanych w skali w poziomie, zapoznaj się z wpisem dla określonej jednostki SKU maszyny wirtualnej wymienionej w katalogu sprzętowym sap HANA.

Minimalne wersje systemu operacyjnego do wdrażania konfiguracji skalowalnego w poziomie na maszynach wirtualnych platformy Azure można sprawdzić szczegóły wpisów w określonej jednostce SKU maszyny wirtualnej wymienionej w katalogu sprzętowym sap HANA. W przypadku konfiguracji skalowalnego w poziomie OLAP n-węzła jeden węzeł działa jako węzeł główny. Pozostałe węzły do limitu certyfikacji działają jako węzeł roboczy. Więcej węzłów rezerwowych nie jest wliczanych do liczby certyfikowanych węzłów

Uwaga

Wdrożenia maszyn wirtualnych platformy Azure skalowane w poziomie platformy SAP HANA z węzłem rezerwowym są możliwe tylko przy użyciu magazynu usługi Azure NetApp Files . Żaden inny certyfikowany magazyn platformy Azure SAP HANA nie zezwala na konfigurację węzłów rezerwowych sap HANA

W przypadku /hana/shared zalecamy użycie usługi Azure NetApp Files lub Azure Files.

Typowy podstawowy projekt pojedynczego węzła w konfiguracji skalowalnego w poziomie z /hana/shared wdrożonym w usłudze Azure NetApp Files wygląda następująco:

Diagram przedstawiający typowy podstawowy projekt pojedynczego węzła w konfiguracji skalowanej w poziomie.

Podstawowa konfiguracja węzła maszyny wirtualnej dla skalowalnego w poziomie platformy SAP HANA wygląda następująco:

  • W przypadku platformy /hana/shared należy użyć natywnej usługi NFS udostępnianej za pośrednictwem usługi Azure NetApp Files lub Azure Files.
  • Wszystkie inne woluminy dysków nie są współużytkowane przez różne węzły i nie są oparte na systemie plików NFS. Konfiguracje instalacji i kroki instalacji skalowalnego w poziomie platformy HANA z nieudostępnymi /hana/data i /hana/log są udostępniane w dalszej części tego dokumentu. Aby zapoznać się z certyfikowanym magazynem HANA, którego można użyć, zapoznaj się z artykułem Konfiguracje magazynu maszyn wirtualnych platformy Azure sap HANA.

Ustalanie rozmiaru woluminów lub dysków, należy sprawdzić dokument WYMAGANIA dotyczące magazynu SAP HANA CSV pod kątem wymaganego rozmiaru zależnego od liczby węzłów roboczych. Dokument zwalnia formułę, którą należy zastosować, aby uzyskać wymaganą pojemność woluminu

Inne kryteria projektowania wyświetlane w grafice konfiguracji pojedynczego węzła dla skalowanej w poziomie maszyny wirtualnej SAP HANA to sieć wirtualna lub lepsza konfiguracja podsieci. Rozwiązanie SAP zdecydowanie zaleca oddzielenie ruchu klienta/aplikacji przed komunikacją między węzłami platformy HANA. Jak pokazano na ilustracji, ten cel jest osiągany przez posiadanie dwóch różnych wirtualnych kart sieciowych dołączonych do maszyny wirtualnej. Obie wirtualne karty sieciowe znajdują się w różnych podsieciach, mają dwa różne adresy IP. Następnie możesz kontrolować przepływ ruchu przy użyciu reguł routingu przy użyciu sieciowych grup zabezpieczeń lub tras zdefiniowanych przez użytkownika.

Szczególnie na platformie Azure nie ma środków i metod wymuszania jakości usług i limitów przydziału dla określonych wirtualnych kart sieciowych. W związku z tym rozdzielenie komunikacji między klientami/aplikacjami i komunikacją wewnątrz węzła nie otwiera żadnych możliwości nadania priorytetowi jednego strumienia ruchu przez drugi. Zamiast tego separacja pozostaje środkiem zabezpieczeń w zabezpieczaniu komunikacji wewnątrzwęźle konfiguracji skalowanych w poziomie.

Uwaga

System SAP zaleca oddzielenie ruchu sieciowego do ruchu po stronie klienta/aplikacji i wewnątrz węzła zgodnie z opisem w tym dokumencie. W związku z tym zaleca się umieszczenie architektury, jak pokazano w ostatniej grafice. Zapoznaj się również z zespołem ds. zabezpieczeń i zgodności, aby uzyskać wymagania, które odbiegają od zalecenia

Z punktu widzenia sieci minimalna wymagana architektura sieci wyglądałaby następująco:

Podstawy skalowania w poziomie pojedynczego węzła

Instalowanie platformy SAP HANA skalowalnego w poziomie n platformy Azure

Instalowanie konfiguracji sap skalowalnego w poziomie, należy wykonać przybliżone kroki:

  • Wdrażanie nowej lub dostosowywanie istniejącej infrastruktury sieci wirtualnej platformy Azure
  • Wdrażanie nowych maszyn wirtualnych przy użyciu usługi Azure Managed Premium Storage, woluminów ultra disk i/lub woluminów NFS opartych na rozwiązaniu ANF
    • Dostosuj routing sieciowy, aby upewnić się, że na przykład komunikacja wewnątrzwęźle między maszynami wirtualnymi nie jest kierowana przez urządzenie WUS.
  • Zainstaluj główny węzeł SAP HANA.
  • Dostosowywanie parametrów konfiguracji węzła głównego platformy SAP HANA
  • Kontynuuj instalację węzłów roboczych sap HANA

Instalacja oprogramowania SAP HANA w konfiguracji skalowanej w poziomie

Podczas wdrażania infrastruktury maszyny wirtualnej platformy Azure i wszystkich innych przygotowań należy zainstalować konfiguracje skalowane w poziomie platformy SAP HANA w następujących krokach:

  • Zainstaluj główny węzeł SAP HANA zgodnie z dokumentacją oprogramowania SAP
  • W przypadku korzystania z usługi Azure Premium Storage lub magazynu w warstwie Ultra z dyskami /hana/data innych niż udostępnione i /hana/logdodaj parametr basepath_shared = no do global.ini pliku. Ten parametr umożliwia platformie SAP HANA uruchamianie w poziomie bez udostępniania /hana/data i /hana/log woluminów między węzłami. Szczegółowe informacje są udokumentowane w artykule SAP Note #2080991. Jeśli używasz woluminów NFS opartych na anf dla /hana/data i /hana/log, nie musisz wprowadzać tej zmiany
  • Po ewentualnej zmianie parametru global.ini uruchom ponownie wystąpienie SAP HANA
  • Dodaj więcej węzłów procesu roboczego. Aby uzyskać więcej informacji, zobacz Dodawanie hostów przy użyciu interfejsu wiersza polecenia. Określ sieć wewnętrzną dla komunikacji między węzłami sap HANA podczas instalacji lub później przy użyciu na przykład lokalnego narzędzia hdblcm. Aby uzyskać bardziej szczegółową dokumentację, zobacz sap Note #2183363.

Aby skonfigurować system sap HANA skalowalny w poziomie z węzłem rezerwowym, zobacz instrukcje wdrażania systemu SUSE Linux lub instrukcje wdrażania oprogramowania Red Hat.

Dynamiczne warstwy SAP HANA 2.0 dla maszyn wirtualnych platformy Azure

Oprócz certyfikatów platformy SAP HANA na maszynach wirtualnych z serii Azure M platforma SAP HANA Dynamic Tiering 2.0 jest również obsługiwana na platformie Microsoft Azure. Aby uzyskać więcej informacji, zobacz Linki do dokumentacji DT 2.0. Nie ma różnicy w instalowaniu lub obsłudze produktu. Możesz na przykład zainstalować kokpit PLATFORMy SAP HANA na maszynie wirtualnej platformy Azure. Istnieją jednak pewne obowiązkowe wymagania, zgodnie z opisem w poniższej sekcji, aby uzyskać oficjalną pomoc techniczną na platformie Azure. W całym artykule będzie używany skrót "DT 2.0" zamiast pełnej nazwy Dynamic Tiering 2.0.

Warstwa dynamiczna SAP HANA 2.0 nie jest obsługiwana przez oprogramowanie SAP BW ani S4HANA. Główne przypadki użycia są teraz natywnymi aplikacjami HANA.

Omówienie

Na poniższej ilustracji przedstawiono omówienie obsługi jednostek DT 2.0 na platformie Microsoft Azure. Istnieje zestaw obowiązkowych wymagań, które należy przestrzegać w celu spełnienia oficjalnego certyfikatu:

  • Jednostka DT 2.0 musi być zainstalowana na dedykowanej maszynie wirtualnej platformy Azure. Może nie działać na tej samej maszynie wirtualnej, na której działa oprogramowanie SAP HANA
  • Maszyny wirtualne SAP HANA i DT 2.0 muszą być wdrożone w tej samej sieci wirtualnej platformy Azure
  • Maszyny wirtualne SAP HANA i DT 2.0 muszą być wdrożone z włączoną przyspieszoną siecią platformy Azure
  • Typ magazynu dla maszyn wirtualnych DT 2.0 musi mieć wartość Azure Premium Storage
  • Wiele dysków platformy Azure musi być dołączonych do maszyny wirtualnej DT 2.0
  • Wymagane jest utworzenie nalotu oprogramowania /woluminu rozłożonego (za pośrednictwem lvm lub mdadm) przy użyciu usuwania na dyskach platformy Azure

Więcej szczegółów zostanie wyjaśnione w poniższych sekcjach.

Omówienie architektury OPROGRAMOWANIA SAP HANA DT 2.0

Dedykowana maszyna wirtualna platformy Azure dla oprogramowania SAP HANA DT 2.0

W usłudze Azure IaaS usługa DT 2.0 jest obsługiwana tylko na dedykowanej maszynie wirtualnej. Nie można uruchomić usługi DT 2.0 na tej samej maszynie wirtualnej platformy Azure, na której jest uruchomione wystąpienie platformy HANA. Początkowo dwa typy maszyn wirtualnych mogą służyć do uruchamiania rozwiązania SAP HANA DT 2.0:

  • M64-32ms
  • E32sv3

Aby uzyskać więcej informacji na temat opisu typu maszyny wirtualnej, zobacz Rozmiary maszyn wirtualnych platformy Azure — pamięć

Biorąc pod uwagę podstawową ideę dt 2.0, która polega na odciążaniu "ciepłych" danych w celu zaoszczędzenia kosztów, warto używać odpowiednich rozmiarów maszyn wirtualnych. Nie ma jednak ścisłej reguły dotyczącej możliwych kombinacji. Zależy to od konkretnego obciążenia klienta.

Zalecane konfiguracje to:

Typ maszyny wirtualnej SAP HANA Typ maszyny wirtualnej DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Możliwe są wszystkie kombinacje maszyn wirtualnych z serii M z certyfikowaną platformą SAP HANA z obsługiwanymi maszynami wirtualnymi DT 2.0 (M64-32ms i E32sv3).

Sieć platformy Azure i oprogramowanie SAP HANA DT 2.0

Zainstalowanie usługi DT 2.0 na dedykowanej maszynie wirtualnej wymaga przepływności sieci między maszyną wirtualną DT 2.0 a minimalną maszyną wirtualną SAP HANA wynoszącą 10 Gb. W związku z tym należy umieścić wszystkie maszyny wirtualne w tej samej sieci wirtualnej platformy Azure i włączyć przyspieszoną sieć platformy Azure.

Zobacz dodatkowe informacje o przyspieszonej sieci platformy Azure Tworzenie maszyny wirtualnej platformy Azure z przyspieszoną siecią przy użyciu interfejsu wiersza polecenia platformy Azure

Magazyn maszyn wirtualnych dla oprogramowania SAP HANA DT 2.0

Zgodnie ze wskazówkami dotyczącymi najlepszych rozwiązań dt 2.0 przepływność operacji we/wy dysku powinna wynosić co najmniej 50 MB/s na rdzeń fizyczny.

Zgodnie ze specyfikacjami dwóch typów maszyn wirtualnych platformy Azure obsługiwanych w przypadku jednostek DT 2.0 maksymalny limit przepływności operacji we/wy dysku dla maszyny wirtualnej wygląda następująco:

  • E32sv3: 768 MB/s (bez pamięci podręcznej), co oznacza stosunek 48 MB/s na rdzeń fizyczny
  • M64-32 ms: 1000 MB/s (bezcached), co oznacza stosunek 62,5 MB/s na rdzeń fizyczny

Wymagane jest dołączenie wielu dysków platformy Azure do maszyny wirtualnej DT 2.0 i utworzenie na poziomie systemu operacyjnego nalotu oprogramowania (usuwanie) w celu osiągnięcia maksymalnego limitu przepływności dysku na maszynę wirtualną. Pojedynczy dysk platformy Azure nie może zapewnić przepływności, aby osiągnąć maksymalny limit maszyny wirtualnej w tym zakresie. Usługa Azure Premium Storage jest obowiązkowa do uruchamiania jednostek DT 2.0.

W zależności od wymagań dotyczących rozmiaru istnieją różne opcje osiągnięcia maksymalnej przepływności maszyny wirtualnej. Poniżej przedstawiono możliwe konfiguracje dysków woluminu danych dla każdego typu maszyny wirtualnej DT 2.0 w celu osiągnięcia górnego limitu przepływności maszyny wirtualnej. Maszyna wirtualna E32sv3 powinna być traktowana jako poziom wejścia dla mniejszych obciążeń. Jeśli okaże się, że nie jest wystarczająco szybko, może być konieczne zmianę rozmiaru maszyny wirtualnej na M64-32 ms. Ponieważ maszyna wirtualna M64-32ms ma dużo pamięci, obciążenie we/wy może nie osiągnąć limitu szczególnie w przypadku obciążeń intensywnie korzystających z odczytu. W związku z tym mniejsza liczba dysków w zestawie pasków może być wystarczająca w zależności od obciążenia specyficznego dla klienta. Jednak aby mieć bezpieczną stronę, konfiguracje dysków poniżej zostały wybrane w celu zagwarantowania maksymalnej przepływności:

Jednostka SKU maszyny wirtualnej Konfiguracja dysku 1 Konfiguracja dysku 2 Konfiguracja dysku 3 Konfiguracja dysku 4 Konfiguracja dysku 5
M64-32ms 4 x P50 –> 16 TB 4 x P40 –> 8 TB 5 x P30 –> 5 TB 7 x P20 –> 3,5 TB 8 x P15 –> 2 TB
E32sv3 3 x P50 –> 12 TB 3 x P40 –> 6 TB 4 x P30 –> 4 TB 5 x P20 –> 2,5 TB 6 x P15 –> 1,5 TB

Szczególnie w przypadku, gdy obciążenie jest intensywne do odczytu, może zwiększyć wydajność operacji we/wy, aby włączyć pamięć podręczną hosta platformy Azure "tylko do odczytu" zgodnie z zaleceniami dotyczącymi woluminów danych oprogramowania bazy danych. Podczas gdy w dzienniku transakcji pamięć podręczna dysku hosta platformy Azure musi być "brak".

Jeśli chodzi o rozmiar woluminu dziennika, zalecany punkt początkowy jest heurystyczny 15% rozmiaru danych. Tworzenie woluminu dziennika można wykonać przy użyciu różnych typów dysków platformy Azure w zależności od wymagań dotyczących kosztów i przepływności. W przypadku woluminu dziennika wymagana jest wysoka przepływność we/wy.

W przypadku korzystania z maszyny wirtualnej typu M64-32ms należy włączyć akcelerator zapisu. Akcelerator zapisu platformy Azure zapewnia optymalne opóźnienie zapisu dysku dla dziennika transakcji (dostępne tylko dla serii M). Istnieje kilka elementów, które należy wziąć pod uwagę, choć jak maksymalna liczba dysków na typ maszyny wirtualnej. Szczegółowe informacje na temat akceleratora zapisu można znaleźć na stronie Akcelerator zapisu platformy Azure

Oto kilka przykładów dotyczących określania rozmiaru woluminu dziennika:

rozmiar woluminu danych i typ dysku wolumin dziennika i typ dysku config 1 wolumin dziennika i typ dysku 2
4 x P50 –> 16 TB 5 x P20 –> 2,5 TB 3 x P30 –> 3 TB
6 x P15 –> 1,5 TB 4 x P6 –> 256 GB 1 x P15 –> 256 GB

Podobnie jak w przypadku skalowania w poziomie platformy SAP HANA katalog /hana/shared musi być współużytkowany między maszyną wirtualną SAP HANA a maszyną wirtualną DT 2.0. Zalecana jest ta sama architektura co w przypadku skalowania w poziomie platformy SAP HANA przy użyciu dedykowanych maszyn wirtualnych, które działają jako serwer NFS o wysokiej dostępności. Aby zapewnić udostępniony wolumin kopii zapasowej, można użyć identycznego projektu. Jednak klient musi mieć wysoką dostępność lub wystarczy, aby po prostu użyć dedykowanej maszyny wirtualnej z wystarczającą pojemnością magazynu, aby działać jako serwer kopii zapasowych.

Operacje wdrażania oprogramowania SAP HANA na maszynach wirtualnych platformy Azure

W poniższych sekcjach opisano niektóre operacje związane z wdrażaniem systemów SAP HANA na maszynach wirtualnych platformy Azure.

Wykonywanie kopii zapasowych i przywracanie operacji na maszynach wirtualnych platformy Azure

W poniższych dokumentach opisano sposób tworzenia kopii zapasowych i przywracania wdrożenia oprogramowania SAP HANA:

Uruchamianie i ponowne uruchamianie maszyn wirtualnych zawierających oprogramowanie SAP HANA

Ważną funkcją chmury publicznej platformy Azure jest to, że opłaty są naliczane tylko za minuty obliczeniowe. Na przykład po zamknięciu maszyny wirtualnej z uruchomioną platformą SAP HANA opłaty są naliczane tylko za koszty magazynowania w tym czasie. Inna funkcja jest dostępna po określeniu statycznych adresów IP dla maszyn wirtualnych w początkowym wdrożeniu. Po ponownym uruchomieniu maszyny wirtualnej z platformą SAP HANA maszyna wirtualna zostanie ponownie uruchomiona przy użyciu poprzednich adresów IP.

Używanie programu SAProuter do obsługi zdalnej oprogramowania SAP

Jeśli masz połączenie lokacja-lokacja między lokalizacjami lokalnymi i platformą Azure, a korzystasz ze składników SAP, prawdopodobnie korzystasz już z programu SAProuter. W takim przypadku wykonaj następujące elementy w celu obsługi zdalnej:

  • Zachowaj prywatny i statyczny adres IP maszyny wirtualnej, która hostuje platformę SAP HANA w konfiguracji programu SAProuter.
  • Skonfiguruj sieciową grupę zabezpieczeń podsieci, która hostuje maszynę wirtualną HANA, aby zezwolić na ruch przez port TCP/IP 3299.

Jeśli łączysz się z platformą Azure za pośrednictwem Internetu i nie masz routera SAP dla maszyny wirtualnej z platformą SAP HANA, musisz zainstalować składnik. Zainstaluj program SAProuter na oddzielnej maszynie wirtualnej w podsieci Zarządzania. Na poniższej ilustracji przedstawiono przybliżony schemat wdrażania oprogramowania SAP HANA bez połączenia typu lokacja-lokacja i z programem SAProuter:

Przybliżony schemat wdrażania dla platformy SAP HANA bez połączenia lokacja-lokacja i programu SAProuter

Pamiętaj, aby zainstalować program SAProuter na oddzielnej maszynie wirtualnej, a nie na maszynie wirtualnej przesiadkowej. Oddzielna maszyna wirtualna musi mieć statyczny adres IP. Aby połączyć komputer SAProuter z programem SAProuter, który jest hostowany przez system SAP, skontaktuj się z systemem SAP w celu uzyskania adresu IP. (Komputer SAProuter, który jest hostowany przez system SAP, jest odpowiednikiem wystąpienia programu SAProuter instalowanego na maszynie wirtualnej). Użyj adresu IP z systemu SAP, aby skonfigurować wystąpienie programu SAProuter. W ustawieniach konfiguracji jedynym wymaganym portem jest port TCP 3299.

Aby uzyskać więcej informacji na temat konfigurowania i obsługi połączeń pomocy zdalnej za pośrednictwem programu SAProuter, zobacz dokumentację systemu SAP.

Wysoka dostępność z platformą SAP HANA na natywnych maszynach wirtualnych platformy Azure

Jeśli używasz systemu SUSE Linux Enterprise Server lub Red Hat, możesz ustanowić klaster Pacemaker z urządzeniami ogrodzeniowymi. Za pomocą urządzeń można skonfigurować konfigurację platformy SAP HANA korzystającą z replikacji synchronicznej z replikacją systemu HANA i automatycznym trybem failover. Aby uzyskać więcej informacji wymienionych w sekcji "następne kroki".

Następne kroki

Zapoznaj się z artykułami wymienionymi na liście