Udostępnij za pośrednictwem

Konfiguracje infrastruktury SAP HANA i operacje na platformie Azure

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 SAP HANA w architekturze scale-out 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:

Łą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 korzystać z maszyn wirtualnych platformy Azure w scenariuszach produkcyjnych, sprawdź, czy certyfikowane maszyny wirtualne SAP HANA znajdują się na opublikowanej przez SAP liście Certified IaaS Platforms.

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

  • Portal Azure.
  • Polecenia cmdlet programu Azure PowerShell.
  • Azure CLI

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 wirtualnej sieci Azure, gospodarującą również wystąpieniami 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

Z powodów funkcjonalności, ale co ważniejsze, z powodów wydajności, nie jest wspierane konfigurowanie wirtualnych urządzeń sieciowych Azure w ścieżce komunikacji między aplikacją SAP a warstwą DBMS systemu opartego na SAP NetWeaver, Hybris lub S/4HANA. Komunikacja między warstwą aplikacji SAP a warstwą DBMS musi być bezpośrednia. Ograniczenie nie obejmuje reguł ASG i NSG usługi Azure, o ile reguły te 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 NVAs w ścieżkach komunikacyjnych mogą łatwo podwoić opóźnienie sieci między dwoma partnerami komunikacyjnymi i mogą ograniczać przepustowość w krytycznych ścieżkach między warstwą aplikacji SAP a warstwą DBMS. W niektórych scenariuszach zaobserwowanych u klientów, wirtualne urządzenia sieciowe (NVA) mogą spowodować awarię klastrów Pacemaker w systemie Linux w przypadkach, gdy węzły klastra muszą komunikować się z urządzeniem SBD za pośrednictwem NVA.

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ą połączone relacją peeringu. 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 do różnych sieci wirtualnych, dwie sieci wirtualne muszą być połączone. Należy pamiętać, że ruch sieciowy między dwiema równorzędnymi sieciami wirtualnymi platformy Azure jest związany z kosztami 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ą.
Również przypisujesz statyczne prywatne adresy IP dla obu wdrożonych wirtualnych kart sieciowych.

Uwaga

Statyczne adresy IP należy przypisać za pośrednictwem platformy Azure do poszczególnych vNICów. 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ć jej wiele wirtualnych kart sieciowych.

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 VNet Azure, która łączy się ze środowiskiem lokalnym, do oddzielnej sieci wirtualnej Azure. Ta oddzielna sieć wirtualna powinna obsługiwać cały ruch wychodzący do lokalnej lub do internetu. Takie podejście umożliwia wdrażanie oprogramowania do audytowania i rejestrowania ruchu, który wchodzi 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 sieciowy przepływający między siecią wirtualną hub a siecią wirtualną spoke przy użyciu komunikacji równorzędnej Azure VNet wiąże się z dodatkowymi kosztami. Na podstawie tych kosztów może być konieczne rozważenie kompromisów pomiędzy uruchomieniem ścisłej architektury typu piasta i szprychy a uruchomieniem wielu bram usługi Azure ExpressRoute, które można połączyć z 'szprychami', aby obejść sąsiedztwo sieci VNet. 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. W zależności od kosztów wymiany danych poprzez peering sieci VNet z jednej strony oraz kosztów związanych z dodatkowymi bramami Azure ExpressRoute i dodatkowymi licencjami na oprogramowanie, możesz zdecydować o mikrosegmentacji w ramach jednej sieci VNet, używając podsieci jako jednostki izolacyjnej zamiast sieci VNet.

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 platformy HANA odnoszą się do adresów IP.

Grupy zabezpieczeń sieciowych Azure (NSG) są używane do kierowania ruchu do instancji SAP HANA lub serwera przesiadkowego. Grupy zabezpieczeń sieci, a ostatecznie grupy zabezpieczeń aplikacji, są skojarzone z podsiecią SAP HANA i podsiecią zarządzania.

Aby wdrożyć SAP HANA na platformie Azure bez połączenia typu lokacja-lokacja, nadal chcesz chronić wystąpienie SAP HANA przed publicznym internetem i ukryć je za serwerem proxy. 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 wirtualnych urządzeń sieciowych (NVA) platformy Azure do kontrolowania i monitorowania routingu z Internetu do architektury sieci wirtualnej platformy 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ń NVA platformy Azure do kontrolowania i monitorowania dostępu z Internetu bez architektury VNet w modelu piasty i szprych można znaleźć w artykule Wdrażanie wysoce dostępnych sieciowych urządzeń wirtualnych.

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

Platforma SAP HANA wymaga niezawodnych i dokładnych informacji o czasie w celu optymalnego działania. Tradycyjnie maszyny wirtualne platformy Azure uruchomione na hypervisorze platformy Azure używały tylko strony 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 systemu Hyper-V (hyperv_clocksource_tsc_page) jest obsługiwana we wszystkich maszynach wirtualnych na platformie Azure jako źródło zegara. Jeśli podstawowy sprzęt, hypervisor i jądro systemu Linux w systemie operacyjnym gościa obsługują Invariant TSC, tsc będzie oferowane jako dostępne i obsługiwane źródło zegara w systemie operacyjnym gościa na maszynach wirtualnych platformy Azure.

Konfigurowanie infrastruktury Azure dla SAP HANA skalowania poziomego

