AERODISK 엔진: 재해 저항성. 2부. 메트로클러스터

안녕하세요, 하브르 독자 여러분! 지난 기사에서는 AERODISK ENGINE 스토리지 시스템의 간단한 재해 복구 수단인 복제에 대해 설명했습니다. 이 기사에서는 더 복잡하고 흥미로운 주제인 메트로 클러스터, 즉 데이터 센터가 활성-활성 모드에서 작동할 수 있도록 두 데이터 센터에 대한 자동화된 재해 보호 수단인 메트로 클러스터에 대해 살펴보겠습니다. 우리는 당신에게 말하고, 보여주고, 부수고 고치겠습니다.

늘 그렇듯 이론 먼저

메트로 클러스터는 도시나 지역 내의 여러 사이트에 분산된 클러스터입니다. "클러스터"라는 단어는 컴플렉스가 자동화되어 있음을 분명히 암시합니다. 즉, 오류 발생 시 클러스터 노드 전환이 자동으로 발생합니다.

여기에 메트로 클러스터와 일반 복제의 주요 차이점이 있습니다. 운영 자동화. 즉, 특정 사고(데이터 센터 장애, 채널 중단 등)가 발생하는 경우 스토리지 시스템은 데이터 가용성을 유지하기 위해 필요한 조치를 독립적으로 수행합니다. 일반 복제본을 사용하는 경우 이러한 작업은 관리자가 전체 또는 부분적으로 수동으로 수행합니다.

어떤 거지?

특정 메트로 클러스터 구현을 사용할 때 고객이 추구하는 주요 목표는 RTO(복구 시간 목표)를 최소화하는 것입니다. 즉, 장애 발생 후 IT 서비스의 복구 시간을 최소화하는 것입니다. 일반 복제를 사용하는 경우 복구 시간은 메트로 클러스터를 사용한 복구 시간보다 항상 길어집니다. 왜? 매우 간단합니다. 관리자는 자신의 책상에 있어야 하며 복제를 수동으로 전환해야 하며 메트로 클러스터는 이 작업을 자동으로 수행합니다.

잠도 안 자고, 밥도 안 먹고, 담배도 안 피우고, 아프지도 않고, 24시간 스토리지 시스템의 상태를 감시하는 전담 관리자가 없다면 관리자가 이를 보장할 방법이 없다. 장애 시 수동 전환이 가능합니다.

따라서 메트로 클러스터가 없거나 99단계 관리자 직무 서비스의 불멸의 관리자가 없는 경우의 RTO는 모든 시스템의 전환 시간과 관리자가 작업을 시작할 수 있는 최대 기간의 합과 같습니다. 스토리지 시스템 및 관련 시스템.

따라서 우리는 RTO 요구 사항이 몇 시간이나 며칠이 아닌 몇 분이면 메트로 클러스터를 사용해야 한다는 분명한 결론에 도달합니다. 즉, 최악의 데이터 센터 장애가 발생하는 경우 IT 부서는 비즈니스에 시간을 제공해야 합니다. 몇 분, 심지어 몇 초 내에 IT 서비스에 대한 액세스를 복원합니다.

어떻게 작동합니까?

하위 수준에서 메트로 클러스터는 이전 기사에서 설명한 동기식 데이터 복제 메커니즘을 사용합니다. 링크). 복제는 동기식이므로 이에 대한 요구 사항은 다음과 같습니다.

• 물리적인 광섬유, 10기가비트 이더넷(또는 그 이상);
• 데이터 센터 사이의 거리는 40km를 넘지 않습니다.
• 데이터 센터 간(스토리지 시스템 간) 광 채널 지연은 최대 5밀리초(최적은 2밀리초)입니다.

이러한 모든 요구 사항은 본질적으로 권고 사항입니다. 즉, 이러한 요구 사항이 충족되지 않더라도 메트로 클러스터는 작동하지만 이러한 요구 사항을 준수하지 않으면 두 스토리지 시스템의 작동 속도가 느려지는 것과 동일하다는 점을 이해해야 합니다. 메트로 클러스터.

그렇다면 동기식 복제본은 스토리지 시스템 간에 데이터를 전송하는 데 사용되며, 복제본은 어떻게 자동으로 전환되며, 가장 중요한 것은 분할 브레인을 방지하는 방법입니다. 이를 위해 더 높은 수준에서 중재자라는 추가 엔터티가 사용됩니다.

