두 개의 노드로 구성된 클러스터 - 악마는 세부 사항에 있습니다.

헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 "두 개의 노드 - 악마는 세부 사항에 있습니다" 앤드류 비크호프(Andrew Beekhof).

많은 사람들이 33노드 클러스터를 선호하는 이유는 개념적으로 더 단순해 보이고 XNUMX노드 클러스터보다 XNUMX% 저렴하기 때문입니다. 두 개의 노드로 구성된 좋은 클러스터를 구성하는 것이 가능하지만 대부분의 경우 고려되지 않은 시나리오로 인해 이러한 구성은 많은 알려지지 않은 문제를 야기합니다.

고가용성 시스템을 구축하는 첫 번째 단계는 개별 실패 지점을 찾아서 제거하는 것입니다. SPoF (단일 실패 지점).

어떤 시스템에서든 다운타임으로 인해 발생할 수 있는 위험을 모두 제거하는 것은 불가능하다는 점을 명심해야 합니다. 이는 위험에 대한 일반적인 방어가 일부 중복성을 도입하는 것이며, 이로 인해 시스템 복잡성이 증가하고 새로운 실패 지점이 출현한다는 사실에서 비롯됩니다. 따라서 우리는 처음에는 관련 체인이 아닌 개별 실패 지점과 관련된 이벤트에 타협하고 집중하여 점점 더 가능성이 낮은 이벤트에 집중합니다.

장단점을 고려할 때 우리는 SPoF를 찾을 뿐만 아니라 위험과 결과의 균형도 맞추며, 그 결과 무엇이 중요하고 무엇이 중요하지 않은지에 대한 결론은 배포마다 다를 수 있습니다.

모든 사람에게 독립 전력선을 갖춘 대체 전력 공급업체가 필요한 것은 아닙니다. 적어도 한 명의 고객이 모니터링을 통해 변압기 결함을 감지했을 때 편집증이 보상을 받았지만. 고객은 결함이 있는 변압기가 폭발할 때까지 전력회사에 알리려고 전화를 걸었습니다.

자연스러운 시작점은 시스템에 둘 이상의 노드를 갖는 것입니다. 그러나 시스템이 장애 후 살아남은 노드로 서비스를 이동하기 전에 일반적으로 이동 중인 서비스가 다른 곳에서 활성화되지 않았는지 확인해야 합니다.

장애로 인해 두 노드가 모두 동일한 정적 웹 사이트를 제공하는 경우 XNUMX노드 클러스터에는 단점이 없습니다. 그러나 결과적으로 양 당사자가 공유 작업 대기열을 독립적으로 관리하거나 복제된 데이터베이스 또는 공유 파일 시스템에 대한 조정되지 않은 쓰기 액세스를 제공하는 경우에는 상황이 달라집니다.

따라서 단일 노드 장애로 인한 데이터 손상을 방지하기 위해 우리는 "분리" (펜싱).

해리의 원리

분리 원칙의 핵심은 다음과 같은 질문입니다. 경쟁 노드가 데이터 손상을 일으킬 수 있습니까? 데이터 손상이 발생할 가능성이 있는 시나리오의 경우 들어오는 요청과 영구 저장소 모두에서 노드를 격리하는 것이 좋은 해결책입니다. 연결 해제에 대한 가장 일반적인 접근 방식은 결함이 있는 노드의 연결을 끊는 것입니다.

해리 방법에는 두 가지 범주가 있습니다. 곧은 и 간접, 그러나 동일하게 호출할 수 있습니다. 유효한 и 수동적 인. 직접적인 방법에는 IPMI(지능형 플랫폼 관리 인터페이스) 또는 iLO(물리적 액세스가 없을 때 서버를 관리하는 메커니즘) 장치와의 상호 작용과 같은 살아남은 피어 측의 작업이 포함되는 반면, 간접적인 방법은 실패한 피어에 의존합니다. 노드가 건강하지 않은 상태에 있음을 어떻게든 인식하고(또는 적어도 다른 구성원의 복구를 방해함) 신호를 보냅니다. 하드웨어 워치독 실패한 노드의 연결을 끊을 필요가 있는지에 대해 설명합니다.

