SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 제작품
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 뉴스 및 이벤트
  • 서버 클러스터 단순화
  • 성공 사례
  • 저희에 게 연락
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

SIOS DataKeeper를 사용하여 성능 테스트 복제를 수행하는 방법

8월 10, 2024 by Jason Aw Leave a Comment

How to Perform Performance Testing Replication with SIOS DataKeeper

SIOS DataKeeper를 사용하여 성능 테스트 복제를 수행하는 방법

프로덕션 데이터베이스에 대한 복제를 구성하는 것은 특히 사전 조사를 수행하지 않은 경우 매우 어려운 작업이 될 수 있습니다. 이 블로그에서는 환경을 적절하게 설정하는 데 있어 가장 까다로운 측면인 성능에 대한 여러 부분을 다룰 것입니다. 이러한 핵심 사항을 이해하면 앞서 나갈 수 있으며 프로덕션 Go-Live에 마지막 순간에 문제가 발생하지 않도록 할 수 있습니다.

고려해야 할 첫 번째이자 가장 기본적인 점은 구성에 맞는 올바른 미러 유형을 선택하는 것입니다. SIOS DataKeeper에는 생성 프로세스 중에 미러 유형에 대한 동기식 및 비동기식의 두 가지 옵션이 제공됩니다. 이러한 옵션 중 하나는 환경에 따라 고유한 장점과 단점이 있습니다.

미러 유형 선택

동기식 미러는 고속 연결이 가능한 LAN 환경에서 가장 뛰어난 성능을 발휘하며 기본 시스템에 대한 커밋 시 1:1 쓰기 일관성을 제공합니다. 그러나 네트워크 또는 대상 스토리지가 기본 시스템의 처리량을 따라잡을 수 없는 경우 동기 쓰기 일관성을 유지하기 위해 쓰기 속도가 감소하는 것을 볼 수 있습니다. 따라서 동기식 미러링은 WAN 또는 대기 시간이 긴 환경에는 권장되지 않습니다.

그러나 비동기식 미러는 WAN 환경에 적합합니다. 비동기식 미러는 노드 간 1:1 쓰기 일관성을 보장하는 동일한 기능을 모두 제공하지만 차이점은 쓰기가 대상 시스템에 커밋되기 전에 기본 시스템에 커밋된다는 것입니다. 이는 의도 로그라고도 알려진 비트맵의 활용으로 인해 가능합니다. 비트맵은 시스템에서 발생하는 모든 변경 사항을 블록 수준에서 추적하고 백로그라고 알려진 백로그를 통해 최대한 빠르게 대상에 데이터를 씁니다. 쓰기 대기열. 쓰기 대기열은 쓰기 수 또는 데이터의 총 MB에 따라 제한될 수 있으며, 제한에 도달하면 미러가 일시 중지되고 데이터가 동기화되므로 데이터가 동기화되지 않은 동안 장애 조치가 방지됩니다.

하드웨어 구성:

이제 환경에 가장 적합한 미러 유형을 결정했으므로 DataKeeper가 마법이 아니라는 점을 이해하는 것이 중요합니다. DataKeeper는 시스템이 허용하는 만큼만 빠르게 쓰고 복제할 수 있으므로 애플리케이션에 필요한 처리량을 달성할 수 있는 하드웨어를 보유하는 것이 중요합니다. 복제 목표를 달성하는 데 필요한 하드웨어를 갖추기 위한 몇 가지 조언과 팁은 다음과 같습니다.

  1. 기본 시스템과 대상 시스템에 동일한 스토리지 하드웨어가 있는지 확인하십시오. 예를 들어 대상 IOPS는 소스 IOPS와 동일해야 합니다. 그렇지 않으면 환경에서 가장 느린 구성 요소가 쓰기 속도의 병목 현상이 되는 것으로 드러납니다. 일치하는 하드웨어는 항상 더 나은 성능을 제공합니다.
  2. 비트맵의 중요성을 이해하면 성능을 크게 향상시키는 가장 쉽고 저렴한 방법은 전용 고속 스토리지에 비트맵을 저장하는 것입니다. 비트맵은 매우 작기 때문에 5GB 또는 10GB SSD를 프로비저닝하는 것으로 충분하며 성능 향상에 대한 큰 수익을 제공합니다.
  3. 데이터 복제로 인해 약간의 오버헤드가 발생한다는 점을 이해하고 독립형 하드웨어를 테스트하십시오. 예를 들어 환경에서 10,000 IOPS를 달성해야 하는 요구 사항이 있는 경우 하드웨어가 클러스터에 포함될 모든 노드에서 최소한 독립 실행형으로 일관된 10,000 IOPS를 달성할 수 있는지 확인하십시오. 동기식 미러링을 수행하려는 경우 동기식 일관성을 유지하기 위해 추가 오버헤드가 도입되므로 최소한의 요구 사항 이상인지 확인하십시오. 또한 복제 체계에 필요한 데이터를 전송할 수 있는지 확인하기 위해 네트워크 부하 테스트도 수행해야 합니다.
  4. 제대로 테스트하는 방법을 알아보세요. 생산 능력을 검증하기 위해 테스트 환경을 활용할 때 설정을 최대한 비슷하게 모방하는 것이 중요합니다. 단순히 복제를 테스트하기 위해 전체 운영 데이터베이스 복제본을 설정할 수는 없지만 올바른 데이터 생성 도구를 활용하면 현재 성능 기능을 더 잘 표시할 수 있다는 점을 이해합니다. Diskspd는 일부 기본 테스트에 사용할 수 있는 무료 도구이지만 SQL 세계에서는 HammerDB가 실제 성능에 대한 훨씬 더 나은 지표를 제공합니다.

