SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

DataKeeper를 사용하여 SQL Server 고 가용성 재해 복구 달성

3월 26, 2019 by Jason Aw Leave a Comment

항상 가용성 그룹 및 SANless SQL Server 장애 조치 (Failover) 클러스터 인스턴스가 혼합 된 SQL Server 고 가용성, 재해 복구 구현

소개

FCI (Always On Availability Groups)와 SQL Server 장애 조치 (FCI) 인스턴스를 함께 사용하는 것에 대한 내용은 잘 설명되어 있습니다. 그러나 솔루션의 SQL Server FCI 부분이 공유 저장소를 사용한다고 가정하는 사용 가능한 대부분의 설명서 문서 구성. Storage Spaces Direct (S2D)를 사용하여 SANless SQL Server FCI를 구축하려는 경우에도 SQL Server AG를 추가 할 수 있습니까? 불행히도이 질문에 대한 대답은 '아니오'입니다. 현재까지 S2D 기반 SQL Server FCI와 Always On AG의 조합은 지원되지 않습니다. 이전에이 S2D 제한 사항에 대해 이전에 블로그에 올렸습니다. 그러나 좋은 소식은 SIOS DataKeeper를 사용하여 SANless SQL Server FCI를 구축 할 수 있으며 읽을 수있는 보조 도메인과 같은 것들에 대해 Always On AG를 활용할 수 있다는 것입니다. 기존의 SAN 기반 SQL Server FCI와 Always On AG를 혼합 할 때 적용되는 것과 동일한 규칙을 준수해야하지만 SQL Server 고 가용성을 달성하기위한 대부분의 부분은 거의 같습니다. DataKeeper 동기식 복제는 일반적으로 동일한 데이터 센터 또는 클라우드 지역의 노드간에 사용되지만 재해 복구를 위해 다른 지역의 추가 노드에 비동기 적으로 복제하고자 할 수 있습니다. 이 경우 예기치 않은 오류가 발생한 후에 DR 노드를 온라인 상태로 전환해야하는 경우 Always On AG 구성을 폐기하고 재구성해야합니다. 이 요구 사항은 VM 내부에서 실행되는 SQL Server Always On AG의 비동기 스냅 샷 복원과 관련하여 Microsoft가 여기에서 발표 한 내용과 매우 유사합니다.

가용성 그룹

기본적으로 DataKeeper를 사용하는 SANLess SQL Server 장애 조치 (Failover) 클러스터 인스턴스는 Always Availability Group Wizard와 관련하여 SQL Server의 단일 인스턴스처럼 보입니다. Always On AG의 구성은 두 개의 독립 실행 형 (클러스터되지 않은) SQL Server 인스턴스간에 Always On AG 만 작성한 경우와 완전히 동일합니다. 이 구성에서 모든 서버가 동일한 장애 조치 (failover) 클러스터에 있다는 사실에 혼란이 생깁니다. 그러나 SQL Server FCI는 SQL Server가 클러스터 된 SQL Server 인스턴스로 설치된 클러스터 노드에서만 실행되도록 구성됩니다. 다른 노드는 동일한 클러스터에 있습니다. 그러나 SQL은 이러한 노드에 클러스터 된 인스턴스가 아닌 독립 실행 형 SQL Server 인스턴스로 설치됩니다. 다소 혼란 스럽습니다. 근본적으로 일어나는 일은 Always On AG가 WSFC 쿼럼 모델과 청취자를 활용한다는 것입니다. 이와 같이 모든 AG Replicas는 일반적으로 SQL Server의 클러스터 된 인스턴스를 실행하지 않더라도 동일한 WSFC에 있어야합니다. 당신이 완전히 혼란스러워해도 괜찮다면, 대부분의 사람들은 처음에이 하이브리드 구성 주위에서 머리를 감싸려고 할 때 혼란 스럽습니다. 이와 같은 구성의 실질적인 이점은 SQL Server 장애 조치 (Failover) 클러스터 인스턴스가 많은 환경에서 Always On AG보다 더 우수하고 비용 효율성이 높은 고 가용성 솔루션이 될 수 있지만 읽을 수있는 보조 복제본. 항상 읽기 가능한 보조 복제본을 추가하면이 필요성을 해결할 수있는 실행 가능한 옵션이됩니다. 또한 SIOS DataKeeper를 사용하면 SQL Server FCI 용 SAN이 필요하지 않으므로 노드가 다른 데이터 센터에있는 SQL Server FCI를 구성 할 수 있으며 Azure 및 SQL Server의 가용성 영역에 해당하는 SQL Server FCI도 지원됩니다. AWS. 아래 그림은 한 가지 가능한 구성 일뿐입니다. 다중 FCI 클러스터 노드, 다중 AG 및 다중 복제본이 모두 지원됩니다. SQL Server 버전에 따른 제한으로 인해 제한됩니다. 이 기사에서는 설치 단계를 문서화하는 것으로 보인다. 물론 여기서는 SQL FCI 용 공유 저장 장치 대신 SIOS DataKeeper를 사용하여 FCI를 작성합니다.

가용성 그룹이있는 SQL Server FCI의 이미지 결과

기본 가용성 그룹

SQL Server Standard Edition에서 "기본 가용성 그룹"을 축소하여 SQL Server Standard Edition에서도이 구성을 가능하게했습니다. 기본 AG는 가용성 그룹당 단일 데이터베이스, 단일 복제본 (2 노드)으로 제한됩니다. 그러나 읽기 가능한 보조 복제본을 지원하지 않으므로이 하이브리드 구성의 사용 사례가 매우 제한적입니다.

분산 가용성 그룹

