자료실

비동기 복제를 다중 사이트 클러스터에서 사용하려면 어떻게해야합니까? 데이터가 동기화되지 않았습니까?

나는이 질문을 몇 번 이상 물어 봤고, 그래서 나는 나의 첫 번째 블로그 포스트에서 대답 할 것이라고 생각했다. 기본 대답은 예입니다. 다중 사이트 클러스터에서 비동기 복제를 사용할 때 예기치 않은 오류가 발생하여 데이터가 손실 될 수 있습니다. 이상적인 세계에서 모든 회사는 DR 사이트에 다크 파이버 연결을하고 다중 사이트 클러스터와의 동기식 복제를 사용하여 데이터 손실 가능성을 제거합니다. 그러나 대부분의 경우 DR 사이트에 대한 WAN 연결에 동기화 복제를 지원하기에는 너무 많은 대기 시간이 필요합니다. 이러한 경우 비동기 복제는 훌륭한 대안입니다.

내 옵션은 무엇입니까?

WSFC 다중 사이트 클러스터와 함께 사용할 비동기 복제 솔루션을 선택할 때 몇 가지 옵션 이상이 있습니다. 여기에는 EMC, IBM, HP 등과 같은 회사의 어레이 기반 솔루션이 포함됩니다. 나에게 친숙하고 친숙한 호스트 기반 솔루션 인 "SteelEye DataKeeper Cluster Edition"을 제공합니다. DataKeeper를 가장 잘 알고 있기 때문에 DataKeeper의 장래성에서이 모든 기능이 어떻게 작동하는지 설명하겠습니다.

SteelEye DataKeeper는 무엇입니까?

SteelEye DataKeeper와 비동기식 복제를 사용할 때 비동기식 대기열에 일정 수의 쓰기를 저장할 수 있습니다. 대기열에 기록 할 수있는 쓰기 수는 "최고급 표시"에 의해 결정됩니다. 이 값은 DataKeeper에서 미러 상태가 "미러링"에서 "일시 중지"로 변경되기 전에 큐에 저장할 수있는 데이터의 양을 결정하는 데 사용할 수있는 조정 가능한 값입니다. 또한 "일시 중지됨"상태는 보조 서버와 주 서버간에 통신 장애가 발생할 때마다 입력됩니다. 일시 중지 된 상태에서 다중 사이트 클러스터의 자동 장애 조치는 사용할 수 없으며 예기치 않은 오류로 인해 손실 될 수있는 데이터의 양이 제한됩니다. 원래 데이터 세트가 "lost forever"로 간주되면 대상 서버의 나머지 데이터를 수동으로 잠금 해제하고 클러스터 노드를 서비스 할 수 있습니다.

"일시 중지됨"상태에있는 동안 DataKeeper는 모든 데이터가 다시 동기화 될 때까지 미러가 "다시 동기화"상태가되는 "낮은 워터 마크"에 도달 할 때까지 비동기 대기열이 소모되도록 허용합니다. 이 시점에서 미러는 다시 한 번 "미러링"상태가되고 자동 장애 조치가 다시 활성화됩니다.

WAN 링크가 포화되거나 깨지지 않는 한이 비동기 대기열에서 주어진 시간에 몇 번 이상 글을 읽지 않아야합니다. 예기치 않은 오류 (전원 코드가 있다고 생각 함)에서는 비동기 대기열에있는 쓰기를 잃게됩니다. 이는 다중 사이트 클러스터로 달성 할 수있는 RPO (복구 지점 목표) 및 RTO (복구 시간 목표)를 원하지만 WAN 링크의 동기 복제를 효과적으로 지원할 수있는 대기 시간이 너무 길 때 트레이드 오프입니다.

SteelEye DataKeeper를 사용해보십시오.

Windows 성능 로그 및 경고를 통해 DataKeeper 비동기 대기열을 모니터링하는 시간을 가지십시오. DataKeeper 복제 엔진의 효율성으로 비동기 큐가 비어있는 대부분의 시간을 발견하게되어 놀랄 것입니다. 대량의 쓰기가 발생하는 경우에도 비동기 큐는 매우 커지지 않으며 항상 거의 즉시 소모됩니다. 따라서 주어진 시간에 위험에 처한 데이터의 양은 최소화됩니다. 어젯밤의 백업에서 복원하는 재해의 대안과 비교할 때, 비동기 복제를 사용하여 예기치 않은 오류가 발생해도 손실 할 수있는 쓰기 횟수는 최소화됩니다.

