Grupa AlwaysOn Availability Automatyczne przełączanie awaryjne nie działa

Grając z konfiguracją AG Mam WSFC i skonfigurowałem dwa węzły w jednej grupie dostępności o nazwie DevClusterOnline. Oba węzły (podstawowy DEV-AWEB5, dodatkowy wtórny DEV-AWEB6) mają system Windows Server 2008 R2.

Jeśli sprawdzę stan mojego AG, otrzymam to:

Uruchomienie poniższego zapytania zwróci ten zestaw wyników:

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

Jeśli odłączę DEV-AWEB5, nie mogę połączyć się z Group Listener (DevListener), ale mogę go pingować, a on odpowie na mój ping. Replika - DEV-AWEB6 przechodzi w stan ROZWIĄZANIA, a moja baza danych jest niedostępna. Mogę jednak ręcznie przejść do Management Studio i ustawić tryb failover na DEV-AWEB6, a następnie znów zaczynam działać i DevListener ponownie zaakceptuje połączenia.

Biorąc pod uwagę fakt, że te fakty potwierdzają, że praca awaryjna faktycznie działa, że ​​zsynchronizowałem zatwierdzenia i skonfigurowałem automatyczne przełączanie awaryjne, nie mam pojęcia, co się stanie, jeśli będę działać nieprawidłowo w mojej konfiguracji.

Po odłączeniu DEV-AWEB5 oczekuję, że moja replika zachowa połączenie, a zatem również DevListener. Oczekuję, że automatyczne przełączanie awaryjne pozwoli mi transparentnie połączyć się z Listener AG. Z punktu widzenia użytkownika końcowego korzystanie z systemu WWW nie powinno być zauważalne, że jeden z serwerów DB ulegnie awarii.

Utknąłem tutaj, czy ktoś może oświecić mnie, co robię źle?

Jeśli odłączę DEV-AWEB5

Zdefiniuj „rozłącz”, jeśli chcesz. Domyślam się, że utrzymałeś pudełko, ale zdjąłeś SQL Server.

Nie mogę się połączyć z Group Listener (DevListener), ale mogę go pingować, a on odpowie na mój ping

Wynika to z faktu, że detektor jest po prostu wirtualną nazwą sieci (VNN) w grupie zasobów klastra WSFC dla reprezentowanej grupy dostępności. Twój węzeł DEV_AWEB5 nadal jest właścicielem grupy zasobów klastra, ale najprawdopodobniej jest to zasób klastra AG, który jest w stanie awarii. VNN musi być nadal online (oczekiwane zachowanie). Po prostu wskazuje na dowolny węzeł, który jest właścicielem tej grupy zasobów (w tym przypadku DEV-AWEB5). W rzeczywistości, jeśli masz włączone zdalne sterowanie PowerShell i uruchomiłeś następujące czynności:

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

Podobnie, jeśli możesz RDP do DEV-AWEB5 (pod warunkiem, że masz możliwości i dostępność itp.), Wówczas będziesz mógł RDP za pomocą nazwy detektora ( mstsc /v:YourListenerName). To tylko VNN.

Zwraca to nazwę komputera posiadanego węzła.

Na podstawie wszystkich twoich symptomów byłbym skłonny założyć się, że osiągnąłeś swój próg przełączania awaryjnego. Próg przełączania awaryjnego określa, ile razy klaster podejmie próbę przełączenia awaryjnego grupy zasobów w określonym przedziale czasu. Domyślne wartości tych maksymalnych przełączeń awaryjnych n - 1 (gdzie n jest liczbą węzłów) w okresie 6 godzin . Możesz to zobaczyć za pomocą następującego polecenia WSFC PowerShell:

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

To tylko daje ustawienia (które możesz zmodyfikować, jeśli tak wybierzesz, oczywiście).

Najlepszym sposobem, aby udowodnić, że tak jest w twoim przypadku, musisz wygenerować dziennik klastra (dzienniki zdarzeń systemowych są szczegółowo omawiane, dopóki „nie powiodło się” lub coś w tym rodzaju).

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

Domyślnie zostanie on umieszczony w folderze „C: \ Windows \ Cluster \ Reports”, a plik nazywa się „Cluster.log”.

Jeśli chcesz otworzyć ten dziennik klastra, powinieneś być w stanie znaleźć następujący ciąg znaków, wskazujący dokładnie, co się stało i dlaczego:

Niepowodzenie w grupie [YourClusterGroupName] , failoverCount [liczba przełączeń awaryjnych] , próg przełączania awaryjnego [wartość progowa przełączania awaryjnego] , nodeAvailCount [liczba dostępnych węzłów ].

Powyższy komunikat jest po prostu informacją WSFC, że nie spowoduje przełączenia awaryjnego grupy, ponieważ wydarzyło się to zbyt często (osiągnąłeś próg).

Dlaczego to się dzieje? Po prostu, aby zapobiec zbyt częstemu wpływowi Ping-Ponga zasobów klastra między węzłami.

Podczas gdy osiąganie tych progów byłoby powszechne w testowaniu przełączania awaryjnego, w produkcji zwykle wskazuje na problem, który należy zbadać.

Dodanie MSSQL jako zasobu usługi ogólnej nie jest odpowiedzią.

To po prostu sprawi, że Cluster Manager będzie odpowiedzialny za SQL Server Service, OK, tak, automatycznie przejdzie w tryb failover, ale zauważysz w SQL Server Configuration Manager, że twoje usługi są teraz ustawione na „Manual”, wskazując, że Cluster Manager jest teraz kontrolujesz swoją usługę serwera SQL.

Sprawujesz, że Cluster Manager odpowiada za aplikację bez klastrowania.

To skończy się łzami.

Prawidłowe podejście do prawidłowej konfiguracji grup dostępności SQL Server zgodnie z dokumentacją MS.

Upewnij się także, czy nie przekraczasz parametrów przełączania awaryjnego określonych w Menedżerze klastrów> Role> Zakładka przełączania awaryjnego.

Jeśli przekroczysz te limity, klaster nie spowoduje awarii zasobów i błąd zostanie wysłany do dziennika zdarzeń aplikacji.