Uwagi dotyczące wydajności magazynu danych Azure VMware Solution dla Azure NetApp Files

Ten artykuł przedstawia uwagi dotyczące wydajności związane z projektowaniem i rozmiarem magazynu danych rozwiązania Azure VMware w przypadku użycia z plikami Azure NetApp Files. Ta treść ma zastosowanie do administratora wirtualizacji, architekta chmury lub architekta pamięci masowej.

Rozważania przedstawione w tym artykule pomagają osiągnąć najwyższe poziomy wydajności aplikacji przy zoptymalizowanej efektywności kosztowej.

Azure NetApp Files zapewnia natychmiast skalowalną, wysokowydajną i niezwykle niezawodną usługę przechowywania danych dla rozwiązania Azure VMware. Testy obejmowały różne konfiguracje pomiędzy Azure VMware Solution a Azure NetApp Files. Testy były w stanie osiągnąć przepustowość ponad 10,500 MiB/s oraz ponad 585,000 operacji wejścia/wyjścia na sekundę (IOPS) przy użyciu tylko czterech hostów Azure VMware Solution/ESXi oraz pojedynczej puli pojemności Azure NetApp Files.

Osiąganie wyższej wydajności magazynowania dla rozwiązania Azure VMware dzięki wykorzystaniu Azure NetApp Files

Provisioning wielu, potencjalnie większych, magazynów danych na jednym poziomie usługowym może kosztować mniej, oferując jednocześnie zwiększoną wydajność. Przyczyną jest rozłożenie obciążenia między wiele strumieni TCP z hostów Azure VMware Solution do kilku magazynów danych. Możesz użyć magazynu danych Azure NetApp Files dla kalkulatora TCO rozwiązania Azure VMware, aby obliczyć potencjalne oszczędności kosztów poprzez przesłanie raportu RVTools lub ręczne wprowadzenie średniej wielkości maszyn wirtualnych.

Gdy określasz, jak skonfigurować magazyny danych, najprostszym rozwiązaniem z perspektywy zarządzania jest stworzenie pojedynczego magazynu danych Azure NetApp Files, zamontowanie go i umieszczenie w nim wszystkich swoich maszyn wirtualnych. Strategia ta działa dobrze w wielu sytuacjach, aż do momentu, gdy wymagane jest większe przepustowość lub IOPS. Aby zidentyfikować różne granice, testy używały syntetycznego generatora obciążeń, programu fio, aby ocenić zakres obciążeń dla każdego z tych scenariuszy. Analiza ta może pomóc w określeniu, jak zarządzać wolumenami Azure NetApp Files jako repozytoriami danych, aby maksymalizować wydajność oraz optymalizować koszty.

Zanim zaczniesz

Aby uzyskać dane dotyczące wydajności Azure NetApp Files, zobacz:

Azure NetApp Files: jak najlepiej wykorzystać magazyn w chmurze

Na hoście usługi Azure VMware Solution ustanawia się pojedyncze połączenie sieciowe dla każdego magazynu danych NFS, podobnie jak przy użyciu nconnect=1 w testach Linux, o których mowa w Sekcji 6 (Opcje optymalizacji). Fakt ten jest kluczowy dla zrozumienia, jak rozwiązanie Azure VMware zwiększa wydajność w wielu magazynach danych.
Wydajność benchmarków danych Azure NetApp Files dla rozwiązania Azure VMware

Metodologia testów

Ta sekcja opisuje metodologię używaną w testach.

Scenariusze testowe i iteracje

To testowanie stosuje metodologię "czterech narożników", która obejmuje zarówno operacje odczytu, jak i zapisu dla każdego sekwencyjnego i losowego wejścia/wyjścia (IO). Zmienne testów obejmują obsługę wielu hostów Azure VMware Solution, magazyny danych Azure NetApp Files, maszyny wirtualne (na host), oraz dyski maszyn wirtualnych (VMDKs) na maszynę wirtualną. Wybrane zostały następujące punkty skali, aby znaleźć maksymalną przepustowość i IOPS dla podanych scenariuszy.

