Migracja lokalnego wystąpienia programu SQL Server do maszyny wirtualnej platformy Azure jest powszechną metodą migracji na platformę Azure. Specjaliści IT są zaznajomieni z określaniem rozmiaru maszyn wirtualnych w odniesieniu do procesora wirtualnego, pamięci i pojemności pamięci masowej. Firma Microsoft oferuje wiele typów i rozmiarów maszyn wirtualnych na potrzeby organizacji. Zobaczysz typy oznaczone jako Family w witrynie Azure Portal podczas ustalania rozmiaru maszyny wirtualnej.
Typy i rozmiary maszyn wirtualnych
Microsoft pomógł uprościć rzeczy, tworząc wiele typów maszyn wirtualnych. Typy są nastawione na definiowanie maszyn według celu. Różne typy to:
- Ogólnego przeznaczenia – zrównoważony stosunek procesora do pamięci, małe i średnie bazy danych
- Zoptymalizowany pod kątem obliczeń — wysoki stosunek procesora do pamięci, serwery WWW o średnim ruchu i serwery aplikacji
- Optymalizacja pamięci — wysoki stosunek pamięci do procesora, serwery relacyjnych baz danych, średnie i duże pamięci podręczne oraz analizy w pamięci
- Zoptymalizowana pamięć masowa – Wysoka przepustowość dysku i IO
- GPU – intensywne renderowanie grafiki i edycja wideo
- Wysoka wydajność obliczeniowa – najszybsze i najpotężniejsze maszyny wirtualne z procesorem
W każdym typie/rodzinie istnieje wiele rozmiarów do wyboru. Rozmiary oferują opcje dotyczące liczby procesorów wirtualnych, pamięci RAM i dysków z danymi. Liczba dysków z danymi określi maksymalną liczbę IOPS (IOPS oznacza operacje wejścia/wyjścia na sekundę), a całkowity rozmiar określi ilość dostępnej pamięci tymczasowej. Niektóre rozmiary obsługują również magazyn premium, który powinien być wymagany w przypadku produkcyjnego serwera SQL.
Opcje obrazu maszyny wirtualnej
Wybierając obraz dla SQL Server, masz kilka opcji. Możesz wybrać tylko system operacyjny, taki jak Linux lub Windows, lub możesz wybrać obraz z już zainstalowanym systemem operacyjnym i SQL Server. Obecnie wolę wybrać obraz z samym systemem operacyjnym, aby móc zainstalować SQL Server i skonfigurować go tak, jak lubię. Po wybraniu obrazu galerii z preinstalowanym programem SQL Server wszystkie składniki zawarte w ISO dla tej wersji są instalowane i nie zawsze potrzebuję zainstalowanych usług Integration Services lub Analysis Services.
Zagadnienia dotyczące rozmiaru maszyny wirtualnej
Wybór maszyny wirtualnej platformy Azure może wydawać się prosty przy wyborze rozmiaru na podstawie liczby procesorów wirtualnych, pamięci i wystarczającej ilości miejsca do przechowywania baz danych, jednak widzę, że klienci mają problemy z wydajnością związane z przechowywaniem. Powszechną tendencją jest wybieranie maszyny wirtualnej opartej wyłącznie na procesorze wirtualnym, pamięci i pojemności pamięci masowej bez porównywania aktualnych wymagań we/wy i przepustowości. Podczas tworzenia maszyny wirtualnej platformy Azure w witrynie Azure Portal możesz filtrować opcje na podstawie następujących czynności:
- Rozmiar
- Pokolenie
- Rodzina
- RAM/pamięć
- Obsługa magazynu Premium
- Liczba procesorów wirtualnych
- Tymczasowy dysk systemu operacyjnego
Po wybraniu opcji filtrowania, jeśli takie istnieją, zobaczysz listę dostępnych serwerów. Na liście wyświetla rozmiar maszyny wirtualnej, ofertę, rodzinę, procesor wirtualny, pamięć RAM, liczbę obsługiwanych dysków z danymi, maksymalną liczbę operacji we/wy na sekundę, magazyn tymczasowy (D:), jeśli dysk premium jest obsługiwany, oraz szacowany koszt. Odfiltrowałem następujące elementy na obsługiwanym dysku premium i rozmiarze zaczynającym się od litery E w celu optymalizacji pamięci.
To, co nie jest jednak wyświetlane, to wielkość przepustowości dozwolona na maszynę wirtualną. Przepustowość mierzy szybkość przesyłania danych do iz nośnika pamięci w megabajtach na sekundę.
Wydajność można obliczyć za pomocą następującego wzoru
MB/s =IOPS * KB na IO / 1024
Używając tej formuły, KB na IO będzie rozmiarem Twojego bloku. Jeśli formatujesz dyski z danymi i dziennikami na 64 KB, wzór dla maszyn wirtualnych E2s_v3, E4-2s_v3 i E8-2s_v3 z 3200, 6400 i 12800 IOPS będzie wyglądał następująco:
MB/s =3200 * 64/1024 lub 200 MB/s
MB/s =6400 * 64/1024 lub 400 MB/s
MB/s =12800 * 64/1024 lub 800 MB/s
Obliczenia przepustowości oparte na IOPS każdej maszyny wirtualnej z rozmiarem bloku 64k nie są złe. Te liczby nie uwzględniają żadnych kar za zapis RAID. Przetestowałem każdą z tych maszyn wirtualnych za pomocą CrystalDiskMark. Liczby, które uzyskałem dla przepustowości, nie były nawet zbliżone do szacunków.
Test porównawczy
Udostępniłem trzy maszyny wirtualne z tej samej rodziny, jednak o różnych rozmiarach, a każda z 2 vCPU. Specyfikacje maszyn wirtualnych były następujące:
- E2s_v3 – 2 vCPU – 16 GB RAM – 3200 IOPS – Obsługa do 4 dysków z danymi
- E4-2s_v3 – 2 vCPU – 32 GB RAM – 6400 IOPS – Obsługa do 8 dysków z danymi
- E8-2s_v3 – 2 vCPU – 64 GB RAM – 12 800 IOPS – Obsługa do 16 dysków z danymi
- Dysk danych P60 — Premium SSD — 16 000 IOPS
Na każdej maszynie wirtualnej udostępniłem dysk premium P60 o pojemności 8 TB. Ten dysk reklamował 16 000 IOPS, które przy rozmiarze bloku 64 KB mogą obsługiwać przepustowość 1000 MB/s, jednak dokumentacja platformy Azure stwierdza, że dysk zapewnia przepustowość 500 MB/s.
CrystalDiskMark to narzędzie do testowania dysków typu open source dla systemu Windows i jest oparte na narzędziu Diskspd firmy Microsoft. Narzędzie mierzy sekwencyjną i losową wydajność odczytów i zapisów.
W górnej części narzędzia znajduje się kilka rozwijanych menu. Liczba 5 to liczba iteracji testu, który zostanie wykonany. Dalej jest 1GiB, to jest rozmiar pliku testowego. W prawdziwym teście produkcyjnym powinno to być wystarczająco duże, aby uniknąć trafienia do pamięci podręcznej. Wersja 7.0 obsługuje plik do 64 GiB. Ostatni to dysk, na którym chcesz przeprowadzić test.
Po dokonaniu wyboru możesz kliknąć Wszystkie, aby rozpocząć serię testów. Test przejdzie przez różne sekwencyjne i losowe operacje odczytu/zapisu. Zachowaj ostrożność, jeśli planujesz testować rzeczywiste serwery produkcyjne. Ten test obciąża dysk i może drastycznie wpłynąć na obciążenie produkcyjne. Preferowane byłyby po godzinach lub podczas przerwy konserwacyjnej.
Zdecydowałem się przeprowadzić 5 iteracji testu z plikiem 32 GiB na dysku P60, który był dyskiem E:.
Maszyna wirtualna E2s_v3 osiągnęła maksymalnie 50 MB/s, czyli znacznie mniej niż 200 MB, które obliczyliśmy.
Maszyna wirtualna E4-2s_v3 osiągnęła maksymalną prędkość poniżej 100 MB/s, a nie 400 MB/s.
Maszyna wirtualna E8-2s_v3 osiągnęła maksymalnie 200 MB/s, a nie szacowane 800 MB/s.
Dlaczego niższa przepustowość?
Opierając się na moich wcześniejszych obliczeniach, 3200 IOPS przy rozmiarze bloku 64k powinno generować przepustowość 200 MB, ale nie widziałem podobnych liczb, dopóki nie miałem dysku 16 000 IOPS na maszynie wirtualnej, która obsługuje do 12 800 IOPS. Uzasadnienie jest takie, że każdy rozmiar maszyny wirtualnej ma limit przepustowości. Jeśli spojrzysz na dokumentację rodziny maszyn wirtualnych zoptymalizowanych pod kątem pamięci, zobaczysz, że maksymalna przepustowość dysku bez pamięci podręcznej E2s wynosi 3200 IOPS /48 MB/s, maksymalna przepustowość dysku bez pamięci podręcznej E4s wynosi 6400 IOPS/96 MB/s, a maksymalna przepustowość dysku bez pamięci podręcznej E8s przepustowość wynosi 12 800 IOPS / 192 Mb/s. Liczby te pokrywają się z wynikami, które uzyskałem za pomocą CrystalDiskMark.
Nawet jeśli możesz przydzielić bardzo duże dyski, które mają dużo IOPS i obsługują wysoką przepustowość, rozmiar maszyny wirtualnej może bardzo dobrze ograniczać przepustowość.
Analiza porównawcza bieżących potrzeb w zakresie przepustowości powinna być priorytetem przed migracją dowolnego obciążenia SQL Server na platformę Azure.
Wniosek
Rozumiem, że IOPS jest jednostką miary, którą zapewniają producenci dysków i dostawcy pamięci masowej, i to jest w porządku. Jednak jeśli chodzi o testowanie pamięci masowej, bardziej skupiamy się na wartościach przepustowości. To tylko problem matematyczny, ale jeśli nie zajmujesz się testowaniem pamięci masowej i wykonywaniem obliczeń od IOPS do przepustowości w oparciu o rozmiar bloku, może to być mylące.
Martwi mnie fakt, że ograniczenie przepustowości nie jest jasne po wybraniu rozmiaru maszyny wirtualnej. Jednostką miary we/wy magazynu jest IOPS. Przy 3200 IOPS i rozmiarze bloku 64k mogłem mieć około 200 MB/s, jednak moja maszyna wirtualna była ograniczona do 48 MB/s. Wielu specjalistów IT odkryło, że ma problemy z wydajnością dysku i przeskalowało swoją pamięć masową do większego i szybszego dysku (więcej IOPS), oczekując lepszej wydajności, ale okazało się, że nie rozwiązało to ich problemu. Problem polega na tym, że rozmiar maszyny wirtualnej ograniczał ich przepustowość. Skalowanie do większego rozmiaru maszyny wirtualnej rozwiązałoby problem, ale wiąże się to z kosztami. W moim przykładzie E4 był dwukrotnie droższy od E2, jednak podwoił pamięć i przepustowość, zachowując ten sam vCPU. E8 był dwukrotnie droższy od E4 i podwoił przepustowość i pamięć, zachowując ten sam vCPU. Utrzymanie tej samej liczby vCPU oznacza, że nie zwiększyłbym kosztu podstawowej licencji SQL Server.
Ostatecznie musisz przeprowadzić test porównawczy swoich bieżących wymagań dotyczących przepustowości i upewnić się, że rozmiar maszyny wirtualnej platformy Azure lub dowolnej maszyny wirtualnej jest odpowiedni do Twoich potrzeb. Nie koncentruj się tylko na testach porównawczych lokalnej pamięci masowej, analizuj, czego potrzebuje Twoje obciążenie i odpowiednio rozmiar.
