백서 : 저장 방법 10 가지 – AlwaysOn vs. 장애 조치 클러스터링

클러스터 솔루션을 선택하기 전에 묻는 10 가지 필수 질문

이 간략한 안내서를 다운로드하고 SQL 배치에 비용을 절감하고 완벽한 구성 유연성을 추가 할 수있는 10 가지 방법을 익히십시오. SQL Enterprise 등을 구입하지 않고도 SQL Server 2012에 대한 고 가용성 보호를 얻는 방법에 대해 알아보십시오.

백서 다운로드 : 10 가지 방법 – AlwaysOn vs. 장애 조치 클러스터링

Azure에서 SQL Server를 실행하기위한 저장소 고려 사항

Azure에서 SQL Server를 실행하기위한 저장소 고려 사항

Azure 또는 모든 클라우드 플랫폼에 SQL Server 배포? 오랜 기간 동안 사내 구축 환경에서 구축 한 것처럼 저장소를 프로비저닝하는 대신 Azure의 저장소를 사내 구축 환경에 액세스 할 수 있었던 저장소와 정확히 같지는 않습니다. 일부 전통적인 "모범 사례"는 추가 비용을 들여 최적의 성과를 내지 못할 수도 있습니다. 그러나 의도 한 이익을 제공하지는 않습니다. SQL Server 가상 컴퓨터의 Azure에 대한 성능 지침에서도 많은 논의를하고 있습니다.

디스크 유형

나는 여기에 UltraSSD, Premium Storage 또는 다른 디스크 유형을 사용해야한다고 말하지 않습니다. 옵션과 각 디스크 유형이 테이블에 가져 오는 것을 알고 있어야합니다. 물론 클라우드의 다른 모든 것과 마찬가지로 지출하는 돈이 많을수록 더 많은 전력, 속도, 처리량 등을 얻을 수 있습니다. 트릭은 스토리지 고려 사항에 적합한 최적의 구성을 찾는 것이므로 원하는 결과를 얻기에 충분할만큼의 시간을 소비합니다.

크기는 중요해

클라우드의 많은 것들과 마찬가지로 특정 사양이 함께 묶여 있습니다. 서버의 경우 더 많은 RAM을 원한다면 더 많은 CPU가 필요하지 않더라도 더 많은 CPU를 얻을 수 있습니다. 스토리지의 경우 IOPS, 처리량 및 크기가 모두 묶여 있습니다. 더 많은 IOPS를 원한다면 더 큰 디스크가 필요합니다. 더 많은 공간이 필요하면 더 많은 IOPS를 얻게됩니다. 물론 스토리지 클래스 간을 이동하여 어느 정도이를 피할 수 있지만 더 많은 IOPS가 필요하면 다른 스토리지 유형에서 더 많은 공간을 확보 할 수 있습니다. 가상 시스템 인스턴스의 크기도 중요합니다. 결국 저장소 구성과 관계없이 전체 처리량은 인스턴스 크기가 허용하는 범위 내에서 제한됩니다. 따라서 다시 한번 원하는 스토리지 성능을 달성하기 위해 필요한 것보다 많은 RAM과 CPU를 지불해야 할 수도 있습니다. 최대 IOPS 및 MBps 처리량에서 인스턴스 크기가 지원할 수있는 것이 무엇인지 이해하십시오. Azure에서는 인스턴스 크기가 스토리지 성능 문제로 인해 병목 현상이되는 경우가 많습니다.

RAID 0 사용

RAID 0은 전통적으로 스토리지 구성 옵션의 세 번째 요소입니다. 모든 RAID 옵션의 성능과 스토리지 활용도를 가장 잘 조합 할 수는 있지만 심각한 재해가 발생할 위험이 있습니다. RAID 0 스트라이프 세트의 하나의 디스크 만 실패하면 전체 스트라이프 세트가 실패합니다. 따라서 전통적으로 RAID 0은 데이터 손실이 허용되고 고성능이 바람직한 시나리오에서만 사용됩니다. 그러나 Azure 소프트웨어에서는 RAID 0이 바람직하며 많은 경우에 권장됩니다. Azure에서 RAID 0으로 어떻게 벗어날 수 있습니까? 대답은 쉽습니다. Azure 가상 머신 인스턴스에 표시하는 각 디스크는 이미 백엔드에 세 가지 중복성을 가지고 있습니다. 스트라이프 세트를 잃기 전에 여러 번 실패 할 필요가 있음을 의미합니다. RAID 0을 사용하면 여러 디스크를 결합 할 수 있습니다. 결합 된 스트라이프 세트의 전체 성능은 스트라이프 세트에 추가하는 각 추가 디스크에 대해 100 % 증가합니다. 따라서 예를 들어 10,000 IOPS의 요구 사항이있는 경우 Premium Storage가 P50으로 7,500 IOPS를 초과하므로 UltraSSD가 필요하다고 생각할 수 있습니다. 그러나 두 개의 P50을 RAID 0에 배치하면 최대 15,000 IOPS를 달성 할 수 있습니다. 이것은 많은 IOPS를 지원하는 Standard_F16s_v2 또는 이와 비슷한 크기의 인스턴스를 실행하고 있다고 가정합니다. Windows 2012 이상에서는 Simple Storage Space를 생성하여 RAID 0을 달성합니다. Windows Server 2008 R2에서 동적 디스크를 사용하여 RAID 0 스트라이프 볼륨을 생성 할 수 있습니다. 조심성있는 한마디. 로컬 스토리지 공간을 사용하고 DataKeeper를 사용하여 가용성 그룹 또는 SANless 장애 조치 클러스터 인스턴스를 구성하려는 경우 클러스터를 만들기 전에 스토리지를 구성하는 것이 가장 좋습니다. 그냥 알림. SQL Server 2008 R2 인스턴스를 Azure로 이동하는 데는 약 두 달 밖에 걸리지 않습니다. 높은 가용성을 보장하기 위해 Azure에 SQL Server 2008 R2 FCI를 배포하는 방법에 관한 저의 게시물을 확인하십시오.