Skalowanie plików VMDK, z których każdy znajduje się na własnym magazynie danych dla pojedynczej maszyny wirtualnej.
Skalowanie liczby maszyn wirtualnych na hosta w jednym magazynie Azure NetApp Files.
Liczba hostów Azure VMware Solution, z których każdy posiada jedną maszynę wirtualną, dzielącą jeden zbiór danych Azure NetApp Files.
Skalowanie liczby magazynów plików Azure NetApp, z których każdy zawiera jeden VMDK równomiernie rozłożony na hostach rozwiązania Azure VMware Solution.

Testowanie operacji zarówno małych, jak i dużych bloków oraz iteracja przez sekwencyjne i losowe obciążenia zapewnia testowanie wszystkich komponentów w stosach obliczeniowych, magazynowych i sieciowych aż do "krawędzi". Aby pokryć cztery rogi wielkością bloków i losowaniem, stosowane są następujące powszechne kombinacje:

64 KB testy sekwencyjne
- Obciążenia związane z przesyłaniem strumieniowym dużych plików zazwyczaj operują na dużych rozmiarach bloków, a także jest to domyślny rozmiar rozciągłości MSSQL.
- Testy dużych bloków zazwyczaj generują największą przepustowość (w MiB/s).
Losowe testy 8 KB
- To ustawienie jest powszechnie używanym rozmiarem bloku dla oprogramowania baz danych, w tym oprogramowania od Microsoft, Oracle i PostgreSQL.
- Testy małych bloków typowo generują największą liczbę IOPS.

Uwaga

Ten artykuł dotyczy jedynie testowania Azure NetApp Files. Nie obejmuje pamięci masowej vSAN uwzględnionej w rozwiązaniu Azure VMware.

Szczegóły środowiska

Wyniki w tym artykule zostały osiągnięte przy użyciu następującej konfiguracji środowiska:

Hosty usługi Azure VMware Solution
- Rozmiar: AV36
- Liczba hostów: 4
- VMware ESXi w wersji 7u3
Połączenie z chmurą prywatną Azure VMware Solution: Brama UltraPerformance z FastPath.
Gościnne maszyny wirtualne
- System operacyjny: Ubuntu 20.04
- Procesory/pamięć: 16 procesorów wirtualnych / 64 GB pamięci
- Wirtualny kontroler LSI SAS SCSI z dyskiem systemowym 16 GB na magazynie danych vSAN Azure VMware Solution
- Kontroler SCSI Parawirtualny dla testowych VMDK-ów
- Konfiguracje LVM/dysków
  - Jeden fizyczny wolumin na dysk
  - Jedna grupa woluminów na wolumin fizyczny
  - Jedna partycja logiczna na grupę woluminów
  - Jeden system plików XFS na partycję logiczną
Protokół Azure VMware Solution do usługi Azure NetApp Files: NFS w wersji 3
Generator obciążenia: fio wersja 3.16
Fio skrypty: fio-parser

Wyniki testów

Ta sekcja opisuje wyniki przeprowadzonych testów.

Single-VM skalowanie

Podczas konfigurowania pamięci, prezentowanej przez magazyn danych na maszynie wirtualnej Azure VMware Solution, należy wziąć pod uwagę wpływ układu systemu plików. Konfigurowanie wielu plików VMDK rozmieszczonych w różnych zasobach danych zapewnia najwyższą dostępną przepustowość. Konfigurowanie dysków VMDK w trybie jeden-do-wielu umieszczonych na jednym magazynie danych zapewnia maksymalną prostotę, jeśli chodzi o kopie zapasowe i operacje DR (disaster recovery), ale kosztem niższego maksymalnego poziomu wydajności. Dane empiryczne przedstawione w tym artykule pomagają w podejmowaniu decyzji.

Aby zmaksymalizować wydajność, często zwiększa się skalę pojedynczej maszyny wirtualnej (VM) na kilka dysków wirtualnych (VMDK) i rozmieszcza te dyski na różnych magazynach danych. Pojedyncza maszyna wirtualna (VM) z jednym lub dwoma plikami VMDK może być ograniczana przez jedną pamięć masową NFS, ponieważ jest zamontowana za pomocą jednego połączenia TCP do danego hosta usługi Azure VMware Solution.