SQL Server 2016에 도입 된 분산 형 AG는이 하이브리드 구성에서도 지원됩니다. 분산 AG는 일반 AG와 매우 유사하지만 복제본은 동일한 클러스터 또는 동일한 Windows 도메인에있을 필요가 없습니다. Microsoft는 다음과 같이 분산 가용성 그룹의 주요 사용 사례를 문서화합니다.

  • 재해 복구 및보다 쉬운 다중 사이트 구성
  • 새 하드웨어 또는 구성으로 마이그레이션 (새 하드웨어 사용 또는 기본 운영 체제 변경 포함)
  • 여러 가용성 그룹에 걸쳐 단일 가용성 그룹에서 판독 가능한 복제본 수를 8 개 이상으로 늘림
분산 가용성 그룹의 이미지 결과

개요

SQL Server 고 가용성을위한 SQL Server FCI에 대한 아이디어가 마음에 들면 읽기 전용 보조 복제본의 유연성을 원한다면이 하이브리드 솔루션이 당신이 찾고있는 것일 수도 있습니다. 전통적인 SAN 기반 SQL Server FCI 및 심지어 S2D (Storage Spaces Direct) 기반 FCI는 단일 데이터 센터로 제한됩니다. SIOS DataKeeper는 SAN 한계에서 벗어나 가용 영역 또는 클라우드 지역에 적용되는 SQL Server FCI와 같은 구성을 가능하게합니다. 또한 SAN에 의존하지 않으므로 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 포기하지 않고도 로컬로 연결된 고속 저장 장치를 활용할 수 있습니다.

* 돈을 저축하는 방법

앞서 SQL Server Standard Edition으로이 모든 작업을 수행하여 비용을 절감하는 방법을 알려 드리겠다고 약속했습니다. 특정 시점의 스냅 샷인 읽을 수있는 복제본으로 살아갈 수있는 경우 Always On AGs를 완전히 건너 뛸 수 있으며 SIOS DataKeeper 대상 측 스냅 샷 기능을 사용하여 진행중인 복제에 영향을주지 않으면 서 대상 서버의 볼륨 스냅 샷을 주기적으로 응용 프로그램에 적용 할 수 있습니다 또는 가용성. 방법은 다음과 같습니다.

http://cisco.com/

SQL Server Standard Edition으로 2 노드 SQL Server FCI를 만들고 SQL 라이센스에 많은 비용을 절약하십시오. 또한보고 또는 DR 목적으로 클러스터 외부의 세 번째 노드에 데이터를 복제합니다. 이 세 x 째 서 v에서 볼륨의 스 냄샷을 작성할 경우이 스 냄샷은 읽기 쉽게 액세스 할 수 있습니다. 이렇게하면 SQL Server의 독립 실행 형 인스턴스에서 해당 데이터베이스를 탑재하여 월말 보고서를 실행하거나 아카이브로 복사하거나 해당 스냅 샷을 사용하여 QA 및 Test / Dev 환경을 최신 SQL로 쉽고 빠르게 업데이트 할 수 있습니다 데이터. 항상 가용성 그룹과 SANless SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 함께 사용하여 SQL Server 고 가용성, 재해 복구를 달성하기위한 가이드를 찾았다면 좋겠습니다.

Clusteringformeremortals.com의 허락을 받아 재현

Filed Under: 서버 클러스터 단순화 Tagged With: SQL Server 장애 조치 (Failover) 클러스터 인스턴스

SQL Server 2008/2008 R2 지원 만료 전에 조치 취하기

1월 13, 2019 by Jason Aw Leave a Comment

SQL Server 2008/2008 R2 지원 만료 전에 조치 취하기

Tick Tock … SQL Server 2008/2008 R2 지원이 만료 될 때까지 6 개월 동안 조치 취하지 않으면

SQL Server 2008/2008 R2를 계속 실행하고 있습니까? 아마도 2019 년 7 월 9 일부터 더 이상 지원을받지 못할 것입니다. Microsoft는이 플랫폼에서 아직 실행 중이며 마감일 전에 새로운 버전의 SQL로 업그레이드 할 수없는 고객을 위해 추가 보안 업데이트를 3 년 동안 제공 할 수있는 두 가지 옵션을 제공합니다.

첫 번째 옵션

준비하기 전에 SQL Server 2008/2008 R2 지원 만료를 방지하려면 먼저 "확장 보안 업데이트"를 구입해야합니다. 확장 보안 업데이트는 전체 라이센스 비용의 75 %를 매년 부담하게됩니다. 또한 고객은 일반적으로 연간 라이선스 비용의 25 % 인 활성 소프트웨어 보증을 받아야합니다. 따라서 확장 보안 업데이트를 받으려면 매년 3 년 동안 또는 SQL Server 2008/2008 R2에서 마이그레이션 할 때까지 새 SQL Server 라이선스를 지불해야합니다.

두 번째 옵션

그러나 SQL Server 2008/2008 R2 지원 만료 전에 또 다른 옵션이 있습니다. Microsoft는 SQL Server 2008 R2 인스턴스를 Azure로 이동하면 추가 비용없이 확장 보안 업데이트를 받게 될 것이라고 발표했습니다. Azure에서 발생하는 시간당 인프라 비용은 물론 있습니다. 또한 기존 SQL 라이센스를 Azure로 가져 오려는 경우 SQL Server 인스턴스로 갈 때의 지불 비용 또는 Software Assurance 비용이 추가로 필요합니다. 그러나이 비용에는 최첨단의 클라우드 환경에서 운영 할 때의 추가 이점이 포함됩니다. 이로 인해 향상된 성능과 HA / DR 시나리오가 가능해질 수 있습니다.

옵션 배열

Azure는 CPU, 메모리 및 스토리지 구성 측면에서 다양한 옵션을 제공합니다. 서버 또는 스토리지 업그레이드를 찾고 있거나 기존의 사내 구축 형 인프라가 새로 고침주기에 도달했다면 지금 Azure 클라우드에 발을 들여 놓고 성능 및 가용성을 업그레이드하는 완벽한 시간입니다. SQL Server 2008/2008 R2 배포의 수명.

99.99 % SLA

