Date: 1월 27, 2019
태그: 퍼블릭 클라우드 서비스 수준
공개 클라우드 서비스 수준이 짧아지는 경우의 옵션
모든 공용 클라우드 서비스 공급자는 가용성과 관련하여 몇 가지 형태의 보증을 제공합니다. 이는 각 애플리케이션의 가동 시간 요구 사항에 따라 충분하지 않을 수도 있습니다. 이러한 보증은 일반적으로 한 달 동안 가동 시간의 95.00 %에서 99.99 %에 이릅니다. 대부분 서비스 제공자는 이러한 임계 값에 미치지 못하는 이유로 "벌칙"을 부과합니다. 일반적으로 대부분의 클라우드 서비스 공급자는 99.00 %의 가동 시간을 제공합니다. 이는 한 달에 약 7 시간의 가동 중지 시간과 같습니다. 그리고 많은 응용 분야에서 2-9가 충분할 수 있습니다. 그러나 미션 크리티컬 애플리케이션의 경우 9 가지가 더 필요합니다. 특히 다운 타임의 많은 일반적인 원인이 보증에서 제외된다는 사실을 감안할 때. 물론 공용 클라우드 서비스를 사용하는 구성에서 독점적으로 또는 하이브리드 배열의 일부로 5 -9의 고 가용성 및 강력한 재해 복구 보호를 달성하는 비용 효율적인 방법이 있습니다. 이 기사에서는 공용 클라우드의 HA 및 DR 조항과 관련된 제한 사항을 강조합니다. 이 제한 사항을 극복하기위한 세 가지 옵션을 살펴보고 장애 조치 (failover) 클러스터에 대한 두 가지 공통 구성을 설명합니다.
클라우드의 Emptor 경고
모든 클라우드 서비스 공급자 (CSP)는 "가동 중지 시간"또는 "사용할 수 없음"을 다소 다르게 정의하지만 이러한 정의에는 응용 프로그램 수준에서 발생할 수있는 모든 장애 원인 중 제한된 집합 만 포함됩니다. 일반적으로 영역이나 영역에 영향을 미치는 오류 또는 외부 연결이 포함됩니다. 또한 모든 CSP는 가동 시간 4 ~ 9 분을 충족시키지 못하면 10 %에서 2 ~ 9 분의 가동 시간을 맞추지 못해 약 25 %까지 다양한 크레딧을 제공합니다. 중복 리소스는 CSP 인프라 내의 영역 및 / 또는 영역에 걸쳐 구성 할 수 있습니다. 응용 프로그램 수준 가용성을 향상시키는 데 도움이됩니다. 그러나 이러한 중복성이 있더라도 업무 핵심 응용 프로그램에서는 수용 할 수없는 몇 가지 제한 사항이 있습니다. 특히 트랜잭션 처리량이 높은 트랜잭션이 필요합니다. 이러한 제한 사항에는 각 마스터가 단일 장애 조치 복제본 만 만들 수있는 것이 포함됩니다. 또한 백업을 위해 마스터 데이터 집합을 사용하고 이벤트 로그를 사용하여 데이터를 복제해야합니다. 이러한 제한 사항 및 기타 제한 사항으로 인해 장애 발생시 복구 시간이 늘어나고 적어도 계획된 다운 타임을 계획해야합니다.
중요한 제한 사항
더 중요한 제한 사항에는 중단 시간을 구성하는 요소에 대한 많은 예외가 포함됩니다. 다음은 다음과 같은 결과로 인해 응용 프로그램 수준의 오류가 발생하는 "가동 중지 시간"또는 "비 가용성"에서 제외되는 실제 공용 클라우드 서비스 수준 계약의 몇 가지 예입니다.
- CSP의 합리적인 통제를 넘어서는 요소 (즉, 통신 사업자 네트워크 중단 및 자연 재해와 같이 정기적으로 발생하는 일부 요인)
- 고객 소프트웨어 또는 타사 소프트웨어 또는 기술 (응용 프로그램 소프트웨어 포함)
- 잘못된 입력이나 지시 또는 필요할 때의 행동 부족 (즉, 인간의 오류 가능성으로 야기되는 필연적 인 실수)
- 특정 상황에 기인하지 않는 개별 인스턴스 또는 볼륨의 문제 "사용 불가능"
- 계약에 따라 제공된 하드웨어 또는 소프트웨어 유지 보수
확실히, CSP는 특정 실패 원인을 제외하는 것이 합리적입니다. 그러나 시스템 관리자가이를 변명으로 사용하는 것은 무책임한 행동입니다. 다른 수단을 통해 응용 프로그램 수준의 가용성을 보장해야합니다.
어떤 공개 클라우드 서비스 수준을 사용할 수 있습니까?
보안이나 성능을 희생시키지 않는 방식으로 고 가용성을위한 리소스를 프로비저닝하는 것은 결코 쉬운 일이 아닙니다. 민간 및 공공 클라우드 인프라가 크게 다를 수있는 하이브리드 클라우드 환경에서는 특히 어려운 과제입니다. 구성을 테스트하고 유지 보수하기가 어렵습니다. 또한 실제로 필요한 경우 장애 조치 규정이 실패 할 수 있습니다. CSP에서 제공하는 서비스 수준이 부족한 응용 프로그램의 경우 응용 프로그램 자체, 운영 체제의 기능 또는 특수 목적의 장애 조치 클러스터링 소프트웨어를 사용하여 세 가지 추가 옵션을 사용할 수 있습니다.
응용 프로그램 수준 가용성 향상을위한 세 가지 옵션
HA / DR
가장 쉽게 구현할 수있는 HA / DR 옵션은 각 응용 프로그램에 맞게 특별히 설계된 옵션입니다. 좋은 예는 캐리어 급 Always Availability Groups 기능을 갖춘 Microsoft의 SQL Server 데이터베이스입니다. 그러나이 방법에는 두 가지 단점이 있습니다. 이 경우 Enterprise Edition에 대한 라이센스 비용이 높을수록 많은 비용이 소요될 수 있습니다. 그리고 더욱 어려워지는 단점은 다양한 애플리케이션에 대해 서로 다른 HA / DR 규정이 필요하다는 것입니다. 이로 인해 지속적인 관리가 끊임없이 (그리고 비용이 많이 드는) 투쟁을하게됩니다.
운영 체제에 통합 된 가동 시간 관련 기능
공개 클라우드 서비스 수준을 향상시키는 두 번째 옵션은 운영 체제에 통합 된 업타임 관련 기능을 사용하는 것입니다. 예를 들어 Windows Server 장애 조치 (Failover) 클러스터링은 OS에 내장 된 강력하고 검증 된 기능입니다. 그러나 자체적으로 WSFC는 데이터 복제 기능이 없기 때문에 완전한 HA / DR 솔루션을 제공하지 못할 수도 있습니다. 프라이빗 클라우드에서 스토리지 영역 네트워크와 같은 공유 스토리지의 형태를 사용하여 데이터 복제를 제공 할 수 있습니다. 그러나 공용 클라우드에서는 공유 스토리지를 사용할 수 없기 때문에 강력한 데이터 복제를 구현하려면 별도의 상업용 또는 사용자 정의 개발 소프트웨어를 사용해야합니다. WSFC와 같은 기능이없는 Linux의 경우 추가 HA / DR 규정 및 / 또는 사용자 정의 개발이 상당히 필요합니다. Pacemaker 및 Corosync와 같은 오픈 소스 소프트웨어를 사용하려면 각 응용 프로그램에 대한 사용자 정의 스크립트를 작성 (및 테스트)해야합니다. 이러한 스크립트는 사용되는 소프트웨어 나 하드웨어에 사소한 변경을 가한 후에도 업데이트하고 다시 테스트해야합니다. 그러나 모든 애플리케이션에 대해 전체 HA 스택을 제대로 작동시키는 것이 매우 어려울 수 있기 때문에 대규모 조직 만이 노력을 기울일 필요가있는 경우도 있습니다.
목적으로 구축 된 장애 조치 클러스터
이상적으로 공공 / 사설 / 하이브리드 클라우드를 통해 Windows 또는 Linux에서 실행되는 모든 응용 프로그램에 대해 비용 효율적으로 작업 할 수있는 HA / DR에 대한 "보편적 인"접근 방법이 있습니다. 가장 융통성 있고 저렴한 솔루션으로는 세 번째 옵션 인 특수 목적의 장애 조치 (failover) 클러스터가 있습니다. 이러한 HA / DR 솔루션은 가상 또는 실제 서버 클러스터 및 활성 또는 기본 인스턴스에서 대기로의 장애 조치를 통해 응용 프로그램에서의 고 가용성을 보장하기 위해 특별히 지정된대로 소프트웨어로 구현됩니다 수평.
이러한 솔루션의 이점
이러한 솔루션은 최소한 실시간 데이터 복제, 지속적인 애플리케이션 모니터링 및 구성 가능한 장애 조치 / 장애 복구 (Failover / Failback) 복구 정책을 제공합니다. 보다 강력한 기능 중 일부는 블록 수준의 동기식 또는 비동기식 복제, 저렴한 SQL Server Standard Edition의 FCI (Failover Cluster Instance) 지원, 향상된 성능 및 최소 대역폭을위한 WAN 최적화 등과 같은 고급 기능을 제공합니다. 활용 및 계획된 유지 관리를 용이하게하는 기본 및 보조 서버 할당의 수동 전환을 지원합니다. 이러한 범용 솔루션은 일반적으로 스토리지에 독립적이며 스토리지 영역 네트워크에서 작동 할 수 있도록 지원되지만 잠재적으로 단일 장애 지점을 제거 할 수있는 기능을 기반으로하는 SANless 장애 조치 클러스터가 일반적으로 선호됩니다.
두 가지 일반적인 장애 조치 (Failover) 클러스터링 구성
모든 장애 조치 클러스터는 두 개 이상의 노드로 구성됩니다. 다른 데이터 센터에있는 하나 이상의 노드를 찾는 것은 현지 재해로부터 보호하기 위해 필요합니다. 여기에는 두 가지 보편적 인 구성이 있습니다. 다른 하나는 미션 크리티컬 한 고 가용성 및 재해 복구를 제공합니다. 고 가용성 구성에서는 높은 트랜잭션 성능이 필요합니다. 예제 응용 프로그램은 데이터베이스입니다. 재해 복구를위한 기본 SANless 장애 조치 (failover) 클러스터에는 1 개의 주 노드와 1 개의 보조 또는 대기 서버 또는 서버 인스턴스가있는 두 개의 노드가 있습니다. 또한이 최소한의 구성에서는 주 서버의 할당을 결정하기위한 쿼럼을 달성하는 데 필요한 세 번째 노드 또는 인스턴스가 감시 서버로 작동해야합니다. 데이터베이스 응용 프로그램의 경우 WAN을 통해 대기 인스턴스로 복제하면 비동기로 기본 인스턴스에서 높은 성능을 유지합니다. SANless 장애 조치 클러스터는 기본 장애시 빠른 복구를 제공합니다. 많은 응용 분야에 적합한 기본 DR 구성이 가능합니다. 공용 클라우드 서비스의 가동 중지 시간으로 계산되지 않은 오류를 포함하여 가능한 모든 오류를 감지 할 수 있습니다. 따라서 개인용, 공용 또는 하이브리드 클라우드 환경에서 작동합니다. 예를 들어, 기본 클라우드는 공용 클라우드에 보조 클라우드가 배치 된 엔터프라이즈 데이터 센터에있을 수 있습니다. 퍼블릭 클라우드 인스턴스는 계획된 기본 유지 보수 또는 장애 발생시 신속하게 해결할 수있는 경우에만 필요하므로 위에 언급 된 서비스 제한 사항 및 예외 사항은 모든 업무용 응용 프로그램의.
3 노드 SANless 장애 조치 (failover) 클러스터
회복
서버 # 1의 고장 직후에 IT 직원은 문제를 일으킨 원인을 진단하고 수리하기 시작합니다. 고정 된 후에는 서버 # 1이 수동 장애 복구를 통해 기본 서버로 복원되거나 서버 # 2가 서버 # 1 및 # 3에 대한 기본 복제 데이터로 계속 작동 할 수 있습니다. 서버 # 1이 작동하기 전에 서버 # 2가 실패하면 서버 # 3이 기본 서버가됩니다. 서버 # 3은 퍼블릭 클라우드의 WAN을 통해 있기 때문에 데이터 복제는 비동기 적이며 장애 조치는 수동으로 이루어져 "복제 지연"으로 인한 데이터 손실을 방지합니다. SANless 장애 조치 클러스터링 소프트웨어는 응용 프로그램 수준에서 발생할 수있는 모든 오류를 감지 할 수 있습니다. 위에서 언급 한 CSP 제한 사항 및 예외 사항을 쉽게 해결합니다. 따라서이 3 노드 구성을 전적으로 공용 클라우드 내에 배치 할 수 있습니다. 즉시 및 자동 장애 조치를 기반으로 동일한 5 -9의 고 가용성을 제공하려면 서버 # 1 및 # 2가 LAN이 동기 복제를 용이하게하는 단일 영역 또는 지역 내에 위치해야합니다. 적절한 DR 보호를 위해서는 높은 트랜잭션 처리량이 필요한 응용 프로그램의 경우 비동기 복제 및 수동 장애 조치 / 장애 복구를 사용해야하는 다른 데이터 센터 또는 지역에 서버 3을 배치해야합니다. 3 노드 클러스터는 세 서버 모두에 대해 계획된 하드웨어 및 소프트웨어 유지 관리를 용이하게합니다. 동시에 응용 프로그램과 해당 데이터에 대한 지속적인 DR 보호를 계속 제공하십시오. 지리적으로 분산 된 여러 데이터 센터를 제공함으로써 공개 클라우드는 가용성을 향상시키고 DR 조항을 향상시킬 수있는 수많은 기회를 제공합니다. SANless 장애 조치 클러스터링 소프트웨어는 모든 컴퓨팅, 스토리지 및 네트워크 리소스를 효과적이고 효율적으로 사용합니다. 또한 구현 및 운영하기가 쉽습니다. 이러한 특수 목적 솔루션은 모든 자본 및 운영 비용을 최소화합니다. 마지막으로 고 가용성이 그 어느 때보다도 강력하고 저렴 해졌습니다. # # #
저자 정보
Cassius Rhue는 SIOS Technology의 엔지니어링 이사입니다. 그는 렉싱턴 (SC)의 소프트웨어 제품 개발 및 엔지니어링 팀을 이끌고 있습니다. Cassius는 17 년 이상의 소프트웨어 엔지니어링, 개발 및 테스트 경험을 보유하고 있습니다. 그는 또한 사우스 캐롤라이나 대학 (University of South Carolina)에서 컴퓨터 공학 학사 학위를 취득했습니다.