로그 파일과 데이터 파일 분리하지 마라.

전통적으로 로그 및 데이터 파일은 서로 다른 실제 디스크에 상주합니다. 로그 파일에는 많은 쓰기 활동이 있고 데이터 파일에는 더 많은 읽기 활동이있는 경향이 있습니다. 따라서 때로는 스토리지가 이러한 특성을 기반으로 최적화됩니다. 또한 복구를 위해 로그와 데이터 파일을 다른 디스크에 보관하는 것이 바람직합니다. 적절한 백업 전략을 사용하여 데이터를 잃어 버리면 데이터 손실없이 데이터베이스를 복구 할 수 있습니다. 클라우드 기반 스토리지의 경우 단일 볼륨을 잃을 가능성이 매우 낮습니다. 이제 스토리지 고려 사항에 대해 생각하고 있습니다. 우연히 스토리지를 잃어 버렸다면 전체 스토리지 클러스터가 3 중 이중화와 함께 점심 식사를 먹었을 가능성이 큽니다. 따라서 로그를 E : logs에 넣고 F : data에 데이터를 넣는 것이 옳은 것처럼 느껴지지만 실제로는 스스로 해를 끼치고 있습니다. 예를 들어, 로그에는 P20을, 데이터에는 P20을 제공합니다. 각 볼륨의 크기는 512 GiB이고 2,300 IOPS로 제한됩니다. 로그 파일의 크기는 모두 필요하지 않을 수도 있습니다. 그러나 그것은 당신에게 당신의 데이터 파일을위한 성장의 여지가 충분하지 않을 수도 있습니다. 결국 여분의 공간을 위해 더 비싼 P30으로 이동해야합니다. 이 두 볼륨을 4,600 IOPS를 지원하는 멋진 1TB 볼륨으로 스트라이프하는 것이 훨씬 더 좋지 않습니까? 이렇게하면 로그 파일과 데이터 파일 모두 증가 된 IOPS를 이용할 수 있습니다. 또한 데이터 파일 용 P30 디스크로 이동하지 않아도 스토리지 활용도를 최적화하고 클라우드 스토리지 비용을 줄였습니다. 동일한 파일 및 파일 그룹을 보유합니다. 당신이하는 일에 대해 정말로 열심히 생각하십시오. 일단 클라우드로 이동하면 여전히 의미가 있는지 여부.  이해가되는 것은 과거에했던 일에 직관적이지 못할 수도 있습니다. 의심 스러울 때는 KISS 규칙 인 Keep It Simple Stupid를 따르십시오! 클라우드의 장점은 스토리지를 추가하거나 인스턴스 크기를 늘리거나 성능 대비 비용을 최적화하는 데 필요한 모든 작업을 수행 할 수 있다는 것입니다.

TempDB에 대해 수행 할 작업

로컬 SSD, 일명 D : 드라이브를 사용하십시오. D 드라이브는 tempdb에 가장 적합한 위치입니다. 로컬 드라이브이기 때문에 데이터는 "임시"로 간주됩니다. 서버가 이동되고 재부팅되면 손실 될 수 있음을 의미합니다. 괜찮아. Tempdb는 SQL이 시작될 때마다 재생성됩니다. 로컬 SSD는 빠르며 대기 시간이 짧습니다. 그러나 로컬이므로 읽기 및 쓰기가 인스턴스 크기의 전체 저장소 IOPS 제한에 기여하지 않습니다. 그래서 효과적으로 그것은 무료 IOPS입니다! 왜 우위를 차지하지 않겠습니까? SIOS DataKeeper를 사용하여 SANless SQL Server FCI를 구축하는 경우 미러링되지 않은 D 드라이브의 볼륨 리소스를 만들어야합니다. 이렇게하면 TempDB를 불필요하게 복제 할 필요가 없습니다.