Na przykład, inżynierowie często konfigurują VMDK na log bazy danych, a następnie przydzielają od jednego do wielu VMDK dla plików bazy danych. Mając wiele VMDK, istnieją dwie opcje. Pierwszą opcją jest użycie każdego VDMK jako osobnego systemu plików. Drugą opcją jest użycie narzędzia do zarządzania przechowywaniem, takiego jak LVM, MSSQL Filegroups lub Oracle ASM, aby zoptymalizować rozdział operacji wejścia-wyjścia (IO) poprzez striping na wielu VMDK-ach. Kiedy VMDK są używane jako indywidualne systemy plików, rozdzielanie obciążeń między wieloma magazynami danych wymaga ręcznego wysiłku i może być kłopotliwe. Używanie narzędzi do zarządzania pamięcią masową w celu rozprzestrzenienia plików na VMDK umożliwia skalowalność obciążenia.

Jeśli paskujesz wolumeny na wielu dyskach, upewnij się, że oprogramowanie do tworzenia kopii zapasowych lub oprogramowanie do odzyskiwania po awarii obsługuje tworzenie kopii zapasowych wielu wirtualnych dysków jednocześnie. Gdy pojedyncze zapisy są rozproszone na wielu dyskach, system plików musi zapewnić, że dyski są „zamrożone” podczas operacji tworzenia migawki lub kopii zapasowej. Większość nowoczesnych systemów plików zawiera operacje zamrażania lub snapshotów, takie jak xfs (xfs_freeze) oraz NTFS (kopie woluminów w tle), z których może korzystać oprogramowanie do tworzenia kopii zapasowych.

Aby zrozumieć, jak dobrze pojedyncza maszyna wirtualna Azure VMware Solution skaluję się przy dodawaniu większej liczby wirtualnych dysków, przeprowadzono testy z jednym, dwoma, czterema i ośmioma magazynami danych (każdy z nich zawierał pojedynczy plik VMDK). Diagram pokazuje pojedynczy dysk, który średnio osiąga około 73 040 IOPS (skalując od 100% zapisu / 0% odczytu do 0% zapisu / 100% odczytu). Gdy test ten został zwiększony do dwóch dysków, wydajność wzrosła o 75,8% do 128,420 IOPS. Zwiększenie liczby dysków do czterech zaczęło pokazywać malejące korzyści w porównaniu do tego, co pojedyncza maszyna wirtualna, skonfigurowana zgodnie z testem, mogła osiągnąć. Zaobserwowane maksymalne IOPS wynosiły 147 000 IOPS przy 100% losowych odczytach.

Jedno-hostowe skalowanie – Jedno magazyn danych

Słabo się skalowuje zwiększenie liczby maszyn wirtualnych obsługujących IO do pojedynczego magazynu danych z jednego hosta. Ten fakt wynika z pojedynczego przepływu sieciowego. Gdy osiągnięta zostaje maksymalna wydajność dla danego obciążenia, często wynika to z użycia pojedynczej kolejki na drodze do pojedynczego zasobu magazynu NFS hosta za pośrednictwem jednego połączenia TCP. Używając bloku o rozmiarze 8 KB, całkowita liczba operacji we/wy (IOPS) wzrosła o 3% do 16% przy skalowaniu z jednej maszyny wirtualnej (VM) z pojedynczym VMDK do czterech maszyn wirtualnych z łączną liczbą 16 VMDK (cztery na każdą maszynę, wszystkie na jednym magazynie danych).

Zwiększenie rozmiaru bloku (do 64 KB) dla obciążeń z dużymi blokami dało porównywalne wyniki, osiągając szczytową wydajność 2148 MiB/s (pojedyncza maszyna wirtualna, pojedynczy VMDK) i 2138 MiB/s (4 maszyny wirtualne, 16 VMDK).

Skalowanie jednokomputerowe – Wiele magazynów danych

