퍼블릭 클라우드 인프라는 IT 전략의 많은 측면을 변화시켰지만 한 가지는 변하지 않았습니다. 고 가용성 클라우드에서. 오늘날 모든 비즈니스가 그렇듯이 데이터가 비즈니스인 경우 손실은 심각한 결과를 초래할 수 있습니다. 그 위험을 최소화하기 위해 최선을 다해야 합니다. 당연히 고가용성은 온프레미스와 클라우드 모두에서 스토리지 공급업체의 핵심 초점 영역이지만 모든 공급업체가 동일한 접근 방식을 취하는 것은 아닙니다. 차이점이 무엇인지, 왜 중요한지 이해하는 것은 데이터와 비즈니스를 위한 올바른 선택을 하는 데 필수적입니다.
고가용성은 영리한 네트워크 트릭에 의존
온프레미스에서 고가용성은 일반적으로 몇 가지 영리한 네트워크 트릭에 의존합니다. 그 중 하나는 유동 IP 주소의 개념입니다. 즉, 하나의 장치에만 속하지 않고 장치 클러스터 간에 공유되는 하나 이상의 IP 주소입니다. 클라이언트는 이러한 유동 IP 주소를 사용하여 클러스터된 장치에서 제공하는 콘텐츠에 액세스하므로 장치 오류가 발생하는 경우 클라이언트의 연결이 한 장치에서 다른 장치로 원활하게 전환될 수 있습니다. 부동 IP 주소를 실패한 장치에서 멀리 돌리는 데 사용할 수 있는 몇 가지 다른 메커니즘이 있습니다. 예를 들어 F5 Networks BIG-IP 플랫폼과 Qumulo는 모두 파일 패브릭 Gratuitous ARP라는 기술을 사용하여 이전에 다른 노드에서 제공한 유동 IP 주소를 인수합니다. 다른 시스템은 라이브 장치만 트래픽을 수신하도록 비동기 라우팅을 사용합니다. 두 경우 모두 문제가 있는 노드에서 작동 중인 노드로 원활한 장애 조치 기능을 활성화하는 것은 네트워크 자체입니다.
In 퍼블릭 클라우드 환경, 귀하는 네트워크를 소유하거나 제어하지 않습니다. 여기에서 활성화할 기능을 지정하는 것은 Amazon, Microsoft 또는 Google입니다. Amazon Web Services(AWS)의 경우 이러한 선택에는 ARP 캐시 포이즈닝(ARP 스푸핑 또는 ARP 포이즌 라우팅이라고도 함)과 같은 남용 위험을 방지하기 위해 ARP 비활성화가 포함됩니다. 즉, 고가용성을 위해 ARP에 의존하여 사용하던 온프레미스 어플라이언스가 작동하지 않습니다. 결과적으로 인프라 공급업체는 클라우드 고가용성을 위해 다른 접근 방식을 찾아야 합니다.
AWS용 Qumulo를 사용해 클라우드에서 파일 스토리지를 경험하십시오.
클라우드의 고가용성을 위한 옵션
클라우드에서 고가용성을 위한 옵션은 두 가지 기본 접근 방식으로 귀결됩니다. 온프레미스에서 수행한 것과 본질적으로 유사한 해결 방법을 찾거나 IP 장애 조치를 위한 새로운 클라우드 전용 방법을 작성할 수 있습니다.
해결 방법의 예는 다음과 같습니다. NetApp ONTAP은 AWS의 IP 장애 조치에 사용. 기존의 스케일업 스토리지 아키텍처인 NetApp은 데이터가 노드 간에 지속적으로 미러링되는 쌍을 이루는 노드에 의존합니다. 이 경우 데이터 저장소의 두 복사본을 효과적으로 유지 관리하고 있으므로 사용된 노드와 사용되지 않은 노드 모두에 대해 컴퓨팅, 스토리지 및 소프트웨어 비용이 발생합니다. 이를 자동차 보험의 한 형태로 생각하면 상대적으로 낮은 월 요금을 지불하는 대신 첫 번째 자동차에 문제가 발생할 경우 두 번째 자동차를 통째로 구입하여 위험을 감수합니다. 이러한 배포는 활성/대기 또는 활성/활성 구성에서 실행할 수 있습니다. 둘 다 데이터를 완전히 복제해야 합니다. 이제 이 배포 자체는 IP 장애 조치를 제공하지 않습니다. 이를 위해서는 NetApp Cloud Manager라고 하는 세 번째 컴퓨팅 시스템을 배포해야 합니다.
Cloud Manager는 ONTAP 시스템의 구성을 처리하고 장애 조치를 제공하는 전용 t2.micro 인스턴스(위에서 "중재자"로 표시)입니다. Cloud Manager는 장애를 감시한 다음 필요에 따라 활성에서 대기로 IP 라우팅을 변경합니다. vCPU가 2개이고 RAM이 2GB인 AWS EC1 인스턴스 유형인 t1.micro를 자세히 살펴보기 전까지는 모든 것이 잘 들립니다. 고가용성 전략의 핵심으로 삼는다는 것은 활성 노드의 단일 실패 지점에서 장애 조치 메커니즘 자체의 더 작은 단일 실패 지점으로 이동하는 것을 의미합니다.
애자일 소프트웨어 회사인 Qumulo는 아무리 어려운 문제라도 각 문제에 대한 올바른 솔루션을 진지하게 고민하고 고객을 위해 구축할 수 있는 위치에 있습니다. 클라우드의 고가용성에 대한 ONTAP 접근 방식의 복잡성과 위험을 고려하여 처음부터 시작하여 더 간단하고 안정적인 방법을 찾았습니다.
온프레미스 모델을 퍼블릭 클라우드 환경에 강제로 맞추는 대신 클라우드를 위해 특별히 설계된 특수 목적의 IP 장애 조치를 구축했습니다. 핵심은 각 퍼블릭 클라우드 플랫폼에서 사용할 수 있는 기능을 활용하는 것입니다. 예를 들어, 클러스터의 모든 작업 구성원에서 AWS API를 사용하여 다운된 클러스터 구성원에서 작동 중인 구성원으로 유동 IP 주소를 스윙합니다. 이러한 방식으로 복잡성의 또 다른 계층을 추가하지 않고 병목 현상이 쉽게 발생할 수 있는 단일 실패 지점을 도입하지도 않았습니다. 추가적인 이점으로, 우리의 접근 방식은 중복 대기 클러스터의 필요성을 제거하여 고가용성 비용을 크게 줄입니다.
클라우드에서 고가용성을 고려해야 하는 이유
이제 보증이 주어진다면 퍼블릭 클라우드의 고가용성에 관심을 가져야 하는 이유가 궁금할 것입니다. 이것들처럼 Amazon에서 :
“Amazon EBS 볼륨은 0.1% – 0.2% 사이의 연간 장애율(AFR)을 위해 설계되었습니다. 여기서 장애는 볼륨의 크기와 성능에 따라 볼륨의 전체 또는 부분 손실을 의미합니다. … 예를 들어, 1,000년 동안 1개의 EBS 볼륨이 실행되고 있다면 1~2개에서 장애가 발생할 것으로 예상해야 합니다.”
진짜 질문은 데이터 손실을 방지하는 것이 온프레미스에서 해결된 문제일 때 클라우드에서 연간 XNUMX~XNUMX개의 손실된 EBS 볼륨을 수용하는 이유입니다. 미디어 및 엔터테인먼트, 유전학 연구, 자율 주행 또는 홈 폴더와 같은 단순한 비즈니스에 관계없이 귀하의 데이터는 소중합니다. 매년 잃어 버리는 EBS 볼륨에는 무엇이있을 수 있습니까? 그들의 손실은 귀하의 비즈니스에 어떤 영향을 미칩니까? 알 수 있는 방법은 없으며 이는 어떤 기업도 부담 없이 감수할 수 있는 위험입니다.
그리고 Amazon의 보증은 생각보다 높을 수 있는 컴퓨팅 노드 실패율을 고려하지도 않습니다. EC2 인스턴스는 여러 가지 흥미로운 이유로 실패할 수 있습니다. 한 가지 일반적인 경우는 AWS가 핵심적으로 공유 하드웨어의 데이터 센터라는 사실에서 비롯됩니다. 하드웨어의 일부가 유지 관리를 받거나 폐기될 경우 EC2 인스턴스를 이동해야 하며 이로 인해 재부팅이 발생합니다. 훨씬 더 간단한 예는 기본 하드웨어 부분에 오류가 있어 해당 하드웨어가 호스팅하는 모든 인스턴스가 다른 하드웨어 부분으로 이동하여 해당 인스턴스가 재부팅되는 경우입니다. 재부팅하면 노드가 일시적으로 실패한 것으로 나타나므로 트래픽을 활성 노드로 전환해야 합니다.
컴퓨팅 노드가 다운되면 ONTAP은 활성 노드에서 남아 있는 노드로 장애 조치됩니다. 물론 실패한 것이 t2.micro NetApp Cloud Manager가 아닌 한. 이런 일이 발생하면 공용 클라우드의 모든 스토리지 트래픽에 대한 항공 교통 통제를 잃게 되며 장애가 발생한 노드에서 살아남은 노드로 클라이언트를 이동할 수 없습니다. 이제 진짜 문제가 생겼습니다. 실패한 노드의 위험을 해결하기 위해 NetApp Cloud Manager는 결국 새로운 실패 조건을 혼합에 추가합니다. 확실히 우리는 차세대 엔터프라이즈 아키텍처에 대해 더 나은 것을 기대할 수 있습니다.
조심스러운 이야기…
NetApp ONTAP은 경고의 역할을 합니다. 이러한 환경의 고유한 차이점을 고려하지 않고 레거시 기술을 퍼블릭 클라우드로 이동하는 방법에 대해 설명합니다. Qumulo의 클라우드 네이티브 접근 방식을 사용하면 추가 복잡성을 도입하지 않고 과도한 비용을 들이지 않고도 디스크 및 노드 장애를 극복할 수 있습니다. 시간을 할애하여 각 유형의 인프라(온프레미스 및 퍼블릭 클라우드)에 대해 올바른 방식으로 작업을 수행함으로써 비즈니스가 의존하는 데이터에 필요한 간단하고 안정적인 고가용성을 제공할 수 있습니다.