쿼럼은 직접 방법과 간접 방법을 모두 사용할 때 도움이 됩니다.

직접 해리

직접 분리의 경우 쿼럼을 사용하여 네트워크 장애 발생 시 분리 경합을 방지할 수 있습니다.

쿼럼 개념을 사용하면 노드가 분리 및/또는 복구를 시작해야 하는지 여부를 자동으로 알 수 있을 만큼 시스템에 충분한 정보가 있습니다(피어에 연결하지 않아도).

쿼럼이 없으면 네트워크 분할의 양측은 상대방이 죽었다고 가정하고 상대방의 연결을 끊으려고 노력할 것입니다. 최악의 경우 두 당사자 모두 전체 클러스터를 종료할 수 있습니다. 대체 시나리오는 데스매치, 즉 피어를 보지 못하고 재부팅하고 피어가 동일한 논리를 따를 때만 재부팅하기 위해 복구를 시작하는 노드 생성의 끝없는 루프입니다.

연결 해제의 문제는 복구 대상으로 지정하려는 동일한 오류 이벤트로 인해 가장 일반적으로 사용되는 장치를 사용할 수 없게 된다는 것입니다. 대부분의 IPMI 및 iLO 카드는 제어하는 ​​호스트에 설치되며 기본적으로 동일한 네트워크를 사용하므로 대상 호스트는 다른 호스트가 오프라인이라고 믿게 됩니다.

불행하게도 장비 구매 시 IPMI 및 iLo 장치의 작동 기능은 거의 고려되지 않습니다.

간접 해리

쿼럼은 간접적인 연결 해제를 관리하는 데에도 중요합니다. 올바르게 수행되면 쿼럼을 통해 생존자는 손실된 노드가 일정 기간 후에 안전한 상태로 전환될 것이라고 가정할 수 있습니다.

이 구성을 사용하면 쿼럼이 손실되지 않으면 하드웨어 감시 타이머가 N초마다 재설정됩니다. 타이머(일반적으로 N의 몇 배수)가 만료되면 장치는 비정상적으로 전원을 끄는 작업을 수행합니다(종료가 아님).

이 접근 방식은 매우 효과적이지만 쿼럼이 없으면 클러스터 내 정보가 부족하여 이를 관리할 수 없습니다. 네트워크 중단과 피어 노드 실패의 차이를 구별하는 것은 쉽지 않습니다. 이것이 중요한 이유는 두 경우를 구별하는 능력이 없으면 두 경우 모두 동일한 행동을 선택해야 하기 때문입니다.

하나의 모드를 선택할 때의 문제점은 가용성을 최대화하고 데이터 손실을 방지하는 조치 과정이 없다는 것입니다.

• 피어 노드가 활성 상태이지만 실제로는 실패한다고 가정하기로 선택한 경우 클러스터는 실패한 피어 노드의 서비스 손실을 보상하기 위해 실행 중인 서비스를 불필요하게 중지합니다.
• 노드가 다운되었다고 가정하기로 결정했지만 이는 단지 네트워크 오류였으며 실제로 원격 노드가 작동하는 경우 기껏해야 결과 데이터 세트에 대한 향후 수동 조정에 등록하는 것입니다.

어떤 경험적 방법을 사용하든 양측 모두에 장애가 발생하거나 클러스터가 살아남은 노드를 종료하게 만드는 장애를 만드는 것은 쉽지 않습니다. 쿼럼을 사용하지 않으면 클러스터의 무기고에서 가장 강력한 도구 중 하나가 박탈됩니다.

다른 대안이 없다면 가장 좋은 접근 방식은 가용성을 희생하는 것입니다(여기서 저자는 CAP 정리를 참조함). 손상된 데이터의 고가용성은 누구에게도 도움이 되지 않으며, 다양한 데이터 세트를 수동으로 조정하는 것도 재미가 없습니다.

정족수

쿼럼이 정말 좋은 것 같죠?

