SIOS 기술, Nutanix Elevate 파트너 프로그램에 합류

SIOS 기술 공사. 에 회원임을 발표했다.Nutanix Elevate 파트너 프로그램, Nutanix AHV 환경 내의 중요한 애플리케이션을 위한 사용하기 쉬운 HA 클러스터링 솔루션을 제공하는 데 획기적인 이정표를 세웠습니다.

SIOS에 수여된 Nutanix Ready 검증 지정 완료는 SIOS를 입증합니다.생명의 수호자그리고데이터키퍼Nutanix 인프라와의 상호 운용성. 이번 검증의 일환으로 두 파트너는 공동 고객이 지속적인 혁신을 통해 이익을 얻을 수 있도록 협력하고 있습니다.

SIOS의 실적에는 전 세계적으로 설치된 80,000개 이상의 라이선스로 HA 및 DR을 활성화하여 다양한 산업 분야의 기업을 위한 애플리케이션을 보호하는 고객을 위한 성공적인 구현이 포함됩니다.

LifeKeeper 및 DataKeeper 제품은 검증 테스트를 완료하여 고객에게 솔루션의 호환성에 대한 확신을 더할 수 있습니다. Linux용 LifeKeeper를 통해 Nutanix는 심층적인 HA 전문 지식을 바탕으로 비즈니스 크리티컬 애플리케이션을 위한 간단하고 안정적인 HA를 고객에게 제공할 수 있습니다. SIOS 제품을 사용하면 SAP, HANA, SQL Server 및 SUSE Linux, Red Hat Linux, Oracle Linux, Rocky Linux 및 Windows Server에서 실행되는 기타 환경과 같이 본질적으로 복잡한 환경을 갖춘 Nutanix 고객은 구현, 유지 관리를 통해 시간을 절약하고 비용이 많이 드는 가동 중지 시간을 제거할 수 있습니다. , 안정적이고 신뢰할 수 있는 HA 환경을 관리합니다.

SIOS 글로벌 마케팅 부사장인 Margaret Hoagland는 다음과 같이 말했습니다. “Nutanix Elevate 파트너 프로그램에 참여하는 것은 강력한 HA 솔루션을 고객에게 제공하고, 범위를 확장하며, Nutanix 사용자에게 중단 없는 안정성과 단순성을 제공하려는 우리의 약속을 입증하는 것입니다. 중요한 애플리케이션을 위한 운영이 가능합니다.”

“Nutanix Ready Validated” 지정을 받은 SIOS 제품은 다음과 같습니다.

• Linux 9.8.0용 LifeKeeper
• Windows 8.10.0용 LifeKeeper
• Windows 8.10.0용 DataKeeper

LifeKeeper for Linux는 가장 광범위한 Linux OS 배포판, 버전 및 플랫폼에 HA를 제공합니다. 온프레미스, 가상, 클라우드. SIOS의 HA/DR 제품 포트폴리오에는 대역폭 효율적인 호스트 기반 블록 수준 복제, 애플리케이션 복구 키트(ARK)가 포함되어 있어 SAP, HANA 및 기타 널리 사용되는 데이터베이스 및 애플리케이션에 대한 애플리케이션 인식을 활성화할 뿐만 아니라 일반 사용자 정의 가능한 ARK도 가능합니다. LifeKeeper for Linux는 애플리케이션, 데이터베이스 및 스토리지에 대한 자동화된 모니터링, 문제 감지 및 지능형 복구를 제공하여 중요한 시스템과 애플리케이션의 가용성을 높게 유지합니다.

SIOS-Nutanix 솔루션에 대해 자세히 알아보기

단계별 – OCI의 SQL Server 2019 FCI(장애 조치 클러스터 인스턴스)

소개

OCI(Oracle Cloud Infrastructure)에 비즈니스 크리티컬 애플리케이션을 배포하는 경우 최적의 가동 시간과 안정성을 위해 OCI에서 제공하는 가용성 SLA(서비스 수준 계약)를 이해하고 활용하는 것이 중요합니다. OCI의 SLA는 선택한 배포 전략에 따라 달라집니다.

가용성 도메인 전반에 걸친 배포:OCI는 동일한 OCI 지역 내의 서로 다른 가용성 도메인에 두 개 이상의 가상 머신(VM)을 배포할 때 99.99% 가용성 SLA를 제공합니다.

장애 도메인 전반에 걸친 배포:오류 도메인 전체에 VM을 배포하는 경우 OCI는 99.95% 가용성 SLA를 제공합니다. 모든 OCI 지역에 여러 가용성 도메인이 있는 것은 아니므로 일부 지역에서는 오류 도메인을 통한 배포가 유일한 옵션이라는 점에 유의하는 것이 중요합니다.

단일 VM 배포:단일 VM이 포함된 배포의 경우 SLA는 99.9%입니다.

이 프레임워크는 OCI가 VM 배포 방법에 따라 특정 수준의 외부 연결을 보장한다는 것을 의미합니다.

SLA는 VM 자체의 가용성을 다루지 VM에서 실행되는 애플리케이션이나 서비스를 다루지 않는다는 점에 유의하는 것이 중요합니다. 애플리케이션 가용성을 보장하려면 애플리케이션 모니터링, 복구 계획, 데이터 복제 및 트랜잭션 복제(SQL Server와 같은 데이터베이스의 경우)와 같은 추가 조치가 필요합니다. 전략에는 애플리케이션 가용성을 효과적으로 관리하기 위한 로드 밸런싱, 클러스터링 또는 데이터 복제가 포함될 수 있습니다.

OCI에서 99.99% 가용성 SLA 기준을 충족하려면 여러 가용성 도메인에 VM을 배포하는 것이 중요합니다. 이 게시물은 가용성 도메인에 걸쳐 SQL Server 장애 조치 클러스터 인스턴스를 촉진하여 중요한 비즈니스 애플리케이션에 대한 최대 가동 시간과 안정성을 보장하기 위해 OCI 인프라를 설계하는 방법을 안내합니다.

VCN 및 서브넷 생성

이 가이드에서는 귀하가 OCI(Oracle Cloud Infrastructure)에 대해 어느 정도 잘 알고 있고 네트워킹 개념에 대한 기본적인 이해가 있다고 가정합니다. 설명과 함께 일반적인 구성 작업을 설명하고 필요한 경우 OCI 네트워킹에서 직면하는 몇 가지 일반적인 문제를 탐색하기 위한 추가 지침을 제공합니다.

잘 계획된 네트워크 계획으로 시작하는 것이 중요합니다. 이 문서에서는 클라우드 네트워크 계획의 복잡성을 다루지 않으므로 다음 예는 여러 가능성 중 하나로 간주되어야 합니다. 네트워크 구성은 크게 다를 수 있습니다. 그러나 중요한 고려 사항은 각 클러스터 노드에 하나를 할당하고 파일 공유 감시에 다른 하나를 할당하여 최소 3개의 가용성 도메인 사용을 계획하는 것입니다. 클러스터링에 필요한 중요한 점은 각 가용성 도메인이 서로 다른 서브넷에 있어야 한다는 것입니다.

가용성 도메인 대신 오류 도메인에 걸쳐 있는 구성을 다루지는 않지만, 오류 도메인에 걸쳐 있는 클러스터에도 동일하게 적용됩니다. 즉, 모든 노드가 서로 다른 서브넷에 있어야 합니다.

우리 시나리오에서는 OCI의 단일 가상 클라우드 네트워크(VCN) 내에서 서로 다른 3개의 가용성 도메인에 걸쳐 3개의 서브넷을 설정합니다.

