IO 병목 현상을 방지하는 방법: Windows 클라우드 배포를 위한 DataKeeper 인텐트 로그 배치 지침

최적의 애플리케이션 성능을 보장하기 위해 배포 시 SIOS 데이터 키퍼 배치하는 것이 중요합니다 의도 로그 (비트맵 파일)을 사용 가능한 가장 낮은 대기 시간 디스크에 저장하여 IO 병목 현상을 방지합니다. AWS, GCP 및 Azure에서 사용 가능한 가장 짧은 지연 시간 디스크는 임시 드라이브입니다. 그러나 Azure에서는 임시 드라이브를 사용하는 것과 Premium SSD를 사용하는 것의 차이가 최소화되므로 Azure에서 DataKeeper를 실행할 때 임시 드라이브를 사용할 필요가 없습니다. 그러나 AWS 및 GCP에서는 의도 로그를 임시 드라이브로 재배치하는 것이 필수적입니다. 그렇지 않으면 쓰기 처리량이 크게 영향을 받습니다.

비트맵 파일에 임시 디스크를 활용할 때 절충점이 있습니다. 임시 드라이브의 특성은 이 드라이브에 저장된 데이터의 지속성이 보장되지 않는다는 것입니다. 실제로 클라우드 인스턴스가 콘솔에서 중지되면 인스턴스에 연결된 임시 드라이브는 폐기되고 새 드라이브가 인스턴스에 연결됩니다. 이 프로세스에서 비트맵 파일은 삭제되고 비어 있는 새 비트맵 파일이 그 자리에 놓입니다.

비트맵 파일이 손실되면 완전한 재동기화가 발생하는 특정 시나리오가 있습니다. 예를 들어 주 서버가 SANless 클러스터 r이 콘솔에서 종료되면 장애 조치가 발생하지만 서버가 다시 온라인 상태가 되면 미러의 새 소스에서 이전 소스로 완전한 재동기화가 발생합니다. 이것은 자동으로 발생하므로 사용자는 어떤 조치도 취할 필요가 없으며 활성 노드는 이 재동기화 기간 동안 온라인 상태를 유지합니다.

비트맵 파일 배치가 성능에 영향을 줄 수 있는 다른 시나리오도 있습니다. 예를 들어 NVMe 드라이브를 복제하는 경우 NVMe 드라이브에 비트맵 파일을 보관할 작은 파티션을 만들고 싶을 것입니다. 일반적으로 비트맵 파일은 인스턴스에서 사용 가능한 가장 빠르고 대기 시간이 짧은 디스크에 있어야 합니다. 또한 다른 IO 작업으로 과도하게 부담되지 않는 디스크에 있어야 합니다.

의도 로그를 재배치하는 방법에 대한 정보는 다음에서 찾을 수 있습니다. DataKeeper 문서 . 의도 로그가 사용되는 방법에 대한 추가 정보는 DataKeeper 문서 .

의 허가를 받아 재생산 시오스

AWS EC2 클라우드에서 중요한 SAP S/4 HANA를 보호하는 선도적인 미디어 플랫폼

SAP, Amazon Web Services 및 Red Hat Linux에 대한 인증 및 검증을 기반으로 SIOS 선택

이 선도적인 미디어 조직은 매주 싱가포르의 거의 모든 성인에게 다가갑니다. 디지털, 텔레비전, 라디오, 인쇄 및 가정 외 미디어에 걸쳐 미국에서 가장 광범위한 미디어 플랫폼을 통해 4개 언어(영어, 북경어, 말레이어 및 타밀어)로 50개 이상의 제품 및 브랜드를 제공합니다.

환경

회사는 사용 SAP S/4 HANA 애플리케이션 그리고 HANA 데이터베이스 조직 전체의 운영을 강화하여 여러 부서의 운영을 통합합니다. 그들은 온프레미스 데이터 센터의 Red Hat Linux 환경에서 이러한 중요한 애플리케이션과 데이터베이스를 실행하고 있었습니다. 이러한 필수 시스템을 가동 중지 및 재해로부터 보호하는 것은 이 조직의 IT 팀의 최우선 과제입니다.

도전

