Datakeeper | SIOS SANless clusters

주요 클라우드 서비스 중단으로 인해 Google Compute Engine에 영향을 미쳤습니다.

6월 7, 2019 by Jason Aw Leave a Comment

주요 클라우드 서비스 중단으로 인해 Google Compute Engine에 영향을 미쳤습니다.

Google은 2019 년 6 월 2 일 12시 25 분 (PDT)에 처음으로 '문제'를 신고했습니다. 현재 모든 유형의 재해에서 흔히 볼 수 있듯이이 중단에 대한 보고서는 소셜 미디어에 처음 나타났습니다. 소셜 미디어는 재난 발생 초기에 어떤 유형의 정보도 얻을 수있는 가장 신뢰할 수있는 곳으로 보인다.

우리가이 최신 Google Compute Engine 작동 중단에 대한 공식적인 근본 원인 분석을 기다리는 동안 Google은 "미국 동부 지역에서 높은 수준의 네트워크 혼잡"으로 인해 다운 타임이 발생했다고보고했습니다. 네트워크 문제를 일으킨 원인을 확인하기 위해 기다려야 할 것입니다. 인간의 실수, 사이버 공격, 하드웨어 오류 또는 다른 것이 었습니까?

이 구름 파동을 준비 했습니까?

마지막으로 주요 클라우드 정전 중에 썼습니다. 클라우드에서 비즈니스 핵심 워크로드를 실행하는 경우 클라우드 서비스 공급자와 상관없이 피할 수없는 중단을 계획하는 것이 중요합니다. 2018 년 9 월 4 일의 다단계 Azure 정전은 전기 폭풍과 관련된 전력 서지 중 2 차 HVAC 시스템이 가동되지 않는 것과 관련이 있습니다. 단일 데이터 센터 내에 장애가 발생했지만 정전으로 인해이 단일 데이터 센터에 종속 된 여러 서비스가 노출되었습니다. 이로 인해 데이터 센터 자체가 단일 실패 지점이되었습니다.

재해 복구 계획을 세우십시오.

클라우드의 인프라를 활용하여 가용 영역, 지역 또는 클라우드 서비스 제공 업체간에 중요한 데이터를 지속적으로 복제함으로써 위험을 최소화하십시오. 데이터 보호 외에도 업무 핵심 응용 프로그램을 신속하게 복구 할 수있는 절차를 마련하는 것이 모든 재해 복구 계획의 필수 요소입니다. 다양한 복제 및 복구 옵션을 사용할 수 있습니다. 여기에는 Azure Site Recovery와 같은 클라우드 공급 업체가 제공하는 서비스, SQL Server Always On Availability Group과 같은 응용 프로그램 별 솔루션, Windows 및 Linux에서 실행되는 다양한 응용 프로그램을 보호하는 SIOS DataKeeper와 같은 타사 솔루션까지 포함됩니다. 단일 클라우드 제공 업체에 전적으로 의존하는 재해 복구 전략을 사용하면 단일 클라우드 내의 여러 지역에 영향을 줄 수있는 시나리오가 발생할 수 있습니다. 다중 데이터 센터 또는 다중 지역 재해는 거의 발생하지 않습니다. 그러나 지난 가을에 발생한 이러한 최근의 가동 중단과 Azure의 정전으로 인해 단일 데이터 센터에 장애가 발생하더라도 영향은 여러 데이터 센터 또는 클라우드 내의 영역까지 광범위하게 퍼질 수 있습니다. 위험을 최소화하려면 재해 복구 사이트가 기본 클라우드 플랫폼 외부에있는 다중 클라우드 또는 하이브리드 클라우드 시나리오를 고려하십시오. 클라우드는 사용자 자신의 데이터 센터만큼이나 작동 불능입니다. 재난 대비를위한 조치를 취해야합니다. 가장 중요한 비즈니스 용 앱을 먼저 살펴 보는 것이 좋습니다. 오프라인 상태에서 관리하고있는 클라우드 포털을 사용할 수 없다면 어떻게 할 것입니까? 복구 할 수 있니? RTO 및 RPO 목표를 달성합니까? 그렇지 않은 경우 재해 복구 전략을 다시 평가할 때입니다.