VCN: 10.0.0.0/16

• AD1: 10.0.0.0/18
• AD2: 10.0.64.0/18
• AD3: 10.0.128.0/18

OCI의 사용자 인터페이스는 변경될 수 있지만 작성 당시에는 OCI 콘솔에서 새 VCN과 3개의 서브넷을 생성하는 프로세스가 간단했습니다. 구체적인 내용은 OCI 설명서나 VCN 및 서브넷 생성에 필요한 단계를 안내하는 사용자 인터페이스를 통해 확인할 수 있습니다.

VCN 생성

VCN에 3개의 서브넷을 생성합니다.

인터넷 게이트웨이 만들기

인터넷 게이트웨이는 인스턴스가 인터넷에 액세스하는 방법입니다. 네트워크에서 인스턴스가 인터넷에 액세스하는 것을 원하지 않을 수도 있지만, 이 예에서는 이를 활성화하고 기본 라우팅 테이블에 추가하겠습니다.

기본 보안 목록 편집

경로 테이블 편집

VCN 외부로 향하는 모든 트래픽이 인터넷 게이트웨이를 통해 라우팅되도록 라우팅 테이블을 편집합니다.

네트워크 보안 그룹 만들기

보안 목록 편집

이러한 설정을 사용하면 가용성 도메인 전반에 걸쳐 자유로운 액세스가 가능하며 어디에서나 RDP 액세스가 가능합니다. 인스턴스에 RDP할 수 있는 IP 주소를 제한하거나 공용 네트워크에서 RDP 액세스에만 사용되는 “점프 VM”을 설정하는 것을 고려할 수도 있습니다.

DHCP 옵션 편집

Active Directory가 올바르게 작동하려면 아래와 같이 DHCP 옵션에서 DC1을 기본 DNS 서버로 설정해야 합니다. 이 경우 구성 중인 도메인 컨트롤러의 고정 IP인 10.0.0.100으로 설정했습니다. 또한 사용자 정의 검색 도메인에 도메인을 추가해야 합니다. 이 경우 나중에 도메인 컨트롤러를 구성할 때 구축할 datakeeper.local이라는 도메인을 사용합니다.

VM 프로비저닝

이제 VCN이 구성되었으므로 VM 프로비저닝을 시작할 차례입니다. 이 예에서는 Windows Server 2022 및 SQL Server 2019를 사용하겠습니다. 그러나 이 문서에 설명된 단계는 모든 버전의 Windows Server 및 SQL Server에서 거의 동일하므로 버전에 관계없이 문제가 발생하지 않습니다. 사용하려는 Windows 또는 SQL Server.

시작하기 전에 계획부터 시작하는 것이 다시 한 번 중요합니다. 이 경우 서버 이름, IP 주소 및 해당 가용성 영역 배치를 계획해야 합니다. 앞서 언급한 것처럼 각 클러스터 노드와 파일 공유 감시는 각각 서로 다른 가용성 영역에 있어야 합니다.

예제 구성에서는 파일 공유 감시 역할도 하는 인스턴스(DC1)에 활성 디렉터리를 배포합니다.

AD1 – DC1 (10.0.0.100)

AD2 – SQL1 – (10.0.64.100, 10.0.64.101, 10.0.64.102)

AD3 – SQL2 – (10.0.128.100, 10.0.128.101, 10.0.128.102)

각 클러스터 노드(SQL1, SQL2)에는 3개의 IP 주소가 있음을 알 수 있습니다. 첫 번째 주소는 인스턴스의 프라이빗 IP 주소입니다. 다른 두 IP 주소는 각 인스턴스에 보조 주소로 추가됩니다. 이러한 IP 주소는 핵심 클러스터 IP 주소 및 SQL Server FCI 네트워크 이름 리소스와 연결된 가상 IP 주소를 설명합니다.

클러스터 노드를 프로비전할 때 SQL Server 소프트웨어가 포함되지 않은 기본 Windows Server 2022 이미지를 사용합니다. 대신 우리는 SQL Server 설치 미디어를 다운로드하고 Marketplace에서 제공되는 “종량제” 라이선스 대신 영구 SQL Server 라이선스를 사용합니다.

다음 섹션에서는 이 예에 사용된 세 개의 VM을 프로비저닝하는 프로세스를 보여줍니다.

FD1에 DC1 프로비저닝

인스턴스 유형을 선택할 때 워크로드에 맞게 크기를 조정해야 합니다. 이는 온프레미스에서 사용하기 위해 물리적 서버의 크기를 조정하는 경우 수행할 작업과 비슷하지만 처음으로 초과 프로비저닝하거나 부족하게 프로비저닝하거나 워크로드가 부족한 경우 크기를 쉽게 조정할 수 있다는 차이점이 있습니다. 시간이 지남에 따라 증가하거나 감소합니다.

인스턴스 세부 정보를 지정할 때 적절한 배치를 위해 올바른 VCN과 서브넷을 선택했는지 확인하십시오. 이 첫 번째 화면에서는 이 인스턴스와 연결하려는 고정 IP도 지정합니다.

FD2에 SQL1 프로비저닝

앞서 설명한 대로 이 예에서는 Windows Server 2022의 기본 설치를 사용합니다. SQL Server 2019는 나중에 다운로드하여 SQL Server FCI 설치에 사용됩니다.

FD3에 SQL2 프로비저닝

추가 볼륨 추가

클러스터의 각 서버에는 하나 이상의 추가 볼륨이 필요합니다. 이러한 볼륨은 SQL Server FCI의 스토리지 요구 사항에 중요하며 SIOS DataKeeper에 의해 복제됩니다.

여러 볼륨

여러 볼륨을 추가하여 데이터, 로그 및 백업을 분리할 수 있습니다.

저장소 유형: 다양한 요구 사항에 맞게 다양한 저장소 유형을 사용할 수 있습니다.

부착 방법

서버에 스토리지를 연결하는 방법에는 여러 가지가 있습니다.

예시 구성

아래에는 가능한 많은 스토리지 구성 중 하나를 보여주는 화면 캡처가 포함되어 있습니다. 이는 설정 프로세스를 이해하는 데 도움이 되는 실제 예입니다. 이 프로세스는 SQL1 및 SQL2에서 완료되어야 합니다.

블록 볼륨 생성

먼저 SQL1 및 SQL2에 적합한 가용성 도메인에 블록 볼륨을 생성합니다.

볼륨 연결

이제 볼륨이 생성되었으므로 이를 인스턴스에 연결해야 합니다.

기억해야 할 핵심 사항

설정은 유연합니다. 특정 요구 사항에 따라 하나 이상의 볼륨을 구성할 수 있습니다.

구성에 사용할 수 있는 다양한 저장소 유형과 연결 방법을 고려하세요.

보조 IP 주소 추가

OCI에서 Windows Server 장애 조치 클러스터링이 제대로 작동하려면 SQL1 및 SQL1에 연결된 VNIC(가상 네트워크 인터페이스)에 클러스터 IP 주소를 보조 주소로 추가해야 합니다. 기억하시겠지만, 각 클러스터 노드에서 다음 IP 주소를 사용하는 방법에 대해 논의했습니다.

	SQL1	SQL2
기본 주소	10.0.64.100	10.0.128.100
클러스터 IP 1(핵심 클러스터 리소스)	10.0.64.101	10.0.128.101
클러스터 IP 2(SQL Server 클러스터 IP)	10.0.64.102	10.0.128.102

SQL1과 SQL2 모두에서 연결된 VNIC를 편집하여 보조 주소를 추가합니다.