고 가용성 및 재해 복구 구성 측면에서 Azure는 최대 99.99 % SLA를 제공합니다.  SLA 자격을 얻으려면 인프라를 적절히 활용해야합니다. 그렇더라도 SLA는 인스턴스에 대한 "발신음"만을 처리합니다. 일반적으로 SQL Server 장애 조치 (Failover) 클러스터 인스턴스 (FCI)를 구축하여 SQL Server의 가용성을 높이는 것은 사용자의 몫입니다. Azure는 SQL Server FCI를 구성 할 수있는 인프라를 갖추고 있습니다. 그러나 클라우드에서 클러스터 인식 공유 저장소가 없기 때문에 SIOS DataKeeper를 사용하여 FCI를 구축해야합니다.

SIOS DataKeeper의 이점

SIOS DataKeeper는 일반적으로 SQL Server FCI에 필요한 공유 저장소 대신 사용됩니다. 대신 각 인스턴스에 첨부 된 NTFS 형식의 볼륨을 활용할 수 있습니다. SIOS는 인스턴스간에 복제 된 볼륨을 유지하고 DataKeeper 볼륨이라는 리소스로 클러스터에 스토리지를 제공합니다. 클러스터에 관한 한 DataKeeper 볼륨은 공유 디스크처럼 보이지만 SCSI 예약 (디스크 잠금)을 제어하는 대신 활성 서버에서 쓰기가 수행되도록 미러 방향을 제어하고 다른 클러스터 노드에 동 기적 또는 비동기 적으로 복제합니다 . 최종 사용자 경험은 기존의 공유 스토리지 클러스터와 완전히 동일합니다. 다루지는 않지만 클러스터는 공유 스토리지 대신 로컬로 연결된 스토리지를 활용합니다.

다른 랙

Azure에서는 클러스터 노드가 서로 다른 랙 (오류 도메인), 데이터 센터 (가용 영역) 또는 다른 지리적 영역에서 실행될 수 있습니다. SIOS DataKeeper는 오류 도메인, 가용성 영역 또는 HA 및 DR 요구 사항을 모두 포괄하는 교차 영역 복제의 세 가지 옵션을 모두 지원합니다. AWS 및 Google Cloud에서도 비슷한 구성이 가능합니다.