미디어 조직의 IT 팀은 SAP 애플리케이션과 HANA 데이터베이스를 AWS EC2 클라우드로 이전함으로써 상당한 비용 절감을 실현할 수 있음을 인식했습니다. 그러나 마이그레이션이 성공하려면 기존 SAP 환경을 중단 없이 AWS로 "리프트 앤 시프트"하는 고가용성(HA) 및 재해 복구(DR) 솔루션이 필요했습니다.

평가

회사의 IT 팀은 클라우드에서 99.99% 가용성 SLA를 충족하기 위해 신뢰할 수 있는 HA/DR 솔루션을 원했습니다. 솔루션은 SAP와 AWS 모두의 인증을 받아야 했으며 Red Hat Linux 운영 체제를 지원해야 했습니다. 마지막으로, 이러한 중요한 워크로드에 대해 완전한 DR 보호를 제공할 수 있도록 하려면 여러 AWS 가용 영역(AZ)에서 장애 조치할 클러스터링 솔루션이 필요했습니다. AWS 솔루션 설계자는 조직에서 Linux 클러스터링 소프트웨어용 SIOS LifeKeeper를 사용할 것을 권장했습니다. 회사의 IT 팀은 프로젝트를 완료하기 위한 짧은 일정이 있었고 진행을 방해하지 않으면서 요구 사항을 충족할 수 있는 HA 공급업체를 선택해야 했습니다.

해결책

그들은 SIOS LifeKeeper가 우리의 모든 기준을 충족했을 뿐만 아니라 SIOS 팀이 매우 빠르게 조직되어 클라우드 마이그레이션 프로젝트를 일정에 맞게 유지할 수 있었기 때문에 SIOS LifeKeeper를 선택했습니다. SIOS Lifekeeper는 Red Hat 및 AWS EC2 클라우드 환경의 고가용성에 대해 AWS와 SAP 모두에서 인증을 받았습니다. SIOS 솔루션은 AWS 가용 영역 전반에 걸쳐 중복성을 복제하고 제공할 수 있기 때문에 또 다른 주요 기준을 충족했습니다. 조직의 IT 팀은 하루 24시간 연중무휴로 질문에 답변하고 지원을 제공할 수 있는 SIOS의 전담 현지 지원 팀에 깊은 인상을 받았습니다. 일주일. 조직에는 현재 AWS EC2의 여러 가용 영역에서 실행되는 S/4 HANA 및 SAP HANA 애플리케이션을 보호하기 위해 Linux용 SIOS LifeKeeper를 사용하는 5쌍의 장애 조치 클러스터가 있습니다.

결과

소프트웨어를 사용한 이후로 가동 중지 시간이 연장되지 않아 가용성이 안정적이었습니다. 이 고객이 HA/DR 또는 애플리케이션 성능을 희생하지 않고 이러한 중요한 워크로드를 클라우드로 마이그레이션할 수 있게 함으로써 SIOS를 통해 상당한 비용 절감을 달성할 수 있었습니다."라고 그는 말했습니다. SIOS LifeKeeper의 Mediacorp의 용이성은 IT 관리 시간을 최소화하여 훨씬 더 많은 비용을 절약했습니다.

의 허가를 받아 재생산 시오스

다운타임으로부터 시스템 보호

오늘날의 비즈니스 환경에서 조직은 SAP, SQL Server, Oracle 등과 같은 애플리케이션, 데이터베이스 및 ERP 시스템에 의존합니다. 이러한 애플리케이션은 가장 중요한 비즈니스 운영을 통합하고 간소화합니다. 실패하면 돈보다 더 많은 비용이 듭니다. 이러한 복잡한 시스템을 다운타임으로부터 보호하는 것이 중요합니다.

입증된 고가용성 및 재해 복구

SIOS는 20년 이상의 경험을 가지고 있습니다. 고가용성 그리고 재해 복구 .SIOS는 모든 솔루션에 딱 맞는 사이즈가 없다는 것을 알고 있습니다. 오늘날의 데이터 시스템은 온프레미스, 퍼블릭 클라우드, 하이브리드 클라우드 및 멀티 클라우드 환경의 조합입니다. 애플리케이션 자체로 인해 훨씬 더 복잡해질 수 있습니다. 그러나 오픈 소스 클러스터 소프트웨어를 구성하는 것은 힘들고 시간이 많이 걸리며 인적 오류가 발생하기 쉽습니다.