마운트 포인트가 사용되지 않게 됨

탑재 지점은 SQL Server의 여러 인스턴스가 동일한 Windows 클러스터에 설치된 경우 SQL Server FCI 구성에서 일반적으로 사용됩니다. 이렇게하면 SQL Server 라이센스의 전체 비용이 절감됩니다. 서버 사용률을 높임으로써 비용을 절감 할 수 있습니다. 과거에 논의한 것처럼 일반적으로 각 SQL Server 인스턴스와 연결된 드라이브가 다섯 개 이상있을 수 있습니다. 각 드라이브가 드라이브 문자를 소비해야한다면 약 3 ~ 4 개의 인스턴스에서 문자가 부족합니다. 따라서 각 드라이브에 문자를주는 대신 마운트 지점을 사용하여 각 인스턴스가 단일 드라이브 문자 인 루트 드라이브로 서비스 될 수 있도록했습니다. 루트 드라이브에는 드라이브 문자가없는 별도의 물리적 디스크에 매핑되는 마운트 지점이 있습니다. 그러나 위에서 설명한 것처럼 개별 디스크를 많이 사용하는 개념은 클라우드에서 실제로 의미가 없습니다. 따라서 마운트 지점은 클라우드에서 쓸모 없게됩니다. 대신 설명 된대로 RAID 0 스트라이프를 만드십시오. 각 클러스터 된 인스턴스 SQL Server는 단순히 공간, 성능 및 비용에 맞게 최적화 된 고유 한 개별 볼륨을 갖습니다. 이것은 드라이브 문자가 부족한 문제를 해결합니다. 또한 클라우드 스토리지 비용을 줄이면서 스토리지 사용 및 성능을 훨씬 향상시킵니다.

결론

이 게시물은 점에서 벗어나 결정적인 가이드가 아닙니다. 이 게시물의 핵심은 Azure에서 SQL Server를 실행하는 것과 관련하여 클라우드 및 스토리지 고려 사항에 대해 다르게 생각하게하는 것입니다. 단순히 온 프레미스 (on-premise)에서 수행 한 작업을 클라우드에서 다시 생성하지 마십시오. 이는 거의 항상 최적의 성능보다 낮아지고 필요한 것보다 훨씬 많은 스토리지 비용을 초래합니다. Clusteringformeremortals.com의 허락을 받아 재현

Azure에서 Windows Server 2008 R2의 SQL Server 2008 R2 장애 조치 (failover) 클러스터 인스턴스 구성

단계별 : Azure의 Windows Server 2008 R2에서 SQL Server 2008 R2 장애 조치 (failover) 클러스터 인스턴스를 구성하는 방법

소개

2019 년 7 월 9 일에 SQL Server 2008 및 2008 R2에 대한 지원이 종료됩니다. 이는 정기적 인 보안 업데이트가 끝났음을 의미합니다. 그러나 SQL Server 인스턴스를 Azure로 옮길 경우 Microsoft는 추가 비용없이 3 년 동안 연장 보안 업데이트를 제공합니다. 현재 SQL Server 2008/2008 R2를 실행 중이고 7 월 9 일 이전에 SQL Server의 이후 버전으로 업데이트 할 수없는 경우 향후 보안 취약성에 직면 할 위험을 감수하기보다는이 제안을 활용하는 것이 좋습니다. . 패치되지 않은 SQL Server 인스턴스는 데이터 손실, 가동 중지 시간 또는 치명적인 데이터 유출로 이어질 수 있습니다.

Azure에서 SQL Server 2008/2008 R2를 실행할 때 직면하게 될 과제 중의 하나는 고 가용성을 보장하는 것입니다. 구내에서 고 가용성을 위해 SQL Server 장애 조치 클러스터 (FCI) 인스턴스를 실행하고 있거나 가상 컴퓨터에서 SQL Server를 실행하고 있으며 가용성을 위해 VMware HA 또는 Hyper-V 클러스터에 의존하고있을 수 있습니다. Azure로 이동할 때 사용할 수있는 옵션이 없습니다. Azure의 가동 중지 시간은 완화 조치를 취해야하는 매우 현실적인 가능성입니다.

가동 중지 시간을 줄이고 Azure의 99.95 % 또는 99.99 % SLA 자격을 얻으려면 SIOS DataKeeper를 사용해야합니다. DataKeeper는 Azure의 공유 저장 장치 부족을 극복하고 Azure에 SQL Server FCI를 구축 할 수있게하여 각 인스턴스에서 로컬로 연결된 저장소를 활용합니다. SIOS DataKeeper는이 가이드에 설명 된대로 SQL Server 2008 R2 및 Windows Server 2008 R2를 지원할뿐만 아니라 2008 R2에서 Windows Server 2019까지의 모든 버전의 Windows Server 및 SQL Server 2008에서 SQL Server 2019까지의 모든 버전의 SQL Server를 지원합니다 .

