SQL Server Alwayson 내부 부하 분산 장치와 리소스 관리자 구성

Date: 3월 16, 2018

태그: Azure Resource Manager 배포 모델, SQL Server Alwayson 내부 부하 분산 장치

Azure Resource Manager (ARM) 배포 모델 #Sqlpass에서 클라이언트 수신기 용 SQL Server Alwayson 내부로드 밸런서 구성

2 가지 배치 모델을 선택하십시오

이 기사에서 설명 할 내용은 Resource Manager 배포 모델에서 SQL Server Alwayson 내부 부하 분산 장치를 구성하는 것입니다.

알지 못했을 경우, Azure는 두 가지 배포 모델 인 자원 관리자 (ARM)와 클래식 배포를 제공합니다. 클래식 배치는 일을하는 "오래된"방식이며, ARM은 새로운 일을하는 방식입니다. Azure 문서 Understanding Resource Manager 배포 및 기본 배포에 설명 된대로 ARM을 사용하면 여러 가지 이점이 있습니다. 그러나 ARM이 가장 좋아하는 새로운 기능 중 하나는 Classic 배포 모델로 얻은 두 개의 오류 도메인이 아니라 가용성 세트 당 세 개의 오류 도메인을 가질 수 있다는 것입니다. 이는 SQL Server High Availability의 중요한 기능입니다.

리소스 관리자 배포 모델

세 가지 오류 도메인을 사용하면 두 노드 클러스터의 각 클러스터 노드와 파일 공유 감시 서버가 모두 서로 다른 오류 도메인에 있는지 확인할 수 있습니다. 이렇게하면 단일 오류 도메인의 실패가 클러스터의 둘 이상의 정족수 투표에 영향을 줄 가능성이 제거됩니다.

기본 배치 모델

두 개의 결함 도메인이있는 Classic Deployment 모델에서는 가용성 세트에 두 개의 클러스터 노드 만 넣을 수있었습니다. 최대한의 가용성을 얻으려면 파일 공유 감시를 다른 지리적 위치에 두어야했습니다. 클러스터 노드 중 하나와 동일한 오류 도메인에서 동일한 지리적 위치에 보관하지 않는 것이 보장되지 않았습니다. 이것은 단일 결함 도메인의 실패가 3 개의 정족수 중 2 개에 영향을 줄 수 있음을 의미합니다. 그것은 전체 클러스터를 파괴 할 것입니다. ARM의 세 가지 오류 도메인은 그러한 가능성을 제거합니다.

Azure Resource Manager

새로운 Azure 기능은 ARM에서만 도입되는대로 ARM은 분명히 갈 길이 멀다. 그러나 설명서는 가볍고 일부 기능은 아직 많이 제공되지 않습니다.  ExpressRoute에 대한 문서화 된 지원 등을 포함합니다. 이 두 가지 문제는 거의 매일 더 좋아집니다. Azure가 따라 잡을 때까지 얼리 어답터는 실제로 열심히해야합니다. 한 가지 다른 문제는 Classic 및 ARM 배포를 혼합 할 수 없다는 것입니다. 클래식 배포로 시작한 경우 기본적으로 리소스 관리자를 사용하여 처음부터 다시 시작해야합니다. 당신이 지금 약간의 고통을 관리 할 수 ​​있다면, 내년에 더 큰 두통을 피하는 데 도움이 될 것입니다. 특히 ARM에서 사용할 수있는 몇 가지 새로운 기능을 원한다는 것을 알게되면 더욱 그렇습니다.

고 가용성 SQL Server 가져 오기

이 기사가 ARM 배포의 측면 중 하나 이상에 도움이 되었기를 바랍니다. 가용성이 높은 SQL Server를 배포하는 것입니다. 이전 기사에서 설명했듯이 Azure "Classic"에 AlwaysOn 가용성 그룹과 AlwaysOn 장애 조치 클러스터 인스턴스를 배포하려면 클라이언트 리디렉션을 위해 Azure Load Balancer (내부 또는 외부)를 사용해야합니다. Classic Azure에서 설정 한 것을 얻는 것은 정확하지 않습니다. Azure, Failover Clustering, SQL Server 및 PowerShell에 익숙한 관리자라면 누구나 제대로 작동 할 수 있습니다.

ILB 구성 및 SQL 클러스터 IP 자원 업데이트

ARM 배포 모델을 사용하는 AlwaysOn 가용성 그룹 및 AlwaysOn 장애 조치 (failover) 클러스터 인스턴스는 여전히 클라이언트 리디렉션을 위해 Azure Load Balancer를 사용해야합니다. 그러나로드 밸런서를 생성하고 구성하는 단계는 완전히 다릅니다. 오늘 현재로, 그것은 또한 정확하게 잘 문서화되지 않습니다.

이 기사에서는 SQL Server AlwaysOn 내부 부하 분산 장치를 구성하고 SQL 클러스터 IP 리소스를 업데이트하는 데 필요한 단계를 강조합니다. 다음 기사에서는 vNet 작성에서부터 SQL 설치 및 클러스터 작성에 이르기까지 전체 프로세스 단계를 단계별로 안내합니다.