SIOS는 중요한 애플리케이션을 위한 고가용성 및 재해 복구를 제공하는 솔루션을 보유하고 있습니다. 이러한 솔루션은 다양한 산업 및 사용 사례 전반에 걸쳐 당사의 실제 경험을 기반으로 개발되었습니다. 우리의 제품은 다음을 포함합니다 Windows용 SIOS DataKeeper 클러스터 에디션 그리고 Linux용 SIOS LifeKeeper 또는 Windows. 이러한 강력한 애플리케이션은 장애 조치 보호를 제공합니다. LifeKeeper에 포함된 애플리케이션 복구 키트는 구성을 자동화하고 입력을 검증하여 애플리케이션 구성 시간을 단축합니다.

온프레미스, 클라우드 또는 하이브리드 환경에서 시스템 보호

SIOS는 온프레미스, 클라우드 또는 하이브리드 클라우드 환경에서 비즈니스 크리티컬 애플리케이션에 필요한 보호 기능을 제공하고 관리 복잡성을 줄입니다. 아래 비디오에서 당사에 대해 자세히 알아보거나 문의하기 비즈니스 크리티컬 애플리케이션을 위한 고가용성 및 재해 복구에 대해 자세히 알아보십시오.

의 허가를 받아 재생산 시오스

WSFC를 사용하여 클라우드에서 고가용성을 달성하는 방법

Microsoft Windows Server에는 중요한 응용 프로그램의 가용성을 보장하는 WSFC(Windows Server 장애 조치 클러스터링) 소프트웨어가 포함되어 있습니다. 온프레미스 환경에서 클러스터의 기본 노드와 대기 노드는 동일한 공유 스토리지에 연결됩니다. 그러나 이 인프라를 클라우드로 직접 가져올 수는 없습니다. 기본 시스템과 대기 시스템 모두에 걸쳐 있는 공유 저장소는 WSFC에서 필수적이지만 공유 저장소는 AWS, Azure 또는 Google Cloud의 IaaS(Infrastructure as a Service)와 같은 공용 클라우드 서비스와 함께 사용할 수 없습니다.

지리적으로 분리된 공유 스토리지 WSFC용 클라우드에서 사용할 수 없음

기업은 온프레미스 애플리케이션을 클라우드로 마이그레이션할 때 온프레미스 운영 프로세스를 변경하지 않고 WSFC를 포함한 전체 인프라를 클라우드로 이동하는 것을 선호합니다. 이를 통해 동일한 WSFC 기술과 노하우를 클라우드에 적용하여 중단을 최소화할 수 있습니다.

클러스터를 구성하는 서버는 애플리케이션이 실행되는 기본 노드와 대기 노드로 나뉩니다. WSFC 소프트웨어는 애플리케이션과 서버 노드를 모니터링하여 작동하는지 확인합니다. WSFC가 기본 노드에 문제가 있음을 감지하면 "장애 조치(failover)"라는 프로세스에서 애플리케이션의 작동을 대기 노드로 전환합니다.

WSFC 환경에서 기본 서버와 대기 서버는 공유 스토리지(일반적으로 SAN(Storage Area Network) 또는 iSCSI-SAN 스토리지라고 하는 스토리지)에 연결됩니다.

기본 서버에서 대기 서버로 작업을 페일오버하려면 대기 서버가 일반적으로 기본 서버에서 읽고 쓰는 SAN에서 읽고 쓸 수 있도록 네트워크 링크를 전환해야 합니다. 이러한 방식으로 짧은 시간에 서비스를 다시 시작할 수 있어 대기 서버가 기본 노드와 동일한 데이터에 액세스하고 낮은 RPO(복구 시점 목표)를 충족할 수 있습니다.

관련 콘텐츠 보기: 재해 복구 기초 .

그러나 WSFC를 클라우드로 마이그레이션할 때 사용할 수 있는 SAN이 없습니다. 예를 들어 Amazon Web Services(AWS) 및 Microsoft Azure를 여러 노드(서버)에 연결하여 공유 스토리지로 사용할 수 없습니다. 다른 클라우드 서비스의 IaaS에도 동일하게 적용됩니다.

