단계별 : Azure Spanning Availability Zone에서 파일 서버 클러스터 구성

이 글에서는 새로운 가용 영역을 아우르는 2 노드 파일 서버 장애 조치 클러스터를 Azure에 배포하는 데 필요한 특정 단계에 대해 자세히 설명합니다. 기본 Azure 개념과 기본 장애 조치 클러스터 개념에 익숙하다고 가정합니다. 가용 영역에서 Azure에 파일 서버 장애 조치 클러스터를 배포하는 방법에 대해 중점적으로 다룰 것입니다. Azure 지역에서 아직 가용 영역을 지원하지 않는 경우 이전 게시물에서 설명한대로 오류 도메인을 사용해야합니다. DataKeeper Cluster Edition을 사용하면 프리미엄 디스크인지 표준 디스크인지에 관계없이 로컬로 연결된 관리 디스크를 가져 와서 둘 이상의 클러스터 노드간에 동 기적으로, 비동기 적으로 또는 혼합 또는 둘 모두로 해당 디스크를 복제 할 수 있습니다. 또한 DataKeeper 볼륨 리소스는 실제 디스크 리소스 대신 Windows Server 장애 조치 (Failover) 클러스터링에 등록됩니다. 물리적 디스크 리소스와 같은 SCSI-3 예약을 제어하는 ​​대신 DataKeeper 볼륨이 미러 방향을 제어합니다. 활성 노드가 항상 미러 소스임을 보장합니다. 페일 오버 클러스터링과 관련하여 물리적 디스크처럼 보이고 느끼고 냄새가 나며 실제 디스크 리소스와 동일한 방식으로 사용됩니다.

사전 요구 사항

• 이전에 Azure Portal을 사용해 왔으며 Azure IaaS에서 가상 시스템을 쉽게 배포 할 수 있습니다.
• SIOS DataKeeper의 라이센스 또는 평가판 라이센스를 취득한 경우

Azure에서 파일 서버 장애 조치 클러스터 배포

Azure에서 2 노드 파일 서버 장애 조치 클러스터 인스턴스를 작성하려면 Azure Resource Manager를 기반으로하는 기본 가상 네트워크가 있다고 가정합니다. 하나 이상의 가상 시스템이 실행 중이며 도메인 컨트롤러로 구성되어 있습니다. 가상 네트워크와 도메인이 구성되면 클러스터의 두 노드로 작동 할 두 개의 새로운 가상 시스템을 프로비저닝 할 것입니다. 우리의 환경은 다음과 같습니다. DC1 – 도메인 컨트롤러 및 파일 공유 미러링 모니터 SQL1 및 SQL2 – 파일 서버 클러스터의 두 노드입니다. 이름이 당신을 혼란스럽게하지 마라. 이 가이드에서는 파일 서버 클러스터를 구축 중입니다. 다음 글에서는 SQL Server 클러스터 구성을 보여줍니다.

두 개의 클러스터 노드 프로비저닝

Azure 포털을 사용하여 SQL1과 SQL2를 정확히 같은 방식으로 프로비저닝 할 것입니다.  인스턴스 크기, 저장 옵션 등을 선택할 수있는 다양한 옵션이 있습니다. 이 안내서는 Azure에 서버를 배포하는 데 필요한 모든 지침을 제공하지 않습니다. 거기에는 정말 좋은 자원이 많이 있으며 매일 더 많이 출간됩니다. 그러나 클러스터 된 환경에서 인스턴스를 만들 때 염두에 두어야 할 몇 가지 중요한 사항이 있습니다. 가용 영역 – SQL1, SQL2가 서로 다른 가용 영역에 있어야합니다. 이 가이드에서는 Windows 2016을 사용 중이며 클러스터 쿼럼에 대한 클라우드 감시를 사용한다고 가정합니다. Windows 2016 대신 Windows 2012 R2 또는 Windows Server 2008 R2를 사용하는 경우 파일 공유 감시를 보조 가용성 영역에 구성해야합니다. Cloud Witness는 Windows Server 2016까지 도입되지 않았습니다. 클러스터 노드를 서로 다른 가용 영역에 배치하여 각 클러스터 노드가 동일한 지역의 다른 Azure 데이터 센터에 있는지 확인합니다. 이전의 Fault Domains보다는 Availability Zones를 활용하는 것이 효과적입니다. 몇 주 전에 일어난 정전의 유형으로부터 당신을 격리 시켰기 때문에 사우스 센트럴 전역을 여러 날 동안 몰아 냈습니다. 각 클러스터 노드를 다른 가용 영역에 추가하십시오. 파일 공유 증인을 이용하면 제 3 가용 영역에 있어야합니다. [/ caption]

