자료실

재해 복구를 위해 기존 SQL Server 장애 조치 클러스터 인스턴스를 클라우드로 확장하는 방법

6월 17, 2021 by Jason Aw Leave a Comment

재해 복구를 위해 기존 SQL Server 장애 조치 클러스터 인스턴스를 클라우드로 확장하는 방법

일반적으로 나는 이것을 가리킨다. DataKeeper 문서 누군가가 기존 SQL Server 장애 조치 클러스터 인스턴스를 재해 복구를 위해 클라우드로 확장하는 방법을 물을 때.

이 첫 번째 문서에서는 클러스터를 확장하고 기존 클러스터에 세 번째 노드를 추가하는 방법에 대해 설명합니다. 클러스터가 3 개의 노드를 지원한다면 괜찮습니다. 그러나 SQL Server Standard Edition을 사용하는 경우 Microsoft는 2 노드 클러스터로 제한합니다. 2- 노드 클러스터의 경우. 여전히 세 번째 노드로 복제 할 수 있습니다. 복구는 수동 프로세스에 가깝다는 점을 명심하십시오. 이 프로세스는 여기 .

사람들은 일반적으로이 지침을 읽고 약간 걱정합니다. 그들은 클러스터에서 열린 심장 수술을 수행하는 것처럼 느낍니다. 정말 셔츠를 갈아 입는 것과 같습니다! 단순히 클러스터 디스크 리소스를 DataKeeper 볼륨 리소스로 바꾸는 것입니다. 아래 비디오에서 볼 수 있듯이 프로세스는 몇 초 밖에 걸리지 않습니다.

비디오에서 보여주는 코드는 다음과 같습니다.

Stop-ClusterGroup SQLServerGroup Remove-ClusterResource -Name "Cluster Disk 1"Set-Disk -Number 4 -IsOffline $ False Set-Disk -Number 4 -IsReadOnly $ False Import-Module -Name Storage Set-Partition -DiskNumber 4 -PartitionNumber 1- NewDriveLetter X New-DataKeeperMirror -SourceIP 10.0.2.100 -SourceVolume X -TargetIP 10.0.1.10 -TargetVolume X -SyncType Sync New-DataKeeperJob -JobName "x drive"-JobDescription "sql data"-Node1Name primary.datakeeper.local -Node1IP 10.0. 2.100 -Node1Volume x -Node2Name dr.datakeeper.local -Node2IP 10.0.1.10 -Node2Volume X -SyncType Sync Add-ClusterResource -Name "DataKeeper Volume X"-ResourceType "DataKeeper Volume"-Group "SQLServerGroup"Get-ClusterResource "DataKeeper Volume X "| Set-ClusterParameter VolumeLetter X Get-ClusterResource -Name 'SQLServer'| Add-ClusterResourceDependency -Provider 'DataKeeper Volume X'Start-ClusterGroup SQLServerGroup

해당 코드를 실행 한 후에는 공유 볼륨 관리를 클릭하여 비디오에 표시된대로 DataKeeper 작업에 백업 노드를 추가해야합니다.

SQL Server Enterprise Edition이있는 경우 마지막 단계는 DR 노드에 SQL Server를 설치하고 기존 클러스터에 노드 추가를 선택하는 것입니다.

SQL Server Standard Edition을 사용하는 경우 작업이 완료된 것입니다. 당신은 단순히 따라갈 것입니다 이 지침 세 번째 노드의 데이터에 액세스 한 다음 복제 된 데이터베이스를 마운트합니다.

이러한 지침은 DR 노드가 클라우드에 있든 자체 DR 사이트에 있든 적용됩니다.

SQL Server 장애 조치 클러스터 인스턴스에 Amazon FSX 사용 정보

2월 14, 2021 by Jason Aw Leave a Comment

SQL Server 장애 조치 클러스터 인스턴스에 Amazon FSX 사용-알아야 할 사항!

AWS EC2에 자체 Microsoft SQL Server 인스턴스를 배포하려는 경우 솔루션의 복원력과 관련하여 몇 가지 결정을 내릴 수 있습니다. 물론, 서로 다른 가용 영역에 두 개 이상의 인스턴스를 배포하는 경우 AWS는 컴퓨팅 리소스에 대해 99.99 % SLA를 제공합니다. 그러나 속지 마십시오. 진정한 애플리케이션 가용성을 계산할 때 고려해야 할 다른 많은 요소가 있습니다. 최근에 클라우드에서 애플리케이션 가용성을 계산하는 방법에 대해 블로그에 올렸습니다. 계속 진행하기 전에 해당 기사를 빨리 읽어야 할 것입니다.

