GlusterFS có phải là một lựa chọn tốt để giữ cho máy chủ web đồng bộ hóa không?

9

Tôi đã có 2 máy chủ web, với cơ hội phải thêm nhiều máy chủ trên đường đi. Ngay bây giờ tôi giữ các máy chủ này đồng bộ bằng lsyncd + csync2. Nó hoạt động tốt hiệu suất khôn ngoan vì tất cả các tệp trên cả hai máy chủ (không cần truy cập mạng để mở tệp cục bộ), nhưng không tốt trong các trường hợp khác.

Một ví dụ về điều này là nếu tôi xóa một tệp trên máy chủ 1 và ngay lập tức tải một tệp mới lên máy chủ 1 có cùng tên. Sau đó, tệp sẽ bị xóa khỏi máy chủ 2, khiến tệp mới được tải lên trên máy chủ 1 bị xóa vì máy chủ 2 gửi sự kiện xóa trên máy chủ 1 để hoàn tất "vòng tròn cập nhật".

Tôi không thể nghĩ rằng phải có một cách tốt hơn để giữ cho máy chủ đồng bộ. Tôi đã xem GlusterFS và tôi thấy rằng một thiết lập trong đó tất cả các tệp được sao chép tới tất cả các máy chủ đều không được khuyến khích. Tuy nhiên, tôi đang chạy các hệ thống CMS như Drupal trên các máy chủ này. Các hệ thống CMS như vậy thường mở khá nhiều tệp và tôi lo lắng rằng quá nhiều lưu lượng mạng để giữ các tệp này sẽ làm chậm các yêu cầu.

Sẽ là một ý tưởng để xem xét thay thế lsyncd + csync2 bằng GlusterFS được thiết lập để sao chép tất cả các tệp vào tất cả các nút, hay đó là một ý tưởng tồi?

— sbrattla
nguồn

2

Tôi có thể giải quyết vấn đề của bạn ở đây, nhưng tại sao không sử dụng lưu trữ mạng được chia sẻ giữa các máy chủ?

— mveroone

1

@Kwaio: Tôi muốn "phản chiếu" tất cả các máy chủ web (cả tập lệnh và nội dung do người dùng tải lên) vì điều này sẽ ngăn chặn thời gian chết nếu máy chủ lưu trữ bộ nhớ chia sẻ. Nói cách khác, tôi không muốn dựa vào một thiết lập trong đó tất cả các máy chủ web lại dựa vào một bộ lưu trữ tệp duy nhất.

— sbrattla

Vậy thì tại sao không phải là một cụm lưu trữ mạng có tính sẵn sàng cao?

— mveroone

Chắc chắn, nhưng điều đó ngụ ý gì? Phần cứng?

— sbrattla

Tôi không phải là chuyên gia, nhưng điều đó có nghĩa là bộ lưu trữ mạng của bạn được nhân đôi trong kiến trúc nô lệ chủ trên 2 cụm và một hệ thống chuyển đổi trong trường hợp lỗi chính. Hầu hết các nhà cung cấp thiết bị lưu trữ mạng đều có giải pháp cho điều đó, ngay cả khi bạn có thể tự xây dựng nó bằng các thiết bị linux, điều này sẽ đòi hỏi khá nhiều sự phát triển.

— mveroone

2

BitTorrent Sync có thể thực hiện hành động cho bạn. Tôi đang sử dụng nó để giữ các tệp đồng bộ giữa một vài máy chủ nội bộ tại nhà của tôi và nó đang thực hiện công việc một cách tuyệt vời. Một thứ khác bạn sẽ cần nghĩ đến là cơ sở dữ liệu phụ trợ khi ứng dụng của bạn sử dụng CMS. Hãy chắc chắn rằng có sự sao chép MySQL đang diễn ra hoặc một cái gì đó thuộc loại đó.

— whiskykilo
nguồn

Nó thật thú vị. BitTorrent Sync xử lý các xung đột như thế nào? Giả sử tôi có 5 máy chủ web và một tệp được cập nhật trên máy chủ A. Sau đó, 2 giây sau, cùng một tệp được cập nhật trên máy chủ C trước khi thay đổi trên A đạt được C. Phần mềm có thuật toán để thiết lập máy chủ nào không chiến thắng trong những trường hợp này?