물론 단일 쓰기를 잃어 버리는 것조차 용납 될 수없는 경우가 있습니다. 이러한 경우 고속, 저 지연 LAN 또는 WAN 연결에서 SteelEye DataKeeper의 동기식 복제 옵션을 사용하는 것이 좋습니다.

Clusteringformeremortals.com의 허락을 받아 재현

ARM을 사용 하 여 Azure에서 2 노드 파일 서버 장애 조치 클러스터 배포

이 게시물에서 우리는 Azure 리소스 관리자를 사용 하 여 Azure의 단일 지역에서 2 노드 파일 서버 장애 조치 클러스터를 배포 하는 데 필요한 특정 단계를 상세하게 됩니다. 난 당신과 기본 장애 조치 클러스터 개념으로 기본 푸른 개념에 익숙한 것 이다 초점 Azure에 있는 파일 서버 장애 조치 클러스터 배포에 대 한 고유의에이 문서를 가정 합니다.

DataKeeper 클러스터 에디션 로컬로 연결 된 저장소, 프리미엄 또는 표준 디스크 하 고 동기적으로, 비동기적으로 디스크를 복제 하는 여부 또는 혼합 또는 둘 다, 두 개 이상의 클러스터 노드 사이 걸릴 수 있습니다. 또한, DataKeeper 볼륨 리소스 Windows 서버 장애 조치 클러스터링 실제 디스크 리소스의 장소를가지고는에 등록 된다. 실제 디스크 리소스와 같은 SCSI-3 예약 제어, 대신 DataKeeper 볼륨 활성 노드는 항상 거울의 소스 보장 미러 방향을 제어 합니다. 늘어나는 만큼 우려는 장애 조치 클러스터링, 느낌 및 실제 디스크 같은 냄새 하며 실제 디스크 리소스는 사용 될 것 이라고 같은 방식으로 사용 됩니다.

필수 조건

당신은 전에 Azure 포털을 이용 했 고 편안 Azure IaaS에서 가상 컴퓨터를 배포.
라이센스 또는 SIOS DataKeeper의 eval 라이센스 취득

Azure Portal을 사용 하 여 파일 서버 장애 조치 클러스터 인스턴스 배포

Azure에서 2 노드 파일 서버 장애 조치 클러스터 인스턴스를 구축, 당신은 기본 가정 가상 네트워크 기반 Azure 리소스 관리자에 있고 하나 이상의 가상 컴퓨터를 하 고 실행 중인 도메인 컨트롤러로 구성 된 것입니다. 일단 가상 네트워크 및 도메인 구성, 우리의 클러스터의 두 노드 역할 것입니다 두 개의 새로운 가상 컴퓨터를 제공 하려고 합니다.

속은 다음과 같이 됩니다.

D c 1-우리의 도메인 컨트롤러와 파일 공유 감시
S q l 1와 SQL2-우리의 파일 서버 클러스터의 두 노드

두 클러스터 노드 프로비저닝 (SQL1 및 SQL2)

Azure 포털을 사용 하 여, 우리는 프로 비전 s q l 1와 SQL2 정확히 같은 방식으로. 인스턴스 크기, 스토리지 옵션, 기타 등등을 포함 하 여 선택할 수 있는 수많은 옵션이 있다. 이 가이드는 몇 가지 정말 좋은 자원 그리고 더 매일 출판 Azure에 서버를 배포 하는 완전 한 가이드를 아닙니다. 그러나 클러스터 된 환경에서 특히, 인스턴스를 만들 때 염두에 두어야 하는 몇 가지 중요 한 것이 있다.

가용성 세트-s q l 1, SQL2 및 d c 1 같은 가용성 세트에 있는 중요 하다. 동일한 여부 설정에 넣어 우리 각 클러스터 노드 및 파일 공유 감시 업데이트 도메인 및 다른 오류 도메인에 있는 보장 됩니다. 이 계획 된 유지 관리 및 클러스터 쿼럼을 유지 관리 하 고 가동 중단을 피할 수 있게 계속 됩니다 계획 되지 않은 유지 관리 동안 보장 하는 데 도움이 됩니다.

그림 3-클러스터 노드 및 파일 공유 감시 같은 가용성 설정에 추가 해야 합니다.

정적 IP 주소

일단 각 VM을 제공 하는 설정으로가 서 하 고 IP 주소는 정적 설정을 변경 원할 것입니다. 우리는 변화를 우리의 클러스터 노드의 IP 주소를 원하지 않습니다.

그림 4-확인 각 클러스터 노드를 사용 하 여 정적 IP

스토리지

