저는 오랫동안 고객과 함께 AWS를 사용하고 있지만 서비스를 계속 제공하려면 비용을 절감해야 합니다. AWS에서는 RSync를 사용하여 일부 폴더를 동기화하고 DRDB를 사용하여 항상 작동하고 각 클라이언트 시스템에 대해 미러를 사용할 준비가 된 투명한 장애 조치로 고가용성을 제공합니다.
이제 마이그레이션하는 훨씬 더 저렴한 클라우드 솔루션은 LVM 없이 하나의 파티션만 있는 Ubuntu 14.04 LTS를 각 시스템에 제공하기 때문에 DRBD를 계속 사용할 수 없습니다. 이 클라우드 플랫폼도 일부 클라이언트의 요구 사항이 됩니다.
제가 생각하고 있는 해결책은 쉘 스크립트를 한쪽에서 매일 BKP로 예약하고 SSH를 통해 다른 쪽으로 전송하고 BKP를 복원하는 것입니다. 그러면 복잡해지고 오류가 발생하기 쉬우며 개발 및 관리에 많은 작업이 필요할 것입니다. .
내 고객 중 다수는 Wordpress+Mysql일 뿐이며 하루의 지연을 허용합니다. 각각에 대한 스크립트를 개발하고 관리할 필요가 없는 하루의 지연이 발생하더라도 "고가용성"을 제공할 수 있는 대안을 찾고 있습니다. 제한된 상황의 경우.
답변1
실제로 블록 장치를 사용할 수 없는 경우(DRBD가 여기에서 더 나을 것이며 이미 경험이 있음) GlusterFS는 파일 수준에서 원하는 복제 기능을 제공할 수 있습니다.
Gluster "브릭"은 이상적으로는 XFS로 끝나는 자체 얇은 LVM 스택이 있는 단일 저장 장치이지만 실제로는 노드의 POSIX 호환 파일 시스템(또는 전용 FS가 아닌 디렉터리)일 수도 있습니다.
이러한 브릭은 이제 많은 브릭이 지정된 파일로 기록되도록 정의하는 "복제본" 정책을 사용하여 통합된 "볼륨"으로 집계됩니다. 이 경우 복제본 2 또는 3일 것입니다. 이러한 복제본은 다음과 같은 경우 다른 노드에 위치하려고 노력합니다. 모두 가능합니다.
Gluster의 실패 의미 체계는 아직 DRBD만큼 일관성이 없습니다. 분할 브레인 조건은 데이터 복제가 연결 클라이언트의 책임이기 때문에 달성하기가 더 쉽습니다(마스터에 쓰는 대신 데이터를 복제하는 대신 각 Gluster 노드에 모든 쓰기의 N 복사본을 보냅니다). 그러나 각 브릭은 복제를 사용할 때 완전히 읽을 수 있는 데이터가 있는 온전한 파일 시스템이므로 서로 다른 데이터가 있는 분할 브레인을 해결하는 것이 잠재적으로 더 쉬울 수 있습니다.
DRBD만큼 빠르지는 않지만 그럴 필요는 없을 수도 있습니다.