Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Platforma Azure udostępnia różne typy magazynów, które są odpowiednie dla maszyn wirtualnych platformy Azure z uruchomionym oprogramowaniem SAP HANA. Certyfikowane przez SAP HANA typy magazynów Azure, które można uwzględnić do wdrożeń SAP HANA, to:
Aby dowiedzieć się więcej na temat tych typów przechowywania dla platformy SAP HANA, zobacz poszczególne artykuły i artykuł przeglądowy Azure Storage types for SAP workload (Typy usługi Azure Storage dla obciążenia SAP). Aby uzyskać listę rodzajów pamięci, ich SLA, IOPS oraz przepustowość, szczegóły znajdziesz w części Wybieranie typu dysku.
Certyfikowane minimalne warunki SAP HANA dla różnych rodzajów pamięci są opisane w każdym z dokumentów.
Ważne
Niezależnie od wybranego typu magazynu platformy Azure, system plików używany w tym magazynie musi być obsługiwany przez SAP dla określonego systemu operacyjnego i DBMS. Uwaga dotycząca obsługi oprogramowania SAP #2972496 zawiera listę obsługiwanych systemów plików dla różnych systemów operacyjnych i baz danych, w tym platformy SAP HANA. Dotyczy to wszystkich woluminów, do których SAP HANA może uzyskiwać dostęp w celu odczytu i zapisu dla dowolnego zadania. Podczas używania systemu plików NFS na platformie Azure z SAP HANA obowiązują dodatkowe ograniczenia dotyczące wersji NFS, jak opisano w dalszej części tego artykułu.
Na podstawie doświadczenia zdobytego od klientów zmieniliśmy obsługę łączenia różnych typów pamięci masowej między /hana/data i /hana/log. Obsługiwane jest łączenie użycia różnych magazynów blokowych platformy Azure, które są certyfikowane dla HANA i udziałów NFS opartych na usłudze Azure NetApp Files. Na przykład można umieścić /hana/data na dyskach SSD Premium w wersji 1 lub 2, a /hana/log na dyskach Ultra, aby uzyskać wymagane niskie opóźnienia. Jeśli używasz woluminu opartego na usłudze Azure NetApp Files dla /hana/data, wolumin /hana/log można również umieścić w jednym z certyfikowanych typów magazynu blokowego platformy Azure HANA. Używanie systemu plików NFS usługi Azure NetApp Files w przypadku jednego z woluminów (takich jak /hana/data) i dysków Azure SSD Premium v1/v2 lub Ultra dla innego woluminu (na przykład /hana/log) jest obsługiwane.
W środowisku lokalnym rzadko trzeba było dbać o podsystemy we/wy i ich możliwości. Przyczyną było to, że dostawca urządzenia musi upewnić się, że minimalne wymagania dotyczące magazynu są spełnione dla platformy SAP HANA. Podczas samodzielnego tworzenia infrastruktury platformy Azure należy pamiętać o niektórych z tych wymagań dotyczących oprogramowania SAP. Niektóre z minimalnych właściwości przepływności zalecanych przez system SAP to:
- Odczyt/zapis w /hana/logach z prędkością 250 MB/s przy rozmiarze operacji we/wy 1 MB
- Aktywność odczytu wynosząca co najmniej 400 MB/s dla /hana/data przy rozmiarach operacji 16 MB i 64 MB.
- Aktywność zapisu wynosząca co najmniej 250 MB/s dla /hana/data o rozmiarach 16 MB i 64 MB we/wy
Biorąc pod uwagę, że małe opóźnienie magazynu ma kluczowe znaczenie dla systemów DBMS, nawet w przypadku systemu DBMS, takiego jak SAP HANA, przechowywanie danych w pamięci. Ścieżka krytyczna w magazynie jest zwykle wokół zapisów dziennika transakcji systemów DBMS. Jednak także operacje, takie jak zapisywanie punktów przywracania lub ładowanie danych do pamięci po awarii, mogą być krytyczne. W związku z tym jest obowiązkowe korzystanie z dysków Azure Premium SSD v1/v2, Ultra disk lub Azure NetApp Files NFS dla woluminu /hana/data i /hana/log.
Poniżej przedstawiono pewne wytyczne dotyczące wybierania konfiguracji magazynu dla platformy HANA:
- Zdecyduj o typie magazynu na podstawie typów usługi Azure Storage dla obciążenia SAP i Wybierz typ dysku
- Ogólna przepływność we/wy maszyny wirtualnej i limity IOPS należy uwzględnić podczas określania rozmiaru lub podejmowania decyzji o maszynie wirtualnej. Ogólna przepływność magazynu maszyn wirtualnych jest udokumentowana w artykule Rozmiary maszyn wirtualnych zoptymalizowane pod kątem pamięci
- Podczas podejmowania decyzji o konfiguracji magazynu spróbuj zachować niższą ogólną przepływność maszyny wirtualnej przy użyciu konfiguracji woluminu /hana/data . Zapisywanie punktów kontrolnych na platformie SAP HANA może wiązać się z intensywnym wykonywaniem operacji we/wy. Łatwo jest osiągnąć limity przepływności woluminu /hana/data podczas zapisywania punktu zapisu. Jeśli dyski, które tworzą wolumin /hana/data, mają wyższą przepustowość niż pozwala na to maszyna wirtualna, możesz napotkać sytuacje, w których przepustowość wykorzystywana przez zapisywanie punktu kontrolnego zakłóca zapotrzebowanie na przepustowość zapisów dziennika przywracania. Sytuacja, która może mieć wpływ na przepływność aplikacji
- Jeśli rozważasz użycie replikacji systemu HANA, magazyn używany dla /hana/data w każdej replice musi być taki sam, a typ magazynu używany dla /hana/log w każdej replice musi być taki sam. Użycie Azure Premium SSD v1 dla /hana/data z jedną maszyną wirtualną oraz Azure Ultra Disk dla /hana/data na innej maszynie wirtualnej uruchamiającej replikę tej samej konfiguracji systemu HANA nie jest obsługiwane.
Ważne
Sugestie dotyczące konfiguracji magazynu w tych lub kolejnych dokumentach są przeznaczone jako wskazówki na początek. Podczas działania obciążeń roboczych i analizy wzorców wykorzystania pamięci masowej, możesz zauważyć, że nie wykorzystujesz w pełni przepustowości pamięci masowej ani liczby operacji we/wy na sekundę (IOPS). Możesz rozważyć zmniejszenie przestrzeni magazynowej. Z drugiej strony, Twoje obciążenie pracą może wymagać większej przepustowości pamięci masowej niż sugerują te konfiguracje. W rezultacie może być konieczne wdrożenie większej pojemności, większej liczby operacji we/wy na sekundę (IOPS) lub większej przepływności. W zrównoważeniu między wymaganą pojemnością magazynu, wymaganym opóźnieniem dostępu do magazynu, przepustowością magazynu, liczbą operacji we/wy na sekundę oraz najmniej kosztowną konfiguracją, platforma Azure oferuje wystarczającą liczbę różnych typów magazynu z różnymi możliwościami i różnymi punktami cenowymi, aby znaleźć i dostosować się do odpowiedniego kompromisu dla Ciebie i obciążenia powodowanego przez HANA.
Zestawy stripe i partycjonowanie woluminów danych SAP HANA
Przy użyciu dysków Azure Premium SSD v1 można osiągnąć najlepszy stosunek ceny do wydajności, gdy paskujesz wolumen /hana/data oraz/lub /hana/log na wielu dyskach Azure. Zamiast wdrażać większe woluminy dysków, które zapewniają więcej operacji we/wy na sekundę lub wymaganą przepływność. Tworzenie pojedynczego woluminu na wielu dyskach platformy Azure można wykonać za pomocą menedżerów woluminów LVM i MDADM, które są częścią systemu Linux. Metoda rozbierania dysków jest od dziesięcioleci i dobrze znana. Mimo że te woluminy paskowane są korzystne dla uzyskania wymaganej liczby operacji we/wy na sekundę lub przepustowości, dodają one również złożoności do zarządzania tymi woluminami. Szczególnie w przypadkach, gdy woluminy muszą być rozszerzone w pojemności. Co najmniej w przypadku /hana/data, SAP wprowadził alternatywną metodę, która osiąga ten sam cel co paskowanie na wielu dyskach Azure. Ponieważ platforma SAP HANA 2.0 SPS03, serwer indeksowania platformy HANA może usunąć swoje działanie we/wy w wielu plikach danych platformy HANA, które znajdują się na różnych dyskach platformy Azure. Zaletą jest to, że nie trzeba zajmować się tworzeniem woluminu rozłożonego i zarządzaniem nim na różnych dyskach platformy Azure. Funkcjonalność partycjonowania woluminów danych w SAP HANA jest szczegółowo opisana w:
- Przewodnik administratora platformy HANA
- Blog na temat platformy SAP HANA — partycjonowanie woluminów danych
- Uwaga SAP #2400005
- Uwaga SAP #2700123
Czytając szczegółowe informacje, widać, że zastosowanie tej funkcji eliminuje złożoność zestawów paskowych opartych na menedżerze woluminów. Zdajesz sobie również sprawę, że partycjonowanie woluminu danych platformy HANA nie tylko działa w przypadku magazynu blokowego platformy Azure, takiego jak dyski SSD Premium w wersji 1/2. Tej funkcji można również używać do usuwania między udziałami NFS w przypadku, gdy te udziały mają ograniczenia liczby operacji we/wy na sekundę lub przepływności.
Tryb harmonogramu we/wy systemu Linux
System Linux ma kilka różnych trybów planowania we/wy. Typowym zaleceniem od dostawców systemów Linux i SAP jest ponowna konfiguracja trybu planisty I/O dla woluminów dysków z trybu mq-deadline lub kyber na tryb noop (bez wielu kolejek) lub none (wielowychodowy). Jeśli nie zostało to jeszcze zrobione przez profile saptune SLES. Szczegóły są przywołyne w:
W systemie Red Hat pozostaw ustawienia określone przez określone profile dostrajania dla różnych aplikacji SAP.
Rozmiary pasm przy użyciu menedżerów woluminów logicznych
Jeśli używasz LVM lub mdadm do tworzenia zestawów paskowych na kilku dyskach Azure Premium, musisz zdefiniować rozmiary pasków. Te rozmiary różnią się między /hana/data i /hana/log. Zalecenie: W miarę rozmiarów rozbieranych zaleca się użycie następującego polecenia:
- 256 KB dla /hana/data
- 64 KB dla /hana/log
Uwaga
Rozmiar paska dla /hana/data został zmieniony z wcześniejszych zaleceń, które mówiły o 64 KB lub 128 KB, na 256 KB w oparciu o doświadczenia klientów z nowszymi wersjami systemu Linux. Rozmiar 256 KB zapewnia nieco lepszą wydajność. Zmieniliśmy również zalecenie dotyczące rozmiarów paska /hana/log z 32 KB do 64 KB, aby uzyskać wystarczającą przepływność z większymi rozmiarami operacji we/wy.
Uwaga
Nie musisz konfigurować żadnego poziomu nadmiarowości przy użyciu woluminów RAID, ponieważ magazyn blokowy platformy Azure przechowuje trzy obrazy wirtualnego dysku twardego. Użycie zestawu paskowego z dysków Premium Azure polega wyłącznie na konfigurowaniu woluminów zapewniających wystarczające IOPS i/lub przepustowość I/O.
Gromadzenie wielu dysków platformy Azure pod zestawem pasków jest kumulacyjne po stronie liczby operacji we/wy na sekundę i przepływności magazynu. Dlatego jeśli umieścisz pasek ustawiony na 3 x P30 dysków SSD w warstwie Premium platformy Azure w wersji 1, powinno to dać trzy razy większą liczbę operacji we/wy na sekundę i trzy razy przepływność magazynu pojedynczego dysku P30.
Ważne
Jeśli używasz menedżera woluminów LVM lub mdadm do tworzenia zestawów stripe na wielu dyskach premium platformy Azure, trzy systemy plików SAP HANA /data, /log i /shared nie mogą być umieszczane w domyślnej lub głównej grupie woluminów. Zdecydowanie zalecamy stosowanie się do wskazówek dostawców systemu Linux, które zwykle służą do tworzenia poszczególnych grup woluminów dla /data, /log i /shared.
Zagadnienia dotyczące udostępnionego systemu plików HANA
Podczas określania rozmiaru systemów plików HANA większość uwagi dotyczy systemów HANA danych i plików dziennika. Jednak /hana/shared odgrywa również ważną rolę w obsłudze stabilnego systemu HANA, ponieważ hostuje podstawowe składniki, takie jak pliki binarne HANA.
Jeśli /hana/shared jest niewymiarowe, może zostać przesycone operacjami we/wy z powodu nadmiernych operacji odczytu/zapisu — na przykład podczas zapisywania dużego zrzutu, intensywnego śledzenia lub gdy kopia zapasowa jest zapisywana do systemu plików /hana/shared. Opóźnienie może również wzrosnąć.
Jeśli system HANA jest w konfiguracji wysokiej dostępności, opóźnione reakcje ze wspólnego systemu plików, tj. /hana/shared, mogą powodować przekroczenia limitu czasu zasobów klastra. Te przekroczenia limitu czasu mogą prowadzić do niepotrzebnych przełączeń awaryjnych, ponieważ agenci zasobów HANA mogą niepoprawnie zakładać, że baza danych jest niedostępna.
Wytyczne SAP dotyczące zalecanych rozmiarów dla /hana/shared:
| Objętość | Zalecany rozmiar |
|---|---|
| /hana/współdzielone zwiększanie zasobów | Min(1 TB, 1 x RAM) |
| /hana/shared rozszerzenie skalowalności | 1 x pamięci RAM węzła roboczego na cztery węzły robocze |
Aby uzyskać więcej informacji, zapoznaj się z następującymi uwagami dotyczącymi oprogramowania SAP:
3288971 — często zadawane pytania: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager w środowiskach replikacji systemu SAP HANA
1999930 — często zadawane pytania: analiza I/O SAP HANA
Najlepszym rozwiązaniem jest rozmiar /hana/shared , aby uniknąć wąskich gardeł wydajności. Należy pamiętać, że odpowiednio dobrany /hana/współdzielony system plików przyczynia się do stabilności i niezawodności systemu SAP HANA, zwłaszcza w scenariuszach wysokiej dostępności.
Konfiguracje Azure Premium SSD v1 dla HANA
Aby uzyskać szczegółowe zalecenia dotyczące konfiguracji magazynu HANA przy użyciu dysków SSD Premium platformy Azure w wersji 1, zapoznaj się z dokumentem Konfiguracje magazynu SSD Premium platformy Azure SAP HANA.
Konfiguracje usługi Azure Premium SSD w wersji 2 dla platformy HANA
Aby uzyskać szczegółowe zalecenia dotyczące konfiguracji magazynu HANA korzystające z magazynu Azure Premium SSD v2, zapoznaj się z dokumentem Konfiguracje magazynu SAP HANA Azure vm Premium SSD v2.
Konfiguracja magazynu dyskowego Ultra Disk na platformie Azure dla SAP HANA
Aby uzyskać szczegółowe zalecenia dotyczące konfiguracji magazynu HANA przy użyciu Azure Ultra Disk, zapoznaj się z dokumentem Konfiguracje magazynu Ultra Disk na maszynie wirtualnej Azure SAP HANA.
Woluminy NFS w wersji 4.1 w usłudze Azure NetApp Files
Aby uzyskać szczegółowe informacje na temat usługi Azure NetApp Files for HANA, przeczytaj dokument NFS v4.1 volumes on Azure NetApp Files for SAP HANA (Woluminy NFS w wersji 4.1 w usłudze Azure NetApp Files dla platformy SAP HANA).
Następne kroki
Aby uzyskać więcej informacji, zobacz:
- Konfiguracje magazynu SSD Premium dla maszyn wirtualnych Azure SAP HANA.
- Konfiguracje magazynu Ultra Disk w maszynach wirtualnych Azure SAP HANA.
- Woluminy NFS w wersji 4.1 w usłudze Azure NetApp Files dla platformy SAP HANA.
- Przewodnik dotyczący wysokiej dostępności oprogramowania SAP HANA dla maszyn wirtualnych platformy Azure.