도메인 생성

복원력을 위해 다양한 가용성 영역에 걸쳐 여러 AD 컨트롤러를 프로비저닝해야 하지만, 이 가이드에서는 하나의 AD 컨트롤러만 프로비저닝하겠습니다. DC1에서 AD를 구성하려면 아래 스크린샷을 따르세요.

인스턴스 세부 정보 섹션에 나열된 자격 증명을 사용하여 로그온합니다. 비밀번호를 재설정하라는 메시지가 표시됩니다.

Active Directory 도메인 서비스 활성화

서버를 도메인 컨트롤러로 승격

이 프로세스를 시작하기 전에 서버에서 로컬 관리자 계정을 활성화하고 비밀번호를 설정하십시오. 그렇지 않으면 도메인 컨트롤러 수준을 올리려고 할 때 이 메시지를 받게 됩니다.

관리자 계정을 활성화하고 비밀번호를 설정한 후 배포 후 구성을 진행하세요.

Active Directory 도메인 서비스를 활성화하기 전에 로컬 관리자 계정을 활성화하고 해당 계정으로 로그온해야 합니다.

선호하는 RDP 프로그램을 사용하여 인스턴스와 연결된 공용 IP 주소를 사용하여 DC1에 연결합니다. Active Directory 도메인 서비스 역할을 추가합니다.

설치가 완료되면 이 서버를 도메인 컨트롤러로 승격합니다.

우리의 목적을 위해 우리는 새로운 도메인을 만들 예정입니다.

DC1을 재부팅하고 다음 섹션으로 이동합니다.

SQL1 및 SQL2를 도메인에 가입

저장소 준비

SQL1 및 SQL2가 도메인에 추가되면 생성한 도메인 관리자 계정으로 인스턴스에 연결하여 나머지 구성 단계를 완료합니다. 가장 먼저 해야 할 일은 아래와 같이 SQL1과 SQL2에 추가한 EBS 볼륨을 연결하고 포맷하는 것입니다.

장애 조치 클러스터링 기능 구성

SQL1과 SQL2 모두에서 장애 조치 클러스터링 기능을 활성화합니다.

SQL1 및 SQL2에서 이 PowerShell 명령을 실행하세요.

Install-WindowsFeature -이름 장애 조치-클러스터링 -IncludeManagementTools

클러스터 검증

SQL1 또는 SQL2에서 이 PowerShell 명령을 실행하세요.

테스트 클러스터 -노드 sql1,sql2

사용 중인 Windows Server 버전에 따라 네트워크 및 저장소에 대한 몇 가지 경고가 표시됩니다. 네트워크 경고는 단일 인터페이스를 통해 각 클러스터 노드에 액세스할 수 있음을 알려줍니다. 이전 버전의 Windows에서는 공유 저장소가 부족하다는 경고를 표시합니다.

OCI에서 호스팅되는 클러스터에서 예상되는 오류는 모두 무시할 수 있습니다. 오류가 수신되지 않는 한 다음 섹션을 진행할 수 있습니다. 오류가 발생하면 수정한 후 유효성 검사를 다시 실행하고 다음 섹션을 계속 진행하세요.

클러스터 생성

다음으로 클러스터를 생성합니다. 아래 예에서는 사용하려고 계획한 두 개의 IP 주소인 10.0.64.101과 10.0.128.101을 사용하고 있음을 알 수 있습니다. 두 클러스터 노드 중 하나에서 이 Powershell을 실행할 수 있습니다.

새 클러스터 – 이름 Cluster1 – 노드 sql1,sql2 -StaticAddress 10.0.64.101, 10.0.128.101

참고하세요:WSFC GUI를 통해 클러스터를 생성하려고 시도하지 마십시오. 인스턴스가 DHCP를 사용하기 때문에 GUI는 클러스터에 IP 주소를 할당하는 옵션을 제공하지 않고 대신 중복 IP 주소를 전달한다는 것을 알게 될 것입니다.

파일 공유 감시 추가

클러스터 쿼럼을 유지하려면 감시를 추가해야 합니다. OCI에서 사용하려는 감시 유형은 파일 공유 감시입니다. 파일 공유 감시는 두 클러스터 노드가 아닌 다른 오류 도메인에 있는 서버에 있어야 합니다.

아래 예에서는 FD1에 있는 DC1에 파일 공유 감시가 생성됩니다.

DC1에서 파일 공유를 만들고 폴더에 대한 CNO(클러스터 이름 개체) 읽기-쓰기 권한을 할당합니다. 생성한 폴더의 공유 및 보안 탭 모두에서 CNO에 대한 권한을 추가합니다. 아래 예에서는 “Witness”라는 폴더를 생성했습니다.

폴더가 생성되고 CNO에 적절한 권한이 할당되면 SQL1 또는 SQL2에서 다음 PowerShell 명령을 실행합니다.

Set-ClusterQuorum -Cluster Cluster1 -FileShareWitness \\dc1\Witness

이제 SQL1 또는 SQL2에서 장애 조치 클러스터 관리자를 시작할 때 클러스터는 다음과 같아야 합니다.

SQL Server FCI 만들기

DataKeeper 클러스터 에디션 설치

다음 단계로 진행하기 전에 SQL1과 SQL2 모두에 DataKeeper Cluster Edition을 설치해야 합니다. 설치 실행 파일을 다운로드하고 두 노드 모두에서 DataKeeper 설치를 실행합니다. 다음을 참조하세요.SIOS 문서설치에 대한 구체적인 지침은 다음과 같습니다.

DataKeeper 볼륨 리소스 생성

클러스터 노드 중 하나에서 DataKeeper UI를 실행하고 아래와 같이 DataKeeper 볼륨 리소스를 생성합니다.

두 서버(먼저 SQL1, 그 다음 SQL2)에 연결합니다.

두 서버 모두에 연결했고 스토리지가 올바르게 구성된 경우 서버 개요 보고서는 다음과 같아야 합니다.

작업 생성을 클릭하여 작업 생성 마법사를 시작합니다.

DataKeeper는 동기식 복제와 비동기식 복제를 모두 지원합니다. 동일한 지역의 가용성 영역 간 복제의 경우 동기를 선택합니다. 여러 지역 또는 클라우드 제공자 간에 복제하려면 비동기식을 선택하세요.

클러스터의 사용 가능한 저장소에 DataKeeper 볼륨 리소스를 등록하려면 여기에서 “예”를 클릭하세요.

The DataKeeper Volume D now appears in Failover Cluster Manager in Available Storage.

SQL1에 SQL Server FCI의 첫 번째 노드 설치

이제 핵심 클러스터가 생성되었고 DataKeeper 볼륨 리소스가 사용 가능한 저장소에 있으므로 첫 번째 클러스터 노드에 SQL Server를 설치할 차례입니다. 앞서 언급한 것처럼 여기 예제에서는 SQL 2019 및 Windows 2022를 사용하는 클러스터 구성을 보여 주지만 배포하려는 Windows Server 또는 SQL Server 버전에 관계없이 이 예제에 설명된 모든 단계는 사실상 동일합니다.

SQL1에 SQL Server를 설치하려면 아래 예를 따르십시오.

아래에 지정하는 이름은 클라이언트 액세스 포인트입니다. 이는 애플리케이션 서버가 SQL Server FCI에 연결하려고 할 때 사용할 이름입니다.

이 화면에서는 앞서 계획 섹션에서 식별한 SQL1 보조 IP 주소를 추가합니다.1 부이 시리즈의.

