AlwaysOn Availability Group Автоматическое восстановление после отказа не работает

Играя с настройкой AG, я настроил WSFC и настроил два узла в одной группе доступности под названием DevClusterOnline. Оба узла (первичный DEV-AWEB5, вторичный DEV-AWEB6) работают под управлением Windows Server 2008 R2.

Если я проверяю здоровье моего AG, я получаю это:

Выполнение запроса ниже вернет этот набор результатов:

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;

Если я отключу DEV-AWEB5, я не смогу подключиться к прослушивателю группы (DevListener), но я могу пропинговать его, и он ответит на мой пинг. Реплика - DEV-AWEB6 переходит в состояние RESOLVING, и моя БД недоступна. Однако я могу вручную зайти в Management Studio и установить Failover на DEV-AWEB6, а затем я снова запускаюсь и работаю, и DevListener снова будет принимать подключения.

Учитывая, что эти факты подтверждают, что аварийное переключение действительно работает, что я синхронизировал фиксацию и настроил автоматическое аварийное переключение, я понятия не имею, что произойдет, если в моей настройке произойдет сбой.

Когда я отключаю DEV-AWEB5, я ожидаю, что моя реплика сохранит соединение и, следовательно, DevListener тоже. Я ожидаю, что автоматический переход на другой ресурс позволит мне прозрачно подключиться к прослушивателю AG. С точки зрения конечного пользователя, при использовании веб-системы не должно быть заметно, что один из серверов БД вышел из строя.

Я застрял здесь, может кто-нибудь объяснить мне, что я делаю неправильно?

Если я отключу DEV-AWEB5

Определите «отключение», если хотите. Я предполагаю, что вы сохранили коробку, но взяли SQL Server.

Я не могу подключиться к прослушивателю группы (DevListener), но я могу пропинговать его, и он ответит на мой пинг

Это связано с тем, что прослушиватель - это просто имя виртуальной сети (VNN) в группе ресурсов кластера WSFC для представленной группы доступности. Ваш узел DEV_AWEB5 по-прежнему владеет группой ресурсов кластера, но, скорее всего, только ресурс кластера AG находится в состоянии сбоя. VNN все еще должен быть в сети (ожидаемое поведение). Он просто указывает на любой узел, которому принадлежит эта группа ресурсов (в данном случае DEV-AWEB5). Фактически, если вы включили удаленное взаимодействие PowerShell, и вы запустили следующее:

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

Аналогично, если вы можете выполнить RDP в DEV-AWEB5 (при условии, что у вас есть возможности, доступность и т. Д.), Вы сможете выполнить RDP с помощью имени слушателя ( mstsc /v:YourListenerName). Это просто ВНН.

Возвращением этого будет имя компьютера вашего узла-владельца.

Судя по всем вашим симптомам, я был бы готов поспорить, что вы достигли порога отработки отказа. Порог отработки отказа определяет, сколько раз кластер будет пытаться выполнить отработку отказа вашей группы ресурсов за указанный период времени. Значение по умолчанию этих значений max failovers n - 1 (где n - количество узлов) в течение 6 часов . Это можно увидеть с помощью следующей команды WSFC PowerShell:

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

Это просто дает вам настройки (которые вы можете изменить, если захотите, конечно).

Лучший способ доказать, что это так, - вам нужно сгенерировать журнал кластера (журналы системных событий подробно описываются только в том случае, если «произошел сбой» или что-то в этом роде).

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

Это будет по умолчанию помещено в папку «C: \ Windows \ Cluster \ Reports», и файл называется «Cluster.log».

Если вы откроете этот журнал кластера, вы сможете найти там следующую строку, точно указав, что произошло и почему это произошло:

Не сбой при работе с группой [YourClusterGroupName] , failoverCount [количество аварийных переключений] , порог аварийного переключения [пороговое значение аварийного переключения] , nodeAvailCount [число доступных узлов ].

Приведенное выше сообщение просто указывает на то, что WSFC не приведет к отказу вашей группы, потому что это произошло слишком часто (вы достигли порога).

Почему это происходит? Просто чтобы предотвратить эффект пинг-понга, когда ресурсы кластера слишком часто перемещаются между узлами.

Принимая во внимание, что это было бы обычным для достижения этих порогов при тестировании отработки отказа, в производстве это обычно указывало бы на проблему, которая должна быть исследована.

Добавление MSSQL как общего ресурса службы не является ответом.

Это просто назначит диспетчер кластеров ответственным за службу SQL Server, да, да, он автоматически переключится при сбое, но вы заметите в диспетчере конфигурации SQL Server, что ваши службы теперь настроены на «Вручную», что указывает на то, что диспетчер кластеров теперь под контролем вашего сервера SQL службы.

Вы назначаете Cluster Manager ответственным за некластерное приложение.

Это закончится слезами.

Правильный подход - правильно настроить группы доступности SQL Server в соответствии с документацией MS.

А также убедитесь, что вы не превышаете параметры аварийного переключения, как определено в диспетчере кластеров> роли> вкладка аварийного переключения.

Если вы превышаете эти ограничения, кластер не перестанет использовать ваши ресурсы, и в журнале событий приложений будет опубликована ошибка.