중재인은 어떻게 일하고 그의 임무는 무엇입니까?

중재자는 세 번째 사이트(예: 사무실)에서 실행되어야 하고 ICMP 및 SSH를 통해 스토리지 시스템에 대한 액세스를 제공해야 하는 소규모 가상 머신 또는 하드웨어 클러스터입니다. 실행 후 중재자는 IP를 설정해야 하며, 스토리지 측에서 해당 주소와 메트로 클러스터에 참여하는 원격 컨트롤러의 주소를 표시해야 합니다. 그 후 심판은 작업 준비가 완료됩니다.

중재자는 메트로 클러스터의 모든 스토리지 시스템을 지속적으로 모니터링하고 특정 스토리지 시스템을 사용할 수 없는 경우 클러스터의 다른 구성원("라이브" 스토리지 시스템 중 하나)에서 사용할 수 없음을 확인한 후 복제 규칙 전환 절차를 시작하기로 결정합니다. 그리고 매핑.

매우 중요한 점입니다. 중재인은 항상 스토리지 시스템이 위치한 장소와 다른 장소, 즉 스토리지 시스템 1이 설치된 데이터 센터 1이나 스토리지 시스템 2가 설치된 데이터 센터 2에 위치하지 않아야 합니다.

왜? 이것이 중재자가 살아남은 스토리지 시스템 중 하나의 도움을 받아 스토리지 시스템이 설치된 두 사이트 중 어느 사이트의 몰락을 명확하고 정확하게 결정할 수 있는 유일한 방법이기 때문입니다. 중재자를 배치하는 다른 방법으로 인해 브레인 분할이 발생할 수 있습니다.

이제 중재인의 업무를 자세히 살펴보겠습니다.

중재자는 모든 스토리지 컨트롤러를 지속적으로 폴링하는 여러 서비스를 실행합니다. 폴링 결과가 이전 결과와 다른 경우(사용 가능/사용 불가능) 소규모 데이터베이스에 기록되며 이는 중재자에서도 작동합니다.

중재인의 작업 논리를 더 자세히 살펴 보겠습니다.

1단계: 가용성을 확인합니다. 스토리지 시스템 오류 이벤트는 5초 이내에 동일한 스토리지 시스템의 두 컨트롤러 모두에서 ping이 없는 것입니다.

2단계. 전환 절차를 시작합니다. 중재자는 스토리지 시스템 중 하나를 사용할 수 없다는 사실을 깨달은 후 "죽은" 스토리지 시스템이 실제로 죽었는지 확인하기 위해 "라이브" 스토리지 시스템에 요청을 보냅니다.

두 번째(라이브) 저장 시스템은 중재자로부터 이러한 명령을 받은 후 타락한 첫 번째 저장 시스템의 가용성을 추가로 확인하고, 존재하지 않는 경우 중재자에게 추측에 대한 확인을 보냅니다. 실제로 스토리지 시스템을 사용할 수 없습니다.

이러한 확인을 받은 후 중재자는 손상된 스토리지 시스템에서 활성(기본)이었던 복제본에 대해 복제를 전환하고 매핑을 높이기 위한 원격 절차를 시작하고 두 번째 스토리지 시스템에 명령을 보내 이러한 복제본을 보조에서 기본으로 변경하고 매핑을 올립니다. 따라서 두 번째 스토리지 시스템은 이러한 절차를 수행한 다음 자체적으로 손실된 LUN에 대한 액세스를 제공합니다.

추가 확인이 필요한 이유는 무엇입니까? 정족수용. 즉, 총 홀수(3)개의 클러스터 구성원 중 다수가 클러스터 노드 중 하나의 하락을 확인해야 합니다. 그래야만 이 결정이 확실히 옳을 것입니다. 이는 잘못된 전환과 그에 따른 분할 브레인을 방지하기 위해 필요합니다.

시간 단계 2에는 약 5~10초가 소요됩니다. 따라서 가용성 확인에 필요한 시간(5초)을 고려하면 사고 후 10~15초 이내에 손상된 스토리지 시스템의 LUN이 자동으로 라이브 작업에 사용할 수 있게 됩니다. 저장 시스템.

