이 문서에서는 Pacemaker를 사용하여 Linux에서 3노드 클러스터를 만들고 이전에 만든 가용성 그룹을 클러스터의 리소스로 추가하는 방법을 설명합니다. 고가용성을 위해 Linux의 가용성 그룹에는 세 개의 노드가 필요합니다. 가용성 그룹 구성의 고가용성 및 데이터 보호를 참조하세요.
SQL Server는 WSFC(Windows Server 장애 조치(failover) 클러스터링)과 통합되는 것처럼 Linux의 Pacemaker와 긴밀하게 통합되지 않습니다. SQL Server 인스턴스는 클러스터를 인식하지 못하며 모든 오케스트레이션은 외부에서 온 것입니다. Pacemaker는 클러스터 리소스 오케스트레이션을 제공합니다. 또한 가상 네트워크 이름은 Windows Server 장애 조치(failover) 클러스터링에만 해당합니다. Pacemaker에는 해당 이름이 없습니다. 클러스터 정보를 쿼리하는 가용성 그룹 DMV(동적 관리 뷰)는 Pacemaker 클러스터에서 빈 행을 반환합니다. 장애 조치(failover) 후에 투명한 다시 연결을 위한 수신기를 만들려면 가상 IP 리소스를 만드는 데 사용되는 IP를 사용하여 DNS에 수신기 이름을 수동으로 등록합니다.
다음 섹션에서는 지원되는 각 Linux 배포판에 대해 Pacemaker 클러스터를 설정하고 고가용성을 위해 클러스터에서 가용성 그룹을 리소스로 추가하는 단계를 안내합니다.
클러스터링 계층은 Pacemaker 위에 빌드된 RHEL(Red Hat Enterprise Linux) HA 추가 기능을 기반으로 합니다.
참고
Red Hat 전체 설명서에 액세스하려면 유효한 구독이 필요합니다.
클러스터 구성, 리소스 에이전트 옵션 및 관리에 대한 자세한 내용은 RHEL 참조 설명서를 참조하세요.
로드맵
고가용성을 위해 Linux 서버에서 가용성 그룹을 만드는 단계는 Windows Server 장애 조치(failover) 클러스터의 단계와 다릅니다. 다음 목록에서는 개괄적인 단계를 설명합니다.
클러스터 노드에서 SQL Server를 구성합니다.
가용성 그룹을 만듭니다.
Pacemaker와 같은 클러스터 리소스 관리자를 구성합니다. 이러한 지침은 이 문서에 포함되어 있습니다.
클러스터 리소스 관리자를 구성하는 방법은 특정 Linux 배포에 따라 다릅니다.
Important
프로덕션 환경에서는 고가용성을 위한 펜싱 에이전트가 필요합니다. 이 설명서의 데모에서는 펜싱 에이전트를 사용하지 않습니다. 데모는 테스트 및 유효성 검사를 위해서만 제공됩니다.
Linux 클러스터는 펜싱을 사용하여 클러스터를 알려진 상태로 되돌립니다. 펜싱을 구성하는 방법은 배포 및 환경에 따라 달라집니다. 현재, 일부 클라우드 환경에서는 펜싱을 사용할 수 없습니다. 자세한 내용은 RHEL 고가용성 클러스터의 지원 정책 - 가상화 플랫폼을 참조하세요.
가용성 그룹을 클러스터의 리소스로 추가합니다.
RHEL에 대해 고가용성을 구성하려면 고가용성 구독을 사용하도록 설정한 다음, Pacemaker를 구성합니다.
RHEL에 대해 고가용성 구독 사용
클러스터의 각 노드에는 RHEL 및 고가용성 추가 기능에 대한 적절한 구독이 있어야 합니다. Red Hat Enterprise Linux에서 고가용성 클러스터 패키지를 설치하는 방법에서 요구 사항을 검토하세요. 다음 단계에 따라 구독 및 리포지토리를 구성합니다.
시스템을 등록합니다.
sudo subscription-manager register
사용자 이름 및 암호를 제공합니다.
등록에 사용할 수 있는 풀을 나열합니다.
sudo subscription-manager list --available
사용 가능한 풀 목록에서 고가용성 구독의 풀 ID를 확인합니다.
다음 스크립트를 업데이트합니다. <pool id>
를 이전 단계의 고가용성을 위한 풀 ID로 바꿉니다. 스크립트를 실행하여 구독을 연결합니다.
sudo subscription-manager attach --pool=<pool id>
리포지토리를 사용하도록 설정합니다.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
자세한 내용은 Pacemaker - The Open Source, High Availability Cluster(Pacemaker - 오픈 소스 고가용성 클러스터)를 참조하세요.
구독을 구성한 후에는 다음 단계를 완료하여 Pacemaker를 구성합니다.
구독을 등록한 후에는 다음 단계를 완료하여 Pacemaker를 구성합니다.
모든 클러스터 노드에서 Pacemaker 방화벽 포트를 엽니다. firewalld
를 사용하여 이러한 포트를 열려면 다음 명령을 실행합니다.
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
방화벽에 고가용성 구성이 기본 제공되지 않는 경우 Pacemaker에 대해 다음 포트를 엽니다.
- TCP: 포트 2224, 3121, 21064
- UDP: 포트 5405
모든 노드에 Pacemaker 패키지를 설치합니다.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Pacemaker 및 Corosync 패키지를 설치할 때 생성된 기본 사용자의 암호를 설정합니다. 모든 노드에서 같은 암호를 사용합니다.
sudo passwd hacluster
다시 시작한 후 노드가 클러스터에 다시 조인할 수 있도록 pcsd
서비스 및 Pacemaker를 사용하도록 설정하고 시작합니다. 모든 노드에서 다음 명령을 실행합니다.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
클러스터를 만듭니다. 클러스터를 만들려면 다음 명령을 실행합니다.
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
RHEL 8의 경우 노드를 별도로 인증해야 합니다. 메시지가 표시될 때 사용자 이름과 암호를 hacluster
수동으로 입력합니다.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
참고 항목
이전에 같은 노드에서 클러스터를 구성한 경우 pcs cluster setup
을 실행할 때 --force
옵션을 사용해야 합니다. 이 옵션은 pcs cluster destroy
를 실행하는 것과 동일합니다. Pacemaker를 다시 사용하도록 설정하려면 sudo systemctl enable pacemaker
를 실행합니다.
SQL Server용 SQL Server 리소스 에이전트를 설치합니다. 모든 노드에서 다음 명령을 실행합니다.
sudo yum install mssql-server-ha
Pacemaker가 구성된 후 pcs
를 사용하여 클러스터와 상호 작용합니다. 클러스터의 한 노드에서 모든 명령을 실행합니다.
여러 NIC(네트워크 인터페이스)에 대한 고려 사항
여러 NIC가 있는 서버에서 고가용성을 설정하는 경우 다음 제안 사항을 따르세요.
여러 NIC의 서버 IP 주소가 각 노드에서 Linux 서버의 호스트 이름으로 확인되도록 hosts
파일이 설정되어 있는지 확인합니다.
Pacemaker를 사용하여 클러스터를 설정할 때 서버의 호스트 이름을 사용하여 모든 NIC에 대한 구성을 설정하도록 Corosync를 구성해야 합니다. 단일 NIC를 통한 Pacemaker/Corosync 통신만 원합니다. Pacemaker 클러스터가 구성되면 corosync.conf
파일의 구성을 수정하고 Pacemaker/Corosync 통신에 사용할 전용 NIC의 IP 주소를 업데이트합니다.
corosync.conf
파일에 지정된 <hostname>
은 역방향 조회(ping -a <ip_address>
)를 수행할 때 지정된 출력과 동일해야 하며 호스트에 구성된 짧은 이름이어야 합니다. hosts
파일이 이름 확인에 적합한 IP 주소를 나타내는지도 확인합니다.
corosync.conf
파일 예시의 변경 내용은 아래에 강조 표시되어 있습니다.
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Pacemaker 클러스터 공급업체는 지원되는 클러스터 설정에 대해 구성된 펜싱 디바이스를 사용하여 장애가 발생한 노드를 펜싱해야 합니다. 클러스터 리소스 관리자가 노드 또는 노드의 리소스 상태를 확인할 수 없는 경우 펜싱은 클러스터를 다시 알려진 상태로 되돌립니다.
펜싱 디바이스는 펜싱 에이전트를 제공합니다. Azure의 Red Hat Enterprise Linux에서 Pacemaker 설정에서는 Azure의 이 클러스터에 대해 펜싱 디바이스를 만드는 방법을 보여 줍니다. 작업 환경에 맞게 지침을 수정하세요.
리소스 수준 펜싱은 리소스를 구성하여 중단 시 데이터 손상이 발생하지 않도록 합니다. 예를 들어 리소스 수준 펜싱을 사용하여 통신 링크가 가동 중단될 때 노드의 디스크를 오래된 것으로 표시할 수 있습니다.
노드 수준 펜싱은 노드가 리소스를 실행하지 않도록 합니다. 이 작업은 노드를 다시 설정하여 수행됩니다. Pacemaker는 다양한 펜싱 디바이스를 지원합니다. 예를 들어 서버에 대한 무정전 전원 공급 디바이스 또는 관리 인터페이스 카드가 있습니다.
실패한 노드 펜싱에 대한 자세한 내용은 다음 문서를 참조하세요.
참고
노드 수준 펜싱 구성은 사용자 환경에 따라 크게 좌우되므로 이 자습서에서는 사용하지 않도록 설정합니다(나중에 구성할 수 있음). 다음 스크립트는 노드 수준 펜싱을 사용하지 않도록 설정합니다.
sudo pcs property set stonith-enabled=false
펜싱을 사용하지 않도록 설정하는 기능은 테스트 목적으로만 제공됩니다. 프로덕션 환경에서 Pacemaker를 사용하려는 경우 해당 환경에 따라 펜싱 구현을 계획하고 사용 상태로 유지해야 합니다.
클러스터 속성 cluster-recheck-interval 설정
cluster-recheck-interval
은 클러스터에서 리소스 매개 변수, 제약 조건 또는 기타 클러스터 옵션의 변경 내용을 확인하는 폴링 간격을 나타냅니다. 복제본의 작동이 중단되면 클러스터는 failure-timeout
값과 cluster-recheck-interval
값을 통해 바인딩된 간격으로 복제본을 다시 시작하려고 합니다. 예를 들어 failure-timeout
을 60초로 설정하고 cluster-recheck-interval
을 120초로 설정한 경우 60초보다 크고 120초보다 작은 간격으로 다시 시작이 시도됩니다. failure-timeout을 60초로 설정하고 cluster-recheck-interval
을 60초보다 큰 값으로 설정하는 것이 좋습니다. cluster-recheck-interval
을 더 작은 값으로 설정하는 것은 권장되지 않습니다.
속성 값을 2 minutes
로 업데이트하려면 다음 명령을 실행합니다.
sudo pcs property set cluster-recheck-interval=2min
Pacemaker 클러스터에서 관리하는 가용성 그룹 리소스가 이미 있는 경우, Pacemaker 패키지 1.1.18-11.el7에서는 해당 값이 false
일 때 start-failure-is-fatal
클러스터 설정 동작이 변경되었습니다. 이 변경 내용은 장애 조치(failover) 워크플로에 영향을 줍니다. 주 복제본이 중단될 경우 클러스터가 사용 가능한 보조 복제본 중 하나로 장애 조치(failover)되어야 합니다. 예상과 달리, 사용자는 클러스터가 실패한 주 복제본을 시작하려고 계속 시도하는 것을 보게 됩니다. 주 복제본이 영구 중단되어 온라인 상태로 전환되지 않는 경우 클러스터도 사용 가능한 다른 보조 복제본으로 장애 조치(failover)되지 않습니다. 이 변경 내용 때문에 start-failure-is-fatal
을 설정하는 이전 권장 구성은 더 이상 유효하지 않으며, 설정을 기본값인 true
로 되돌려야 합니다.
또한 failure-timeout
속성이 포함되도록 AG 리소스를 업데이트해야 합니다.
속성 값을 true
로 업데이트하려면 다음 명령을 실행합니다.
sudo pcs property set start-failure-is-fatal=true
ag_cluster
리소스 속성 failure-timeout
을 60s
로 업데이트하려면 다음을 실행합니다.
pcs resource update ag_cluster meta failure-timeout=60s
Pacemaker 클러스터 속성에 대한 자세한 내용은 Pacemaker Clusters Properties(Pacemaker 클러스터 속성)를 참조하세요.
Pacemaker용 SQL Server 로그인 만들기
주의
암호는 SQL Server 기본 암호 정책을 따라야 합니다. 기본적으로 암호는 8자 이상이어야 하며 대문자, 소문자, 0~9까지의 숫자 및 기호 네 가지 집합 중 세 집합의 문자를 포함해야 합니다. 암호 길이는 128자까지 가능하며 되도록 길고 복잡한 암호를 사용합니다.
모든 SQL Server 인스턴스에서 Pacemaker를 위한 서버 로그인을 만듭니다.
다음 Transact-SQL은 로그인을 만듭니다. <password>
를 사용자 고유의 복합 암호로 바꿉니다.
USE [master];
GO
CREATE LOGIN [pacemakerLogin]
WITH PASSWORD = N'<password>';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
가용성 그룹을 만든 이후, 노드를 추가하기 전에 pacemaker 사용자는 가용성 그룹에 대해 ALTER
, CONTROL
, VIEW DEFINITION
권한이 필요합니다.
모든 SQL Server 인스턴스에서 SQL Server 로그인을 위한 자격 증명을 저장합니다.
<password>
를 사용자 고유의 복합 암호로 바꿉니다.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo '<password>' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
가용성 그룹 리소스 만들기
가용성 그룹 리소스를 만들려면 pcs resource create
명령을 사용하고 리소스 속성을 설정합니다. 다음 명령은 이름이 ag1
인 가용성 그룹에 대해 ocf:mssql:ag
마스터/하위 유형 리소스를 만듭니다.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
RHEL 8의 가용성과 함께, 생성 구문이 변경되었습니다. RHEL 8을 사용하는 경우 용어 master
가 promotable
로 변경되었습니다. 위의 명령 대신 다음의 생성 명령을 사용합니다.
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
가상 IP 리소스 만들기
가상 IP 주소 리소스를 만들려면 한 노드에서 다음 명령을 실행합니다. 네트워크의 사용 가능한 고정 IP 주소를 사용합니다. <10.128.16.240>
사이 IP 주소를 유효한 IP 주소로 바꿉니다.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
Pacemaker에는 해당하는 가상 서버 이름이 없습니다. IP 주소 대신 문자열 서버 이름을 가리키는 연결 문자열을 사용하려면 DNS에 가상 IP 리소스 주소와 원하는 가상 서버 이름을 등록합니다. DR 구성의 경우 기본 및 DR 사이트의 DNS 서버에 원하는 가상 서버 이름 및 IP 주소를 등록합니다.
공동 배치 제약 조건 추가
리소스를 실행할 위치 선택과 같은, Pacemaker 클러스터의 거의 모든 결정은 점수 비교를 통해 수행됩니다. 점수는 리소스별로 계산됩니다. Cluster Resource Manager는 특정 리소스에 대해 점수가 가장 높은 노드를 선택합니다. 노드의 리소스 점수가 음수이면 해당 노드에서 리소스를 실행할 수 없습니다.
Pacemaker 클러스터에서 제약 조건을 사용하여 클러스터의 결정을 조작할 수 있습니다. 제약 조건에는 점수가 있습니다. 제약 조건의 점수가 INFINITY
보다 낮으면 Pacemaker는 이 제약 조건을 권장 사항으로 간주합니다. INFINITY
점수는 필수입니다.
주 복제본과 가상 IP 리소스가 동일한 호스트에서 실행되는지 확인하려면 점수가 INFINITY인 공동 배치 제약 조건을 정의합니다. 공동 배치 제약 조건을 추가하려면 한 노드에서 다음 명령을 실행합니다.
RHEL 7
RHEL 7에서 ag_cluster
리소스를 만들 때 리소스를 ag_cluster-master
로 만듭니다. RHEL 7의 다음 명령을 사용합니다.
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
RHEL 8에서 ag_cluster
리소스를 만들 때 리소스를 ag_cluster-clone
로 만듭니다. RHEL 8의 다음 명령 형식을 사용합니다.
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
정렬 제약 조건 추가
공동 배치 제약 조건에는 암시적 정렬 제약 조건이 있습니다. 이 제약 조건은 가용성 그룹 리소스를 이동하기 전에 가상 IP 리소스를 이동합니다. 기본적으로 이벤트 시퀀스는 다음과 같습니다.
사용자가 node1에서 node2까지 가용성 그룹 주 복제본에 대해 pcs resource move
를 실행합니다.
노드 1에서 가상 IP 리소스가 중지됩니다.
노드 2에서 가상 IP 리소스가 시작됩니다.
참고
이때 노드 2는 여전히 장애 조치(failover) 전 보조 복제본이지만, IP 주소가 일시적으로 노드 2를 가리킵니다.
노드 1의 가용성 그룹 주 복제본이 보조 복제본으로 수준이 내려갑니다.
노드 2의 가용성 그룹 보조 복제본이 주 복제본으로 수준이 올라갑니다.
IP 주소가 일시적으로 장애 조치(failover) 이전 보조 복제본이 있는 노드를 가리키지 않도록 하려면 정렬 제약 조건을 추가합니다.
정렬 제약 조건을 추가하려면 한 노드에서 다음 명령을 실행합니다.
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Important
클러스터를 구성하고 가용성 그룹을 클러스터 리소스로 추가한 후에는 Transact-SQL을 사용하여 가용성 그룹 리소스를 장애 조치(failover)할 수 없습니다. Linux의 SQL Server 클러스터 리소스는 WSFC(Windows Server 장애 조치(failover) 클러스터)에 있을 때처럼 운영 체제와 긴밀하게 결합되지 않습니다. SQL Server 서비스는 클러스터의 현재 상태를 인식하지 못합니다. 모든 오케스트레이션이 클러스터 관리 도구를 통해 수행됩니다. RHEL 또는 Ubuntu에서는 pcs
를 사용하고 SLES에서는 crm
도구를 사용합니다.
pcs
를 사용하여 가용성 그룹을 수동으로 장애 조치(failover)합니다. Transact-SQL을 사용하여 장애 조치(failover)를 시작하지 않도록 합니다. 자세한 내용은 장애 조치(failover)를 참조하세요.
관련 콘텐츠
클러스터링 계층은 Pacemaker를 토대로 빌드된 SUSE HAE(고가용성 확장)를 기반으로 합니다.
클러스터 구성, 리소스 에이전트 옵션, 관리, 모범 사례 및 권장 사항에 대한 자세한 내용은 SUSE Linux Enterprise High Availability Extension을 참조하세요.
로드맵
고가용성을 위한 가용성 그룹을 만드는 절차는 Linux 서버와 Windows Server 장애 조치(failover) 클러스터 간에 차이가 있습니다. 다음 목록에서는 개괄적인 단계를 설명합니다.
클러스터 노드에서 SQL Server를 구성합니다.
가용성 그룹을 만듭니다.
Pacemaker와 같은 클러스터 리소스 관리자를 구성합니다. 이러한 지침은 이 문서에 포함되어 있습니다.
클러스터 리소스 관리자를 구성하는 방법은 특정 Linux 배포에 따라 다릅니다.
Important
프로덕션 환경에서는 고가용성을 위한 펜싱 에이전트가 필요합니다. 이 문서의 예시에서는 펜싱 에이전트를 사용하지 않습니다. 예시는 테스트 및 유효성 검사를 위해서만 제공됩니다.
Linux 클러스터는 펜싱을 사용하여 클러스터를 알려진 상태로 되돌립니다. 펜싱을 구성하는 방법은 배포 및 환경에 따라 달라집니다. 현재, 일부 클라우드 환경에서는 펜싱을 사용할 수 없습니다. 자세한 내용은 SUSE Linux Enterprise High Availability Extension을 참조하세요.
가용성 그룹을 클러스터의 리소스로 추가.
필수 구성 요소
다음 엔드투엔드 시나리오를 완료하려면 3노드 클러스터를 배포할 머신 3대가 필요합니다. 다음 단계에서는 이러한 서버를 구성하는 방법을 간략하게 설명합니다.
첫 번째 단계는 클러스터 노드에서 운영 체제를 구성하는 것입니다. 이 연습에서는 HA 추가 기능을 위한 유효한 구독이 있는 SLES 12 SP3을 사용합니다.
모든 노드에서 SQL Server 서비스를 설치하고 설정합니다. 자세한 내용은 SQL Server on Linux 설치 참고 자료를 참조하세요.
한 노드를 주 노드로, 다른 노드를 보조 노드로 지정합니다. 이 용어는 가이드 전체에서 사용됩니다.
클러스터에 포함하려는 노드가 서로 통신할 수 있는지 확인합니다.
다음 예시에서는 SLES1, SLES2, SLES3이라는 세 노드의 정보가 추가된 /etc/hosts
를 보여 줍니다.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
모든 클러스터 노드는 SSH를 통해 서로 액세스할 수 있어야 합니다. hb_report
또는 crm_report
(문제 해결용), Hawk의 History Explorer와 같은 도구에는 노드 간에 암호 없는 SSH 액세스가 필요합니다. 액세스 권한이 없으면 현재 노드에서만 데이터를 수집할 수 있습니다. 표준이 아닌 SSH 포트를 사용하는 경우 -X 옵션을 사용합니다(man
페이지 참조). 예를 들어 SSH 포트가 3479이면 다음을 사용하여 crm_report
를 호출합니다.
sudo crm_report -X "-p 3479" [...]
자세한 내용은 SLES Administration Guide - Miscellaneous(SLES 관리 가이드 - 기타) 섹션을 참조하세요.
Pacemaker용 SQL Server 로그인 만들기
주의
암호는 SQL Server 기본 암호 정책을 따라야 합니다. 기본적으로 암호는 8자 이상이어야 하며 대문자, 소문자, 0~9까지의 숫자 및 기호 네 가지 집합 중 세 집합의 문자를 포함해야 합니다. 암호 길이는 128자까지 가능하며 되도록 길고 복잡한 암호를 사용합니다.
모든 SQL Server 인스턴스에서 Pacemaker를 위한 서버 로그인을 만듭니다.
다음 Transact-SQL은 로그인을 만듭니다. <password>
를 사용자 고유의 복합 암호로 바꿉니다.
USE [master];
GO
CREATE LOGIN [pacemakerLogin]
WITH PASSWORD = N'<password>';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
가용성 그룹을 만든 이후, 노드를 추가하기 전에 pacemaker 사용자는 가용성 그룹에 대해 ALTER
, CONTROL
, VIEW DEFINITION
권한이 필요합니다.
모든 SQL Server 인스턴스에서 SQL Server 로그인을 위한 자격 증명을 저장합니다.
<password>
를 사용자 고유의 복합 암호로 바꿉니다.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo '<password>' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Linux 서버에서 가용성 그룹을 구성한 다음, 클러스터 리소스를 구성합니다. 가용성 그룹을 구성하려면 Linux에서 고가용성을 위한 SQL Server Always On 가용성 그룹 구성을 참조하세요.
고가용성 확장을 설치합니다.
참고자료는 SUSE Linux Enterprise Server 및 고가용성 확장 설치를 참조하세요.
두 노드에서 모두 SQL Server 리소스 에이전트 패키지를 설치합니다.
sudo zypper install mssql-server-ha
첫 번째 노드 설정
SLES 설치 지침을 참조하세요.
클러스터 노드로 사용할 물리적 머신 또는 가상 머신에 root
로 로그인합니다.
다음 명령을 실행하여 부트스트랩 스크립트를 시작합니다.
sudo ha-cluster-init
NTP가 부팅 시 시작되도록 구성되지 않은 경우 메시지가 표시됩니다.
계속하기로 결정하면 스크립트에서 자동으로 SSH 액세스 및 Csync2 동기화 도구용 키를 생성하고 둘 다에 필요한 서비스를 시작합니다.
클러스터 통신 계층(Corosync)을 구성합니다.
바인딩할 네트워크 주소를 입력합니다. 기본적으로 스크립트는 네트워크 주소 eth0을 제안합니다. 또는 다른 네트워크 주소(예: 주소 bond0)를 입력합니다.
멀티캐스트 주소를 입력합니다. 스크립트에서 사용할 수 있는 임의 주소를 기본값으로 제안합니다.
멀티캐스트 포트를 입력합니다. 스크립트는 5405를 기본값으로 제안합니다.
SBD ()
를 구성하려면 SBD에 사용하려는 블록 디바이스 파티션의 영구 경로를 입력합니다. 이 경로는 클러스터의 모든 노드에서 일치해야 합니다.
마지막으로, 스크립트는 Pacemaker 서비스를 시작하여 1노드 클러스터를 온라인 상태로 전환하고 웹 관리 인터페이스 Hawk2를 사용하도록 설정합니다. Hawk2에 사용할 URL이 화면에 표시됩니다.
설정 프로세스에 대한 자세한 내용은 /var/log/sleha-bootstrap.log
를 참조하세요. 이제 1노드 클러스터가 실행되고 있습니다. crm status를 사용하여 클러스터 상태를 확인합니다.
sudo crm status
crm configure show xml
또는 crm configure show
를 사용하여 클러스터 구성을 확인할 수도 있습니다.
부트스트랩 프로시저는 암호linux
로 명명된 hacluster
Linux 사용자를 만듭니다. 가능한 한 빨리 기본 암호를 안전한 암호로 바꿉니다.
sudo passwd hacluster
기존 클러스터에 노드 추가
하나 이상의 노드가 포함된 클러스터를 실행 중인 경우 ha-cluster-join 부트스트랩 스크립트를 사용하여 클러스터 노드를 더 추가합니다. 스크립트에 기존 클러스터 노드에 대한 액세스 권한만 있으면 현재 머신에서 기본 설정을 자동으로 완료합니다. 다음 단계를 사용합니다.
YaST
클러스터 모듈을 사용하여 기존 클러스터 노드를 구성한 경우 ha-cluster-join
을 실행하기 전에 다음 필수 조건이 충족되었는지 확인합니다.
클러스터에 참가해야 하는 물리적 머신 또는 가상 머신에 root
로 로그인합니다.
다음 명령을 실행하여 부트스트랩 스크립트를 시작합니다.
sudo ha-cluster-join
NTP가 부팅 시 시작되도록 구성되지 않은 경우 메시지가 표시됩니다.
계속하기로 결정하면 기존 노드의 IP 주소를 입력하라는 메시지가 표시됩니다. IP 주소를 입력합니다.
두 머신 간에 암호 없는 SSH 액세스를 아직 구성하지 않은 경우 기존 노드의 루트 암호를 입력하라는 메시지가 표시됩니다.
지정된 노드에 로그인하면 스크립트에서 Corosync 구성을 복사하고 SSH 및 Csync2
를 구성한 다음, 현재 머신을 온라인 상태로 전환하고 새 클러스터 노드로 표시합니다. 그 외에도 Hawk에 필요한 서비스를 시작합니다. OCFS2
를 사용하여 공유 스토리지를 구성한 경우 OCFS2
파일 시스템의 탑재 지점 디렉터리도 자동으로 생성됩니다.
클러스터에 추가하려는 모든 머신에 대해 이전 단계를 반복합니다.
프로세스에 대한 자세한 내용은 /var/log/ha-cluster-bootstrap.log
를 참조하세요.
sudo crm status
를 사용하여 클러스터 상태를 확인합니다. 두 번째 노드를 성공적으로 추가한 경우 출력이 다음과 같이 표시됩니다.
sudo crm status
다음 예시와 유사한 출력이 표시됩니다.
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
참고 항목
admin_addr
은 최초 1노드 클러스터 설정 중에 구성된 가상 IP 클러스터 리소스입니다.
모든 노드를 추가한 후에 전역 클러스터 옵션에서 no-quorum-policy를 조정해야 하는지 확인합니다. 이 작업은 2노드 클러스터에서 특히 중요합니다.
클러스터 속성 cluster-recheck-interval 설정
cluster-recheck-interval
은 클러스터에서 리소스 매개 변수, 제약 조건 또는 기타 클러스터 옵션의 변경 내용을 확인하는 폴링 간격을 나타냅니다. 복제본의 작동이 중단되면 클러스터는 failure-timeout
값과 cluster-recheck-interval
값을 통해 바인딩된 간격으로 복제본을 다시 시작하려고 합니다. 예를 들어 failure-timeout
을 60초로 설정하고 cluster-recheck-interval
을 120초로 설정한 경우 60초보다 크고 120초보다 작은 간격으로 다시 시작이 시도됩니다. failure-timeout을 60초로 설정하고 cluster-recheck-interval
을 60초보다 큰 값으로 설정하는 것이 좋습니다. cluster-recheck-interval
을 더 작은 값으로 설정하는 것은 권장되지 않습니다.
속성 값을 2 minutes
로 업데이트하려면 다음 명령을 실행합니다.
crm configure property cluster-recheck-interval=2min
Pacemaker 클러스터에서 관리하는 가용성 그룹 리소스가 이미 있는 경우, Pacemaker 패키지 1.1.18-11.el7에서는 해당 값이 false
일 때 start-failure-is-fatal
클러스터 설정 동작이 변경되었습니다. 이 변경 내용은 장애 조치(failover) 워크플로에 영향을 줍니다. 주 복제본이 중단될 경우 클러스터가 사용 가능한 보조 복제본 중 하나로 장애 조치(failover)되어야 합니다. 예상과 달리, 사용자는 클러스터가 실패한 주 복제본을 시작하려고 계속 시도하는 것을 보게 됩니다. 주 복제본이 영구 중단되어 온라인 상태로 전환되지 않는 경우 클러스터도 사용 가능한 다른 보조 복제본으로 장애 조치(failover)되지 않습니다. 이 변경 내용 때문에 start-failure-is-fatal
을 설정하는 이전 권장 구성은 더 이상 유효하지 않으며, 설정을 기본값인 true
로 되돌려야 합니다.
또한 failure-timeout
속성이 포함되도록 AG 리소스를 업데이트해야 합니다.
속성 값을 true
로 업데이트하려면 다음 명령을 실행합니다.
crm configure property start-failure-is-fatal=true
기존 AG 리소스 속성 failure-timeout
을 60s
로 업데이트하려면 다음 명령을 실행합니다(ag1
을 해당 가용성 그룹 리소스의 이름으로 바꿈).
crm configure edit ag1
텍스트 편집기에서 param
의 뒤와 op
앞에 meta failure-timeout=60s
를 추가합니다.
Pacemaker 클러스터 속성에 대한 자세한 내용은 클러스터 리소스 구성을 참조하세요.
여러 NIC(네트워크 인터페이스)에 대한 고려 사항
여러 NIC가 있는 서버에서 고가용성을 설정하는 경우 다음 제안 사항을 따르세요.
여러 NIC의 서버 IP 주소가 각 노드에서 Linux 서버의 호스트 이름으로 확인되도록 hosts
파일이 설정되어 있는지 확인합니다.
Pacemaker를 사용하여 클러스터를 설정할 때 서버의 호스트 이름을 사용하여 모든 NIC에 대한 구성을 설정하도록 Corosync를 구성해야 합니다. 단일 NIC를 통한 Pacemaker/Corosync 통신만 원합니다. Pacemaker 클러스터가 구성되면 corosync.conf
파일의 구성을 수정하고 Pacemaker/Corosync 통신에 사용할 전용 NIC의 IP 주소를 업데이트합니다.
corosync.conf
파일에 지정된 <hostname>
은 역방향 조회(ping -a <ip_address>
)를 수행할 때 지정된 출력과 동일해야 하며 호스트에 구성된 짧은 이름이어야 합니다. hosts
파일이 이름 확인에 적합한 IP 주소를 나타내는지도 확인합니다.
corosync.conf
파일 예시의 변경 내용은 아래에 강조 표시되어 있습니다.
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Pacemaker 클러스터 공급업체는 지원되는 클러스터 설정에 대해 구성된 펜싱 디바이스를 사용하여 장애가 발생한 노드를 펜싱해야 합니다. 클러스터 리소스 관리자가 노드 또는 노드의 리소스 상태를 확인할 수 없는 경우 펜싱은 클러스터를 다시 알려진 상태로 되돌립니다.
리소스 수준 펜싱은 주로 리소스를 구성하여 중단 시 데이터 손상이 발생하지 않도록 합니다. 예를 들어 DRBD(Distributed Replicated Block Device)에서 리소스 수준 펜싱을 사용하여 통신 링크의 작동이 중단될 경우 노드의 디스크를 오래된 것으로 표시할 수 있습니다.
노드 수준 펜싱은 노드가 리소스를 실행하지 않도록 합니다. 노드를 다시 설정하여 이 작업을 수행하며, 해당 Pacemaker 구현을 STONITH라고 합니다. Pacemaker는 서버에 대해 무정전 전원 공급 디바이스 또는 관리 인터페이스 카드와 같은 다양한 펜싱 디바이스를 지원합니다.
자세한 내용은 다음을 참조하세요.
클러스터 초기화 시 구성이 검색되지 않으면 펜싱이 사용하지 않도록 설정됩니다. 나중에 다음 명령을 실행하여 사용하도록 설정할 수 있습니다.
sudo crm configure property stonith-enabled=true
Important
펜싱을 사용하지 않도록 설정하는 기능은 테스트 목적으로만 제공됩니다. 프로덕션 환경에서 Pacemaker를 사용하려는 경우 해당 환경에 따라 펜싱 구현을 계획하고 사용 상태로 유지해야 합니다. SUSE는 클라우드 환경(Azure 포함) 또는 Hyper-V용 펜싱 에이전트를 제공하지 않습니다. 따라서 클러스터 공급업체도 이러한 환경에서 프로덕션 클러스터를 실행하기 위한 지원을 제공하지 않습니다. 이 문제의 해결 방법을 개발 중이며, 이후 릴리스에서 제공될 예정입니다.
SLES 관리 가이드를 참조하세요.
Pacemaker 사용
Pacemaker를 사용하도록 설정하여 자동으로 시작합니다.
클러스터의 모든 노드에서 다음 명령을 실행합니다.
systemctl enable pacemaker
가용성 그룹 리소스 만들기
다음 명령은 가용성 그룹 [ag1] 복제본 3개의 가용성 그룹 리소스를 만들고 구성합니다. 모니터링 작업 및 시간 제한은 SLES에서 명시적으로 지정해야 합니다. 시간 제한은 워크로드에 따라 큰 차이가 있으며 각 배포에 맞게 신중하게 조정해야 합니다.
클러스터의 노드 중 하나에서 명령을 실행합니다.
crm configure
를 실행하여 crm 프롬프트를 엽니다.
sudo crm configure
crm 프롬프트에서 다음 명령을 실행하여 리소스 속성을 구성합니다.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
가상 IP 리소스 만들기
ha-cluster-init
를 실행할 때 가상 IP 리소스를 만들지 않은 경우 지금 이 리소스를 만들 수 있습니다. 다음 명령은 가상 IP 리소스를 만듭니다. <0.0.0.0>
을 네트워크에서 사용 가능한 주소로 바꾸고, <24>
를 CIDR 서브넷 마스크의 비트 수로 바꿉니다. 한 노드에서 다음 명령을 실행합니다.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<0.0.0.0> \
cidr_netmask=<24>
공동 배치 제약 조건 추가
리소스를 실행할 위치 선택과 같은, Pacemaker 클러스터의 거의 모든 결정은 점수 비교를 통해 수행됩니다. 점수는 리소스별로 계산되며, Cluster Resource Manager는 특정 리소스에 대해 점수가 가장 높은 노드를 선택합니다. 노드의 리소스 점수가 음수이면 해당 노드에서 리소스를 실행할 수 없습니다. 제약 조건을 사용하여 클러스터의 결정을 조작할 수 있습니다. 제약 조건에는 점수가 있습니다. 제약 조건의 점수가 INFINITY보다 낮으면 권장 사항일 뿐입니다. 점수가 INFINITY이면 필수 항목입니다. 가용성 그룹의 주 복제본과 가상 IP 리소스가 동일한 호스트에서 실행되도록 하기 위해 점수가 INFINITY인 공동 배치 제약 조건을 정의합니다.
기본 노드와 동일한 노드에서 실행되도록 가상 IP에 대해 공동 배치 제약 조건을 설정하려면 한 노드에서 다음 명령을 실행합니다.
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
정렬 제약 조건 추가
공동 배치 제약 조건에는 암시적 정렬 제약 조건이 있습니다. 이 제약 조건은 가용성 그룹 리소스를 이동하기 전에 가상 IP 리소스를 이동합니다. 기본적으로 이벤트 시퀀스는 다음과 같습니다.
- 사용자가 node1에서 node2까지 가용성 그룹 주 복제본에 대해
resource migrate
를 실행합니다.
- 노드 1에서 가상 IP 리소스가 중지됩니다.
- 노드 2에서 가상 IP 리소스가 시작됩니다. 이때 노드 2는 여전히 장애 조치(failover) 전 보조 복제본이지만, IP 주소가 일시적으로 노드 2를 가리킵니다.
- 노드 1의 가용성 그룹 마스터가 수준이 내려갑니다.
- 노드 2의 가용성 그룹이 마스터로 수준이 올라갑니다.
IP 주소가 일시적으로 장애 조치(failover) 이전 보조 복제본이 있는 노드를 가리키지 않도록 하려면 정렬 제약 조건을 추가합니다.
정렬 제약 조건을 추가하려면 한 노드에서 다음 명령을 실행합니다.
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Important
클러스터를 구성하고 가용성 그룹을 클러스터 리소스로 추가한 후에는 Transact-SQL을 사용하여 가용성 그룹 리소스를 장애 조치(failover)할 수 없습니다. Linux의 SQL Server 클러스터 리소스는 WSFC(Windows Server 장애 조치(failover) 클러스터)에 있을 때처럼 운영 체제와 긴밀하게 결합되지 않습니다. SQL Server 서비스는 클러스터의 현재 상태를 인식하지 못합니다. 모든 오케스트레이션이 클러스터 관리 도구를 통해 수행됩니다. SLES에서는 crm
을 사용합니다.
crm
를 사용하여 가용성 그룹을 수동으로 장애 조치(failover)합니다. Transact-SQL을 사용하여 장애 조치(failover)를 시작하지 않도록 합니다. 자세한 내용은 장애 조치(failover)를 참조하세요.
자세한 내용은 다음을 참조하세요.
관련 콘텐츠
로드맵
고가용성을 위해 Linux 서버에서 가용성 그룹을 만드는 단계는 Windows Server 장애 조치(failover) 클러스터의 단계와 다릅니다. 다음 목록에서는 개괄적인 단계를 설명합니다.
SQL Server on Linux의 설치 지침
Linux에 고가용성을 위한 SQL Server Always On 가용성 그룹을 구성합니다.
Pacemaker와 같은 클러스터 리소스 관리자를 구성합니다. 이러한 지침은 이 문서에 포함되어 있습니다.
클러스터 리소스 관리자를 구성하는 방법은 특정 Linux 배포에 따라 다릅니다.
Important
프로덕션 환경에서는 고가용성을 위한 펜싱 에이전트가 필요합니다. 이 문서의 예시에서는 펜싱 에이전트를 사용하지 않습니다. 예시는 테스트 및 유효성 검사를 위해서만 제공됩니다.
Linux 클러스터는 펜싱을 사용하여 클러스터를 알려진 상태로 되돌립니다. 펜싱을 구성하는 방법은 배포 및 환경에 따라 달라집니다. 현재, 일부 클라우드 환경에서는 펜싱을 사용할 수 없습니다.
펜싱은 일반적으로 운영 체제에서 구현되며 환경에 따라 달라집니다. 운영 체제 배포자 문서에서 펜싱 지침을 확인합니다.
가용성 그룹을 클러스터의 리소스로 추가합니다.
모든 노드에서 방화벽 포트를 엽니다. Pacemaker 고가용성 서비스, SQL Server 인스턴스 및 가용성 그룹 엔드포인트에 대한 포트를 엽니다. SQL Server 실행 서버의 기본 TCP 포트는 1433
입니다.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
또는 방화벽을 사용하지 않도록 설정할 수 있지만 프로덕션 환경에서는 권장되지 않습니다.
sudo ufw disable
Pacemaker 패키지를 설치합니다. 모든 노드에서 Ubuntu 20.04에 대해 다음 명령을 실행합니다. 이전 버전에 설치하는 방법에 대한 자세한 내용은 Ubuntu HA - MS SQL Server on Azure를 참조하세요.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Pacemaker 및 Corosync 패키지를 설치할 때 생성된 기본 사용자의 암호를 설정합니다. 모든 노드에서 같은 암호를 사용합니다.
sudo passwd hacluster
클러스터 만들기
클러스터를 만들기 전에 주 서버에 인증 키를 만들고 AG에 참여하는 다른 서버에 복사해야 합니다.
다음 스크립트를 사용하여 주 서버에 인증 키를 만듭니다.
sudo corosync-keygen
scp
를 사용하여 생성된 키를 다른 서버에 복사할 수 있습니다.
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
클러스터를 만들려면 주 서버에서 /etc/corosync/corosync.conf
파일을 편집합니다.
sudo vim /etc/corosync/corosync.conf
corosync.conf
파일은 다음 예와 비슷합니다.
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
다른 노드의 corosync.conf
파일을 바꿉니다.
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
pacemaker
및 corosync
서비스를 다시 시작합니다.
sudo systemctl restart pacemaker corosync
클러스터 상태 및 구성을 확인합니다.
sudo crm status
여러 NIC(네트워크 인터페이스)에 대한 고려 사항
여러 NIC가 있는 서버에서 고가용성을 설정하는 경우 다음 제안 사항을 따르세요.
여러 NIC의 서버 IP 주소가 각 노드에서 Linux 서버의 호스트 이름으로 확인되도록 hosts
파일이 설정되어 있는지 확인합니다.
Pacemaker를 사용하여 클러스터를 설정할 때 서버의 호스트 이름을 사용하여 모든 NIC에 대한 구성을 설정하도록 Corosync를 구성해야 합니다. 단일 NIC를 통한 Pacemaker/Corosync 통신만 원합니다. Pacemaker 클러스터가 구성되면 corosync.conf
파일의 구성을 수정하고 Pacemaker/Corosync 통신에 사용할 전용 NIC의 IP 주소를 업데이트합니다.
corosync.conf
파일에 지정된 <hostname>
은 역방향 조회(ping -a <ip_address>
)를 수행할 때 지정된 출력과 동일해야 하며 호스트에 구성된 짧은 이름이어야 합니다. hosts
파일이 이름 확인에 적합한 IP 주소를 나타내는지도 확인합니다.
corosync.conf
파일 예시의 변경 내용은 아래에 강조 표시되어 있습니다.
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Pacemaker 클러스터 공급업체는 지원되는 클러스터 설정에 대해 구성된 펜싱 디바이스를 사용하여 장애가 발생한 노드를 펜싱해야 합니다. 클러스터 리소스 관리자가 노드 또는 노드의 리소스 상태를 확인할 수 없는 경우 펜싱은 클러스터를 다시 알려진 상태로 되돌립니다.
리소스 수준 펜싱은 가동 중단이 발생하는 경우 데이터 손상이 발생하지 않도록 합니다. 예를 들어 DRBD(Distributed Replicated Block Device)에서 리소스 수준 펜싱을 사용하여 통신 링크의 작동이 중단될 경우 노드의 디스크를 오래된 것으로 표시할 수 있습니다.
노드 수준 펜싱은 노드가 리소스를 실행하지 않도록 합니다. 노드를 다시 설정하여 이 작업을 수행하며, 해당 Pacemaker 구현을 STONITH라고 합니다. Pacemaker는 서버에 대해 무정전 전원 공급 디바이스 또는 관리 인터페이스 카드와 같은 다양한 펜싱 디바이스를 지원합니다.
자세한 내용은 Pacemaker 클러스터 기초 및 펜싱 및 Stonith를 참조하세요.
노드 수준 펜싱 구성은 사용자 환경에 따라 크게 좌우되므로 이 자습서에서는 사용하지 않도록 설정합니다(나중에 구성할 수 있음). 주 노드에서 다음 스크립트를 실행합니다.
sudo crm configure property stonith-enabled=false
이 예시에서 펜싱을 사용하지 않도록 설정하는 기능은 테스트 목적으로만 제공됩니다. 프로덕션 환경에서 Pacemaker를 사용하려는 경우 해당 환경에 따라 펜싱 구현을 계획하고 사용 상태로 유지해야 합니다. 특정 배포의 펜싱 에이전트에 대한 자세한 내용은 운영 체제 공급업체에 문의하세요.
클러스터 속성 cluster-recheck-interval 설정
cluster-recheck-interval
속성은 클러스터에서 리소스 매개 변수, 제약 조건 또는 기타 클러스터 옵션의 변경 내용을 확인하는 폴링 간격을 나타냅니다. 복제본의 작동이 중단되면 클러스터는 failure-timeout
값과 cluster-recheck-interval
값을 통해 바인딩된 간격으로 복제본을 다시 시작하려고 합니다. 예를 들어 failure-timeout
을 60초로 설정하고 cluster-recheck-interval
을 120초로 설정한 경우 60초보다 크고 120초보다 작은 간격으로 다시 시작이 시도됩니다. failure-timeout
을 60초로 설정하고, cluster-recheck-interval
을 60초보다 큰 값으로 설정해야 합니다. cluster-recheck-interval
을 더 작은 값으로 설정하는 것은 권장되지 않습니다.
속성 값을 2 minutes
로 업데이트하려면 다음 명령을 실행합니다.
sudo crm configure property cluster-recheck-interval=2min
Pacemaker 클러스터에서 관리하는 가용성 그룹 리소스가 이미 있는 경우, Pacemaker 패키지 1.1.18-11.el7에서는 해당 값이 false
일 때 start-failure-is-fatal
클러스터 설정 동작이 변경되었습니다. 이 변경 내용은 장애 조치(failover) 워크플로에 영향을 줍니다. 주 복제본이 중단될 경우 클러스터가 사용 가능한 보조 복제본 중 하나로 장애 조치(failover)되어야 합니다. 예상과 달리, 사용자는 클러스터가 실패한 주 복제본을 시작하려고 계속 시도하는 것을 보게 됩니다. 주 복제본이 영구 중단되어 온라인 상태로 전환되지 않는 경우 클러스터도 사용 가능한 다른 보조 복제본으로 장애 조치(failover)되지 않습니다. 이 변경 내용 때문에 start-failure-is-fatal
을 설정하는 이전 권장 구성은 더 이상 유효하지 않으며, 설정을 기본값인 true
로 되돌려야 합니다.
또한 failure-timeout
속성이 포함되도록 AG 리소스를 업데이트해야 합니다.
속성 값을 true
로 업데이트하려면 다음 명령을 실행합니다.
sudo crm configure property start-failure-is-fatal=true
기존 AG 리소스 속성 failure-timeout
을 60s
로 업데이트하려면 다음 명령을 실행합니다(ag1
을 해당 가용성 그룹 리소스의 이름으로 바꿈).
sudo crm configure meta failure-timeout=60s
Pacemaker와 연결하기 위해 SQL Server 리소스 에이전트 설치
모든 노드에서 다음 명령을 실행합니다.
sudo apt-get install mssql-server-ha
Pacemaker용 SQL Server 로그인 만들기
주의
암호는 SQL Server 기본 암호 정책을 따라야 합니다. 기본적으로 암호는 8자 이상이어야 하며 대문자, 소문자, 0~9까지의 숫자 및 기호 네 가지 집합 중 세 집합의 문자를 포함해야 합니다. 암호 길이는 128자까지 가능하며 되도록 길고 복잡한 암호를 사용합니다.
모든 SQL Server 인스턴스에서 Pacemaker를 위한 서버 로그인을 만듭니다.
다음 Transact-SQL은 로그인을 만듭니다. <password>
를 사용자 고유의 복합 암호로 바꿉니다.
USE [master];
GO
CREATE LOGIN [pacemakerLogin]
WITH PASSWORD = N'<password>';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
가용성 그룹을 만든 이후, 노드를 추가하기 전에 pacemaker 사용자는 가용성 그룹에 대해 ALTER
, CONTROL
, VIEW DEFINITION
권한이 필요합니다.
모든 SQL Server 인스턴스에서 SQL Server 로그인을 위한 자격 증명을 저장합니다.
<password>
를 사용자 고유의 복합 암호로 바꿉니다.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo '<password>' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
가용성 그룹 리소스 만들기
가용성 그룹 리소스를 만들려면 sudo crm configure
명령을 사용하여 리소스 속성을 설정합니다. 다음 예에서는 이름이 ag1
인 가용성 그룹에 대해 주/복제본 유형 리소스 ocf:mssql:ag
를 만듭니다.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
가상 IP 리소스 만들기
가상 IP 주소 리소스를 만들려면 한 노드에서 다음 명령을 실행합니다. 네트워크의 사용 가능한 고정 IP 주소를 사용합니다. 스크립트를 실행하기 전에 < ... >
사이의 값을 유효한 IP 주소로 바꿉니다.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
Pacemaker에는 해당하는 가상 서버 이름이 없습니다. 문자열 서버 이름을 가리키며 IP 주소를 사용하지 않는 연결 문자열을 사용하려면 DNS에 IP 리소스 주소와 원하는 가상 서버 이름을 등록합니다. DR 구성의 경우 기본 및 DR 사이트의 DNS 서버에 원하는 가상 서버 이름 및 IP 주소를 등록합니다.
공동 배치 제약 조건 추가
리소스를 실행할 위치 선택과 같은, Pacemaker 클러스터의 거의 모든 결정은 점수 비교를 통해 수행됩니다. 점수는 리소스별로 계산되며, Cluster Resource Manager는 특정 리소스에 대해 점수가 가장 높은 노드를 선택합니다. (노드의 리소스 점수가 음수이면 해당 노드에서 리소스를 실행할 수 없습니다.)
제약 조건을 사용하여 클러스터의 결정을 구성합니다. 제약 조건에는 점수가 있습니다. 제약 조건의 점수가 INFINITY보다 낮으면 권장 사항일 뿐입니다. INFINITY 점수는 필수 항목임을 의미합니다.
주 복제본과 가상 IP 리소스가 동일한 호스트에 있는지 확인하려면 점수가 INFINITY인 공동 배치 제약 조건을 정의합니다. 공동 배치 제약 조건을 추가하려면 한 노드에서 다음 명령을 실행합니다.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
정렬 제약 조건 추가
공동 배치 제약 조건에는 암시적 정렬 제약 조건이 있습니다. 이 제약 조건은 가용성 그룹 리소스를 이동하기 전에 가상 IP 리소스를 이동합니다. 기본적으로 이벤트 시퀀스는 다음과 같습니다.
사용자가 node1
에서 node2
까지 가용성 그룹 주 복제본에 대해 pcs resource move
를 실행합니다.
node1
에서 가상 IP 리소스가 중지됩니다.
node2
에서 가상 IP 리소스가 시작됩니다.
이때 node2
가 여전히 장애 조치(failover) 이전 보조 복제본이지만, IP 주소는 일시적으로 node2
를 가리킵니다.
node1
의 가용성 그룹 주 복제본이 보조로 강등됩니다.
node2
의 가용성 그룹 보조 복제본이 주 복제본으로 승격됩니다.
IP 주소가 일시적으로 장애 조치(failover) 이전 보조 복제본이 있는 노드를 가리키지 않도록 하려면 정렬 제약 조건을 추가합니다.
정렬 제약 조건을 추가하려면 한 노드에서 다음 명령을 실행합니다.
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
클러스터를 구성하고 가용성 그룹을 클러스터 리소스로 추가한 후에는 Transact-SQL을 사용하여 가용성 그룹 리소스를 장애 조치(failover)할 수 없습니다. Linux의 SQL Server 클러스터 리소스는 WSFC(Windows Server 장애 조치(failover) 클러스터)에 있을 때처럼 운영 체제와 긴밀하게 결합되지 않습니다. SQL Server 서비스는 클러스터의 현재 상태를 인식하지 못합니다. 모든 오케스트레이션이 클러스터 관리 도구를 통해 수행됩니다.
관련 콘텐츠