0

프런트 엔드 2013에 SharePoint 팜이 있습니다.
우리는 SQL Server 2014 Enterprise Edition을 사용하고 있습니다.SharePoint 팜의 항상 가용성 장애 조치가 SQL Server에 연결하지 못했습니다.

처음에는 SharePoint 팜이 서버 A에 연결되었습니다.
그러나이 경우 항상 가용성을 구성하려고합니다.
SQL 끝에서 구성했습니다. 서버 B는 보조 복제본입니다.

그리고 수신기도 구성했습니다.
리스너를 구성한 후 리스너 이름과 IP를 SharePoint 팀에 제공했습니다.
클라이언트 연결 측에서 별칭 이름을 Listner 이름으로 변경했습니다.
그런 다음 가능한 시나리오를 수행하여 장애 조치를 테스트했습니다.

그러나 장애 조치 시나리오가 실패했습니다.
모든 시나리오에서 하나의 공통된 문제점을 발견했습니다.
서버 B로 장애 조치 (failover) 한 후 SharePoint는 서버 B로 리디렉션하지 않고 서버 A에만 계속 연결하려고합니다.
서버 A를 종료하면 SharePoint도 다운됩니다.

서버 B (기본)로 장애 조치를 수행하고 서버 A를 사용할 수 있고 읽을 수있는 보조 서버 역할을 수행 할 때. 현재 SharePoint 웹 사이트는 읽기 가능한 상태입니다.

여기서 SharePoint 팜은 서버 A 상태에만 의존한다는 것이 관찰되었습니다.

우리는 SharePoint 팀에게 항상 켜고 수신기를 잊어 버리고 서버 B에 직접 연결을 시도하도록 요청했습니다.
cliconfg.exe에서 일부 설정이 변경되었습니다.

그런 다음 SharePoint는 다시 서버 A에만 액세스하려고 시도합니다.
이유가 무엇일까요?

SQL 및 SharePoint는 제외하고이 문제를 해결하기 위해 다른 팀이 참여할 예정입니까?

쿼럼은 감시 파일 공유로 구성됩니다. 우리는 2 개의 복제본 만 가지고 있습니다. 서버 A가 종료되면 파일 공유와 서버 B간에 쿼럼이 구성됩니다. 그러나 서버 A가 중지 된 직후 장애 조치 (failover) 클러스터 관리자를 확인할 때 클러스터가 정상적으로 작동합니다.

FS 감시 서버가 서버 A 쪽이나 서버 B쪽에 있지 않습니다. 다른 서버에 배치됩니다.

답변

0

내 이해는 당신이 찾고있는 것이 라우팅 기능입니다.

장애 조치 후 장애가있는 보조 트래픽으로 트래픽을 라우팅하는 데 문제가 있습니다. 공유 지점은 항상 AG Listener 와만 통신합니다. AG Listener는 누가 기본 서버인지 알려주고 기본 클라이언트 (공유 지점)는 연결을 설정하는 보조 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 
관련 문제