디스크 속도:https://github.com/microsoft/diskspd
해머DB:https://www.hammerdb.com/

  1. 마지막으로 DataKeeper 조정이 있으며 DataKeeper 내에는 미러 유형 외에 구성 가능한 설정이 있습니다. 이를 수정하는 것은 일반적으로 좀 더 미묘하며 SIOS 지원 팀의 조언에 따라 가장 잘 수행됩니다. 그러나 다른 모든 권장 사항이 제대로 적용되었음을 확인한 경우 일부 DataKeeper 매개 변수를 조정하면 필요한 측정 항목을 충족하는 데 필요한 성능이 마지막으로 향상될 수 있습니다. 조정의 몇 가지 예로는 쓰기 대기열에 있을 수 있는 미해결 쓰기 수를 늘리거나 비트맵 파일이 디스크에 플러시되는 빈도를 수정하는 것입니다.

다음의 허가를 받아 복제됨시오스

Filed Under: 서버 클러스터 단순화 Tagged With: 복제

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

7월 22, 2020 by Jason Aw Leave a Comment

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

백업, 복제 및 고 가용성 (HA) 클러스터링은 IT 위험 관리의 기본 요소이며 자동차의 바퀴만큼이나 필수적입니다. IT 데이터 보호에도 복제가 필수적입니다.

백업 및 HA 클러스터 환경은 상호 배타적이지 않습니다

백업, 복제 및 페일 오버가 모두 중요하지만 이들을 올바르게 적용하려면 이해해야 할 주요 차이점이 있습니다.

예를 들어, 더 큰 데이터 보호 환경에서 데이터를 고려하지 않고 복제를 사용하여 지속적으로 최신 데이터 사본을 유지 보수 할 수 있지만, 바이러스에 감염된 데이터와 같은 문제점 데이터도 복사합니다.

이러한 경우 데이터를 마지막으로 알려진 올바른 지점으로 되돌리려면 백업이 필수적입니다. 복제를 수행하면 데이터를 생성하여 eDiscovery 유형 모델에서 지원할 수없는 방식으로 시스템 장애 직전에 복제 된 이미지에 액세스 할 수 있습니다 (= RTO / RTO가 우수함).

따라서 "SIOS Protection Suite"에는 SIOS LifeKeeper 클러스터링 소프트웨어와 DataKeeper 복제 소프트웨어가 모두 포함됩니다. SIOS LifeKeeper는 애플리케이션 상태를 모니터링하고 애플리케이션 페일 오버를 오케스트레이션하는 HA 페일 오버 클러스터 제품이며 DataKeeper는 블록 기반 스토리지 복제 소프트웨어입니다. 그러나 HA 클러스터라고해서 백업이 필요하지 않다는 의미는 아닙니다. SIOS Protection Suite를 사용하여 HA 클러스터 환경에서 백업 할 때주의 사항 및주의 사항을 고려하십시오.

고 가용성 클러스터링 환경에서 5 가지 백업 지점

백업 획득의 대상으로 다음 5 가지 사항을 고려하십시오.

  1. 운영 체제 (OS)
  2. SIOS Protection Suite – LifeKeeper / DataKeeper 프로그램 클러스터링 소프트웨어
  3. SIOS Protection Suite – LifeKeeper / DataKeeper 구성 정보
  4. 응용 프로그램 (예 : SQL Server, SAP S / 4 HANA, Oracle, PostgreSQL 등)
  5. 응용 프로그램 데이터

OS 백업

OS를 백업하려면 표준 OS 유틸리티 또는 타사 백업 소프트웨어를 사용하는 것이 일반적입니다. 그러나 "고 가용성"환경에는 특별한 고려 사항이 없으므로 여기서 다루지 않습니다.