이 가이드는 Windows Server 2008 R2에서 실행되는 Azure에서 2 노드 SQL Server 2008 R2 장애 조치 (FCI) 인스턴스를 만드는 과정을 안내합니다. SIOS DataKeeper는 가용 영역 또는 영역에 걸쳐있는 클러스터도 지원하지만이 안내서는 각 노드가 동일한 Azure Region에 있지만 다른 오류 도메인에 있다고 가정합니다. SIOS DataKeeper는 일반적으로 SQL Server 2008 R2 FCI를 만드는 데 필요한 공유 저장소 대신 사용됩니다.

Azure에서 첫 번째 SQL Server 인스턴스 만들기

이 가이드는 Azure 마켓 플레이스에 게시 된 Windows Server 2008R2 이미지의 SQL Server 2008R2SP3을 활용합니다.

첫 번째 인스턴스를 프로비저닝 할 때 새 가용성 세트를 만들어야합니다. 이 과정에서 오류 도메인의 수를 3으로 늘리십시오. 이렇게하면 두 클러스터 노드와 파일 공유 감시 서버 각각이 자체 폴트 도메인에 상주 할 수 있습니다.

각 인스턴스에 디스크를 추가하십시오. Premium 또는 Ultra SSD를 권장합니다. SQL 로그 파일에 사용되는 디스크에서 캐싱을 사용하지 않습니다. SQL 데이터 파일에 사용되는 디스크에서 읽기 전용 캐싱을 사용합니다. 저장소 모범 사례에 대한 추가 정보는 Azure 가상 컴퓨터의 SQL Server 성능 가이드 라인을 참조하십시오.

가상 네트워크를 구성하지 않은 경우 만들기 마법사에서 새 가상 네트워크를 만들 수 있습니다.

인스턴스가 생성되면 IP 구성으로 이동하여 개인 IP 주소를 고정시킵니다. 이는 SIOS DataKeeper에 필요하며 클러스터 된 인스턴스의 모범 사례입니다.

DNS 서버를 로컬 Windows AD 컨트롤러로 설정하도록 가상 네트워크가 구성되어 있는지 확인하십시오. 이것은 나중에 도메인에 가입 할 수 있는지 확인하기위한 것입니다.

Azure에서 최종 SQL Server 인스턴스 만들기

위와 동일한 단계를 따르십시오. 이 인스턴스를 첫 번째 인스턴스로 만든 동일한 가상 네트워크 및 가용성 집합에 배치해야합니다.

FSW (File Share Witness) 인스턴스 만들기

WSFC (Windows Server 장애 조치 클러스터)가 최적으로 작동하려면 다른 Windows Server 인스턴스를 만들어 SQL Server 인스턴스와 동일한 가용성 집합에 배치해야합니다. 동일한 가용성 세트에 배치하여 각 클러스터 노드와 FSW가 다른 오류 도메인에 있는지 확인합니다. 따라서 전체 오류 도메인이 오프라인 상태가되면 클러스터가 온라인 상태를 유지하게됩니다. 이 인스턴스에는 SQL Server가 필요하지 않습니다. 그것은 단순한 파일 공유를 호스트하는 것만 큼 단순한 Windows 서버가 될 수 있습니다.

이 인스턴스는 WSFC에 필요한 파일 공유 감시를 호스팅합니다. 이 인스턴스는 동일한 크기 일 필요가 없으며 추가 디스크를 연결하지 않아도됩니다. 단순한 파일 공유를 호스팅하는 것이 유일한 목적입니다. 사실 다른 용도로 사용될 수 있습니다. 내 실험 환경에서 FSW는 또한 내 도메인 컨트롤러입니다.

SQL Server 2008 R2 제거

프로비저닝 된 두 SQL Server 인스턴스에는 이미 SQL Server 2008 R2가 설치되어 있습니다. 그러나 클러스터 된 인스턴스가 아닌 독립 실행 형 SQL Server 인스턴스로 설치됩니다. 클러스터 인스턴스를 설치하기 전에 이러한 각 인스턴스에서 SQL Server를 제거해야합니다. 가장 쉬운 방법은 아래와 같이 SQL Setup을 실행하는 것입니다.

setup.exe / Action-RunDiscovery를 실행하면 사전 설치된 모든 항목이 표시됩니다. 

setup.exe / Action-RunDiscovery

setup.exe / Action = Uninstall / FEATURES = SQL, AS, RS, IS, Tools / INSTANCENAME = MSSQLSERVER를 실행하면 제거 프로세스가 시작됩니다.

setup.exe / Action = Uninstall / FEATURES = SQL, AS, RS, IS, 도구 / INSTANCENAME = MSSQLSERVER

setup.exe / Action-RunDiscovery를 실행하면 제거가 완료 되었음이 확인됩니다.

setup.exe / Action-RunDiscovery

두 번째 인스턴스에서이 제거 프로세스를 다시 실행하십시오.

