소개

시리즈 "Step by by Step : Windows Server 2008 R2에서 2 노드 다중 사이트 클러스터 구성"의 1 부에 오신 것을 환영합니다. 세부 사항으로 바로 들어가기 전에 잠시 시간을내어 정확히 멀티 사이트 클러스터가 무엇인지, 왜 구현해야 하는지를 논의 해 보겠습니다. Microsoft는 세부 정보를 얻으려는 훌륭한 웹 페이지 및 백서를 다운로드하고 싶으므로 여기서는 모든 내용을 반복하지 않겠습니다. 그러나 기본적으로 멀티 사이트 클러스터는 재해 복구 솔루션이며 고 가용성 솔루션이 하나로 통합되어 있습니다. 다중 사이트 클러스터를 통해 중요한 응용 프로그램에 사용할 수있는 RTO (복구 지점 목표)와 RTO (복구 시간 목표)를 가장 많이 제공합니다. Windows Server 2008 장애 조치 (failover) 클러스터링이 도입됨에 따라 다중 사이트 클러스터는 교차 서브넷 장애 조치 (cross subnet failover) 도입 및 대기 시간이 긴 네트워크 통신 지원으로 훨씬 더 적합 해졌습니다.

Windows Server 2008 장애 조치 (Failover) 클러스터링의 새로운 기능인 "교차 서브넷 장애 조치 (cross-subnet failover)"에 대해 언급했으며 이는 대단한 새로운 기능입니다. 그러나 SQL Server는 아직이 기능을 채택하지 않았으므로 SQL Server 다중 사이트 클러스터의 사이트에서 서브넷을 확장해야합니다. SQL Server 팀은 Tech-Ed 2009에서이 기능을 지원할 계획이라고보고했으나 SQL Server 2008 R2가 출시 된 이후에 출시 될 예정이라고합니다. 가까운 미래에 SQL Server 다중 사이트 클러스터의 여러 사이트에서 서브넷을 확장 할 수 있습니다. 중복 통신 경로, 대역폭 및 파일 공유 감시 위치와 같이 고려해야 할 다른 몇 가지 네트워크 관련 문제가 있습니다.

네트워크 고려 사항

모든 Microsoft 장애 조치 클러스터에는 중복 네트워크 통신 경로가 있어야합니다. 이렇게하면 어느 한 통신 경로에 오류가 발생해도 오류가 발생하지 않으며 클러스터 가용성을 높일 수 있습니다. 다중 사이트 클러스터에는 이러한 요구 사항이 있으므로 네트워크를 염두에두고 계획해야합니다. 일반적으로 노드간에 이동해야 할 두 가지가 있습니다 : 복제 트래픽과 클러스터 하트 비트. 그 외에도 클라이언트 연결 및 클러스터 관리 작업을 고려해야합니다. 당신은 당신이 자리 잡은 네트워크가 무엇이든, 당신이 네트워크를 압도하지 않거나 당신이 신뢰할 수없는 행동을 할 것이라는 것을 확신하고 싶을 것입니다. 복제 트래픽에는 가장 많은 대역폭이 필요합니다. 얼마나 많은 대역폭이 필요한지 판별하려면 복제 공급 업체와 협력해야합니다.

중복 통신 경로가 마련되어 있으므로 고려해야 할 마지막 사항은 쿼럼 모델입니다. 2 노드 다중 사이트 클러스터 구성의 경우 Microsoft에서 권장하는 구성은 노드 및 파일 공유 과반수 쿼럼입니다. 정족수 유형에 대한 자세한 설명은이 기사를 참조하십시오.

노드 및 파일 공유 과반수 쿼럼과 혼동을 일으키는 가장 일반적인 원인은 파일 공유 감시의 배치입니다. 파일 공유를 호스팅하는 서버는 어디에 두어야합니까? 옵션을 살펴 보겠습니다.

옵션 1 – 기본 사이트에 파일 공유 위치.

이는 재해 복구를위한 확실한 옵션이지만 높은 가용성을 보장하는 것은 아닙니다. 주 사이트 및 파일 공유 감시를 포함하여 전체 사이트가 실패하는 경우 보조 사이트의 보조 노드가 자동으로 서비스되지 않으므로 수동으로 쿼럼을 온라인 상태로 설정해야합니다. 이것은 클러스터에서 유일하게 남은 투표 일 것입니다. 3 명 중 1 명이 과반수가되지 않습니다! 재해 발생시 복구를 위해 수작업 단계로 참여할 수 있다면이 구성이 도움이 될 것입니다.