SIOS Protection Suite 클러스터링 소프트웨어 백업

SIOS Protection Suite에는 SIOS LifeKeeper / DataKeeper 프로그램이 포함되어 있습니다. OS 표준 유틸리티 또는 타사 백업 소프트웨어를 사용하여 얻을 수도 있지만 디스크 오류 등으로 인해 프로그램이 사라지는 경우. 의도적으로 백업하지 않고 다시 설치해야합니다. 아마도 이분법에 대해 생각하는 사람들이있을 것입니다.

SIOS Protection Suite 구성 정보 백업

SIOS LifeKeeper에는 구성 정보를 백업 할 수있는 lkbackup이라는 간단한 명령이 제공됩니다. lkbackup은 SIOS LifeKeeper 및 관련 리소스에서 실행될 수 있으며 실행중인 서비스에는 영향을 미치지 않습니다.

이 명령은 다음 세 가지 주요 경우에 실행될 수 있습니다.

  • 새로 생성 된 SIOS LifeKeeper 리소스를 설치 한 직후
  • SIOS LifeKeeper 구성 변경 전후 (종속성 추가 / 변경, 자원 추가 / 삭제)
  • SIOS LifeKeeper 버전 업그레이드 전후

lkbackup으로 구성 정보를 백업하는 경우 디스크 고장으로 인해 구성 정보가 사라지거나 조작 실수 등으로 구성 정보가 손상된 경우에도) 원래의 작동 상태로 빠르게 돌아갈 수 있습니다.

백업 운영 프로그램

운영 프로그램 백업은 HA 클러스터에서 보호되는 비즈니스 응용 프로그램을 백업하는 것을 의미하지만 1에서와 같이 OS 표준 유틸리티 또는 타사 백업 소프트웨어를 사용하여 백업 이미지를 생성 및 복원 할 수 있습니다. 그리고 위의 2.

백업 비즈니스 애플리케이션 데이터

HA 클러스터 환경에서는 활성 및 대기 서버 모두가 액세스 할 수있는 공유 스토리지가 제공됩니다. 정상 작동 중에는 공유 스토리지가 활성 클러스터 노드에서 사용됩니다. 응용 프로그램 데이터 (예 : 데이터베이스 데이터)는 일반적으로이 공유 스토리지의 스토리지이지만이 스토리지를 백업 할 때 다음 사항을 명심해야합니다.

공유 스토리지 구성 

활성 클러스터 노드와 대기 시스템이 공유하는 스토리지로 SANless 클러스터 구성에있는 데이터의 백업을 확보 할 때, 활성 시스템에서만 데이터에 액세스 할 수 있습니다 (대기 시스템은 데이터에 액세스 할 수 없음). 결과적으로 백업도 활성화됩니다. 이 경우 장애 조치 및 백업 복원 시나리오를 처리하기에 충분한 처리 능력이 있는지 확인하십시오.

공유 스토리지 구성

 

데이터 복제 구성 

"데이터 복제"구성의 경우 운영 체제에서의 백업이 기본이지만 미러링을 일시적으로 중지하고 잠금을 해제하면 백업을 대기 시스템 측에서도 실행할 수 있습니다. 그러나이 경우 데이터가 일시적으로 동기화되지 않습니다.

데이터 복제 구성

외부 백업 서버에서 클러스터 노드 백업

외부 백업 서버에서 클러스터 노드 백업을 수행하려면 클러스터 노드의 가상 또는 실제 IP 주소를 사용하십시오. 각 경우에 유의해야 할 사항은 다음과 같습니다.

클러스터 노드의 가상 IP 주소를 사용하여 백업

백업 서버의 관점에서 LifeKeeper의 가상 IP 주소로 표시된 노드로 백업이 실행됩니다. 이 경우 백업 서버는 어떤 노드가 활성 노드인지 알 필요가 없습니다.

클러스터 노드의 가상 IP 주소를 사용하여 백업

클러스터 노드의 실제 IP 주소를 사용하여 백업

백업 서버의 관점에서 LifeKeeper의 가상 IP 주소를 사용하지 않고 실제 IP 주소로 백업이 수행됩니다. 대기 클러스터 노드에서 공유 스토리지에 액세스 할 수 없으므로 백업 서버와 클라이언트는 어떤 노드가 활성 노드인지 확인해야합니다.

잘 테스트되고 검증 된 구성 백업에서 백업, 복제 및 장애 조치 클러스터링을 결합하는 것이 필수적입니다. 사용자 측에서 사전에 충분한 작동 검증을 수행하십시오.

SIOS의 허가하에 재생

Filed Under: 서버 클러스터 단순화 Tagged With: 복제

Fusion-io를 사용하여 Linux 클러스터링의 복제 성능 극대화

