Uruchamianie programu SQL Server 2014 na maszynie wirtualnej platformy Azure

Microsoft ułatwia uruchamianie SQL Server 2014 na maszynie wirtualnej Azure w jednym z siedemnastu centrów danych Microsoft Azure. Wstępnie skonfigurowaną maszynę wirtualną można uruchomić ze wstępnie skonfigurowanym wystąpieniem programu SQL Server 2014 z galerii platformy Azure na wybranej maszynie wirtualnej platformy Azure o dowolnym rozmiarze. Jedną z opcji z galerii jest „SQL Server 2014 Enterprise Optimized for Transactional Workloads” działający w systemie Windows Server 2012 R2. Jedną z zalet korzystania ze wstępnie skonfigurowanego obrazu galerii jest to, że nie trzeba płacić za licencje SQL Server 2014. Po prostu płacisz godzinowy koszt wersji programu SQL Server i wybranego rozmiaru maszyny wirtualnej.

Opcje konfiguracji SQL Server 2014

Microsoft wyjaśnia, że ​​„ten obraz Enterprise Edition jest zoptymalizowany pod kątem obciążeń OLTP i jest przeznaczony dla maszyn wirtualnych o rozmiarach, w tym A4, A7, A8 i A9. Po wdrożeniu maszyna wirtualna jest dostarczana ze wstępnie skonfigurowanymi miejscami do magazynowania systemu Windows”. Microsoft wykonuje również pewne prace konfiguracyjne na poziomie instancji na SQL Server 2014, chociaż nie idą one wystarczająco daleko w tym, co uważam za standardowe najlepsze praktyki.

Tworzą osiem plików danych tempdb, które mają rozmiar 25600 MB, z przyrostem automatycznego wzrostu wynoszącym 1024 MB, co jest dobrym wyborem domyślnym. Włączają również TF1117 i TF1118 jako flagi śledzenia uruchamiania, które są również dobrym wyborem dla SQL Server. Wreszcie Microsoft umożliwia także błyskawiczną inicjalizację plików i blokowanie stron w pamięci w systemie operacyjnym, z czym też się zgadzam.

Wolałbym, aby firma Microsoft wprowadziła również pewne zmiany w tych opcjach konfiguracji na poziomie instancji:

1. domyślna kompresja kopii zapasowej
2. próg kosztów dla równoległości
3. maksymalny stopień równoległości
4. maksymalna pamięć serwera (MB)
5. optymalizuj pod kątem obciążeń ad hoc

W większości przypadków kompresja kopii zapasowej powinna być domyślnie włączona. Próg kosztów dla równoległości często powinien być podniesiony do wyższej wartości niż domyślna wartość 5, w zależności od obciążenia. Maksymalny stopień równoległości zwykle należy zmienić na wartość inną niż domyślna na podstawie liczby rdzeni w węźle NUMA. To ustawienie zależy również od obciążenia pracą. Maksymalna pamięć serwera powinna być ustawiona na wartość inną niż domyślna na podstawie ilości pamięci RAM w maszynie wirtualnej i tego, co jest uruchomione (oprócz aparatu bazy danych SQL Server) na maszynie wirtualnej. Wreszcie, myślę, że optymalizacja dla obciążeń ad hoc powinna być włączona, prawie we wszystkich przypadkach.

W obronie firmy Microsoft trudno byłoby dokonać zadowalającego wyboru konfiguracji dla niektórych z tych elementów bez znajomości (wcześniej) szczegółów rozmiaru maszyny wirtualnej i oczekiwanego obciążenia serwera bazy danych. To pozostawia tobie to zadanie, tak jak w przypadku lokalnej instancji programu SQL Server.

Rozmiar maszyny wirtualnej Azure

Mimo że możesz wybrać dowolną maszynę, od A0 Basic do A9 Standard, firma Microsoft zaleca wybranie maszyny wirtualnej o rozmiarze A4 Standard, A7 Standard, A8 Standard lub A9 Standard do użytku produkcyjnego. Szczegóły cen dla maszyn wirtualnych SQL Server są wymienione tutaj.

Patrząc na porównawcze specyfikacje tych zaleceń w Tabeli 1, trudno jest zrozumieć, dlaczego miałbyś chcieć wybrać maszynę A4 Standard, ponieważ kosztuje ona tyle samo za godzinę, co większe maszyny A7 lub A8 Standard. Patrząc na dokumentację online, początkowo nie jest jasne, jaka jest rzeczywista różnica między maszyną A7 i A8 Standard. Kopiąc nieco głębiej, maszyna A8 Standard jest uważana za instancję Intensive Compute, która ma wykorzystywać szybszy procesor Intel Xeon E5-2670 2,6 GHz wraz z dwiema kartami sieciowymi (jedną 10 Gb/s i jedną obsługującą RDMA 32 Gb/s).

