단계별 : Azure에서 SQL Server 2008 R2 장애 조치 (Failover) 클러스터 인스턴스를 구성하는 방법

아직 Azure로 이동 한 후에도 SQL Server 인스턴스의 가용성이 높은 상태를 유지하는 방법을 알아 냈습니까? 오늘날 대부분의 사람들은 업무상 중요한 SQL Server 2008/2008 R2를 데이터 센터에 클러스터 된 인스턴스 (SQL Server FCI)로 구성합니다. Azure를 살펴볼 때 공유 저장소가 부족하여 SQL Server FCI를 Azure 클라우드로 가져올 수없는 것처럼 보일 수도 있습니다. 그러나 SIOS DataKeeper 덕분에 그렇지 않습니다. SIOS DataKeeper를 사용하면 Azure, AWS 또는 Google Cloud에서 SQL Server FCI를 구축 할 수 있습니다. 공유 스토리지를 사용할 수없는 곳이라면 어디에서나 사용할 수 있습니다. DataKeeper는 1999 년부터 Windows 및 Linux 용 SANless 클러스터를 활성화 해 왔습니다. Microsoft는 SIOS DataKeeper for SQL Server FCI 사용 설명서를 Azure Virtual Machines의 SQL Server에 대한 고 가용성 및 재해 복구 문서로 제공합니다. 이전에 Azure에서 실행중인 SQL Server FCI에 대해 작성했습니다. 그러나 SQL Server 2008/2008 R2 관련 단계별 가이드는 게시하지 않았습니다. 좋은 소식은 SQL 2012/2014/2016/2017에서와 마찬가지로 SQL 2008/2008 R2와 마찬가지로 훌륭하게 작동한다는 것입니다. 곧 2019 년에 발매 될 예정입니다. 또한 Windows Server (2008/2012/2016/2019) 또는 SQL Server (2008/2012/2014/2016/2017)의 버전에 관계없이 구성 프로세스가 유사하기 때문에이 가이드로 충분하므로 모든 구성. SQL 또는 Windows의 맛이 제 가이드에서 다루지 않는 경우 SQL Server FCI에 들어가서이 가이드를 참조하는 것을 두려워하지 마십시오. 이 가이드에서는 Windows Server 2012 R2와 함께 SQL Server 2008 R2를 사용합니다. 이 글을 쓰는 시점에서 필자는 Windows Server 2012 R2에서 SQL 2008 R2의 Azure Marketplace 이미지를 보지 못했습니다. 그래서 SQL 2008 R2를 수동으로 다운로드하여 설치해야했습니다. 개인적으로 나는이 조합을 선호합니다. Windows Server 2008 R2를 사용해야하는 경우 좋습니다. Windows Server 2008 R2를 사용하는 경우이 문서에서 설명하는 핫픽스를 설치하는 것을 잊지 마십시오.  Windows Server 2008 R2는 Azure의 FCI에 포함될 수 있습니다.

Azure 인스턴스 제공

나는 스크린 샷을 잔뜩 가지고 여기에 아주 자세히 들어가는 않을거야. 이유는 Azure Portal UI는 꽤 자주 바뀌는 경향이 있으며 스크린 샷은 오래 전에 낡아 빠질 것입니다. 대신, 나는 당신이 알고 있어야하는 중요한 주제들을 다룰 것입니다.

오류 도메인 또는 가용 영역?

SQL Server 인스턴스의 가용성을 높이려면 클러스터 노드가 다른 오류 도메인 (FD) 또는 다른 가용 영역 (AZ)에 있는지 확인해야합니다. 그 외에도 File Share Witness (아래 참조)는 클러스터 노드가있는 FD 또는 AZ와 다른 FD 또는 AZ에 있어야합니다. 여기에 그것이있다. AZ는 최신 Azure 기능이지만 지금까지 소수의 지역에서만 지원됩니다. AZ는 높은 SLA (99.99 %)를 제공 한 다음 FD (99.95 %)를 제공합니다. 또한, 게시자가 Azure Outage Post-Mortem에서 설명하는 종류의 클라우드 중단에 대비하여 사용자를 보호합니다. AZ를 지원하는 지역에 배포 할 수 있다면 AZ를 사용하는 것이 좋습니다. 이 가이드에서는로드 밸런서 구성에 관한 절을 읽었을 때 표시되는 AZ를 사용했습니다. 그러나 FD를 사용하는 경우로드 밸런서 구성이 가용 영역보다는 가용 세트를 참조한다는 점을 제외하면 모든 것이 정확히 동일합니다.

당신이 묻는 파일 공유 증인은 무엇입니까?

WSFC (Windows Server Failover Clustering)를 사용하면 장애 조치 (failover)가 올바르게 수행되도록 "감시 (Witness)"를 구성해야합니다. WSFC는 디스크, 파일 공유, 클라우드의 세 가지 종류의 증인을 지원합니다. 우리가 Azure에 있기 때문에 Disk Witness는 불가능합니다. 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 클러스터에 필요합니다.

클러스터 및 Datakeeper 볼륨 리소스 만들기

이제 클러스터 구축을 시작할 준비가되었습니다. 첫 번째 단계는 기본 클러스터를 만드는 것입니다. 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를 이미 설치했다면 괜찮습니다. 설치를 다시 실행하고 선택적인 설치 복구를 실행하기 만하면됩니다. 아래의 스크린 샷은 기본적인 설치 과정을 안내합니다. DataKeeper 설치 프로그램을 실행하여 시작하십시오.

아래에서 지정하는 계정은 도메인 계정이어야하며 각 클러스터 노드의 로컬 관리자 그룹에 속해야합니다.

SIOS License Key Manager가 제공되면 임시 키로 찾아 볼 수 있습니다. 또는 영구 키가있는 경우 시스템 호스트 ID를 복사하여 영구 키를 요청할 수 있습니다. 키를 새로 고침해야하는 경우 SIOS License Key Manager는 별도로 실행하여 새 키를 추가 할 수있는 프로그램입니다.