호스트와의 연결이 끊어지지 않도록 하려면 호스트에서 시간 초과를 올바르게 구성하도록 주의해야 한다는 점은 분명합니다. 권장되는 제한 시간은 30초 이상입니다. 이렇게 하면 재해 발생 시 로드 전환 중에 호스트에서 스토리지 시스템에 대한 연결이 끊어지는 것을 방지하고 I/O 중단이 발생하지 않도록 할 수 있습니다.

잠깐만요. 메트로 클러스터의 모든 것이 양호하다면 왜 정기적인 복제가 필요한가요?

실제로 모든 것이 그렇게 간단하지 않습니다.

메트로 클러스터의 장단점을 고려해 봅시다

따라서 우리는 기존 복제에 비해 메트로 클러스터의 확실한 장점은 다음과 같다는 것을 깨달았습니다.

• 완전 자동화로 재해 발생 시 복구 시간을 최소화합니다.
• 그게 다야 :-).

이제 주의할 점은 단점입니다.

• 솔루션 비용. Aerodisk 시스템의 메트로 클러스터에는 추가 라이선스가 필요하지 않지만(복제본과 동일한 라이선스가 사용됨) 솔루션 비용은 여전히 ​​동기 복제를 사용하는 것보다 훨씬 높습니다. 동기 복제본에 대한 모든 요구 사항과 추가 전환 및 추가 사이트와 관련된 메트로 클러스터에 대한 요구 사항을 구현해야 합니다(메트로 클러스터 계획 참조).
• 솔루션의 복잡성. 메트로 클러스터는 일반 복제본보다 훨씬 복잡하며 계획, 구성 및 문서화에 훨씬 더 많은 주의와 노력이 필요합니다.

결국. Metrocluster는 실제로 몇 초 또는 몇 분 안에 RTO를 제공해야 하는 경우 기술적으로 매우 진보된 훌륭한 솔루션입니다. 그러나 그러한 작업이 없고 몇 시간 안에 RTO가 비즈니스에 적합하다면 대포에서 참새를 쏘는 것은 의미가 없습니다. 메트로 클러스터는 추가 비용을 발생시키고 IT 인프라를 복잡하게 만들기 때문에 일반적인 노동자-농민 복제로 충분합니다.

메트로 클러스터 계획

이 섹션은 메트로 클러스터 설계에 대한 포괄적인 가이드는 아니지만 그러한 시스템을 구축하기로 결정한 경우 수행해야 할 주요 방향만 보여줍니다. 따라서 실제로 메트로 클러스터를 구현할 때에는 반드시 스토리지 시스템 제조사(즉, 당사)와 기타 관련 시스템을 참여시켜 협의를 진행하시기 바랍니다.

장소

위에서 설명한 대로 메트로 클러스터에는 최소 XNUMX개의 사이트가 필요합니다. 스토리지 시스템 및 관련 시스템이 운영될 두 개의 데이터 센터와 중재자가 근무할 세 번째 사이트입니다.

데이터 센터 간 권장 거리는 40km를 넘지 않습니다. 거리가 멀면 추가 지연이 발생할 가능성이 높으며 이는 메트로 클러스터의 경우 매우 바람직하지 않습니다. 지연 시간은 최대 5밀리초여야 하지만 2밀리초 이내로 유지하는 것이 좋습니다.

계획 과정에서도 지연을 확인하는 것이 좋습니다. 데이터 센터 간에 광섬유를 제공하는 어느 정도 성숙한 공급자는 품질 검사를 매우 신속하게 구성할 수 있습니다.

중재자 이전의 지연(즉, 세 번째 사이트와 처음 두 사이트 사이)의 경우 권장되는 지연 임계값은 최대 200밀리초입니다. 즉, 인터넷을 통한 일반 기업 VPN 연결이 적합합니다.

스위칭 및 네트워킹

서로 다른 사이트의 스토리지 시스템을 연결하는 것으로 충분한 복제 체계와 달리 메트로 클러스터 체계는 호스트를 서로 다른 사이트의 두 스토리지 시스템과 모두 연결해야 합니다. 차이점이 무엇인지 더 명확하게 하기 위해 두 가지 구성표가 아래에 표시됩니다.

