우리가 논의한 바와 같이, 고가용성 클러스터 환경에는 하나의 활성 노드와 활성 노드가 실패하거나 응답을 중지할 때 서비스를 인계할 하나 이상의 대기 노드가 있습니다.

이것은 노드 간의 네트워크 계층을 고려할 때까지 합리적인 가정처럼 들립니다. 노드 간의 네트워크 경로가 다운되면 어떻게 됩니까?

이제 어느 노드도 다른 노드와 통신할 수 없으며 이 상황에서 대기 서버는 활성 노드가 실패했다고 생각하는 것을 기반으로 스스로를 활성 서버로 승격할 수 있습니다. 이로 인해 두 노드가 모두 '활성' 상태가 되어 서로가 다른 노드를 죽은 것으로 간주하게 됩니다. 결과적으로 두 노드의 데이터가 변경됨에 따라 데이터 무결성과 일관성이 손상됩니다. 이것은 "스플릿 브레인" .

스플릿 브레인 시나리오를 피하려면 클러스터 내에 쿼럼 노드('증인'이라고도 함)를 설치해야 합니다. 쿼럼 노드를 추가하면(짝수 수의 노드로 구성된 클러스터에) 홀수 수의 노드(3, 5, 7 등)가 생성되며 노드는 클러스터 내에서 활성 노드로 작동해야 하는 노드를 결정하기 위해 투표합니다.

아래 예에서는 노드 B가 포함된 서버 랙이 손실되었습니다. 랜 연결성. 이 시나리오에서 클러스터 환경에 세 번째 노드를 추가하면 시스템은 여전히 활성 노드가 되어야 하는 노드를 결정할 수 있습니다.

쿼럼/감시 기능은 시오스 보호 스위트. 설치 시 Quorum/Witness는 모든 노드(쿼럼 노드 뿐만 아니라)에서 선택되고 모든 노드(쿼럼 노드 포함) 간에 통신 경로가 정의됩니다.

쿼럼 노드는 활성 서비스를 호스팅하지 않습니다. 유일한 역할은 노드 통신에 참여하여 활성 상태를 결정하고 통신 중단 시 '동률 투표'를 제공하는 것입니다.

시오스 또한 지원 IO 펜싱 및 스토리지 쿼럼 장치로 사용되며 이러한 구성에서는 추가 쿼럼 노드가 필요하지 않습니다.

앞서 논의한 바와 같이 한 번 고가용성 클러스터 두 개 이상의 노드가 동시에 실행되고 사용자가 "활성" 노드 . 활성 노드에서 문제가 발생하면 "장애 조치" 조건이 발생하고 "대기" 노드가 새로운 "활성" 노드가 됩니다. 장애 조치가 발생하면 클라이언트가 장애 조치 조건을 감지하고 다시 연결하거나 사용자의 활성 클라이언트 세션을 활성 노드로 원활하게 전송할 수 있는 메커니즘이 있어야 합니다.

가상 IP 주소

일반적으로 클러스터가 구성되고 클라이언트가 클라이언트와 통신할 때 "가상" IP 주소가 생성됩니다. 활성 노드 가상 IP 주소를 사용합니다. 장애 조치가 발생하면 가상 IP 주소가 새 활성 노드에 재할당되고 클라이언트가 동일한 가상 IP 주소에 다시 연결합니다.

예를 들어 IP 주소가 다음과 같은 두 개의 노드 A와 B가 있다고 가정합니다. 10.20.1.10 그리고 10.20.2.10 . 이 예에서는 현재 활성 노드에 할당된 것으로 간주되어야 하는 10.20.0.10의 가상 IP 주소를 정의합니다.

이는 한 노드의 한 네트워크 인터페이스 카드에 두 번째 IP 주소를 할당하는 것과 유사합니다. 만약 명령이 아이피 활성 노드에 입력하면 두 IP 주소가 모두 나타납니다(이 Linux 예의 10행과 12행).

그만큼 ARP 규약

