W poszukiwaniu właściwego rytmu oraz elastyczności w #azure

Minął weekend, nieco mniej aktywnie w obszarze publikacji na sql4You, jednak najważniejsze, aby wypracować pewien rytm, dlatego też testuję różne podejścia.Od codziennych publikacji, przez publikacje co drugi dzień, aż do schematu, który zamierzam zweryfikować w tym tygodniu – czyli publikacje od poniedziałku do piątku. Próba wypracowania takiego rytmu nie jest wymówką i usprawiedliwienia braku aktywności, a raczej znalezieniem tak popularnego “work-life & hobby balance”. (A Tobie, który rytm publikacji najbardziej odpowiada? Pamiętaj, że wpisy na tym blogu pojawiają się właśnie dla Ciebie, dlatego Twoja opinia jest bardzo ważna. Zachęcam do wyrażenia swojej opinii w komentarzach…). Wspomniany rytm potrzebny jest nie tylko przy publikacjach, ale również w świecie baz danych. Dopasowanie platformy bazodanowej, jej możliwości, wydajności i kosztu do rytmu biznesu jest jednym z kluczowych aspektów wdrożenia takiego rozwiązania.

Właśnie dlatego nowy tydzień postanowiłem rozpocząć od przybliżenia obszaru Azure SQL Database. Skąd taki pomysł?  Platforma danych Microsoft, czyli obecnie SQL Server 2016, jest dość dobrze rozpoznawana na rynku, jeżeli planowałe(a)ś wdrożenie, uruchamiałe(a)ś lub dopiero przymierzasz się do uruchomienia rozwiązania, które będzie wykorzystywało SQL Server czy jakikolwiek inny silnik bazodanowy jako fragment rozwiązania, doskonale wiesz, że jednym z ważnych elementów jest wyskalowanie platformy sprzętowej oraz określenie wymagań funkcjonalnych dla uruchamianego silnika baz danych. Z drugiej strony doskonale wiesz, że dynamika zmian jest dzisiaj tak duża, że dość ciężko jest precyzyjnie określić potrzeby w perspektywie 6 miesięcy, roku czy 3-5 lat. Tym samym baza danych, która dzisiaj obsługuje 200-500 transakcji na godzinę, w niedługim czasie być może będzie musiała obsłużyć 10 000 transakcji na minutę, a może na sekundę. Potrzeba skalowalności, a jednocześnie optymalizacji wykorzystania warstwy sprzętowej doprowadziła do upowszechnienia wirtualizacji. SQL Server w środowisku wirtualnym to dzisiaj codzienność. Jednak wirtualizacja w zaciszu własnego data center , a nawet na platformach oferowanych przez dostawców chmury publicznej takich jak Azure czy AWS nie do końca adresuje dzisiejsze potrzeby. Dlaczego? Decydując się na wirtualizację nadal musimy estymować zapotrzebowanie na komponenty takie jak pamięć, IOPS, CPU. Dodatkowo nadal trzeba zarządzać infrastrukturą na potrzeby uruchomienia nawet najmniejszej bazy danych. W przypadku Azure SQL Database sytuacja planowania staje się nieco prostsza, liczy się ile danych potrzebujemy w bazie zapisać i jakiej wydajności oczekujemy od bazy danych – wydajności, a nie ilości rdzeni, GB RAMu czy operacji IOPS. W przypadku Azure SQL Database wydajność bazy wyrażona jest w jednostkach DTU. O samych jednostkach i opcjach usługi Azure SQL Database można przeczytać np. na stronach poświęconych usługom Azure. Dodatkowo dostępny jest kalkulator jednostek DTU, który na podstawie aktualnych parametrów pracy serwera pozwala dokonać estymacji zapotrzebowania na jednostki DTU (opcja przydatna w przypadku już istniejących systemów). Oczywiście ilość jednostek DTU wpływa na koszt wykorzystania usługi, jednak warto ten temat nieco zgłębić, chociażby ze względu na wprowadzoną jakiś czas temu opcję elastycznych baz danych i związanej z nimi jednostki eDTU. Elastyczne bazy danych umożliwiają zarządzanie zbiorczą wydajnością puli, a nie pojedynczymi bazami danych (postaram się jeszcze w tym tygodniu napisać kilka zdań o elastycznych bazach i pulach zasobów).

Warto w tym miejscu podkreślić, że dwa główne atrybuty usługi Azure SQL Database to dość duża swoboda skalowalności (możliwość zmiany parametrów usługi – jednostek DTU), a także bezpieczeństwo i ciągłość działania – domyślnie zapewnione są 3 kopie bazy danych.

Gdybym pisał ten tekst 2 lata temu w tym miejscu w zasadzie można byłoby postawić kropkę i nie wchodzić w szczegóły porównania funkcjonalności (Azure SQL Database vs SQL Server on-premises/VM), ponieważ usługa Azure SQL Database na samym początku w dość znaczący sposób odbiegała funkcjonalnie, od już wtedy dość zaawansowanego funkcjonalnie, silnika SQL Server wersji 2014. Obecna wersja Azure SQL Database pozwala na wykorzystanie większości funkcjonalności znany z silnika relacyjne platformy SQL Server, a nawet część funkcjonalności można było testować w ramach Azure SQL Database jeszcze przed ich premiera w SQL Server 2016.

Reasumując, Azure SQL Database to dość dobra alternatywa dla klasycznych implementacji SQL Server. Jak zawsze trzeba przeanalizować, czy jest to rozwiązanie dopasowane do scenariusza, który aktualnie analizujesz,  ale niewątpliwe dobrze jest mieć pewną alternatywę. Poniżej krótkie porównanie, które może ułatwić decyzję, jednak na pewno znajdziesz własne kategorie porównania dla Azure SQL Database oraz SQL Server.

Kategoria Azure SQL Database SQL Server (VM, Azure VM)
Funkcjonalności Azure SQL Database oferuje większość funkcjonalności dostępnych dla baz danych uruchamianych w ramach klasycznych instancji SQL Server dlatego należy przeanalizować (korzystając np. z Upgrade Advisora 2016 – można też przeczytać o tym narzędziu na sql4You) możliwość sobodnej migracji do Azure SQL Database Bardzo dobre rozwiązanie jeśli potrzebne jest zachowanie określonej wersji bazy danych oraz parametrów konfiguracji instancji SQL Server ( w przypadku Azure SQL Database nie mamy dostępu do parametrów konfiguracji instancji)
PaaS vs IaaS Domyślnie zapewnione mechanizmy wysokiej dostępności i odzyskiwania awaryjnego, jak również możliwości dość swobodnej skalowalności w obszarze wydajności bazy danych Konieczność budowy własnych rozwiązań HA oraz DR, a tym samym dodatkowej inwestycji w sprzęty na potrzeby tych rozwiązań
Aktualizacje Automatyczny proces aktualizacji, bez dodatkowych kosztów związanych z utrzymaniem rozwiązania Działanie w oparciu o konkretną wersję, wymagana aktualizacja i instalacja poprawek przez lokalnych administratorów rozwiązania
Licencjonowanie Brak konieczności zakupu licencji na SQL Server jak również możliwości wykorzystania posiadanych licencji. Aktywacja usługi zapewnia prawo do jej wykorzystania dla nieokreślonej liczby użytkowników końcowych (brak CAL, brak modelu licencjonowanie per core/CPU) Konieczność zapewnienia odpowiednich licencji na platformę SQL Server oraz użytkowników końcowych ( model Server + CAL lub core

One Reply to “W poszukiwaniu właściwego rytmu oraz elastyczności w #azure”

Comments are closed.