DataKeeper 볼륨 리소스 만들기

DataKeeper가 각 노드에 설치되면 첫 번째 DataKeeper 볼륨 리소스를 만들 준비가 된 것입니다. 첫 번째 단계는 DataKeeper UI를 열고 각 클러스터 노드에 연결하는 것입니다.

모든 것이 올바르게 완료되면 서버 개요 보고서는 다음과 같아야합니다.

이제 아래와 같이 첫 번째 작업을 만들 수 있습니다.

소스 및 대상을 선택하면 다음과 같은 옵션이 제공됩니다. 같은 지역의 로컬 타겟에 대해서만 선택해야하는 것은 Synchronous입니다.

예를 선택하고이 볼륨을 클러스터 리소스로 자동 등록하십시오.

이 프로세스를 완료하면 장애 조치 (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가 사용하는 포트를 잠그는 것입니다. 기본적으로 SQL Server의 명명 된 인스턴스는 1433을 사용하지 않습니다. 포트를 잠그면 방화벽 설정 및 Load Balancer 설정을 포함하여 1433 대신 해당 포트를 지정해야합니다.

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

앞에서 언급했듯이 SQL Server 2008 R2는 AD 보안 그룹을 사용합니다. 계속하기 전에 아래와 같이 SQL Server를 구성하십시오.

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

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

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

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

두 번째 노드에 SQL Server 설치

하나는 두 번째 노드로 SQL Server 2008 R2 SP3을 설치하고 SQL Server FCI에 노드 추가를 선택합니다.

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

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

그러나 활성 클러스터 노드의 SQL Server 인스턴스에만 연결할 수 있습니다. 문제는 Azure가 무상 ARP를 지원하지 않기 때문에 클라이언트가 클러스터 IP 주소에 직접 연결할 수 없다는 것입니다. 대신 클라이언트는 Azure Load Balancer에 연결해야합니다. 그러면 연결이 활성 노드로 리디렉션됩니다. 이 작업을 수행하려면 두 단계가 필요합니다. 먼저로드 밸런서를 만들고 SQL Server 클러스터 IP를 수정하여로드 밸런서 프로브에 응답합니다. 그런 다음 255.255.255.255 서브넷 마스크를 사용하십시오. 이러한 단계는 아래에 설명되어 있습니다.

Azure로드 밸런서 만들기

클라이언트가 SQL 클러스터의 내부 IP 주소와 직접 통신 할 수 있다고 가정하여이 가이드에서 내부로드 밸런서 (ILB)를 생성합니다. 공용 인터넷에서 SQL 인스턴스를 노출해야하는 경우 대신 Public Load Balancer를 사용할 수 있습니다. Azure 포털에서 아래와 같이 스크린 샷을 따라 새 Load Balancer를 만듭니다. Azure 포털 UI는 빠르게 변하지 만,이 스크린 샷은 필요한 작업을 수행 할 수있는 충분한 정보를 제공합니다. 우리가 따라갈 때 나는 중요한 세팅을 불러 낼 것이다. 여기서 우리는 ILB를 만듭니다. 이 화면에서 중요한 것은 "정적 IP 주소 할당"을 선택하고 SQL 클러스터 설치 중에 사용한 것과 동일한 IP 주소를 지정해야한다는 것입니다. 가용 영역을 사용했기 때문에 Zone Redundant가 옵션으로 사용됩니다. 가용성 세트를 사용하면 경험치가 약간 다를 수 있습니다.

백엔드 풀에서는 두 개의 SQL Server 인스턴스를 선택해야합니다. 풀에 파일 공유 감시 기능을 추가하고 싶지는 않습니다.

여기에서는 상태 프로브를 구성합니다. 대부분의 Azure 문서는 포트 59999를 사용하고 있으므로 우리는 해당 포트를 사용하여 구성합니다.

여기서로드 밸런싱 규칙을 추가 할 것입니다. 여기서는 모든 SQL Server 트래픽을 활성 노드의 TCP 포트 1433으로 리디렉션하려고합니다. Floating IP (Direct Server Return)를 Enabled로 선택하는 것도 중요합니다.

PowerShell 스크립트를 실행하여 SQL 클라이언트 액세스 지점 업데이트

이제로드 밸런서 프로브가 어떤 노드가 활성인지 감지 할 수 있도록 클러스터 노드 중 하나에서 Powershell 스크립트를 실행해야합니다. 또한이 스크립트는 방금 작성한 Load Balancer와의 IP 주소 충돌을 피할 수 있도록 SQL 클러스터 IP 주소의 서브넷 마스크를 255.255.255.255.255로 설정합니다.

# 변수 정의
$ ClusterNetworkName = "" 
# 클러스터 네트워크 이름 (Windows Server 2012에서 Get-ClusterNetwork를 사용하여 이름을 찾으십시오)
$ IPResourceName = "" 
# IP 주소 자원 이름 
$ ILBIP = "" 
# 내부 부하 분산 장치 (ILB) 및 SQL 클러스터의 IP 주소
가져 오기 모듈 장애 조치 (failover) 클러스터
# Windows Server 2012 이상을 사용하는 경우 :
Get-ClusterResource $ IPResourceName | Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"; 네트워크 = $ ClusterNetworkName; EnableDhcp = 0}
# Windows Server 2008 R2를 사용하는 경우 다음을 사용하십시오. 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999 subnetmask = 255.255.255.255

이것은 정확하게 실행되면 출력이 보입니다.

다음 단계

이 시점에 이르면 여전히 원격으로 클러스터에 연결할 수 없으므로 처음 사람이 아닙니다. 보안,로드 밸런서, SQL 포트 등의 측면에서 잘못 될 수있는 많은 것들이 있습니다. 연결 문제를 해결하는 데 도움이되는이 가이드를 작성했습니다. 실제로이 바로 설치에서 SQL Server 구성 관리자의 SQL Server TCP / IP 속성과 관련하여 이상한 문제가 발생했습니다. 속성을 살펴보면 SQL Server 클러스터 IP 주소가 수신 대기중인 주소 중 하나가 아니므로 수동으로 추가해야했습니다. 그게 변칙인지 확실하지 않습니다. 원격 클라이언트에서 클러스터에 연결하기 전에 확실히 해결해야 할 문제였습니다. 앞에서 언급했듯이이 설치에서 개선 할 수있는 점 중 하나는 TempDB 용 DataKeeper 비 미러 볼륨 자원을 사용하는 것입니다. 이를 설정하면 사람들이 일반적으로 실행하는 다음 두 가지 구성 문제에 유의하십시오. 첫 번째 문제는 tempdb를 첫 번째 노드의 폴더로 이동하는 경우 두 번째 노드에서 정확히 동일한 폴더 구조를 만들어야한다는 것입니다. 장애 조치를 시도 할 때 그렇게하지 않으면 TempDB를 만들 수 없기 때문에 SQL Server가 온라인 상태가되지 않습니다. 두 번째 문제는 클러스터를 만든 후에 다른 DataKeeper 볼륨 리소스를 SQL 클러스터에 추가 할 때 발생합니다. SQL Server 클러스터 리소스의 속성으로 이동하여 추가 한 새 DataKeeper 볼륨 리소스에 종속되게해야합니다. 이는 TempDB 볼륨 및 클러스터를 만든 후에 추가 할 수있는 다른 볼륨에 적용됩니다. SQL Server를 구성하고 Clusteringformeremortals.com의 허가를 받아 고 가용성을 재확인하는 방법을 보려면 여기를 읽어보십시오.

단계별 : 공유 저장 장치없이 Google Cloud Platform (Google Compute Engine)에서 Linux 장애 조치 클러스터를 구성하는 방법 #google #gce #sanless #cluster

이 단계별 가이드에서는 Google Cloud Platform (Google Compute Engine, 별칭 : GCE)에서 가용성이 높은 2 노드 MySQL 클러스터 (미러링 모니터 서버)를 구성하는 데 필요한 모든 단계를 안내합니다.  가이드에는 적절한 스크린 샷, 셸 명령 및 코드 스 니펫이 모두 포함되어 있습니다.  귀하는 Google Cloud Platform에 다소 익숙하며 이미 계정이 있다고 가정합니다.  그렇지 않은 경우 오늘 무료 평가판에 가입 할 수 있습니다.  기본적인 리눅스 시스템 관리 기술은 물론 가상 IP, 쿼럼 등과 같은 기본적인 장애 조치 클러스터링 개념을 이해하고 있다고 가정합니다.

면책 조항 : 클라우드는 빠르게 움직이는 목표입니다.  따라서 기능 / 화면 / 버튼은 시간이 지남에 따라 바뀌므로 아래에서 보는 것과 약간 다를 수 있습니다.  이 가이드에서는 MySQL 데이터베이스의 가용성을 높이는 방법을 설명하지만 SAP, PostgreSQL, Oracle, WebSphere MQ, NFS 파일 서버 등과 같은 다른 응용 프로그램이나 데이터베이스를 보호하기 위해이 정보와 프로세스를 확실히 적용 할 수 있습니다. 다음은 Google Compute Engine에서 고 가용성 MySQL 데이터베이스를 만드는 고급 단계입니다.

1. 프로젝트 만들기
2. 인스턴스 만들기 (가상 컴퓨터)
3. 인스턴스 그룹 만들기
4. VNC 액세스를 허용하는 방화벽 규칙 만들기
5. Linux OS 구성
6. MySQL 설치 및 구성
7. 클러스터 설치 및 구성
8. 내부로드 밸런서 만들기
9. 내부로드 밸런서에 대한 방화벽 규칙 만들기
10. 클러스터 연결 테스트

개요

이 기사에서는 단일 Google Cloud 지역 내에 클러스터를 만드는 방법에 대해 설명합니다.  클러스터 노드 (node1, node2 및 미러링 모니터 서버)는 모두 "us-central1"(10.128.0.0/20 네트워크) 영역에 있지만 해당 지역을 적절하게 선택할 수 있습니다. 구성은 다음과 같습니다. 다음 IP 주소가 사용됩니다.

• node1 : 10.128.0.2
• node2 : 10.128.0.3
• 목격자 : 10.128.0.4
• 내부로드 밸런서 IP : 10.128.0.99
• MySQL 포트 : 3306

프로젝트 만들기

처음 로그인하면 빈 홈 대시 보드가 표시되며 프로젝트를 생성하라는 메시지가 표시됩니다.  Google에서 만드는 모든 Google Compute Engine 리소스는이 Google Cloud Platform 프로젝트에 속합니다. 여기서 우리는 새롭게 생성 된 Project "LinuxCluster"를 호출 할 것입니다 :

인스턴스 만들기 (가상 컴퓨터)

이 가이드에서는 3 개의 가상 시스템을 프로비저닝 할 것입니다.  처음 두 VM ( "node1"및 "node2"라고 부름)은 MySQL 데이터베이스와 관련 리소스를 온라인 상태로 가져 오는 클러스터 노드로 작동합니다.  세 번째 VM은 스플릿 브레인에 대한 추가 보호를 위해 클러스터의 감시 서버 역할을합니다. 최대한의 가용성을 보장하기 위해 3 개의 VM이 모두 지역 내의 다른 영역 (예 : us-central1-a, us-central1-b, us-central1-c)에 있습니다.

"node1"인스턴스 만들기

첫 번째 VM 인스턴스 ( "node1")를 만듭니다.  인스턴스를 처음 작성한 경우 화면은 아래 이미지와 유사합니다. 화면 가운데에있는 "Create Instance"버튼을 클릭하십시오 : 다른 인스턴스가 이미 GCE에서 실행 중이면 화면이 조금 다르게 보일 것입니다.  계속하려면 "create instance"를 클릭하십시오. 기본적으로 Debian Linux가 기본적으로 선택됩니다.  우리는이 안내서에서 CentOS 6.X를 사용하기 때문에 * 이것을 원하지 않습니다. 인스턴스에 이름 ( "node1")을 지정하고 지역 (us-central1) 내의 첫 번째 영역 (a)을 선택하고 "변경"을 클릭하여 적절한 부팅 이미지를 선택하십시오.  워크로드 요구 사항에 따라 인스턴스의 크기를 조정할 수 있지만이 가이드에서는 기본 크기를 사용하여 비용을 최소화합니다. VM은 매우 적습니다 (1 vCPU 및 3.75GB RAM 만 해당). 부팅 디스크 팝업 CentOS 6을 선택하면 하단에 SSD 부팅 디스크가 표시됩니다.  이 가이드의 목적에는 10GB가 충분합니다.  그에 따라 시스템의 크기를 정할 수 있습니다. "선택"을 클릭하면 인스턴스 작성 화면으로 돌아갑니다.  하단에 "관리, 디스크, 네트워킹, SSH 키"를 클릭하십시오. VM에 두 번째 디스크를 추가하기 때문입니다.  이 두 번째 디스크는 데이터베이스를 저장하는 데 사용되며 나중에 클러스터링 소프트웨어에 의해 복제 / 동기화됩니다.   "디스크"탭을 선택하고 "항목 추가"를 클릭하여이 인스턴스에 두 번째 디스크를 추가하십시오 : "디스크 생성"을 클릭하십시오 : 새 디스크의 이름을 지정하고 원하는 유형을 선택한 다음 빈 디스크로 시작하십시오.  이 예제 구성에서는 여기에 10GB가 충분해야합니다.  참고 : 여기서 설정 한 값을 기억하십시오.  두 클러스터 노드 (node1과 node2)는 같은 크기 여야합니다. 마지막으로 "네트워킹"탭을 클릭하고 node1에게 고객 내부 IP를 제공하십시오. "Create"를 클릭하여 새 인스턴스를 시작하십시오 :

"노드 2"생성

위의 단계를 두 번 반복하여 두 번째 클러스터 노드 ( "node2")를 만듭니다.  두 번째 디스크 추가를 포함하여 node1처럼이 인스턴스를 만듭니다. 중요 : 다른 영역 (us-central1-b)에 있는지 확인하고 고유 한 IP (10.128.0.3)를 지정하십시오.

"감시 (witness)"VM 만들기

세 번째 VM ( "감시")을 만들고 처음 두 인스턴스와 다른 영역 (us-central1-c)에 있는지 확인하십시오. 참고 :이 인스턴스는 추가 된 디스크가 필요하지 않습니다. 3 개의 VM 인스턴스가 프로비저닝하는 데 약간의 시간이 걸릴 수 있습니다.  완료되면 Google Cloud Console의 VM 인스턴스 화면에 VM이 표시됩니다.  각 VM을 다른 영역에 제대로 시작했는지 확인하십시오.  

인스턴스 그룹 만들기

이 가이드의 뒷부분에서 트래픽을 활성 클러스터 노드로 라우팅하기 위해 내부로드 밸런서를 생성 할 것입니다.  Google Cloud Platform에서 사용 가능한 모든로드 밸런서 구성에는 인스턴스 그룹이로드 밸런서에서 전송 된 트래픽을 제공해야합니다. 두 개의 인스턴스 그룹이 생성되고 각각 하나의 클러스터 노드가 포함됩니다.

인스턴스 그룹 1 생성

첫 번째 인스턴스 그룹에 이름 ( "instance-group-1a")을 지정하고 "단일 영역"을 선택한 다음 첫 번째 VM 인스턴스가있는 영역을 올바르게 선택하십시오.  여기서는 us-central-1a를 선택합니다. 왜냐하면 그것이 "node1"이 배포 된 곳이기 때문입니다.  아래에서 "기존 인스턴스 선택"을 선택하고 VM 인스턴스 드롭 다운에서 "node1"을 선택하십시오.

인스턴스 그룹 2 생성

이전 단계를 한 번 더 반복하십시오. 이번에는 두 번째 노드가 상주하는 영역을 선택하십시오.  us-central-1b 및 node2 :

VNC 액세스를 허용하는 방화벽 규칙 만들기

네트워킹 -> 방화벽 규칙 기본적으로 바깥 세상에서 VM으로 열리는 "Google 방화벽"의 포트는 ping, SSH (포트 22) 및 RDP (방화벽 만 해당)입니다. 포트 3389). 나중에이 가이드에서 VNC를 사용하여 "node1"의 데스크탑에 액세스하고 GUI를 사용하여 클러스터를 구성 할 것입니다.  VNC 액세스를 허용하는 방화벽 규칙을 만듭니다.  이 가이드에서는 포트 5902가 사용됩니다.  VNC 구성에 따라 조정하십시오.  