정적 IP 주소

각 VM을 프로비저닝 한 후에는 설정으로 이동하여 IP 주소가 정적이되도록 설정을 변경해야합니다. 클러스터 노드의 IP 주소가 변경되는 것을 원하지 않습니다. 각 클러스터 노드에서 고정 IP [/ caption]

저장

Storage에 관한 한, Azure 가상 시스템에서 SQL Server의 성능 모범 사례를 참조하십시오. 어떤 경우 든 각 클러스터 노드에 적어도 하나의 추가 관리 디스크를 최소한으로 추가해야합니다. DataKeeper는 기본 디스크, 프리미엄 저장소 또는 로컬 스토리지 공간에서 함께 스트라이프 된 여러 디스크를 사용할 수 있습니다. 로컬 스토리지 공간을 사용하려면 클러스터 구성 전에 스토리지 공간을 생성해야합니다. 이는 장애 조치 (failover) 클러스터링 및 로컬 저장소 공간과 관련된 알려진 문제가 원인입니다. 모든 디스크는 NTFS로 포맷해야합니다.

클러스터 만들기

위에서 설명한대로 두 클러스터 노드 (SQL1 및 SQL2)가 준비되어 기존 도메인에 추가되었다고 가정하면 클러스터를 만들 준비가 완료되었습니다. 클러스터를 만들기 전에 몇 가지 기능을 활성화해야합니다. 이러한 기능은 .NET Framework 3.5 및 장애 조치 (Failover) 클러스터링입니다. 이러한 기능은 두 클러스터 노드에서 모두 활성화해야합니다. 또한 FIle Server 역할을 사용 가능하게해야합니다. [/ caption] .Net Framework 3.5 및 장애 조치 (Failover) 클러스터링 기능과 두 클러스터 노드의 파일 서버를 모두 활성화합니다. [/ caption] 해당 역할과 해당 기능을 사용하도록 설정 한 후 클러스터 생성 후 DataKeeper 설치 [/ caption] 설치 중에 모든 기본 옵션을 사용할 수 있습니다.  사용하는 서비스 계정은 도메인 계정이어야하며 클러스터의 각 노드에있는 로컬 관리자 그룹에 있어야합니다. 서비스 계정은 각 노드의 로컬 관리자 그룹에있는 도메인 계정이어야합니다. 각 노드에 DataKeeper를 설치하고 라이센스를 부여한 후에는 서버를 다시 부팅해야합니다.

DataKeeper 볼륨 리소스 만들기

DataKeeper 볼륨 리소스를 생성하려면 DataKeeper UI를 시작하고 두 서버에 모두 연결해야합니다. SQL1에 연결 SQL2에 연결 [/ caption] 각 서버에 연결되면 DataKeeper 볼륨을 만들 준비가 된 것입니다. 작업을 마우스 오른쪽 단추로 클릭하고 "작업 작성"을 선택하십시오. 작업 이름과 설명을 입력하십시오. 원본 서버, IP 및 볼륨을 선택하십시오. IP 주소는 복제 트래픽이 이동할지 여부입니다. 대상 서버를 선택하십시오. 옵션을 선택하십시오. 두 VM이 동일한 지리적 영역에있는 우리의 목적을 위해 우리는 동기식 복제를 선택할 것입니다. 장거리 복제의 경우 비동기를 사용하고 일부 압축을 사용하고자 할 것입니다. 마지막 팝업에서 예를 클릭하면 장애 조치 클러스터링에서 사용 가능한 저장소에 새로운 DataKeeper 볼륨 리소스가 등록됩니다. 사용 가능한 저장소에 새 DataKeeper 볼륨 리소스가 표시됩니다.

파일 서버 클러스터 리소스 만들기

파일 서버 클러스터 리소스를 만들려면 장애 조치 클러스터 인터페이스가 아닌 Powershell을 다시 사용하십시오. 그 이유는 가상 머신이 DHCP를 사용하도록 구성 되었기 때문에 GUI 기반 마법사가 클러스터 IP 주소를 입력하라는 메시지를 표시하지 않고 대신 중복 된 IP 주소를 발행하기 때문입니다. 이를 방지하기 위해 간단한 powershell 명령을 사용하여 FIle 서버 클러스터 리소스를 만들고 IP 주소를 지정합니다

Add-ClusterFileServerRole - 저장소 "DataKeeper 볼륨 E"- 이름 FS2 -StaticAddress 10.0.0.101