Microsoft SQL Server 인스턴스의 고 가용성을 보장하는 데 있어서는 Always On 가용성 그룹 (AG) 또는 SQL Server 장애 조치 클러스터 인스턴스 (FCI)의 두 가지 기본 선택이 있습니다. 이 기사를 읽고 있다면이 두 가지 옵션을 모두 잘 알고 있으며 SQL Server Always On AG 대신 SQL Server 장애 조치 클러스터 인스턴스를 사용하는 것을 진지하게 고려하고 있다고 가정하고 있습니다.

Microsoft SQL Server 장애 조치 클러스터 인스턴스의 이점

다음 목록은 AWS가 SQL Server FCI의 이점이라고 말하는 내용을 요약 한 것입니다.

FCI는 일반적으로 다음이 사용 사례의 우선 순위 문제인 경우 SQL Server 고 가용성 배포의 경우 AG보다 선호됩니다.

라이선스 비용 효율성 : AG를 실행하려면 SQL Server의 Enterprise Edition 라이선스가 필요하지만 FCI를 실행하려면 Standard Edition 라이선스 만 필요합니다. 이는 일반적으로 Enterprise Edition보다 50-60 % 저렴합니다. SQL Server 2016부터 Standard Edition에서 AG의 기본 버전을 실행할 수 있지만 AG 당 하나의 데이터베이스 만 지원하는 제한이 있습니다. 이는 SharePoint와 같은 여러 데이터베이스가 필요한 응용 프로그램을 처리 할 때 문제가 될 수 있습니다.

인스턴스 수준 보호 대 데이터베이스 수준 보호 : FCI를 사용하면 전체 인스턴스가 보호됩니다. 기본 노드를 사용할 수 없게되면 전체 인스턴스가 대기 노드로 이동됩니다. 이는 공유 저장소에 물리적으로 저장되는 시스템 데이터베이스에 저장된 SQL Server 로그인, SQL Server 에이전트 작업, 인증서 등을 처리합니다. 반면 AG에서는 그룹의 데이터베이스 만 보호되고 시스템 데이터베이스는 AG에 추가 될 수 없으며 사용자 데이터베이스 만 허용됩니다. 모든 AG 복제본의 시스템 개체에 대한 변경 사항을 복제하는 것은 데이터베이스 관리자의 책임입니다. 이로 인해 인적 오류가 발생하여 데이터베이스가 애플리케이션에 액세스 할 수 없게됩니다.

DTC 기능 지원 : SQL Server 2012 또는 2014를 사용하고 애플리케이션에서 DTC (Distributed Transaction Coordinator)를 사용하는 경우 AG가 지원되지 않으므로 사용할 수 없습니다. 이 상황에서 FCI를 사용하십시오.

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

클라우드에서 FCI의 과제

물론이야. 가용성 영역에 걸쳐있는 FCI를 구축하는 데있어 문제는 일반적으로 필요한 공유 저장 장치가 없다는 것입니다. 클러스터의 노드가 여러 데이터 센터에 분산되어 있기 때문에 기존 SAN은 공유 스토리지를위한 실행 가능한 옵션이 아닙니다. 따라서 클러스터 스토리지에는 SIOS DataKeeper와 같은 타사 스토리지 클래스 리소스 또는 새로운 Amazon FSx라는 두 가지 선택이 있습니다.

선택하기 전에 알아야 할 사항을 살펴 보겠습니다.

서비스 수준 계약

애플리케이션 가용성 계산 방법에서 작성한 것처럼 전체 애플리케이션 SLA는 가장 취약한 링크만큼만 좋습니다. 이 경우 99.9 %의 FSx SLA입니다.

일반적으로 99.99 % 가용성은 "고 가용성"으로 간주되는 시작점을 나타냅니다. 두 개 이상의 가용 영역에 배포 될 때 AWS가 컴퓨팅 리소스에 대해 약속하는 것입니다.

3 개의 9와 4 개의 9의 차이를 몰랐다면…

99.9 % 가용성으로 매월 43.83 분의 다운 타임 가능
99.99 %의 가용성으로 매월 4.38 분의 다운 타임 만 허용

99.99 %의 컴퓨팅 가용성에도 불구하고 FSx에서 클러스터 스토리지를 호스팅하면 전체 애플리케이션 가용성이 99.9 %가됩니다. 반대로 DataKeeper 배포와 같이 가용성 영역에 걸쳐있는 EBS 볼륨은 스토리지 및 컴퓨팅 계층 모두에서 99.99 % SLA를 충족합니다. 이는 전체 애플리케이션 가용성이 99.99 %임을 의미합니다.