Linux OS 구성

다음으로 인스턴스의 Linux OS를 구성하고 명령 줄에서 손을 더럽힐 필요가 있습니다. Linux 관리자는 지금까지 익숙해 져야합니다. Linux VM의 콘솔에 연결하는 데는 여러 가지 방법이 있습니다.  GCE 웹 인터페이스에서 직접 SSH 연결을 시작하거나 랩톱 / 워크 스테이션에 Google Cloud SDK를 로컬로 설치할 수 있습니다. 브라우저를 사용하는 SSH를 사용하려면 Compute -> VM Instances로 이동하고 연결하려는 VM의 오른쪽에서 "Connect"아래의 "Open in browser window"를 선택하십시오. 노트북 / 워크 스테이션에 기본적으로 설치된 Google Cloud 명령 줄 도구를 사용하려면 https://cloud.google.com/sdk/docs/quickstarts 문서를 참조하십시오. 연결되면 "sudo"명령을 사용하여 루트 권한 얻기 :

$ sudo su -

/ etc / hosts 편집

DNS 서버를 이미 설치하지 않은 경우 세 서버 모두에서 호스트 파일 항목을 만들어 이름별로 서로 올바르게 해결할 수 있습니다. / etc / hosts 파일의 끝에 다음 행을 추가하십시오.