도메인에 인스턴스 추가

세 인스턴스 모두 Windows 도메인에 추가해야합니다.

Windows 장애 조치 (Failover) 클러스터링 기능 추가

장애 조치 (Failover) 클러스터링 기능을 두 SQL Server 인스턴스에 추가해야합니다.

Add-WindowsFeature 장애 조치 - 클러스터링

Windows 방화벽 끄기

간단히하기 위해 SQL Server FCI 설치 및 구성 중에 Windows 방화벽을 해제하십시오. Azure Network Security Best Practices에 문의하여 Azure 리소스 보안에 대한 조언을 얻으십시오. 필수 Windows 포트에 대한 자세한 내용은 여기, SQL Server 포트는 여기, SIOS DataKeeper 포트는 여기에서, 내부로드 밸런서에는 나중에 포트 59999 액세스가 필요합니다. 따라서 보안 구성에서이를 고려해야합니다.

NetSh Advfirewall이 allprofiles 상태를 해제합니다.

Windows Server 2008 R2 SP1 용 편의 롤업 업데이트 설치

Azure에서 Windows Server 2008 R2 인스턴스를 구성하는 데 필요한 중요 업데이트 (kb2854082)가 있습니다. 이 업데이트와 그 이상은 Windows Server 2008 R2 SP1 용 편의 롤업 업데이트에 포함되어 있습니다. 두 SQL Server 인스턴스 각각에이 업데이트를 설치하십시오.

스토리지 포맷

두 개의 SQL Server 인스턴스를 프로비저닝 할 때 첨부 된 추가 디스크를 포맷해야합니다. 각 인스턴스의 각 볼륨에 대해 다음을 수행하십시오.

마이크로 소프트 모범 사례는 다음과 같이 말합니다 …

"NTFS 할당 단위 크기 : 데이터 디스크를 포맷 할 때 데이터 및 로그 파일과 TempDB에 대해 64KB 할당 단위 크기를 사용하는 것이 좋습니다."

클러스터 유효성 검사 실행

클러스터 유효성 검사를 실행하여 모든 것이 클러스터 될 준비가되었는지 확인하십시오.

보고서에는 저장 및 네트워킹에 대한 경고가 포함됩니다. 공유 디스크가없고 서버간에 단일 네트워크 연결 만 있다는 것을 알기 때문에 경고를 무시할 수 있습니다. 또한 무시할 수있는 네트워크 바인딩 순서에 대한 경고를받을 수도 있습니다. 오류가 발생하면 계속하기 전에 해결해야합니다.

클러스터 만들기

Azure에서 클러스터를 만드는 가장 좋은 방법은 아래와 같이 Powershell을 사용하는 것입니다. Powershell을 사용하면 정적 IP 주소를 지정할 수 있지만 GUI 방법은 지정할 수 없습니다. 안타깝게도 Azure의 DHCP 구현은 Windows Server 장애 조치 (Failover) 클러스터링에서 제대로 작동하지 않습니다. GUI 방법을 사용하는 경우 클러스터 IP 주소로 중복 IP 주소가 표시됩니다. 그것은 세상의 종말은 아니지만, 내가 보여 주듯이 그것을 고쳐야 할 것입니다.

앞서 말했듯이 Powershell 방법이 일반적으로 가장 잘 작동합니다. 그러나 다음과 같이 Windows Server 2008 R2에서 어떤 이유로 인해 문제가있는 것으로 보입니다.

새 클러스터 -Name cluster1 -Node sql1, sql2 -StaticAddress 10.1.0.100 -NoStorage

당신은 그 방법을 시도해 볼 수 있습니다. 다시 돌아가서 이것이 우연인지 좀 더 조사해야합니다. Powershell이 작동하지 않는 경우 탐색 할 또 다른 옵션은 Cluster.exe입니다. cluster / create /?를 실행 중입니다. 더 이상 사용되지 않는 cluster.exe 명령을 사용하여 클러스터를 만드는 데 사용할 적절한 구문을 제공합니다.

그러나 Powershell 또는 Cluster.exe에서 실패한 경우 아래 단계에서는 클러스터에 할당 할 중복 IP 주소를 수정하는 등 Windows Server 장애 조치 (Failover) 클러스터링 UI를 통해 클러스터를 만드는 방법을 보여줍니다.

여기서 지정한 이름은 CNO (Cluster Name Object)입니다. 이 이름은 SQL 클라이언트가 클러스터에 연결하는 데 사용하는 이름이 아닙니다. 다음 단계에서 SQL Server 클러스터를 설정하는 동안이를 정의 할 것입니다. 

이 시점에서 클러스터가 만들어 지지만 중복 IP 주소 문제로 인해 Windows Server 장애 조치 (Failover) 클러스터링 UI로 클러스터에 연결할 수 없습니다.

Duplicate IP Address 수정