11월 27, 2018 by Jason Aw Leave a Comment

Fusion-io를 사용하여 Linux 클러스터링의 복제 성능 극대화

Linux 클러스터링에서 복제 성능을 극대화하는 팁 Fusion-io

대부분의 사람들은 클러스터 설정에 대해 생각할 때 대개 둘 이상의 서버와 SAN 또는 다른 유형의 공유 저장 장치를 필요로합니다. SAN은 일반적으로 설정 및 유지 관리에 매우 비용이 많이 들고 복잡합니다. 또한 클러스터 아키텍처에서 기술적으로 단일 장애 지점 (SPOF)을 나타냅니다. 요즘 점점 더 많은 사람들이 번개 빠른 ioDrive를 통해 Fusion-io와 같은 회사로 전환하여 중요한 응용 프로그램을 가속화하고 있습니다.  이러한 저장 장치는 서버 내에 있습니다 (즉, "공유 디스크"가 아닙니다). 따라서 기존의 많은 클러스터링 솔루션이있는 클러스터 디스크로 사용할 수 없습니다. 다행스럽게도 Fusion-io를 사용하여 Linux 클러스터링의 복제 성능을 극대화하는 방법이 있습니다. 공유 저장 장치가없는 경우 장애 조치 클러스터를 구성 할 수있는 솔루션, 즉 "공유되지 않은"클러스터.

전통적 클러스터 Fusion-io를 사용한 Linux 클러스터링의 복제 성능 극대화 - 기존 클러스터  "Shared Nothing"클러스터Fusion-io-Shared-Nothing Cluster를 사용하여 Linux 클러스터링의 복제 성능 극대화

클러스터 구성의 일부로 데이터 복제를 활용할 때는 충분한 대역폭을 확보하여 디스크에 기록 된 것만큼 빠르게 네트워크를 통해 데이터를 복제 할 수 있어야합니다.  다음은 고속 스토리지가 관련되어있을 때 "공유 안 함"클러스터 구성을 최대한 활용할 수있게 해주는 튜닝 팁입니다.

회로망

  • 10Gbps NIC 사용 : Fusion-io의 플래시 기반 저장 장치 (또는 OCZ, LSI 등의 유사한 제품)는 HUNDREDS (750) MB / 초 이상의 속도로 데이터를 쓸 수 있습니다.  1Gbps NIC는 이론상 최대 ~ 125MB / sec의 속도를 낼 수 있기 때문에 ioDrive의 잠재력을 이용하는 모든 사람이 1Gbps 네트워크 연결을 통해 전달할 수있는 것보다 훨씬 빨리 데이터를 쓸 수 있습니다.  실시간 데이터 복제를 용이하게하기 위해 서버간에 충분한 대역폭을 확보하려면 복제 트래픽을 전달하는 데 항상 10Gbps NIC를 사용해야합니다
  • 점보 프레임 활성화 : 네트워크 카드와 스위치가이를 지원한다고 가정하면 점보 프레임을 활성화하면 네트워크 처리량을 크게 늘릴 수 있으며 동시에 CPU주기를 줄일 수 있습니다.  점보 프레임을 활성화하려면 다음 구성을 수행하십시오 (예 : RedHat / CentOS / OEL Linux 서버)
    • ifconfig <인터페이스 이름> mtu 9000
    • / etc / sysconfig / network-scripts / ifcfg- <interface_name> 파일을 편집하고 "MTU = 9000"을 추가하여 재부팅시 변경 사항이 지속되도록하십시오
    • 엔드 – 투 – 엔드 점보 프레임 작동을 확인하려면 다음 명령을 실행하십시오. ping -s 8900 -M do <IP-of-other-server>
  • NIC의 전송 대기열 길이 변경 :
    • / sbin / ifconfig <인터페이스 _ 이름> txqueuelen 10000
    • 다시 부팅 할 때마다 설정을 유지하려면 /etc/rc.local에 추가하십시오.

TCP / IP 조정

  • NIC의 netdev_max_backlog를 변경하십시오.
    • /etc/sysctl.conf에 "net.core.netdev_max_backlog = 100000"을 설정하십시오.
  • 복제 성능을 향상시키는 다른 TCP / IP 조정 :
    • 참고 :이 값은 예제 값이며 하드웨어 구성에 따라 조정해야 할 수도 있습니다
    • /etc/sysctl.conf를 편집하고 다음 매개 변수를 추가하십시오.
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = htcp

조정