10.128.0.2 node1
10.128.0.3 node2
증인 10.128.0.4
10.128.0.99 mysql-vip

SELinux 사용 안 함

/ etc / sysconfig / linux를 편집하고 "SELINUX = disabled"로 설정하십시오.

# vi / etc / sysconfig / selinux

#이 파일은 시스템상의 SELinux 상태를 제어합니다.
# SELINUX =은 다음 세 가지 값 중 하나를 취할 수 있습니다.
# enforcing - SELinux 보안 정책이 시행됩니다.
# permissive - SELinux는 강제가 아닌 경고를 출력합니다.
# disabled - SELinux 정책이로드되지 않습니다.
SELINUX = 비활성화 됨
# SELINUXTYPE = 다음 두 값 중 하나를 취할 수 있습니다.
# targeted - 타겟 프로세스가 보호되고,
# mls - 다단계 보안 보호.
SELINUXTYPE = 타겟팅 됨

다양한 RPM 패키지 설치

다음으로 클러스터링 소프트웨어의 필수 조건으로 나중에 필요할 rpm 패키지를 몇 개 설치하십시오.

# yum install redhat-lsb patch

VNC (및 관련 패키지) 설치 및 구성

Linux 서버의 GUI에 액세스하려면 클러스터를 나중에 구성하려면 클러스터 노드에 VNC 서버를 설치하십시오.  내 설치에서는 "node1"에서만이 작업을 수행했습니다.