공유 스토리지 없이 WSFC를 기반으로 HA 클러스터 구성을 구축하는 것도 가능하지만 대기 노드에서 데이터를 복구하는 자체 프로그램을 만드는 것과 같은 고도의 기술이 필요합니다. 조작이 복잡하고 사고 발생시 확인이 쉽지 않습니다.

데이터 복제 소프트웨어로 문제 해결

이 문제를 해결하려면 다음을 설치할 수 있습니다. 데이터 복제 SIOS DataKeeper Cluster Edition과 같은 HA 클러스터에 특화된 소프트웨어를 사용하고 로컬 서버 간에 스토리지를 동기화합니다. 기본 및 대기 노드의 로컬 디스크에 있는 데이터는 호스트 기반 블록 수준 복제를 사용하여 실시간으로 동기화됩니다. 이 방법을 사용하면 공유 저장소가 필요하지 않습니다. 대신 기존 프로세스를 방해하지 않고 친숙한 WSFC를 사용하여 HA 클러스터 구성을 구축할 수 있습니다.

DataKeeper를 사용하면 동기화된 노드가 WSFC 관리 화면(장애 조치 클러스터 관리)에 SAN으로 나타납니다. 운영 관리자가 WSFC를 사용한 경우 이 접근 방식에 대한 교육이 거의 또는 전혀 필요하지 않습니다.

온프레미스 HA를 능가하는 클라우드의 고가용성 SIOS DataKeeper 및 WSFC 사용

DataKeeper 클러스터 에디션 WSFC(Windows Server Failover Clustering)와 원활하게 통합되어 성능이 최적화된 호스트 기반 동기 또는 비동기 복제를 추가하는 소프트웨어 애드온입니다. 드물게 HA 클러스터가 오작동하는 경우 WSFC는 대기 노드에 대한 작업 장애 조치를 조정하고 공유 스토리지인 것처럼 공유 스토리지에 액세스합니다. 이 간단한 메커니즘을 통해 기존 시스템의 운영을 변경하지 않고 AWS로 이전할 수 있습니다.

친숙한 WSFC 작업을 손상시키지 않고 온프레미스와 동일하거나 더 나은 DataKeeper를 사용하여 클라우드에서 고가용성을 보장할 수 있습니다. 고가용성 . 이 클러스터 구성의 장점은 매우 간단하고 모든 클라우드 환경에 쉽게 적용할 수 있다는 것입니다.

WSFC와의 원활한 통합

SIOS DataKeeper Cluster Edition은 성능에 최적화된 호스트 기반 데이터 복제 메커니즘을 제공하여 WSFC(Windows Server Failover Clustering)와 원활하게 통합 및 확장합니다. WSFC가 소프트웨어 클러스터를 관리하는 동안 SIOS는 재해 보호를 활성화하고 클라우드, 가상 및 고성능 스토리지 환경과 같이 공유 스토리지 클러스터가 불가능하거나 비실용적인 경우 데이터 손실을 방지하기 위해 데이터 복제를 수행합니다.

의 허가를 받아 재생산 시오스

쿼럼/감시를 배포하는 가장 좋은 단일 방법

최근 회의에서 한 고객이 고가용성(HA) 및 쿼럼/증인 실행 가능성의 필요성에 대해 질문했습니다. 그들의 질문은 "정족수/증인을 배치하는 가장 좋은 방법은 무엇입니까?"였습니다. 그들의 질문에 대한 대답은 간단합니다. 쿼럼을 배포하는 가장 좋은 방법은 없습니다.그 이유를 이해하기 위해 감시 리소스, 쿼럼 리소스 및 분할 브레인 시나리오의 세 가지 주요 사항을 정의하는 것으로 시작하겠습니다.

스플릿 브레인이란?

일반 클러스터 환경에서 보호된 애플리케이션은 클러스터의 기본 노드에서 실행됩니다.해당 기본 노드의 애플리케이션 오류가 발생하는 경우 클러스터링 소프트웨어는 애플리케이션 작업을 기본 노드의 역할을 가정하는 보조 또는 원격 노드로 이동합니다. 주어진 시간에 하나의 기본 노드만 있습니다.