앞서 언급했듯이 GUI를 사용하여 클러스터를 작성하면 클러스터의 IP 주소를 선택할 기회가 제공되지 않습니다. 인스턴스가 DHCP를 사용하도록 구성 되었기 때문에 (Azure에서 필요함) GUI는 DHCP를 사용하여 자동으로 IP 주소를 할당하려고합니다. 안타깝게도 Azure의 DHCP 구현은 예상대로 작동하지 않으며 클러스터는 노드 중 하나에서 이미 사용중인 것과 동일한 주소를 할당합니다. 클러스터가 제대로 생성 되더라도이 문제를 해결해야만 클러스터에 연결할 수 있습니다.

이 문제를 해결하려면 노드 중 하나에서 다음 명령을 실행하여 해당 노드에서 클러스터 서비스가 시작되는지 확인하십시오.

net start clussvc / fq

동일한 노드에서 이제 IP 주소가 온라인 상태가되지 않은 것을 볼 수있는 Windows Server 장애 조치 (Failover) 클러스터링 UI에 연결할 수 있어야합니다.

클러스터 IP 주소의 등록 정보를 열고이를 DHCP에서 정적으로 변경하고 사용하지 않는 IP 주소를 할당하십시오.

이름 리소스를 온라인 상태로 만듭니다.

파일 공유 감시 기능 추가

다음으로 File Share Witness를 추가해야합니다. 우리가 FSW로 프로비저닝 한 세 번째 서버에서 폴더를 만들고 아래 그림과 같이 공유하십시오. 아래와 같이 공유 및 보안 수준에서 CNO (클러스터 이름 개체) 읽기 / 쓰기 권한을 부여해야합니다.

공유가 생성되면 클러스터 노드 중 하나에서 클러스터 쿼럼 구성 마법사를 실행하고 아래에 설명 된 단계를 수행하십시오.

DataKeeper를위한 서비스 계정 만들기

우리는 거의 DataKeeper를 설치할 준비가되었습니다. 그러나이 작업을 수행하기 전에 도메인 계정을 만들어 각 SQL Server 클러스터 인스턴스의 로컬 관리자 그룹에 추가해야합니다. DataKeeper를 설치할 때이 계정을 지정합니다.

DataKeeper 설치

아래 그림과 같이 두 SQL Server 클러스터 노드 각각에 DataKeeper를 설치하십시오.

여기서 각 로컬 도메인 관리자 그룹에 추가 한 도메인 계정을 지정합니다.

DataKeeper 구성

DataKeeper가 두 개의 클러스터 노드 각각에 설치되면 DataKeeper를 구성 할 준비가 된 것입니다.

참고 – 다음 단계에서 가장 흔히 발생하는 오류는 보안과 관련이 있으며, 주로 기존의 Azure Security 그룹이 필요한 포트를 차단하고 있습니다. 서버가 필요한 포트를 통해 통신 할 수 있는지 확인하려면 SIOS 설명서를 참조하십시오.

먼저 두 노드 각각에 연결해야합니다.

모든 것이 제대로 구성되면 서버 개요 보고서에 다음 내용이 표시되어야합니다.

다음으로 새 작업을 만들고 아래에 설명 된 단계를 따르십시오.

사용 가능한 저장소에 DataKeeper 볼륨 리소스를 등록하려면 여기에서 예를 선택하십시오.

각 볼륨에 대해 위의 단계를 완료하십시오. 완료되면 Windows Server 장애 조치 (Failover) 클러스터링 UI에서 다음을 볼 수 있습니다.

이제 SQL Server를 클러스터에 설치할 준비가되었습니다.

참고 -이 시점에서 복제 된 볼륨은 현재 Available Storage를 호스팅하고있는 노드에서만 액세스 할 수 있습니다. 예상 했으니 걱정하지 마라.

첫 번째 노드에 SQL Server 설치

첫 번째 노드에서 SQL Server 설치 프로그램을 실행합니다.

새 SQL Server 장애 조치 (Failover) 클러스터 설치를 선택하고 그림과 같은 단계를 수행하십시오.

필요한 옵션 만 선택하십시오. 

이 문서는 사용자가 SQL Server의 기본 인스턴스를 사용한다고 가정합니다. 명명 된 인스턴스를 사용하는 경우에는 수신 대기 포트를 잠그고 나중에로드 밸런서를 구성 할 때 해당 포트를 사용해야합니다. 또한 명명 된 인스턴스에 연결하기 위해 SQL Server Browser Service (UDP 1434)에 대한 부하 분산 장치 규칙을 만들어야합니다. 이 두 가지 요구 사항 중 어느 것도이 가이드에서 다루지 않습니다. 그러나 명명 된 인스턴스가 필요한 경우 두 가지 추가 단계를 수행하면 작동합니다.

여기서 사용하지 않는 IP 주소를 지정해야합니다.