저장 위치

고 가용성을 위해 FSx를 구성 할 때 다중 AZ 지원을 사용하는 것이 좋습니다. 다중 AZ를 활성화하면 효과적으로 "선호"AZ와 "대기"AZ를 갖게됩니다. SQL Server FCI 노드를 배포 할 때 해당 노드를 동일한 AZ에 배포하려고합니다.

이제 정상적인 상황에서 활성 클러스터 노드가 기본 FSx 스토리지 노드와 동일한 AZ에 있는지 확인해야합니다. 이는 스토리지의 거리와 대기 시간을 최소화하기위한 것입니다. 또한 AZ 간의 데이터 전송과 관련된 비용을 최소화합니다. FSx 가격 가이드에 명시된대로 '파일 시스템에 대한 AZ 간 또는 리전 간 액세스에는 표준 데이터 전송 요금이 적용됩니다.'

SQL Server FCI 오류가 있지만 FSx 오류가 아닌 불행한 상황에서는 저장소와 컴퓨팅을 함께 연결할 메커니즘이 없습니다. FSx가 장애 조치되는 경우 자동으로 기본 가용성 영역으로 장애 조치됩니다. 그러나 모범 사례에 따르면 근본 원인 분석이 수행되고 일반적으로 유지 관리 기간 동안 장애 복구가 발생하도록 예약 될 때까지 보조 노드에서 SQL FCI가 계속 실행됩니다. 이로 인해 스토리지가 다른 AZ에 상주하여 추가 비용이 발생하는 상황이 발생합니다. 현재 수신 및 송신 모두 AZ에서 데이터를 전송하는 비용은 GB 당 $ 0.01입니다.

FSx 및 SQL Server FCI의 상태를 면밀히 주시하지 않으면 월말에 데이터 전송 요금이 표시 될 때까지 다른 지역에서 실행되고 있다는 사실을 알지 못할 수도 있습니다.

반대로 SIOS DataKeeper를 사용하는 구성에서 저장소 장애 조치는 SQL Server FCI 복구의 일부이므로 저장소가 항상 SQL Server 인스턴스로 장애 조치를 수행하도록합니다. 이렇게하면 SQL Server가 항상 활성 노드에 직접 연결된 EBS 볼륨을 읽고 쓸 수 있습니다. DataKeeper는 AZ 또는 리전간에 복제되는 쓰기 작업과 관련된 데이터 전송 비용을 발생시킵니다. 이 데이터 전송 비용은 DataKeeper에서 사용 가능한 압축을 사용하여 최소화 할 수 있습니다.

장애 조치 제어

FSx 다중 서브넷 구성에는 선호 가용성 영역과 대기 가용성이 있습니다. 선호 가용성 영역의 FSx 파일 서버에 오류가 발생하면 대기 AZ의 파일 서버가 복구됩니다. AWS는이 복구 시간이 표준 공유의 경우 약 30 초가 걸린다고보고합니다. 지속적으로 사용 가능한 파일 공유를 사용하여 Microsoft는이 장애 조치 시간이 15 초에 가까울 수 있다고보고합니다. 이 페일 오버 시간 동안 읽기 및 쓰기가 일시 중지 된 브라운 아웃이 발생하지만 복구가 완료되면 계속됩니다.

FSx 다중 사이트에는 자동 장애 복구가 활성화되어 있습니다. 즉, FSx의 계획되지 않은 모든 장애 조치에 대해 계획되지 않은 장애 복구도 발생합니다. 대조적으로, 일반적으로 SQL Server FCI에 계획되지 않은 장애 조치가 발생하면 보조 서버에서 실행 상태로 두거나 몇 시간 후 또는 다음 유지 관리 기간 동안 장애 복구를 예약합니다.

FSX에서 지원되지 않는 SQL SERVER ANALYSIS SERVICES CLUSTER

SSAS를 클러스터링하려면 SIOS DataKeeper와 같은 클러스터 된 디스크 리소스가 필요합니다. SQL Server Analysis Server를 클러스터링하는 방법 백서에는 SMB를 사용할 수 없으며 드라이브 문자가있는 클러스터 드라이브를 사용해야한다고 명시되어 있습니다. 반대로 DataKeeper Volume 리소스는 자체적으로 클러스터 된 디스크로 표시되며 SSAS와 함께 사용할 수 있습니다.