이 예에서는 D 드라이브에 tempdb를 남겨 두었습니다. 그러나 최상의 성능을 위해서는 복제되지 않은 볼륨에 tempdb를 배치하는 것이 좋습니다.

SQL2에 SQL Server FCI의 두 번째 노드를 설치합니다.

이제 SQL2에 SQL Server를 설치할 차례입니다.

두 클러스터 노드 모두에 SQL Server를 설치하면 장애 조치 클러스터 관리자가 다음과 같아야 합니다.

SQL Server 관리 스튜디오 설치

SQL Server 버전 2016 이상에서는 아래와 같이 SSMS를 별도의 옵션으로 다운로드하여 설치해야 합니다. 참고: 이전 버전의 SQL Server에서는 SSMS(SQL Server Management Studio)가 SQL 설치 중에 설치하도록 선택할 수 있는 옵션이었습니다.

SSMS가 설치되면 클라이언트 액세스 포인트를 통해 클러스터에 연결합니다. SQL Server FCI는 다음과 같아야 합니다.

다중 서브넷 고려 사항

OCI에서 SQL Server FCI를 실행할 때 가장 큰 고려 사항 중 하나는 클러스터 노드가 서로 다른 서브넷에 상주한다는 사실입니다. Microsoft는 Microsoft 설명서에 설명된 대로 Windows Server 2008 R2에 “OR” 기능을 추가하여 클러스터 노드가 다른 서브넷에 있을 수 있다는 사실을 고려하기 시작했습니다.선적 서류 비치.

에서 가져옴SQL Server 다중 서브넷 클러스터링(SQL Server)

설명서에 설명된 중요한 사항은 SQL Server FCI를 만들 때 기본적으로 활성화되는 네트워크 이름 리소스의 RegisterAllProvidersIP 개념입니다. 설명된 대로 이 기능이 활성화되면 두 개의 A 레코드가 네트워크 이름 리소스를 사용하여 각 IP 주소에 대해 하나씩 DNS에 등록됩니다.

“OR” 기능을 사용하면 활성 서브넷과 연결된 IP 주소만 온라인 상태가 되고 다른 IP 주소는 오프라인으로 표시됩니다. 클라이언트가 연결 문자열에 multisubnetfailover=true 추가를 지원하는 경우 두 IP 주소가 동시에 시도되고 클라이언트는 자동으로 활성 노드에 연결됩니다. 이는 다중 서브넷 클러스터에서 클라이언트 리디렉션의 가장 쉬운 기본 방법입니다.

문서에는 클라이언트가 multisubnetfailover=true 기능을 지원하지 않는 경우 “각 추가 IP 주소에 대해 클라이언트 연결 문자열의 연결 시간 제한을 21초씩 조정해야 합니다.”라고 나와 있습니다. 이렇게 하면 다중 서브넷 FCI의 모든 IP 주소를 순환할 수 있기 전에 클라이언트의 재연결 시도가 시간 초과되지 않습니다.”

RegisterAllProvidersIP를 비활성화하는 것도 작동하는 또 다른 옵션입니다. RegisterAllProvidersIP를 비활성화하면 DNS에 단일 A 레코드만 남게 됩니다. DNS A 레코드는 클러스터가 이름 리소스와 연결된 활성 클러스터 IP 주소로 장애 조치될 때마다 업데이트됩니다.

이 시나리오 구성의 단점은 클라이언트가 TTL(Time to Live)이 만료될 때까지 이전 IP 주소를 캐시한다는 것입니다. 재연결 지연을 최소화하려면 이름 리소스의 TTL을 변경하는 것이 좋습니다. 이 과정이 설명되어 있습니다여기아래에는 TTL을 5분으로 설정하는 예가 나와 있습니다.

Get-ClusterResource -이름 sqlcluster | Set-ClusterParameter – 이름 HostRecordTTL – 값 300

AD 통합 DNS 서버의 변경 사항이 전체 포리스트에 전파되는 데에도 시간이 걸릴 수 있다는 점을 명심하세요.

요약

이 기술 가이드는 OCI(Oracle Cloud Infrastructure)에서 SQL Server 2019 FCI(장애 조치 클러스터 인스턴스) 설정에 대한 포괄적인 개요를 제공합니다. 먼저 배포 전략에 따라 달라지는 OCI의 가용성 SLA(가용성 도메인 전체 배포의 경우 99.99%, 오류 도메인 전체의 99.95%, 단일 VM 배포의 경우 99.9%)를 이해하는 것이 중요하다는 점을 강조합니다. 이 가이드에서는 SLA가 VM 가용성을 다루지 VM에서 실행되는 애플리케이션이나 서비스를 다루지 않으므로 애플리케이션 가용성에 대한 추가 조치가 필요하다는 점을 강조합니다.

이 가이드에서는 OCI에서 VCN(가상 클라우드 네트워크) 및 서브넷을 생성하는 초기 단계를 자세히 설명하고 클러스터링 목적으로 최소 3개의 가용성 도메인을 수용하는 네트워크 계획의 필요성을 강조합니다. 각 가용성 도메인은 서로 다른 서브넷에 있어야 하며 이는 장애 도메인에 걸쳐 있는 클러스터에도 적용되는 요구 사항입니다. 단일 VCN 내의 서로 다른 가용성 도메인에 걸쳐 3개의 서브넷을 설정하기 위한 특정 구성을 제공합니다.

또한 이 가이드에서는 가용성 도메인 전반에 걸쳐 액세스와 보안을 용이하게 하기 위해 인터넷 게이트웨이를 생성하고 기본 보안 목록과 라우팅 테이블을 편집하는 프로세스를 설명합니다. 또한 Active Directory 호환성을 위한 DHCP 옵션 구성을 다루고 Windows Server 2022 및 SQL Server 2019로 VM을 프로비저닝하는 단계를 간략하게 설명하며 서버 이름, IP 주소 및 가용성 영역 배치 계획의 중요성을 강조합니다.

그런 다음 가이드에서는 SQL Server FCI 스토리지 요구 사항에 맞게 추가 볼륨을 추가하는 방법을 살펴보고 블록 볼륨을 생성하고 인스턴스에 연결하는 프로세스를 자세히 설명합니다. 또한 OCI에서 Windows Server 장애 조치 클러스터링을 위한 보조 IP 주소를 구성하는 방법에 대해 설명합니다.

다음으로 이 가이드에서는 Active Directory 도메인 서비스 활성화 및 서버를 도메인 컨트롤러로 승격시키는 등 도메인 컨트롤러 설정에 대해 설명합니다. 클러스터 유효성 검사 및 생성 프로세스와 함께 저장소를 준비하고 SQL1 및 SQL2에서 장애 조치 클러스터링 기능을 활성화하는 과정을 안내합니다.

이 가이드에서는 클러스터 쿼럼을 유지하기 위해 파일 공유 감시를 추가하고 볼륨 복제를 위해 DataKeeper Cluster Edition을 설치하는 방법에 대해 자세히 설명합니다. 다중 서브넷 배포에 대한 고려 사항과 함께 클러스터 노드 및 SQL Server Management Studio에 SQL Server를 설치하는 단계별 접근 방식을 제공합니다.

요약하면, 이 가이드는 OCI에서 SQL Server 2019 FCI를 배포 및 구성하기 위한 자세한 청사진을 제공하며 네트워크 설정 및 VM 프로비저닝부터 클러스터링, 스토리지 구성 및 도메인 제어 설정까지 다양한 측면을 다루며 비즈니스에 중요한 애플리케이션의 최대 가동 시간과 안정성을 보장합니다. .

여기에서 단계별 가이드를 다운로드하세요.