일반적으로 구현하려는 클러스터링 및 복제 기술에 따라 달라지는 클러스터 구성을 조정해야합니다.  이 예에서는 SIOS Technologies의 Linux 용 SteelEye Protection Suite (일명 LifeKeeper SPS)를 사용하고 있습니다. 사용자는 파이버 채널 SAN, iSCSI, NAS 또는이 기사와 가장 관련이있는 클러스터 노드간에 실시간으로 동기화 / 복제해야하는 로컬 디스크를 비롯하여 모든 백 엔드 저장소 유형을 활용하여 장애 조치 (failover) 클러스터를 구성 할 수 있습니다.  SPS for Linux에는 통합 된 블록 레벨 데이터 복제 기능이 포함되어있어 공유 스토리지가 필요없는 클러스터를 쉽게 설정할 수 있습니다.

권장 사항

Fusion-io를 사용하여 Linux 클러스터링의 복제 성능을 극대화하려면 다음을 시도해보십시오. Linux 구성 권장 사항 인 SteelEye Protection Suite (SPS) :

  • Fusion-io 드라이브에있는 작은 (~ 100 MB) 디스크 파티션을 할당하여 비트 맵 파일을 배치하십시오.  이 파티션에 파일 시스템을 만들고 마운트합니다 (예 : / bitmap).
    • # mount | grep / bitmap
    • / dev / fioa1 on / 비트 맵 유형 ext3 (rw)
  • 미러를 만들기 전에 / etc / default / LifeKeeper에서 다음 매개 변수를 조정하십시오
    • 삽입 : LKDR_CHUNK_SIZE = 4096
      • 기본값은 64입니다.
    • 편집 : LKDR_SPEED_LIMIT = 1500000
      • (기본값은 50000 임)
      • LKDR_SPEED_LIMIT는 재 동기화가 취할 최대 대역폭을 지정합니다.이 값은 가능한 한 최대 속도로 재 동기화를 수행 할 수 있도록 충분히 높게 설정해야합니다
    • 편집 : LKDR_SPEED_LIMIT_MIN = 200000
      • (기본값은 20000 임)
      • LKDR_SPEED_LIMIT_MIN은 다른 I / O가 동시에 진행될 때 재 동기화를 허용하는 속도를 지정합니다. 일반적으로 굶주림을 피하려면 드라이브의 최대 쓰기 처리량의 절반 이하로 설정해야합니다 재 동기화가 발생할 때 정상 I / O 활동을 종료합니다.

여기에서 계속해서 거울을 만들고 평소와 같이 클러스터를 구성하십시오. Linux 클러스터링에서 복제 성능 극대화에 관심 Fusion-io를 사용하면 SIOS가 제공 할 수있는 다른 기능을 살펴보십시오. LinuxClustering의 허가를 받아 재현

Filed Under: Datakeeper, 서버 클러스터 단순화 Tagged With: fusion io로 리눅스 클러스터링을위한 복제 성능 극대화, 리눅스, 복제, 융합 - io

Azure에서 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터를 작성하는 방법

9월 10, 2018 by Jason Aw Leave a Comment

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

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

새로운 기능인 Cloud Witness는 현재 내가 가장 좋아하는 기능입니다. Windows Server 2016의 새로운 쿼럼 기능을 살펴보기 전에 우리가 어디서 왔는지를 아는 것이 중요하다고 생각합니다. 이전 글에서는 Windows Server 2012 R2의 Windows Server 장애 조치 (Failover) 클러스터 쿼럼 (Understanding the Windows Server Failover Cluster Quorum)에 대해 클러스터 쿼럼의 내역과 발전에 대해 자세히 설명했습니다. 이 게시물을 검토하여 Windows Server 2012 R2에서 쿼럼이 어떻게 작동하는지 이해하는 것이 좋습니다. 또한 Windows Server 2016의 새로운 기능으로 인해 클러스터 배포가 더욱 탄력을받을 것입니다.

구름 증인

Cloud Witness를 사용하면 Azure Blob 저장소를 활용하여 클러스터의 미러링 모니터 역할을 할 수 있습니다. 이 증인은 디스크 증인이나 파일 공유 증인이 될 것입니다. Cloud Witness의 구성은 매우 쉽습니다. 내 경험에 비추어 볼 때 Azure에서 호스트해야 할 것이 없습니다. 유일한 단점은 클러스터 노드가 Azure BLOB 저장소와 인터넷을 통해 통신 할 수 있어야한다는 것입니다. 매우 자주 클러스터 노드는 공용 인터넷에 통신 할 수 없습니다. 따라서 Cloud Witness를 사용하려면 보안 팀과상의해야합니다. Cloud Witness를 사용하여 Azure에서 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 구축해야하는 많은 이유가 있습니다. 하지만 필자는 저에게 Azure의 장애 조치 클러스터, 지점 클러스터 및 다중 사이트 클러스터의 세 가지 매우 특정한 환경에서 가장 잘 이해하고 있습니다.

가까이에서