요약

FSx는 Windows 사용자 파일 및 99.9 % 가용성 SLA로 충분한 기타 중요하지 않은 서비스와 같은 일반적인 SMB 사용에 확실히 적합 할 수 있지만, 애플리케이션에 고 가용성 (99.99 %) 또는 확장되는 HA / DR 솔루션이 필요한 경우 FSx는 탁월한 옵션입니다. SIOS DataKeeper가 적합합니다.

Clusteringformeremortals의 허가를 받아 복제

Azure 가상 컴퓨터에서 SQL Server 장애 조치 (failover) 클러스터 인스턴스 구성

4월 4, 2019 by Jason Aw Leave a Comment

Msdtc #Sql #Azure #Msdtc를 사용하여 Azure 가상 컴퓨터에서 SQL Server 장애 조치 (failover) 클러스터 인스턴스 구성

SQL Server 2008에서 최신 버전을 통해 Azure에 SQL Server 장애 조치 (Failover) 클러스터 인스턴스 (FCI)를 구축하기위한 단계별 가이드가 많이 포함되어 있음을 알고 계실 것입니다. 다음은 시작하기위한 몇 가지 링크입니다. 그러나 실제로 Windows와 SQL Server의 서로 다른 버전간에 구성에는 약간의 차이가 있습니다. 그래서 당신이 사용하는 버전에 관계없이 그것을 파악할 수있을 것이라고 생각합니다. 단계별 : Microsoft SQL Server 2008 R2 실패 클러스터 인 스턴스를 AZURE로 구성하는 방법 해결되지 않은 것은 MSDTC에 대해해야 할 일입니다. Microsoft는이 기사에서이 내용을 게시했습니다. https://blogs.msdn.microsoft.com/sql_pfe_blog/2018/07/05/configure-sql-server-failover-cluster-instance-on-azure-virtual-machines-with-msdtc 그러나 해당 기사 / 비디오 전용 SQL Server 2016 이상을 다룹니다. 좋은 소식은 대부분의 지침이 SQL Server 2008/2012/2014에 적용될 수 있다는 것입니다. 적절한 단계별 가이드를 할 시간이 있기까지는 기본 메모를 적어두고 더 많이 생각 나게했습니다. 그러나 그 동안에도이 정보가 유용 할 수 있습니다. 아래 단계에서는 Azure에 SQL Server FCI를 이미 만들고 DTC 리소스를 클러스터링했다고 가정합니다. 해당 단계에 대한 자세한 내용은 위 가이드를 참조하십시오. 아래 단계는 실제로 Azure에서 필요한로드 밸런서 구성을 자세히 설명하여이 작업을 수행하는 것입니다.

MSDTC 용로드 밸런서 만들기

MSDTC 리소스에는 자체 부하 분산 장치가 필요합니다. 새로운로드 밸런서를 만드는 대신 SQL Server FCI 용으로 이미 구성된로드 밸런서에 새로운 프론트 엔드를 추가합니다. 물론이 프론트 엔드 IP 주소는 클러스터 된 MSDTC 리소스와 연결된 클러스터 IP 주소와 일치해야합니다. 백엔드 풀의 경우 SQL 클러스터 노드가 포함 된 기존 풀을 다시 사용하기 만하면됩니다. MSDTC 리소스 전용의 새 상태 프로브를 만들어야합니다. 사용하는 포트는 SQL 자원에 사용했던 포트와 달라야합니다. 59999를 사용하지 마십시오. 아마도 49999와 같은 것을 사용할 것입니다. 마지막 단계는 MSDTC에 대한로드 균형 조정 규칙을 만드는 것입니다. 새 규칙을 만들고 방금 만든 MSDTC 프론트 엔드와 기존 백엔드를 참조하십시오. 다음으로 새로운로드 밸런싱 규칙을 만들어야합니다. MSDTC는 큰 범위의 포트 인 임시 포트를 사용합니다. 규칙을 만들 때 "HA 포트"라는 상자를 선택해야합니다. 마지막으로 Direct Server Return이 활성화되어 있는지 확인하십시오.

MSDTC 클러스터 IP 리소스 업데이트

SQL Server 클러스터 IP 주소와 같은 기능을합니다. MSDTC 클러스터 IP 리소스가 방금 생성 한 상태 프로브에 응답하는 Powershell 명령을 실행하여 포트 49999를 프로브해야합니다. 또한 MSDTC 클러스터 IP 주소의 서브넷 마스크를 255.255.255.255로 설정하여 동일한 주소를 공유하는로드 밸런서 프런트 엔드와의 IP 주소 충돌을 방지합니다.

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