[SIZE DataKeeper를 사용하여 Azure의 일반적인 2- 노드 SQL Server FCI 푸른 하늘구성 [/ caption]

ASR (Azure Site Recovery)을 사용하면 자체 재해 복구 사이트를 관리해야하는 번거 로움과 비용을 들이지 않고도 지역 쌍간에 SQL Server의 독립 실행 형 인스턴스 또는 클러스터 된 인스턴스를 복제 할 수 있습니다. 물론 SQL Server는 거의 혼자 살지 않습니다. 따라서 SQL Server 인스턴스를 Azure로 이동하는 동시에 Azure에서 사용할 수있는 성능 및 가용성 업그레이드를 활용하기 위해 응용 프로그램 서버를 옮길 수도 있습니다. DR을위한 HA 및 ASR 용 SIOS DataKeeper를 결합하면 SAN 복제 및 자체 DR 사이트를 사용하여 구현하는 것이 불가능하거나 비용이 많이 드는 비용 효과적인 HA 및 DR 전략을 제공합니다.

[캡션 ID = "attachment_2384"align = "alignnone"widasr - 2th = "660"] HA 용 SIOS DataKeeper 및 DR 용 Azure 사이트 복구를 활용하는 일반적인 구성 [/ caption]

시작하다

Azure에서 SQL Server 인스턴스를 시작하는 데 몇 분 밖에 걸리지 않지만 마이그레이션을 마칠 때까지 기다릴 필요가 없습니다. 앞으로 몇 달 동안 Azure에 익숙해지기 전에 몇 가지 테스트를 시작한 다음 2019 년 7 월 9 일의 만료 날짜 이전에 작업 부하를 마이그레이션 할 계획을 세우십시오. 이 날짜 이후에 SQL Server를 실행하면 새로운 보안 위협에 취약해질뿐만 아니라 규정을 준수하지 못할 수도 있습니다. 직장 상사를 Azure로 마이그레이션 한 후에는 상사, 그리고 더 중요한 것은 고객이 자신의 데이터가 안전하고 사용 가능하며 규정을 준수하고 있음을 알게되어 기쁩니다.

SQL Server 2008/2008 R2 이후에 할 일을 알아내는 것과 같은 팁 즐기기 지원 만료, 더 읽을만한 훌륭한 게시물 Clusteringformeremortals.com의 허가로 복제

Filed Under: 서버 클러스터 단순화 Tagged With: sql server 2008 2008 r2 지원 만료

클라우드에서 Windows에서 MaxDB를 클러스터링하는 방법

1월 12, 2019 by Jason Aw Leave a Comment

클라우드에서 Windows에서 MaxDB를 클러스터링하는 방법

클라우드에서 Windows에서 MaxDB를 클러스터링하는 방법

Windows에서 클라우드에서 MaxDB를 클러스터링하는 방법 #AZURE #AWS #GCP #SAP

최근 클라우드의 Windows에서 MaxDB를 클러스터링하는 고 가용성 솔루션을 원하는 많은 고객이있었습니다. 일부 고객은 Azure에 있었고 일부는 AWS에있었습니다. 그러나 클라우드 플랫폼에 상관없이 결국 이들은 모두 SAP 커뮤니티 WIKI에서 프로세스를 설명하는 게시물을 찾습니다. https://wiki.scn.sap.com/wiki/display/MaxDB/HowTo+-+Embed+SAP+MaxDB+in+MSCS

도전 과제

클라우드 환경에서이 게시물의 문제점은 전통적인 공유 스토리지 클러스터를 구축 할 수있는 Azure, AWS 또는 GCP에서 사용할 수있는 공유 스토리지 (SAN)가 없다는 것입니다. 클라우드에서 HA의 장점은 일반적으로 클러스터 노드가 다른 데이터 센터, 즉 가용성 영역 (AZ)에서 서로 멀리 떨어진 곳에 있다는 것입니다. 따라서 공유 저장 장치를 사용할 수있는 경우에도 단일 AZ에 있어야하므로 많은 의미가 없습니다. 그것은 모두 함께 하의 목적을 이깁니다.

해결책

그러나 클라우드의 Windows MaxDB 클러스터에 대한 대답이 있습니다. SIOS DataKeeper는 SIOS 기술의 SANless 클러스터링 솔루션입니다. 로컬로 연결된 저장소를 Windows Server 장애 조치 (failover) 클러스터에서 사용할 수 있습니다. 이렇게하면 SAN이 필요하지 않습니다. 대신 SIOS는 동기 블록 레벨 복제 기술을 사용하여 로컬로 연결된 디스크를 동기화 상태로 유지하고 WSFC에이 저장 장치를 DataKeeper 볼륨이라는 클러스터 된 디스크 리소스로 제공합니다.

다른 지역에 세 번째 노드가있는 가용 영역의 일반적인 2 노드 WSFC [/ caption]

클러스터에 관한 한, DataKeeper 볼륨 클러스터 리소스는 공유 디스크처럼 보입니다. 그러나 디스크 잠금 (SCSI 예약)을 제어하는 대신 미러 방향을 제어합니다. 따라서 모든 점에서 공유 저장소 대신 로컬로 연결된 저장소를 사용한다는 점을 제외하면 여전히 진정한 WSFC입니다. 로컬로 연결된 저장소는 EBS 블록 장치에서 Azure 프리미엄 디스크까지 또는 여러 디스크가 함께 제거 된 로컬 저장소 공간까지 사용할 수 있습니다. Windows에서 NTFS로 포맷 된 볼륨이 드라이브 문자로 표시되고 볼륨 크기가 각 인스턴스에서 동일하면 클러스터에서 사용할 수 있습니다.

DataKeeper 볼륨 클러스터 리소스

이 유형의 클러스터는 일반적으로 SANless 클러스터로 알려져 있습니다. 공유 스토리지를 사용할 수없는 지리적 클러스터 및 클러스터를 수년 동안 사용해 왔습니다. 데이터베이스 관리자는 또한 PCIe 플래시 또는 SSD 드라이브와 같은 로컬 고속 저장 장치를 사용할 수 있으므로이를 좋아합니다. 동시에 높은 가용성을 위해 WSFC를 계속 사용하십시오. SIOS는 또한 비동기식 복제를 지원합니다. 따라서 재해 복구를 위해 다른 지리적 위치에 노드를 추가하려는 경우 같은 영역에는 있지만 다른 결함 도메인과 3 개의 노드가 완전히 다른 지역에 있거나 2 개의 노드가있는 3 노드 클러스터를 구축 할 수 있습니다 재해 복구 옵션을위한 온 – 프레미엄 Azure에 있다면 SIOS DataKeeper가 ASR과 호환되므로 재해 복구를 위해 ASR (Azure Site Recovery)을 활용할 수 있습니다. WSFC와 SIOS DataKeeper는 동일한 IP 주소를 유지해야합니다. 따라서 ASR 구성의 경우 여기서 설명한대로 장애 조치시 IP 주소를 유지해야합니다. https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-retain-ip-azure-vm-failover

수액

SIOS는 SAP의 고 가용성 및 재해 복구를 낯선 사람이 아닙니다. Linux 용 SIOS Protection Suite는 SAP 및 SAP HANA 용 SAP 인증 HA 솔루션입니다. SIOS DataKeeper는 클라우드 환경에서 Windows 용 SAP ASCS에 대해 선호되는 HA / DR 솔루션입니다. Azure에서 MaxDB를위한 HA / DR 솔루션을 제공하면 SIOS를 SAP 고 가용성 전문가로 더욱 강화할 수 있습니다. SAP의 고 가용성에 대해 궁금한 점이 있거나 MaxDB를 클러스터하는 방법에 대한 자세한 내용은 Windows In The Cloud에서 다른 게시물을 참조하십시오.

Clusteringformeremortals.com의 허락을 받아 재현

Filed Under: 서버 클러스터 단순화 Tagged With: 클라우드 윈도우의 클러스터 maxdb

Linux 용 SQL Server에 대한 단계별 지침

1월 9, 2019 by Jason Aw Leave a Comment

Linux 용 SQL Server - 공용 미리보기 사용 가능

단계별 : SQL Server v.Next Linux 고 가용성 – 공용 미리보기 # azure #sql #sanless

올해 초 Microsoft는 Linux 용 SQL Server 버전을 발표 할 것이라고 발표했습니다.  오늘 저는 Microsoft가 SQL Server v.Next를 현재 호출하고있는 내용을 공개적으로 미리 알리고 Linux 및 Windows 운영 체제에서 사용할 수 있다는 사실을 알게되어 매우 기쁩니다.  자세한 정보와 함께 다운로드 링크 및 설명서는 다음에서 찾을 수 있습니다.

https://www.microsoft.com/en-us/sql-server/sql-server-vnext-including-Linux

Linux 용 SQL Server

이 기사에서는 SQL Server를 실행하는 Azure에 Linux VM을 배포하는 방법을 보여줄뿐만 아니라 2 노드 장애 조치 (failover) 클러스터를 구성하여 가용성을 높입니다. 공유 스토리지 (일명 "사네 (sanless)"또는 "공유되지 않은 (shared nothing)"클러스터)를 사용하지 않아도됩니다. 최종 결과는 Microsoft Azure IaaS (서비스로서의 인프라)에서 2 노드 SQL Server for Linux 클러스터 (미러링 모니터 서버)가됩니다.  가이드에는 적절한 스크린 샷, 셸 명령 및 코드 스 니펫이 모두 포함되어 있습니다.  필자는 귀하가 Microsoft Azure에 익숙하며 Azure 계정이 이미 가입되어 있다고 가정합니다.  그렇지 않은 경우 오늘 무료 계정에 가입 할 수 있습니다.  기본적인 리눅스 시스템 관리 기술은 물론 가상 IP와 같은 기본적인 장애 조치 클러스터링 개념을 이해하고 있다고 가정합니다. 면책 조항 : 하늘빛은 빠르게 움직이는 표적입니다.  그리고 여기서는 Linux 용 SQL Server의 공개 미리보기 버전을 사용하고 있습니다.  따라서 SQL v.Next가 공식적으로 발표되기 전에 기능 / 화면 / 단추가 바뀌어 사용자 경험이 아래와 같이 약간 다를 수 있습니다.  이 가이드에서는 Linux 용 SQL Server 데이터베이스의 가용성을 높일 수있는 방법을 보여 주지만 여기에서 앞서 설명한 것처럼 (MySQL 예제)이 정보와 프로세스를 적용하여 다른 응용 프로그램이나 데이터베이스를 보호 할 수 있습니다. 다음은 Microsoft Azure IaaS에서 고 가용성 MySQL 데이터베이스를 만드는 고급 단계입니다.

  1. 자원 그룹 작성
  2. 가상 네트워크 만들기
  3. 저장소 계정 만들기
  4. 가용성 집합에 가상 컴퓨터 만들기
  5. VM 고정 IP 주소 설정
  6. 클러스터 노드에 데이터 디스크 추가
  7. VNC 액세스를 허용하는 인바운드 보안 규칙 만들기
  8. Linux OS 구성
  9. SQL Server 설치 및 구성
  10. 클러스터 설치 및 구성
  11. 내부로드 밸런서 만들기
  12. 클러스터 연결 테스트

개요

이 기사에서는 단일 Azure 영역 내에 클러스터를 만드는 방법을 설명합니다.  새 Azure Resource Manager (ARM) 덕분에 클러스터 노드 (sql-linux1, sql-linux2 및 미러링 모니터 서버)는 가용성 세트 (3 개의 다른 오류 도메인 및 업데이트 도메인)에 상주합니다. 우리는 새로운 Azure Resource Manager를 사용하여 모든 리소스를 생성 할 것입니다. 구성은 다음과 같습니다. 하늘빛 - 리눅스 - sqlserver다음 IP 주소가 사용됩니다.

  • sql-linux1 : 10.0.0.7
  • sql-linux2 : 10.0.0.8
  • sql-witness : 10.0.0.9
  • 가상 / "유동"IP : 10.0.0.199
  • SQL Server 포트 : 1433

자원 그룹 작성

먼저, 자원 그룹을 작성하십시오.  리소스 그룹에는 클러스터 배포와 관련된 다양한 개체 (가상 컴퓨터, 저장소 계정 등)가 모두 포함됩니다.  여기 새로 생성 된 리소스 그룹 "sql-cluster"를 호출합니다. sql-resource-group1 지역 선택시주의하십시오.  모든 리소스는 동일한 지역 내에 있어야합니다.  여기서는 모든 것을 "미국 서부"지역에 배치 할 것입니다. sql-resource-group2

가상 네트워크 생성 (VNet)

그런 다음 아직 가상 네트워크를 만들지 않은 경우 가상 네트워크를 만듭니다.  가상 네트워크는 Azure 클라우드 내의 고립 된 네트워크로, 사용자 전용입니다.  IP 주소 블록 및 서브넷, 라우팅, 보안 정책 (방화벽), DNS 설정 등을 완벽하게 제어 할 수 있습니다.  Azure Iaas 가상 머신 (VM)을 가상 네트워크로 시작합니다. 내 Azure 계정에는 이미이 가이드에서 사용할 "클러스터 네트워크"라는 기존 VNet (10.0.0.0/16)이 있습니다.  VNet을 생성하는 것은 매우 간단하며, 새로 고침이 필요하면 여기에서 작성하는 방법을 다뤘습니다.

저장소 계정 만들기

가상 머신을 프로비저닝하기 전에 가상 머신을 저장하기 위해 스토리지 계정이 필요합니다. sql-storage-account1 그런 다음 새 저장소 계정에 이름을 지정하십시오.  스토리지 계정 이름은 Azure의 * ALL *에서 고유해야합니다.  Azure Storage에 저장하는 모든 객체에는 고유 한 URL 주소가 있습니다. 저장소 계정 이름은 해당 주소의 하위 도메인을 구성합니다.)이 예에서는 저장소 계정 "sqllinuxcluster"를 호출하지만 사용자가 직접 설정 한 것과 다른 것을 선택해야합니다. 요구 사항 및 예산에 따라 스토리지 유형을 선택하십시오.  이 안내서의 목적 상, "표준 -RSRS"(즉, 표준 LRS)를 선택했습니다. 로컬 이중화)을 사용하여 비용을 최소화하십시오. 새 저장소 계정이 동일한 위치 (이 예에서 "West US")의 1 단계 ( "sql-cluster")에서 만든 리소스 그룹에 추가되었는지 확인하십시오. sql-storage-account2

