SIOS SANless clusters High-availability Machine Learning monitoring
Windows Server 장애 조치 (failover) 클러스터링 및 SteelEye DataKeeper Cluster Edition을 사용하여 가까운 장래에 데이터 센터간에 및 / 또는 공유 저장소없이 DHCP를 구성하는 방법에 대한 단계별 문서를 찾아보십시오. 그 동안 클러스터의 공유 디스크 대신 복제 된 DHCP 데이터베이스를 사용하는 DHCP 클러스터를 보여주는이 비디오를 확인하십시오.
https://clusteringformeremortals.com/2009/11/23/dhcp-cluster-without-shared-storage-andor-across-data-centers/의 허락을 받아 복제했습니다.
최근에는 장거리 데이터 센터를 통해 가상 컴퓨터 라이브 마이그레이션을 실행하고 데이터 센터간에 vMotion에 대한 VMware의 제한된 지원 또는 "장거리 vMotion"을 알리는 등 많은 언론이있었습니다. 솔루션에 대한 자세한 내용은 시스코 웹 사이트에서 확인할 수 있습니다. 그게 좋다고 생각하지만, Microsoft Hyper-V는 오늘날이 동일한 기능을 갖추고 있으며 VMware의 장거리 vMotion보다 요구 사항과 제한 사항이 훨씬 적습니다.
VMware에서 VMware HA, vMotion 및 SRM (Site Recovery Manager)을 사용하여 가상 시스템 가용성을 관리하는 경우 Microsoft는 Windows Server 장애 조치 (Failover) 클러스터링과 동일한 기능을 제공하며 사실 경우에 따라 VMware에서 가상 시스템 가용성 측면에서 제공 할 수있는 것 이상을 제공합니다. 나는 이전 글에서 설명했다.
오늘 제가 중점을두고 싶습니다. "장거리 vMotion"에 대한 Microsoft의 경쟁력있는 제안입니다. Hyper-V에서 동일한 기능을 수행하려면 Windows Server 장애 조치 (Failover) 클러스터링과 Windows Server 2008 다중 사이트 클러스터에서 작동하도록 인증 된 호스트 또는 저장소 기반 복제 솔루션을 사용하여 다중 사이트 Hyper-V 클러스터를 배포하면됩니다. 이렇게하면 기존 네트워크 인프라와 기존 스토리지 인프라를 사용하여 데이터 센터 전체에서 실시간 마이그레이션을 수행 할 수 있습니다. 클라이언트가 오래된 네트워크에 캐시 할 수 있으므로 가상 컴퓨터를 새 서브넷으로 이동할 때 발생하는 클라이언트 재 연결 문제를 피하기 위해 서브넷을 확장하는 것을 권장한다는 점을 제외하고는 요구 사항까지 모든 멀티 사이트 클러스터와 실제로 동일합니다. TTL이 만료 될 때까지 IP 주소.
Windows Server 2008 R2 Hyper-V 및 SteelEye DataKeeper Cluster Edition을 사용하여 데이터 센터 전반에서 실시간 마이그레이션 데모 비디오를 볼 수 있습니다.
https://clusteringformeremortals.com/2009/09/17/hyper-v-live-migration-across-data-centers/의 허락을 받아 재생산되었습니다.
고 가용성 클러스터 구성을 구축 할 때 응용 프로그램 가용성은 가장 약한 링크만큼 좋습니다. 이것이 의미하는 바는 중복 된 모든 것 (CPU, 팬, 전원, RAID, RAM 등)을 갖춘 훌륭한 서버와 다중 경로 연결성을 갖춘 수퍼 디럭스 SAN을 구입 한 경우입니다. 여러 SAN 스위치와 결합하여 선호하는 클러스터링 소프트웨어로 애플리케이션을 클러스터링했습니다. 아마도 매우 신뢰할만한 응용 프로그램 일 것입니다 – 맞습니까? 음, 반드시 그런 것은 아닙니다. 서버가 동일한 UPS에 연결되어 있습니까? 그들은 동일한 네트워크 스위치에 있습니까? 동일한 AC 장치로 냉각 되었습니까? 그들은 같은 건물에 있습니까? SAN이 진정으로 신뢰할 수 있습니까? 이러한 문제 중 하나는 고 가용성 클러스터 구성의 단일 실패 지점입니다.
물론, "충분 함"이 "충분히 만족 스러울 때"를 알아야합니다. 예산과 SLA가 정확히 무엇이 좋은지 결정하는 데 도움이됩니다. 그러나 사람들이 저격 할 우려가있는 부분 중 하나는 저장 영역에 있습니다. 저렴한 또는 무료 iSCSI 대상 소프트웨어 솔루션의 출현으로 일부 사용자는 여분의 서버에 일부 iSCSI 대상 소프트웨어를 던져 즉시 공유 저장소에 보관할 것을 권장합니다.
페일 오버 기술 및 / 또는 기타 가용성 기능을 내장 한 OEM iSCSI 솔루션에 대해 언급하는 것이 아닙니다. FalconStor와 같은 스토리지 가상화 솔루션을 제공합니다. Windows Server 2008을 실행하는 서버를 가지고있는 사람이 스토리지를로드하고 iSCSI 대상으로 전환하려고합니다. 이것은 실험실에서 훌륭합니다. 그러나 당신이 HA에 대해 진지하다면 다시 생각해야합니다. 마이크로 소프트조차도 엔터프라이즈 급 스토리지 어레이 제공 경험이 풍부한 유능한 OEM 업체에게만 iSCSI 대상 소프트웨어를 제공합니다.
우선, 이것은 Windows입니다. 스토리지를 제공하기 위해 만들어진 일부 강화 된 OS가 아닙니다. 유지 관리, 보안 업데이트, 하드웨어 수정 등이 필요합니다. 기본적으로 보호하려는 응용 프로그램 서버와 동일한 안정성을가집니다. 응용 프로그램 서버를 클러스터링하는 것이 합리적입니까? 그러나 서버 및 OS의 동일한 클래스를 사용하여 스토리지를 호스팅 할 수 있습니까? 기본적으로 단일 실패 지점을 응용 프로그램 서버 밖으로 옮기고이를 저장소 서버로 이동했습니다. 내가 염려하는 한 똑똑한 움직임이 아닙니다.
일부 엔터프라이즈 클래스 iSCSI 대상 소프트웨어에는 동기 및 / 또는 비동기 복제 소프트웨어 및 스냅 샷 기능이 포함되어 있습니다. 이 기능은 복구 지점 목표 (RPO) 측면에서 도움이됩니다. 페일 오버가 자동으로 클러스터링 소프트웨어에 원활하지 않으면 RTO (복구 시간 목표)에 도움이되지 않습니다. 한밤중에 기본 iSCSI 스토리지 배열이 실패했다고 가정 해 봅시다. 누가 복제 된 사본을 활성화 할 것입니까? 문제가 있음을 깨닫기까지 꽤 오랜 시간 동안 다운 될 수도 있습니다. 다시 말하지만, 이것은 "충분히 좋다"; 당신은 당신이 가입하고있는 것을 인식하고 있어야합니다. 원하는 고 가용성 클러스터 구성입니까?
iSCSI 대상 서버의 안정성을 향상시키기 위해 할 수있는 한 가지 방법은 SteelEye DataKeeper Cluster Edition과 같은 복제 제품을 사용하여 단일 실패 지점을 제거하는 것입니다. 설명해 드리겠습니다.
위에서 설명한 것과 동일한 구성을 사용하고 복제 및 자동 장애 조치를 수행하기 위해 SteelEye DataKeeper Cluster Edition을 사용하는 핫 스탠바이 iSCSI 타겟을 추가하면 iSCSI 대상 솔루션이 완전히 새로운 차원의 가용성을 제공하게되었습니다. 그 해결책은 이것과 아주 비슷하게 보일 것입니다.
SteelEye DataKeeper Cluster Edition과 복제 솔루션을 사용하는 솔루션의 주요 차이점은 일부 iSCSI 대상 공급 업체가 제공하는 WSFC와의 통합입니다. iSCSI 솔루션 공급 업체에게 묻는 질문은 다음과 같습니다.
활성 iSCSI 대상 서버에서 전원 코드를 당기면 어떻게됩니까?
복구 프로세스가 수동 절차 인 경우 실제 HA 솔루션이 아닙니다. 하지만 자동으로 WSFC와 완전히 통합되면 어떻게 될까요? 그런 다음 훨씬 높은 수준의 가용성을 확보하고 iSCSI 어레이를 단일 실패 지점으로 제거했습니다.
고 가용성 클러스터 구성을 달성하기 위해 우리와 채팅하십시오.
Clusteringformortals의 허가를 받아 복제했습니다.
저는 Windows IT Pro가 SteelEye DataKeeper Cluster Edition을 최고의 고 가용성 및 재해 복구 제품으로 두 범주로 선정했다고 발표하게되어 기쁩니다. 커뮤니티 초이스 금상 수상 및 편집자 최우수 실버 상.
저는 SteelEye DataKeeper 팀의 일원이었던 것을 자랑스럽게 생각하며 Community Choice 상에 선정 된 모든 Windows IT Pro 커뮤니티에 감사드립니다!
https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/에서 허락을 받아 복제했습니다.
나는이 질문을 몇 번 이상 물어 봤고, 그래서 나는 나의 첫 번째 블로그 포스트에서 대답 할 것이라고 생각했다. 기본 대답은 예입니다. 다중 사이트 클러스터에서 비동기 복제를 사용할 때 예기치 않은 오류가 발생하여 데이터가 손실 될 수 있습니다. 이상적인 세계에서 모든 회사는 DR 사이트에 다크 파이버 연결을하고 다중 사이트 클러스터와의 동기식 복제를 사용하여 데이터 손실 가능성을 제거합니다. 그러나 대부분의 경우 DR 사이트에 대한 WAN 연결에 동기화 복제를 지원하기에는 너무 많은 대기 시간이 필요합니다. 이러한 경우 비동기 복제는 훌륭한 대안입니다.
WSFC 다중 사이트 클러스터와 함께 사용할 비동기 복제 솔루션을 선택할 때 몇 가지 옵션 이상이 있습니다. 여기에는 EMC, IBM, HP 등과 같은 회사의 어레이 기반 솔루션이 포함됩니다. 나에게 친숙하고 친숙한 호스트 기반 솔루션 인 "SteelEye DataKeeper Cluster Edition"을 제공합니다. DataKeeper를 가장 잘 알고 있기 때문에 DataKeeper의 장래성에서이 모든 기능이 어떻게 작동하는지 설명하겠습니다.
SteelEye DataKeeper와 비동기식 복제를 사용할 때 비동기식 대기열에 일정 수의 쓰기를 저장할 수 있습니다. 대기열에 기록 할 수있는 쓰기 수는 "최고급 표시"에 의해 결정됩니다. 이 값은 DataKeeper에서 미러 상태가 "미러링"에서 "일시 중지"로 변경되기 전에 큐에 저장할 수있는 데이터의 양을 결정하는 데 사용할 수있는 조정 가능한 값입니다. 또한 "일시 중지됨"상태는 보조 서버와 주 서버간에 통신 장애가 발생할 때마다 입력됩니다. 일시 중지 된 상태에서 다중 사이트 클러스터의 자동 장애 조치는 사용할 수 없으며 예기치 않은 오류로 인해 손실 될 수있는 데이터의 양이 제한됩니다. 원래 데이터 세트가 "lost forever"로 간주되면 대상 서버의 나머지 데이터를 수동으로 잠금 해제하고 클러스터 노드를 서비스 할 수 있습니다.
"일시 중지됨"상태에있는 동안 DataKeeper는 모든 데이터가 다시 동기화 될 때까지 미러가 "다시 동기화"상태가되는 "낮은 워터 마크"에 도달 할 때까지 비동기 대기열이 소모되도록 허용합니다. 이 시점에서 미러는 다시 한 번 "미러링"상태가되고 자동 장애 조치가 다시 활성화됩니다.
WAN 링크가 포화되거나 깨지지 않는 한이 비동기 대기열에서 주어진 시간에 몇 번 이상 글을 읽지 않아야합니다. 예기치 않은 오류 (전원 코드가 있다고 생각 함)에서는 비동기 대기열에있는 쓰기를 잃게됩니다. 이는 다중 사이트 클러스터로 달성 할 수있는 RPO (복구 지점 목표) 및 RTO (복구 시간 목표)를 원하지만 WAN 링크의 동기 복제를 효과적으로 지원할 수있는 대기 시간이 너무 길 때 트레이드 오프입니다.
Windows 성능 로그 및 경고를 통해 DataKeeper 비동기 대기열을 모니터링하는 시간을 가지십시오. DataKeeper 복제 엔진의 효율성으로 비동기 큐가 비어있는 대부분의 시간을 발견하게되어 놀랄 것입니다. 대량의 쓰기가 발생하는 경우에도 비동기 큐는 매우 커지지 않으며 항상 거의 즉시 소모됩니다. 따라서 주어진 시간에 위험에 처한 데이터의 양은 최소화됩니다. 어젯밤의 백업에서 복원하는 재해의 대안과 비교할 때, 비동기 복제를 사용하여 예기치 않은 오류가 발생해도 손실 할 수있는 쓰기 횟수는 최소화됩니다.
물론 단일 쓰기를 잃어 버리는 것조차 용납 될 수없는 경우가 있습니다. 이러한 경우 고속, 저 지연 LAN 또는 WAN 연결에서 SteelEye DataKeeper의 동기식 복제 옵션을 사용하는 것이 좋습니다.
Clusteringformeremortals.com의 허락을 받아 재현