그것이 작동하는지 확인하십시오!

DTCPing을 사용하거나 구성 요소 서비스로 이동하여 Computers> My Computers> Distributed Transaction Coordinator에서 로컬 DTC 및 클러스터 된 DTC를 볼 수 있습니다. 모든 분산 트랜잭션은 로컬 DTC가 아니라 클러스터 된 DTC에 나타나야합니다. 테스트를 위해 분산 트랜잭션을 작성하는 방법에 대한 예제는이 비디오를 확인하십시오.

다음 단계

이것은 빠르고 더러운 가이드입니다. 숙련 된 사용자는 MSDTC 리소스를 Azure에서 실행해야합니다. 가까운 장래에 세부적인 단계별 가이드를 게시 할 예정입니다. 그동안 방해가되면 Twitter @daveberm에서 나에게 연락을 주저하지 마세요.

DataKeeper를 사용하여 SQL Server 고 가용성 재해 복구 달성

3월 26, 2019 by Jason Aw Leave a Comment

항상 가용성 그룹 및 SANless SQL Server 장애 조치 (Failover) 클러스터 인스턴스가 혼합 된 SQL Server 고 가용성, 재해 복구 구현

소개

FCI (Always On Availability Groups)와 SQL Server 장애 조치 (FCI) 인스턴스를 함께 사용하는 것에 대한 내용은 잘 설명되어 있습니다. 그러나 솔루션의 SQL Server FCI 부분이 공유 저장소를 사용한다고 가정하는 사용 가능한 대부분의 설명서 문서 구성. Storage Spaces Direct (S2D)를 사용하여 SANless SQL Server FCI를 구축하려는 경우에도 SQL Server AG를 추가 할 수 있습니까? 불행히도이 질문에 대한 대답은 '아니오'입니다. 현재까지 S2D 기반 SQL Server FCI와 Always On AG의 조합은 지원되지 않습니다. 이전에이 S2D 제한 사항에 대해 이전에 블로그에 올렸습니다. 그러나 좋은 소식은 SIOS DataKeeper를 사용하여 SANless SQL Server FCI를 구축 할 수 있으며 읽을 수있는 보조 도메인과 같은 것들에 대해 Always On AG를 활용할 수 있다는 것입니다. 기존의 SAN 기반 SQL Server FCI와 Always On AG를 혼합 할 때 적용되는 것과 동일한 규칙을 준수해야하지만 SQL Server 고 가용성을 달성하기위한 대부분의 부분은 거의 같습니다. DataKeeper 동기식 복제는 일반적으로 동일한 데이터 센터 또는 클라우드 지역의 노드간에 사용되지만 재해 복구를 위해 다른 지역의 추가 노드에 비동기 적으로 복제하고자 할 수 있습니다. 이 경우 예기치 않은 오류가 발생한 후에 DR 노드를 온라인 상태로 전환해야하는 경우 Always On AG 구성을 폐기하고 재구성해야합니다. 이 요구 사항은 VM 내부에서 실행되는 SQL Server Always On AG의 비동기 스냅 샷 복원과 관련하여 Microsoft가 여기에서 발표 한 내용과 매우 유사합니다.

가용성 그룹