"준비를하지 않으면 실패 할 준비를하고 있습니다."– 벤자민 프랭클린

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

4월 24, 2019 by Jason Aw Leave a Comment

단계별 : 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의 허락을 받아 재현

새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터

4월 14, 2019 by Jason Aw Leave a Comment

새로운 Azure ILB 기능으로 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터 구축 가능

Microsoft는 지난 9 월에 이그제큐티브를 통해 Azure에 대한 발표를 시작했습니다. 이러한 발표 중 하나는 내부로드 밸런서에 여러 VIP가 일반적으로 제공된다는 것입니다. 왜 이것이 SQL Server DBA에게 중요한가? 이제까지 Azure에 고 가용성 SQL Server를 배포하려는 경우 클러스터 당 하나의 SQL Server FCI 또는 단일 가용성 그룹 수신기로 제한되었습니다. 이 제한으로 인해 장애 조치 (Failover) 클러스터에서 보호하려는 각 SQL Server 인스턴스에 대해 새 클러스터를 배포해야했습니다. 또한 AlwaysOn AG 구성에서 자동 장애 조치 및 클라이언트 리디렉션을 원할 경우 모든 데이터베이스를 단일 가용성 그룹으로 그룹화해야했습니다.

이러한 제한 사항을 벗어나려면 어떻게해야합니까?

이러한 제한 사항은 이제 새로운 ILB 기능으로 해제되었습니다. 이 글에서는 두 SQL Server 인스턴스가 포함 된 Azure에 SQL Server FCI를 배포하는 과정을 안내합니다. 향후 게시글에서 SQL Server AlwaysOn AG와 동일한 프로세스로 안내 할 것입니다.

다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터 시작하기

Azure Resource Manager에서 Microsoft SQL Server 2014 장애 조치 (failover) 클러스터 배포 게시물에 설명 된대로 Azure에서 기본 단일 인스턴스 SQL Server FCI를 작성하십시오. 이 게시물은 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 만드는 과정을 설명합니다. DataKeeper를 사용하여 클러스터에서 사용되는 복제 된 볼륨 리소스를 만들려면 ILB (Internal Load Balancer)를 만든 다음 ILB에서 작동하도록 SQL Server 클러스터 IP 리소스를 수정하십시오. 해당 프로세스를 건너 뛰고 구성을 시작하려는 경우 SIOS DataKeeper를 사용하여 2 노드 SQL Server FCI를 만드는 Azure 배포 템플릿을 항상 사용할 수 있습니다. 이제 기본 두 노드 SQL Server FCI가 있다고 가정하고 두번째 인스턴스는 다음과 같습니다.

현재 사용되지 않는 다른 볼륨에 다른 DataKeeper 볼륨 리소스를 만듭니다. 사용 가능한 볼륨이없는 경우 Azure 인스턴스에 디스크를 추가해야 할 수도 있습니다. 이 볼륨 생성 프로세스의 일부로 새로운 DataKeeper 볼륨 리소스가 클러스터의 사용 가능한 저장소에 등록됩니다. 자세한 내용은 앞에서 언급 한 기사를 참조하십시오.
방금 저장 위치로 만든 DataKeeper 볼륨을 지정하여 첫 번째 노드에 SQL Server의 명명 된 인스턴스를 설치합니다.
"노드 추가"는 두 번째 노드의 클러스터에 추가됩니다.
이 새 명명 된 인스턴스의 포트 번호를 사용 중이 아닌 포트로 잠급니다. 내 예제에서는 포트 1440을 사용합니다.

ILB를 두 번째 인스턴스로 조정