— sbrattla

Tôi hiểu là, BitTorrent Sync sẽ so sánh ngày / giờ sửa đổi trên cả hai bản sao và chỉ giữ bản mới nhất, có thể là lý tưởng hoặc có thể gây bất lợi cho trường hợp sử dụng.

— whiskykilo

1

Gluster sẽ giải quyết vấn đề bạn gặp phải vì nó có thể giữ các khóa, truyền các thay đổi - xóa tệp trên tất cả các nút khác, nhưng nó có thể thêm độ trễ bổ sung có thể là vấn đề đối với máy chủ web. Giải pháp thay thế tiếp theo là DRBD + OCFS2 hoặc GFS, nhưng điều đó có thể phức tạp hơn như với gluster bạn đang sử dụng hệ thống tệp cơ bản - nó không hoạt động ở cấp độ khối nên nếu máy chủ không đồng bộ thì không quá khó để sửa, các tệp có thể Không dễ bị hỏng vì bộ não bị chia cắt, v.v ...

Chúng tôi đang sử dụng nó cho một mailserver và nó khá chậm đối với các thư mục có nhiều tệp. Bạn chắc chắn nên kiểm tra mọi thứ trước khi triển khai. Tôi hiện đang thử nghiệm mount NFS vì nó hoạt động tốt hơn cho các tệp nhỏ.

— Jure1873
nguồn

1

GlusterFS khó triển khai. Đối với dữ liệu web, mức độ đồng bộ hóa tệp như Unison dễ triển khai và bảo trì hơn nhiều.

DRBD là một giải pháp hoàn hảo để giữ đồng bộ dữ liệu ở cấp độ khối. Nhưng bạn phải định dạng chúng thành định dạng đặc biệt như OCFS2 hoặc một cái gì đó tương tự.

— trượngtx
nguồn

GlusterFS không giống như DRBD - nó không hoạt động ở cấp độ khối, nhưng ở cấp độ tệp. Nhưng tôi đồng ý rằng unison dễ triển khai hơn.

— Jure1873

-3

Tại sao bạn không sử dụng một công cụ như con rối ? Viết một lần trong một nguồn và một khi đã sẵn sàng triển khai nó tới các mục tiêu bằng cách sử dụng "cú đá rối" hoặc mcolletive. Nó được ghi chép lại. Và bạn có thể dễ dàng thêm máy chủ sau này nếu cần.

Bạn cũng có thể dựa vào các công cụ sử dụng inotify, như lsyncd, hoạt động ở cấp kernel. Nó theo dõi các thay đổi trong một thư mục và kích hoạt đồng bộ hóa. Nhưng nếu một công cụ dành riêng cho việc đồng bộ hóa các tệp trên một cụm như csync2 là không đủ thì tôi không biết nó sẽ là gì.

Để chắc chắn, các sửa đổi cũng xảy ra trên máy chủ 2 hay chỉ trên máy chủ 1?

— Rosco
nguồn

3

Downvote - Puppet không phải là một cách tốt để giữ các tệp được đồng bộ hóa giữa các máy chủ. Đó là tuy nhiên một công cụ tuyệt vời để quản lý cấu hình máy chủ .

— Craig Watson

Sửa đổi có thể xảy ra tại bất kỳ máy chủ nào, vì chúng tham gia vào một thiết lập cân bằng tải. Người dùng có thể tải tệp lên bất kỳ máy chủ nào và do đó tệp đó sẽ có sẵn trên tất cả các máy chủ vì lưu lượng được lan truyền giữa các máy chủ.

— sbrattla

1

Chà, trong trường hợp này con rối không phải là thứ bạn muốn (nhưng vẫn là @Craig Watson, một tệp là một tệp, cấu hình hoặc HTML, nó vẫn là một tệp). Tôi nghi ngờ rằng GlusterFS đã sẵn sàng để sản xuất, vì vậy nếu bạn thực sự muốn thứ gì đó an toàn, tốt hơn bạn nên sử dụng máy chủ NFS có tính sẵn sàng cao.

— Rosco