가용성 집합에 가상 컴퓨터 만들기

이 가이드에서는 3 개의 가상 시스템을 프로비저닝 할 것입니다.  처음 두 VM ( "sql-linux1"및 "sql-linux2"라고 부름)은 SQL Server 데이터베이스와 관련 리소스를 온라인 상태로 가져 오는 클러스터 노드로 작동합니다.  세 번째 VM은 스플릿 브레인에 대한 추가 보호를 위해 클러스터의 감시 서버 역할을합니다. 최대한의 가용성을 보장하기 위해 3 개의 VM이 모두 동일한 가용성 세트에 추가되어 서로 다른 오류 도메인 및 업데이트 도메인에있게됩니다. Azure Marketplace에는 "Red Hat Enterprise Linux 7.2에 SQL Server vNext"라는 VM 템플릿이 있습니다.이 템플릿에는 공용 미리보기 평가 버전 인 SQL Server v.Next for Linux가 사전 설치되어있어 몇 단계를 줄일 수 있습니다.  빈 VM로 시작하여 SQL을 직접 설치하려면 여기에서 설치 지시 사항을 찾으십시오.

"sql-linux1"VM 만들기

첫 번째 VM ( "sql-linux1")을 만들고 위에서 언급 한 마켓 플레이스 이미지를 선택하십시오. sql-create-vm1 VM에 나중에 SSH로 시스템에 사용되는 호스트 이름 ( "sql-linux1") 및 사용자 이름 / 암호를 지정하십시오.  이 VM을 리소스 그룹 ( "sql-cluster")에 추가하고 다른 모든 리소스와 동일한 영역에 상주하는지 확인하십시오. 그런 다sql-create-vm2음 인스턴스 크기를 선택하십시오.  사용 가능한 다양한 인스턴스 크기에 대한 자세한 내용을 보려면 여기를 클릭하십시오. 이 가이드의 목적에 따라 프로덕션 워크로드를 실행하지 않으므로 비용을 최소화하기 위해이 경우 "DS1_V2 Standard"에서 가능한 가장 작은 / 가장 저렴한 크기를 선택했습니다.  테스트 할 대상을 기준으로 가장 적합한 인스턴스 크기를 선택하십시오. sql-create-vm3중요 : 기본적으로 VM은 가용성 집합에 추가되지 않습니다.  새 가용성 세트를 만들 때 설정 화면에서 "sql-availability-set"을 호출합니다.  Azure Resource Manager (ARM)를 사용하면 3 개의 오류 도메인으로 가용성 세트를 생성 할 수 있습니다.  여기의 기본값은 문제가 없습니다sql-create-vm4. 다음 화면에서 VM 속성을 검토하고 확인을 클릭하여 첫 번째 VM을 만듭니다.