다음으로 트래픽을이 두 번째 인스턴스로 리디렉션하도록 ILB를 조정해야합니다. 다음과 같은 단계를 따라야합니다. 두 번째 SQL Server 인스턴스에 사용 된 SQL 클러스터 IP 주소와 동일한 프런트 엔드 IP 주소를 아래와 같이 추가합니다. 새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터 다음으로 인스턴스가 다른 서버에서 실행될 수 있으므로 다른 프로브를 추가해야합니다. 아래 그림과 같이 포트 59998 (보통 59999 대신)을 프로브하는 프로브를 추가했습니다. 새 규칙이이 조사를 참조하는지 확인해야합니다. 또한이 프로세스의 마지막 단계에서이 인스턴스와 연결된 IP 주소를 업데이트해야하므로 포트 번호를 기억해야합니다. 새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터 이제 ILB에 두 개의 새로운 규칙을 추가하여이 두 번째 SQL 인스턴스로 향하는 트래^픽을 지정해야합니다. 물론 TCP 포트 1440 (명명 된 SQL 인스턴스에 사용 된 포트)을 리디렉션하는 규칙을 추가해야하지만 이제는 명명 된 인스턴스를 사용하기 때문에 SQL Server Browser Service를 지원하는 포트가 있어야합니다. UDP 포트 1434. SQL Server Browser Service에 대한 규칙을 묘사하는 아래 그림에서 프런트 엔드 IP 주소가 새 프런트 엔드 IP 주소 (10.0.0.201), UDP 포트 1434 (포트 및 백 엔드 포트 모두)를 참조합니다. 풀에서 클러스터의 두 서버를 지정하고 마지막으로 방금 만든 새 상태 프로브를 선택해야합니다. 새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터 이제 TCP / 1440에 대한 규칙을 추가 할 것입니다. 아래 그림과 같이 포트 TCP 1440에 대한 새 규칙을 추가하거나 명명 된 SQL Server 인스턴스에 대해 잠긴 포트를 추가합니다. 다시 한 번, 새 FrontEnd IP 주소와 새 상태 프로브 (59998)를 선택하십시오. 또한 Floating IP (직접 서버 리턴)가 사용 가능한지 확인하십시오. 새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터

마지막 단계

로드 균형 조정기가 구성되었으므로 마지막 단계는 PowerShell 스크립트를 실행하여이 두 번째 SQL Server 인스턴스와 연결된 새 클러스터 IP ^주소를 업데이트하는 것입니다. 이 PowerShell 스크립트는 클러스터 노드 중 하나에서만 실행하면됩니다.

# 변수 정의

$ ClusterNetworkName = ""

# 클러스터 네트워크 이름 
(Windows Server 2012의 Get-ClusterNetwork를 사용하여 이름을 찾으십시오)

$ IPResourceName = ""

# SQL Server의 두 번째 인스턴스의 IP 주소 리소스 이름

$ ILBIP = ""

# 두 번째 SQL 인스턴스의 IP 주소, 
이는 새로운 프론트 엔드 IP 주소와 동일해야합니다.

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

# Windows Server 2012 이상을 사용하는 경우 :

Get-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; 네트워크 = $ ClusterNetworkName; EnableDhcp = 0}

# Windows Server 2008 R2를 사용하는 경우 다음을 사용하십시오.

#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998  
서브넷 마스크 = 255.255.255.255

이제 Azure에 완벽하게 작동하는 다중 인스턴스 SQL Server FCI가 있습니다. Clusteringformeremortals.com에서 복제 된 New Azure ILB 기능으로 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 구축하는 데 관한 질문이 있으면 알려주십시오.

새로운 Azure ILB 기능을 갖춘 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터

4월 14, 2019 by Jason Aw Leave a Comment

새로운 Azure ILB 기능으로 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터 구축 가능

이러한 제한 사항을 벗어나려면 어떻게해야합니까?

다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터 시작하기

Azure Resource Manager에서 Microsoft SQL Server 2014 장애 조치 (failover) 클러스터 배포 게시물에 설명 된대로 Azure에서 기본 단일 인스턴스 SQL Server FCI를 작성하십시오. 이 게시물은 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 만드는 과정을 설명합니다. DataKeeper를 사용하여 클러스터에서 사용되는 복제 된 볼륨 리소스를 만들려면 ILB (Internal Load Balancer)를 만든 다음 ILB에서 작동하도록 SQL Server 클러스터 IP 리소스를 수정하십시오. 해당 프로세스를 건너 뛰고 구성을 시작하려는 경우 SIOS DataKeeper를 사용하여 2 노드 SQL Server FCI를 만드는 Azure 배포 템플릿을 항상 사용할 수 있습니다. 이제 기본 두 노드 SQL Server FCI가 있다고 가정하고 두번째 인스턴스는 다음과 같습니다.