Cloud Witness가 어떻게 도움이되는지 알아 보려면 각 시나리오를 살펴 보겠습니다. 그림 1 – 다중 인스턴스 SQL Server 장애 조치 (FAzure에서 다중 인스턴스 SQL Server 장애 조치 (failover) 클러스터를위한 새로운 ILB 기능ailover) 클러스터를 Azure에서 빌드하려고 할 때 클라우드 감시 서버 저장소는 항상 구성되어야합니다. 로컬 중복 저장소 (Local Advisory Storage) (LRS) [/ caption]

고 가용성 배포

Azure (또는 정말로 클라우드 제공자)로 이동하는 경우, 배치의 가용성을 높이고 싶을 것입니다. Windows Server 장애 조치 (Failover) 클러스터링으로 전통적으로 클러스터링 된 SQL Server, 파일 서버, SAP 또는 다른 작업 부하를 처리하는 경우 Azure에서 디스크 감시가 불가능하므로 파일 공유 감시 또는 클라우드 감시를 사용해야합니다. Windows Server 2012 R2 또는 Windows Server 2008 R2에서는 파일 공유 감시 기능을 사용해야합니다. Windows Server 2016을 사용하면 Cloud Witness를 사용할 수 있습니다. Cloud Witness의 이점은 파일 공유를 호스팅하기 위해 Azure에서 다른 Windows 인스턴스를 유지 관리 할 필요가 없다는 것입니다. 대신 Blob 저장소를 활용할 수 있습니다.  이렇게하면 관리하기가 훨씬 쉽고 탄력적 인 솔루션을 얻을 수 있습니다.

위치

지사의 클러스터 구축을 고려할 때 비용 및 유지 관리가 항상 고려됩니다. 수백 또는 수천 개의 위치가있는 소매 체인의 경우 각 위치에 SAN을 설치하는 것은 비용이 많이들 수 있습니다. 각 위치에서 다수의 가상 시스템을 호스트하기 위해 S2D Hyper-converged 구성 또는 타사 복제 솔루션에서 2 노드 Hyper-V 클러스터를 실행할 수 있습니다. 이제 Cloud Witness가 할 수있는 일은 각 위치에 추가 물리적 서버를 추가하는 비용을 피하여 파일 공유 감시 또는 각 위치에 SAN을 추가하는 데 드는 비용을 피할 수 있도록 지원하는 것입니다.

세 번째 데이터 센터에 대한 필요성 제거

마지막으로 다중 사이트 클러스터를 배포 할 때 Cloud Witness는 File Share Witness를 호스팅 할 세 번째 데이터 센터가 필요하지 않습니다. Cloud Witness가 도입되기 전에 File Share Witness가 3 번째 위치에 있어야한다고 명시하는 것이 가장 좋습니다. 파일 공유 감시를 호스팅하기위한 제 3의 데이터 센터에 대한 액세스는 항상 실현 가능할뿐만 아니라 또 다른 복잡성의 층을 가져 왔습니다. Cloud Witness를 사용하면 세 번째 위치를 유지할 필요가없고 감시 네트워크에 대한 액세스가 공용 인터넷을 통해 이루어 지므로 네트워크 요구 사항도 최소화됩니다.

사이트 인식

다중 사이트 클러스터를 구축 할 때 또 다른 공통된 문제가있었습니다. 로컬 사이트를 항상 선호하도록 장애 조치를 제어하는 ​​것은 불가능했습니다. 기본 소유자를 지정할 수는 있지만 기본 설정 소유자는 일반적으로 잘못 이해합니다. 관리자는이를 인식하지 못할 수도 있습니다. 그러나 기본 소유자로 서버를 나열하지 않더라도 서버는 클러스터에서 유지 관리하는 기본 소유자 목록의 끝에 자동으로 추가됩니다. 이 오해의 결과는 로컬 서버를 기본 소유자로 나열했을지라도 잠재적으로 DR 사이트에 대한 클러스터 리소스 페일 오버를 가질 수 있다는 것입니다. 그리고 이것은 로컬 사이트에서 사용할 수있는 완벽한 노드가있는 경우에도 마찬가지입니다. 분명히 이것은 당신이 기대하는 것이 아니며 사이트 인식을 사용하면 앞으로이 문제를 제거 할 수 있습니다. 사이트 인식은 온라인 상태로 전환 할 노드를 결정할 때 항상 로컬 사이트를 선호하므로이 문제를 해결합니다. 따라서 정상적인 상황에서 클러스터 된 작업 부하는 완전한 사이트 중단이 발생하지 않는 한 항상 로컬 노드로 장애 조치됩니다. 이 경우 DR 노드 중 하나가 온라인 상태가됩니다. DR 사이트에서 실행되면 동일하게 적용됩니다. 클러스터는 DR 사이트의 노드에서 이전에 실행 중이었던 DR 사이트의 서버에서 작업 부하를 복구합니다. 사이트 인식은 항상 로컬 노드를 선호합니다.

