| 4월 24, 2024 |
SIOS 기술, Nutanix Elevate 파트너 프로그램에 합류 |
||||||||||||||||||||||||||||
| 4월 22, 2024 |
단계별 – OCI의 SQL Server 2019 FCI(장애 조치 클러스터 인스턴스) |
||||||||||||||||||||||||||||
| 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 도메인 서비스 활성화
서버를 도메인 컨트롤러로 승격
이 프로세스를 시작하기 전에 서버에서 로컬 관리자 계정을 활성화하고 비밀번호를 설정하십시오. 그렇지 않으면 도메인 컨트롤러 수준을 올리려고 할 때 이 메시지를 받게 됩니다.
관리자 계정을 활성화하고 비밀번호를 설정한 후 배포 후 구성을 진행하세요.
선호하는 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가지 팁
올바른 고가용성 솔루션을 선택하기 위한 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 파일 감시를 설정하는 단계별 가이드
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는 다음 조합을 지원합니다.
| QUORUM_MODE | |||||
| 다수 | tcp_remote | 저장 | 없음/꺼짐 | ||
| WITNESS_MODE | 원격_확인 | 지원3개 이상의 노드 | 지원3개 이상의 노드 | 지원되지 않음 | 지원3개 이상의 노드 |
| 저장 | 지원되지 않음 | 지원되지 않음 | 지원됨2~4개 노드 사이 | 지원되지 않음 | |
| 없음/꺼짐 | 지원3개 이상의 노드 | 지원2개 이상의 노드 | 지원되지 않음 | 지원됨 | |
쿼럼에 대해 외부 저장소를 사용하려는 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 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오당사 서비스 및 전문 지원에 대한 자세한 내용을 알아보십시오.
다음의 허가를 받아 복제됨시오스