SQL Server na Windows Server w chmurze

SQL Server na Windows Server w chmurze łączy tradycyjną platformę systemową z elastycznością infrastruktury dostawcy.

SQL Server na Windows Server w środowisku chmurowym

SQL Server uruchomiony na Windows Server w chmurze jest relacyjnym systemem zarządzania bazami danych działającym na serwerze udostępnionym przez dostawcę infrastruktury. Windows Server zapewnia system operacyjny, usługi sieciowe, obsługę dysków oraz mechanizmy zarządzania kontami, natomiast SQL Server odpowiada za przechowywanie tabel, wykonywanie zapytań T-SQL, transakcje, indeksowanie i kontrolę dostępu do danych. Chmura zmienia sposób dostarczania zasobów, ale nie zmienia podstawowych zasad działania silnika SQL Server.

W takim układzie można utworzyć instancję SQL Server na serwerze z odpowiednią wersją Windows Server, przydzielić jej procesory wirtualne, pamięć operacyjną, przestrzeń dyskową i interfejs sieciowy, a następnie skonfigurować dostęp z aplikacji. Wydajność zależy nie tylko od parametrów samej instancji, lecz także od rodzaju dysków, opóźnień sieciowych, limitów dostawcy oraz sposobu rozmieszczenia plików danych i dzienników transakcji. SQL Server korzysta z plików danych, zwykle z rozszerzeniem .mdf lub .ndf, oraz z pliku dziennika transakcji .ldf.

Dobór zasobów i rozmieszczenie plików bazy

Podczas wdrażania SQL Server na Windows Server trzeba rozdzielić kilka niezależnych obszarów konfiguracji. Pamięć operacyjna jest używana przez bufor danych, w którym silnik przechowuje często wykorzystywane strony baz. Jeżeli pamięci jest zbyt mało, system częściej odczytuje dane z dysku, co zwiększa opóźnienia. Zbyt duża wartość limitu pamięci SQL Server może z kolei ograniczyć zasoby dostępne dla systemu Windows Server i innych procesów. Dlatego parametr max server memory powinien pozostawiać systemowi operacyjnemu zapas pamięci potrzebny do stabilnej pracy.

Pliki danych i dziennik transakcji mają różne wzorce obciążenia. Pliki danych obsługują odczyty oraz modyfikacje stron baz, natomiast dziennik zapisuje zmiany w sposób sekwencyjny i jest niezbędny do odtwarzania spójności po awarii. Umieszczenie obu typów plików na tym samym, przeciążonym wolumenie może powodować wzajemne opóźnienia. Przy ocenie środowiska warto analizować czas oczekiwania operacji wejścia-wyjścia, wzrost pliku dziennika, częstotliwość punktów kontrolnych oraz wykorzystanie procesora. Sam rozmiar dysku nie mówi jeszcze, czy konfiguracja będzie wystarczająco szybka.

Połączenia, uwierzytelnianie i kopie zapasowe

Aplikacja łączy się z SQL Server za pomocą protokołu TDS, korzystając z konfiguracji instancji oraz portu sieciowego. Dla domyślnej instancji SQL Server często używany jest port TCP 1433, ale rzeczywista konfiguracja może być inna. Port powinien być dostępny wyłącznie z wymaganych sieci, a reguły zapory systemu Windows Server i zapory dostawcy chmury muszą ze sobą współdziałać. Otwieranie dostępu z całego Internetu bez uzasadnienia zwiększa powierzchnię ataku i utrudnia kontrolę połączeń.

SQL Server obsługuje uwierzytelnianie Windows oraz uwierzytelnianie SQL Server, zależnie od wybranego trybu instalacji i konfiguracji instancji. Uprawnienia należy nadawać konkretnym loginom, użytkownikom baz danych i rolom, ponieważ uprawnienie do połączenia z serwerem nie oznacza automatycznie prawa do odczytu lub zmiany wszystkich tabel. Ochrona danych operacyjnych wymaga również regularnych kopii pełnych, różnicowych i dziennika transakcji, jeżeli baza działa w modelu odzyskiwania FULL. Kopia zapasowa jest użyteczna dopiero wtedy, gdy można ją poprawnie odtworzyć, dlatego test odtwarzania powinien być częścią procedury utrzymaniowej.

Diagnostyka awarii SQL Server na Windows Server

Problemy z SQL Server w chmurze mogą wynikać z błędnej konfiguracji systemu, ograniczenia zasobów, niedostępności sieci albo nieprawidłowej pracy samej bazy. Diagnostykę rozpoczyna się od sprawdzenia, czy usługa SQL Server jest uruchomiona, czy instancja nasłuchuje na właściwym adresie i porcie oraz czy zapora nie odrzuca połączenia. Następnie analizuje się dziennik błędów SQL Server, Podgląd zdarzeń systemu Windows oraz komunikaty klienta. Błąd logowania, przekroczenie limitu czasu i brak trasy sieciowej wskazują na różne warstwy problemu, więc nie powinny być traktowane jako jeden rodzaj awarii.

Przy spowolnieniach należy odróżnić oczekiwanie na procesor od oczekiwania na wejście-wyjście, blokad transakcyjnych i nieefektywnych planów wykonywania zapytań. Pomocne są statystyki oczekiwań, raporty aktywności sesji, analiza blokad oraz kontrola fragmentacji i aktualności statystyk indeksów. Jeżeli wystąpi uszkodzenie plików, nagłe zatrzymanie serwera lub utrata dostępu do wolumenu, priorytetem jest zachowanie spójności i ustalenie możliwości odtworzenia bazy z kopii. Diagnostyka powinna obejmować zarówno Windows Server, warstwę sieciową dostawcy chmury, jak i konfigurację SQL Server, ponieważ sprawny silnik nie naprawi problemu z niedostępnym dyskiem lub błędną regułą zapory.