기본적으로 DataKeeper를 사용하는 SANLess SQL Server 장애 조치 (Failover) 클러스터 인스턴스는 Always Availability Group Wizard와 관련하여 SQL Server의 단일 인스턴스처럼 보입니다. Always On AG의 구성은 두 개의 독립 실행 형 (클러스터되지 않은) SQL Server 인스턴스간에 Always On AG 만 작성한 경우와 완전히 동일합니다. 이 구성에서 모든 서버가 동일한 장애 조치 (failover) 클러스터에 있다는 사실에 혼란이 생깁니다. 그러나 SQL Server FCI는 SQL Server가 클러스터 된 SQL Server 인스턴스로 설치된 클러스터 노드에서만 실행되도록 구성됩니다. 다른 노드는 동일한 클러스터에 있습니다. 그러나 SQL은 이러한 노드에 클러스터 된 인스턴스가 아닌 독립 실행 형 SQL Server 인스턴스로 설치됩니다. 다소 혼란 스럽습니다. 근본적으로 일어나는 일은 Always On AG가 WSFC 쿼럼 모델과 청취자를 활용한다는 것입니다. 이와 같이 모든 AG Replicas는 일반적으로 SQL Server의 클러스터 된 인스턴스를 실행하지 않더라도 동일한 WSFC에 있어야합니다. 당신이 완전히 혼란스러워해도 괜찮다면, 대부분의 사람들은 처음에이 하이브리드 구성 주위에서 머리를 감싸려고 할 때 혼란 스럽습니다. 이와 같은 구성의 실질적인 이점은 SQL Server 장애 조치 (Failover) 클러스터 인스턴스가 많은 환경에서 Always On AG보다 더 우수하고 비용 효율성이 높은 고 가용성 솔루션이 될 수 있지만 읽을 수있는 보조 복제본. 항상 읽기 가능한 보조 복제본을 추가하면이 필요성을 해결할 수있는 실행 가능한 옵션이됩니다. 또한 SIOS DataKeeper를 사용하면 SQL Server FCI 용 SAN이 필요하지 않으므로 노드가 다른 데이터 센터에있는 SQL Server FCI를 구성 할 수 있으며 Azure 및 SQL Server의 가용성 영역에 해당하는 SQL Server FCI도 지원됩니다. AWS. 아래 그림은 한 가지 가능한 구성 일뿐입니다. 다중 FCI 클러스터 노드, 다중 AG 및 다중 복제본이 모두 지원됩니다. SQL Server 버전에 따른 제한으로 인해 제한됩니다. 이 기사에서는 설치 단계를 문서화하는 것으로 보인다. 물론 여기서는 SQL FCI 용 공유 저장 장치 대신 SIOS DataKeeper를 사용하여 FCI를 작성합니다.

기본 가용성 그룹

SQL Server Standard Edition에서 "기본 가용성 그룹"을 축소하여 SQL Server Standard Edition에서도이 구성을 가능하게했습니다. 기본 AG는 가용성 그룹당 단일 데이터베이스, 단일 복제본 (2 노드)으로 제한됩니다. 그러나 읽기 가능한 보조 복제본을 지원하지 않으므로이 하이브리드 구성의 사용 사례가 매우 제한적입니다.

분산 가용성 그룹

SQL Server 2016에 도입 된 분산 형 AG는이 하이브리드 구성에서도 지원됩니다. 분산 AG는 일반 AG와 매우 유사하지만 복제본은 동일한 클러스터 또는 동일한 Windows 도메인에있을 필요가 없습니다. Microsoft는 다음과 같이 분산 가용성 그룹의 주요 사용 사례를 문서화합니다.

재해 복구 및보다 쉬운 다중 사이트 구성
새 하드웨어 또는 구성으로 마이그레이션 (새 하드웨어 사용 또는 기본 운영 체제 변경 포함)
여러 가용성 그룹에 걸쳐 단일 가용성 그룹에서 판독 가능한 복제본 수를 8 개 이상으로 늘림

개요

SQL Server 고 가용성을위한 SQL Server FCI에 대한 아이디어가 마음에 들면 읽기 전용 보조 복제본의 유연성을 원한다면이 하이브리드 솔루션이 당신이 찾고있는 것일 수도 있습니다. 전통적인 SAN 기반 SQL Server FCI 및 심지어 S2D (Storage Spaces Direct) 기반 FCI는 단일 데이터 센터로 제한됩니다. SIOS DataKeeper는 SAN 한계에서 벗어나 가용 영역 또는 클라우드 지역에 적용되는 SQL Server FCI와 같은 구성을 가능하게합니다. 또한 SAN에 의존하지 않으므로 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 포기하지 않고도 로컬로 연결된 고속 저장 장치를 활용할 수 있습니다.

* 돈을 저축하는 방법

앞서 SQL Server Standard Edition으로이 모든 작업을 수행하여 비용을 절감하는 방법을 알려 드리겠다고 약속했습니다. 특정 시점의 스냅 샷인 읽을 수있는 복제본으로 살아갈 수있는 경우 Always On AGs를 완전히 건너 뛸 수 있으며 SIOS DataKeeper 대상 측 스냅 샷 기능을 사용하여 진행중인 복제에 영향을주지 않으면 서 대상 서버의 볼륨 스냅 샷을 주기적으로 응용 프로그램에 적용 할 수 있습니다 또는 가용성. 방법은 다음과 같습니다.

