Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Za pomocą platformy Microsoft Azure możesz migrować istniejącą aplikację SAP działającą w systemie IBM Db2 dla systemów Linux, UNIX i Windows (LUW) na maszyny wirtualne platformy Azure. Dzięki oprogramowaniu SAP w systemie IBM Db2 dla systemu LUW administratorzy i deweloperzy mogą nadal korzystać z tych samych narzędzi programistycznych i administracyjnych, które są dostępne lokalnie. Ogólne informacje na temat uruchamiania pakietu SAP Business Suite w systemie IBM Db2 for LUW są dostępne za pośrednictwem programu SAP Community Network (SCN) w systemie SAP w systemie IBM Db2 dla systemów Linux, UNIX i Windows.
Aby uzyskać więcej informacji i aktualizacji dotyczących SAP on Db2 for LUW na platformie Azure, zobacz SAP Note 2233094.
Istnieją różne artykuły dotyczące obciążenia SAP na platformie Azure. Zalecamy rozpoczęcie pracy z oprogramowaniem SAP na maszynach wirtualnych platformy Azure, a następnie zapoznanie się z innymi interesującymi obszarami.
Następujące uwagi sap są powiązane z oprogramowaniem SAP na platformie Azure w odniesieniu do obszaru omówionego w tym dokumencie:
| Numer notatki | Tytuł |
|---|---|
| 1928533 | Aplikacje SAP na platformie Azure: obsługiwane produkty i typy maszyn wirtualnych platformy Azure |
| 2015553 | Oprogramowanie SAP na platformie Microsoft Azure: wymagania wstępne dotyczące pomocy technicznej |
| 1999351 | Rozwiązywanie problemów z rozszerzonym monitorowaniem platformy Azure dla oprogramowania SAP |
| 2178632 | Kluczowe metryki monitorowania oprogramowania SAP na platformie Microsoft Azure |
| 1409604 | Wirtualizacja w systemie Windows: rozszerzone monitorowanie |
| 2191498 | Oprogramowanie SAP w systemie Linux z platformą Azure: rozszerzone monitorowanie |
| 2233094 | DB6: Aplikacje SAP na platformie Azure przy użyciu systemu IBM DB2 dla systemów Linux, UNIX i Windows — dodatkowe informacje |
| 2243692 | Maszyna wirtualna z systemem Linux na platformie Microsoft Azure (IaaS): problemy z licencjami SAP |
| 1984787 | SUSE LINUX Enterprise Server 12: Informacje o instalacji |
| 2002167 | Red Hat Enterprise Linux 7.x: instalacja i uaktualnianie |
| 1597355 | Zalecenie dotyczące zamiany miejsca dla systemu Linux |
Przeczytaj wstępnie dokument Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Zagadnienia dotyczące wdrażania systemu DBMS usługi Azure Virtual Machines dla obciążenia SAP). Zapoznaj się z innymi przewodnikami podczas korzystania z obciążeń SAP na platformie Azure.
Obsługa wersji programu IBM Db2 dla systemów Linux, UNIX i Windows
Oprogramowanie SAP w systemie IBM Db2 for LUW w usługach Microsoft Azure Virtual Machine Services jest obsługiwane w wersji 10.5 bazy danych Db2.
Aby uzyskać informacje o obsługiwanych produktach SAP i typach maszyn wirtualnych platformy Azure, zapoznaj się z artykułem SAP Note 1928533.
Wytyczne dotyczące konfiguracji IBM Db2 dla systemów Linux, UNIX i Windows dla instalacji SAP na maszynach wirtualnych platformy Azure.
Konfiguracja usługi Storage
Aby zapoznać się z omówieniem typów magazynu platformy Azure dla obciążenia SAP, zapoznaj się z artykułem Typy usługi Azure Storage dla obciążenia SAP Wszystkie pliki bazy danych muszą być przechowywane na zainstalowanych dyskach magazynu blokowego platformy Azure (Windows: NTFS, Linux: xfs, obsługiwanych w wersji Db2 11.1 lub ext3).
Zdalne udostępnione woluminy, takie jak usługi platformy Azure w wymienionych scenariuszach, NIE są obsługiwane dla plików bazy danych Db2.
Usługa plików platformy Microsoft Azure dla wszystkich systemów operacyjnych dla gości.
Usługa Azure NetApp Files dla Db2 działającego w systemie operacyjnym gościa Windows.
Zdalne udostępnione woluminy, takie jak usługi platformy Azure w wymienionych scenariuszach, są obsługiwane w przypadku plików bazy danych Db2:
- Hostowanie danych Db2 i plików dziennika systemu operacyjnego gościa Linux na udziałach NFS hostowanych w usłudze Azure NetApp Files jest obsługiwane!
Jeśli używasz dysków opartych na usłudze Azure Page BLOB Storage lub zarządzanych dysków, instrukcje zawarte w temacie dotyczącym wdrażania systemu DBMS usługi Azure Virtual Machines dla obciążeń SAP mają zastosowanie również do wdrożeń z systemem Db2 DBMS (System Zarządzania Bazą Danych).
Jak wyjaśniono wcześniej w części ogólnej dokumentu, istnieją limity przydziału przepływności operacji we/wy na sekundę dla dysków platformy Azure. Dokładne przydziały zależą od używanego typu maszyny wirtualnej. Listę typów maszyn wirtualnych z ich przydziałami można znaleźć tutaj (Linux) i tutaj (Windows).
Jeśli bieżący limit przydziału operacji we/wy na sekundę na dysk jest wystarczający, można przechowywać wszystkie pliki bazy danych na jednym zainstalowanym dysku. Podczas gdy zawsze należy oddzielić pliki danych i pliki dziennika transakcji na różnych dyskach/dyskach VHD.
Aby zapoznać się z zagadnieniami dotyczącymi wydajności, zapoznaj się również z rozdziałem "Zagadnienia dotyczące bezpieczeństwa i wydajności danych dla katalogów baz danych" w przewodnikach instalacji oprogramowania SAP.
Alternatywnie, możesz użyć pul magazynów systemu Windows, które są dostępne tylko w systemie Windows Server 2012 i nowszych, zgodnie z opisem w Zagadnieniach dotyczących wdrażania DBMS na maszynach wirtualnych Azure dla obciążeń SAP. W systemie Linux można użyć lvm lub mdadm, aby utworzyć jedno duże urządzenie logiczne na wielu dyskach.
W przypadku maszyny wirtualnej z serii M na platformie Azure, przy użyciu Akceleratora Zapisów Azure, można znacznie zmniejszyć opóźnienia zapisu w dziennikach transakcji, w porównaniu z wydajnością magazynu Azure Premium. W związku z tym należy wdrożyć akcelerator zapisu platformy Azure dla co najmniej jednego dysku VHD tworzącego wolumin dzienników transakcji Db2. Szczegóły można odczytać w dokumencie Akcelerator zapisu.
IBM Db2 LUW 11.5 dodał wsparcie dla sektora o rozmiarze 4 KB. Chociaż należy włączyć użycie rozmiaru sektora 4 KB z wartością 11,5 przez ustawienie konfiguracji db2set DB2_4K_DEVICE_SUPPORT=ON, jak opisano w artykule:
W przypadku starszych wersji db2 należy użyć rozmiaru sektora 512 Bajtów. Dyski SSD w warstwie Premium mają natywną obsługę 4 KB i emulację 512-bajtową. Dysk Ultra domyślnie używa rozmiaru sektora 4 KB. Można włączyć rozmiar sektora 512 bajtów podczas tworzenia dysku Ultra. Szczegóły są dostępne używając ultra dysków Azure. Ten rozmiar sektora 512 Bajtów jest wymaganiem wstępnym dla wersji IBM Db2 LUW niższej niż 11.5.
W systemie Windows przy użyciu pul magazynu dla ścieżek magazynu Db2 dla log_dirkatalogów sapdata i saptmp należy określić rozmiar sektora dysku fizycznego o rozmiarze 512 bajtów. W przypadku korzystania z pul magazynów systemu Windows należy ręcznie utworzyć pule magazynów za pomocą interfejsu wiersza polecenia przy użyciu parametru -LogicalSectorSizeDefault. Aby uzyskać więcej informacji, zobacz New-StoragePool.
Zalecenie dotyczące maszyny wirtualnej i struktury dysków dla wdrożenia ibm Db2
Oprogramowanie IBM Db2 for SAP NetWeaver Applications jest obsługiwane na dowolnej maszynie wirtualnej wymienionej w uwagach dotyczących pomocy technicznej sap 1928533. Zalecane rodziny maszyn wirtualnych do uruchamiania bazy danych IBM Db2 to Esd_v4/Eas_v4/Es_v3 i seria M/M_v2 dla dużych baz danych wielobajtowych. Wydajność zapisu dysku dziennika transakcji IBM Db2 można poprawić, włączając akcelerator zapisu serii M.
Poniżej przedstawiono konfigurację bazową dla różnych rozmiarów i zastosowań oprogramowania SAP w przypadku wdrożeń Db2 od małych do bardzo dużych.
Ważne
Wymienione poniżej typy maszyn wirtualnych to przykłady spełniające kryteria procesorów wirtualnych i pamięci poszczególnych kategorii. Konfiguracja magazynu jest oparta na usłudze Azure Premium Storage w wersji 1. Dyski SSD w warstwie Premium w wersji 2 i dyski Azure Ultra są w pełni obsługiwane z bazą danych IBM Db2 i mogą być używane do wdrożeń. Użyj wartości pojemności, przepustowości szczytowej i liczby operacji we/wy na sekundę do zdefiniowania konfiguracji dysku Ultra Disk lub SSD Premium v2. Możesz ograniczyć operacje we/db2//log_dir na około 5000 operacji we/<SID>wy na sekundę. Dostosuj przepustowość i IOPS do określonego obciążenia, jeśli te zalecenia bazowe nie spełniają wymagań.
Bardzo mały system SAP: rozmiar bazy danych 50–200 GB: przykład Solution Manager
| Rozmiar maszyny wirtualnej / przykłady | Punkt instalacji Db2 | Dysk platformy Azure w warstwie Premium | Liczba dysków | IOPS (liczba operacji we/wy na sekundę) | Przez- przepustowość [MB/s] |
Rozmiar [GB] | Tymczasowe operacje we/wy na sekundę | Przebicie się włóż [GB] |
Rozmiar paska | Buforowanie |
|---|---|---|---|---|---|---|---|---|---|---|
| Procesor wirtualny: 4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| RAM: ~32 GiB | /db2/<SID>/sapdata |
P10 | 2 | 1000 | 200 | 256 | 7 000 | 340 | 256 KB |
Tylko do odczytu |
| E4(d)s_v5 | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3500 | 170 | ||
| E4(d)as_v5 | /db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 64 KB |
|
| ... | /db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3500 | 170 |
Mały system SAP: rozmiar bazy danych 200 – 750 GB: mały pakiet biznesowy
| Rozmiar maszyny wirtualnej / przykłady | Punkt instalacji Db2 | Dysk platformy Azure w warstwie Premium | Liczba dysków | Liczba operacji we/wy na sekundę | Przez- przepustowość [MB/s] |
Rozmiar [GB] | Operacje szczytowe we/wy na sekundę | Przesiąknięć włóż [GB] |
Rozmiar paska | Buforowanie |
|---|---|---|---|---|---|---|---|---|---|---|
| Procesor wirtualny: 16 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| RAM: ~128 GiB | /db2/<SID>/sapdata |
P15 | 100 | 4 400 | 500 | 1.024 | 14 000 | 680 | 256 KB | Tylko do odczytu |
| E16(d)s_v5 | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7 000 | 340 | 128 KB | |
| E16(d)as_v5 | /db2/<SID>/log_dir |
P15 | 2 | 2200 | 250 | 512 | 7 000 | 340 | 64 KB |
|
| ... | /db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3500 | 170 |
Średni system SAP: rozmiar bazy danych 500– 1000 GB: mały pakiet biznesowy
| Rozmiar maszyny wirtualnej / przykłady | Punkt instalacji Db2 | Dysk platformy Azure w warstwie Premium | Liczba dysków | Liczba operacji we/wy na sekundę | Przez- put [MB/s] |
Rozmiar [GB] | Operacje we/wy na sekundę | Przebij się umieść [GB] |
Rozmiar paska danych | Buforowanie |
|---|---|---|---|---|---|---|---|---|---|---|
| procesor wirtualny: 32 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| RAM: ~256 GiB | /db2/<SID>/sapdata |
P30 | 2 | 10,000 | 400 | 2.048 | 10,000 | 400 | 256 KB | Tylko do odczytu |
| E32(d)s_v5 | /db2/<SID>/saptmp |
P10 | 2 | 1000 | 200 | 256 | 7 000 | 340 | 128 KB | |
| E32(d)as_v5 | /db2/<SID>/log_dir |
P20 | 2 | 4 600 | 300 | 1.024 | 7 000 | 340 | 64 KB |
|
| M32ls | /db2/<SID>/offline_log_dir |
P15 | 1 | 1,100 | 125 | 256 | 3500 | 170 |
Duży system SAP: rozmiar bazy danych 750– 2000 GB: Business Suite
| Rozmiar maszyny wirtualnej / przykłady | Punkt instalacji Db2 | Dysk platformy Azure w warstwie Premium | Liczba dysków | IOPS | Przez- put [MB/s] |
Rozmiar [GB] | Operacje szczytowe we/wy na sekundę | Przesiąknięć put [GB] |
Rozmiar paska danych | Buforowanie |
|---|---|---|---|---|---|---|---|---|---|---|
| Procesor wirtualny: 64 | /db2 | P6 | 1 | 240 | 50 | 64 | 3500 | 170 | ||
| RAM: ~512 GiB | /db2/<SID>/sapdata |
P30 | 4 | 20,000 | 800 | 4.096 | 20,000 | 800 | 256 KB | Tylko do odczytu |
| E64(d)s_v5 | /db2/<SID>/saptmp |
P15 | 2 | 2200 | 250 | 512 | 7 000 | 340 | 128 KB | |
| E64(d)as_v5 | /db2/<SID>/log_dir |
P20 | 100 | 9,200 | 600 | 2.048 | 14 000 | 680 | 64 KB |
|
| M64ls | /db2/<SID>/offline_log_dir |
P20 | 1 | 2300 | 150 | 512 | 3500 | 170 |
Duży system SAP z wieloma terabajtami: rozmiar bazy danych 2 TB+: globalny system pakietu biznesowego
Szczególnie w przypadku takich większych systemów ważne jest, aby ocenić infrastrukturę, na którą jest obecnie uruchomiony system, oraz dane dotyczące zużycia zasobów tych systemów w celu znalezienia najlepszego dopasowania infrastruktury obliczeniowej i magazynu i konfiguracji platformy Azure.
| Nazwa/rozmiar maszyny wirtualnej | Punkt instalacji Db2 | Dysk platformy Azure w warstwie Premium | Liczba dysków | Liczba operacji we/wy na sekundę | Przez- prześlij [MB/s] |
Rozmiar [GB] | Operacje we/wy w trybie burst | Przebić się przez umieść [GB] |
Rozmiar paska danych | Keszowanie |
|---|---|---|---|---|---|---|---|---|---|---|
| procesor wirtualny: =>128 | /db2 | P10 | 1 | 500 | 100 | 128 | 3500 | 170 | ||
| Pamięć RAM: =>2048 GiB | /db2/<SID>/sapdata |
P40 | 100 | 30,000 | 1000 | 8.192 | 30,000 | 1000 | 256 KB | Tylko do odczytu |
| M128s_v2 | /db2/<SID>/saptmp |
P20 | 2 | 4 600 | 300 | 1.024 | 7 000 | 340 | 128 KB | |
| M176s_2_v3 | /db2/<SID>/log_dir |
P30 | 100 | 20,000 | 800 | 4.096 | 20,000 | 800 | 64 KB |
Pisać- Akcelerator |
| M176s_3_v3, M176s_4_v3 |
/db2/<SID>/offline_log_dir |
P30 | 1 | 5,000 | 200 | 1.024 | 5,000 | 200 |
Korzystanie z usługi Azure NetApp Files
Użycie woluminów NFS w wersji 4.1 opartych na Azure NetApp Files (ANF) jest obsługiwane w IBM Db2, hostowanym na systemie operacyjnym gościa Suse lub Red Hat Linux. Należy utworzyć co najmniej cztery różne woluminy, takie jak:
- Współdzielone woluminy: saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - Jeden wolumin danych dla sapdata1 do sapdatan
- Jeden wolumin dla katalogu dziennika redo
- Jeden wolumin dla archiwów dzienników i kopii zapasowych
Piąty potencjalny wolumin może być woluminem ANF, którego używasz do bardziej długoterminowych kopii zapasowych oraz do tworzenia migawek i przechowywania tych migawek w magazynie obiektów blob platformy Azure.
Konfiguracja może wyglądać następująco:
Warstwę wydajności i rozmiar woluminów hostowanych przez ANF należy wybrać w oparciu o wymagania dotyczące wydajności. Jednak zalecamy wybór poziomu wydajności Ultra dla woluminu danych i dziennika. Nie jest dozwolone mieszanie typów pamięci blokowej i pamięci współdzielonej dla wolumenów danych i dzienników.
W przypadku opcji montowania instalowanie tych woluminów może wyglądać następująco (należy zastąpić <SID> SID systemu SAP i <sid> SID systemu SAP):
vi /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt
Uwaga
Opcje montowania "hard" i "sync" są wymagane
Tworzenie/przywracanie kopii zapasowych
Funkcje tworzenia/przywracania kopii zapasowych dla systemu IBM Db2 dla LUW są obsługiwane w taki sam sposób jak w standardowych systemach operacyjnych Windows Server i funkcji Hyper-V.
Upewnij się, że masz prawidłową strategię tworzenia kopii zapasowych bazy danych.
Podobnie jak we wdrożeniach bez systemu operacyjnego wydajność tworzenia kopii zapasowych/przywracania zależy od tego, ile woluminów można odczytać równolegle i jaka może być przepływność tych woluminów. Ponadto użycie CPU spowodowane kompresją kopii zapasowych może odgrywać znaczącą rolę na maszynach wirtualnych z maksymalnie ośmioma wątkami. W związku z tym można założyć:
- Mniejsza liczba dysków używanych do przechowywania urządzeń bazy danych, tym mniejsza ogólna przepływność odczytu
- Mniejsza liczba wątków procesora CPU na maszynie wirtualnej, tym większy wpływ kompresji kopii zapasowej
- Im mniejsza liczba obiektów docelowych (katalogi stripe, dyski) do zapisu kopii zapasowej, tym niższa przepływność
Aby zwiększyć liczbę miejsc docelowych do zapisu, można użyć/połączyć dwie opcje w zależności od potrzeb:
- Paskowanie woluminu docelowego kopii zapasowej na wiele dysków w celu zwiększenia wydajności IOPS na tym woluminie rozłożonym.
- Zapisywanie kopii zapasowej przy użyciu więcej niż jednego katalogu docelowego
Uwaga
System Db2 w systemie Windows nie obsługuje technologii VSS systemu Windows. W związku z tym nie można wykorzystać spójnej na poziomie aplikacji kopii zapasowej maszyny wirtualnej usługi Azure Backup dla maszyn wirtualnych, w których jest wdrażana baza danych DBMS db2.
Wysoka dostępność i odzyskiwanie po awarii
Linux Pacemaker
Ważne
W przypadku bazy danych Db2 w wersji 11.5.6 lub nowszej zdecydowanie zalecamy rozwiązanie zintegrowane przy użyciu programu Pacemaker firmy IBM.
- Zintegrowane rozwiązanie przy użyciu narzędzia Pacemaker
- Obsługiwane są alternatywne lub dodatkowe konfiguracje dostępne w usłudze Microsoft Azure wysoka dostępność i odzyskiwanie po awarii (HADR) Db2 z programem pacemaker. Obsługiwane są systemy operacyjne SLES i RHEL. Ta konfiguracja umożliwia wysoką dostępność oprogramowania IBM Db2 dla systemu SAP. Przewodniki wdrażania:
- SLES: wysoka dostępność systemu IBM Db2 LUW na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server z programem Pacemaker
- RHEL: wysoka dostępność systemu IBM Db2 LUW na maszynach wirtualnych platformy Azure w systemie Red Hat Enterprise Linux Server
Windows Cluster Server
Klaster trybu failover systemu Windows Server (WSFC) znany również jako serwer klastra firmy Microsoft (MSCS) nie jest obsługiwany.
Odzyskiwanie po awarii o wysokiej dostępności (HADR) bazy danych Db2 jest obsługiwane. Jeśli maszyny wirtualne konfiguracji wysokiej dostępności mają działające rozpoznawanie nazw, konfiguracja na platformie Azure nie różni się od żadnej konfiguracji wykonywanej lokalnie. Nie zaleca się polegania tylko na rozpoznawaniu adresów IP.
Nie używaj replikacji geograficznej dla kont magazynowych, które przechowują dyski bazy danych. Aby uzyskać więcej informacji, zobacz dokument Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Zagadnienia dotyczące wdrażania systemu DBMS usługi Azure Virtual Machines dla obciążenia SAP).
Przyspieszona sieć
W przypadku wdrożeń Db2 w systemie Windows zdecydowanie zalecamy korzystanie z funkcji Przyspieszonej Sieci platformy Azure, zgodnie z opisem w dokumencie Przyspieszona Sieć Azure. Należy również wziąć pod uwagę zalecenia dotyczące zagadnień dotyczących wdrażania usługi AZURE Virtual Machines DBMS dla obciążenia SAP.
Specyfika wdrożeń systemu Linux
Jeśli bieżący limit IOPS na dysk jest wystarczający, można przechowywać wszystkie pliki bazy danych na jednym, pojedynczym dysku. Podczas gdy zawsze należy oddzielić pliki danych i pliki dziennika transakcji na różnych dyskach.
Jeśli IOPS lub przepustowość we/wy pojedynczego dysku VHD w Azure nie jest wystarczająca, możesz użyć LVM (Menedżera Woluminów Logiczych) lub MDADM zgodnie z opisem w dokumencie Zagadnienia dotyczące wdrożenia DBMS maszyn wirtualnych Azure dla obciążeń SAP w celu utworzenia jednego dużego urządzenia logicznego na wielu dyskach.
W przypadku dysków zawierających ścieżki magazynu Db2 dla katalogów sapdata i saptmp upewnij się, że używany jest rozmiar sektora dysku fizycznego o rozmiarze 4 KB. W przypadku tworzenia woluminu rozłożonego na wielu dyskach przy użyciu lvM lub MDADM należy skonfigurować rozmiar paska (lub rozmiar fragmentu) do 512 KB, aby zoptymalizować przepływność we/wy dla dużych obciążeń baz danych.
Inne
Wszystkie inne ogólne obszary, takie jak zestawy dostępności platformy Azure lub monitorowanie oprogramowania SAP, mają zastosowanie do wdrożeń maszyn wirtualnych z bazą danych IBM Database. Te ogólne obszary opisujemy w temacie Considerations for Azure Virtual Machines DBMS deployment for SAP workload (Zagadnienia dotyczące wdrażania DBMS na maszynach wirtualnych Azure dla obciążenia SAP).
Następne kroki
Przeczytaj artykuł: