Wersje Windows Server

Wersje Windows Server determinują dostępność niektórych funkcji SQL Server, np. mechanizmów klastrowania.

Rola wersji Windows Server w środowisku SQL Server

Wersja Windows Server określa, jakie składniki systemu są dostępne dla uruchamianych na nim usług, w tym dla SQL Server. Dotyczy to między innymi obsługi klastra pracy awaryjnej Windows Server Failover Clustering (WSFC), sposobu zarządzania rolami serwerowymi, dostępnych mechanizmów sieciowych oraz okresu wsparcia producenta. Sam SQL Server nie tworzy niezależnie pełnej infrastruktury klastrowej. W przypadku instancji skonfigurowanej jako Failover Cluster Instance korzysta z funkcji klastra udostępnianych przez system Windows Server.

W praktyce oznacza to, że zgodność trzeba analizować dla konkretnej pary produktów: wydania Windows Server, edycji Windows Server, wersji SQL Server oraz jej edycji. Aktualizacja systemu operacyjnego nie zmienia automatycznie edycji SQL Server ani nie odblokowuje funkcji objętych licencją silnika. Może jednak umożliwić instalację nowszej wersji SQL Server, zapewnić obsługę określonych sterowników lub usunąć ograniczenia związane z końcem wsparcia starszego systemu.

Najważniejsze generacje systemu dla administratora

W środowiskach spotyka się między innymi Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022 oraz Windows Server 2025. Każde z tych wydań ma własny cykl wsparcia, wymagania sprzętowe i listę obsługiwanych wersji SQL Server. Windows Server 2012 R2 i Windows Server 2012 nie są już właściwym wyborem dla nowych wdrożeń, ponieważ ich standardowe okresy wsparcia zakończyły się. Przy utrzymywaniu starszej instalacji trzeba sprawdzić, czy organizacja ma odpowiednią umowę rozszerzonego wsparcia oraz czy używana wersja SQL Server nadal jest zgodna z tym systemem.

Windows Server 2016, 2019 i 2022 różnią się między innymi funkcjami klastra, modelami aktualizacji, obsługą sprzętu i terminami zakończenia wsparcia. Windows Server 2025 jest nowszą generacją przeznaczoną do aktualnych wdrożeń, ale przed migracją należy potwierdzić zgodność używanej wersji SQL Server, sterowników macierzy, oprogramowania do kopii zapasowych i narzędzi monitorujących. W środowisku produkcyjnym nie wystarczy sprawdzić, czy instalator SQL Server uruchamia się poprawnie. Należy także zweryfikować działanie klastra po restarcie węzła, utracie interfejsu sieciowego i przełączeniu zasobów.

WSFC, FCI i Always On: różne mechanizmy wysokiej dostępności

Windows Server Failover Clustering zapewnia warstwę klastrową, w której kilka węzłów może współdzielić kontrolę nad zasobami usługi. SQL Server Failover Cluster Instance wykorzystuje tę warstwę do uruchamiania jednej instancji SQL Server na aktywnym węźle. Po awarii węzła zasoby instancji, takie jak nazwa sieciowa, adres IP i dostęp do magazynu, mogą zostać przeniesione na drugi węzeł. FCI wymaga odpowiednio przygotowanego współdzielonego magazynu lub rozwiązania udostępniającego dane wszystkim węzłom zgodnie z wymaganiami konkretnej wersji SQL Server.

Always On Availability Groups działają inaczej. Bazy danych są utrzymywane na oddzielnych instancjach SQL Server, a zmiany są przesyłane między replikami. W tym rozwiązaniu WSFC nadal może być wymagany do zarządzania zasobami i automatycznego przełączania, ale dane nie muszą znajdować się na jednym współdzielonym woluminie w taki sposób jak przy klasycznej FCI. Zakres funkcji zależy od wersji i edycji SQL Server. Przykładowo SQL Server Standard ma bardziej ograniczone możliwości grup dostępności niż SQL Server Enterprise, dlatego przed projektem trzeba sprawdzić aktualną macierz funkcji, liczbę obsługiwanych replik, liczbę baz oraz dostępne tryby pracy.

Weryfikacja wersji przed instalacją i naprawą

Podstawową czynnością jest odczytanie dokładnej wersji systemu i SQL Server na każdym węźle. W Windows Server można użyć polecenia winver albo polecenia PowerShell Get-ComputerInfo, zwracając uwagę na nazwę produktu, numer kompilacji i zainstalowane aktualizacje. Stan funkcji klastrowych można sprawdzić w Server Managerze, narzędziach Failover Cluster Manager oraz poleceniem PowerShell Get-WindowsFeature Failover-Clustering. Sam fakt zainstalowania roli nie potwierdza jeszcze poprawnej konfiguracji sieci, kworum, nazw klastrowych ani zależności zasobów.

Informacje o SQL Server można odczytać w SQL Server Management Studio, w SQL Server Configuration Managerze lub zapytaniem SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel'), SERVERPROPERTY('Edition');. Należy porównać wynik z oficjalną dokumentacją zgodności Microsoftu dla konkretnego wydania. Podczas diagnostyki warto sprawdzić dzienniki SQL Server, dzienniki FailoverClustering, stan usług, rozpoznawanie nazw DNS, reguły zapory oraz dostępność portu używanego przez instancję. Błąd przypisywany „wersji Windows Server” może w rzeczywistości wynikać z niezgodnej edycji SQL Server, brakujących aktualizacji, niewłaściwych uprawnień kont usług, problemu z kworum albo niedostępnego magazynu danych.