스플릿 브레인은 클러스터의 구성원이 서로 통신할 수 없지만 실행 및 작동 가능한 상태에 있으며 이후에 공통 리소스의 소유권을 동시에 가져갈 때 발생하는 상태입니다. 실제로 두 명의 버스 운전사가 운전대를 놓고 싸우고 있습니다.분할 브레인은 파괴적인 특성으로 인해 데이터 손실 또는 데이터 손상을 유발할 수 있으며 클러스터 중재를 위한 펜싱, 쿼럼, 감시 또는 쿼럼/감시 기능을 사용하여 방지하는 것이 가장 좋습니다.

대부분의 클러스터 관리자에서 쿼럼은 다음과 같은 경우에 유지됩니다.

1. 모든 서버는 모든 클러스터 피어 및 증인에 대해 동일한 상태를 볼 수 있습니다.
2. 모든 서버는 모든 클러스터 피어에 대해 동일한 상태를 볼 수 있지만 증인은 아닙니다.
3. 모든 서버는 서로는 아니지만 감시 리소스를 볼 수 있으며 분할 브레인 시나리오를 피할 수 있습니다.

대부분의 클러스터 관리자에서 다음과 같은 경우 쿼럼이 손실됩니다.

1. 서버는 모든 클러스터 피어와 감시 서버를 볼 수 없습니다.
2. 서버는 감시 서버를 볼 수 있지만 대다수의 클러스터 피어를 볼 수 없습니다.
3. 서버는 쿼럼 구성원 및 리소스 액세스를 성공적으로 중재하기 위해 쿼럼 리소스에 액세스하거나 액세스를 유지할 수 없습니다.

감시 리소스(또는 서버)란 무엇입니까?

감시 리소스는 클러스터에 짝수의 구성원이 있는 경우 쿼럼을 달성하고 유지 관리하는 데 사용되는 서버, 네트워크 끝점 또는 장치입니다.클러스터 과반수를 사용하는 홀수의 구성원이 있는 클러스터는 과반수 구성원을 중재하기 위해 클러스터 서버의 모든 구성원으로 감시 리소스를 사용할 필요가 없습니다.

쿼럼 및 쿼럼 리소스란 무엇입니까?

쿼럼 리소스는 클러스터 상태 및 구성원 자격을 중재하는 수단으로 사용되는 리소스(장치, 시스템, 블록 저장소, 파일 저장소, 파일 공유 등)입니다.일부 클러스터 관리자에서 쿼럼은 클러스터 상태 및 클러스터 구성원 결정에 도움이 되거나 필요한 클러스터 내의 리소스입니다.다른 클러스터 관리자에서 쿼럼은 분할 브레인을 방지하기 위한 결정자 역할을 합니다.

쿼럼을 배포하는 여러 가지 방법

쿼럼의 중요한 특성을 감안할 때 HA 아키텍처가 쿼럼/감시 리소스를 적절하게 배포하는 것이 중요합니다. 하나도 없다 , 쿼럼을 배포하는 가장 좋은 방법입니다.증인 및 정족수 자원이 작동하는 방식을 형성할 수 있는 몇 가지 요인이 있습니다.이러한 요인에는 다음이 포함됩니다.

1. 배포가 온프레미스, 클라우드 또는 하이브리드인지 여부

파이버 채널 스토리지, 전원 제어 장치 또는 연결 또는 기존의 stonith 장치와 같은 추가 스토리지 장치가 있는 온프레미스 데이터 센터에 배포하면 클라우드에 없을 수 있는 쿼럼 및 감시 기능에 대한 추가 옵션이 고객에게 제공됩니다.마찬가지로 클라우드 및 하이브리드 환경은 배포할 수 있는 것과 방지하기 위해 배포하는 사용 사례 쿼럼에 차이가 있습니다. 또한 대기 시간 요구 사항과 차이점으로 인해 쿼럼/감시 구성에 사용할 수 있는 장치 및 리소스 유형이 제한될 수 있습니다.  

2. 복구 목표