다음의 허가를 받아 복제됨시오스

올바른 고가용성 솔루션을 선택하기 위한 4가지 팁

고가용성과 Lebron은 GOAT(역사상 가장 위대한) 논쟁입니다.

나는 Spades에서지고있었습니다. 나는 Kahoot에서지고있었습니다. 나는 농구 경기에서 모두 같은 우호적 경쟁자인 Brandon에게 지고 있었습니다. 그래서 그의 주의를 분산시키기 위해 나는 다시 토론하러 갔습니다. “르브론은 역대 최고입니다!” 긴장으로 가득 찬 다음 순간은 마이클 조던, 줄리어스 어빙, 윌트 체임벌린, 밥 쿠지, 샤크, 빌 러셀, 제리 웨스트, 스테판 커리, 케빈 듀란트, 코비 브라이언트 등 농구계의 위대한 선수들의 이름이 곁들여진 호언장담으로 가득 찼습니다. , 매직 앤 워디, 르브론. 그는 “어찌 르브론이 최고라고 말할 수 있겠는가, 코비는 킬러 본능을 갖고 있다”며 시합을 벌였다. 우리의 말다툼은 요구 사항이 무엇인지, 누군가를 위대한 대화의 일부로 만드는 것, 심지어 토론의 일부 후보로 만드는 것까지 확장될 것입니다. 장수, 득점 기록, 수비 능력, 기타 칭찬과 영예가 필요합니까? 최소한 몇 개의 MVP 상을 받아야 합니까? 그들의 시대의 초월성은 어떻습니까? 이것저것은 어떻습니까? 물론 내 친구 Brandon은 항상 제목을 빨리 제시합니다!

최고의 고가용성 솔루션을 선택하는 방법

그런데, 이게 무슨 상관이지?고가용성? 물어봐서 다행이에요. 수많은 경쟁자 중에서 최고의 가용성이나 더 높은 가용성의 솔루션을 제공하거나 선택하라는 요청을 얼마나 자주 받았습니까? 계획되지 않은 애플리케이션 충돌 또는 프로덕션 서버 다운으로 인해 망가진 지난 주말을 자동화된 모니터링 및 복구의 부족으로 망가질 마지막 주말로 결정했습니다. 그러나 Microsoft Failover Clustering, SuSE High Availability Extensions, PaceMaker, NEC ClusterPro, vWare HA, SIOS Protection Suite 및 SIOS AppKeeper와 같은 훌륭한 이름 중에서 어떤 솔루션이 가장 좋습니까? Greatest Of All Time에 대한 논쟁에서 내가 배운 네 가지 사항은 가용성이 높고 가용성이 높은 문제를 해결하는 데 도움이 될 것입니다.

HA 요구 사항

첫째, 요구사항은 무엇입니까? 역대 최고의 순수 슈팅 게임을 원한다면 쉽고 쉽게 스테판 커리를 포함시킬 것입니다. 가장 위협적인 물리적 존재감을 원한다면 Shaq 같은 사람과 함께 갈 것입니다. 최고의 팀 동료, 어시스트 리더 또는 뛰어난 선수가 필요하다면 르브론 제임스, 매직 존슨, 제리 웨스트, 래리 버드가 대화에 참여한다고 생각합니다. 마찬가지로 HA 솔루션 가동을 시작하기 전에 필요한 것이 무엇인지 이해하십시오. ~이다데이터 복제필수인가요, 선택인가요? 당신이 필요로 할SQL아니면 다른 데이터베이스를 사용할 의향이 있습니까? 다른 어떤 응용 프로그램과 패키지가 필요합니까? 클라우드로 안내할 수 있는 솔루션이 필요하지만 먼저 레거시, vmWare 및 물리적 시스템을 관리해야 합니까? Windows 애플리케이션 전체를 판매하시겠습니까, 아니면 혼합하여 사용하시겠습니까? 당신의 팀도 생각해보십시오. 이직률이 높아 여러 솔루션의 관리가 어렵고 교육 과정이 필수이며실제 지원하는 사람들비판적인? 사용 편의성이 필요합니까, 아니면 견고성이 중요합니까? 오퍼링, 제품 및 회사의 수명과 안정성은 어디에 적합합니까?

둘째, 요구사항의 우선순위를 어떻게 정하고 있습니까? 확립된 요구 사항을 기준으로 우수 기업의 우선순위를 어떻게 정하시겠습니까? 내 친구 Brandon은 항상 제목을 빨리 제시합니다. 그는 항상 반박합니다. 르브론은 얼마나 많은 타이틀을 가지고 있습니까? 그의 논쟁에서는 제목이 왕이다. 나는 일반적으로 벤치에 있는 12번째 남자도 링을 받는다고 비꼬듯 반박합니다. 뛰어난 파워포워드인 로버트 호리가 르브론이나 MJ보다 더 많은 타이틀을 갖고 있다는 점을 강조한다. 요구사항의 우선순위에 대해 솔직하고 솔직하게 대화하세요. HA 솔루션을 선택할 때 RTO/RPO와 비교하여 사용 편의성, OS 지원 및 애플리케이션 지원 범위가 얼마나 중요합니까? 꼭 있어야 하고, 가지고 있어야 하고, 있으면 좋은 기능과 요구 사항은 무엇입니까? 고객 경험 담당 부사장으로서 우리는 2~3개보다 큰 클러스터를 구축할 계획이 없음에도 불구하고 클러스터 소프트웨어가 32개 노드를 지원한다고 주장하는 고객을 만난 적이 있습니다. 목록의 우선순위를 정하세요.

재해 복구를 위한 RPO 및 RTO 측정

셋째, 이러한 요구 사항을 어떻게 측정하고 있습니까? 확립된 요구 사항을 기준으로 위대한 기업을 어떻게 측정할 예정인가요? 농구의 통계는 재미있고 유익하며 오해의 소지가 있는 경우가 많습니다. Brandon은 내가 몇 번이나 우승했는지 가르칠 때마다 득점 타이틀을 획득한 방법을 확인하라고 자주 상기시켜 줍니다. 우리는 종종 누가 게임을 시작하거나 끝내는 것이 더 나은지, 추진력, 강도, 승리 의지를 실제로 측정하는 방법에 대해 욕설을 퍼붓습니다. 마찬가지로 문헌을 샅샅이 뒤질 때 개념 증명 세부 사항을 자세히 살펴보고 RPO 및 RTO와 같은 항목을 측정하는 방법을 결정하고 정의하십시오. RTO는 클라이언트 재연결 시간을 기준으로 합니까, 아니면 애플리케이션이 다시 시작되는 시간을 기준으로 합니까? RTO를 측정하고 있나요?장애 조치(서버 충돌) 복구(응용 프로그램 충돌), 수동 전환(관리 조치), 아니면 위의 모든 것인가요? 애플리케이션 성능이 중요하다면 해당 측정값은 어떻게 되나요? 읽기 성능, 쓰기 성능입니까, 아니면 클라이언트의 실제 또는 특성화된 워크로드를 기반으로 합니까? 벤치마크가 어디에 적합한지 생각해 보세요. 아니면 적합합니까? 또한 숫자를 무엇과 비교하고 있는지 솔직하게 설명하세요. 정상 작동 및 복구 시 더 빠른 데이터베이스 쿼리 시간을 측정하는 것이 중요합니다. 하지만 나머지 솔루션으로 인해 사용자 경험에서 더 높은 수준의 지연이 발생한다면 어떻게 될까요?

고가용성 및 재해 복구 평가

