자료실

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 대신 지정해야합니다.

여기서 사용되지 않는 새 IP 주소를 지정하십시오. 나중에 나중에 내부로드 밸런서를 구성 할 때 사용할 동일한 IP 주소입니다.

앞에서 언급했듯이 SQL Server 2008 R2는 AD 보안 그룹을 사용합니다. 아직 작성하지 않았다면 SQL 설치의 다음 단계를 계속하기 전에 아래에 표시된대로 지금 작성하십시오.

앞서 작성한 보안 그룹을 지정하십시오.

지정한 서비스 계정이 연관된 보안 그룹의 구성원인지 확인하십시오.

여기서 SQL Server 관리자를 지정하십시오.

모든 것이 잘되면 이제 클러스터의 두 번째 노드에 SQL Server를 설치할 준비가되었습니다.

두 번째 노드에 SQL Server 설치

하나는 두 번째 노드로 SQL Server 2008 R2 SP3 설치를 실행하고 SQL Server 장애 조치 (Failover) 클러스터링 인스턴스에 노드 추가를 선택합니다.

다음 스크린 샷과 같이 설치를 진행하십시오.

모든 것이 잘되었다고 가정하면 이제 다음과 같은 두 노드의 SQL Server 2008 R2 클러스터가 구성되어 있어야합니다.

그러나 활성 클러스터 노드의 SQL Server 인스턴스에만 연결할 수 있습니다.

가용성 공식 – 고 가용성 솔루션

12월 9, 2018 by Jason Aw Leave a Comment

가용성 공식

가용성 방정식에 익숙합니까? 간단히 말해서,이 방정식은 애플리케이션을 가용성으로 복원하는 데 필요한 총 시간이 애플리케이션에 문제가 발생했음을 감지하는 데 필요한 시간과 복구 조치를 수행하는 데 필요한 시간을 합한 것과 같습니다.

T_RESTORE = T_DETECT + T_RECOVER

고 가용성 솔루션의 주요 개념

이 수식에서는 고 가용성 (HA)의 핵심 개념 인 클러스터링, 문제 감지 및 후속 복구를 소개합니다. HA 솔루션은 비즈니스 응용 프로그램 구성 요소의 상태를 모니터링합니다. 문제가 발견되면 이러한 솔루션은 서비스를 복원합니다. 고 가용성 솔루션을 배포하는 목적은 다운 타임을 최소화하는 것입니다. 탐지 및 복구 시간을 줄이는 것은 배포하도록 선택한 모든 HA 솔루션의 두 가지 중요한 작업입니다. 오늘날의 응용 프로그램은 서버, 저장소, 네트워크 인프라 등 기술 조합입니다. HA 옵션을 검토 할 때 각 솔루션이 모든 중단 유형을 감지하고 복구하는 데 사용하는 기술을 이해해야합니다. 각 기술은 서비스 복원 시간에 직접적인 영향을 미칩니다.

로컬 검색 및 복구

고 가용성 솔루션은 간단합니다. 가능한 가장 빠른 복원 시간을 제공하는 데 중요한 기술 중 하나가 로컬 탐지 및 복구 (서비스 수준 문제 감지 및 복구라고도 함)입니다. 기본 클러스터링 솔루션에서는 서버가 연결됩니다. 서버 실패시 하나 이상의 서버가 다른 서버의 작업을 인계받을 수 있도록 구성됩니다. 클러스터의 서버 노드는 하트 비트 신호라고도하는 작은 데이터 패킷을 계속해서 보내고 이들이 "활성"상태임을 나타냅니다. 간단한 클러스터 환경에서 한 서버가 하트 비트 생성을 중지하면 다른 클러스터 구성원은이 서버가 다운 된 것으로 간주합니다. 그런 다음 해당 서버의 작동 도메인에 대한 책임을 인수하는 프로세스를 시작합니다. 이 접근 방식은 서버 수준에서 실패를 감지하는 데 적합합니다. 그러나 문제로 인해 하트 비트 신호가 중단되거나 중단되지 않으면 서버 수준의 탐지가 적절하지 않습니다. 그보다는 실제로 정전의 정도와 영향을 확대 할 수 있습니다. 예를 들어, Apache 프로세스가 중단되면 서버가 여전히 하트 비트를 보낼 수 있습니다. 웹 서버 서브 시스템이 주요 기능 수행을 중단하더라도. 동일한 서버 나 다른 서버에서 Apache 하위 시스템을 다시 시작하는 대신 기본 서버 수준 클러스터링 솔루션은 백업 서버에서 오류가 발생한 서버의 전체 소프트웨어 스택을 다시 시작하므로 사용자가 중단되고 복구 시간이 연장됩니다.