# yum은 tigervnc-server xterm을 설치합니다.
# vncpasswd
# vi / etc / sysconfig / vncservers

      VNCSERVERS = "2 : root"
      VNCSERVERARGS [2] = "- 형상 1024x768"

# service vncserver start
# chkconfig vncserver on

랩톱 / 데스크톱에서 VNC 클라이언트를 열고 클러스터 노드의 공용 IP에 연결하여 연결을 테스트하십시오.

클러스터 노드 재부트

SELinux가 비활성화되도록 재부팅하십시오. 3 개의 시스템 (node1, node2, witness) 모두를 재부팅해야합니다.

"데이터"디스크 파티션 및 포맷

VM 인스턴스를 생성하는 동안 보호 할 응용 프로그램 데이터를 저장하기 위해 각 클러스터 노드에 추가 디스크가 추가되었습니다.  이 경우 MySQL 데이터베이스가됩니다. VM의 디스크 구성은 다음과 같습니다.

• / dev / sda – OS 디스크
• / dev / sdb – 데이터 디스크

인스턴스 생성 중 추가 된 두 번째 디스크 / dev / sdb.  "fdisk -l"명령을 실행하여 확인할 수 있습니다.  / dev / sda (OS)가 이미 디스크 파티션을 가지고 있고 사용 중임을 알 수 있습니다.

# fdisk -l

디스크 / dev / sda : 10.7GB, 10737418240 바이트
255 헤드, 63 섹터 / 트랙, 1305 실린더
단위 = 16065 * 512 = 8225280 바이트의 실린더
섹터 크기 (논리 / 실제) : 512 바이트 / 4096 바이트
I / O 크기 (최소 / 최적) : 4096 바이트 / 4096 바이트
디스크 식별자 : 0x00035e98

 장치 부팅 시작 끝 블록 ID 시스템
/ dev / sda1 * 1 1306 10484736 83 Linux

디스크 / dev / sdb : 10.7GB, 10737418240 바이트
64 헤드, 32 섹터 / 트랙, 10240 실린더
단위 = 2048 * 512 = 1048576 바이트의 실린더
섹터 크기 (논리 / 실제) : 512 바이트 / 4096 바이트
I / O 크기 (최소 / 최적) : 4096 바이트 / 4096 바이트
디스크 식별자 : 0x762b810b

여기서 파티션 (/ dev / sdb1)을 만들고, 포맷하고, MySQL의 기본 위치 인 / var / lib / mysql에 마운트합니다.  "node1"및 "node2"모두에서 다음 단계를 수행하십시오.

# fdisk / dev / sdb
명령 (m 도움말) : n
명령 동작
확장 된
p 주 파티션 (1-4)
피
파티션 번호 (1-4) : 1
첫 번째 실린더 (1-1305, 기본값 1) : <enter>
기본값 1 사용
마지막 실린더, 실린더 또는 크기 {K, M, G} (1-1305, 기본값 1305) : <Enter>
기본값 1305 사용
 
명령 (m 도움말) : w
파티션 테이블이 변경되었습니다!
파티션 테이블을 다시 읽으려면 ioctl ()을 호출하십시오.
디스크 동기화 중.
[root @ node1 ~] #

# mkfs.ext4 / dev / sdb1
# mkdir / var / lib / mysql

node1에서 파일 시스템을 마운트하십시오.

# mount / dev / sdb1 / var / lib / mysql

MySQL 설치 및 구성

다음으로, MySQL 패키지를 설치하고, 샘플 데이터베이스를 초기화하고, MySQL의 "root"비밀번호를 설정하십시오.

"node1"에서 :

# yum -y mysql mysql-server를 설치한다.
# / usr / bin / mysql_install_db --datadir = "/ var / lib / mysql /"--user = mysql
# mysqld_safe --user = root --socket = / var / lib / mysql / mysql.sock --port = 3306 --datadir = / var / lib / mysql --log &
#
# # 참고 :이 다음 명령은 모든 호스트의 원격 연결을 허용합니다.  생산을위한 좋은 생각이 아닙니다!
# echo "사용자 업데이트 설정 Host = '%'여기서 Host = 'node1'; flush privileges"| mysql mysql
#
# # MySQL의 루트 암호를 'SIOS'로 설정
# echo "update user set Password = PASSWORD ( 'SIOS') 여기서 User = 'root'; mysql mysql

MySQL 구성 파일을 만듭니다. 이를 데이터 디스크에 저장합니다 (나중에 /var/lib/mysql/my.cnf에 복제됩니다).  예:

# vi /var/lib/mysql/my.cnf

[mysqld]
datadir = / var / lib / mysql
소켓 = / var / lib / mysql / mysql.sock
pid-file = / var / lib / mysql / mysqld.pid
사용자 = 루트
포트 = 3306
# 보안 위험을 방지하려면 심볼릭 링크를 비활성화하는 것이 좋습니다.
기호 링크 = 0
 
[mysqld_safe]
log-error = / var / log / mysqld.log
pid-file = / var / run / mysqld / mysqld.pid
 
[고객]
사용자 = 루트
암호 = SIOS

/ etc에있는 원본 MySQL 구성 파일을 삭제합니다 (있는 경우).

# rm /etc/my.cnf

"노드 2"에서 :

"node2"에서는 MySQL 패키지 만 설치하면됩니다.  다른 단계는 필요하지 않습니다.

[root @ node2 ~] # yum -y mysql mysql-server를 설치합니다.

클러스터 설치 및 구성

이제 클러스터를 설치하고 구성 할 준비가되었습니다.  이 안내서에서는 Linux 용 SIOS Protection Suite (일명 SPS-Linux)가 클러스터링 기술로 사용됩니다.  고 가용성 페일 오버 클러스터링 기능 (LifeKeeper)과 블록 레벨 데이터 복제 (DataKeeper)를 단일 통합 솔루션으로 제공합니다.  SPS-Linux를 사용하면 Azure VM의 경우처럼 클러스터 노드에 공유 저장소가 없다는 의미의 "공유되지 않음"클러스터 인 "SANLess"클러스터를 배포 할 수 있습니다.

Linux 용 SIOS Protection Suite 설치

모든 3 개의 VM (node1, node2, witness)에서 다음 단계를 수행하십시오. SPS-Linux 설치 이미지 파일 (sps.img)을 다운로드하고 평가판 라이센스를 얻거나 영구 라이센스를 구입하십시오.  자세한 내용은 SIOS에 문의하십시오. 당신은 그것을 루프백 (loopback) 마운트 할 것이고 루트 ( "root su"를 얻기 위해 "sudo su -"라고 쓰는 것) 안에 "setup"스크립트를 실행시킬 것이다. 예를 들면 :

# mkdir / tmp / install
# mount -o loop sps.img / tmp / install
# cd / tmp / install
# ./설정

설치 스크립트 중에 여러 가지 질문에 대답하라는 메시지가 표시됩니다.  거의 모든 화면에서 Enter 키를 눌러 기본값을 적용합니다.  다음 예외에 유의하십시오.

• "High Availability NFS"라는 화면에서 고 가용성 NFS 서버를 만들지 않으므로 "n"을 선택할 수 있습니다
• 설치 스크립트가 끝날 때까지 평가판 라이센스 키를 지금 설치하거나 나중에 설치하도록 선택할 수 있습니다. 나중에 라이센스 키를 설치하므로이 시점에서 "n"을 안전하게 선택할 수 있습니다
• "설정"의 마지막 화면에서 화면에 표시된 목록에서 설치하려는 ARK (응용 프로그램 복구 키트, 즉 "클러스터 에이전트")를 선택하십시오.
  • ARK는 "node1"과 "node2"에서만 필요합니다.  "증인"에 설치할 필요가 없습니다.
  • 위쪽 / 아래쪽 화살표를 사용하여 목록을 탐색하고 스페이스 바를 눌러 다음을 선택하십시오.
    • lkDR – Linux 용 DataKeeper
    • lkSQL – LifeKeeper MySQL RDBMS 복구 키트
  • 그러면 "node1"및 "node2"에 다음과 같은 추가 RPM이 설치됩니다.
    • steeleye-lkDR-9.0.2-6513.noarch.rpm
    • steeleye-lkSQL-9.0.2-6513.noarch.rpm

Witness / Quorum 패키지 설치

LifeKeeper (steeleye-lkQWK)를위한 Quorum / Witness Server 지원 패키지는 LifeKeeper 코어의 기존 장애 조치 프로세스와 결합하여 전체 네트워크 장애가 공통적으로 발생할 수있는 상황에서보다 높은 수준의 신뢰성으로 시스템 장애 조치를 수행 할 수 있습니다. 이는 효과적으로 "스플릿 브레인"상황의 위험을 크게 줄이면서 장애 극복을 수행 할 수 있음을 의미합니다. 모든 3 개 노드 (node1, node2, witness)에 Witness / Quorum rpm을 설치합니다.

# cd / tmp / install / quorum
# rpm -Uvh steeleye-lkQWK-9.0.2-6513.noarch.rpm

모든 3 노드 (node1, node2, witness)에서 / etc / default / LifeKeeper를 편집하고 NOBCASTPING = 1로 설정합니다. Witness 서버 ( "witness")에서만 / etc / default / LifeKeeper를 편집하고 WITNESS_MODE = off / none

라이센스 키 설치

3 개 노드 모두에서 "lkkeyins"명령을 사용하여 SIOS에서 얻은 라이센스 파일을 설치하십시오.

# / opt / LifeKeeper / bin / lkkeyins <경로 _ 파일> / <파일 이름> .lic

LifeKeeper 시작

3 개 노드 모두에서 "lkstart"명령을 사용하여 클러스터 소프트웨어를 시작하십시오.

# / opt / LifeKeeper / bin / lkstart

LifeKeeper GUI에 대한 사용자 권한 설정

3 개 노드 모두에서 / etc / group을 편집하고 "tony"사용자 (또는 로그인 한 사용자 이름)를 "lkadmin"그룹에 추가하여 LifeKeeper GUI에 대한 액세스 권한을 부여하십시오.  기본적으로 "root"만이 그룹의 구성원이며 root 암호가 없습니다 :

# vi / etc / group

lkadmin : x : 502 : 루트, 토니

LifeKeeper GUI 열기