마찬가지로 지금까지 스토리지에 관한 성능 유용한 SQL Server Azure 가상 컴퓨터에 대 한 상담을 원할 것입니다. 어떤 경우에, 당신은 최소한 각 클러스터 노드를 하나 이상 추가 디스크를 추가 해야 합니다. DataKeeper 기본 디스크, 프리미엄 스토리지 또는 심지어 저장소 풀의 여러 디스크를 저장소 풀에 구성 된 사용할 수 있습니다. 그냥 각 클러스터 노드에 동일한 양의 스토리지를 추가 하 고 동일 하 게 구성 해야 합니다. 또한, 각 가상 컴퓨터에 대 한 다른 저장소 계정을 사용 하 여 그 하나의 스토리지 계정에 문제가 영향을 주지 않습니다 두 가상 컴퓨터를 동시에 확인 해야 합니다.

그림 5-각 클러스터 노드에 추가 스토리지를 추가할 수 있는지 확인

클러스터 만들기

두 클러스터 노드 (s q l 1와 SQL2) 위에서 설명한 대로 구축 되 고 기존 도메인에 추가 했다고 가정 하면, 우리는 클러스터를 만들 준비가 되어 있다. 우리는 클러스터를 생성 하기 전에 설정 해야 하는 몇 가지 기능이 있습니다. 이러한 기능에는.Net Framework 3.5 및 장애 조치 클러스터링. 이러한 기능은 두 클러스터 노드에서 활성화 될 필요가 있다. 또한 파일 서버 역할을 설정 해야 합니다.

그림 6-활성화 모두.Net Framework 3.5 및 장애 조치 클러스터링 기능 및 둘 다에 파일 서버 클러스터 노드

그 역할 및 기능을 사용 하는 일단 클러스터를 만들 준비가 되었습니다. PowerShell와 GUI를 통해 내가 모두 수행할 수 있습니다 보여 단계의 대부분. 그러나, 나는이 매우 첫 번째 단계에 대 한 PowerShell을 사용 하면 클러스터를 만드는 것이 좋습니다 거 야. 장애 조치 클러스터 관리자 GUI를 사용 하 여 클러스터를 만들려고 하면 중복 IP 주소 문제를 되 고 클러스터와 바람 찾을 수 있습니다.

훌륭한 세부 사항에 들어 갔 없이, Azure Vm DHCP를 사용 하는 발견할 것 이다. 우리 푸른 포털에서 VM을 만들 때 "고정 IP"를 지정 하 여 우리 모두는 일종의 DHCP 예약을 만들 했다. 그것은 정확히 DHCP 예약 때문에 진정한 DHCP 예약 DHCP 풀에서 IP 주소를 제거할 것입니다. 대신, 의미 단순히이 푸른 포털에서 정적 ip 주소를 지정 하는 VM에서 요청 하는 경우 IP 주소를 사용할 수 있는 경우 Azure 발행할 것 이다 IP 그것에. 그러나, VM 오프 라인 이며 또 다른 호스트는 같은 서브넷에 온라인 상태가 경우 그것은 잘 수 발행 동일한 IP 주소.

Azure는 DHCP를 구현 하는 방법에 또 다른 이상한 부작용이 있다. (그들은 하는) DHCP를 사용 하 여 호스트 때 Windows 서버 장애 조치 클러스터 GUI와 함께 클러스터를 만들 때 클러스터 IP 주소를 지정 하려면 옵션 하지 않습니다. 대신 그것은 DHCP 주소를 사용 합니다. 이상한 것은, DHCP 중복 IP 주소를 새 IP 주소를 요청 하는 호스트 일반적으로 동일한 IP 주소를 발급 합니다. 클러스터는 일반적으로 완료, 하지만 몇 가지 이상한 오류가 있을 수 있습니다 그리고 실행 하 그것을 얻기 위하여 다른 노드에서 Windows 서버 장애 조치 클러스터 GUI를 실행 해야 할 수 있습니다. 일단 현재 네트워크에서 사용 되지 않은 주소를 클러스터 IP 주소를 변경 하려면 실행 얻을.

단순히 Powershell 통해 클러스터를 만들고 클러스터를 만드는 PowerShell 명령의 일부로 클러스터 IP 주소를 지정 하는 모든 혼란을 피할 수 있습니다.

다음과 같이 새 클러스터 명령을 사용 하 여 클러스터를 만들 수 있습니다.

새로운 클러스터-이름 cluster1-노드 s q l 1, 10.0.0.101 sql2-StaticAddress-NoStorage