다이어그램에서 볼 수 있듯이 사이트 1 호스트는 스토리지 시스템 1과 스토리지 시스템 2를 모두 봅니다. 또한 사이트 2 호스트는 스토리지 시스템 2와 스토리지 시스템 1을 모두 봅니다. 즉, 각 호스트에는 두 스토리지 시스템이 모두 표시됩니다. 이는 메트로 클러스터 작동을 위한 전제 조건입니다.

물론, 광 코드를 사용하여 각 호스트를 다른 데이터 센터에 연결할 필요가 없으며 포트나 코드만으로는 충분하지 않습니다. 이러한 모든 연결은 이더넷 10G+ 또는 FibreChannel 8G+ 스위치를 통해 이루어져야 합니다(FC는 IO용 호스트 및 스토리지 시스템 연결에만 사용되며 복제 채널은 현재 IP(이더넷 10G+)를 통해서만 사용할 수 있습니다.

이제 네트워크 토폴로지에 대해 몇 마디 하겠습니다. 중요한 점은 서브넷을 올바르게 구성하는 것입니다. 다음 유형의 트래픽에 대해 여러 서브넷을 즉시 정의해야 합니다.

• 스토리지 시스템 간에 데이터가 동기화되는 복제 서브넷입니다. 그 중 여러 개가 있을 수 있습니다. 이 경우에는 중요하지 않으며 모두 현재(이미 구현된) 네트워크 토폴로지에 따라 다릅니다. 그 중 두 개가 있는 경우 분명히 둘 사이에 라우팅을 구성해야 합니다.
• 호스트가 스토리지 리소스에 액세스하는 데 사용되는 스토리지 서브넷(iSCSI인 경우) 각 데이터 센터에는 이러한 서브넷이 하나씩 있어야 합니다.
• 제어 서브넷, 즉 스토리지 시스템이 관리되는 XNUMX개 사이트에 라우팅 가능한 XNUMX개의 서브넷이 있으며 중재자도 여기에 위치합니다.

여기서는 호스트 리소스에 액세스하기 위한 서브넷을 고려하지 않습니다. 서브넷은 작업에 크게 의존하기 때문입니다.

서로 다른 트래픽을 서로 다른 서브넷으로 분리하는 것은 매우 중요합니다(복제본을 I/O에서 분리하는 것이 특히 중요함). 왜냐하면 모든 트래픽을 하나의 "두꺼운" 서브넷에 혼합하면 이 트래픽을 관리할 수 없게 되기 때문입니다. 두 데이터 센터의 조건에 따라 여전히 다른 네트워크 충돌 옵션이 발생할 수 있습니다. 네트워크 장비 제조업체의 리소스를 사용하여 데이터 센터 간에 확장된 네트워크 계획에 대해 자세히 설명할 수 있으므로 이 기사의 틀 내에서는 이 문제를 깊이 다루지 않을 것입니다.

중재자 구성

중재자는 ICMP 및 SSH 프로토콜을 통해 스토리지 시스템의 모든 관리 인터페이스에 대한 액세스를 제공해야 합니다. 중재자의 안전 장치에 대해서도 생각해야 합니다. 여기에는 뉘앙스가 있습니다.

Arbiter 장애 조치는 매우 바람직하지만 필수는 아닙니다. 심판이 잘못된 시간에 충돌하면 어떻게 되나요?

• 일반 모드의 메트로 클러스터 작동은 변경되지 않습니다. arbtir는 일반 모드에서 메트로 클러스터의 작동에 전혀 영향을 미치지 않습니다(그 작업은 적시에 데이터 센터 간에 로드를 전환하는 것입니다).
• 더욱이, 어떤 이유로든 중재자가 데이터 센터에서 사고로 넘어져 "잠든" 경우 필요한 전환 명령을 내리고 정족수를 구성할 사람이 없기 때문에 전환이 발생하지 않습니다. 이 경우 메트로 클러스터는 복제가 포함된 일반 구성표로 전환되며 재해 발생 시 수동으로 전환해야 하며 이는 RTO에 영향을 미칩니다.

이것으로부터 무엇이 나오나요? 최소 RTO를 보장해야 하는 경우 중재자가 내결함성을 갖추고 있는지 확인해야 합니다. 이에 대한 두 가지 옵션이 있습니다.

• 내결함성 하이퍼바이저에서 중재자가 있는 가상 머신을 시작합니다. 다행히 모든 성인용 하이퍼바이저는 내결함성을 지원합니다.
• 세 번째 사이트(기존 사무실)에서 일반 클러스터를 설치하기에는 너무 게으르고 기존 Hypervozor 클러스터가 없는 경우, 우리는 두 개의 일반 클러스터가 있는 2U 상자에 만들어진 중재자의 하드웨어 버전을 제공했습니다. x-86 서버는 작동하며 로컬 오류에도 살아남을 수 있습니다.

일반 모드에서는 메트로 클러스터가 필요하지 않음에도 불구하고 중재자의 내결함성을 보장하는 것이 좋습니다. 그러나 이론과 실제 모두에서 알 수 있듯이 진정으로 신뢰할 수 있는 재해 방지 인프라를 구축한다면 안전하게 플레이하는 것이 더 좋습니다. "비열한 법칙", 즉 중재인과 스토리지 시스템이 위치한 사이트 중 하나의 실패로부터 자신과 귀하의 비즈니스를 보호하는 것이 좋습니다.

솔루션 아키텍처

위의 요구 사항을 고려하면 다음과 같은 일반적인 솔루션 아키텍처를 얻을 수 있습니다.

심각한 과부하를 방지하려면 LUN을 두 사이트에 고르게 분산해야 합니다. 동시에, 두 데이터 센터 모두에서 크기를 조정할 때 두 배의 볼륨(두 개의 스토리지 시스템에 동시에 데이터를 저장하는 데 필요함)뿐만 아니라 애플리케이션 성능 저하를 방지하기 위해 IOPS 및 MB/s의 두 배 성능도 포함해야 합니다. 데이터 센터 중 하나에 장애가 발생한 경우 ov.

이와 별도로, 크기 조정에 대한 적절한 접근 방식을 사용하면(즉, IOPS 및 MB/s의 적절한 상한과 필요한 CPU 및 RAM 리소스를 제공한 경우) 다음 스토리지 시스템 중 하나가 메트로 클러스터에 장애가 발생하더라도 하나의 스토리지 시스템에서 임시 작업을 수행하는 경우 성능이 크게 저하되지는 않습니다.

이는 두 사이트가 동시에 작동할 때 각 트랜잭션이 두 개의 스토리지 시스템(RAID-1/10과 유사)에 기록되어야 하기 때문에 동기식 복제가 쓰기 성능의 절반을 "먹는다"는 사실로 설명됩니다. 따라서 스토리지 시스템 중 하나에 장애가 발생하면 일시적으로(장애가 발생한 스토리지 시스템이 복구될 때까지) 복제의 영향이 사라지고 쓰기 성능이 두 배로 향상됩니다. 장애가 발생한 스토리지 시스템의 LUN이 작동 중인 스토리지 시스템에서 다시 시작되면 다른 스토리지 시스템의 LUN에서 로드가 나타나기 때문에 이 두 배의 증가는 사라지고 이전과 동일한 수준의 성능으로 돌아갑니다. "가을", 그러나 한 사이트의 틀 내에서만 가능합니다.

적절한 사이징을 통해 사용자가 전체 스토리지 시스템의 오류를 전혀 느끼지 않는 조건을 보장할 수 있습니다. 그러나 다시 한 번 반복합니다. 이를 위해서는 매우 신중한 크기 조정이 필요하며 무료로 문의하실 수 있습니다 :-).