옵션 2 – 두 번째 사이트에서 파일 공유 위치.

이것은 좋은 생각이 아닙니다. 사이트가 완전히 손실되는 경우 자동 복구 문제를 해결하지만 오류가 발생하면 장애 조치가 발생할 위험이 있습니다. 이것을 고려해보십시오 … 보조 사이트가 다운되면 어떻게됩니까? 이 경우 기본 사이트 (노드 1)는 기본 사이트의 단일 노드이기 때문에 오프라인 상태가되어 더 이상 노드가 다수 존재하지 않게됩니다. 너무 많은 위험이 관련되어 있으므로이 구성을 구현할 충분한 이유가 없습니다.

옵션 3 – 3 지리적 위치에있는 파일 공유 증인 놓기

사이트 전체가 손실되는 경우 자동 장애 조치를 허용하고 보조 사이트가 기본 노드를 오프라인 상태로 만드는 데 실패 할 가능성을 없애기 때문에 기본 구성입니다. 세 번째 사이트 호스트에서 파일 공유 감시를하면 한 사이트가 단일 실패 지점으로 제거되므로 이제 클러스터가 예상대로 작동하고 사이트 손실이 발생할 경우 자동 장애 조치가 가능합니다. 세 번째 지리적 위치를 확인하는 것은 일부 기업에게는 어려울 수 있지만 Amazon EC2 및 GoGrid와 같은 클라우드 기반 유틸리티 컴퓨팅의 출현으로 모든 회사가 클라우드에 파일 공유 증인을 배치하고 탄력성을 요구할 수 있습니다 효과적인 다중 사이트 클러스터. 사실, 클라우드 자체를 보조 데이터 센터로 간주하고 재난 발생시 클라우드로 페일 오버 할 수 있습니다. 클라우드 기반 컴퓨팅 및 재해 복구 구성의 가능성은 극도로 매력적이며 실제로 가까운 장래에 바로 블로그 게시물을 다룰 계획입니다.

클러스터 구성

이제 기본 개념을 살펴 보았으므로 클러스터의 실제 구성을 시작합시다. 클러스터의 두 노드에 장애 조치 클러스터링 기능을 추가하려고합니다. 간단하게하기 위해, 나는 PRIMARY와 SECONDARY 노드를 호출했다. 아래 그림과 같이 기능 추가 마법사를 통해 매우 쉽게 수행 할 수 있습니다.

다음으로는 네트워크 연결을 확인해야합니다. 각 서버의 연결 이름을 변경하여 해당 네트워크가 반영되도록하는 것이 가장 좋습니다. 이렇게하면 나중에 쉽게 기억할 수 있습니다.

또한 각 서버의 네트워크 연결 고급 설정 (Alt 키를 눌러 고급 설정 메뉴 참조)으로 이동하여 공용 네트워크가 목록의 첫 번째인지 확인하십시오.

개인 네트워크에는 IP 주소와 서브넷 마스크 만 있어야합니다. 기본 게이트웨이 또는 DNS 서버를 정의하지 않아야합니다. 노드가이 네트워크에서 통신 할 수 있어야하므로 서버가이 네트워크에서 통신 할 수 있어야합니다. 필요한 경우 고정 경로를 추가하십시오.

네트워크를 구성했으면 클러스터를 빌드 할 준비가 된 것입니다. 첫 번째 단계는 "구성 유효성 검사"입니다. 장애 조치 (failover) 클러스터 관리자를 열고 구성 유효성 검사를 클릭하십시오.

유효성 검사 마법사가 시작되어 아래와 같이 첫 번째 화면을 표시합니다. 클러스터에 두 개의 서버를 추가하고 계속하려면 다음을 클릭하십시오.

다중 사이트 클러스터는 저장소 유효성 검사를 통과 할 필요가 없습니다 (Microsoft 기술 자료 참조). 스토리지 유효성 검사 프로세스를 Toskip하고 "선택한 테스트 만 실행"을 클릭 한 다음 계속을 클릭하십시오.

테스트 선택 화면에서 스토리지를 선택 해제하고 다음을 클릭하십시오.

다음 확인 화면이 나타납니다. 다음을 클릭하여 계속하십시오.