현재 사용되지 않는 다른 볼륨에 다른 DataKeeper 볼륨 리소스를 만듭니다. 사용 가능한 볼륨이없는 경우 Azure 인스턴스에 디스크를 추가해야 할 수도 있습니다. 이 볼륨 생성 프로세스의 일부로 새로운 DataKeeper 볼륨 리소스가 클러스터의 사용 가능한 저장소에 등록됩니다. 자세한 내용은 앞에서 언급 한 기사를 참조하십시오.
방금 저장 위치로 만든 DataKeeper 볼륨을 지정하여 첫 번째 노드에 SQL Server의 명명 된 인스턴스를 설치합니다.
"노드 추가"는 두 번째 노드의 클러스터에 추가됩니다.
이 새 명명 된 인스턴스의 포트 번호를 사용 중이 아닌 포트로 잠급니다. 내 예제에서는 포트 1440을 사용합니다.

ILB를 두 번째 인스턴스로 조정

마지막 단계

# 변수 정의

$ ClusterNetworkName = ""

# 클러스터 네트워크 이름 
(Windows Server 2012의 Get-ClusterNetwork를 사용하여 이름을 찾으십시오)

$ IPResourceName = ""

# SQL Server의 두 번째 인스턴스의 IP 주소 리소스 이름

$ ILBIP = ""

# 두 번째 SQL 인스턴스의 IP 주소, 
이는 새로운 프론트 엔드 IP 주소와 동일해야합니다.

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

# Windows Server 2012 이상을 사용하는 경우 :

Get-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
SubnetMask = "255.255.255.255"; 네트워크 = $ ClusterNetworkName; EnableDhcp = 0}

# Windows Server 2008 R2를 사용하는 경우 다음을 사용하십시오.

#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998  
서브넷 마스크 = 255.255.255.255

Azure에서 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 구성하는 방법

3월 31, 2019 by Jason Aw Leave a Comment

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

Azure에서 SQL Server 장애 조치 (failover) 클러스터 인스턴스를 구성하는 데 필요한 가이드가 필요하면 SQL Server 2008/2008 R2를 사용하고있는 것입니다. SQL Server 2008/2008 R2를 Azure로 전환하면 Microsoft에서 제공하는 확장 보안 업데이트를 활용하고 싶습니다. 이전에이 블로그 게시물에이 주제에 관해 썼습니다. Azure로 이동 한 후에도 SQL Server 장애 조치 (Failover) 클러스터 인스턴스의 고 가용성을 유지하는 방법을 궁금해하실 수 있습니다. 오늘날 대부분의 사람들은 업무상 중요한 SQL Server 2008/2008 R2를 데이터 센터에 클러스터 된 인스턴스 (SQL Server FCI)로 구성합니다. Azure를 살펴볼 때 공유 저장 장치가 부족하여 Azure 클라우드에 SQL Server FCI를 가져올 수없는 것처럼 보일 수도 있습니다. 그러나 SIOS DataKeeper 덕분에 그렇지 않습니다. SIOS DataKeeper를 사용하면 Azure, AWS, Google Cloud 또는 공유 저장소를 사용할 수 없거나 공유 저장소가 적합하지 않은 다중 사이트 클러스터를 구성하려는 경우 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 구축 할 수 있습니다. DataKeeper는 1999 년 이래로 Windows 및 Linux 용 SANless 클러스터를 지원하고 있습니다. Microsoft는 Azure Virtual Machines에서 SQL Server의 고 가용성 및 재해 복구와 같은 설명서에서 SQL Server Failover Cluster 인스턴스 용 SIOS DataKeeper를 사용하고 있습니다. 이전에 Azure에서 실행중인 SQL Server FCI에 대해 작성했지만 SQL Server 2008/2008 R2 관련 단계별 안내서는 게시하지 않았습니다. 좋은 소식은 SQL 2008/2008/2016/2017 및 2019 년 곧 출시 될 SQL 2008/2008 R2와 마찬가지로 훌륭하게 작동한다는 것입니다. 또한 Windows Server 버전 (2008/2012/2016/2019) 또는 SQL Server (2008/2012/2014/2016/2017)에 관계없이 구성 프로세스가 유사하기 때문에이 가이드로 인해 구성. SQL이나 Windows의 맛이 제 가이드에서 다루지 않는 경우 SQL Server FCI를 작성하고이 가이드를 참조하기를 두려워하지 마십시오. 차이점을 파악하고 방금 막혔다면 트위터 @daveberm에서 나에게 다가 가라. 나는 너에게 손을 뻗어 기뻐할 것이다. 이 가이드에서는 Windows Server 2012 R2와 함께 SQL Server 2008 R2를 사용합니다. 이 글을 쓰는 시점에서 필자는 Windows Server 2012 R2에서 Azure Marketplace의 SQL 2008 R2 이미지를 보지 못했습니다. 따라서 SQL 2008 R2를 수동으로 다운로드하여 설치해야했습니다. 개인적으로 필자는이 조합을 선호하지만 Windows Server 2008 R2 또는 Windows 212를 사용해야하는 경우에는 문제가 없습니다. Windows Server 2008 R2를 사용하는 경우 Windows Server 2008 R2 SP1 용 kb3125574 편의 롤업 업데이트를 설치하는 것을 잊지 마십시오. 또는 Server 2012 (R2가 아님)가 붙어있는 경우 kb2854082의 핫픽스가 필요합니다. SQL Server 2008 R2 인스턴스에 kb2854082를 설치해야한다는 내용의이 기사에 속지 마십시오. Windows Server 2008 R2에 대한 해당 업데이트 검색을 시작하면 Server 2012 버전 만 사용할 수 있습니다. Server 2008 R2의 특정 핫픽스는 대신 Windows Server 2008 R2 SP1 용 롤업 편의 롤업 업데이트에 포함되어 있습니다.