유일한 단점은 N개의 구성원이 있는 클러스터에 이를 포함하려면 남은 노드의 N/2+1개 사이에 연결이 있어야 한다는 것입니다. 한 노드에 장애가 발생한 후 두 노드 클러스터에서는 불가능합니다.

궁극적으로 두 노드의 근본적인 문제가 발생합니다.
쿼럼은 두 노드 클러스터에서 의미가 없으며, 쿼럼이 없으면 가용성을 최대화하고 데이터 손실을 방지하는 작업 과정을 안정적으로 결정하는 것이 불가능합니다.
크로스오버 케이블로 연결된 두 노드의 시스템에서도 네트워크 중단과 다른 노드의 장애를 명확하게 구별하는 것은 불가능합니다. 한쪽 끝을 비활성화하면(물론 노드 간 거리에 비례하는 확률) 링크 상태가 파트너 노드 상태와 동일하다는 가정이 무효화되기에 충분합니다.

XNUMX노드 클러스터 작동

때로는 클라이언트가 세 번째 노드를 구매할 수 없거나 구매를 원하지 않아 대안을 찾아야 하는 경우도 있습니다.

옵션 1 - 중복 해리 방법

노드의 iLO 또는 IPMI 장치는 오류 지점을 나타냅니다. 오류가 발생하면 생존자는 이를 사용하여 노드를 안전한 상태로 만들 수 없기 때문입니다. 3개 이상의 노드로 구성된 클러스터에서는 쿼럼을 계산하고 하드웨어 워치독(앞서 설명한 간접 연결 해제 메커니즘)을 사용하여 이를 완화할 수 있습니다. 노드가 XNUMX개인 경우 대신 네트워크 전력 분배 장치(PDU)를 사용해야 합니다.

오류가 발생한 후 생존자는 먼저 기본 연결 해제 장치(내장형 iLO 또는 IPMI)에 연결을 시도합니다. 성공하면 평소대로 복구가 계속됩니다. iLO/IPMI 장치에 오류가 발생한 경우에만 PDU에 액세스되며, 액세스에 성공하면 복구를 계속할 수 있습니다.

PDU를 클러스터 트래픽과 다른 네트워크에 배치해야 합니다. 그렇지 않으면 단일 네트워크 오류로 인해 연결 해제 장치 모두에 대한 액세스가 차단되고 서비스 복원이 차단됩니다.

여기에서 질문할 수 있습니다. PDU가 단일 실패 지점입니까? 물론 대답은 그렇습니다.

이 위험이 귀하에게 중요하다면 혼자가 아닙니다. 두 노드를 두 개의 PDU에 연결하고 노드 전원을 켜고 끌 때 두 노드를 모두 사용하도록 클러스터링 소프트웨어에 지시하십시오. 이제 하나의 PDU가 중단되더라도 클러스터는 활성 상태로 유지되며, 다른 PDU 또는 IPMI 장치에 두 번째 오류가 발생하면 복구를 차단해야 합니다.

옵션 2 - 중재자 추가

일부 시나리오에서는 중복 연결 해제 방법이 기술적으로는 가능하지만 정치적으로는 어렵습니다. 많은 기업에서는 관리자와 애플리케이션 소유자를 어느 정도 분리하기를 원하며, 보안을 중시하는 네트워크 관리자는 PDU 액세스 설정을 다른 사람과 공유하는 데 항상 열성적인 것은 아닙니다.

이 경우 권장되는 대안은 정족수 계산을 보완할 수 있는 중립적인 제XNUMX자를 만드는 것입니다.

장애가 발생한 경우 노드는 서비스를 복원하기 위해 피어 또는 중재자의 전파를 볼 수 있어야 합니다. 중재자는 두 노드가 중재자를 볼 수 있지만 서로를 볼 수 없는 경우 연결 해제 기능도 포함합니다.

이 옵션은 피어 및 중재자 노드에 대한 연결이 끊어지면 컴퓨터를 종료하도록 구성된 하드웨어 감시 타이머와 같은 간접적인 연결 해제 방법과 함께 사용해야 합니다. 따라서 생존자는 하드웨어 감시 타이머가 만료된 후 피어 노드가 보안 상태에 있을 것이라고 합리적으로 가정할 수 있습니다.