node1의 공용 IP 주소에 VNC 연결을 설정하십시오.  위에서 설명한 VNC 및 방화벽 규칙 구성에 따라 앞에서 지정한 VNC 암호를 사용하여 <Public_IP> : 2에 연결합니다.  로그인 한 후 터미널 창을 열고 다음 명령을 사용하여 LifeKeeper GUI를 실행하십시오.

# / opt / LifeKeeper / bin / lkGUIapp &

첫 번째 클러스터 노드 ( "node1")에 연결하라는 메시지가 나타납니다.  VM 생성 중에 지정된 Linux 사용자 ID와 암호를 입력하십시오 : 다음, 다음 스크린 샷에서 강조 표시된 "서버에 연결"단추를 클릭하여 "node2"와 "witness"모두에 연결하십시오. 이제 GUI에서 3 개의 모든 서버를 볼 수 있습니다. 온라인 상태이고 건강하다는 것을 나타내는 녹색 체크 표시 아이콘 :

통신 경로 생성

"node1"을 마우스 오른쪽 버튼으로 클릭하고 Comm Path 생성을 선택하십시오. "node2"와 "witness"를 선택하고 마법사를 따르십시오.  그러면 다음 사이에 통신 경로가 만들어집니다.

• 노드 1 및 노드 2
• 노드 1 및 증인

노드 2와 감시 사이에 통신 경로를 생성해야합니다.   "node2"를 마우스 오른쪽 단추로 클릭하고 통신 경로 작성을 선택하십시오.  마법사를 따라 원격 서버로 "witness"를 선택하십시오. 다음과 같은 통신 경로가 생성되었습니다 :

• node1 <-> node2
• 노드 1 <-> 목격자
• 노드 2 <-> 목격자

서버 앞의 아이콘이 녹색 "확인 표시"에서 노란색 "위험 신호"로 바뀌 었습니다.  이는 노드간에 단일 통신 경로 만 있기 때문입니다. VM에 여러 개의 NIC가있는 경우 (여러 NIC가있는 Azure VM을 만드는 방법에 대한 정보는 여기에서 찾을 수 있지만이 기사에서 다루지는 않음) 각 서버간에 중복 통신 경로를 만듭니다. 경고 아이콘을 제거하려면보기 메뉴로 이동하여 "Comm Path Redundancy Warning"을 선택 해제합니다. 결과 :

통신 경로 확인

"lcdstatus"명령을 사용하여 클러스터 자원의 상태를보십시오.  # / opt / LifeKeeper / bin / lcdstatus -q -d node1 MACHINE NETWORK ADDRESSES / DEVICE STATE PRIO node2 TCP 10.128.0.2/ 다음 명령을 실행하여 각 노드에서 다른 두 서버에 대한 통신 경로를 올바르게 작성했는지 확인하십시오. 10.128.0.3 ALIVE 1 증인 TCP 10.128.0.2/10.128.0.4 ALIVE 1 # / opt / LifeKeeper / bin / lcdstatus -q -d node2 MACHINE 네트워크 주소 / 장치 상태 프리 노드 1 TCP 10.128.0.3/10.128.0.2 ALIVE 1 증인 TCP 10.128.0.3 / 10.128.0.4 ALIVE 1 # / opt / LifeKeeper / bin / lcdstatus -q -d 감시 기계 네트워크 주소 / 장치 상태 프리 노드 1 TCP 10.128.0.4/10.128.0.2 ALIVE 1 node2 TCP 10.128.0.4/10.128.0.3 살아있는 1

데이터 복제 클러스터 리소스 (예 : 거울)

그런 다음 / var / lib / mysql 파티션을 node1 (원본)에서 node2 (대상)로 복제 할 데이터 복제 자원을 만듭니다.  "녹색 더하기"아이콘을 클릭하여 새 리소스를 만듭니다. 마법사의 지시에 따르십시오 :

복구 키트를 선택하십시오 : 데이터 복제
스위치 백 유형 : 지능형
서버 : node1
계층 구조 유형 : 기존 파일 시스템 복제
기존 마운트 지점 : / var / lib / mysql
데이터 복제 리소스 태그 : datarep-mysql
파일 시스템 리소스 탭 : / var / lib / mysql
비트 맵 파일 : (기본값)
비동기 복제 사용 : 아니요

리소스가 생성 된 후 "확장"(백업 서버 정의) 마법사가 나타납니다.  다음 선택 항목을 사용하십시오.

대상 서버 : node2
스위치 백 유형 : 지능형
템플릿 우선 순위 : 1
목표 우선 순위 : 10
대상 디스크 : / dev / sdb1
데이터 복제 리소스 태그 : datarep-mysql
비트 맵 파일 : (기본값)
복제 경로 : 10.128.0.2/10.128.0.3
마운트 포인트 : / var / lib / mysql
루트 태그 : / var / lib / mysql

클러스터는 다음과 같습니다.  

MySQL 자원 계층 만들기

그런 다음 MySQL 클러스터 리소스를 만듭니다.  MySQL 자원은 MySQL 데이터베이스의 중지 / 시작 / 모니터링을 담당합니다.  생성하려면 "녹색 더하기"아이콘을 클릭하여 새 리소스를 만듭니다. 마법사를 따라 다음을 선택하여 IP 리소스를 만듭니다.

복구 키트 선택 : MySQL 데이터베이스
스위치 백 유형 : 지능형
서버 : node1
my.cnf의 위치 : / var / lib / mysql
MySQL 실행 파일의 위치 : / usr / bin
데이터베이스 태그 : mysql

다음 선택 사항으로 IP 자원을 확장하십시오.

대상 서버 : node2
스위치 백 유형 : 지능형
템플릿 우선 순위 : 1
목표 우선 순위 : 10

결과적으로 클러스터는 다음과 같습니다.  데이터 복제 리소스가 자동으로 데이터베이스 아래로 이동 (종속성이 자동으로 생성 됨)되어 데이터베이스 전에 항상 온라인 상태로 유지되는지 확인합니다.  

내부로드 밸런서 만들기

