물리적으로 다양한 위치에서 자동 장애 조치 기능을 갖춘 고 가용성 MySQL을위한 아키텍처

데이터 센터 간 MySQL 용 고 가용성 (HA) 솔루션을 연구하고 있습니다.

동일한 물리적 환경에있는 서버의 경우 능동 수동 접근 방식을 사용하여 하트 비트 (부동 VIP)가있는 이중 마스터를 선호합니다. 하트 비트는 직렬 연결과 이더넷 연결 모두에 있습니다.

궁극적으로 저의 목표는 데이터 센터간에 동일한 수준의 가용성을 유지하는 것입니다. 수동 개입없이 두 데이터 센터간에 동적으로 장애 조치를 수행하고 데이터 무결성을 유지하려고합니다.

상단에 BGP가있을 것입니다. 두 위치에있는 데이터베이스로 라우팅 할 수있는 두 위치의 웹 클러스터 사이트 1에서 인터넷 연결이 끊어진 경우 클라이언트는 사이트 2를 통해 웹 클러스터로 라우팅 한 다음 두 사이트 사이의 링크가 여전히 작동하는 경우 사이트 1의 데이터베이스로 라우팅합니다.

이 시나리오에서는 물리적 링크 (직렬)가 없기 때문에 두뇌가 분할 될 가능성이 더 높습니다. 두 사이트 사이에서 WAN이 다운되면 VIP가 두 사이트 모두에서 종료되며 다양한 불쾌한 시나리오에서 비동기가 발생할 수 있습니다.

또 다른 잠재적 인 문제는이 인프라를 향후 세 번째 데이터 센터로 확장하는 데 어려움이 있다는 것입니다.

네트워크 계층은 초점이 아닙니다. 이 단계에서는 아키텍처가 유연합니다. 다시 한 번, 초점은 MySQL 데이터베이스를 통한 자동 장애 조치뿐만 아니라 데이터 무결성을 유지하기위한 솔루션입니다. 나는 이것 주위에 나머지를 디자인 할 것입니다.

물리적으로 다양한 두 사이트 사이에서 입증 된 MySQL HA 솔루션을 추천 할 수 있습니까?

이것을 읽어 주셔서 감사합니다. 나는 당신의 추천을 읽을 수 있기를 기대합니다.

"CAP"정리 문제에 직면하게됩니다. 일관성, 가용성 및 파티션 공차를 동시에 가질 수는 없습니다.

DRBD / MySQL HA는 블록 장치 수준에서 동기식 복제를 사용합니다. 두 노드를 모두 사용할 수 있거나 일시적인 오류가 발생하거나 재부팅 등이 발생한 경우에는 문제가 없습니다. 네트워크 파티션을 받으면 문제가 시작됩니다.

두 개의 데이터 센터에서 실행중인 경우 네트워크 파티션이 매우 높습니다. 본질적으로 어느 당사자도 파티션을 실패한 다른 노드와 구별 할 수 없습니다. 보조 노드는 인계 (기본 실패) 여부 (링크가 끊어 졌는지)를 모릅니다.

컴퓨터가 같은 위치에있는 동안이 문제를 해결하기 위해 보조 통신 채널 (일반적으로 직렬 케이블 또는 크로스 오버 이더넷)을 추가 할 수 있습니다. 따라서 보조는 기본이 실제로 다운 된 시점을 알고 네트워크 파티션이 아닙니다. .

다음 문제는 성능입니다. DRBD는 컴퓨터의 대기 시간이 짧은 연결 (예 : 기가비트 이더넷-일부 사람들은 전용 고속 네트워크를 사용하는 경우)에 알맞은 ** 성능을 제공 할 수 있지만 네트워크의 대기 시간이 길수록 트랜잭션을 커밋하는 데 더 오래 걸립니다 *** . 쓰기의 내구성을 보장하기 위해 앱에 "확인"이라고 말하기 전에 보조 서버 (온라인 일 때)가 모든 쓰기를 인식 할 때까지 기다려야하기 때문입니다.

다른 데이터 센터에서이 작업을 수행하면 일반적으로 가까이 있어도 몇 밀리 초 이상의 대기 시간이 발생합니다.

** 괜찮은 로컬 IO 컨트롤러보다 훨씬 느리다

*** 고 가용성 DRBD 시스템에는 MyISAM을 사용할 수 없습니다.이 시스템은 장애 조치 (failover) 중에 필요한 부정한 종료로부터 적절히 / 자동으로 복구되지 않기 때문입니다.

VLAN을 사용하여 두 개 이상의 데이터 센터에있는 모든 서버를 하나로 묶는 것은 어떻습니까? 그런 다음 CARP를 사용하여 자동 장애 조치를 수행 할 수 있습니다. 데이터베이스 복제를 사용하여 모든 것을 동기화하십시오.

데이터 센터를 소유 한 경우 각 데이터 센터에 여러 개의 WAN 업 링크가 있는지 확인할 수 있습니다.

