Wystąpienie zarządzane usługi Azure SQL Database stało się ogólnie dostępne pod koniec 2018 r. Od tego czasu wiele organizacji rozpoczęło migrację do wystąpienia zarządzanego, aby korzystać z zalet środowiska zarządzanego. Organizacje korzystają z zarządzanych kopii zapasowych, wielu wbudowanych funkcji bezpieczeństwa, umowy SLA na poziomie 99,99% i zawsze aktualnego środowiska, w którym nie są już odpowiedzialne za instalowanie poprawek SQL Server lub systemu operacyjnego.
Jeden rozmiar nie zawsze pasuje do wszystkich. Wystąpienie zarządzane zapewnia dwie warstwy wydajności. Ogólny cel warstwa jest przeznaczona dla aplikacji o typowych wymaganiach dotyczących wydajności i opóźnień we/wy oraz zapewnia wbudowaną HA. Kluczowe znaczenie biznesowe warstwa jest przeznaczona dla aplikacji, które wymagają małych opóźnień we/wy i wyższych wymagań HA. Business Critical zapewnia również dwa nieczytelne pliki pomocnicze i jeden czytelny plik pomocniczy. Czytelna pomocnicza wersja to świetny sposób na rozłożenie obciążenia poza podstawową, co może obniżyć warstwę usług wymaganą dla podstawowej — zmniejszając ogólne wydatki na instancję.
Kiedy instancja zarządzana została po raz pierwszy wydana, można było wybierać między procesorami Gen4 i Gen5. Gen4 jest nadal opisany w dokumentacji, ale ta opcja jest obecnie w większości niedostępna. W tym artykule omówię tylko konfiguracje z procesorami Gen5.
Każda warstwa usług obsługuje od 4 do 80 procesorów logicznych — znanych również jako rdzenie wirtualne lub rdzenie wirtualne. Pamięć jest przydzielana na poziomie około 5,1 GB na rdzeń wirtualny. General Purpose zapewnia do 8 TB wysokowydajnej pamięci masowej Azure Blob, podczas gdy Business Critical zapewnia do 4 TB superszybkiej lokalnej pamięci masowej SSD.
Pamięć
Mając tylko 5,1 GB pamięci na rdzeń wirtualny, instancja z mniejszą liczbą rdzeni wirtualnych może mieć problemy. Opcje konfiguracji rdzeni wirtualnych to 4, 8, 16, 24, 32, 40, 64 i 80 rdzeni wirtualnych. Jeśli wykonasz obliczenia na każdej z opcji rdzeni wirtualnych ((number of vCores) × (5.1 GB) ), otrzymasz następujące kombinacje rdzeń / pamięć:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
W wielu organizacjach, którym pomogłem w przejściu z wystąpienia lokalnego do wystąpienia zarządzanego, zauważyłem znaczne zmniejszenie ilości pamięci. Typowe konfiguracje lokalne to 4 rdzenie wirtualne i 32 GB pamięci lub 8 rdzeni wirtualnych i 64 GB. Oba odpowiadają za ponad 30% redukcję pamięci. Jeśli instancja była już pod presją pamięci, może to powodować problemy. W większości przypadków byliśmy w stanie zoptymalizować wystąpienie lokalne, aby zmniejszyć obciążenie pamięci przed przejściem do wystąpienia zarządzanego, ale w kilku przypadkach klient musiał skorzystać z wyższej instancji rdzeni wirtualnych, aby zmniejszyć zużycie pamięci .
Pamięć
Przechowywanie jest nieco trudniejsze do zaplanowania i rozważenia ze względu na konieczność uwzględnienia wielu czynników. W przypadku magazynu należy uwzględnić ogólne wymagania dotyczące magazynu zarówno pod względem rozmiaru magazynu, jak i potrzeb we/wy. Ile GB lub TB jest potrzebnych dla instancji SQL Server i jak szybka musi być pamięć? Ile IOPS i jaka przepustowość jest używana przez wystąpienie lokalne? W tym celu należy wykonać linię bazową bieżącego obciążenia przy użyciu perfmon do przechwytywania średnich i maksymalnych MB/s i/lub wykonywania migawek sys.dm_io_virtual_file_stats w celu przechwytywania wykorzystania przepustowości. Dzięki temu zorientujesz się, jakiego typu we/wy i przepustowości potrzebujesz w nowym środowisku. Kilku klientów, z którymi współpracowałem, przegapiło tę istotną część planowania migracji i napotkało problemy z wydajnością z powodu wybrania poziomu instancji, który nie obsługiwał ich obciążenia.
Ma to kluczowe znaczenie dla linii bazowej, ponieważ w przypadku serwerów lokalnych często udostępnia się pamięć masową z superszybkiej sieci SAN o dużej przepustowości do mniejszych maszyn wirtualnych. Na platformie Azure limity IOPS i przepływności są określane na podstawie rozmiaru węzła obliczeniowego, a w przypadku zarządzania wystąpieniem są określane na podstawie liczby przydzielonych rdzeni wirtualnych. W przypadku ogólnego przeznaczenia obowiązuje limit 30-40 000 IOPS na wystąpienie lub od 500 do 12 500 IOPS na plik, w zależności od rozmiaru pliku. Przepustowość na plik jest również oparta na rozmiarze od 100 MiB/s dla plików do 128 GB i do 480 MiB/s dla plików 4 TB i większych. W przypadku krytycznego znaczenia biznesowego IOPS wynosi od 5,5 tys. do 110 tys. na instancję lub 1375 IOPS na rdzeń wirtualny.
Konsumenci muszą również uwzględnić przepustowość zapisu dziennika dla wystąpienia. Ogólne przeznaczenie to 3 MB/s na rdzeń wirtualny, z maksymalną prędkością 22 MB/s dla instancji, a Krytyczny dla działalności to 4 MB/s na rdzeń wirtualny, z maks. 48 MB/s dla całej instancji. Z mojego doświadczenia w pracy z klientami wynika, że wielu z nich znacznie przekroczyło te limity przepustowości zapisu. Dla niektórych był to efektowny, a dla innych byli w stanie zoptymalizować i zmodyfikować swój system, aby zmniejszyć obciążenie.
Oprócz konieczności znajomości ogólnej przepustowości i wymagań we/wy rozmiar pamięci masowej jest również powiązany z liczbą wybranych rdzeni wirtualnych. Do celów ogólnych:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Dla biznesu o znaczeniu krytycznym:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
W przypadku ogólnego przeznaczenia, gdy osiągniesz 8 rdzeni wirtualnych, możesz zmaksymalizować dostępną pamięć, co działa dobrze dla tych, którzy potrzebują tylko ogólnego przeznaczenia. Ale kiedy potrzebujesz krytycznego rozwiązania biznesowego, sprawy mogą być trudniejsze. Pracowałem z wieloma klientami, którzy mają wiele TB przydzielonych do maszyn wirtualnych z 4, 8, 16 i 24 procesorami logicznymi. Każdy z tych klientów musiałby zwiększyć liczbę rdzeni wirtualnych o co najmniej 32, aby spełnić wymagania dotyczące pamięci masowej, co jest kosztowną opcją. Azure SQL Database ma podobny problem z maksymalnym rozmiarem bazy danych, a firma Microsoft opracowała opcję hiperskalowania. Spodziewamy się, że w pewnym momencie stanie się to opcją dla wystąpienia zarządzanego, aby w podobny sposób zająć się limitami miejsca.
Rozmiar bazy tempdb jest również skorelowany z liczbą rdzeni wirtualnych. W warstwie Ogólnego przeznaczenia otrzymujesz 24 GB na rdzeń wirtualny (do 1920 GB) dla plików danych przy limicie rozmiaru pliku dziennika tempdb wynoszącym 120 GB. W przypadku warstwy Krytyczne dla firmy tempdb może rosnąć aż do aktualnie dostępnego rozmiaru magazynu wystąpień.
OLTP w pamięci
W przypadku osób, które obecnie korzystają z usługi OLTP w pamięci (lub planują ją), należy pamiętać, że jest ona obsługiwana tylko w warstwie usług o znaczeniu krytycznym dla firmy. Ilość miejsca dostępnego dla tabel w pamięci jest również ograniczona przez rdzenie wirtualne:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Wniosek
Planując migrację do wystąpienia zarządzanego Azure SQL, należy wziąć pod uwagę wiele kwestii przed podjęciem decyzji o migracji. Najpierw musisz w pełni zrozumieć wymagania dotyczące pamięci, procesora i pamięci, ponieważ to określi rozmiar instancji. Równie ważna jest wiedza o wymaganiach we/wy pamięci masowej. IOPS i przepustowość dla warstwy Ogólnego przeznaczenia są bezpośrednio powiązane z rdzeniami wirtualnymi i rozmiarem plików bazy danych. W przypadku Business Critical jest powiązana z liczbą rdzeni wirtualnych. Jeśli masz bardzo duże obciążenie we/wy, warstwa o znaczeniu krytycznym dla biznesu jest bardziej atrakcyjną warstwą usług, ponieważ zapewnia wyższe liczby IOPS i przepływności. Wyzwaniem dla Business Critical jest mniejsza pojemność pamięci masowej i obsługa tylko 1 TB dla całej instancji z maksymalnie 16 rdzeniami wirtualnymi.
Przy odpowiednim planowaniu i możliwej dekonsolidacji większych wystąpień do mniejszych wystąpień zarządzanych ta oferta może być bardzo opłacalną opcją migracji dla wielu organizacji. Atrakcją są korzyści płynące z posiadania zarządzanych kopii zapasowych, wbudowanej HA z umową SLA na poziomie 99,99%, dodatkowych funkcji i opcji bezpieczeństwa oraz braku konieczności martwienia się o instalowanie poprawek systemu operacyjnego lub instancji SQL Server.