데이터 디렉토리 탭으로 이동하여 데이터 및 로그 파일을 재배치하십시오. 이 가이드의 끝 부분에서는 최적의 성능을 위해 미러되지 않은 DataKeeper 볼륨에 tempdb를 재배치하는 방법에 대해 설명합니다. 지금은 클러스터 된 디스크 중 하나에 보관하십시오.

두 번째 노드에 SQL 설치

두 번째 노드에서 SQL Server 설치 프로그램을 다시 실행하십시오. 그런 다음 SQL Server 장애 조치 (failover) 클러스터에 노드 추가를 선택하십시오.

축하합니다. 거의 완료되었습니다! 그러나 Azure가 ARP를 지원하지 않기 때문에 다음 단계 에서처럼 클라이언트 리디렉션을 지원하기 위해 내부로드 밸런서 (ILB)를 구성해야합니다.

SQL 클러스터 IP 주소 업데이트

ILB가 제대로 작동하려면 클러스터 노드 중 하나에서 다음 명령을 실행해야합니다. SQL 클러스터 IP를 사용하면 SQL 클러스터 IP 주소가 ILB 상태 프로브에 응답하고 상태 프로브와의 IP 주소 충돌을 피하기 위해 서브넷 마스크를 255.255.255.255로 설정할 수 있습니다.

클러스터 res <IPResourceName> / priv enabledhcp = 0 주소 = <ILBIP> probeport = 59999 subnetmask = 255.255.255.255

참고 – 그것이 우연인지 나는 모른다. 때때로이 명령을 실행했지만 작동하는 것처럼 보이지만 작업이 완료되지 않아 다시 시작해야합니다. 작동 여부를 알 수있는 방법은 SQL Server IP 리소스의 서브넷 마스크를 보는 것입니다. 255.255.255.255가 아니라면 성공적으로 실행되지 않았다는 것을 알 수 있습니다.  단순히 GUI 새로 고침 문제 일 수 있습니다. 서브넷 마스크가 업데이트되었는지 확인하려면 클러스터 GUI를 다시 시작하십시오.

성공적으로 실행 한 후에는 리소스를 오프라인으로 전환 한 다음 다시 온라인으로 가져와 변경 내용을 적용하십시오.

로드 밸런서 만들기

마지막 단계는로드 밸런서를 만드는 것입니다. 이 경우 우리는 포트 1433에서 수신 대기하는 SQL Server의 기본 인스턴스를 실행하고 있다고 가정합니다.

부하 분산 장치를 만들 때 정의한 개인 IP 주소는 SQL Server FCI가 사용하는 주소와 완전히 동일합니다.

두 SQL Server 인스턴스를 백엔드 풀에 추가합니다. FSW를 백엔드 풀에 추가하지 마십시오.

이로드 밸런싱 규칙에서 유동 IP를 활성화해야합니다.

클러스터 테스트

가장 간단한 테스트는 패시브 노드에서 SQL Server Management Studio를 열고 클러스터에 연결하는 것입니다. 축하해! 연결하는대로 올바르게 했어! 연결할 수 없다면 두려워하지 마십시오. 문제를 해결하는 데 도움이되는 블로그 기사를 작성했습니다. 클러스터 관리는 기존의 공유 스토리지 클러스터를 관리하는 것과 완전히 동일합니다. 모든 것은 장애 조치 클러스터 관리자를 통해 제어됩니다.

선택 사항 – TempDB 재배치

최적의 성능을 위해 tempdb를 복제되지 않은 로컬 SSD로 옮기는 것이 좋습니다. 그러나 SQL Server 2008 R2에서는 tempdb가 클러스터 된 디스크에 있어야합니다. SIOS에는이 문제를 해결하는 비 미러 볼륨 리소스 (Non-Mirrored Volume Resource)라는 솔루션이 있습니다. 로컬 SSD 드라이브의 미러되지 않은 볼륨 리소스를 생성하고 거기에서 tempdb를 이동하는 것이 좋습니다. 참고로, 로컬 SSD 드라이브는 비 지속성입니다. tempdb를 보관하는 폴더와 해당 폴더에 대한 사용 권한이 서버를 다시 부팅 할 때마다 다시 만들어 지도록주의해야합니다.

로컬 SSD의 미러되지 않은 볼륨 리소스를 만든 후에는이 문서의 단계에 따라 tempdb의 위치를 변경하십시오. 이 기사에서 설명하는 시작 스크립트는 각 클러스터 노드에 추가되어야합니다.

Clusteringformeremortals.com의 허락을 받아 재현

비디오 : SQL Server 용 SANless 클러스터 구축

SQL Server 용 SANless 클러스터 구축

이 비디오에서 Dave Bermingham은 SIOS Protection Suite for SQL Server 사용에 대한 간단한 데모를 제공합니다.

GUI에서는 고 가용성 및 재난 복구 구성을 제공하기 위해 SQL Server 보호 기능을 구성합니다. 우리는 2 개의 서버에 연결되어있는 것을 볼 수 있습니다.  1 차 및 2 차 서버간에 장애 복구 프로세스를 생성하는 프로세스를 살펴 보겠습니다.