오류 도메인

사이트 인지도를 구축하는 것은 결함 도메인입니다. 오류 도메인 (Fault Domains)은 한 걸음 더 나아가 사이트 (Site) 외에도 노드, 섀시 및 랙 위치를 정의 할 수있게합니다. 오류 도메인에는 3 가지 장점이 있습니다. 스트레치 클러스터의 스토리지 선호도는 스토리지 공간 복원력을 높입니다. 경보를 발생시키는 관련 자원의 위치에 대한 메타 데이터를 포함하여 Health Services 경보를 향상시킵니다. Storage Affinity는 클러스터 작업 부하와 스토리지가 동일한 위치에서 실행되도록합니다. 확실히 당신의 VM이 다른 도시의 CSV에 앉아 데이터를 읽고 쓰는 것을 원하지 않을 것입니다. 그러나 여기서 가장 큰 승자는 S2D (Storage Spaces Directive) 시나리오입니다. SD2는 클러스터 노드 위치 (사이트, 랙, 섀시)에 대해 제공 한 정보를 활용하여 중복성을 위해 작성된 여러 데이터 복사본이 서로 다른 오류 도메인에 있는지 확인합니다. 이를 통해 단일 Node, Chassis, Rack 또는 Site의 장애로 인해 전체 S2D 배치가 중단되지 않도록 데이터 배치를 최적화 할 수 있습니다.  코스모스 다윈 (Cosmos Darwin)은이 개념을 아주 자세하게 설명하는 채널 9에 관한 훌륭한 비디오를 가지고 있습니다.

개요

Windows Server 2016은 클러스터 배포에 몇 가지 즉각적인 이점을 제공하는 몇 가지 새로운 기능을 클러스터 쿼럼에 추가합니다. 또한 롤링 시스템 업그레이드, 가상 컴퓨터 복원력, 작업 그룹 및 다중 도메인 클러스터 및 기타 여러 가지 새로운 클러스터 향상된 기능을 확인하십시오. 새로운 Multi-Instance SQL Server 장애 조치 클러스터 구축과 같은 다른 팁을 읽으려면 Cloud Witness가있는 Azure에서 게시물을 읽으십시오. Clusteringformeremortals.com의 허락을 받아 재현

Filed Under: 서버 클러스터 단순화 Tagged With: Azure Resource Manager, PowerShell, System Center 구성 관리자, Windows Server 2012, 구름 증인, 로드 균형, 복제, 전개, 푸른 하늘에있는 다중 인스턴스 SQL 서버 장애 조치 클러스터

데이터 보호를위한 SIOS 데이터 복제 및 재해 복구 솔루션

5월 27, 2018 by Jason Aw Leave a Comment

데이터 보호를위한 SIOS 데이터 복제 및 재해 복구 솔루션

소프트웨어 회사, SIOS의 비용 효과적인 데이터 복제 및 지속적인 데이터 보호를위한 재해 복구 솔루션을 사용하는 교육 기관

많은 기대를 모으고있는 Windows Server 2008 R2가 10 월 말에 출시되었습니다. VISUCATE는 Microsoft Hyper-V를 배포하고 라이브 마이그레이션과 같은 새로운 기능을 즐길 수있는 많은 중소기업 중 하나가되었습니다. 회사는 데이터 복제 및 재난 복구 솔루션이 필요했습니다. 합리적으로 가격이 책정되고 일급 보호를 제공 한 제품.

VISUCATE는 자체 설정을 완료하기 위해 소규모 기업의 기대치를 충족시키는 비즈니스 연속성 플랫폼을 원했습니다. Windows Server 장애 조치 (Failover) 클러스터링의 고 가용성 기능을 활용했습니다. 그러나 5fhbvd VISUCATE는 중요한 데이터 또는 중단 시간의 손실이 소프트웨어 판매를 손상시키지 않을 것이라는 추가적인 보장이 필요했습니다. 이러한 특정 데이터 복제 장애물을 해결하기 위해 VISUCATE는 SIOS DataKeeper Cluster Edition을 사용했습니다.

도전 과제

또한 새로운 Hyper-V 설정을 보호하기 위해 합리적인 가격의 단순하고 강력한 데이터 복제 및 재해 복구 솔루션이 필요했습니다. 다운 타임을 방지하기 위해 회사는 운영 기능을 복제하고 유지 관리 할 서버가 필요했습니다. 하나의 서버에 장애가 발생하면 다른 서버가 가동을 유지하고 가동 시간을 최대화하며 사용자의 생산성을 보장하도록 인계합니다. Microsoft Hyper-V와 Windows Server 장애 조치 (Failover) 클러스터링 및 SIOS DataKeeper Cluster Edition의 공동 솔루션은 VISUCATE에 필수적인 비즈니스 요구 사항과이 과제를 해결하려는 모든 조직의 의도를 해결했습니다.