규정 AZURE INSTANCES

Azure Portal UI가 꽤 자주 변경되는 경향이 있기 때문에 특히 스크린 샷을 많이 사용하지는 않겠다. 그래서 찍은 모든 스크린 샷은 꽤 빨리 사라질 것이다. 대신, 나는 당신이 알고 있어야하는 중요한 주제들을 다룰 것입니다.

결함이있는 도메인 또는 가용성 영역?

SQL Server 인스턴스의 가용성을 높이려면 클러스터 노드가 다른 오류 도메인 (FD) 또는 다른 가용 영역 (AZ)에 있는지 확인해야합니다. 인스턴스가 다른 FD 또는 AZ에 있어야 할뿐만 아니라 File Share Witness (아래 참조)도 클러스터 노드가있는 FD 또는 AZ와 다른 FD 또는 AZ에 있어야합니다. 여기에 그것이있다. AZ는 최신 Azure 기능이지만 지금까지 소수의 지역에서만 지원됩니다. AZ는 당신에게 더 높은 SLA (99.99 %)를주고 FDs (99.95 %)를 제공하며, Azure Postage에 게시 된 클라우드 중단의 종류로부터 당신을 보호합니다. AZ를 지원하는 지역에 배포 할 수 있다면 AZ를 사용하는 것이 좋습니다. 이 가이드에서는로드 밸런서 구성에 관한 절을 읽었을 때 표시되는 AZ를 사용했습니다. 그러나 FD를 사용하는 경우로드 밸런서 구성이 가용 영역보다는 가용 세트를 참조한다는 점을 제외하면 모든 것이 정확히 동일합니다.

당신이 묻는 증분 몫은 무엇입니까?

WSFC (Windows Server Failover Clustering)를 사용하면 장애 조치 (failover)가 올바르게 수행되도록 "감시 (Witness)"를 구성해야합니다. Windows Server 장애 조치 (Failover) 클러스터링은 디스크, 파일 공유, 클라우드의 세 가지 종류의 증인을 지원합니다. 우리가 Azure에 있기 때문에 디스크 증인은 불가능합니다. Cloud Witness는 Windows Server 2016 이상에서만 사용할 수 있으므로 File Share Witness가 필요합니다. 클러스터 쿼럼에 대한 자세한 내용은 Microsoft Press 블로그의 MVP : Windows Server 2012 R2의 Windows Server 장애 조치 (failover) 클러스터 쿼럼 이해 (영문)를 참조하십시오.