Aby dowiedzieć się, jakie typy maszyn wirtualnych platformy Azure są certyfikowane dla rozproszonego OLAP lub rozproszonego 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 pod kątem skalowalności poziomej, zapoznaj się z wpisem dla określonego 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 konfiguracji skalowalnej w poziomie OLAP z n węzłami, jeden z nich 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 do skalowania horyzontalnego systemu SAP HANA z węzłem rezerwowym są możliwe tylko przy użyciu magazynu usługi Azure NetApp Files. Żaden inny certyfikowany magazyn 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 skalowania poziomego 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 i kroki instalacji dla instalacji HANA opartych na skalowaniu poziomym z niewspółdzielonymi /hana/data i /hana/log są przedstawione dalej w tym dokumencie. Aby zapoznać się z certyfikowaną pamięcią masową HANA, którą można wykorzystać, zapoznaj się z artykułem Konfiguracje pamięci masowej maszyn wirtualnych Azure SAP HANA.

Aby określić rozmiar woluminów lub dysków, należy sprawdzić dokument SAP HANA TDI Storage Requirements w celu ustalenia wymaganego rozmiaru zależnie od liczby węzłów roboczych. Dokument przedstawia formułę, którą należy zastosować, aby uzyskać wymaganą pojemność objętości.

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. SAP zdecydowanie zaleca oddzielenie ruchu klienta/aplikacji od komunikacji między węzłami 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 sieciowego za pomocą reguł routingu, korzystając z sieciowych grup zabezpieczeń (NSG) 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 bezpieczeństwa w zabezpieczaniu wewnętrznej komunikacji między węzłami w konfiguracjach poziomego skalowania.

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. Skonsultuj 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:

Skalowanie pojedynczego węzła: podstawy

Instalowanie SAP HANA w konfiguracji scale-out w Azure

Podczas instalowania skalowanej w poziomie konfiguracji SAP, należy wykonać bieżące 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 pomiędzy maszynami wirtualnymi w ramach jednego węzła nie jest kierowana przez urządzenie NVA.
  • Zainstaluj główny węzeł SAP HANA.
  • Dostosowywanie parametrów konfiguracji węzła głównego platformy SAP HANA
  • Kontynuuj proces instalacji tych węzłów roboczych SAP HANA

Instalacja oprogramowania SAP HANA w konfiguracji rozproszonej

Po wdrożeniu infrastruktury maszyn wirtualnych Azure i po zakończeniu wszystkich innych przygotowań, należy zainstalować konfiguracje rozproszone SAP HANA w następujących krokach:

  • Zainstaluj główny węzeł SAP HANA zgodnie z dokumentacją oprogramowania SAP
  • W przypadku korzystania z Azure Premium Storage lub pamięci masowej Ultra z nieudostępnionymi dyskami /hana/data i /hana/log, dodaj parametr basepath_shared = no do pliku global.ini. Ten parametr umożliwia platformie SAP HANA uruchamianie w architekturze rozproszonej bez współdzielenia woluminów /hana/data i /hana/log 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 roboczych. 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 ustawić system SAP HANA rozproszony z węzłem rezerwowym, zobacz instrukcje wdrażania SUSE Linux lub instrukcje wdrażania Red Hat.

SAP HANA Dynamic Tiering 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 SAP HANA wewnątrz maszyny wirtualnej 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 SAP HANA Dynamic Tiering 2.0 nie jest obsługiwana przez oprogramowanie SAP BW ani SAP S/4HANA. Obecne główne przypadki użycia dotyczą natywnych aplikacji HANA.

Omówienie

Na poniższej ilustracji przedstawiono przegląd obsługi 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 VM DT 2.0 musi być Azure Premium Storage
  • Wiele dysków platformy Azure musi być dołączonych do maszyny wirtualnej DT 2.0
  • Wymagane jest utworzenie macierzy RAID programowej lub paskowanego woluminu (za pośrednictwem lvm lub mdadm) przy użyciu paskowania na dyskach 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

Pamięć maszyn wirtualnych dla 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 (niezbuforowane), co oznacza przepustowość 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 uruchomienia 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 (I/O) może nie osiągnąć limitu, szczególnie w przypadku obciążeń skupiających się na odczycie. 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. Dla pewności wybrano poniższe konfiguracje dysków, aby zagwarantować maksymalną przepustowość.

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 charakteryzuje się dużą ilością odczytów, można zwiększyć wydajność operacji we/wy, włączając pamięć podręczną hosta platformy Azure w trybie "tylko do odczytu", co jest zalecane dla woluminów danych oprogramowania bazy danych. Natomiast dla dziennika transakcji pamięć podręczna dysku hosta platformy Azure musi być ustawiona na "brak".

Jeśli chodzi o rozmiar woluminu dziennika, zalecany punkt początkowy to zastosowanie heurystyki 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 Write Accelerator można znaleźć na stronie Write Accelerator 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 konfiguracja woluminu dziennika i typu 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 skalowalności poziomej 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. To klient decyduje, czy wysoka dostępność jest konieczna, czy wystarczy po prostu użyć dedykowanej maszyny wirtualnej z wystarczającą pojemnością magazynu, aby działał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 typu Jumpbox. 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. (SAProuter hostowany przez SAP jest odpowiednikiem instancji SAProuter, którą instalujesz na swojej maszynie wirtualnej). Użyj adresu IP od SAP, aby skonfigurować swoje wystąpienie 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, przejdź do sekcji „następne kroki”.

Następne kroki

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