1. 의사 소통 경로 생성 : 우선 우리가하고 싶은 일은 의사 소통 경로를 만드는 것입니다. 의사 소통 경로는 전체 서버에 장애가있을 때이를 감지합니다.  마법사를 시작하여 통신 경로를 선택하고 로컬 서버를 먼저 선택한 다음 원격 서버를 선택합니다. 우리가 사용할 커뮤니케이션 하트 비트는 TCP 또는 표준 하트 비트입니다.  하트 비트 간격은 하트 비트를 보내는 빈도를 결정합니다.  기본값 인 6 초를 선택합니다.  최대 하트 비트는 실패가 발생하기 전에 얼마나 많은 박자를 놓칠 수 있는지입니다.  기본값은 5 초입니다.  본질적으로 30 초 후에 우리는 실패가 발생했는지를 결정할 것입니다. 마지막으로 하트 비트에 사용할 로컬 IP 주소를 선택한 다음 마법사를 완료합니다.

2. 리소스 계층 만들기 : 이제 통신 하트 비트가 설정되었으므로 리소스 계층 구조를 만듭니다.

• 먼저 응용 프로그램 서버가 통신 할 주소 인 IP 자원을 만듭니다. 기본 서버와 보조 서버 및 보호하려는 응용 프로그램을 선택합니다.  이 예에서는 공용 네트워크에서 사용되지 않는 하나를 선택하려고합니다. IP 자원 태그는 그대로 두십시오. 로컬 복구 – 장애 복구가 가능하지만이 경우 로컬 복구를 선택합니다. IP 주소가 온라인 상태가되어 기본 서버와 연결되어 있음을 알 수 있습니다.
• 다음으로이 자원을 보조 서버로 확장합니다.  IP 주소는 동일하게 유지됩니다. 우리가 사용하고자하는 네트워크는 공용 네트워크입니다. 대상 복원 모드도 활성화되므로 다른 서브넷에있는 서브넷 집합에서 장애가 발생할 때 유용합니다. 그런 다음 확장을 클릭합니다.

삼. SQL Server 리소스 및 볼륨 리소스 만들기 : 이제 IP 리소스를 만들었으므로 SQL 서버 리소스 및 볼륨 리소스를 만듭니다. 기본 및 백업 서버를 선택합니다.  보호하려는 응용 프로그램은 Microsoft SQL Server입니다.  인스턴스가 기본 인스턴스입니다.  찾으려는 이름은 sa 계정의 sa 계정과 암호입니다. 이 서버에서 SQL Server의 인스턴스를 쿼리했습니다.  현재 데이터베이스는 모두 E 드라이브에 있습니다.

4. 미러 만들기 : SQL Server 리소스가 주 서버에서 생성 된 것을 볼 수 있습니다.  다음 단계는 보조 서버로 확장하는 것입니다.  이제 볼륨 E를 보조 서버로 확장하여 미러를 생성하려고합니다.  그것은 우리에게 거울의 종말점을 요구하고 있습니다. 복제를 위해 개인 네트워크를 설정 한 다음 LAN에 대한 동기식 미러링을 선택합니다. 그런 다음 거울을 만듭니다.

그리고 보조 서버로 리소스를 확장 할 것입니다.  완료를 클릭하면 완벽하게 구성된 SIOS Protection Suite for SQL Server를 갖게됩니다. 우리는 SQL, IP 및 볼륨을 모두 1 차 서버에서 실행 중이고 2 차 서버에 의해 백업됩니다.

SIOS Protection Suite 및 SQL Server High Availability에 대해 자세히 알아 보거나 지금 무료 평가판을 요청하십시오.

비디오 : 당신의 방법으로 클러스터

클러스터 귀하의 방법

비용 절감, 사용자 만족도 유지, 앱 추가 및 데이터 센터 운영을 원활하게 유지하는 것과 같은 과제를 해결해야한다는 압력에 대처하는 방법에 대해 알아보십시오.  다행히도 물리적, 가상 및 클라우드 구성을 다양하게 조합하여 이러한 문제를 해결할 수있는 선택의 여지가 늘고 있습니다.

SIOS는 공용, 사설 및 하이브리드 클라우드를 비롯한 Windows 및 Linux 환경의 중요한 비즈니스 응용 프로그램을 보호하며 서버 및 스토리지 하드웨어를 선택하여 클러스터를 구성 할 수 있습니다. 데이터 센터를 원하는 방식으로 구성하십시오. 다운 타임이나 데이터 손실에 대한 걱정없이 클라우드에서 SQL Server, Oracle 또는 SAP 응용 프로그램을 실행할 수 있습니다. SAN 및 SANLess 환경을 혼합하십시오. 그러나 당신은 그것을하기로 결정하지만, SIOS는 당신의 방식대로 클러스터를 제공합니다.

고 가용성 솔루션에 대해 자세히 알아보십시오.