어떻게 작동 하는가?

로컬 검색 및 복구를 사용하는 고급 클러스터링 솔루션은 개별 클러스터 서버 내에 상태 모니터링 에이전트를 배포하여 파일 시스템, 데이터베이스, 사용자 수준 응용 프로그램, IP 주소 등과 같은 개별 시스템 구성 요소를 모니터링합니다. 이러한 에이전트는 모니터링되는 구성 요소에 특정한 휴리스틱을 사용합니다. 따라서 에이전트는 운영 문제를 예측하고 감지 한 다음 가장 적절한 복구 작업을 수행 할 수 있습니다. 대부분의 경우 가장 효율적인 복구 방법은 동일한 서버에서 문제가되는 하위 시스템을 중지했다가 다시 시작하는 것입니다. 동일한 물리적 서버 내에서 복구를 사용 가능하게함으로써 응용 프로그램을 사용자 가용성으로 복원하는 시간을 크게 줄일 수 있습니다. 또한 단순히 서버 수준의 하트 비트를 관찰하는 것보다 세분화 된 수준에서 오류를 감지합니다. Linux 용 SteelEye Protection Suite (예 : SIOS)와 같은 솔루션은 사용자 환경에 대해 이러한 수준의 탐지 및 복구를 제공합니다. 배포하는 HA 솔루션이 로컬 탐지 및 복구를 지원할 수 있는지 확인하십시오. 귀사의 프로젝트에 고 가용성 솔루션을 즐기시겠습니까? 우리와 함께 확인하십시오. 더 많은 참고 문헌이 필요합니다. 여기에는 성공 사례가 있습니다. Linux 클러스터링의 허락을 받아 재현

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

11월 27, 2018 by Jason Aw Leave a Comment

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

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


전통적 클러스터	"Shared Nothing"클러스터

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

회로망

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의 허가를 받아 재현

파일 공유 감시 기능을 DFS 공유에 배치 할 수 있습니까?

10월 22, 2018 by Jason Aw Leave a Comment

파일 공유 감시 기능을 DFS 공유에 배치 할 수 있습니까?

나는 항상이 질문을받습니다 – 어디서 파일 공유 증인을 DFS 공유에 배치 할 수 있습니까? 사람들은 파일 공유 증인의 상실에 대해 우려하고 있습니다. 따라서 많은 다른 주식과 마찬가지로 일부 추가 가용성을 위해 DFS를 활용하고자합니다. 이는 매우 나쁜 생각이며 지원되지 않습니다. Microsoft는 최근 DFS 공유에서 파일 공유 감시가 지원되지 않는 이유를 정확하게 설명하는 훌륭한 블로그 기사를 게시합니다. https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/이 기사의 대부분은 사람들이 사용할 수 있는지 묻는 사람들에게도 적용됩니다. DataKeeper는 볼륨 리소스를 디스크 공유로 복제했습니다. 말이 되는군요. 다른 워크로드에 대해 물리적 디스크 리소스 대신 DataKeeper 볼륨 리소스를 사용할 수 있습니다. 왜 Disk Witness가 아닌가? 이 문제는 DFS 문제와 동일합니다. 두 서버간에 통신이 끊어지면 두 서버에서 볼륨이 온라인 상태가되지 않도록 보장 할 수 없습니다. 그것은 잠재적 인 스플릿 브레인 상태를 초래할 것입니다. Physical Disk 리소스는 SCSI 예약을 사용하여이 문제를 해결합니다. 이렇게하면 한 번에 하나의 클러스터 노드에서만 디스크에 액세스 할 수 있습니다. 좋은 소식은 Microsoft가 이미 복제 된 DataKeeper 볼륨 리소스를 사용하지 못하도록 차단한다는 것입니다. 그리고 Windows Server 2019에서 DFS 공유를 파일 공유 감시로 사용하는 것을 차단하는 것처럼 보입니다.

