SIOS SANless clusters High-availability Machine Learning monitoring
기업은 유연성과 확장성을 유지하기 위해 여러 클라우드 서비스 제공업체를 점점 더 많이 사용하고 있습니다. 그러나 CrowdStrike 중단과 같은 최근 사건은 최고 시스템조차도 특히 업데이트 및 보안 패치와 관련하여 문제가 발생할 수 있음을 보여줍니다. 이 웨비나에서는 예기치 않은 중단 중에 미션 크리티컬 애플리케이션을 작동 상태로 유지하기 위해 다중 클라우드 고가용성(HA) 솔루션을 구현하기 위한 모범 사례를 설명합니다. 또한 시스템 구성 오류나 문제가 있는 패치로 인한 가동 중지를 방지하여 클라우드 인프라를 효과적으로 관리할 수 있는 전략도 다룹니다.
온디맨드 웨비나를 시청하고 사용자 환경에서 HA를 달성하고 예방 가능한 가동 중지 시간을 최소화하는 방법을 알아보세요.
허가를 받아 재생산되었습니다.시오스
Flexera 2021 State of the Cloud Report에 따르면 클라우드 컴퓨팅은 지난 10년 동안 조직의 99%가 하나 이상의 퍼블릭 또는 프라이빗 클라우드를 사용하면서 유비쿼터스화되었습니다. AWS, Microsoft Azure 및 GCP는 오늘날 3대 퍼블릭 클라우드 제공업체이지만 많은 조직이 의도적으로든 우연히든 가장 매력적이고 가장 적합한 클라우드 서비스를 선택할 수 있는 멀티 클라우드 전략을 채택했습니다. 고유한 비즈니스 요구 사항에 Flexera 보고서에 따르면 오늘날 기업의 92%가 멀티클라우드 전략을 가지고 있으며 SaaS(Software-as-a-Service), PaaS(Platform-as-a-Service), 및 IaaS(Infrastructure-as-a-Service) 오퍼링.
멀티 클라우드는 단순히 두 개 이상의 퍼블릭 및/또는 프라이빗 클라우드(SaaS, PaaS 및 IaaS 포함)로 구성된 환경입니다. 다중 클라우드 환경의 서로 다른 서비스는 상호 운용될 수 있거나(이 경우 하이브리드 클라우드일 수 있음) 반드시 상호 운용되지 않을 수 있습니다(본질적으로 별도의 클라우드 사일로로 작동). 모든 하이브리드 클라우드는 멀티 클라우드이지만 모든 멀티 클라우드가 하이브리드 클라우드는 아닙니다.
다중 클라우드 환경은 SaaS, PaaS 및 IaaS를 포함하여 둘 이상의 퍼블릭 또는 프라이빗 클라우드 오퍼링의 조합으로 구성됩니다. 따라서 조직의 다중 클라우드 전략은 Amazon Elastic Cloud Compute(EC2)에서 실행되고 이메일 및 백오피스 애플리케이션에 Microsoft 365를 사용하는 엔터프라이즈 워크로드로 구성될 수 있습니다. 또는 조직은 프라이빗 클라우드에서 호스팅되는 사용자 정의 데이터베이스를 퍼블릭 클라우드 SaaS 제품인 Salesforce에 연결할 수 있습니다.
하이브리드 클라우드 환경은 온프레미스, 프라이빗 클라우드 및 퍼블릭 클라우드 환경이 혼합되어 구성됩니다. Flexera 보고서에 따르면 기업의 80%가 하이브리드 클라우드 전략을 가지고 있습니다(그림 4 참조). 멀티 클라우드 환경은 종종 중앙 집중식 IT 부서와 상의할 필요 없이 서로 다른 부서가 개별 요구 사항을 충족하기 위해 클라우드 서비스를 조달하는 섀도우 IT의 결과로 발전합니다. 예를 들어, 마케팅 팀은 IT 부서가 AWS에 첫 번째 워크로드를 배포하기 오래 전에 Salesforce를 사용하기 시작했고, HR 및 재무 부서는 조직이 현재 의존하고 있는 SaaS 애플리케이션 조합에 Workday와 Concur를 추가하느라 바빴을 수 있습니다. 또는 전 세계 여러 프로젝트에서 작업하는 애플리케이션 개발 팀이 있을 수도 있습니다. 한 개발 팀은 Azure DevOps를 선호하는 반면 다른 팀은 AWS의 오픈 소스 도구를 선호할 수 있습니다. 따라서 다중 클라우드 전략은 순전히 우연히 발전했을 수 있으며 이는 반드시 나쁜 것만은 아닙니다.
앱 개발 팀이 선호하는 개발 환경에서 생산성을 극대화하고 시장 출시 시간을 단축할 수 있는 동안 서로 다른 부서는 요구 사항을 충족하는 최고의 솔루션을 선택할 수 있습니다.
다중 클라우드 환경은 예를 들어 규제 요구 사항, 합병 및 인수로 인해 또는 고가용성 및 재해 복구 전략을 구현하기 위해 설계에 따라 진화합니다.
규정 언어는 모호하고 혼란스러울 수 있습니다. 예를 들어 IT 아웃소싱에 대한 FCA(Financial Conduct Authority) 규정에는 기업이 "대체 서비스 제공업체로 전환하고 비즈니스 연속성을 유지하는 방법을 알 수 있어야 한다"고 명시되어 있습니다. 이 진술은 규제를 받는 회사가 최소한 보조 클라우드 환경에 대한 계획을 세워야 함을 의미합니다. 규제가 심한 많은 회사의 위험 회피 특성을 감안할 때 이러한 유형의 문제로 인해 많은 기업이 멀티클라우드 전략을 채택하게 되었습니다.
합병 또는 인수 후 IT 시스템을 통합하고 데이터 센터와 클라우드 환경을 통합하는 것은 중요한 과제입니다. 클라우드 공급자 또는 코로케이션 공급자와의 기존 계약을 포함하여 이 문제를 복잡하게 만들 수 있는 여러 요인이 있습니다. 물리적 데이터 센터를 통합하는 것과 마찬가지로 클라우드 워크로드를 통합하는 것은 상당한 비즈니스 가치를 제공하지 않는 주요 작업일 수 있으므로 우선 순위가 더 높은 프로젝트를 위해 자주 지연됩니다.
마지막으로 고가용성 및 재해 복구 요구 사항을 지원하기 위해 다중 클라우드 전략이 채택되는 경우가 많습니다. AWS 및 Azure에서 주요 퍼블릭 클라우드 중단을 평가할 때 대부분의 중단은 일반적으로 한 번에 단일 클라우드 지역으로 제한되며 가장 일반적으로 소프트웨어와 관련됩니다.
점점 더 많은 조직(Flexera 보고서에 따르면 34%)이 여러 퍼블릭 클라우드 공급자에 걸쳐 미션 크리티컬 워크로드를 배포하는 추가 단계를 수행했습니다. 이는 서로 독립적으로 실행할 수 있는 웹 사이트 및 애플리케이션과 같은 정적 워크로드의 경우 훨씬 더 쉬울 수 있습니다. 데이터베이스 및 디렉터리 서비스(예: Active Directory)와 같은 분산 시스템의 경우 다중 클라우드 재해 복구가 훨씬 더 어려울 수 있습니다.
다중 클라우드 환경은 단일 클라우드 배포보다 더 복잡하고 따라서 관리하기 더 어렵습니다. 다중 클라우드 환경의 몇 가지 고유한 문제는 다음과 같습니다. • 엔드투엔드 가시성: 완전한 가시성을 보장하는 것은 모든 IT 환경에서 어려운 일이며 고도로 동적인 다중 클라우드 환경에서는 훨씬 더 복잡하고 어렵습니다. 그러나 엔드투엔드 가시성은 성능 문제 및 병목 현상을 해결하고, 디지털 공간을 보호하고, 미션 크리티컬 시스템 및 애플리케이션에서 단일 실패 지점을 식별하는 데 매우 중요합니다.
• 보안 및 ID 관리: 랜섬웨어 및 기타 사이버 보안 위협은 오늘날 모든 IT 리더의 최우선 과제입니다. 퍼블릭 클라우드 플랫폼으로 이동하면 일반적으로 특정 보안 책임(예: 데이터 센터 및 물리적 보안)을 퍼블릭 클라우드 제공업체로 이전하고 암호화 및 네트워크 세분화와 같은 서비스에 대한 온디맨드 액세스를 제공함으로써 조직의 보안 태세를 개선할 수 있습니다. 또한 비용이 많이 드는 실수를 더 쉽게 할 수 있습니다. 예를 들어, 네트워크 구성 오류가 일반적일 수 있습니다. 부적절하게 구성된 AWS S3 스토리지 버킷으로 인해 수천 건의 데이터 유출이 발생했습니다. ID 관리는 또 다른 과제입니다. 예를 들어 Azure Active Directory는 이전에 온프레미스 환경에서 Active Directory를 사용했지만 Azure를 넘어 AWS, GCP 및 SaaS 제품(예: Salesforce, ServiceNow, Workday 등)으로 ID 관리를 확장한 조직에 매우 친숙할 수 있습니다. ) 새로운 도전을 소개할 수 있습니다.
• 애플리케이션 및 데이터 이식성: 하이브리드(멀티 클라우드) 환경에서 다양한 퍼블릭 클라우드 플랫폼 간에 애플리케이션과 데이터를 동적으로 이동하는 기능은 많은 멀티 클라우드 전략의 핵심입니다. 퍼블릭 클라우드 공급자가 애플리케이션 및 데이터 이식성을 제한하기 위해 반드시 서비스를 구축하지는 않지만 이러한 기능을 촉진하기 위해 반드시 협력하지는 않으며 관련 비용이 발생할 수 있습니다. 다양한 클라우드 공급자는 다양한 서비스 제공을 위해 다양한 기술을 사용합니다.
• 다중 클라우드 사일로: 조직이 애플리케이션 및 데이터 이식성을 위해 다중 클라우드 배포를 계획 및 설계하지 않으면 사일로화된 애플리케이션 및 스토리지로 끝날 수 있으며, 기본적으로 여러 클라우드 플랫폼에서 기존 온프레미스 데이터 센터 환경의 일반적인 문제를 재현할 수 있습니다. 최소한 조직에는 다양한 클라우드 플랫폼에서 위험과 사용량/비용을 효과적으로 관리할 수 있는 멀티 클라우드 보안 및 관리 도구가 필요합니다.
Flexera 2021 클라우드 현황 보고서에 따르면 조직의 81%가 보안을 클라우드 배포의 가장 큰 과제로 꼽았고 그 다음이 클라우드 지출 관리(79%)였습니다. 그러나 조직의 42%만이 다중 클라우드 비용 관리 도구를 사용하고 38%만이 다중 클라우드 보안 도구를 사용합니다.
다중 클라우드 배포에는 많은 문제가 있지만 특히 주요 클라우드 중단 및 재해 복구의 경우 추가 가용성을 제공할 수 있습니다. 조직에서 멀티클라우드 전략을 추구하는 경우 신뢰할 수 있고 클라우드에 구애받지 않는 파트너와 협력하여 전체론적 접근 방식을 사용하여 멀티클라우드 배포를 설계하고 구현할 수 있도록 도와야 합니다.
을 위한 고가용성 그리고 재해 복구를 위해 사용하는 클라우드 플랫폼에 관계없이 다중 클라우드 환경을 포괄하는 클라우드 독립적인 기술 솔루션도 필요합니다. 항상 고가용성 솔루션이 독립 실행형 솔루션보다 환경에서 가동 중지 시간을 더 많이 발생시키는 시나리오를 피하려고 합니다. 초기 버전의 SQL Server 클러스터링은 디스크 공간을 추가하기 위해 독립 실행형 솔루션에서는 발생하지 않았을 중단 시간을 발생시켜야 한다는 문제를 제시했습니다. 정적 웹 사이트와 같은 것을 장애 조치하는 것은 사소할 수 있지만 다중 계층 애플리케이션 스택을 이동하는 것은 네트워킹 및 데이터 동기화 측면에서 매우 복잡합니다. 또한 클라우드 제공자 전체의 서로 다른 보안 솔루션 간의 뉘앙스에 대한 이해 부족으로 인해 잠재적으로 잘못 구성되었을 수 있는 덜 안전한 클라우드 환경으로 장애 조치하는 것을 피해야 합니다.
마지막으로 모든 퍼블릭 클라우드에는 비용을 빠르게 증가시킬 수 있는 소수의 서비스가 있습니다. 이러한 서비스는 사용량 기반 가격 책정에 따라 청구되며 단 며칠 만에 급격한 비용 증가를 의미할 수 있습니다. 이 위험을 완화하는 한 가지 방법은 각 클라우드 플랫폼에 있는 비용 모니터링 서비스 및 경고를 활용하고 있는지 확인하는 것입니다.
다중 클라우드 배포가 모든 조직을 위한 것은 아니지만 많은 조직이 이 경로를 따라갈 것입니다. 네트워킹 및 보안을 이해하는 것은 가장 큰 기술적 장애물 중 하나이며 거버넌스 및 비용 관리는 주요 기능적 과제입니다. 테스트는 멀티클라우드 클러스터 솔루션이 작동하는지 확인하는 데 중요합니다. 간단한 전환 및 전환을 가능하게 하는 고가용성 클러스터링 솔루션을 사용하고 각 애플리케이션이 어떻게 작동하는지 이해하는 것이 중요합니다. 장애 조치 , 그리고 가장 중요한 것은 네트워킹 또는 데이터 장애물을 이해하기 위해 해당 장애 조치를 정기적으로 테스트하는 것입니다.
의 허가를 받아 복제됨 시오스
이 주제가 혼란스럽게 들린다면 이해합니다. 전문가의 조언을 통해 귀하의 우려를 완화하는 동시에 이전 또는 이후에 귀하의 조직에 대한 몇 가지 중요한 고려 사항을 제기할 수 있기를 바랍니다. 가고있다 멀티 클라우드 . 재해 복구 계획은 클라우드 컴퓨팅을 사용하는 회사, 특히 여러 클라우드 공급자가 관련된 경우 혼동을 일으키는 일반적인 지점입니다.
데이터 보호 및 재해 복구 (DR) 모든 데이터가 온프레미스에 있는 경우. 그러나 오늘날 많은 기업이 여러 클라우드 제공업체와 함께 온프레미스 데이터를 보유하고 있습니다. 하이브리드 전략은 비즈니스에 적합할 수 있지만 데이터 보호 업무를 수행하는 사람들에게 문제를 일으킬 수 있습니다. 세부 사항을 살펴보기 전에 핵심 용어를 정의하겠습니다.
멀티 클라우드는 조직의 IT 서비스 및 인프라를 제공하기 위해 둘 이상의 클라우드 공급자를 활용하는 것입니다. 멀티 클라우드 접근 방식은 일반적으로 Amazon Web Services(AWS), Google Cloud Platform(GCP) 및 Microsoft Azure와 같은 주요 퍼블릭 클라우드 제공업체의 조합으로 구성됩니다.
조직은 비용, 기술 요구 사항, 지리적 가용성 및 기타 요소를 기반으로 각 클라우드 공급자로부터 최상의 서비스를 선택합니다. 이는 회사에서 개발/테스트에 Google Cloud를 사용하고 재해 복구에 AWS를 사용하고 비즈니스 분석 데이터를 처리하는 데 Microsoft Azure를 사용한다는 것을 의미할 수 있습니다.
멀티 클라우드는 온프레미스 인프라, 프라이빗 클라우드 서비스 및 퍼블릭 클라우드가 혼합된 컴퓨팅 환경을 의미하는 하이브리드 클라우드와 다릅니다.
이러한 과제를 해결하려면 기업이 수많은 문제를 다루는 데이터 보호 및 복구 전략을 개발해야 합니다. 다음과 같은 전략적 질문을 스스로에게 해보십시오.
멀티 클라우드 시나리오에서 데이터 보호 및 복구 성공의 가장 큰 열쇠는 저장 방식에 관계없이 모든 데이터에 대한 가시성을 확보하는 것입니다. 기업의 도구를 사용하면 재해 시나리오에서 복구해야 하는 데이터와 애플리케이션과 복구 방법을 정의할 수 있습니다. 예를 들어 백업 이미지에서 또는 데이터를 클라우드에서 새로 생성된 VM으로 이동하는 방법으로 복구할 수 있습니다.
이 도구는 복구 시나리오를 조정하고 중요한 것은 테스트하는 데 도움이 되어야 합니다. 도구가 데이터 백업 도구와 잘 통합되면 데이터가 여러 클라우드와 같은 다른 위치에 저장되어 있더라도 백업을 복구 데이터의 소스로 사용할 수 있습니다. 가장 최근의 SIOS 웨비나에서도 이와 동일한 사항에 대해 논의합니다. 손목 시계 여기 당신이 관심이 있다면.SIOS 데이터 키퍼 다음과 같이 유연하고 확장 가능한 클라우드 환경에서 비즈니스 크리티컬 애플리케이션을 실행할 수 있습니다. 아마존 웹 서비스(AWS) , 하늘빛 , 그리고 구글 클라우드 플랫폼 성능, 고가용성 또는 재해 보호를 희생하지 않고 SIOS DataKeeper는 AWS 마켓플레이스 WSFC용으로 제공되는 유일한 Azure 인증 고가용성 소프트웨어 애저 마켓플레이스.
재해가 일어나 갑작스러운 다운 타임이 발생합니다. 그러나 사실상 모든 클라우드 중단에서 생존하기 위해 모든 고객이 할 수있는 일이 있습니다. 물건이 생겼어. 크고 작은 실패는 필연적입니다. 필연적 인 것은 오랜 기간의 가동 중지 시간입니다. Microsoft의 Azure 클라우드의 South Central United States 지역에서 치명적인 오류가 발생한 날을 생각해보십시오. 심한 뇌우로 인해 계단식 문제가 생겨 결국 전체 데이터 센터가 파괴되었습니다. 일부 사람들은 "하늘 구름이 하늘에서 떨어지는 날"이라고 불렀던 대부분의 고객은 몇 초 또는 몇 분만이 아니라 하루 동안 오프라인 상태였습니다. 일부는 2 일 이상 오프라인 상태였습니다. Microsoft는 그 후 정전으로 이어지는 많은 문제를 해결했지만 IT 전문가는이 문제를 오랫동안 기억할 것입니다. 그것은 나쁜 소식입니다. 좋은 소식은 : Azure 고객이 사실상 중단 된 상황에서 생존하기 위해 할 수있는 일이 있습니다. 단일 서버가 실패하여 전체 데이터 센터가 오프라인 상태가 될 수 있습니다. 실제로 실시간 데이터 복제 및 신속한 자동 장애 조치를 갖춘 강력한 고 가용성 및 재해 복구 조항을 구현 한 Azure 고객은 재해가 발생할 때마다 데이터 손실이 발생하지 않으며 가동 중단 시간이 거의 없거나 전혀 없을 것으로 예상 할 수 있습니다. 또한보십시오 : Nutanix는 기업 구름이 구름 인종을이기는 것을 봅니다
이 기사에서는 하이브리드 및 순수 Azure 클라우드 구성에서 재해 복구 (DR) 및 고 가용성 (HA) 보호를 제공하는 네 가지 옵션을 검토합니다. 두 가지 옵션은 Azure 클라우드에서 널리 사용되는 Microsoft SQL Server 데이터베이스에만 적용됩니다. 다른 두 옵션은 응용 프로그램에 독립적입니다. 다양한 조합으로 사용할 수있는 네 가지 옵션이 테이블에서 비교되어 다음과 같습니다.
네 가지 옵션을 설명하기 전에 DR 및 HA 조항의 효율성을 평가하는 데 사용되는 두 가지 메트릭, 즉 복구 시간 목표 및 복구 시점 목표에 대한 기본적인 이해가 필요합니다. RTO 및 RPO에 익숙한 사용자는이 섹션을 건너 뛸 수 있습니다. RTO는 정전의 최대 허용 기간입니다. 온라인 트랜잭션 처리 응용 프로그램은 일반적으로 가장 낮은 RTO를 가지며 미션 크리티컬 한 응용 프로그램은 종종 단 몇 초의 RTO를가집니다. RPO는 데이터 손실을 허용 할 수있는 최대 기간입니다. 데이터 손실이 허용 가능하지 않으면 RPO는 0입니다. RTO는 일반적으로 필요한 HA 및 / 또는 DR 보호의 유형을 결정합니다. 낮은 복구 시간은 일반적으로 일상적인 시스템 및 소프트웨어 장애로부터 보호하는 강력한 HA 규정을 필요로하지만 더 긴 RTO는보다 광범위하지만 덜 빈번한 재해로부터 시스템을 보호하기 위해 설계된 기본 DR 규정에 충족 될 수 있습니다. HA 및 DR 조항에 사용되는 데이터 복제는 RTO와 RPO 간의 잠재적 인 상충 관계에 대한 필요성을 창출 할 수 있습니다. 복제가 동기식이 될 수있는 대기 시간이 짧은 LAN 환경에서 기본 및 보조 데이터 세트를 동시에 업데이트 할 수 있습니다. 이를 통해 전체 복구가 자동 및 실시간으로 수행 될 수 있으므로 절충없이 가장 까다로운 복구 시간 및 복구 지점 목표 (각각 몇 초 및 0)를 만족시킬 수 있습니다. 대조적으로, WAN을 통해 주 서버가 모든 트랜잭션에 대한 업데이트 완료를 확인하기 위해 보조 서버가 성능을 저하시키는 것을 기다리도록 강요합니다. 이러한 이유로 WAN에서의 데이터 복제는 일반적으로 비동기입니다. 이로 인해 RTO와 RPO를 수용하는 것과 일반적으로 복구 시간이 길어지는 것 사이에 절충점이 생길 수 있습니다. 이유는 다음과 같습니다. RPO를 0으로 맞추기 위해서는 페일 오버가 발생할 수 있기 전에 모든 데이터 (예 : 트랜잭션 로그)가 2 차 서버에서 완전히 복제되었는지 확인하기 위해 수동 프로세스가 필요합니다.이 여분의 노력으로 복구 시간이 길어 지므로 이러한 구성 DR이 아닌 HA에 주로 사용됩니다.
ASR은 Azure의 DR as a a service (DRaaS) 오퍼링입니다. ASR은 실제 및 가상 시스템을 다른 Azure 사이트, 잠재적으로 다른 지역 또는 사내 구축 형 인스턴스에서 Azure 클라우드로 복제합니다. 이 서비스는 시스템 및 사이트 중단으로부터의 신속한 복구를 제공하고 롤링 소프트웨어 업그레이드 중 다운 타임을 제거함으로써 계획된 유지 보수를 용이하게합니다. 모든 DRaaS 오퍼링과 마찬가지로 ASR에는 몇 가지 제한 사항이 있습니다. 가장 심각한 것은 응용 프로그램 수준의 작동 중지 시간을 유발하는 여러 가지 장애로부터 자동으로 감지하고 장애 조치 할 수 없다는 것입니다. 물론 이것이 서비스가 HA가 아닌 DR을위한 것으로 특징 지워지는 이유입니다. ASR을 사용할 경우 복구 시간은 일반적으로 관리자가 수동으로 문제를 감지하고 대응할 수있는 속도에 따라 3-4 분이 소요됩니다. 위에서 설명한 것처럼 WAN을 통한 비동기 데이터 복제의 필요성은 RPO가 0 인 응용 프로그램의 복구 시간을 더욱 증가시킬 수 있습니다.
SQL Server는 장애 조치 클러스터 인스턴스 (여기에서 설명 함) 및 Always On Availability Groups (다음에 설명 함)의 두 가지 HA / DR 옵션을 제공합니다. FCI는 다음과 같은 두 가지 이점이 있습니다.이 기능은 저렴한 SQL Server Standard Edition에서 사용할 수 있으며 기존 HA 클러스터와 같은 공유 저장소를 사용하지 않아도됩니다. 후자의 이점은 Microsoft 나 다른 클라우드 서비스 제공 업체의 공유 스토리지를 단순히 클라우드에서 사용할 수 없기 때문에 중요합니다. Azure 클라우드의 저장소로 널리 사용되는 것은 광범위한 응용 프로그램을 지원하는 S2D (Storage Spaces Direct)이며 SQL Server에 대한 지원은 데이터베이스뿐 아니라 전체 인스턴스를 보호합니다. S2D의 가장 큰 단점은 서버가 단일 데이터 센터 내에 있어야한다는 것입니다.이 옵션은 일부 HA 요구에는 적합하지만 DR에는 적합하지 않습니다. 다중 사이트 HA 및 DR 보호의 경우 로그 전달 또는 타사 장애 조치 (Failover) 클러스터링 솔루션을 통해 필요한 데이터 복제를 제공해야합니다.
가용성 그룹 항상 가용성 그룹은 HA 및 DR 모두에 대해 SQL Server에서 가장 뛰어난 기능을 제공하지만보다 비싼 Enterprise Edition에 대한 라이센스가 필요합니다. 이 옵션은 5-10 초의 복구 시간과 초 이하의 복구 지점을 제공 할 수 있습니다. 또한 데이터베이스를 쿼리 할 수있는 보조 라이센스를 적절한 라이센스와 함께 제공하며 데이터베이스 크기 나 보조 인스턴스 수에 제한을 두지 않습니다. HA 및 DR 보호를 모두 제공하는 상시 가용성 그룹 구성은 단일 가용성 세트 또는 영역에 두 개의 노드가있는 3- 노드 구성과 개별 Azure 영역의 세 번째 노드로 구성됩니다. 한 가지 주목할만한 제한 사항은 데이터베이스 만 복제되고 다른 일부 수단으로 보호해야하는 전체 SQL 인스턴스가 아니라는 것입니다. 일부 데이터베이스 응용 프로그램의 경우 비용이 많이 드는 것 외에도 이러한 접근 방식에는 또 다른 단점이 있습니다. 응용 프로그램에 따라 IT 부서는 다른 모든 응용 프로그램에 대해 다른 HA 및 DR 조항을 구현해야합니다. 여러 HA / DR 솔루션을 사용하면 라이센스, 교육, 구현 및 지속적인 운영을 위해 복잡성과 비용이 크게 증가 할 수 있으므로 조직이 애플리케이션에 구속받지 않는 타사 솔루션을 선호하는 또 다른 이유가 있습니다.
애플리케이션에 독립적이며 플랫폼에 독립적 인 설계로 장애 조치 클러스터링 소프트웨어는 사설, 공용 및 하이브리드 클라우드 환경의 거의 모든 애플리케이션에 완벽한 HA 및 DR 솔루션을 제공 할 수 있습니다. 여기에는 Windows와 Linux가 모두 포함됩니다. 응용 프로그램에 의존하지 않으면 다양한 응용 프로그램에 대해 서로 다른 HA / DR 규정을 가질 필요가 없습니다. 플랫폼에 구속력이 없기 때문에 오류 도메인, 가용성 세트 및 영역, 지역 쌍 및 Azure 사이트 복구를 비롯하여 Azure 클라우드의 다양한 기능과 서비스를 활용할 수 있습니다. 완벽한 솔루션 인 소프트웨어에는 최소한 실시간 데이터 복제, 응용 프로그램 수준에서 장애를 감지 할 수있는 지속적인 모니터링 및 장애 조치 및 장애 복구 (failback and failback)를위한 구성 가능한 정책이 포함됩니다. 또한 대부분의 솔루션은 장애 조치 클러스터가 거의 모든 HA / DR 요구 사항을 충족시키기 위해 최소한의 데이터 손실 또는 20 초 미만의 복구 시간을 제공 할 수있는 다양한 부가 가치 기능을 제공합니다.
개별적으로 운영하든 콘서트에서 운영하든 네 가지 옵션 모두 DR 및 HA 보호의 연속성을 엔터프라이즈 애플리케이션의 전체 스펙트럼에 대해보다 효과적이고 저렴하게 만드는 역할을 할 수 있습니다. 여기에는 약간의 데이터 손실과 장기간의 가동 중단 시간을 허용 할 수있는 것부터 최소 5 분의 9의 가동 시간을 달성하기 위해 실시간 복구가 필요한 것까지 포함됩니다. 현실 세계에서 다음 클라우드 장애를 극복하기 위해 선택한 DR 및 / 또는 HA 조항에 따라 두 사이트에 두 개 이상의 노드가 분산되어 구성되어 있는지 확인하십시오. 또한 각 애플리케이션의 복구 시간 및 복구 지점 목표를 얼마나 만족시키는 지 반드시 이해하십시오. 모든 가능한 오류를 감지하는 데 필요한 수작업 프로세스의 필요성을 포함하여 존재할 수있는 제한 사항뿐만 아니라 응용 프로그램 연속성 및 데이터 무결성을 보장하는 방식으로 장애 조치를 유발합니다.
Jonathan Meltzer는 SIOS Technology의 제품 관리 담당 이사입니다. 그는 고객이 인적 자원 및 IT 자원을 관리, 변환 및 최적화 할 수 있도록 도와주는 소프트웨어 및 SaaS 제품에 대한 제품 관리 및 마케팅 분야에서 20 년 이상의 경력을 쌓았습니다. RTinsights에서 재현