"sql-linux2"및 "sql-witness"VM 만들기

위의 두 단계를 반복하여 VM을 두 개 더 만듭니다. 유일한 차이점은 방금 만든 가용성 세트 ( "sql-availability-set")에이 VM을 추가한다는 것입니다. 3 대의 VM을 프로비저닝하는 데 약간의 시간이 걸릴 수 있습니다.  완료되면 Azure 포털의 가상 시스템 화면에 가상 머신 (sql-linux1, sql-linux2 및 sql-witness)이 나열됩니다.

VM 고정 IP 주소 설정

VM은 다음 IP 주소로 설정됩니다.

  • sql-linux1 : 10.0.0.7
  • sql-linux2 : 10.0.0.8
  • sql-witness : 10.0.0.9

각 VM에 대해이 단계를 반복하십시오.  VM을 선택하고 네트워크 인터페이스 편집sql-static-ip1 VM과 관련된 네트워크 인터페이스를 선택하고 IP 구성을 편집합니다.  "정적"을 선택하고 원하는 IP 주소를 지정하십시오 : sql-static-ip2

클러스터 노드에 데이터 디스크 추가

다음으로 클러스터 노드 ( "sql-linux1"및 "sql-linux2")에 디스크를 추가해야합니다.  이 디스크는 SQL 데이터베이스를 저장하고 나중에 노드간에 복제됩니다. 참고 : "sql-witness"노드에 추가 디스크를 추가 할 필요는 없습니다.  "sql-linux1"및 "sql-linux2". VM을 편집하고 디스크를 선택한 다음 새 디스크를 연결하십시오.  작업 유형에 따라 디스크 유형 (표준 또는 프리미엄 SSD)과 크기를 선택하십시오.  여기서는 두 클러스터 노드 모두에 10GB 표준 디스크를 만듭니다.  호스트 캐싱이 진행되는 한 "없음"또는 "읽기 전용"캐싱이 좋습니다.  데이터 유실 가능성이 있으므로 "읽기 / 쓰기"사용을 권장하지 않습니다. sql-add-disk1

VNC 액세스를 허용하는 인바운드 보안 규칙 만들기

VM이 NSG (Network Security Group)의 일부인 경우 VM을 생성하는 동안 VM을 비활성화하지 않으면 기본적으로 "Azure 방화벽"에서 열리는 유일한 포트는 SSH (포트 22)입니다.  나중에이 가이드에서 VNC를 사용하여 "sql-linux1"의 데스크탑에 액세스하고 GUI를 사용하여 클러스터를 구성 할 것입니다.  인바운드 보안 규칙을 만들어 VNC 액세스를 엽니 다.  이 가이드에서는 포트 5902가 사용됩니다.  VNC 구성에 따라 조정하십시오. 가상 시스템 -> (sql-linux1 선택) -> 네트워크 인터페이스 -> (NIC 선택) -> 네트워크 보안 그룹 -> (NSG 선택) -> 인바운드 보안 규칙 -> 추가 sql-security-group1

Linux OS 구성

여기 Azure 포털을 잠시 떠나서 커맨드 라인에서 손을 더럽힐 곳이 있습니다. 리눅스 관리자는 지금까지 익숙해 져야합니다.  Azure에서 Linux VM에 대한 루트 암호가 제공되지 않으므로 VM 생성 중에 지정된 사용자로 로그인하면 "sudo"명령을 사용하여 루트 권한을 얻습니다.

$ sudo su -

/ etc / hosts 편집

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

10.0.0.7 sql-linux1
10.0.0.8 sql-linux2
10.0.0.9 sql-witness
10.0.0.199 sql-vip

SELinux 사용 안 함

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

# vi / etc / sysconfig / selinux

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

클러스터 가상 IP가 작동하도록 iptables 구성

