Date: 6월 19, 2018
태그: 장애 조치 (failover) 클러스터 인스턴스
SQL Server 장애 조치 인스턴스 클러스터 연결에서 Azure ILB 연결 문제 해결
SQL Server 장애 조치 (Failover) 클러스터 인스턴스 연결 문제를 해결하는 데 도움이되는 다음 도구를 사용합니다. 특히 그 성가신 Azure ILB 연결 문제. 나는 새로운 도구를 찾을 때마다이 기사를 업데이트하려고 노력할 것이다.
NETSTAT
첫 번째 도구는 SQL 클러스터 IP가 수신 대기해야하는 포트에서 수신 대기하는지 확인하는 간단한 테스트입니다. 이 경우 SQL 클러스터 IP 주소는 10.0.0.201입니다. 하지만 포트 1433 인 기본 인스턴스를 사용하고 있습니다.
다음은 액티브 노드가 해당 포트에서 수신 대기 중인지 여부를 빠르게 식별하는 데 도움이되는 명령입니다. 우리의 경우 아래 모든 것이 정상적으로 보입니다.
C : Users dave.SIOS> netstat -na | "1433"을 찾는다.
TCP 10.0.0.4 : 49584 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49592 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49593 10.0.0.201:1433 설립
TCP 10.0.0.4 : 49595 10.0.0.201:1433 설립
TCP 10.0.0.201:1433 0.0.0.0:0 LISTENING
설립 됨
TCP 10.0.0.201:1433 10.0.0.4:49592 설립
TCP 10.0.0.201:1433 10.0.0.4:49593 설립
TCP 10.0.0.201:1433 10.0.0.4:49595 설립
일단 SQL이 적절한 포트를 듣고 있는지 확인할 수있게되면 PSPING을 사용하여 포트에 원격으로 연결하려고합니다.
PSPING
PSPing은 Microsoft에서 제공하는 PSTools 패키지의 일부입니다. 보통 도구를 다운로드하고 PSPing을 직접 System32 폴더에 넣으므로 디렉토리를 변경하지 않고도 필요할 때마다 사용할 수 있습니다.
이제 ILB, 클러스터 및 방화벽 관점에서 모든 것이 올바르게 구성되었다고 가정하면 패시브 서버에서 SQL 클러스터 IP 주소와 포트 1433을 ping 할 수 있어야합니다. 아래에 결과가 표시됩니다.
C : Users dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - 핑, 대기 시간, 대역폭 측정 유틸리티
저작권 (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP 10.0.0.201:1433에 연결 :
5 회 반복 (예열 1) 연결 테스트 :
10.0.0.201:1433에 연결 중 (워밍업) : 6.99ms
10.0.0.201:1433에 연결 중 : 0.78ms
10.0.0.201:1433에 연결 중 : 0.96ms
10.0.0.201:1433에 연결 중 : 0.68ms
10.0.0.201:1433에 연결 중 : 0.89ms
일들이 제대로 구성되지 않으면 다음과 비슷한 결과가 나타날 수 있습니다 ...
C : Users dave.SIOS> psping 10.0.0.201:1433
TCP 10.0.0.102:1433에 연결 :
5 회 반복 (예열 1) 연결 테스트 :
10.0.0.102:1433에 연결 중 (워밍업) :
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) :
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) :
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) :
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
10.0.0.102:1433에 연결 중 (워밍업) :
제한 시간이 만료되었으므로이 작업이 반환되었습니다.
PSPing이 연결되어 있지만 응용 프로그램에서 연결에 문제가있는 경우 조금 더 자세히 조사해야 할 수 있습니다. Great Plains와 같은 일부 응용 프로그램에서도 포트 445에 연결하려고합니다. 응용 프로그램이 연결할 수 없지만 PSPing이 1433에 잘 연결되면. 그런 다음 네트워크 추적을 수행하고 응용 프로그램이 연결하려고하는 다른 포트를 확인해야 할 수 있습니다. 마지막 단계는 해당 포트에 대한로드 밸런싱 규칙을 추가하는 것입니다.
명명 된 인스턴스
명명 된 인스턴스를 사용 하시겠습니까? 고정 포트를 사용하려면 TCP 서비스를 잠그고 있어야합니다. 동시에로드 밸런서에 규칙을 추가하여 SQL Browser 서비스 용 UDP 1434를 리디렉션해야합니다. 그렇지 않으면 명명 된 인스턴스에 연결할 수 없습니다.
파이어 월
TCP 포트 1433 및 59999를 여는 것은 필요한 모든 수동 단계를 다루어야합니다. 그러나 연결 문제를 해결할 때 일반적으로 Windows 방화벽을 꺼서 문제의 가능한 원인으로 방화벽을 제거합니다. 잊지 마세요. Azure에는 Network Security Groups라는 방화벽도 있습니다. 누군가가 트래픽을 차단할 수있는 기본값에서이를 변경했다면.
이름 해상도
SQL 클러스터 이름을 ping하십시오. SQL Server 클러스터 IP 주소로 확인되어야합니다. 몇 번 이상 본 적이 있지만 SQL 클러스터 네트워크 이름과 관련된 DNS A 레코드는 DNS에서 신비하게 사라집니다. 그렇다면 DNS의 A 레코드로 SQL Custer 이름과 IP 주소를 읽고 읽습니다.
SQL CONFIGURATION MANAGER
SQL Configuration Manager에는 SQL 클러스터 IP 주소와 포트 1433이 나열되어 있어야합니다. 우연히 명명 된 인스턴스를 설치했다면 당연히 여기에 들어가서 포트를 특정 포트에 고정하고로드 밸런싱 규칙을 해당 포트에 반영해야합니다. AGUR 당 ILB에 대한 Azure ILB 제한으로 인해 명명 된 인스턴스를 사용하는 유효한 이유가 실제로 없습니다. 스스로를 더 쉽게 만들고 SQL의 기본 인스턴스를 사용하십시오. (업데이트 : 2016 년 10 월 현재 ILB 당 여러 개의 IP 주소를 사용할 수 있으므로 클러스터에 SQL 인스턴스가 여러 개있을 수 있습니다.)
Mere Mortals를위한 클러스터링 (Clustering for Mere Mortals)의 허락을 받아 복제했습니다.