클러스터 생성이 완료 된 후 다음 명령을 실행 하 여 클러스터 유효성 검사를 실행 하려면 것입니다.

테스트-클러스터

그림 7-클러스터 만들기 및 클러스터 유효성 검사 명령 출력

파일 공유 감시 만들기

아무 공유 저장소가 있기 때문에, 두 개의 클러스터 노드 같은 가용성 설정 다른 서버에 파일 공유 감시를 만들 해야 합니다. 동일한 가용성 세트에 그것을 넣어 그만 손실 1 개의 투표를 쿼럼에서 어떤 주어진된 시간에 수 있습니다. 당신이 확실 하지 않은 경우 파일 공유 감시를 만드는 방법을이 문서 http://www.howtonetworking.com/server/cluster12.htm를 검토할 수 있습니다. 내 데모에서 나 도메인 컨트롤러에서 파일 공유 감시를 넣어. 내가 https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/에서 클러스터 쿼럼의 철저 한 설명을 게시합니다

데이터 키퍼 설치

클러스터 그것을 만든 후 DataKeeper를 설치 하는 시간이 이다. 그것은 사용자 정의 클러스터 리소스 종류는 클러스터로 등록 될 수 있다 그래서 초기 클러스터를 만든 후 DataKeeper를 설치 하는 것이 중요. 클러스터를 생성 하기 전에 DataKeeper를 설치 하는 경우 설치를 다시 실행 하 고 복구 설치를 간단 하 게 해야 합니다.

그림 8-설치 DataKeeper 클러스터를 만든 후

설치 하는 동안 모든 기본 옵션을 수행할 수 있습니다. 사용 하는 서비스 계정이 도메인 계정 이어야 하 고 클러스터의 각 노드에서 로컬 관리자 그룹에 있을 해야 합니다.

그림 9-서비스 계정이 각 노드의 로컬 관리자 그룹에 있는 도메인 계정 이어야 합니다.

일단 DataKeeper를 설치 하 고 각 노드에 라이센스 서버를 재 부 팅 해야 합니다.

datakeeper 볼륨 리소스 만들기

DataKeeper 볼륨 리소스를 만들려면 DataKeeper UI를 시작 하 여 두 서버에 연결 해야.
S q l 1에 연결

SQL2에 연결

각 서버에 연결 되어, 일단 DataKeeper 볼륨을 만들 준비가 되었습니다. 작업을 마우스 오른쪽 단추로 클릭 하 고 "작업 만들기"를 선택

이름 및 설명 작업을 제공 합니다.

원본 서버, IP와 볼륨을 선택 합니다. IP 주소는 복제 트래픽을 여행 여부.

대상 서버를 선택 합니다.

옵션을 선택 합니다. 두 Vm 같은 지역에 있는 우리의 목적을 위해 우리 동기 복제를 선택 합니다. 더 긴 거리 복제에 대 한 몇 가지 압축을 사용 하 고 비동기 사용을 원할 것입니다.

마지막 팝업에서 예를 클릭 하 여 장애 조치 클러스터링에서 사용 가능한 저장소에 새로운 DataKeeper 볼륨 리소스를 등록 합니다.

새로운 DataKeeper 볼륨 리소스 사용 가능한 저장소에 표시 됩니다.

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

파일 서버 클러스터 리소스를 만들려면 장애 조치 (Failover) 클러스터 인터페이스가 아닌 Powershell을 다시 한 번 사용 합니다. 이는 가상 머신이 DHCP를 사용 하도록 구성 된 경우 GUI 기반 마법사가 클러스터 IP 주소를 입력 하 라는 메시지를 표시 하지 않습니다. 대신, 중복 된 IP 주소를 발급 합니다. 이를 방지 하기 위해 간단한 powershell 명령을 사용 하 여 파일 서버 클러스터 리소스를 만들고 IP 주소를 지정 합니다.

추가-ClusterFileServerRole-저장 "DataKeeper 볼륨 E"-FS2-StaticAddress 10.0.0.201 이름

여기에 지정 하는 IP 주소를 적어 둡니다. 그것은 당신의 네트워크에 고유 IP 주소 여야 합니다. 우리가 우리가 우리의 내부 부하 분산 장치를 만들 때 나중에이 동일한 IP 주소를 사용 합니다.

내부 부하 분산 장치 만들기

