Всегда при отказе доступности для фермы SharePoint не удается подключиться к SQL Server

У нас есть ферма SharePoint во внешнем интерфейсе 2013.
Мы используем корпоративную версию sql server 2014.

Изначально ферма SharePoint подключена к серверу A.
Но мы хотели настроить для этого доступность Always On.
Мы настроили ее со стороны Sql.Сервер B является вторичной репликой.

И мы также настроили прослушиватель.
После настройки прослушивателя мы дали имя и IP-адрес прослушивателя команде SharePoint.
Они изменили псевдоним на имя Листнера на стороне подключения клиента.
После этого у нас есть сделал возможные сценарии для проверки отказоустойчивости.

Но сценарии перехода на другой ресурс потерпели неудачу.
Мы обнаружили одну общую проблему во всех сценариях.
После переключения на сервер B SharePoint не перенаправляется на сервер B, он по-прежнему пытается подключиться только к серверу A. .
Когда мы отключаем сервер A, SharePoint также выходит из строя.

Когда мы переключились на сервер B (первичный), сервер A доступен и действует как вторичный для чтения. На данный момент веб-сайт SharePoint находится в читаемом состоянии.

Здесь наблюдение состоит в том, что ферма SharePoint зависит только от состояния сервера A.

Мы попросили команду SharePoint забыть о постоянно включенном и прослушивателе и попытаться подключиться к серверу B напрямую.
Они изменили некоторые настройки в cliconfg.exe .

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

Есть ли какая-либо другая команда, которая будет участвовать в решении этой проблемы, кроме SQL и SharePoint?

Кворум настроен как файловый ресурс-свидетель. у нас есть только 2 реплики. Когда сервер A не работает, кворум настраивается между файловым ресурсом и сервером B. Однако кластер работает нормально, когда мы проверяем диспетчер отказоустойчивого кластера сразу после того, как сервер А вышел из строя.

Свидетель FS не размещается ни на стороне сервера A, ни на стороне сервера B. Он размещен на другом сервере.


sql-server high-availability sharepoint-2013 sql-server-2014 failovercluster
person spiky    schedule 29.03.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Насколько я понимаю, вы ищете функцию маршрутизации только для чтения.

У вас возникла проблема с маршрутизацией вашего трафика на доступный для чтения вторичный сервер после отработки отказа. Ваша точка доступа всегда общается только с AG Listener. AG Listener сообщит вам, кто является основным, а основной возвращает клиенту (sharepoint) дополнительный URL-адрес для установления соединения.

Многие люди не понимают, что список маршрутизации только для чтения является свойством реплики. Каждый узел имеет свой собственный список маршрутизации только для чтения. Если у вас есть проблема после отработки отказа, но до этого проблем не было. Я предлагаю вам проверить конфигурацию списка маршрутизации только для чтения обоих узлов. убедитесь, что у сервера B (первичный) есть список, чтобы сообщить клиенту, что вам следует перейти на сервер A. Используйте следующий запрос, чтобы проверить свою конфигурацию.

SELECT ar.replica_server_name "When This Server is Primary", 
    rl.routing_priority, 
    ar2.replica_server_name "Route to this Server", 
    ar.primary_role_allow_connections,
    ar.secondary_role_allow_connections_desc,   ar2.read_only_routing_url 
FROM sys.availability_read_only_routing_lists rl
  inner join sys.availability_replicas ar 
    on rl.replica_id = ar.replica_id
  inner join sys.availability_replicas ar2
    on rl.read_only_replica_id = ar2.replica_id
ORDER BY ar.replica_server_name, rl.routing_priority
person zero    schedule 12.04.2017