여기에 우리가 간다.

시작하기 전에 다음과 같은 가정을하고 있습니다.

• ARM을 사용하여 vNet 생성
• 프로비저닝 된 3 ARM 기반 VM (DC, SQL1, SQL2)
• DC, SQL1 및 SQL2를 동일한 가용성 세트 및 자원 그룹에 넣습니다.
• SQL1과 SQL2를 사용하여 클러스터를 만들고 파일 공유 감시에 DC를 사용했습니다.
• SIOS DataKeeper Cluster Edition을 사용하여 AlwaysOn 가용성 그룹 또는 AlwaysOn 장애 조치 (Failover) 클러스터 인스턴스를 만들었습니다. 두 경우 모두 이름 리소스와 IP 리소스로 구성된 클라이언트 수신기를 사용합니다. 부하 분산 장치를 만들 때까지 AlwaysOn AG 및 장애 조치 (Failover) 클러스터 인스턴스 구성은 Azure Classic 배포 모델과 완전히 동일합니다. 그것은 내 자신의 블로그 게시물을 포함한 여러 장소에서 웹에 문서화되어 있습니다

빠른 팁

이제 완전히 구성된 AlwaysOn AG 또는 장애 조치 (Failover) 클러스터 인스턴스가 생겼으므로 현재 SQL 클러스터 이름 리소스를 호스팅하는 노드 이외의 서버에서 클러스터 이름에 연결할 수 없습니다. 나는 이것이 Azure 네트워킹이 무상 ARPS를 지원하지 않기 때문이라고 들었다. 따라서 클라이언트는 클러스터 IP 주소와 직접 통신 할 수 없습니다. 대신 클라이언트는 ILB와 통신해야하며 ILB는 트래픽을 활성 노드로 리디렉션합니다. 그래서 1 단계는 ILB를 만드는 것입니다. Azure Portal을 통해이 작업을 수행 할 수 없으므로 다음 Azure PowerShell 명령을 사용합니다.

[1/6/2016 Update – The directions below assume you are using Azure PowerShell pre-version 1. The script if you are using Azure PowerShell Version 1 or later is detailed in my blog post here.]

스위치 - AzureMode - 이름 AzureResourceManager

Select-AzureSubscription -SubscriptionName "MSDN Azure"
# vNet 및 VM을 만드는 데 사용했던 가입 이름

# 배포와 관련된 값을 사용하여 변수 선언

$ ResourceGroupName = 'SIOS-EAST-RG'
# SQL 노드가 배포 된 자원 그룹 이름

$ FrontEndConfigurationName = 'FE'
# 당신이 좋아하는대로 불러주세요.

$ BackendConfiguratioName = 'BE'
# 당신이 좋아하는대로 불러주세요.

$ LoadBalancerName = 'ILB'
# 내부 로컬 잔액 개체의 이름 지정

$ 위치 = 'eastus2'
# SQL VM의 데이터 센터 위치 입력

$ subname = 'PUBLIC'
# SQL 노드가있는 서브넷 이름을 제공하십시오

$ ILBIP = '10 .0.0.201 '
# 리스너 또는로드 밸런서의 IP 주소를 입력하십시오.

$ subnet = Get-AzureVirtualNetwork -ResourceGroupName $ ResourceGroupName |
Get-AzureVirtualNetworkSubnetConfig -name $ subname

$ FEConfig = New-AzureLoadBalancerFrontendIpConfig 
-Name $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id

$ BackendConfig = New-AzureLoadBalancerBackendAddressPoolConfig 
-Name $ BackendConfiguratioName

# ILB 작성
New-AzureLoadBalancer -Name $ LoadBalancerName -ResourceGroupName 
$ ResourceGroupName - 위치 $ 위치
-FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig

ILB가 생성됨

아래 그림과 같이 리소스 그룹에있는 모든 개체를 나열하면 Azure 포털에서 볼 수 있습니다.

나머지 구성은 PowerShell을 통해 수행 할 수도 있습니다. 그러나 필자는 GUI를 사용하려고합니다. PowerShell을 사용하려면 Azure Resource Manager를 사용하여 내부로드 밸런서 구성 시작하기 문서를 참조하여 스크립트를 작성하십시오. 솔직히 그 기사는 나에게 두통을 준다. 나는 언젠가 그것을 알아낼 것이고 그것을 사용자 친화적 인 형식으로 문서화하려고 노력할 것이다. 당분간은 GUI가 다음 단계에서 괜찮다고 생각합니다.

아래의 스크린 샷을 따르십시오. 길을 잃은 경우 Azure Portal 상단의 탐색 힌트를 따라 현재 위치를 파악하십시오.

백엔드 풀 설정 탭을 클릭하십시오. 백엔드 풀을 선택하여 가용성 세트 및 가상 시스템을 업데이트합니다. 변경 사항을 저장하십시오.

