SQL Server Cluster – zależności

SQL Server Cluster wymaga uwzględnienia zależności między usługą bazodanową a zasobami klastra Windows.

SQL Server Cluster jako rola Windows Server Failover Clustering

SQL Server Cluster w typowej konfiguracji oznacza SQL Server Failover Cluster Instance (FCI), czyli instancję SQL Server zainstalowaną w ramach Windows Server Failover Clustering (WSFC). W danym momencie zasoby tej instancji są własnością tylko jednego węzła, natomiast pozostałe węzły mogą przejąć rolę po awarii albo kontrolowanym przeniesieniu. WSFC nie synchronizuje danych między niezależnymi instancjami SQL Server. Zarządza własnością zasobów, ich stanem oraz kolejnością uruchamiania.

Rola FCI obejmuje między innymi zasób usługi SQL Server, zasób SQL Server Agent, zasoby magazynu oraz wirtualną nazwę sieciową i powiązane z nią adresy IP. Zależność oznacza, że zasób nadrzędny może zostać uruchomiony dopiero wtedy, gdy wymagany zasób podrzędny jest dostępny. Jeżeli zasób zależny przestaje działać, WSFC może wyłączyć, zrestartować albo przenieść całą grupę zasobów na inny węzeł, zależnie od konfiguracji polityki awaryjnej.

Magazyn współdzielony, nazwa sieciowa i kolejność startu

Usługa SQL Server w FCI korzysta z woluminów, na których znajdują się pliki baz danych, logów transakcyjnych oraz pozostałe dane instancji. Te zasoby magazynowe muszą być dostępne dla każdego węzła, który może przejąć rolę. W zależności od architektury mogą to być między innymi zasoby Fibre Channel, iSCSI, FCoE, SAS, SMB albo Storage Spaces Direct. Sam fakt, że drugi węzeł ma dostęp do katalogu instalacyjnego SQL Server, nie wystarcza, jeżeli nie widzi właściwych woluminów z danymi.

Wirtualna nazwa SQL Server jest zasobem sieciowym używanym przez klientów do łączenia się z instancją. Zasób nazwy zależy od co najmniej jednego zasobu adresu IP, a adresy mogą należeć do różnych podsieci. Nazwa sieciowa może wymagać prawidłowej rejestracji w DNS oraz odpowiednich obiektów i uprawnień w Active Directory Domain Services. W uproszczonym drzewie zależności adres IP musi być dostępny przed nazwą sieciową, natomiast usługa SQL Server wymaga dostępności zarówno magazynu, jak i nazwy sieciowej.

SQL Server Agent i zasoby dodatkowe

SQL Server Agent jest osobnym zasobem klastra, którego standardowa zależność prowadzi do zasobu SQL Server. Dzięki temu Agent nie powinien startować przed uruchomieniem właściwej usługi silnika. Jeżeli aplikacja lub dodatkowy zasób ma działać tylko wtedy, gdy SQL Server jest dostępny, trzeba ostrożnie dobrać punkt zależności. Microsoft zaleca, aby zasób wymagający dostępności SQL Server zależał od zasobu SQL Server Agent, gdy taki model spełnia cel operacyjny, ponieważ awaria Agenta nie musi wtedy powodować wyłączenia samego silnika bazodanowego.

Nie każdy zasób powinien być dopisywany do grupy FCI. Szczególnej uwagi wymagają udziały plikowe używane przez funkcje SQL Server, zasoby FILESTREAM, dodatkowe nazwy sieciowe oraz zasoby aplikacji korzystających z bazy. Dodanie niewłaściwej zależności może spowodować niepotrzebne przenoszenie całej roli albo zatrzymanie SQL Server po awarii elementu, który nie jest konieczny do pracy silnika. Drzewo zależności należy zmieniać tylko wtedy, gdy konkretna funkcja wymaga takiej modyfikacji i gdy wszystkie zasoby mają poprawnie określonych właścicieli możliwych.

Sprawdzanie zależności przed przełączeniem instancji

Diagnostykę rozpoczyna się od sprawdzenia roli FCI w Failover Cluster Manager oraz statusu każdego zasobu: magazynu, adresów IP, nazwy sieciowej, usługi SQL Server i SQL Server Agent. Istotne jest ustalenie, który węzeł jest aktualnym właścicielem grupy, a także czy docelowy węzeł znajduje się na liście możliwych właścicieli wszystkich wymaganych zasobów. Zasób może być dostępny na jednym serwerze, ale niezdolny do uruchomienia na innym z powodu braku dysku, uprawnień, sterownika, ścieżki montowania albo łączności z usługami katalogowymi.

Do odczytu konfiguracji można użyć polecenia PowerShell Get-ClusterResourceDependency, które pokazuje zależności skonfigurowane między zasobami klastra. Przydatne jest również porównanie stanu zasobów z dziennikami WSFC i dziennikiem błędów SQL Server. Jeżeli po przełączeniu nazwa sieciowa jest niedostępna, należy sprawdzić adres IP, DNS i zależności nazwy. Jeżeli usługa SQL Server nie startuje, trzeba zweryfikować dostępność wszystkich wymaganych woluminów oraz ścieżki plików baz danych. Dopiero po potwierdzeniu tych elementów można oceniać samą konfigurację silnika, uprawnienia usługi i proces odzyskiwania baz po przełączeniu.