파일 공유 감시를 DFS 공유에 두는 것과 같은 질문이 있습니까? 블로그를 읽어 보거나 저희에게 연락하십시오! ClusteringForMereMortals.com의 허락을 받아 재현

S2D SQL Server 장애 조치 (Failover) 클러스터 인스턴스

9월 8, 2018 by Jason Aw Leave a Comment

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 직접적인 저장소 공간

Windows Server 2016 Datacenter Edition이 도입됨에 따라 Storage Spaces Direct (S2D)라는 새로운 기능이 도입되었습니다. 매우 높은 수준에서 S2D For SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 사용하면 로컬로 연결된 저장소를 함께 풀링하여 스케일 아웃 파일 서버에서 사용할 CSV로 클러스터에 표시 할 수 있습니다. 그런 다음 SMB 3을 통해 액세스 할 수 있으며 Hyper-V VMDK 파일과 같은 클러스터 데이터를 보유하는 데 사용됩니다. 또한 응용 프로그램과 데이터가 모두 동일한 서버 집합에서 실행될 수 있도록 하이퍼 수렴 (HCI) 방식으로 구성 할 수 있습니다. 이것은 지나치게 단순화 된 설명이지만 자세한 내용은 여기를 참조하십시오.

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview에서 가져온 이미지 주요 대상은 Hyper-V 배포를위한 하이퍼 – 컨버전스 인프라입니다. 그러나이 SMB 저장소를 활용하여 SQL Server 장애 조치 (Failover) 클러스터 인스턴스에서 사용할 SQL Server 데이터를 저장하는 등의 다른 사용 사례가 있습니다

왜 누군가는 그것을하고 싶습니까?

이제는 공유 스토리지가 필요없이 SQL Server Standard Edition을 통해 고 가용성 2 노드 SQL Server 장애 조치 (Failover) 클러스터 인스턴스 (FCI)를 구축 할 수 있습니다. 이전에 SAN없이 HA를 원한다면 SQL Server Enterprise Edition을 구입하고 항상 가용성 그룹을 사용하거나 SIOS DataKeeper를 구입하고 모든 버전의 Windows 또는 SANless 클러스터를 구축 할 수있는 타사 솔루션을 활용해야했습니다. SQL 서버. SQL Server Enterprise Edition은 특히 가용성 그룹 기능을 위해 SQL Server Enterprise Edition을 구입하는 경우 프로젝트 비용을 크게 높일 수 있습니다. 가용성 그룹과 관련된 비용 외에도 AG를 통해 장애 조치 (failover) 클러스터를 선호 할 수있는 여러 가지 기술적 인 이유가 있습니다. 응용 프로그램 호환성, 인스턴스 대 데이터베이스 수준 보호, 많은 수의 데이터베이스, DTC 지원, 숙련 된 직원 등은 장애 조치 (Failover) 클러스터 인스턴스를 유지하려는 기술적 이유 중 일부에 지나지 않습니다.

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 SIOS DataKeeper 솔루션 대 S2D

Microsoft는 SIOS DataKeeper 솔루션과 S2D 솔루션을 SQL Server FCI를 지원하는 두 가지 솔루션으로 여기에 설명합니다. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr 두 가지 솔루션을 비교할 때 다음을 고려해야합니다. SIOS는 1999 년부터 SANless 클러스터를 구축 할 수있게 해줍니다. 그러나 S2D For SQL Server 장애 조치 (Failover) 클러스터 인스턴스는 초기 단계입니다. 그렇다고해서 S2D가 따라 잡을만한 부분이있을 것입니다. 또는 단순히 기술의 한계로 인해 지원되지 않는 기능입니다.

SANless 클러스터 솔루션을 선택하기 전에

SANless 클러스터 솔루션을 선택하기 전에 고려해야 할 몇 가지 사항에 대한 개요는 다음 표를보십시오. S2D SQL Server 장애 조치 (Failover) 클러스터 인스턴스 이 차트를 살펴보면 SIOS DataKeeper에는 몇 가지 중요한 이점이 있음을 알 수 있습니다. 그 중 하나 인 DataKeeper는 Windows Server 2008 R2 및 SQL Server 2008 R2로 다시 돌아가는 훨씬 다양한 플랫폼을 지원합니다. S2D 솔루션은 Windows 및 SQL Server 2016/2017의 최신 릴리스 만 지원합니다. 또한 S2D는 Windows Datacenter Edition을 필요로하므로 배포 비용이 크게 추가 될 수 있습니다. 또한 SIOS는 온 – 프레미엄과 클라우드에서 모두 작동하는 Linux 용 SQL Server 전용 HA / DR 솔루션을 제공합니다.