마지막으로 계속 평가해 보세요. 줄리어스가 베이스라인에서 아기를 흔들어 잠들게 한 때부터 조던이 자유투 라인에서 벗어나는 날, 스테판 커리가 하프코트 라인 안쪽으로 슛을 날린 때까지 농구 게임은 진화해 왔습니다. “Jordan Rules” 및 “Bad Boy Era” 스웨거는 기술, 힘 및 기교의 조합을 선호하고 강조하는 규칙 세트로 대체되었습니다. 마찬가지로 기술 환경도 끊임없이 변화하고 있습니다. Solaris 및 MP-RAS 서버가 지배했을 때 상위 10위 안에 들었던 솔루션은 Linux, Windows 또는 기타 변형의 민첩성에 적응하지 못했을 수 있습니다. Fibre Channel의 강력한 기능을 활용한 SAN 기반 솔루션은 다음과 같은 상황에서는 더 이상 사용되지 않을 수 있습니다.구름그리고SAN이 없는 세상. 그러므로 위대함을 계속 평가하십시오. 상위 10개 솔루션이 추세에 맞춰 어떻게 움직이고 있는지 계속 모니터링하세요. 더 나아가서는 계속해서 솔루션을 만들고 있습니다.

Brandon과의 논쟁이 계속되고 있으며 앞으로 여러 세대에 걸쳐 우리 아이들도 승자를 정하지 못할 것입니다. 귀하는 기업 가용성 요구 사항을 충족하는 올바른 HA 솔루션을 선택할 수 있습니다.SIOS 담당자에게 문의하세요요구 사항을 초과하는 SIOS Protection Suites 기능을 이해하고 우선 순위를 지정하고 측정하는 데 도움이 됩니다.

다음의 허가를 받아 복제됨시오스

재해 복구 솔루션: “권장 사항”과 “요구 사항”을 처리하는 방법

당신이 당신의 컴퓨터에서 문제를 경험했다고 가정해 봅시다.클라우드 클러스터 환경, 문제를 해결하려면 애플리케이션 공급업체 중 하나에 문의해야 합니다. 그들은 해결책을 제시하지만 응답에서 이러한 시스템을 구성하는 방식은 “권장되지 않음”이라고 언급합니다. 이 정보를 어떻게 처리합니까? 결국 지금까지 모든 것이 잘 작동했기 때문에 “권장되는” 방식으로 재구성하려면 많은 시간과 리소스가 필요할 수 있습니다. 반면에 판매자가 추천하는 데에는 이유가 있겠죠? 나중에 다른 합병증이 발생하면 어떻게 되나요? 권장 사항이 정확히 무엇인지, 수용 여부와 상관없이 권장 사항에 접근할 수 있는 방법을 살펴보겠습니다.

DR 솔루션 권장 구성

“최선의 조치에 대한 제안 또는 제안”으로 정의된 권장 사항을 완전히 문자 그대로 받아들여 권장 사항을 처리하는 방법을 살펴보기 시작해야 합니다. 이미 우리는 이를 식별하는 데 사용되는 “제안” 및 “제안”이라는 단어를 사용하여 어떻게 접근할 수 있는지에 대한 몇 가지 힌트를 볼 수 있습니다. 이렇게 보면 벤더 추천이 불편하거나 불필요하다는 이유로 거절하기 쉽습니다.

그러나 권장 사항에 대한 조치를 취하기 전에 보다 실용적인 측면도 살펴보시기 바랍니다. 결국 공급업체가 이러한 특정 종류의 구성을 제안하는 데에는 이유가 있습니다. 그들은 당신이 지속적인 관계의 일부인 것처럼 당신의 성공에도 관심이 있으므로 확실히 그것은 일종의 긍정적인 이익을 가져다 줄 것입니다. 권장되는 구성이 없으면 특정 유형의 오류가 발생할 가능성이 더 높아질 수 있습니다. 모든 것이 제대로 작동하지만 더 잘 작동하거나 더 빠르게 작동하는 성능 저하의 경우일 수도 있습니다. 이 점을 고려하면, 권장 사항을 따르지 않아 단점을 겪은 후에 시작하는 것보다 지금 이러한 권장 사항을 충족하기 위해 시간과 노력을 투자하는 것이 더 낫지 않을까요?

권장 사항을 벗어난 DR 솔루션 구성을 처리하는 방법

이제 우리는 이 토론의 양쪽 끝을 종합하여 권장 사항에 대한 완전한 관점을 구축할 수 있습니다. 요약된 버전은 다음과 같습니다. “공급업체 권장 사항이 권장되는 이유를 알고 그렇게 할 경우 발생할 수 있는 단점을 수용하는 한 공급업체 권장 사항을 따르지 않아도 괜찮습니다.” 중요한 첫 번째 단계는 항상 공급업체와 간단히 대화하는 것입니다. 권장하는 이유, 권장하는 환경과 그렇지 않은 경우의 영향, 권장 환경으로 쉽게 전환할 수 있는 방법이나 절차가 있는지, 자신과 내부 팀에 더 나은 정보를 제공하는 데 도움이 될 수 있는 기타 사항에 대해 질문하세요. 일단 영향을 이해하고 나면 적절한 정당성이 있는 경우 이를 거부할 수 있는 올바른 위치에 있게 됩니다. 권장 사항을 거절하는 좋은 근거의 예는 보안 목적입니다. 아마도 권장 환경은 현재 시행 중인 특정 보안 조치를 끄거나 우회할 수 있으므로 해당 환경을 사용하면 더욱 취약해질 뿐만 아니라 다음 정책 위반으로 이어질 수도 있습니다.SLA, 파트너 계약 또는 귀하가 준수해야 하는 표준. 이 경우 권장 구성을 따르지 않는 이유를 공급업체에 알릴 수 있습니다. 이는 공급업체에게도 매우 유익할 수 있습니다. 공급업체는 이 피드백을 받아 향후 권장 구성과 보안 조치를 동시에 허용할 수 있는 개선 사항을 구현할 수 있기 때문입니다. 앞서 언급했듯이, 그들은 또한 귀하의 성공을 위해 투자하므로 이는 모두를 위한 승리입니다.

재해 복구 솔루션 요구 사항

하지만 공급업체가 말하는 내용에 “아니오”라고 말하기가 쉽지 않은 경우도 있습니다. 이는 벤더의 “추천”에서 벤더의 “요구사항”으로 경계를 넘어가는 곳이며, 이는 불가피하게 됩니다. 그것이 요구 사항으로 제시되면 따르기를 거부할 수 없는 것이 됩니다. 그럼에도 불구하고 권장 사항과 마찬가지로 이것이 왜 요구 사항인지, 실제로 무엇을 위한 요구 사항인지 이해하는 것이 중요합니다. 공급업체와 합의한 SLA 또는 제품, 애플리케이션 또는 서비스에 대한 TSA의 일부로 특정 관행이 필요할 수 있습니다. 이러한 경우 실제로 이 요구 사항을 충족하기 위해 필요한 변경이 이루어져야 합니다. 요구사항은 일반적으로 기술적인 측면에도 속합니다. 예를 들어 디스크 크기, I/O 용량 또는 사용 가능한 시스템 리소스에 대한 사양 등이 있습니다. 이는 애플리케이션이 의도한 대로 작동하는 데 필요한 경향이 있으므로 이러한 요구 사항을 충족시키는 데 따른 가치는 쉽게 알 수 있습니다.

재해 복구 솔루션 유연성