SQL Server 인스턴스에 저장소를 추가하십시오.

SQL Server 인스턴스를 프로비저닝 할 때 각 인스턴스에 디스크를 추가해야합니다. 최소한 SQL 데이터 및 로그 파일 용으로 하나의 디스크, Tempdb 용으로 하나의 디스크가 필요합니다. 클라우드에서 실행할 때 로그 및 데이터 파일 용으로 별도의 디스크를 사용해야하는지 여부는 다소 논쟁의 여지가 있습니다. 백엔드에서 저장소는 모두 같은 위치에서 나오며 인스턴스 크기는 총 IOPS를 제한합니다. 내 의견으로는 실제로 두 개의 물리적 디스크 세트에서 실행 중인지 확인할 수 없으므로 로그 파일과 데이터 파일을 분리 할 때 가치가 없습니다. 내가 결정할 수 있도록 남겨두고 싶지만 로그와 데이터를 모두 같은 볼륨에 넣습니다. 일반적으로 SQL Server 2008 R2 FCI에서는 클러스터 된 디스크에 tempdb를 넣어야합니다. 그러나, SIOS DataKeeper는 DataKeeper Non-Mirrored Volume Resource라는 정말 멋진 기능을 가지고 있습니다. 이 가이드에서는 미러되지 않은 볼륨 리소스로 tempdb를 이동하는 방법에 대해서는 설명하지 않지만 최적의 성능을 위해서는이 작업을 수행해야합니다. 어쨌든 장애 조치시에 다시 작성되기 때문에 tempdb를 복제 할 충분한 이유가 없습니다. 스토리지에 관한 한 모든 스토리지 유형을 사용할 수 있지만 가능할 때마다 Managed Disks를 사용하십시오. 클러스터의 각 노드가 동일한 스토리지 구성을 갖고 있는지 확인하십시오. 인스턴스를 실행하면 이러한 디스크를 연결하고 NTFS로 포맷 할 수 있습니다. 각 인스턴스가 동일한 드라이브 문자를 사용하는지 확인하십시오.

네트워킹

어려운 요구 사항은 아니지만 가능하면 가속화 된 네트워킹을 지원하는 인스턴스 크기를 사용하십시오. 또한 인스턴스가 고정 IP 주소를 사용하도록 Azure 포털에서 네트워크 인터페이스를 편집해야합니다. 클러스터링이 제대로 작동하려면 일부 공용 DNS 서버가 아니라 Windows AD / DNS 서버를 가리 키도록 DNS 서버의 설정을 업데이트해야합니다.

보안

기본적으로 동일한 가상 네트워크의 노드 간 통신은 활발하지만 Azure 보안 그룹을 잠근 경우 클러스터 노드간에 열려야하는 포트를 확인하고 보안 그룹을 조정해야합니다. Azure에 클러스터를 구축 할 때 발생하는 거의 모든 문제는 저의 경험으로 포트 차단으로 인한 것입니다. DataKeeper에는 클러스터 된 인스턴스간에 열려야하는 일부 포트가 있습니다. 이러한 포트는 다음과 같습니다. UDP : 137, 138 TCP : 139, 445, 9999 및 10000 – 10025 범위의 포트 장애 조치 (failover) 클러스터에는 여기에 문서화하지 않는 자체 포트 요구 사항 세트가 있습니다. 이 기사에는이 내용이 포함되어있는 것으로 보입니다. http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html 또한로드 밸 랜서는 각 노드에서 인바운드 트래픽을 허용해야하는 프로브 포트를 사용합니다. 이 가이드에서 일반적으로 사용되는 포트는 59999입니다. 마지막으로 클라이언트가 SQL Server 인스턴스에 연결할 수있게하려면 SQL Server 포트가 열려 있는지 확인해야합니다.이 포트는 기본적으로 1433입니다. 이 포트는 Windows 방화벽이나 Azure 보안 그룹에 의해 차단 될 수 있으므로 둘 모두를 확인하여 액세스가 가능한지 확인하십시오.

도메인에 가입하십시오.