여기에 지정한 IP 주소를 적어 두십시오. 네트워크의 고유 한 IP 주소 여야합니다. 나중에 내부로드 밸런서를 만들 때이 동일한 IP 주소를 사용합니다.

내부로드 밸런서 만들기

Azure의 장애 조치 클러스터링이 전통적인 인프라와 다른 점이 여기에 있습니다. Azure 네트워크 스택은 무상 ARPS를 지원하지 않으므로 클라이언트는 클러스터 IP 주소에 직접 연결할 수 없습니다. 대신 클라이언트는 내부 부하 분산 장치에 연결하고 활성 클러스터 노드로 리디렉션됩니다. 우리가해야 할 일은 내부로드 밸런서를 만드는 것입니다. 이 작업은 아래 그림과 같이 Azure Portal을 통해 수행 할 수 있습니다. 클라이언트가 공용 인터넷을 통해 연결하는 경우 공용로드 밸런서를 사용할 수 있습니다. 그러나 고객이 동일한 vNet에 상주한다고 가정하면 내부 부하 분산 장치를 생성합니다. 여기서 중요한 점은 가상 네트워크가 클러스터 노드가 상주하는 네트워크와 동일하다는 것입니다. 또한 지정한 개인 IP 주소는 파일 서버 클러스터 리소스를 만드는 데 사용한 주소와 정확히 동일합니다. 또한 가용 영역을 사용하기 때문에 아래 그림과 같이 영역 중복 표준로드 밸런서가 생성됩니다. 내부 부하 분산 장치 (ILB)를 만든 후에는 편집해야합니다. 우리가 할 첫 번째 일은 백엔드 풀을 추가하는 것입니다. 이 과정을 통해 두 개의 클러스터 노드를 선택하게됩니다. 다음으로 할 일은 프로브를 추가하는 것입니다. 우리가 추가 한 프로브는 포트 59999를 프로브합니다. 이 프로브는 클러스터에서 어떤 노드가 활성 상태인지 확인합니다. 마지막으로 SMB 트래픽 (TCP 포트 445)을 리디렉션하는로드 균형 조정 규칙이 필요합니다. 아래 스크린 샷에서 주목할 점은 Direct Server Return is Enabled입니다. 당신이 그 변화를 만들 었는지 확인하십시오.

파일 서버 IP 자원 수정

구성의 마지막 단계는 클러스터 노드 중 하나에서 다음 PowerShell 스크립트를 실행하는 것입니다. 이렇게하면 클러스터 IP 주소가 ILB 프로브에 응답 할 수 있습니다. 또한 클러스터 IP 주소와 ILB간에 IP 주소 충돌이 발생하지 않도록합니다. 받아 적기를 바랍니다; 사용자 환경에 맞게이 스크립트를 편집해야합니다. 서브넷 마스크는 255.255.255.255로 설정됩니다. 이것은 실수가 아니며 그대로 두십시오. 이것은 ILB와의 IP 주소 충돌을 피하기 위해 호스트 특정 라우트를 작성합니다.

# 변수 정의
$ ClusterNetworkName = "" 
# 클러스터 네트워크 이름 (Windows Server 2012에서 Get-ClusterNetwork를 사용하여 이름을 찾으십시오)
$ IPResourceName = "" 
# IP 주소 자원 이름 
$ ILBIP = "" 
# 내부로드 밸런서 (ILB)의 IP 주소
가져 오기 모듈 장애 조치 클러스터
# Windows Server 2012 이상을 사용하는 경우 :
Get-ClusterResource $ IPResourceName | Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"; 네트워크 = $ ClusterNetworkName; EnableDhcp = 0}
# Windows Server 2008 R2를 사용하는 경우 다음을 사용하십시오. 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999 subnetmask = 255.255.255.255

파일 공유 만들기

장애 조치 (Failover) 클러스터 관리자에서 파일 공유 마법사를 사용하면 작동하지 않습니다. 대신 Windows 탐색기에서 활성 노드의 파일 공유를 만듭니다. 장애 조치 클러스터링은 이러한 공유를 자동으로 선택하여 클러스터에 저장합니다. 이 구성에서는 파일 공유의 "연속 가용성"옵션이 지원되지 않습니다.

결론

가용 영역에 걸친 Azure에 파일 서버 장애 조치 클러스터가 작동해야합니다. DataKeeper 평가 키가 필요하면 http://us.sios.com/clustersyourway/cta/14-day-trial에 양식을 작성하십시오. SIOS는 귀하에게 발송 된 평가 키를 보내드립니다.