차이점 분석

비용 및 플랫폼의 한계를 넘어, SANless 클러스터의 재난 복구 옵션을 고려할 때 가장 큰 차이가 발생한다고 생각합니다. SQL Server Cluster 전문가이자 동료 Microsoft Cloud 및 Datacenter 관리 MVP 인 Allan Hirt는 최근에이 S2D 제한에 대해 게시했습니다. 스토리지 공간 직접 방문 및 SQL Server FCI에 대한 기사에서 Allan은 사이트 전체에서 S2D 클러스터를 확장하거나 Always Availability 그룹에서 S2D 기반 클러스터를 다리로 포함 할 수있는 지원이 부족하기 때문에 S2D 시나리오는 로그 전달입니다! 나를 오해하지 마라. 로그 전달은 영원히 계속되었으며 내가 사라진 후 아마도 오래있을 것입니다. 그러나 다중 사이트 클러스터, 가용성 그룹 등과 같이 익숙해 진 모든 재해 복구 솔루션에 대해 생각할 때 거슬러 올라갑니다. 반면 SIOS DataKeeper 솔루션은 Always On Availability Groups를 완벽하게 지원합니다. 더 나은 방법은 RTI / RPO 관점에서 달성 할 수있는 최상의 HA / DR 솔루션을 제공하기 위해 여러 사이트에서 FCI를 확장 할 수 있습니다. Azure 환경에서 DataKeeper는 ASR (Azure Site Recovery)을 지원하므로 재난 복구를위한 더 많은 옵션을 제공합니다. 이 차트의 나머지 부분은 꽤 자명합니다. 기본적으로 S2D 클러스터를 배치하기 전에 충족시켜야하는 하드웨어, 스토리지 및 네트워킹 요구 사항 목록으로 구성됩니다. 여기에는 S2D 요구 사항의 철저한 목록이 있습니다. https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper. 무슨 좋은

SIOS DataKeeper 솔루션은 훨씬 관대합니다. 로컬로 연결된 모든 저장소를 지원하며 하드웨어가 클러스터 유효성 검사를 통과하면 지원되는 클러스터 구성입니다. 블록 레벨 복제 솔루션은 1Gbps가 고속 LAN으로 간주되고 T1 WAN 연결이 사치로 여겨지기 때문에 큰 성과를 거두었습니다. SANless 클러스터링은 클라우드 구축에 특히 유용합니다. 클라우드는 클러스터에 기존의 공유 스토리지 옵션을 제공하지 않습니다. 따라서 클라우드로 옮겨 가려는 사용자에게 클러스터를 가져 가려는 사용자는 대체 스토리지 솔루션을 고려해야합니다. 클라우드 배포의 경우 SIOS는 Azure, AWS 및 Google에 대한 인증을 받았으며 관련 클라우드 마켓에서 사용할 수 있습니다. Azure 또는 Google에서 S2D 기반 클러스터의 배포를 차단하는 것으로 보이는 것은 아니지만 해당 플랫폼에 대한 Microsoft의 설명서 또는 지원 가능성에 대한 언급이 눈에 띄지 않습니다.

안전한 선택 만들기

SIOS DataKeeper는 1999 년부터이 작업을 해오 고 있습니다. SIOS는 모든 기능 요청을 듣고 모든 버그를 밝혀 냈으며 시간을 테스트하고 입증 된 SANless 클러스터를위한 견고한 솔루션을 보유하고 있습니다. Microsoft S2D는 1 세대 제품으로 유망한 기술이지만 먼지가 잠길 때까지 기다렸다가 기능상의 차이로 인해 업무상 중요한 응용 프로그램으로 간주되기까지 기다릴 것입니다.

SQL Server 장애 조치 (Failover) 클러스터 인스턴스에 대한 자세한 내용은 여기를 참조하십시오. Clusteringformeremortals.com의 허가를 받아 복제 한 SIOS DataKeeper