기본 위치와 보조 위치 간의 데이터 복제에 DRBD 사용을 고려하고 싶습니다. 초기 계획은 둘 사이에 VPN 터널을 구축하는 것입니다. 이중 T1 링크 슬라이스를 사용하는 1 차측 및 케이블 / dsl 회선의 2 차 위치 설정.
2 차는 DR에 대해서만 존재하며 1 차로 "복제"되지 않습니다.
누구든지 이와 같은 일을하고 / 피곤하고 / 사용했으며 그 경험은 무엇입니까?
Linbit에는 또한 WAN 유형 링크 (압축, 다중 피어)를 통해 작동하도록 설계된 (유료) DRBD 프록시 제품이 있습니다. 누구든지 이것을 시도 했습니까?
답변:
DRBD 프록시를 말할 수는 없지만 일반 DRBD는 이것을 좋아하지 않습니다.
활동이 제한되어 있어도 듀얼 T1 (2x 1.5Mbps, 라운드 수, 300KB / s)을 쉽게 채울 수 있습니다. 300KB / s는 응용 프로그램 로깅만으로도 서버에서 흥미로운 작업을 수행 할 수 있습니다. 이것은 over-the-vpn 대기 시간을 방정식에 추가하는 것은 물론 동기식 복제 ( 프로토콜 C )를 배제합니다 .
비동기 복제 ( 프로토콜 A )는 기술적으로 작동 할 수 있지만 장애가 발생했을 때 보조 복제본이 오래되어 사용할 수 없을 것으로 예상합니다 (복제본은 하루 동안 몇 시간이 걸릴 수 있음)
메모리 동기 ( 프로토콜 B )는 여전히 대역폭 문제로 인해 제약을 받으므로 도움이되지 않습니다.
DRBD 프록시는 여전히 비슷한 문제로 어려움을 겪을 것으로 예상되며, 주로 제한된 대역폭으로 인해 복제 지연이 발생합니다.
DR 전략을 다시 평가하여 완화하려는 대상을 해결하는 것이 좋습니다. 하드웨어 고장 또는 사이트 고장.
사이트 장애로부터 보호하는 경우 하나 또는 두 개의 대역폭 제한 사이트의 경우 더 낮은 대역폭 / 높은 밀도 전송에서 더 나은 마일리지를 얻을 수 있습니다. 이 기법의 일부 예는 rsync입니다 (무선 전송은 모든 변경에 대한 변경 당 변경이 아니라 실행 간 파일 변경으로 제한됨) 및 일부 프로토콜 오버 헤드; 트래픽을 암호화하고 압축하기 위해 SSH를 통해 실행할 수 있음) 데이터베이스 로그 전달 (DR 상자에서 재생하기 위해 압축 된 데이터베이스 로그를 전송하면 전체 데이터베이스 덤프를 전송하는 것보다 적은 대역폭을 사용할 수 있음)
하드웨어 장애로부터 보호하는 경우 GigE 크로스 오버와 연결된 로컬 DRBD 복제본은 제대로 작동하고 완전히 동기화 된 업데이트가 가능하며 온라인 검증을 통해 두 노드에서 데이터가 일관성이 있음을 증명할 수 있습니다. 기본 사이트 장애로부터 보호하기 위해이 옵션을 DR 파일에 대한 제한된 파일 복제와 결합 할 수 있습니다.