이것이 실제 서버 또는 가상 서버를 사용하는 일반적인 온 – 프레미스 클러스터 인 경우이 시점에서 완료됩니다.  클라이언트와 응용 프로그램은 활성 노드에 도달하기 위해 클러스터의 가상 IP (10.128.0.99)에 연결합니다.  Google Cloud에서는 일부 추가 구성 없이는 작동하지 않습니다. 클러스터에 연결하기 위해 Google은 내부로드 밸런서 (ILB)를 설정할 수있는 기능을 제공합니다.  본질적으로 ILB의 IP 주소 (10.128.0.99로 설정)에 연결하면 현재 활성 클러스터 노드로 라우팅됩니다. TCP 부하 분산 장치 만들기 : 내부 부하 분산 장치이므로 "내 VM 간 전용"을 선택하십시오. 다음으로 부하 분산 장치의 이름 ( "internal-lb")을 지정한 다음 백 엔드 구성을 클릭하십시오. 지역 ( "us-central1")을 선택하고 백엔드를 구성하십시오.  "백엔드 추가"를 클릭하고 인스턴스 그룹 (instance-group-1a 및 instance-group-1b)을 모두 추가합니다.로드 밸런서는 상태 확인을 기반으로 트래픽을 라우팅 할 노드를 결정합니다.  이 예에서는 MySQL이 실행 중인지 (기본 포트 3306 확인) 상태 확인을 구성합니다.  "상태 확인 만들기"를 선택하십시오 : 새 상태 검사에 이름 ( "mysql-health-check")을 지정하고 TCP 포트 3306에 맞게 구성하십시오 : 다음으로로드 밸런서의 프론트 엔드를 구성하십시오.  "프론트 엔드 구성"을 선택하고 IP 주소 아래에 사용자 정의 정적 내부 IP를 10.128.0.99로 정의하십시오.  포트는 MySQL의 기본 포트 인 3306이어야합니다. 마지막으로로드 밸런서 생성을 검토하고 완료하십시오.  "만들기"를 클릭하십시오 : 결과.  로드 밸런서가 온라인 상태이지만 인스턴스 그룹이 정상적으로 표시되지 않습니다. (0/0으로 표시).  우리는 다음 절에서 그것을 고칠 것입니다 :

내부로드 밸런서에 대한 방화벽 규칙 만들기

Google 설명서 ( "내부로드 균형 조정을 허용하도록 방화벽 규칙 구성"섹션 참조)에서 두 가지 방화벽 규칙을 만들어야합니다.  첫 번째 매개 변수는로드 균형 조정기와로드 밸런서에서 인스턴스로의 트래픽을 허용합니다. 두 번째 방법은 상태 검사기에서 상태 검사 프로브를 허용합니다. 새 방화벽 규칙 만들기 : 새 규칙에 이름 (allow-internal-lb)을 지정하고 "10.128.0.0/20"을 원본 IP 범위로 지정하십시오.  허용 된 프로토콜과 포트는 "tcp : 3306"이어야합니다 : "만들기"를 클릭하면 방화벽 규칙 페이지로 돌아가고 목록에서 새로 생성 된 규칙을 볼 수 있습니다.  "방화벽 규칙 만들기"를 다시 클릭하여 두 번째 필수 규칙을 만들 수 있습니다. 두 번째 규칙에 이름을 지정하십시오 ( "허용 – 상태 – 검사").  두 가지 소스 IP 범위를 정의해야합니다.

• 130.211.0.0/22
• 35.191.0.0/16

참고 : Google 클라우드 문서를 다시 확인하여 이러한 IP 범위가 유효한지 항상 확인하는 것이 좋습니다. 새로 생성 된 방화벽 규칙이 모두 목록에 표시됩니다.

클러스터 연결 테스트

이제 모든 Google 클라우드 및 클러스터 구성이 완료되었습니다. 클러스터 리소스는 node1에서 현재 활성화되어 있습니다. 내부로드 밸런서가 instance-group-1a의 구성원 인 node1이 "정상"이며 따라서 가상 IP (10.128.0.99)로 들어오는 트래픽을 라우팅하는 것으로 나타납니다. )를 node1에 추가합니다. SSH를 미러링 모니터 서버에 연결하고 "sudo su -"를 사용하여 루트 액세스를 얻습니다.   필요한 경우 mysql 클라이언트를 설치하십시오.

[root @ witness ~] # yum -y mysql을 설치합니다.

클러스터에 MySQL 연결을 테스트하십시오.

[root @ witness ~] # mysql --host = 10.128.0.99 mysql -u root -p

다음 MySQL 쿼리를 실행하여 활성 클러스터 노드의 호스트 이름을 표시합니다.

mysql> select @@ hostname;
 ------------ 
| @@ 호스트 이름 |
 ------------ 
| node1 |
 ------------ 
1 행 세트 (0.00 초)
mysql>

LifeKeeper GUI 사용, 노드 1 -> 노드 2에서의 장애 복구 "를 참조하십시오.  노드 2 아래의 mysql 리소스를 마우스 오른쪽 단추로 클릭하고 "서비스 중 ..."을 선택합니다. 장애 조치 후 노드 2에서 리소스가 온라인 상태가됩니다 : 내부로드 밸런서가 node2가 포함 된 인스턴스 그룹 -b1이 정상적으로 표시됨을 확인할 수 있습니다 .  이제 트래픽이 node2로 라우팅됩니다. 장애 조치가 완료된 후 MySQL 쿼리를 다시 실행하십시오.  다음과 같은 MySQL 쿼리를 실행하여 활성 클러스터 노드의 호스트 이름을 표시하고 "node2"가 활성 상태인지 확인합니다.

mysql> select @@ hostname;
오류 2006 (HY000) : MySQL 서버가 사라졌습니다.
연결되지 않았습니다. 다시 연결하려고합니다 ...
연결 ID : 48
현재 데이터베이스 : mysql
 ------------ 
| @@ 호스트 이름 |
 ------------ 
| 노드 2 |
 ------------ 
1 행 세트 (0.56 초)
mysql>