여기에 장애 조치 클러스터링 Azure에는 다른 전통적인 인프라입니다. 클라이언트가 클러스터 IP 주소에 직접 연결할 수 없습니다 그래서 푸른 네트워크 스택 무상 ARP를 지원 하지 않습니다. 대신, 클라이언트는 내부 부하 분산 장치에 연결 하 고 활성 클러스터 노드로 리디렉션됩니다. 우리가 필요가 있는 무엇을 할는 내부 부하 분산 장치를 만듭니다. 이 모든 할 수 있습니다 아래와 같이 Azure 포털을 통해.

첫째, 새로운 부하 분산 장치를 만들

클라이언트가 공용 인터넷을 통해 연결 하는 경우 공용 부하 분산 장치를 사용할 수 있습니다. 그러나 클라이언트가 동일한 vNet에 상주 한다고 가정할 경우 내부 부하 분산 장치를 만듭니다. 여기서 주의 깊게 살펴 중요 한 점은 가상 네트워크는 클러스터 노드를 있는 네트워크와 동일. 또한, 개인 IP 주소 지정 하는 것입니다 정확 하 게 SQL 클러스터 리소스를 만드는 데 사용 하는 주소와 같습니다.

내부 부하 분산 장치 (ILB)를 만든 후 편집 해야 합니다. 우리가 할 첫번째 일은 백엔드 풀을 추가 하는. 이 과정을 통해 SQL 클러스터 Vm 있는 여부 설정을 선택 합니다. 그러나, 백 엔드 풀에 추가 하려면 실제 Vm을 선택 하면 반드시 파일 공유 감시를 선택 하지 마십시오. 우리는 파일 공유 미러링 모니터 SQL 트래픽을 리디렉션할 싶지 않습니다.

우리 할 것 이다 다음 것은 프로브를 추가. 프로브 추가 포트 59999 조사할 것 이다. 이 프로브는 노드는 우리의 클러스터 활성화를 결정 합니다.

그리고 마지막으로, 우리 SMB 트래픽을, 아래 스크린샷에서 통지를 중요 한 것은 활성화 되어 직접 서버 반환 TCP 포트 445 로드 균형 조정 규칙. 그 변경 다는 것을 확인 하십시오.

파일 서버 IP 리소스를 수정 합니다.

클러스터 노드 중 하나에서 다음 PowerShell 스크립트를 실행 하는 구성의 마지막 단계가입니다. 그러면 클러스터 IP 주소를 ILB 프로브에 응답 하 고 클러스터 IP 주소와는 ILB 사이 IP 주소 충돌 확인 하십시오. 주의 해 주시기 바랍니다. 사용자 환경에 맞게이 스크립트를 편집 해야 합니다. 서브넷 마스크는 255.255.255.255로 설정 됩니다, 이것은 실수를 하지, 그대로 두고. 이 ILB 함께 IP 주소 충돌을 피하기 위해 호스트 특정 경로를 만듭니다.

# 변수를 정의 $ClusterNetworkName = "" # 클러스터 네트워크 이름 (이름을 찾기 위해 윈도우 서버 2012의 높은에 Get-ClusterNetwork 사용) $IPResourceName = "" # IP 주소 리소스 이름 $ILBIP = "" # 내부 부하 분산 장치 (ILB)의 IP 주소 가져오기 모듈 FailoverClusters # 윈도 서버 2012 이상 사용 하는 경우: Get-ClusterResource $IPResourceName | 세트-ClusterParameter -여러 @{주소 = $ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"; 네트워크 = $ClusterNetworkName; EnableDhcp = 0} Windows Server 2008 r 2를 사용 하는 경우 #을 사용 하 여이. #cluster 해상도 $IPResourceName 사용 enabledhcp 0 주소 = $ILBIP probeport = 59999 = subnetmask = 255.255.255.255

파일 공유 만들기

장애 조치 클러스터 관리자에서 파일 공유 마법사를 사용 하 여 작동 하지 않는 것을 발견할 것 이다. 대신, 당신은 단순히 활성 노드에서 Windows 탐색기에서 파일 공유 만들 것 이다. 장애 조치 클러스터링 자동으로 공유를 선택 하 고 클러스터에 그들을 저장 합니다.

참고가이 구성에서의 파일 공유 "지속적인 가용성" 옵션이 지원 되지 않습니다.

결론

이제 파일 서버 장애 조치 클러스터를 작동 해야 합니다. 당신은 어떤 문제가 있는 경우, 트위터 @daveberm에 나에 게 연락 주시기 바랍니다. datakeeper 평가 키 필요 http://us.sios.com/clustersyourway/cta/14-day-trial에서 양식을 작성 하 고 sios는 사용자에 게 전송 된 평가 키를 보냅니다.

덩어리의 허락으로 재생산 됩니다.