W kontekście pojedynczego hosta rozwiązania Azure VMware, podczas gdy pojedynczy magazyn danych pozwalał maszynom wirtualnym generować około 76,000 IOPS, rozłożenie obciążeń na dwa magazyny danych zwiększyło całkowitą przepustowość średnio o 76%. Przejście z dwóch magazynów danych do czterech spowodowało wzrost o 163% (w porównaniu z jednym magazynem danych, wzrost o 49% z dwóch do czterech), jak pokazano na poniższym diagramie. Mimo że nadal występowały poprawy wydajności, dalsze zwiększanie liczby ponad ośmiu magazynów danych pokazywało malejące korzyści.

Skalowanie wielu hostów – Pojedyncza baza danych

Pojedyncza baza danych z pojedynczego hosta osiągnęła przepustowość ponad 2000 MiB/s w sekwencyjnym transferze danych o rozmiarze 64 KB. Rozdzielenie tego samego obciążenia roboczego na wszystkie cztery hosty przyniosło szczytowy wzrost o 135%, osiągając ponad 5000 MiB/s. Ten wynik prawdopodobnie stanowi górną granicę przepustowości wydajności pojedynczej jednostki Azure NetApp Files.

Zmniejszenie wielkości bloku z 64 KB do 8 KB i ponowne uruchomienie tych samych iteracji spowodowało, że cztery maszyny wirtualne wygenerowały 195 000 IOPS, jak pokazano na poniższym diagramie. Wydajność rośnie wraz ze wzrostem liczby hostów i liczby magazynów danych, ponieważ wzrasta liczba przepływów sieciowych. Wydajność rośnie poprzez skalowanie liczby hostów pomnożonej przez liczbę magazynów danych, ponieważ liczba przepływów sieciowych jest funkcją ilości hostów razy magazyny danych.

Skalowanie wielogospodarzowe – Wiele magazynów danych

Pojedynczy magazyn danych z czterema maszynami wirtualnymi rozmieszczonymi na czterech hostach wygenerował ponad 5000 MiB/s sekwencyjnego 64-KB wejścia/wyjścia. Dla bardziej wymagających obciążeń każda maszyna wirtualna (VM) jest przenoszona do dedykowanego magazynu danych, co łącznie daje ponad 10 500 MiB/s, jak pokazano na poniższym diagramie.

Dla obciążeń losowych z małymi blokami, pojedynczy magazyn danych wygenerował 195 000 losowych operacji IOPS o wielkości 8 KB. Skalowanie do czterech magazynów danych dało ponad 530,000 losowych operacji IOPS na 8K.

Implikacje i rekomendacje

W tej sekcji omawiane są przyczyny, dla których rozproszenie maszyn wirtualnych (VM) na kilku różnych magazynach danych przynosi znaczące korzyści wydajnościowe.

Jak pokazano w wynikach testów, możliwości wydajnościowe Azure NetApp Files są znaczne.

Testy pokazują, że jeden magazyn danych może zapewnić średnio ~148,980 8-KB IOPS lub ~4147 MiB/s przy 64-KB IOPS (średnia z wszystkich testów zapis%/odczyt%) w konfiguracji czterech hostów.
Jedna maszyna wirtualna na jednym magazynie danych –
- Jeśli masz poszczególne maszyny wirtualne (VM), które mogą potrzebować więcej niż ~75 tys. 8-KB IOPS lub ponad ~1700 MiB/s, rozłóż systemy plików na wiele VMDK, aby zwiększyć wydajność pamięci masowej VM.
Jedna maszyna wirtualna na wielu magazynach danych – Jedna maszyna wirtualna na 8 magazynach danych osiągnęła do ~147 000 operacji IOPS o rozmiarze 8 KB lub ~2786 MiB/s przy rozmiarze bloku 64 KB.
Jeden host - Każdy host był w stanie obsłużyć średnio ~198,060 operacji IOPS 8-KB lub ~2351 MiB/s, jeśli użyjesz co najmniej 4 maszyn wirtualnych na hosta z co najmniej 4 magazynami danych Azure NetApp Files. Masz możliwość zrównoważenia provisioningu wystarczającej liczby magazynów danych dla maksymalnej, potencjalnie eksplodującej wydajności w porównaniu do złożoności zarządzania i kosztów.