모든 작업을 올바르게 완료했다면 다음과 같은 요약 페이지가 나타납니다. 노란색 느낌표는 모든 테스트가 실행되지 않았 음을 나타냅니다. 이 테스트는 저장 테스트를 건너 뛰므로 다중 사이트 클러스터에서 예상됩니다. 다른 모든 것들이 OK를 확인하는 한 계속 진행할 수 있습니다. 보고서에 다른 오류가 표시되면 문제점을 수정하고 테스트를 다시 실행 한 후 계속하십시오.

이제 클러스터를 만들 준비가되었습니다. 장애 조치 (Failover) 클러스터 관리자에서 클러스터 만들기를 클릭합니다.

다음 단계에서는 클러스터의 유효성을 검사할지 여부를 묻습니다. 이미이 작업을 수행 했으므로이 단계를 건너 뛸 수 있습니다. 계속 진행하기 전에 클러스터가 유효성 검사를 통과해야하므로 SQL을 설치하는 경우 나중에 약간의 문제가 발생합니다. 이 시점에 이르면 SQL Server 설치의 명령 줄 옵션을 통해이 검사를 우회하는 방법을 보여줍니다. 지금은 아니오 및 다음을 선택하십시오.

다음 단계는이 클러스터를 관리하기 위해이 클러스터와 IP의 이름을 만들어야한다는 것입니다. 이 이름은 나중에 작성할 SQL 클러스터 자원의 이름이 아니라 클러스터 관리에 사용할 이름입니다. 고유 한 이름과 IP 주소를 입력하고 다음을 클릭하십시오.

참고 :이 문서의 뒷부분에서 설명하는대로 파일 공유 감시에 대한 권한이 필요한 컴퓨터 이름이기도합니다.

선택 사항을 확인하고 다음을 클릭하십시오.

축하합니다. 모든 것이 올바르게 끝난 경우 다음 요약 페이지가 표시됩니다. 노란색 느낌표를 확인하십시오. 분명히 뭔가 완벽하지는 않습니다. 보고서보기를 클릭하여 문제의 원인을 찾으십시오.

보고서를 보면 다음과 같은 몇 줄을보아야합니다.

두려워하지 마라. 이는 다중 사이트 클러스터에서 예상됩니다. 앞서 노드와 파일 공유 과반수 쿼럼을 구현할 것이라고 말한 것을 기억하십시오. 쿼럼 유형을 현재 노드 대다수 클러스터 (2 노드 클러스터에서는 좋지 않음)에서 노드 및 파일 공유 과반수 쿼럼으로 변경합니다.

NODE 및 FILE SHARE MAJORITY QUORUM 구현

먼저 파일 공유 감시 서버를 확인해야합니다. 앞에서 설명한 것처럼이 파일 공유 감시는 세 번째 위치에 있어야하며 클러스터의 두 노드에서 액세스 할 수 있어야합니다. 서버를 식별하면 일반적으로 폴더를 공유하는 것처럼 폴더를 공유하십시오. 필자의 경우 DEMODC라는 서버에 MYCLUSTER라는 공유를 생성합니다.

이 공유에 대해 기억해야 할 핵심 사항은 공유 수준과 NTFS 수준 사용 권한 모두에서 클러스터 컴퓨터 이름에 공유에 대한 읽기 / 쓰기 권한을 부여해야한다는 것입니다. 그림 13을 다시 회상하면 클러스터를 생성하고 "MYCLUSTER"라는 이름을 부여했습니다. 다음 스크린 샷과 같이 클러스터 컴퓨터 계정에 읽기 / 쓰기 권한을 부여해야합니다.

이제 공유 폴더가 있고 적절한 권한이 할당되면 쿼럼 유형을 변경할 준비가 된 것입니다. 장애 조치 (failover) 클러스터 관리자에서 클러스터를 마우스 오른쪽 단추로 클릭하고 추가 작업 및 클러스터 쿼럼 설정 구성을 선택합니다.

다음 화면에서 노드 및 파일 공유 과반수를 선택하고 다음을 클릭하십시오.

이 화면에서 이전에 생성 한 파일 공유 경로를 입력하고 다음을 클릭하십시오.

정보가 올바른지 확인하고 다음을 클릭하십시오.

모든 것을 올바르게했다고 가정하면 다음 요약 페이지를 볼 수 있습니다.