SQL Server 2008 R2 FCI에 대한 요구 사항은 인스턴스가 동일한 Windows Server 도메인에 있어야한다는 것입니다. 그래서 그렇게하지 않았다면 인스턴스를 Windows 도메인에 가입 시켰는지 확인하십시오.

지역 서비스 계정

DataKeeper를 설치하면 서비스 계정을 제공하라는 메시지가 나타납니다. 도메인 사용자 계정을 만든 다음 해당 사용자 계정을 각 노드의 로컬 관리자 그룹에 추가해야합니다. DataKeeper 설치 중에 질문을 받으면 해당 계정을 DataKeeper 서비스 계정으로 지정하십시오. 참고 – DataKeeper를 아직 설치하지 마십시오!

도메인 글로벌 보안 그룹

SQL 2008 R2를 설치할 때 두 개의 전역 도메인 보안 그룹을 지정하라는 메시지가 표시됩니다. SQL 설치 지침을보고 해당 그룹을 작성하는 것이 좋습니다. 또한 도메인 사용자 계정을 만들어 각 보안 계정에 배치하십시오. 이 계정을 SQL Server 클러스터 설치의 일부로 지정합니다.

기타 사전 요청

두 클러스터 인스턴스의 각 인스턴스에서 장애 조치 클러스터링과 .Net 3.5를 모두 사용해야합니다. 장애 조치 (Failover) 클러스터링을 사용하도록 설정하면 선택적 "장애 조치 (Failover) 클러스터 자동화 서버"도 사용하도록 설정해야합니다. 이는 Windows Server 2012 R2의 SQL Server 2008 R2 클러스터에 필요합니다.

클러스터 및 데이터 키퍼 볼륨 자원 만들기

이제 클러스터 구축을 시작할 준비가되었습니다. 첫 번째 단계는 기본 클러스터를 만드는 것입니다. Azure가 DHCP를 처리하는 방식 때문에 우리는 클러스터 UI가 아닌 Powershell을 사용하여 클러스터를 만들어야합니다. Powershell은 생성 프로세스의 일부로 고정 IP 주소를 지정할 수 있도록하기 때문에 Powershell을 사용합니다. UI를 사용하면 VM이 DHCP를 사용하며 중복 된 IP 주소가 자동으로 할당됩니다. 그러므로 이러한 상황을 피하기 위해 아래와 같이 Powershell을 사용하십시오.

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

클러스터가 생성 된 후 Test-Cluster를 실행하십시오. 이는 SQL Server를 설치하기 전에 필요합니다.

테스트 클러스터

저장 및 네트워킹에 대한 경고가 표시됩니다. 고맙게도 Azure의 SANless 클러스터에서 예상대로 무시할 수 있습니다. 그러나 계속 진행하기 전에 다른 경고 또는 오류를 해결하십시오. 클러스터를 만든 후에는 파일 공유 감시를 추가해야합니다. 파일 공유 감시로 지정한 세 번째 서버에서 파일 공유를 만들고 위의 방금 만든 클러스터 컴퓨터 개체에 읽기 / 쓰기 권한을 부여합니다. 이 경우 $ Cluster1은 공유 및 NTFS 보안 수준에서 읽기 / 쓰기 권한이 필요한 컴퓨터 개체의 이름입니다. 공유가 만들어지면 아래와 같이 클러스터 쿼럼 구성 마법사를 사용하여 파일 공유 감시를 구성 할 수 있습니다.

데이터 키퍼 설치

DataKeeper 설치시 DataKeeper 볼륨 리소스 유형이 장애 조치 클러스터링에 등록되므로 DataKeeper를 설치하기 전에 기본 클러스터가 만들어 질 때까지 기다리는 것이 중요합니다. 총을 들고 DataKeeper를 이미 설치했다면 괜찮습니다. 설치를 다시 실행하고 설치 복구를 선택하기 만하면됩니다. 아래의 스크린 샷은 기본적인 설치 과정을 안내합니다. DataKeeper 설치 프로그램을 실행하여 시작하십시오.

아래에서 지정하는 계정은 도메인 계정이어야합니다. 각 클러스터 노드의 로컬 관리자 그룹에 속해야합니다.