복구 목표는 쿼럼 및 감시 리소스를 설계하고 구성할 때 고려해야 할 중요합니다.2개의 노드 클러스터(노드 A 및 노드 B)의 예에서 노드 A에서 노드 B에 대한 연결이 끊어지면 복구를 위한 가장 높은 우선 순위가 무엇입니까? 감시/쿼럼 리소스가 노드 A와 동일한 네트워크에 있는 경우 노드 A가 온라인 상태로 남아 있지만 클라이언트에서 분리될 수 있는 반면 노드 B는 쿼럼 및 인계를 평가할 수 없습니다.마찬가지로, 쿼럼 장치가 지역, 데이터 센터 또는 노드 B가 있는 네트워크에만 있는 경우 손실이 발생하면 리소스가 없어진 네트워크 또는 센터로 장애 조치되거나 기능 및 작동 기본 노드에서 멀어질 수 있습니다.

3. 인프라 내에서 사용 가능한 데이터 센터(또는 지역)의 이중화

데이터 센터 또는 지역의 이중화도 쿼럼/감시가 있는 HA 토폴로지에서 중요한 요소입니다. 데이터 센터에 두 가지 수준의 중복만 있는 경우 기본 또는 대기 클러스터 노드와 동일한 데이터 센터에 쿼럼/감시 배치 간의 균형을 이해해야 합니다. 데이터 센터에 세 번째 가용 영역 또는 두 번째 지역에 대한 액세스와 같이 두 개 이상의 중복 계층이 있는 경우 이 옵션은 클러스터에 더 높은 수준의 중복성을 제공합니다.

4. 재해 복구 요구 사항

실제 재해 복구 요구 사항을 이해하는 것도 설계의 주요 요소입니다. 클러스터 관리자 소프트웨어에서 전체 데이터 센터 중단(또는 지역 장애)을 복구하기 위해 쿼럼/감시 액세스가 필요한 경우 설계에 대한 이러한 영향을 이해해야 합니다.많은 고가용성 소프트웨어 패키지에는 이 시나리오를 위한 도구 또는 방법이 있지만 소프트웨어에 없는 경우 쿼럼/감시를 설계하고 배치하여 이러한 현실을 수용해야 할 수 있습니다.

5. 클러스터 내의 구성원 수 및 위치

클러스터에 홀수개의 노드가 포함된 경우 일반적으로 추가 쿼럼/감시 서버가 필요하지 않습니다.그러나 클러스터에서 두 개의 노드만 사용하거나 항상 사용할 수 없는 DR 노드를 배포하는 경우 아키텍처가 변경될 수 있습니다.고객 경험 담당 부사장으로서 저는 3개의 노드 아키텍처를 배포한 고객과 함께 작업했지만 비용 절감을 위해 세 번째 서버의 주기적 종료를 자동화했습니다.

6. 운영 체제 및 클러스터 관리자

쿼럼/감시에서 언급할 마지막 요소는 클러스터 관리자와 운영 체제입니다.쿼럼/감시 배포 또는 쿼럼 상태 중재와 관련하여 모든 HA 소프트웨어 및 클러스터 관리자가 동일하지는 않습니다.일부 클러스터링 소프트웨어에는 중재를 위해 공유 디스크가 필요하고 다른 소프트웨어는 공유를 허용하는 더 유연합니다(NFS, SMB, EFS, Azure Files 및 S3).클러스터 관리자가 요구하는 사항과 쿼럼과 관련하여 지원하는 모드(단순 과반수, 감시, 파일 공유 등)를 알고 있으면 배포 대상뿐만 아니라 배포 방법에도 영향을 미칩니다.

쿼럼/감시 서버를 배포하는 가장 좋은 방법은 쿼럼/감시 및 사용 가능한 옵션에 대한 공급업체의 정의를 이해하고, 요구 사항을 파악하고, 데이터 센터(또는 클라우드 환경)에서 제공하는 제한 사항이나 기회를 고려하고, 솔루션을 설계하는 것입니다. 스플릿 브레인(split-brain), 잘못된 장애 조치(failover) 및 다운타임에 대한 최고 수준의 보호를 중요한 시스템에 제공합니다.

-Cassius Rhue, VP, 고객 경험