SQL Server Standard Edition으로 2 노드 SQL Server FCI를 만들고 SQL 라이센스에 많은 비용을 절약하십시오. 또한보고 또는 DR 목적으로 클러스터 외부의 세 번째 노드에 데이터를 복제합니다. 이 세 x 째 서 v에서 볼륨의 스 냄샷을 작성할 경우이 스 냄샷은 읽기 쉽게 액세스 할 수 있습니다. 이렇게하면 SQL Server의 독립 실행 형 인스턴스에서 해당 데이터베이스를 탑재하여 월말 보고서를 실행하거나 아카이브로 복사하거나 해당 스냅 샷을 사용하여 QA 및 Test / Dev 환경을 최신 SQL로 쉽고 빠르게 업데이트 할 수 있습니다 데이터. 항상 가용성 그룹과 SANless SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 함께 사용하여 SQL Server 고 가용성, 재해 복구를 달성하기위한 가이드를 찾았다면 좋겠습니다.

S2D SQL Server 장애 조치 (Failover) 클러스터 인스턴스

9월 8, 2018 by Jason Aw Leave a Comment

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 직접적인 저장소 공간

Windows Server 2016 Datacenter Edition이 도입됨에 따라 Storage Spaces Direct (S2D)라는 새로운 기능이 도입되었습니다. 매우 높은 수준에서 S2D For SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 사용하면 로컬로 연결된 저장소를 함께 풀링하여 스케일 아웃 파일 서버에서 사용할 CSV로 클러스터에 표시 할 수 있습니다. 그런 다음 SMB 3을 통해 액세스 할 수 있으며 Hyper-V VMDK 파일과 같은 클러스터 데이터를 보유하는 데 사용됩니다. 또한 응용 프로그램과 데이터가 모두 동일한 서버 집합에서 실행될 수 있도록 하이퍼 수렴 (HCI) 방식으로 구성 할 수 있습니다. 이것은 지나치게 단순화 된 설명이지만 자세한 내용은 여기를 참조하십시오.

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview에서 가져온 이미지 주요 대상은 Hyper-V 배포를위한 하이퍼 – 컨버전스 인프라입니다. 그러나이 SMB 저장소를 활용하여 SQL Server 장애 조치 (Failover) 클러스터 인스턴스에서 사용할 SQL Server 데이터를 저장하는 등의 다른 사용 사례가 있습니다

왜 누군가는 그것을하고 싶습니까?

이제는 공유 스토리지가 필요없이 SQL Server Standard Edition을 통해 고 가용성 2 노드 SQL Server 장애 조치 (Failover) 클러스터 인스턴스 (FCI)를 구축 할 수 있습니다. 이전에 SAN없이 HA를 원한다면 SQL Server Enterprise Edition을 구입하고 항상 가용성 그룹을 사용하거나 SIOS DataKeeper를 구입하고 모든 버전의 Windows 또는 SANless 클러스터를 구축 할 수있는 타사 솔루션을 활용해야했습니다. SQL 서버. SQL Server Enterprise Edition은 특히 가용성 그룹 기능을 위해 SQL Server Enterprise Edition을 구입하는 경우 프로젝트 비용을 크게 높일 수 있습니다. 가용성 그룹과 관련된 비용 외에도 AG를 통해 장애 조치 (failover) 클러스터를 선호 할 수있는 여러 가지 기술적 인 이유가 있습니다. 응용 프로그램 호환성, 인스턴스 대 데이터베이스 수준 보호, 많은 수의 데이터베이스, DTC 지원, 숙련 된 직원 등은 장애 조치 (Failover) 클러스터 인스턴스를 유지하려는 기술적 이유 중 일부에 지나지 않습니다.

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 SIOS DataKeeper 솔루션 대 S2D

Microsoft는 SIOS DataKeeper 솔루션과 S2D 솔루션을 SQL Server FCI를 지원하는 두 가지 솔루션으로 여기에 설명합니다. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr 두 가지 솔루션을 비교할 때 다음을 고려해야합니다. SIOS는 1999 년부터 SANless 클러스터를 구축 할 수있게 해줍니다. 그러나 S2D For SQL Server 장애 조치 (Failover) 클러스터 인스턴스는 초기 단계입니다. 그렇다고해서 S2D가 따라 잡을만한 부분이있을 것입니다. 또는 단순히 기술의 한계로 인해 지원되지 않는 기능입니다.

SANless 클러스터 솔루션을 선택하기 전에