메트로 클러스터 설정

메트로 클러스터 설정은 일반 복제 설정과 매우 유사합니다. 이전 기사. 따라서 차이점에만 집중하겠습니다. 우리는 위의 아키텍처를 기반으로 실험실에 최소 버전의 벤치를 설치했습니다. 즉, 10G 이더넷을 통해 연결된 두 개의 스토리지 시스템, 두 개의 10G 스위치 및 10G 포트가 있는 두 스토리지 시스템의 스위치를 살펴보는 하나의 호스트입니다. 중재자는 가상 머신에서 실행됩니다.

복제본에 대한 가상 IP(VIP)를 구성할 때 메트로 클러스터에 대해 VIP 유형을 선택해야 합니다.

두 개의 LUN에 대해 두 개의 복제 링크를 생성하여 이를 두 개의 스토리지 시스템, 즉 스토리지 시스템 1의 LUN TEST 기본(METRO 링크), LUN TEST2 스토리지 시스템 2의 기본(METRO2 링크)에 배포했습니다.

이를 위해 두 개의 동일한 대상을 구성했습니다(우리의 경우 iSCSI이지만 FC도 지원되며 설정 논리는 동일합니다).

스토리지 시스템1:

스토리지 시스템2:

복제 연결의 경우 각 스토리지 시스템에서 매핑이 이루어졌습니다.