Rekomendacje

Gdy wydajność pojedynczego magazynu danych jest niewystarczająca, rozłóż swoje maszyny wirtualne na wiele magazynów danych, aby jeszcze bardziej zwiększyć skalę. Prostota jest często najlepsza, ale wydajność i skalowalność mogą uzasadniać dodaną, ale ograniczoną złożoność.

Cztery magazyny danych Azure NetApp Files zapewniają do 10 GB/s użytecznej przepustowości dla dużych sekwencyjnych operacji wejścia-wyjścia lub możliwość obsługi do 500 tys. operacji losowych IOPS przy rozmiarze 8K. Chociaż jedna baza danych może wystarczyć dla wielu potrzeb związanych z wydajnością, dla najlepszej wydajności zaleca się rozpoczęcie od co najmniej czterech baz danych.

W celu precyzyjnego dostrajania wydajności systemy operacyjne uruchomione na maszynach wirtualnych działające zarówno na Windows, jak i Linux umożliwiają rozłożenie danych na wielu dyskach. W związku z tym powinieneś rozproszyć systemy plików na wiele VMDK rozłożonych na różnych magazynach danych. Jednakże, jeśli spójność migawek aplikacji jest problemem i nie można go rozwiązać za pomocą LVM lub przestrzeni dyskowych, rozważ zamontowanie plików Azure NetApp z systemu operacyjnego gościa lub zbadanie skalowania na poziomie aplikacji, w przypadku czego Azure oferuje wiele świetnych opcji.

Jeśli paskujesz wolumeny na wielu dyskach, upewnij się, że oprogramowanie do tworzenia kopii zapasowych lub oprogramowanie do odzyskiwania po awarii obsługuje tworzenie kopii zapasowych wielu wirtualnych dysków jednocześnie. Ponieważ pojedyncze operacje zapisu są rozłożone na wiele dysków, system plików musi zapewnić, że dyski są "zamrożone" podczas operacji tworzenia migawki lub kopii zapasowej. Większość nowoczesnych systemów plików zawiera operację zamrażania lub tworzenia migawki, jak na przykład xfs (xfs_freeze) oraz NTFS (kopie woluminowe), z której mogą korzystać programy do tworzenia kopii zapasowych.

Ponieważ Azure NetApp Files nalicza opłaty za zarezerwowaną pojemność na poziomie puli pojemności, a nie za przydzieloną pojemność (datastory), na przykład zapłacisz tyle samo za 4x20TB datastory, co za 20x4TB datastorów. Jeśli zajdzie taka potrzeba, możesz dostosować pojemność i wydajność magazynów danych na żądanie, dynamicznie za pomocą API/konsoli Azure.

Na przykład, zbliżając się do końca roku fiskalnego, stwierdzasz, że potrzebujesz większej wydajności magazynowania na Standard datastore. Możesz zwiększyć poziom usług magazynów danych na miesiąc, aby umożliwić wszystkim maszynom wirtualnym na tych magazynach lepszą wydajność, jednocześnie utrzymując niższy poziom usług dla pozostałych magazynów danych. Nie tylko oszczędzasz na kosztach, ale także zyskujesz lepszą wydajność, rozpraszając obciążenia pomiędzy większą liczbą połączeń TCP między każdym magazynem danych a każdym hostem AVS.

Możesz monitorować metryki swojego magazynu danych za pomocą vCenter Server lub za pomocą interfejsu API/konsoli Azure. Korzystając z vCenter Server, możesz monitorować średnie skumulowane IOPS pamięci masowej w Wykresach zaawansowanych/Performance, pod warunkiem że włączysz zbieranie metryk Storage IO Control na pamięci masowej. Azure API i konsola przedstawiają metryki dla WriteIops, ReadIops, ReadThroughput, i WriteThroughput oraz innych, aby mierzyć obciążenia na poziomie magazynu danych. Dzięki metrykom Azure można ustawić zasady alertów z działaniami, które automatycznie zmieniają rozmiar magazynu danych za pomocą funkcji Azure, webhooku lub innych działań.

Następne kroki

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-18