VISUCATE, SIOS DataKeeper®로 Hyper-V 가용성, 비즈니스 연속성 유지

VISUCATE는 Hyper-V 역할을 사용하는 두 대의 실제 서버에 Windows Server 2008 R2를 배포했습니다. 이 회사는 Windows Server 장애 조치 (Failover) 클러스터링 및 SIOS DataKeeper Cluster Edition을 사용하여 가상 컴퓨터의 복제 및 장애 조치를 제공합니다. Hyper-V 배포를 통해 VISUCATE의 5 개의 가상 컴퓨터가 두 서버에 설치되었습니다. 한 서버에 세 개, 다른 서버에 두 개.

작동중인 Windows Server 2008 Hyper-V 가상 컴퓨터를 두 개의 실제 서버간에 동기화함으로써 SIOS DataKeeper는 일반적으로 일반적인 백업 및 복원 기술과 관련된 복구 및 다운 타임없이 재해 복구를 가능하게합니다. 활성 Windows Server 2008 Hyper-V 가상 컴퓨터의 실시간 연속 복제는 VISUCATE 설정에 영향을주는 중단 시간이 발생해도 복제 된 가상 컴퓨터를 데이터 유실없이 최소한의 상태로 유지할 수 있습니다. VISUCATE는 장애 조치 클러스터 솔루션에 대한 몇 가지 옵션을 고려했습니다. 회사는 저렴한 비용의 SAN 또는 NAS / 파일 서버로 클러스터를 생성하는 옵션을 취소했습니다. 해당 구성의 SAN이 손상된 경우 전체 설치가 실패합니다.

SIOS DataKeeper Cluster Edition은 SAN의 필요성을 제거함으로써 클러스터 배치 비용을 줄입니다. 또한 기존의 공유 스토리지 클러스터에서 SAN이 대표하는 단일 실패 지점을 제거함으로써 가상 시스템 및 애플리케이션의 가용성을 향상시킵니다.

은혜

SIOS DataKeeper Cluster Edition을 사용하면 VISUCATE와 같은 회사에서 "비공유"및 지리적으로 분산 된 Windows Server 2008 Hyper-V 클러스터를 구축 할 수 있습니다. 공유 스토리지에 대한 요구 사항을 제거함으로써 기업은 서버 및 스토리지에 대한 계획된 또는 계획되지 않은 중단 시간으로부터 보호 할 수 있습니다. 또한 Windows Server 2008 Hyper-V 가상 컴퓨터에서 SIOS DataKeeper를 사용하면 무중단 재해 복구 테스트가 가능합니다. VISUCATE 및 다른 회사는 재난 복구 사이트에서 복제 된 가상 시스템에 간단히 액세스하여 프로덕션 네트워크와 별도로 가상 네트워크를 분할 할 수 있습니다. 또한 재해 복구 테스트를 위해 복제 된 가상 컴퓨터를 시작할 수도 있습니다. 관리자는 프로덕션 사이트에 영향을주지 않고 전체 데이터 복제 및 재난 복구 솔루션 테스트를 수행 할 수 있습니다.

Hyper-V 클러스터 지원 외에도 SIOS DataKeeper Cluster Edition은 다른 모든 Microsoft 클러스터 리소스 유형에 대한 다중 사이트 클러스터를 지원합니다. 여기에는 SQL Server, Exchange, 파일 / 인쇄 및 DHCP가 포함됩니다.

SIOS 제품에 대한 자세한 내용을 보려면 여기로 이동하십시오.
SIOS가 VISUCATE가 데이터 복제 및 재해 복구 솔루션을 어떻게 도왔는지 읽어 보려면 여기로 이동하십시오.

Filed Under: 성공 사례 Tagged With: 데이터 복제 및 재해 복구 솔루션, 복제, 재해 복구 솔루션

최근 게시물

  • Nutanix 환경에서 고가용성 솔루션을 선택하기 위한 10가지 고려 사항
  • 내 서버는 일회용인가요? 고가용성 소프트웨어가 클라우드 모범 사례에 어떻게 적용되는가?
  • 재난에 취약한 세상을 위한 데이터 복구 전략
  • DataKeeper와 Baseball: 재해 복구에 대한 전략적 접근
  • SQL Server 가동 중지 위험에 대한 예산 책정

가장 인기있는 게시물

우리의 메일 링리스트에 가입하세요

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in