프로브 탭에서 추가를 눌러로드 밸 랜서의 프로브를 구성하십시오. 프로브 이름을 지정하고 TCP 포트 59999를 사용하도록 구성하십시오. 검사 간격과 비정상적인 임계 값을 기본 설정으로 유지했습니다. 즉, ILB가 장애 조치 후 활성 노드 목록에서 패시브 노드를 제거하기까지는 10 초가 걸립니다. 또한 클라이언트가 새 활성 노드로 리디렉션되는 데 최대 10 초가 걸릴 수도 있음을 의미합니다. 변경 사항을 저장하십시오.

로드 균형 조정 규칙 탭으로 이동하여 새 규칙을 추가하십시오. 규칙에 적절한 이름을 지정하십시오 (SQL1433 또는 기타). TCP 프로토콜 포트 1433을 선택합니다 (SQL Server의 기본 인스턴스를 사용한다고 가정). 백엔드 포트에 대해서도 1433을 선택하십시오. 백엔드 풀의 경우 이전에 만든 백엔드 풀을 선택합니다 (BE). 다음으로 프로브에 대해 이전에 생성 한 프로브를 선택합니다. 세션 지속성은 사용하지 않으려하지만 플로팅 IP (직접 서버 리턴)를 사용하고자합니다. 유휴 시간 제한을 기본 설정으로 두었습니다. 하지만 그 값을 최대 값으로 늘리는 것이 좋습니다. 연결이 끊어지고 다시 설정되어야 할 때마다 SAP 로그 오류 메시지와 같은 일부 응용 프로그램을 보았습니다.

이 시점에서 ILB가 구성됩니다. 일어날 필요가있는 단 하나의 최종 단계가 있습니다. Classic IP 배포 모델에서 SQL IP 클러스터 리소스를 업데이트해야합니다. 이를 수행하려면 클러스터 노드 중 하나에서만 다음 PowerShell 스크립트를 실행해야합니다. 그리고, SubnetMask = "255.255.255.255"는 실수가 아닙니다. 실제 서브넷 마스크에 관계없이 32 비트 마스크를 사용하십시오.

#이 스크립트는 기본 클러스터 노드에서 실행해야합니다. 
내부로드 밸런서가 생성됩니다.
# 변수 정의

$ ClusterNetworkName = "클러스터 네트워크 1"
# 클러스터 네트워크 이름

$ IPResourceName = "SQL IP 주소 1 (SQLCluster1)"
# IP 주소 자원 이름

$ CloudServiceIP = "10.0.0.201"
# 내부로드 밸런서의 IP 주소

가져 오기 모듈 장애 조치 클러스터

# Windows 2012 이상을 사용하는 경우, 
Get-Cluster Resource 명령을 사용하십시오. 
Windows 2008 R2를 사용하는 경우, 
주석 처리 된 cluster res 명령을 사용하십시오.

Get-ClusterResource $ IPResourceName
Set-ClusterParameter -Multiple @ { "Address"= "$ CloudServiceIP";
"ProbePort"= "59999"; SubnetMask = "255.255.255.255";
"Network"= "$ ClusterNetworkName"; "OverrideAddressMatch"= 1; "EnableDhcp"= 0}

# cluster res $ IPResourceName / priv enabledhcp = 0 
overrideaddressmatch = 1 address = $ CloudServiceIP probeport = 59999 
서브넷 마스크 = 255.255.255.255

최종 노트 1 개

초기 테스트에서 위의 모든 단계를 완료 한 후에도 여전히 SQL 리소스 이름에 연결할 수 없었습니다. 몇 시간 동안 벽에 머리를 꽂고 나면 SQL 클러스터 이름 리소스가 DNS에 등록되지 않은 것을 발견했습니다. 그 일이 어떻게 일어 났는지, 또는 그것이 계속 일어날 지 확신 할 수 없습니다. 연결에 문제가 있으면 DNS를 꼭 확인하십시오. 또한 SQL 클러스터 이름과 IP 주소가 아직없는 경우 새 레코드로 추가하십시오.

그리고 물론 좋은 Windows 방화벽을 잊지 마세요. 당신은 1433과 59999에 대한 예외를 만들거나 내가했던 것처럼 모든 것이 올바르게 설정 될 때까지 그냥 꺼야합니다. 어쨌든 로컬 Windows 방화벽 대신 Azure Network Security Groups를 활용하여 모든 Azure 리소스에 대해보다 통일 된 경험을 얻고 싶을 것입니다.

행운을 빌어 요, 리소스 관리자가있는 SQL Server AlwaysOn 내부로드 밸런서를 구성한 경험이 어떤지 알려주십시오.

https://clusteringformeremortals.com/2015/10/29/configuring-the-sql-server-alwayson-ilb-for-the-client-listener-in-azure-resource-manager-arm-deployment-the-client-listener-in-azure-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-resources-manager-arm-deployment-the-client-listener-in-azure-에서 권한을 재현했습니다 model-sqlpass /