Linux의 가용성 그룹 및 장애 조치(failover) 클러스터 인스턴스에 대한 Pacemaker
적용 대상: 
SQL Server - Linux
SQL Server 2017(14.x)부터 SQL Server는 Linux 및 Windows에서 모두 지원됩니다. Windows 기반 SQL Server 배포와 마찬가지로 SQL Server 데이터베이스 및 인스턴스는 Linux에서 가용성이 높아야 합니다. 이 문서에서는 Corosync와 함께 Pacemaker를 이해하기 위한 기본 정보와 SQL Server 구성을 위해 이것을 계획 및 배포하는 방법을 설명합니다.
HA 추가 기능/확장 기본 사항
현재 지원되는 모든 배포는 Pacemaker 클러스터링 스택을 기반으로 하는 고가용성 추가 기능/확장을 제공합니다. 이 스택은 다음과 같은 두 가지 주요 구성 요소인 Pacemaker 및 Corosync를 통합합니다. 스택의 모든 구성 요소는 다음과 같습니다.
- Pacemaker. 클러스터형 컴퓨터에서 항목을 조정하는 핵심 클러스터링 구성 요소입니다.
- Corosync. 쿼럼, 실패한 프로세스를 다시 시작하는 기능 등의 항목을 제공하는 API의 프레임워크 및 세트입니다.
- libQB. 로깅 같은 항목을 제공합니다.
- 리소스 에이전트. 애플리케이션이 Pacemaker와 통합될 수 있도록 제공되는 특정 기능입니다.
- 펜스 에이전트. 노드에 문제가 있는 경우 노드를 격리하고 처리하는 데 도움이 되는 스크립트/기능입니다.
참고
클러스터 스택은 일반적으로 Linux 환경에서 Pacemaker라고도 합니다.
이 솔루션은 Windows를 사용하여 클러스터형 구성을 배포하는 것과 일부 측면에서는 비슷하지만 많은 측면에서 서로 다릅니다. Windows에서는 WSFC(Windows Server 장애 조치(failover) 클러스터)라는 클러스터링의 가용성 형식이 운영 체제에 기본 제공되며, WSFC, 장애 조치(failover) 클러스터링을 만들 수 있는 기능은 기본적으로 사용하지 않도록 설정됩니다. Windows에서 AG 및 FCI는 WSFC 위에 빌드되며 SQL Server에서 제공하는 특정 리소스 DLL로 인해 긴밀한 통합을 공유합니다. 한 공급업체에서 모든 것을 제공하므로 대체로 솔루션을 이렇게 긴밀하게 결합할 수 있습니다.
Linux에서 지원되는 각 배포에는 Pacemaker를 사용할 수 있지만 각 배포는 약간 다른 구현 및 버전을 사용자 지정하고 포함할 수 있습니다. 몇 가지 차이는 이 문서의 지침에 반영됩니다. 클러스터링 계층은 오픈 소스이므로 배포와 함께 제공되더라도 WSFC가 Windows에서 작동하는 것과 동일한 방식으로 긴밀하게 통합되지는 않습니다. 이런 이유로 Microsoft에서는 SQL Server 및 Pacemaker 스택이 Windows 기반 AG 및 FCI에 가깝지는 똑같지는 않은 환경을 제공할 수 있도록 mssql-server-ha를 제공합니다.
RHEL 및 SLES의 경우 전체 참조 정보에 포함된 모든 항목에 대한 자세한 설명을 포함한 Pacemaker에 대한 전체 설명서는 다음을 참조하세요.
Ubuntu에는 가용성에 대한 가이드가 없습니다.
전체 스택에 대한 자세한 내용은 ClusterLabs 사이트의 공식 Pacemaker 설명서 페이지를 참조하세요.
Pacemaker 개념 및 용어
이 섹션에서는 Pacemaker 구현에 대한 일반적인 개념과 용어를 설명합니다.
노드
노드는 클러스터에 참여하는 서버입니다. Pacemaker 클러스터는 기본적으로 최대 16개의 노드를 지원합니다. Corosync가 추가 노드에서 실행되지 않지만 SQL Server에 대해 Corosync가 필요한 경우 이 수를 초과할 수 있습니다. 따라서 SQL Server 기반 구성에 대해 클러스터에 포함할 수 있는 최대 노드 수는 16개입니다. 이는 Pacemaker 한도이며 SQL Server에서 지정하는 AG 및 FCI에 대한 최대 제한 사항에 대해 수행할 작업은 없습니다.
리소스
WSFC 및 Pacemaker 클러스터에는 둘 다 리소스 개념이 있습니다. 리소스는 디스크 또는 IP 주소와 같이 클러스터의 컨텍스트에서 실행되는 특정 기능입니다. 예를 들어 Pacemaker에서는 FCI 및 AG 리소스를 둘 다 만들 수 있습니다. 이는 AG를 구성할 때 FCI 또는 AG 리소스에 대한 SQL Server 리소스를 확인할 수 있는 WSFC에서 수행하는 작업과 다르지 않지만, SQL Server가 Pacemaker와 통합되는 방식의 기본적인 차이로 인해 똑같지는 같습니다.
Pacemaker에는 표준 및 복제 리소스가 있습니다. 복제 리소스는 모든 노드에서 동시에 실행되는 리소스입니다. 예를 들어 부하 분산을 위해 여러 노드에서 실행되는 IP 주소가 있습니다. 특정 시간에 하나의 노드만 FCI를 호스트할 수 있으므로 FCI에 대해 만들어지는 모든 리소스는 표준 리소스를 사용합니다.
참고
바이어스 없는 통신
이 문서에는 이 컨텍스트에서 사용될 때 Microsoft가 불쾌한 표현으로 간주하는 용어인 슬레이브 용어에 대한 참조가 포함되어 있습니다. 이 용어가 이 문서에 나타나는 이유는 현재 소프트웨어에 나타나기 때문입니다. 소프트웨어에서 이 용어가 제거되면 문서에서 제거할 것입니다.
AG를 만들 때 다중 상태 리소스라는 특수한 형식의 복제 리소스가 필요합니다. AG에는 주 복제본이 하나만 있지만 AG 자체는 작동하도록 구성된 모든 노드에서 실행되며 읽기 전용 액세스와 같은 작업을 허용할 수 있습니다. 이는 노드의 “라이브” 사용이므로 리소스에는 두 가지 상태인 승격됨(이전 마스터) 및 승격되지 않음(이전 슬레이브)의 개념이 있습니다. 자세한 내용은 Multi-state resources: Resources that have multiple modes(다중 상태 리소스: 여러 모드를 포함하는 리소스)를 참조하세요.
리소스 그룹/세트
WSFC의 역할과 마찬가지로 Pacemaker 클러스터에는 리소스 그룹의 개념이 있습니다. 리소스 그룹(SLES의 경우 세트라고 함)은 함께 작동하고 한 노드에서 다른 노드로 단일 단위로 장애 조치(failover)될 수 있는 리소스 컬렉션입니다. 리소스 그룹은 승격됨 또는 승격되지 않음으로 구성된 리소스를 포함할 수 없으므로 AG에 사용할 수 없습니다. 리소스 그룹은 FCI에 사용될 수 있지만 일반적으로 권장되는 구성이 아닙니다.
제약 조건
WSFC에는 두 가지 다른 리소스 간 부모/자식 관계를 WSFC에 알리는 종속성 같은 항목과 리소스에 대한 다양한 매개 변수가 있습니다. 종속성은 먼저 온라인으로 전환해야 하는 리소스를 WSFC에 알리는 규칙일 뿐입니다.
Pacemaker 클러스터에는 종속성 개념이 없지만 제약 조건이 있습니다. 공동 배치, 위치 및 순서 지정의 세 가지 제약 조건이 있습니다.
- 공동 배치 제약 조건은 두 리소스를 동일한 노드에서 실행해야 하는지 여부를 적용합니다.
- 위치 제약 조건은 리소스를 실행할 수 있거나 실행할 수 없는 위치를 Pacemaker 클러스터에 알려 줍니다.
- 순서 지정 제약 조건은 리소스를 시작해야 하는 순서를 Pacemaker 클러스터에 알려줍니다.
참고 항목
공동 배치 제약 조건은 모두 단일 단위로 표시되기 때문에 리소스 그룹의 리소스에 필요하지 않습니다.
쿼럼, 펜스 에이전트 및 STONITH
Pacemaker에서 쿼럼은 WSFC 개념과 비슷합니다. 클러스터 쿼럼 메커니즘의 전체 목적은 클러스터가 계속 실행되는지 확인하는 것입니다. Linux 배포에 대한 WSFC 및 HA 추가 기능에는 각 노드가 쿼럼으로 계산되는 투표 개념이 있습니다. 대부분의 투표가 증가하기를 원합니다. 그렇지 않으면 최악의 경우 클러스터가 종료됩니다.
WSFC와 달리 쿼럼 작업을 수행할 감시 리소스가 없습니다. WSFC와 마찬가지로 목표는 투표자 수를 홀수로 유지하는 것입니다. 쿼럼 구성에는 FCI와는 다른 AG에 대한 고려 사항이 있습니다.
WSFC는 참여하는 노드의 상태를 모니터링하고 문제가 발생할 때 노드를 처리합니다. 이후 버전의 WSFC는 잘못 동작하거나 사용할 수 없는 노드를 격리하는 것과 같은 기능을 제공합니다(노드가 작동되지 않음, 네트워크 통신 작동이 중단됨 등). Linux 쪽에서는 이 유형의 기능이 펜스 에이전트에서 제공됩니다. 이 개념을 펜싱이라고도 합니다. 그러나 이 펜스 에이전트는 배포와 관련이 있으며 대부분은 하드웨어 공급업체에서 제공되고 일부는 하이퍼바이저를 제공하는 공급업체와 같은 소프트웨어 공급업체에서 제공됩니다. 예를 들어 VMware는 vSphere를 사용하여 가상화된 Linux VM에 사용할 수 있는 펜스 에이전트를 제공합니다.
쿼럼 및 펜싱은 STONITH 또는 Shoot the Other Node in the Head(헤드에 있는 다른 노드 맞추기)라는 다른 개념에 연결합니다. 모든 Linux 배포에 지원되는 Pacemaker 클러스터를 포함하려면 STONITH가 필요합니다. 자세한 내용은 Fencing in a Red Hat High Availability Cluster(Red Hat 고가용성 클러스터의 펜싱)(RHEL)를 참조하세요.
corosync.conf
이 corosync.conf 파일에는 클러스터의 구성이 포함됩니다. /etc/corosync에 있습니다. 클러스터가 제대로 설정되어 있다면 일상적인 작업을 수행하는 동안에는 이 파일을 편집할 필요가 없습니다.
클러스터 로그 위치
Pacemaker 클러스터의 로그 위치는 배포에 따라 다릅니다.
- RHEL 및 SLES:
/var/log/cluster/corosync.log - Ubuntu:
/var/log/corosync/corosync.log
기본 로깅 위치를 변경하려면 corosync.conf를 수정합니다.
SQL Server에 대한 Pacemaker 클러스터 계획
이 섹션에서는 Pacemaker 클러스터의 중요한 계획 사항을 설명합니다.
SQL Server에 대한 Linux 기반 Pacemaker 클러스터 가상화
가상 머신을 사용하여 AG 및 FCI에 대해 Linux 기반 SQL Server 배포를 배포하는 작업에는 Windows 기반 배포의 경우와 동일한 규칙이 적용됩니다. 하드웨어 가상화 환경에서 실행되는 Microsoft SQL Server 제품에 대한 지원 정책에는 Microsoft에서 제공하는 가상화된 SQL Server 배포의 지원 가능성에 대한 기본 규칙 집합이 있습니다. Microsoft의 Hyper-V 및 VMware의 ESXi와 같은 하이퍼바이저는 플랫폼 자체의 차이로 인해 서로 다른 분산을 포함할 수 있습니다.
가상화된 AG 및 FCI의 경우 지정된 Pacemaker 클러스터의 노드에 대해 선호도 방지가 설정되어 있는지 확인합니다. AG 또는 FCI 구성에서 고가용성을 위해 구성된 경우 SQL Server를 호스트하는 VM은 동일한 하이퍼바이저 호스트에서 실행되지 않아야 합니다. 예를 들어 2노드 FCI가 배포된 경우에는, 특히 Live Migration 또는 vMotion 같은 기능을 사용하는 경우 호스트 오류 발생 시 이동할 노드를 호스트하는 VM 중 하나에 사용할 위치가 있도록 적어도 세 개의 하이퍼바이저 호스트가 있어야 합니다.
Hyper-V 설명서는 고가용성을 위해 게스트 클러스터링 사용을 참조 하세요.
네트워크
WSFC와 달리 Pacemaker의 경우 Pacemaker 클러스터 자체에 대해 전용 이름 또는 하나 이상의 전용 IP 주소가 필요하지 않습니다. AG 및 FCI의 경우 IP 주소가 필요하지만(자세한 내용은 각 설명서 참조), 네트워크 이름 리소스가 없으므로 이름이 필요하지 않습니다. SLES는 관리를 위해 IP 주소를 구성할 수 있지만, Pacemaker 클러스터 만들기에서 볼 수 있는 것처럼 반드시 필요한 것은 아닙니다.
WSFC와 마찬가지로 Pacemaker는 중복 네트워킹을 선호합니다. 즉, 개별 IP 주소가 있는 고유한 네트워크 카드(NIC 또는 물리적 카드의 경우 pNIC)를 사용합니다. 클러스터 구성 측면에서 각 IP 주소에는 자체 링이라는 항목이 있습니다. 그러나 현재 WSFC와 마찬가지로 많은 구현이 가상화되어 있거나 서버에 제공되는 단일 vNIC(가상화된 NIC)만 있는 퍼블릭 클라우드에 있습니다. 모든 pNIC 및 vNIC가 동일한 실제 또는 가상 스위치에 연결된 경우 네트워크 계층에는 실제 중복성이 없으므로 여러 NIC를 구성하는 것은 가상 머신에 대한 약간의 오해입니다. 네트워크 중복성은 일반적으로 가상화된 배포를 위해 하이퍼바이저에 기본 제공되며, 퍼블릭 클라우드에 한정적으로 기본 제공됩니다.
여러 NIC 및 Pacemaker와 WSFC의 한 가지 차이는 Pacemaker는 동일한 서브넷에서 여러 IP 주소를 허용하지만 WSFC는 허용하지 않는다는 것입니다. 여러 서브넷 및 Linux 클러스터에 대한 자세한 내용은 여러 서브넷 Always On 가용성 그룹 및 장애 조치(failover) 클러스터 인스턴스 구성 문서를 참조하세요.
쿼럼 및 STONITH
쿼럼 구성 및 요구 사항은 SQL Server의 AG 또는 FCI 특정 배포와 관련됩니다.
지원되는 Pacemaker 클러스터에는 STONITH가 필요합니다. 배포의 설명서를 사용하여 STONITH를 구성합니다. SLES에 대한 예제는 Storage-based Fencing(스토리지 기반 펜싱)에 있습니다. ESXI 기반 솔루션의 경우 VMware vCenter에 대한 STONITH 에이전트도 있습니다. 자세한 내용은 VMware VM VCenter SOAP 펜싱을 위한 Stonith 플러그 인 에이전트(비공식)를 참조하세요.
상호 운용성
이 섹션에서는 Linux 기반 클러스터가 WSFC 또는 Linux의 다른 배포와 상호 작용하는 방법에 대해 설명합니다.
WSFC
현재는 WSFC 및 Pacemaker 클러스터가 함께 작동할 수 있는 직접적인 방법이 없습니다. 즉, WSFC 및 Pacemaker에서 작동하는 AG 또는 FCI를 만들 수 있는 방법이 없습니다. 그러나 두 가지 상호 운용성 솔루션이 있으며 둘 다 AG용으로 디자인됩니다. FCI가 플랫폼 간 구성에 참여할 수 있는 유일한 방법은 다음 두 가지 시나리오 중 하나에서 인스턴스로 참여하는 경우입니다.
- 클러스터 유형이 없음인 AG. 자세한 내용은 Windows 가용성 그룹 설명서를 참조하세요.
- 두 가지 AG를 자체 가용성 그룹으로 구성할 수 있는 특수 가용성 그룹 유형인 분산 AG. 분산 AG에 대한 자세한 내용은 분산 가용성 그룹 설명서를 참조하세요.
기타 Linux 배포
Linux에서 Pacemaker 클러스터의 모든 노드는 동일한 배포에 있어야 합니다. 예를 들어 이것은 SLES 노드가 있는 Pacemaker 클러스터에 RHEL 노드가 포함될 수 없음을 의미합니다. 이에 대한 주요 이유는 이전에 언급한 것처럼 배포의 버전과 기능이 서로 달라 항목이 제대로 작동할 수 없기 때문입니다. 배포를 함께 사용하는 것은 WSFC 및 Linux를 함께 사용하는 것인 없음 또는 분산 AG를 사용하는 것과 같습니다.