가상 IP가 작동하도록 클러스터에 연결하고 IP 자원을 모니터링하려면 몇 가지 iptables 규칙을 설정해야합니다.  참고 : 10.0.0.199는 클러스터에서 사용할 가상 IP이고 1433은 SQL Server에서 사용되는 기본 포트입니다. 참고 : RHEL7은 기본 방화벽을 iptables 대신 FirewallD로 변경했습니다.  아직 firewalld에 많은 시간을 할애하지 않았으므로,이 안내서는 firewalld를 비활성화하고 대신 iptables를 사용합니다. 아래의 "service"와 "chkconfig"명령이 작동하도록 "iptables-services"패키지를 설치해야합니다.

# systemctl stop firewalld
# systemctl disable firewalld

sql-linux1 (10.0.0.7)에서 다음 명령을 실행하십시오.

# yum은 iptables-services를 설치합니다.
# iptables --flush
# iptables -t nat -A PREROUTING -p tcp --dport 1433 -j DNAT - 목적지 10.0.0.199:1433
# iptables -t nat -A PREROUTING -p tcp --dport 1434 -j DNAT - 대상 10.0.0.199:1434
# iptables -t nat -A POSTROUTING -p icmp -s 10.0.0.199 -j SNAT --to-source 10.0.0.7 
# service iptables save 
# chkconfig iptables on 

sql-linux2 (10.0.0.8)에서 다음 명령을 실행하십시오.

# yum은 iptables-services를 설치합니다.
# iptables --flush 
# iptables -t nat -A PREROUTING -p tcp --dport 1433 -j DNAT - 목적지 10.0.0.199:1433
# iptables -t nat -A PREROUTING -p tcp --dport 1434 -j DNAT - 대상 10.0.0.199:1434
# iptables -t nat -A POSTROUTING -p icmp -s 10.0.0.199 -j SNAT --to-source 10.0.0.8 
# service iptables save 
# chkconfig iptables on

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

Linux 서버의 GUI에 액세스하고 나중에 클러스터를 설치 및 구성하려면 VNC 서버와 기타 필요한 패키지 (클러스터 소프트웨어에는 redhat-lsb 및 patch rpms가 필요함)를 설치하십시오.

# yum install tigervnc-server xterm wget unzip 패치 redhat-lsb
# vncpasswd

다음 URL은 RHEL 7 / CentOS 7에서 VNC 서버를 실행하는 데 유용한 지침입니다. https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-remote-access-for -gnome-desktop-on-centos-7 주 :이 예제 구성은 디스플레이 2 (: 2, 일명 포트 5902) 및 루트 (안전하지 않음)에서 VNC를 실행합니다.  적절하게 조정하십시오!

# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:2.service
# vi /etc/systemd/system/vncserver@:2.service


[서비스]
유형 = 분기
# /tmp/.X11-unix 환경의 기존 파일 정리
ExecStartPre = / bin / sh -c '/ usr / bin / vncserver -kill % i> / dev / null 2> & 1 || : '
ExecStart = / sbin / runuser -l root -c "/ usr / bin / vncserver % i -geometry 1024x768"
PIDFile = / root / .vnc / % H % i.pid
ExecStop = / bin / sh -c '/ usr / bin / vncserver -kill % i> / dev / null 2> & 1 || : '


# systemctl daemon-reload
# systemctl enable vncserver @ : 2.service
# vncserver : 2 기하학 1024x768

클러스터 노드 재부트

SELinux가 비활성화되고 이전에 추가 한 두 번째 디스크가 감지되도록 클러스터 노드를 재부트합니다.

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

이 안내서의 6 단계 ( "클러스터 노드에 데이터 디스크 추가")에서 우리는 다음과 같이 수행했습니다. 보호 할 응용 프로그램 데이터를 저장하기 위해 각 클러스터 노드에 여분의 디스크를 추가했습니다.  이 경우 MySQL 데이터베이스가됩니다. Azure IaaS에서 Linux 가상 머신은 디스크에 대해 다음과 같은 배열을 사용합니다.

  • / dev / sda – OS 디스크
  • / dev / sdb – 임시 디스크
  • / dev / sdc – 첫 번째 데이터 디스크
  • / dev / sdd – 두 번째 데이터 디스크
  • …
  • / dev / sdj – 8 번째 데이터 디스크

이 가이드의 6 단계에서 추가 한 디스크는 / dev / sdc로 표시되어야합니다.  "fdisk -l"명령을 실행하여 확인할 수 있습니다.  / dev / sda (OS)와 / dev / sdb (temporary)는 이미 디스크 파티션을 가지고 있으며 사용 중임을 알 수 있습니다.

# fdisk -l

디스크 / dev / sda : 31.5GB, 31457280000 바이트, 61440000 섹터
단위 = 1의 섹터 * 512 = 512 바이트
섹터 크기 (논리 / 실제) : 512 바이트 / 4096 바이트
I / O 크기 (최소 / 최적) : 4096 바이트 / 4096 바이트
디스크 레이블 유형 : dos
디스크 식별자 : 0x000c46d3

장치 부팅 시작 끝 블록 ID 시스템
/ dev / sda1 * 2048 1026047 512000 83 Linux
/ dev / sda2 1026048 61439999 30206976 83 Linux

디스크 / dev / sdb : 7516MB, 7516192768 바이트, 14680064 섹터
단위 = 1의 섹터 * 512 = 512 바이트
섹터 크기 (논리 / 실제) : 512 바이트 / 4096 바이트
I / O 크기 (최소 / 최적) : 4096 바이트 / 4096 바이트
디스크 레이블 유형 : dos
디스크 식별자 : 0x7cd70e11

장치 부팅 시작 끝 블록 ID 시스템
/ dev / sdb1 128 14678015 7338944 83 Linux

디스크 / dev / sdc : 10.7GB, 10737418240 바이트, 20971520 섹터
단위 = 1의 섹터 * 512 = 512 바이트
섹터 크기 (논리 / 실제) : 512 바이트 / 4096 바이트
I / O 크기 (최소 / 최적) : 4096 바이트 / 4096 바이트