이제 클러스터를 볼 때 쿼럼 구성에 아래와 같이 "노드 및 파일 공유 과반수"가 표시되어야합니다.

SQL, Exchange, 파일 서버 또는 다른 유형의 장애 조치 (failover) 클러스터에 관계없이이 지점까지 다중 사이트 클러스터에 적용 할 때까지 설명한 단계가 있습니다. 다중 사이트 클러스터를 만드는 다음 단계는 스토리지 및 복제 솔루션을 장애 조치 클러스터에 통합하는 것입니다. 이 단계는 복제 솔루션에 따라 다르므로 실제로 복제 공급 업체와 긴밀한 관계를 유지해야합니다. 제 2 부에서는 SteelEye DataKeeper Cluster Edition이 Windows Server 장애 조치 (Failover) 클러스터링과 통합되어 복제 공급 업체 솔루션 중 하나가 어떻게 작동 하는지를 설명합니다.

이 시리즈의 다른 부분에서는 SQL, 파일 서버 및 Hyper-V를 다중 사이트 클러스터에 설치하는 방법에 대해 자세히 설명합니다. 또한 세 개 이상의 노드로 구성된 다중 노드 클러스터에 대한 고려 사항에 대한 게시물을 게시 할 예정입니다.

Windows Server 2008 R2가 출시되면서 동적 VHD 파일의 성능이 향상되었습니다. R2 이전에는 동적 확장 VHD 파일에 쓰기가 제한된 메타 데이터 캐싱으로 인해 고정 크기 VHD 파일에 쓰는 것보다 3 배 느려질 수있었습니다. 전반적으로 Microsoft는 동적 VHD 파일과 고정 크기 VHD 파일의 성능이 거의 동일하다고 주장합니다. Hyper-V VM을 구성 할 때 패스 스루 디스크가 다른 옵션입니다. 내 결과에 따르면 통과 디스크의 성능은 VHD 파일의 성능보다 약간 우수합니다. 그러나 통과 디스크를 사용하면 이식성, 스냅 샷 및 씬 프로비저닝과 같은 VHD 파일의 모든 이점을 잃게됩니다. 이러한 절충 사항을 고려할 때 통과 디스크를 사용하는 것은 실제로 크기가 2TB보다 큰 디스크가 필요하거나 응용 프로그램이 I / O 경계에 있고 실제로 다른 디스크에서 이익을 얻을 수있는 경우에만 고려해야합니다. 귀하의 평균 응답 시간.

필자는 마이크로 소프트의 말을 듣기보다는 다른 종류의 디스크를 직접 테스트 해 보았습니다. Windows Server 2008 R2에서 실행되는 Hyper-V Windows Server 2008 R2 가상 컴퓨터를 설정했습니다. 하이퍼 바이저의 경우 필자는 Dell AX150 SAN에 연결된 Dell PowerEdge 1950 서버를 사용하여 테스트에 사용할 10GB LUN 3 개를 조각했습니다. Hyper-V 관리자에서 패스 스루 한 개, 동적 VHD 한 개, 고정 크기 VHD 한 개를 추가했습니다. 그런 다음 IOMeter를 사용하여 디스크의 성능을 테스트했습니다. 테스트 매개 변수 및 원시 데이터는이 CSV 파일에서 찾을 수 있습니다.

아래 차트는 내 결과를 요약 한 것입니다. 극한 상황 (최대 / 최소)에서 볼 수 있듯이 대부분의 경우 통과 디스크가 이깁니다. 그러나 평균적으로 세 가지 디스크 유형의 성능 간에는 거의 차이가 없습니다.

 

VHD 파일 또는 사용 가능한 디스크 공간보다 큰 결합 된 크기의 여러 VHD 파일을 만드는 씬 프로비저닝의 이점과 VHD 파일의 이식성으로 인해 동적으로 확장되는 VHD 파일이 대부분의 Windows Server 2008 R2 가상 컴퓨터에서 확실한 선택입니다 .

요약하면 Windows Server 2008 R2에서 다음 Hyper-V 배포를 위해 동적으로 확장되는 VHD 파일을 사용하는 것이 좋습니다.

https://clusteringformeremortals.com/2009/09/25/hyper-v-pass-through-disk-performance-vs-fixed-size-vhd-files-and-dynamic-vhd-files-in-에서 허락을 받아 복제했습니다. windows-server-2008-r2 /