SIOS 라이센스 키 관리자가 나타나면 임시 키를 찾아 볼 수 있습니다. 또는 영구 키가있는 경우 시스템 호스트 ID를 복사하여 영구 키를 요청할 수 있습니다. 키를 새로 고침해야하는 경우 SIOS License Key Manager는 별도로 실행하여 새 키를 추가 할 수있는 프로그램입니다.

데이터 키퍼 볼륨 자원 만들기

DataKeeper가 각 노드에 설치되면 첫 번째 DataKeeper 볼륨 리소스를 만들 준비가 된 것입니다. 첫 번째 단계는 DataKeeper UI를 열고 각 클러스터 노드에 연결하는 것입니다.

모든 것이 올바르게 완료되면 서버 개요 보고서는 다음과 같아야합니다.

이제 아래와 같이 첫 번째 작업을 만들 수 있습니다.

소스 및 대상을 선택하면 다음과 같은 옵션이 제공됩니다. 같은 지역에있는 지역 타겟의 경우, 선택해야하는 것은 동기식입니다.

예를 선택하고이 볼륨을 클러스터 리소스로 자동 등록하십시오.

이 프로세스를 완료하면 장애 조치 (failover) 클러스터 관리자를 열고 디스크를 살펴보십시오. 사용 가능한 저장소에 DataKeeper 볼륨 리소스가 표시되어야합니다. 이 시점에서 WSFC는 정상적인 클러스터 디스크 리소스 인 것처럼 처리합니다.

SLIPSTREAM SP3에서 SQL 2008 R2 설치 미디어로 이동

SQL Server 2008 R2는 SQL Server SP2 이상이 설치된 Windows Server 2012 R2에서만 지원됩니다. 불행히도 Microsoft는 SP2 또는 SP3이 포함 된 SQL Server 2008 R2 설치 미디어를 출시하지 않았습니다. 대신 설치하기 전에 서비스 팩을 설치 미디어에 설치해야합니다. 표준 SQL Server 2008 R2 미디어를 사용하여 설치를 시도하면 모든 종류의 문제가 발생합니다. 정확한 오류를 기억하지 못합니다. 그러나 나는 그들이 정확히 정확한 문제를 지적하지 않았던 것을 기억한다. 무엇이 잘못되었는지 알아 내려고 많은 시간을 낭비 할 것입니다. 이 글을 쓰는 시점 현재, Microsoft는 Azure 마켓 플레이스에 SQL Server 2008 R2를 제공하는 Windows Server 2012 R2가 없습니다. Azure의 Windows Server 2012 R2에서 SQL 2008 R2를 실행하려면 자신의 SQL 라이센스를 가져 오십시오. 나중에 이미지를 추가하거나 Windows Server 2008 R2에서 SQL 2008 R2 이미지를 사용하도록 선택한 경우 먼저 이동하기 전에 SQL Server의 기존 독립 실행 형 인스턴스를 제거해야합니다. SP3을 SQL 2008 R2 설치 미디어에 적용하기 위해이 기사의 옵션 1에 대한 지침을 따랐습니다. 이 기사에서는 SP3 대신 SP2를 참조하므로 몇 가지 사항을 조정해야합니다. 클러스터의 두 노드에 사용할 설치 미디어에서 SP3을 슬립 스트림으로 만듭니다. 완료되면 다음 단계로 진행합니다.

첫 번째 노드에 SQL Server 설치

슬립 스트리밍 된 SP3과 함께 SQL Server 2008 R2 미디어를 사용하여 다음과 같이 설치 프로그램을 실행하고 클러스터의 첫 번째 노드를 설치합니다.

SQL Server의 기본 인스턴스 이외의 다른 것을 사용하는 경우이 가이드에서 다루지 않은 몇 가지 추가 단계가 있습니다. 가장 큰 차이점은 기본적으로 SQL Server의 명명 된 인스턴스는 1433을 사용하지 않으므로 SQL Server에서 사용하는 포트를 잠그지 않아야한다는 것입니다. 포트를 잠그면 방화벽 설정 및 Load Balancer 설정을 포함하여이 가이드에서 포트 1433을 참조 할 때마다 포트를 1433 대신 지정해야합니다.