요구 사항을 따라야 한다고 해서 단순히 스스로 사임해야 한다는 의미는 아닙니다. 해당 요구 사항이 존재하는 이유를 이해하는 데는 여전히 많은 가치가 있습니다. 권장 사항과 마찬가지로 공급업체와 대화하는 것이 중요합니다. 아마도 요구 사항이 마음에 들지 않는 이유는 오해에 뿌리를 두고 있을 수 있으며, 공급업체와 그 이유를 논의하면 이를 밝혀내고 일부 우려를 없앨 수 있습니다. 다시 한번 말씀드리지만, 이러한 요구 사항에 대한 피드백은 공급업체가 제품이나 서비스를 개선하고 다른 방식으로 작업할 수 있는 가치를 이해하는 데 매우 중요할 수 있습니다. 필요한 것은 단지 대화를 시작하는 것뿐입니다.

SIOS 고가용성 및 재해 복구

SIOS Technology Corporation이 제공하는고가용성그리고재해 복구가장 중요한 애플리케이션에 대한 클러스터 관리를 통해 IT 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오당사 서비스 및 전문 지원에 대한 자세한 내용을 알아보십시오.

다음의 허가를 받아 복제됨시오스

Linux에서 SIOS LifeKeeper를 사용하여 NFS 파일 감시를 설정하는 단계별 가이드

SIOS Lifekeeper 및 NFS 기반 파일 감시 시작하기

~ 안에고가용성 클러스터링, 증인은 클러스터의 무결성과 신뢰성을 보장하는 데 중요한 역할을 합니다. 없이세 번째 노드, 두 노드가 모두 활성화되어야 한다고 생각하는 연결을 끊는 데 도움이 되는 데이터가 없기 때문에 쿼럼을 달성하기 어려울 수 있습니다.분열된 두뇌). 예를 들어 전용 감시 서버, 전체 클러스터에서 볼 수 있는 공유 스토리지 경로를 제공하거나 단순히 클러스터 자체에 더 많은 노드(최소 3개!)를 두는 등 다양한 방법으로 이 문제를 해결할 수 있습니다. 고맙게도,SIOS 라이프키퍼Linux 환경에서 고가용성 클러스터를 설정하기 위한 강력한 솔루션을 제공하며 쿼럼을 개선하기 위한 감시 구성은 필수 기능입니다.

이 가이드에서는 Linux에서 SIOS LifeKeeper를 사용하여 NFS 기반 파일 감시를 설정하는 단계를 안내하여 클러스터된 애플리케이션의 가용성과 복원력을 향상시키는 데 도움을 줍니다.

목표:

아래 다이어그램에 표시된 대로 NFS 기반 스토리지 감시를 사용하여 2노드 클러스터를 구현하려면 다음을 수행하세요.

전제조건: 시작하기 전에 다음이 있는지 확인하십시오.

• Linux 서버는 관리 권한(예: 루트 액세스)으로 구성 및 연결됩니다.
• SIOS LifeKeeper는 설치 또는 다운로드되어 각 서버에 설치할 준비가 되어 있습니다.
• NFS 공유는 클러스터의 모든 서버에 액세스할 수 있습니다.

1단계: SIOS LifeKeeper 설치/수정:

이 단계에서 LifeKeeper를 설치하거나 이전에 Witness 기능을 이미 포함하지 않은 경우 설정을 다시 실행하여 Witness 기능을 추가해야 합니다.

제 경우에는 RHEL8.8을 사용하고 있으므로 RHEL8.8에 필요한 추가 패키지로 설정을 실행하기 전에 ISO를 마운트하겠습니다.

[root@server1-LK ~]# 마운트 /root/sps.img /mnt/loop -t iso9660 -o 루프

[root@server1-LK ~]# cd /mnt/loop/

[root@server1-LK 루프]# ./setup –addHADR /root/HADR-RHAS-4.18.0-477.10.1.el8_8.x86_64.rpm

여기서 우리 목적에 있어 중요한 부분은 아래 스크린샷과 같이 감시 기능을 활성화하는 것입니다. 그러나 여기에 추가하거나 나중에 재량에 따라 명령줄을 통해 추가할 수 있는 추가 라이센스 파일도 필요합니다.

그렇지 않은 경우 목적에 맞게 LifeKeeper를 구성하거나, 이미 구성된 경우 “정족수/감시 기능 사용” 옵션을 포함시킨 후 설정을 계속 진행하십시오.

명령줄을 통해 라이선스를 추가하기로 결정한 경우 라이선스 파일의 올바른 경로를 사용하여 클러스터의 각 노드에서 다음 명령도 실행합니다.

[root@server1-LK ~]# /opt/LifeKeeper/bin/lkkeyins /<path-to-license-file>l/quorum-disk.lic

2단계: 공유 저장소 설정 및 마운트:

클러스터의 모든 서버에 액세스할 수 있는 공유 스토리지가 있는지 확인하십시오.
‘mount’ 명령을 사용하거나 ‘findmnt’를 사용하여 각 서버가 로컬로 마운트되었는지 확인할 수 있습니다.

[root@server1-LK 루프]# 마운트 | 그렙 nfs

/var/lib/nfs/rpc_pipefs의 sunrpc 유형 rpc_pipefs(rw,relatime)

172.16.200.254:/nfs/general 유형 nfs4의/var/nfs/general(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,
proto=tcp,timeo=600,retrans= 2,sec=sys,clientaddr=172.16.205.151,local_lock=none,addr=172.16.200.254)

또는

[root@server1-LK ~]# findmnt -l /nfs/general

대상 소스 FSTYPE 옵션

/nfs/general 172.16.200.254:/var/nfs/general nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,
retrans=2,sec =sys,클라이언트주소=172.16.205.151,local_lock=없음,주소=172.16.200.254

그래도 공유를 직접 마운트해야 하는 경우 다음 단계를 따르세요.

먼저 호스트 서버에서 NFS 공유를 볼 수 있는지 확인합니다.

[root@server1-LK ~]# showmount -e 172.16.200.254

172.16.200.254에 대한 목록 내보내기:

/집 172.16.205.244,172.16.205.151

/var/nfs/일반 172.16.205.244,172.16.205.151

제 경우에는 ‘/var/nfs/general’ 공유를 마운트하고 싶습니다.

이 공유를 마운트하려면 먼저 공유를 마운트하려는 디렉터리가 존재하는지 확인하세요. 그렇지 않은 경우 작성하십시오.

[root@server1-LK ~]# mkdir -p /nfs/general

이제 다음 명령을 사용하여 공유를 수동으로 마운트하여 연결할 수 있는지 확인할 수 있으며 작동합니다.

[root@server1-LK ~]# 마운트 172.16.200.254:/var/nfs/general /nfs/general

마지막으로 만족스러우면 마운트 지점을 /etc/fstab 파일에 추가하여 부팅 시 마운트되도록 합니다.

[root@server1-LK ~]# cat /etc/fstab

#

# /etc/fstab

# 2024년 1월 25일 목요일 12:07:15에 anaconda에 의해 생성됨

#

# 참조로 접근 가능한 파일 시스템은 ‘/dev/disk/’에 유지됩니다.

# 자세한 내용은 맨 페이지 fstab(5), findfs(8), mount(8) 및/또는 blkid(8)를 참조하십시오.

#

# 이 파일을 편집한 후 ‘systemctl daemon-reload’를 실행하여 systemd를 업데이트합니다.

이 파일에서 # 단위가 생성되었습니다.

#

/dev/mapper/rhel-root / xfs 기본값 0 0

UUID=6b22cebf-8f1c-405b-8fa8-8f12e1b6b56c /boot xfs 기본값 0 0