첫 번째 단계는 현재 HA 솔루션을 OpenAIS를 클러스터 멤버쉽 계층으로 사용하는 솔루션으로 업그레이드하는 것입니다. 이는 많은 유연성을 제공하고 사이트 간 대기 시간이 짧은 링크를 통해 도달 할 수 있습니다. PaceMaker 및 RHEL 클러스터링이이를 지원합니다.

자동 데이터 센터 장애 조치 (failover)의 경우 타이 브레이커 역할을하는 세 번째 사이트가 실제로 필요합니다. 그렇지 않으면 사이트간에 사이트 간 라우팅 문제와 원격 사이트 장애를 구분할 수 없습니다. Microsoft는 놀라 울 정도로 훌륭한 웹 캐스트를 보유하고 있습니다.

Windows Server 2008 다중 사이트 클러스터링

분명히 정확한 기술은 Linux 도메인에 매핑되지 않지만 개념은 동일합니다.

미안 이것은 또 다른 네트워크이지만 제쳐두고 생각합니다 ...

언급 한 스플릿 브레인 시나리오의 경우 두 사이트 사이에 중복 링크가있을 수 있으며 이러한 상황이 발생할 가능성을 줄일 수 있습니다.

가장 작은 라우팅 가능 블록이 4k, / 22, 행운을 빕니다. BGP를 사용할 수 없습니다. 아마도 DNS 기반 솔루션이 필요할 것입니다.

당신이 가진 데이터의 양, 이것에 맞추고 자하는 서버의 양 등에 따라 정답을 얻는 것이 어려울 수 있습니다.

MySQL을 사용하는 여러 사이트에 대한 입증 된 솔루션은 없습니다. 그러나 작동하는 솔루션이 있습니다. 일부 지적했듯이 예 DRDB는 제대로 작동하지만 설정에 따라 한계 또는 가능한 문제가 있습니다.

세 번째 사이트 (다른 ​​데이터 센터)가 필요하십니까? 그렇다면 얼마나 많은 시간과 돈이 필요합니까?

마스터 / 슬레이브 / dns 서버, 백업 등을 추가 할 때마다 ... 관리 할 서버를 직접 추가하면 서버 수 측면에서 관리 용량은 어느 정도입니까? 이 수치를 정의 할 수 있다면 가능한 해결책을 버리고 관리 부서가 병목 현상이되지 않도록 귀하의 수치에 맞는 해결책을 찾아야합니다.

데이터 센터가 자주 다운되지 않는 것을 고려할 때 여러 사이트는로드 밸런싱과 일부 DNS 해킹을 의미합니다. 이것이 동일한 데이터 센터에 있습니까? 그렇다면 어떤 이유로 든 하나의 데이터 센터가 다운되면 DNS 및로드 밸런싱의 좋은 부분이이 데이터 센터에 있기 때문에 문제가 발생할 수 있습니다.

그래서 당신은 그 분할 뇌 상황을 계획해야 할 수도 있습니다. 각각의 가능한 설정에 대해, 침뇌 상황을 해결하는 방법은 다릅니다. 또한 각 솔루션은 X 시간이 걸립니다.
처음부터 3 개의 데이터 센터를 사용하는 것이 훨씬 더 쉬울 수도 있습니다. 나는 MySQL 전문가는 아니지만 프로덕션 환경에서 문제가 발생하면 2 명보다 3 명의 주인을 얻는 것이 더 쉽다는 것을 들었습니다.

당신이 도움이 될 한 가지는 제우스 같은 일부 네트워킹 공급 업체에서 제공하는로드 밸런싱 서비스, 모습이 여기에 아마 더 많은 이러한 종류의 서비스를 제공하고 있습니다. 나는 그것이 가격에 올 것이라고 확신하지만 때로는 다른 것들을 줄일 수 있습니다.

행운을 빕니다!

DRBD는 데이터베이스 및 복제 속도에 영향을 줄 수있는 대역폭이 필요하므로 원격 데이터 센터에 권장되는 솔루션이 아닙니다. 권장되는 솔루션은 마스터-마스터 복제입니다. 이것의 유일한 문제는 자동 증분 필드를 비틀어 야한다는 것입니다.

MySQL에 대한 진정한 HA 솔루션이 필요한 경우 DRBD는 장애 발생시 데이터 무결성을 제공 할 수 없기 때문에 MySQL 클러스터를 사용해야합니다.

MySQL에서 사용할 수있는 옵션과 장단점에 대한 블로그 게시물을 찾았습니다. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

직렬 케이블의 부족을 극복하는 것은 실제로 정말 쉽습니다. 모뎀이라는 어두운 시대의 것을 사용합니다. 각 끝에 하나씩 있고 PPP 링크를 통해 하트 비트를 실행합니다. 프레임 릴레이를 사용할 수도 있습니다. 두 방법 모두 layer1 / 2 중복 경로에 대한 모든 문제를 해결합니다.

그러나 약 300µs (0.3ms) 이상의 대기 시간을 가진 링크를 통해 실행되는 DRBD는 매우 빠르게 어리 석습니다.

표준 MySQL 복제 및 PPP 및 Linux over over HA를 사용하여 장애 조치를 수행하면 더 나은 서비스를 제공받을 수 있습니다.

적어도 그것은 과거에 고객을 위해 한 일입니다.