Maszyna wirtualna A7 Standard wykorzystuje nieco wolniejszy procesor Intel Xeon E5-2660 2,2 GHz, podczas gdy łączność sieciowa wydaje się być standardową siecią Ethernet 1 Gb/s. Choć brzmi to jak znacząca różnica w wydajności procesora i sieci, nie jest to główny problem w przypadku maszyn wirtualnych serii A do użycia w programie SQL Server.

Tabela 1:Informacje o maszynie wirtualnej SQL Server serii A

Głównym problemem ze wszystkimi maszynami wirtualnymi z serii A jest dość nędzna wydajność podsystemu we/wy, mimo że Microsoft wstępnie skonfigurował podsystem dysku z miejscami do magazynowania systemu Windows, aby uzyskać najlepszą możliwą wydajność, biorąc pod uwagę nieodłączne ograniczenia wydajności A- serie maszyn wirtualnych i hostów. Rysunek 1 przedstawia wyniki CrystalDiskMark dla dysku E:z maszyny A4 Standard z centrum danych Azure East US, która jest przeznaczona dla plików dziennika transakcji.

Rysunek 1:Standardowe wyniki CrystalDiskMark A4

Znacznie lepszą alternatywą dla SQL Server są maszyny wirtualne z serii D. Te maszyny wirtualne kosztują tyle samo za godzinę, co maszyny wirtualne serii A o porównywalnej wielkości i mają lokalną pamięć SSD, która powinna być używana tylko dla plików tempdb i/lub plików rozszerzeń puli buforów (BPE), ponieważ nie są trwałe. Niektóre istotne specyfikacje maszyn wirtualnych z serii D przedstawiono w Tabeli 2.

Tabela 2:Informacje o maszynie wirtualnej SQL Server serii D

Maszyna D4 Standard kosztuje tyle samo, co maszyna A4 Standard, ale ma dwa razy więcej pamięci RAM i trochę lokalnego dysku SSD. Maszyna D13 Standard kosztuje tyle samo, co maszyna A7 lub A8 Standard, ale z korzyścią dla lokalnej pamięci SDD. Maszyna D14 Standard kosztuje tyle samo, co maszyna A9 Standard, ale ma również zaletę lokalnej pamięci SSD. Biorąc pod uwagę te informacje, używanie maszyny wirtualnej serii A dla programu SQL Server nie ma sensu.

Niestety, stałe dyski dla danych i plików dziennika SQL Server również mają dość niską wydajność we/wy w CrystalDiskMark, jak pokazano na rysunkach 2 i 3.

Rysunek 2:Standardowe wyniki CrystalDiskMark D14

Rysunek 3:Standardowe wyniki CrystalDiskMark D14

Wydajność lokalnego dysku SSD jest powiązana z rozmiarem maszyny wirtualnej platformy Azure, przy czym większe rozmiary zapewniają lepszą wydajność lokalnego dysku SSD. Wyniki wydajności CrystalDiskMark dla maszyny D14 Standard w centrum danych Azure East US są pokazane na rysunku 4.

Rysunek 4:Standardowe wyniki CrystalDiskMark D14 dla lokalnej pamięci masowej SSD

Dysk F:(dla plików danych programu SQL Server) ma nieco lepsze wyniki niż dysk E:, ale oba dyski mają bardzo niski poziom wydajności programu SQL Server.

Wniosek

Wydaje się całkiem jasne, że maszyny z serii D są lepsze do użycia w SQL Server niż maszyny z serii A. Warto również zwrócić szczególną uwagę na rozmiar i cenę maszyny wirtualnej, którą zdecydujesz się udostępnić dla SQL Server, ponieważ możesz uzyskać więcej pamięci RAM przy tych samych kosztach godzinowych. Dwie najlepsze opcje z punktu widzenia wydajności to maszyny wirtualne D13 lub D14 Standard.

Wstępnie skonfigurowane wystąpienia programu SQL Server 2014 z galerii platformy Azure pozwalają zaoszczędzić dużo pieniędzy na kosztach licencjonowania programu SQL Server, a większość niezbędnych prac konfiguracyjnych została już ukończona w obrazie podstawowym. Nadal powinieneś wejść i wprowadzić kilka ostatecznych zmian w konfiguracji w oparciu o swoje preferencje i obciążenie pracą. Na koniec należy poświęcić trochę czasu na przeprowadzenie testów wydajności na maszynie wirtualnej, aby zrozumieć poziom wydajności, jaki może zapewnić.