SANless 클러스터 솔루션을 선택하기 전에 고려해야 할 몇 가지 사항에 대한 개요는 다음 표를보십시오. S2D SQL Server 장애 조치 (Failover) 클러스터 인스턴스 이 차트를 살펴보면 SIOS DataKeeper에는 몇 가지 중요한 이점이 있음을 알 수 있습니다. 그 중 하나 인 DataKeeper는 Windows Server 2008 R2 및 SQL Server 2008 R2로 다시 돌아가는 훨씬 다양한 플랫폼을 지원합니다. S2D 솔루션은 Windows 및 SQL Server 2016/2017의 최신 릴리스 만 지원합니다. 또한 S2D는 Windows Datacenter Edition을 필요로하므로 배포 비용이 크게 추가 될 수 있습니다. 또한 SIOS는 온 – 프레미엄과 클라우드에서 모두 작동하는 Linux 용 SQL Server 전용 HA / DR 솔루션을 제공합니다.

차이점 분석

비용 및 플랫폼의 한계를 넘어, SANless 클러스터의 재난 복구 옵션을 고려할 때 가장 큰 차이가 발생한다고 생각합니다. SQL Server Cluster 전문가이자 동료 Microsoft Cloud 및 Datacenter 관리 MVP 인 Allan Hirt는 최근에이 S2D 제한에 대해 게시했습니다. 스토리지 공간 직접 방문 및 SQL Server FCI에 대한 기사에서 Allan은 사이트 전체에서 S2D 클러스터를 확장하거나 Always Availability 그룹에서 S2D 기반 클러스터를 다리로 포함 할 수있는 지원이 부족하기 때문에 S2D 시나리오는 로그 전달입니다! 나를 오해하지 마라. 로그 전달은 영원히 계속되었으며 내가 사라진 후 아마도 오래있을 것입니다. 그러나 다중 사이트 클러스터, 가용성 그룹 등과 같이 익숙해 진 모든 재해 복구 솔루션에 대해 생각할 때 거슬러 올라갑니다. 반면 SIOS DataKeeper 솔루션은 Always On Availability Groups를 완벽하게 지원합니다. 더 나은 방법은 RTI / RPO 관점에서 달성 할 수있는 최상의 HA / DR 솔루션을 제공하기 위해 여러 사이트에서 FCI를 확장 할 수 있습니다. Azure 환경에서 DataKeeper는 ASR (Azure Site Recovery)을 지원하므로 재난 복구를위한 더 많은 옵션을 제공합니다. 이 차트의 나머지 부분은 꽤 자명합니다. 기본적으로 S2D 클러스터를 배치하기 전에 충족시켜야하는 하드웨어, 스토리지 및 네트워킹 요구 사항 목록으로 구성됩니다. 여기에는 S2D 요구 사항의 철저한 목록이 있습니다. https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper. 무슨 좋은

SIOS DataKeeper 솔루션은 훨씬 관대합니다. 로컬로 연결된 모든 저장소를 지원하며 하드웨어가 클러스터 유효성 검사를 통과하면 지원되는 클러스터 구성입니다. 블록 레벨 복제 솔루션은 1Gbps가 고속 LAN으로 간주되고 T1 WAN 연결이 사치로 여겨지기 때문에 큰 성과를 거두었습니다. SANless 클러스터링은 클라우드 구축에 특히 유용합니다. 클라우드는 클러스터에 기존의 공유 스토리지 옵션을 제공하지 않습니다. 따라서 클라우드로 옮겨 가려는 사용자에게 클러스터를 가져 가려는 사용자는 대체 스토리지 솔루션을 고려해야합니다. 클라우드 배포의 경우 SIOS는 Azure, AWS 및 Google에 대한 인증을 받았으며 관련 클라우드 마켓에서 사용할 수 있습니다. Azure 또는 Google에서 S2D 기반 클러스터의 배포를 차단하는 것으로 보이는 것은 아니지만 해당 플랫폼에 대한 Microsoft의 설명서 또는 지원 가능성에 대한 언급이 눈에 띄지 않습니다.

안전한 선택 만들기

SIOS DataKeeper는 1999 년부터이 작업을 해오 고 있습니다. SIOS는 모든 기능 요청을 듣고 모든 버그를 밝혀 냈으며 시간을 테스트하고 입증 된 SANless 클러스터를위한 견고한 솔루션을 보유하고 있습니다. Microsoft S2D는 1 세대 제품으로 유망한 기술이지만 먼지가 잠길 때까지 기다렸다가 기능상의 차이로 인해 업무상 중요한 응용 프로그램으로 간주되기까지 기다릴 것입니다.

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 자세한 내용은 여기를 참조하십시오. Clusteringformeremortals.com의 허가를 받아 복제 한 SIOS DataKeeper