클라이언트가 IP 주소를 사용하여 서버를 찾으려고 할 때 클라이언트는 일반적으로 다음을 사용합니다. ARP (주소 확인 프로토콜)을 찾기 위해 맥 (미디어 액세스 제어) 대상 시스템의 주소입니다.

클라이언트가 대상 IP 주소를 찾기 위해 메시지를 브로드캐스트하면 활성 노드는 다음으로 응답합니다. 맥 주소와 클라이언트가 요청을 해결하고 연결합니다.

ARP 클라우드 환경을 위한 대안

그러나 클라우드 환경에서는 다음을 사용하여 활성 노드를 식별할 수 없습니다. ARP 가상 환경에서 많은 레이어가 추상화됩니다. 특정 클라우드 환경에서 사용 중인 네트워크 인프라에 기반한 대체 방법이 필요할 수 있습니다. 일반적으로 여러 옵션이 있으며 다음 목록에서 선택해야 합니다.

• AWS 라우팅 테이블 시나리오

• AWS 탄력적 IP 시나리오

• AWS Route53 시나리오

• Azure 내부 부하 분산 장치 시나리오

• Google Cloud 내부 부하 분산기 시나리오

워크로드(노드)가 어떻게 분산되어야 하는지 결정하는 것은 고가용성을 염두에 두고 퍼블릭 클라우드로 마이그레이션할 때 일반적인 토론 주제입니다. 워크로드가 온프레미스 환경에 있는 경우 이러한 워크로드의 위치는 구축된 데이터 센터의 위치로 정의되는 경우가 많습니다. 많은 경우에 워크로드를 호스팅할 다른 위치를 선택하는 것은 사용 가능한 옵션이 아닙니다. 퍼블릭 클라우드 제품에는 다양한 지리적 지역과 선택할 수 있는 가용 영역이 있습니다.

가용 영역은 일반적으로 동일한 물리적 지역(예: 캘리포니아)에 있는 하나 이상의 데이터 센터(물리적 위치)와 유사합니다. 이러한 데이터 센터는 서로 다른 영역에 위치할 수 있지만 고속 네트워크를 사용하여 연결되어 데이터 센터 간의 연결 대기 시간을 최소화합니다. (가용 지역 내의 여러 데이터 센터에서 서비스를 호스팅하는 것은 사용자에게 투명해야 합니다).

일반적으로 워크로드 간의 물리적 거리가 멀수록 환경이 더 탄력적입니다. 지진과 같은 자연 재해가 동시에 다른 지역에 영향을 미치지 않을 것이라는 합리적인 가정입니다(예: 미국 서부 해안과 동부 해안 모두 동시에). 그러나 시스템 전체의 장애로 인해 여러 지역에서 동시에 서비스 중단이 발생할 가능성이 있습니다(일부 클라우드 공급자는 이전에 미국 및 호주와 같은 지역 간 동시 중단을 보고했습니다). 여러 클라우드 제공업체에 걸쳐 정의된 DR(재해 복구) 계획을 만드는 것이 적절할 수 있습니다.

고려할 가치가 있는 또 다른 관점은 자원을 보호하는 비용입니다. 일반적으로 워크로드 간의 거리가 멀수록 데이터 전송에 더 많은 비용이 발생합니다. 많은 경우 동일한 데이터 센터(가용 영역) 내의 노드 간 데이터 전송은 무료이지만 가용 영역 간에 데이터를 전송하는 데는 GB당 $0.01 이상의 비용이 들 수 있습니다. 이 추가 비용은 지역 간에 데이터를 전송할 때 두 배(또는 그 이상)(예: $0.02/GB)할 수 있습니다. 또한 워크로드 간의 물리적 거리가 증가하기 때문에 노드 간의 데이터 대기 시간이 더 길어질 것으로 예상해야 합니다. 일반적으로 이러한 요소를 고려하여 동일한 리전 내의 가용 영역에 워크로드를 분산하는 것이 좋습니다.