중재자와 세 번째 노드의 실질적인 차이점은 중재자가 작동하는 데 훨씬 적은 리소스가 필요하며 잠재적으로 두 개 이상의 클러스터를 서비스할 수 있다는 것입니다.

옵션 3 - 인적 요소

마지막 접근 방식은 생존자가 이미 실행 중이던 서비스를 계속 실행하되, 문제가 자체적으로 해결되거나(네트워크 복원, 노드 재부팅) 다른 쪽이 종료되었음을 수동으로 확인할 책임이 있는 사람이 나올 때까지 새 서비스를 시작하지 않는 것입니다.

보너스 옵션

세 번째 노드를 추가할 수 있다고 말씀드렸나요?

랙 XNUMX개

논의를 위해 세 번째 노드의 장점을 확신했다고 가정하겠습니다. 이제 노드의 물리적 배열을 고려해야 합니다. 동일한 랙에 보관(및 전원 공급)되는 경우에도 SPoF가 구성되며 두 번째 랙을 추가해도 문제가 해결되지 않습니다.

이것이 놀라운 일이라면 두 개의 노드가 있는 랙에 오류가 발생할 경우 어떤 일이 발생하는지, 그리고 살아남은 노드가 해당 노드와 네트워크 오류를 어떻게 구별할 것인지 생각해 보십시오.

짧은 대답은 불가능하다는 것입니다. 그리고 다시 우리는 XNUMX노드 사례의 모든 문제를 다루고 있습니다. 또는 생존자:

• 쿼럼을 무시하고 네트워크 중단 중에 복원을 시작하려고 잘못 시도합니다(분리를 완료하는 능력은 다른 이야기이며 PDU가 관련되어 있는지, 랙과 전원을 공유하는지 여부에 따라 다름).
• 쿼럼을 존중하고 피어 노드가 실패하면 조기에 연결을 끊습니다.

어떤 경우든 XNUMX개의 랙은 XNUMX개보다 나을 수 없으며 노드는 독립적인 전원 공급 장치를 받거나 XNUMX개(또는 보유한 노드 수에 따라 그 이상) 랙에 분산되어야 합니다.

두 개의 데이터 센터

이 시점에서 더 이상 위험을 싫어하지 않는 독자는 재해 복구를 고려할 수 있습니다. XNUMX개의 서로 다른 랙에 분산된 XNUMX개의 노드가 있는 동일한 데이터 센터에 소행성이 충돌하면 어떻게 됩니까? 분명히 나쁜 일이지만 필요에 따라 두 번째 데이터 센터를 추가하는 것만으로는 충분하지 않을 수 있습니다.

올바르게 완료되면 두 번째 데이터 센터는 귀하의 서비스와 해당 데이터에 대한 최신의 일관된 사본을 귀하에게 제공합니다(합리적으로는 그렇습니다). 그러나 XNUMX노드, XNUMX랙 시나리오와 마찬가지로 최대 가용성을 보장하고 손상(또는 데이터 세트 불일치)을 방지할 만큼 시스템에 정보가 충분하지 않습니다. XNUMX개의 노드(또는 랙)가 있더라도 이를 XNUMX개의 데이터 센터에만 분산하면 양 당사자가 통신할 수 없는 (이제 훨씬 더 가능성이 높은) 이벤트가 발생하는 경우 시스템이 안정적으로 올바른 결정을 내릴 수 없게 됩니다.

이는 듀얼 데이터 센터 솔루션이 결코 적합하지 않다는 의미는 아닙니다. 기업에서는 백업 데이터 센터로 이동하는 특별한 조치를 취하기 전에 사람이 이를 알기를 원하는 경우가 많습니다. 중단을 자동화하려면 쿼럼을 이해하기 위한 세 번째 데이터 센터가 필요하거나(직접 또는 중재자를 통해) 전체 데이터를 안정적으로 종료할 수 있는 방법을 찾아야 한다는 점을 명심하세요. 센터.

출처 : habr.com