여기서 파티션 (/ dev / sdc1)을 만들고, 포맷하고, SQL의 기본 위치 인 / var / opt / mssql에 마운트합니다.  "sql-linux1"과 "sql-linux2"모두 다음 단계를 수행하십시오.

# fdisk / dev / sdc
명령 (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 @ sql-linux1 ~] #
# mkfs.ext4 / dev / sdc1
# mkdir / var / opt / mssql
# chmod 770 / var / opt / mssql

파일 시스템 마운트 :

# mount / dev / sdc1 / var / opt / mssql

SQL Server 설치 및 구성

신선한 리눅스 시스템으로 시작했다면 여기에서 전체 설치 지침을 찾을 수 있습니다. 이 가이드에서 설명한 것처럼 "Red Hat Enterprise Linux 7.2"Azure 템플릿의 SQL Server vNext를 사용하여 VM을 만든 경우 SQL Server가 이미 설치되어 있습니다.  이제는 설정 스크립트를 실행하기 만하면됩니다.

# / opt / mssql / bin / sqlservr-setup
Microsoft (R) SQL Server (R) 설치

언제든지 Ctrl-C를 눌러 설정을 중단 할 수 있습니다. 이 프로그램 시작
무인 상태에서 실행하는 방법에 대한 정보는 --help 옵션과 함께
방법.

이 제품의 사용권 조항은에서 다운로드 할 수 있습니다.
http://go.microsoft.com/fwlink/?LinkId=746388&hl=ko
/usr/share/doc/mssql-server/LICENSE.TXT에 있습니다.

라이센스 조건에 동의합니까? 그렇다면 "YES"를 입력하십시오 : 예

시스템 관리자 (SA) 계정의 암호를 입력하십시오 : <원하는 암호 입력>
시스템 관리자 (SA) 계정의 암호를 확인하십시오 : <원하는 암호 입력>

시스템 관리자 (SA) 계정 암호 설정 중 ...

지금 SQL Server 서비스를 시작 하시겠습니까? [y / n] : y
부팅 할 때 SQL Server를 시작 하시겠습니까? [y / n] : n

sqlservr-setup --enable-service를 사용하여 SQL Server를 시작할 수 있습니다.
부팅시.

설치가 성공적으로 완료되었습니다.

서비스가 실행 중인지 확인하십시오.

# systemctl status mssql-server

두 노드에서 SQL Server를 중지하십시오.  클러스터 소프트웨어는 나중에 시작할 책임이 있습니다.

# systemctl stop mssql-server
# systemctl stop mssql-server-telemetry

클러스터 설치 및 구성

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

Linux 용 SIOS Protection Suite 설치

3 개의 VM (sql-linux1, sql-linux2, sql-witness) 모두에서 다음 단계를 수행하십시오. SPS-Linux 설치 이미지 파일 (sps.img)을 다운로드하고 평가판 라이센스를 얻거나 영구 라이센스를 구입하십시오.  자세한 내용은 SIOS에 문의하십시오. 당신은 루프백으로 마운트 할 것이고, 루트로 "setup"스크립트를 실행할 것입니다 (또는 아직 루트 쉘을 얻지 못했다면 첫번째 "sudo su -"). 예를 들면 다음과 같습니다 :

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

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

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

Witness / Quorum 패키지 설치

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

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

 

 

 

 

 

 

 

 

  

 

 

 

   

 

   

 

  

  •  
  •  

    

  •  
  •  
  •  

       

 

  

  

    

 
 
 
 
 
 
 
 
 

  

 
 
 
 
 
 
 
 
 
 

  

 

  

 
 
 
 
 
 
 

 

 
 
 
 
 
 
 
 

 

          

 

   

  •  
  •  
  •  
  •  
 

 

 

 
 
 

 

 
 
 

 

 
 
 

 

 
 
 

 

 

 

   

 
 
 
 
 
 
 
 
 
 

 

 
 
 
 
 
 

  

 

        

 

              

 

  

 

 

 
 

 
 

 

  

 

 

 
 

 
 

 

 

 

Filed Under: 서버 클러스터 단순화 Tagged With: Linux 용 SQL Server, 리눅스

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

1월 6, 2019 by Jason Aw Leave a Comment

단계별 : 공유 저장 장치없이 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와 암호를 입력하십시오lk-gui-connect1 : 다음, 다음 스크린 샷에서 강조 표시된 "서버에 연결"단추를 클릭하여 "node2"와 "witness"모두에 연결하십시오. 이제 lk-gui-connect2GUI에서 3 개의 모든 서버를 볼 수 있습니다. 온라인 상태이고 건강하다는 것을 나타내는 녹색 체크 표시 아이콘 : lk-gui-connect3

통신 경로 생성

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

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

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

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

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

통신 경로 확인

"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 (대상)로 복제 할 데이터 복제 자원을 만듭니다.  "녹색 더하기"아이콘을 클릭하여 새 리소스를 만데이터 복제 1듭니다. 마법사의 지시에 따르십시오 :

복구 키트를 선택하십시오 : 데이터 복제
스위치 백 유형 : 지능형
서버 : 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

클러스터는 다음과 같습니다. 데이터 복제 2  

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>

 

Filed Under: 서버 클러스터 단순화

  • « Previous Page
  • 1
  • …
  • 74
  • 75
  • 76
  • 77
  • 78
  • …
  • 106
  • Next Page »

최근 게시물

  • 능동-능동 방식 vs. 능동-수동 방식
  • Broadcom/VMware: 고가용성을 하이퍼바이저에서 분리할 때가 되었다
  • 기술 지원 고객 만족도를 높이는 방법
  • 건물 안전 유지: 유지보수 및 보안 시스템의 고가용성 확보
  • 모듈화와 추상화를 통한 고가용성 설계

가장 인기있는 게시물

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

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