스토리지 시스템1:

스토리지 시스템2:

다중 경로를 설정하고 이를 호스트에 제공했습니다.

중재인 설정

중재자 자체에 대해 특별한 작업을 수행할 필요는 없으며 세 번째 사이트에서 이를 활성화하고 IP를 제공하고 ICMP 및 SSH를 통해 액세스를 구성하기만 하면 됩니다. 설정 자체는 스토리지 시스템 자체에서 수행됩니다. 이 경우 메트로 클러스터의 스토리지 컨트롤러에서 중재자를 한 번만 구성하면 충분하며 이러한 설정은 모든 컨트롤러에 자동으로 배포됩니다.

섹션에서 원격 복제>> Metrocluster(모든 컨트롤러에서)>> "구성" 버튼을 클릭합니다.

중재자의 IP와 두 개의 원격 스토리지 컨트롤러의 제어 인터페이스를 입력합니다.

그런 다음 모든 서비스를 활성화해야 합니다("모두 다시 시작" 버튼). 나중에 재구성하는 경우 설정을 적용하려면 서비스를 다시 시작해야 합니다.

모든 서비스가 실행 중인지 확인합니다.

이것으로 메트로 클러스터 설정이 완료됩니다.

충돌 테스트

우리의 경우 충돌 테스트는 매우 간단하고 빠릅니다. 왜냐하면 복제 기능(전환, 일관성 등)이 다음에서 논의되었기 때문입니다. 마지막 기사. 따라서 메트로 클러스터의 신뢰성을 테스트하려면 오류 감지, 전환 및 기록 손실(I/O 중지)이 없는지 자동화를 확인하는 것으로 충분합니다.

이를 위해 우리는 두 컨트롤러를 모두 물리적으로 꺼서 스토리지 시스템 중 하나의 완전한 장애를 에뮬레이션합니다. 먼저 다른 스토리지 시스템에서 활성화해야 하는 LUN에 대용량 파일을 복사하기 시작했습니다.

하나의 스토리지 시스템을 비활성화합니다. 두 번째 스토리지 시스템에서는 이웃 시스템과의 연결이 끊어졌다는 경고와 메시지가 로그에 표시됩니다. SMTP 또는 SNMP 모니터링을 통한 알림이 구성된 경우 관리자는 해당 알림을 받게 됩니다.

정확히 10초 후(두 스크린샷 모두에 표시됨) METRO 복제 연결(장애가 발생한 스토리지 시스템의 기본 연결)이 자동으로 작동 중인 스토리지 시스템의 기본 연결이 되었습니다. 기존 매핑을 사용하면 LUN TEST를 호스트에서 계속 사용할 수 있으며 녹화가 약간 줄어들었지만(약속된 10% 이내) 중단되지는 않았습니다.

테스트가 성공적으로 완료되었습니다.

요약

현재 AERODISK Engine N 시리즈 스토리지 시스템에 메트로 클러스터를 구현하면 IT 서비스의 가동 중지 시간을 없애거나 최소화하고 최소한의 인건비로 연중무휴 24시간 운영을 보장해야 하는 문제를 완벽하게 해결할 수 있습니다.

물론 이 모든 것이 이론, 이상적인 실험실 조건 등이라고 말할 수 있습니다. 그러나 우리는 재해 복구 기능을 구현하고 시스템이 완벽하게 작동하는 구현된 프로젝트가 많이 있습니다. 재해 방지 구성에서 단 두 개의 스토리지 시스템만 사용하는 상당히 잘 알려진 고객 중 한 명이 이미 프로젝트에 대한 정보를 게시하는 데 동의했으므로 다음 부분에서는 전투 구현에 대해 이야기하겠습니다.

감사합니다. 생산적인 토론을 기대합니다.

출처 : habr.com