Tôi không thể nói cho Proxy DRBD, nhưng DRBD thông thường sẽ không thích điều này nhiều.
Với hoạt động thậm chí còn hạn chế, bạn có thể dễ dàng bão hòa một T1 kép (2x 1,5Mbps; cho số vòng, 300KB / giây). 300KB / s có thể được xử lý bằng cách đăng nhập ứng dụng một mình, chứ đừng nói gì đến việc làm thú vị trên máy chủ của bạn. Điều này loại trừ việc sao chép đồng bộ ( Giao thức C ), chứ chưa nói đến việc thêm độ trễ quá mức vào phương trình.
Sao chép không đồng bộ ( Giao thức A ) về mặt kỹ thuật có thể hoạt động, nhưng tôi hy vọng thứ cấp sẽ bị lỗi thời vì không thể sử dụng được trong trường hợp bị lỗi (bản sao có thể chậm hàng giờ trong ngày)
Bộ nhớ đồng bộ ( Giao thức B ) sẽ không giúp ích vì nó vẫn bị hạn chế bởi vấn đề băng thông.
Tôi hy vọng DRBD Proxy vẫn sẽ gặp phải các vấn đề tương tự, chủ yếu gây ra sự chậm trễ sao chép do băng thông hạn chế.
Tôi khuyên bạn nên đánh giá lại chiến lược DR của mình để tìm ra những gì bạn đang giảm nhẹ; lỗi phần cứng hoặc lỗi trang web.
Trong trường hợp bảo vệ chống lại sự cố trang web, bạn có thể nhận được số dặm tốt hơn từ băng thông thấp hơn / chuyển mật độ cao hơn trong trường hợp một (hoặc cả hai) trang web bị hạn chế băng thông. Một số ví dụ về kỹ thuật này là rsync (chuyển tiền qua mạng bị giới hạn ở các thay đổi trong các tệp giữa các lần chạy - thay vì mỗi thay đổi cho mỗi thay đổi - cộng với một số chi phí giao thức; có thể được chạy qua SSH để mã hóa và nén lưu lượng hơn nữa) và vận chuyển nhật ký cơ sở dữ liệu (chuyển nhật ký cơ sở dữ liệu nén để phát lại trên hộp DR có thể sử dụng ít băng thông hơn so với chuyển kết xuất cơ sở dữ liệu đầy đủ).
Nếu bạn đang bảo vệ chống lại lỗi phần cứng, bản sao DRBD cục bộ được kết nối với crossover GigE sẽ hoạt động tốt, cho phép cập nhật hoàn toàn đồng bộ và cho phép xác minh trực tuyến để chứng minh dữ liệu phù hợp trên cả hai nút. Bạn vẫn có thể kết hợp tùy chọn này với sao chép tệp giới hạn vào một trang DR để bảo vệ chống lại lỗi trang chính.