Obsługa klastrów w edycjach

Klastry pracy awaryjnej obsługuje edycja Standard z ograniczeniem do dwóch węzłów; Enterprise znosi ten limit.

Zakres obsługi klastra pracy awaryjnej

W kontekście edycji SQL Server określenie „obsługa klastrów” odnosi się do klastra pracy awaryjnej, czyli rozwiązania opartego na Windows Server Failover Clustering (WSFC) i instancji SQL Server skonfigurowanej jako Failover Cluster Instance (FCI). Taka konfiguracja pozwala uruchamiać jedną instancję SQL Server na jednym z kilku węzłów klastra. W przypadku awarii aktywnego węzła zasoby instancji mogą zostać przeniesione na inny węzeł, który przejmuje jej działanie.

Ważne jest rozróżnienie liczby węzłów od liczby jednocześnie działających instancji. Węzeł to serwer uczestniczący w klastrze WSFC, natomiast instancja SQL Server jest rolą klastra, która w danym momencie działa na określonym węźle. Klaster pracy awaryjnej nie oznacza automatycznego równoległego wykonywania zapytań przez wszystkie serwery. Jego głównym zadaniem jest zapewnienie możliwości przełączenia usługi po awarii, a nie zwiększanie wydajności przez rozdzielanie obciążenia.

Różnica między edycją Standard a Enterprise

Edycja Standard SQL Server obsługuje instancję Failover Cluster Instance z ograniczeniem do dwóch węzłów. Oznacza to, że w ramach jednej konfiguracji klastra pracy awaryjnej mogą uczestniczyć dwa serwery przeznaczone do uruchomienia tej samej klastrowanej instancji SQL Server. Jeden z nich może pełnić funkcję węzła aktywnego, a drugi pozostaje gotowy do przejęcia roli po wystąpieniu awarii lub podczas zaplanowanego przełączenia.

Edycja Enterprise znosi limit dwóch węzłów dotyczący tej funkcji. Możliwe jest więc zaprojektowanie klastra z większą liczbą serwerów, jeżeli pozwalają na to wymagania techniczne, konfiguracja systemu Windows Server Failover Clustering, sposób udostępniania magazynu oraz warunki licencyjne. Sam wybór Enterprise nie tworzy jednak dodatkowych węzłów i nie zapewnia automatycznie poprawnego przełączania. Każdy węzeł musi być prawidłowo przygotowany, mieć zgodne komponenty oraz dostęp do zasobów wymaganych przez klastrowaną instancję.

Węzły, magazyn danych i mechanizm przełączenia

Failover Cluster Instance korzysta ze wspólnych zasobów, do których dostęp musi mieć każdy węzeł mogący przejąć instancję. Dotyczy to przede wszystkim plików baz danych, dzienników transakcji, baz systemowych oraz innych elementów wymaganych przez konkretną konfigurację SQL Server. W zależności od architektury środowiska magazyn może być udostępniany przez rozwiązanie obsługiwane przez WSFC, na przykład dyski klastrowane. Dostęp do danych musi pozostać spójny po zmianie aktywnego węzła.

Przełączenie następuje wtedy, gdy klaster wykryje niedostępność aktywnego węzła albo awarię zasobu przypisanego do roli SQL Server. WSFC wykorzystuje mechanizm głosowania i kworum do podjęcia decyzji, który zestaw węzłów ma prawo uruchomić zasoby klastra. Prawidłowo skonfigurowe kworum ogranicza ryzyko uruchomienia tej samej roli jednocześnie w dwóch miejscach, co mogłoby prowadzić do konfliktu dostępu do danych. Po przełączeniu usługa SQL Server może wymagać ponownego ustanowienia połączeń przez aplikacje.

Weryfikacja edycji i konfiguracji przed wdrożeniem

Ocena, czy dana konfiguracja spełnia wymagania, powinna rozpocząć się od ustalenia dokładnej edycji i wersji SQL Server zainstalowanej na każdym węźle. Następnie należy sprawdzić, czy planowana funkcja jest Failover Cluster Instance, czy innym mechanizmem wysokiej dostępności. Limit dwóch węzłów dla edycji Standard dotyczy klastra instancji pracy awaryjnej; nie należy przenosić tego ograniczenia bezpośrednio na inne funkcje SQL Server, takie jak grupy dostępności.

Podczas diagnostyki sprawdza się stan klastra WSFC, kworum, role i zasoby klastra, zależności usług, dostępność wspólnego magazynu oraz zgodność nazw sieciowych i punktów dostępu. Istotne są także dzienniki zdarzeń systemu Windows i logi SQL Server, ponieważ mogą wskazać, czy problem wynika z awarii węzła, utraty dostępu do dysku, błędów komunikacji, nieprawidłowej zależności zasobów albo ograniczenia samej edycji. Dopiero po rozdzieleniu tych przyczyn można ocenić, czy potrzebna jest zmiana konfiguracji, korekta instalacji, odtworzenie zasobu lub zastosowanie edycji Enterprise.