/dev/mapper/rhel-swap 없음 스왑 기본값 0 0

#NFS 공유에 추가됨

172.16.200.254:/var/nfs/general /nfs/general nfs4 기본값 0 0

이제 mount 명령을 사용하여 마운트되었는지 확인할 수 있습니다.

[root@server1-LK ~]# mount -l | 그렙 nfs

/var/lib/nfs/rpc_pipefs의 sunrpc 유형 rpc_pipefs(rw,relatime)

172.16.200.254:/nfs/general 유형 nfs4의/var/nfs/general(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,
proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.16.205.151,local_lock=none,
addr=172.16.200.254)

위에 강조 표시된 텍스트에서 볼 수 있듯이 이제 성공적으로 마운트되었습니다. 계속하기 전에 모든 서버에 공유가 마운트되어 있는지 확인할 때까지 모든 서버에서 반복하십시오.

4단계: 호스트 이름을 확인하고 /etc/default/LifeKeeper 설정을 구성합니다.

각 노드에서 다음 명령을 실행하면 LifeKeeper가 각 서버에 대해 알고 있는 호스트 이름을 확인할 수 있습니다.

/opt/LifeKeeper/bin/lcduname

/etc/default/LifeKeeper 파일에 추가해야 하는 설정의 예:

WITNESS_MODE=저장소

QWK_STORAGE_TYPE=파일

QWK_STORAGE_HBEATTIME=6

QWK_STORAGE_NUMHBEATS=9

QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA

QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB

‘QWK_STORAGE_OBJECT_<server-name>’의 경우 각 노드에 대해 이를 선언해야 하며 호스트 이름과 경로, 감시 파일 자체의 원하는 위치를 사용하여 구성됩니다.

호스트 이름에 “-” 또는 “.”가 포함된 경우 밑줄 “_”로 바꾸십시오(예: lksios-1 → lksios_1 또는 lksios-1.localdomain → lksios_1_localdomain ).

내 예에서는 다음과 같은 호스트 이름을 사용했습니다.

server1-LK.localdomain

server2-LK.localdomain

이는 다음 ‘QWK_STORAGE_OBJECT_’ 정의를 추가하는 것을 의미합니다.

QWK_STORAGE_OBJECT_server1_LK_localdomain=/nfs/general/nodeA

QWK_STORAGE_OBJECT_server2_LK_localdomain=/nfs/general/nodeB

또한 /etc/default/LifeKeeper의 기존 설정 중 하나를 조정해야 합니다.

QUORUM_MODE=저장소

WITNESS_MODE 및 QUORUM_MODE를 모두 스토리지로 설정한 이유를 이해하려면 다음 표를 살펴보세요.

지원되는 쿼럼 모드와 감시 모드의 조합

LifeKeeper는 다음 조합을 지원합니다.

쿼럼에 대해 외부 저장소를 사용하려는 2노드 클러스터가 있으므로 지원되는 유일한 조합은 두 값 모두에 대해 ‘저장소’입니다. 그러나 더 많은 노드가 필요할 때 이것이 얼마나 유연한지 표를 통해 확인할 수 있으며, 이는 통신을 달성하고 쿼럼을 제공하는 다양한 방법을 제공합니다.

4단계: 감시 파일 초기화:

감시 파일을 초기화하고 사용을 활성화하려면 각 노드에서 다음 명령을 실행해야 합니다.

[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init

각 노드가 완료될 때까지 실행이 일시 중지되므로 클러스터의 첫 번째 노드에서 명령을 실행한 다음 두 번째 노드 등에서 명령을 실행한 후 다시 돌아와서 명령이 오류 없이 완료되었는지 확인합니다.

예:

[root@server1-LK ~]# /opt/LifeKeeper/bin/qwk_storage_init

ok: LifeKeeper가 실행 중입니다.

ok: LifeKeeper 라이센스 키가 성공적으로 설치되었습니다.

ok: QWK 매개변수가 유효합니다.

/nfs/general/nodeA의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeA는 이미 QWK_STORAGE_OBJECT가 아닌 것으로 존재합니다: 덮어쓰시겠습니까? (y/n): y

ok: QWK 개체의 경로가 유효합니다.

확인: 다운: /opt/LifeKeeper/etc/service/qwk-storage: 1377s

ok: 자체 노드의 QWK 객체 초기화가 완료되었습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

/nfs/general/nodeB의 QWK 개체는 아직 사용할 수 없습니다.

ok: 쿼럼 시스템이 준비되었습니다.

ok: 실행: /opt/LifeKeeper/etc/service/qwk-storage: (pid 14705) 1s, 일반적으로 다운

성공적인.

5단계: 구성 확인:

다음 명령을 실행하여 구성을 확인할 수 있습니다.

/opt/LifeKeeper/bin/lktest

오류가 발견되면 터미널에 인쇄됩니다. 아래 예에서는 호스트 이름의 특수 문자를 바꾸지 않았으므로 스토리지를 찾을 수 없음이 강조되었습니다.

[root@server1-LK ~]# /opt/LifeKeeper/bin/lktest

/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[308]: QWK_STORAGE_OBJECT_server1_LK.localdomain=/nfs/general/nodeA: 찾을 수 없음

/opt/LifeKeeper/bin/lktest: /etc/default/LifeKeeper[309]: QWK_STORAGE_OBJECT_server2_LK.localdomain=/nfs/general/nodeB: 찾을 수 없음

FS UID PID PPID C CLS PRI NI SZ STIME TIME CMD

4 S 루트 2348 873 0 TS 39 -20 7656 15:49 00:00:00 lcm

4 S 루트 2388 882 0 TS 39 -20 59959 15:49 00:00:00 ttymonlcm

4 S 루트 2392 872 0 TS 29 -10 10330 15:49 00:00:00 lcd

4 S 루트 8591 8476 0 TS 19 0 7670 15:58 00:00:00 lcdremexec -d server2-LK.localdomain -e — cat /proc/mdstat

다음과 같이 명령줄을 통해 감시 파일이 업데이트되고 있는지 확인할 수도 있습니다.

[root@server1-LK ~]# cat /nfs/general/nodeA

서명=lifekeeper_qwk_object

local_node=server1-LK.localdomain

시간=2024년 2월 15일 목요일 14:10:56

시퀀스=157

노드=server2-LK.localdomain

통신상태=UP

체크섬=13903688106811808601

NFS를 사용한 성공적인 파일 공유 감시

NFS를 사용하여 파일 공유 감시를 설정하는 것은 쉽습니다! 두 개의 노드로 제한되어 있지만 특히 AWS의 EFS와 같은 기능을 활용할 수 있는 클라우드에서 분할 브레인 이벤트에 대한 더 나은 복원력이 필요한 경우 강력할 수 있습니다. 또 다른 필수 부분은 더 많은 통신 경로를 활용할 수 있지만 이는 다른 블로그입니다. 그러나 이 가이드에 설명된 단계를 따르면 클러스터링된 애플리케이션의 복원력을 향상하고 가동 중지 시간의 위험을 최소화할 수 있습니다. 항상 참고하세요SIOS 문서고가용성 설정에 대한 추가 지침 및 최적화를 위한 모범 사례입니다. 공개적으로 이용 가능하며 매우 포괄적입니다!

SIOS 고가용성 및 재해 복구

SIOS Technology Corporation이 제공하는고가용성그리고재해 복구가장 중요한 애플리케이션에 대한 클러스터 관리를 통해 IT 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오당사 서비스 및 전문 지원에 대한 자세한 내용을 알아보십시오.

다음의 허가를 받아 복제됨시오스