Đồng bộ hóa hàng triệu tệp giữa hai máy chủ Linux

Tôi có một máy chủ xuất một thư mục chứa ~ 7 triệu tệp (chủ yếu là hình ảnh) từ đĩa cục bộ của nó sang các máy khách mạng thông qua NFS .

Tôi cần thêm cái thứ hai vì lợi ích của HA, và để giữ cho nó đồng bộ với cái thứ nhất với càng ít delta giữa hai cái càng tốt.

Nghiên cứu đề xuất sử dụng lsyncd hoặc các giải pháp dựa trên cơ sở inotify khác cho việc này, nhưng với số lượng tệp tạo ra đồng hồ inotify mất một thời gian vĩnh cửu. Điều tương tự cho rsync .

Giải pháp khả thi khác có vẻ là drdb , hoặc cụm tập tin hệ thống như ceph hoặc GlusterFS , nhưng tôi không có kinh nghiệm với những người và không biết cái nào sẽ thích hợp hơn và đối phó tốt với nhiều tập tin và vẫn cung cấp hiệu suất tốt.

Lưu ý rằng hoạt động chủ yếu được đọc với ít xảy ra ghi.

Tôi có xu hướng đề xuất sao chép dữ liệu bất khả tri, như drbd. Số lượng lớn tệp sẽ khiến mọi thứ chạy ở mức cao hơn "khối lưu trữ" để dành một lượng thời gian không đáng kể để đi trên cây - như bạn đã tìm thấy bằng cách sử dụng rsync hoặc tạo đồng hồ inotify.

Phiên bản ngắn của câu chuyện cá nhân của tôi sao lưu: Tôi chưa sử dụng Ceph, nhưng tôi khá chắc chắn rằng điều này không nằm trong mục tiêu thị trường chính của họ dựa trên sự tương đồng với Gluster. Tuy nhiên, tôi đã cố gắng thực hiện loại giải pháp này với Gluster trong nhiều năm qua. Nó đã hoạt động và chạy hầu hết thời gian, mặc dù có một vài cập nhật phiên bản lớn, nhưng tôi không gặp vấn đề gì. Nếu mục tiêu của bạn là dư thừa hơn hiệu suất, Gluster có thể không phải là một giải pháp tốt. Đặc biệt, nếu kiểu sử dụng của bạn có nhiều lệnh gọi stat (), Gluster không thực sự tốt khi sao chép. Điều này là do các lệnh gọi tới khối lượng được sao chép sẽ chuyển đến tất cả các nút được sao chép (thực sự là "cục gạch", nhưng có lẽ bạn sẽ chỉ có một viên gạch trên mỗi máy chủ). Nếu bạn có bản sao 2 chiều, ví dụ: mỗi stat () từ một khách hàng chờ phản hồi từ cả hai khối để đảm bảo rằng nó sử dụng dữ liệu hiện tại. Sau đó, bạn cũng có phí FUSE và thiếu bộ nhớ đệm nếu bạn đang sử dụng hệ thống tệp gluster gốc để dự phòng (thay vì sử dụng Gluster làm phụ trợ với NFS làm giao thức và tự động dự phòng, vẫn còn vì lý do stat () . Gluster thực sự rất tốt với các tệp lớn, nơi bạn có thể truyền dữ liệu trên nhiều máy chủ; phân chia và phân phối dữ liệu hoạt động tốt, vì đó thực sự là những gì nó làm. Và bản sao kiểu RAID10 mới hơn hoạt động tốt hơn so với các bản sao thẳng cũ hơn. Nhưng, dựa trên những gì tôi đoán là mô hình sử dụng của bạn, tôi khuyên bạn nên chống lại nó. Sau đó, bạn cũng có phí FUSE và thiếu bộ nhớ đệm nếu bạn đang sử dụng hệ thống tệp gluster gốc để dự phòng (thay vì sử dụng Gluster làm phụ trợ với NFS làm giao thức và tự động dự phòng, vẫn còn vì lý do stat () . Gluster thực sự rất tốt với các tệp lớn, nơi bạn có thể truyền dữ liệu trên nhiều máy chủ; phân chia và phân phối dữ liệu hoạt động tốt, vì đó thực sự là những gì nó làm. Và bản sao kiểu RAID10 mới hơn hoạt động tốt hơn so với các bản sao thẳng cũ hơn. Nhưng, dựa trên những gì tôi đoán là mô hình sử dụng của bạn, tôi khuyên bạn nên chống lại nó. Sau đó, bạn cũng có phí FUSE và thiếu bộ nhớ đệm nếu bạn đang sử dụng hệ thống tệp gluster gốc để dự phòng (thay vì sử dụng Gluster làm phụ trợ với NFS làm giao thức và tự động dự phòng, vẫn còn vì lý do stat () . Gluster thực sự rất tốt với các tệp lớn, nơi bạn có thể truyền dữ liệu trên nhiều máy chủ; phân chia và phân phối dữ liệu hoạt động tốt, vì đó thực sự là những gì nó làm. Và bản sao kiểu RAID10 mới hơn hoạt động tốt hơn so với các bản sao thẳng cũ hơn. Nhưng, dựa trên những gì tôi đoán là mô hình sử dụng của bạn, tôi khuyên bạn nên chống lại nó. mà vẫn hút vì lý do stat ()). Gluster thực sự rất tốt với các tệp lớn, nơi bạn có thể truyền dữ liệu trên nhiều máy chủ; phân chia và phân phối dữ liệu hoạt động tốt, vì đó thực sự là những gì nó làm. Và bản sao kiểu RAID10 mới hơn hoạt động tốt hơn so với các bản sao thẳng cũ hơn. Nhưng, dựa trên những gì tôi đoán là mô hình sử dụng của bạn, tôi khuyên bạn nên chống lại nó. mà vẫn hút vì lý do stat ()). Gluster thực sự rất tốt với các tệp lớn, nơi bạn có thể truyền dữ liệu trên nhiều máy chủ; phân chia và phân phối dữ liệu hoạt động tốt, vì đó thực sự là những gì nó làm. Và bản sao kiểu RAID10 mới hơn hoạt động tốt hơn so với các bản sao thẳng cũ hơn. Nhưng, dựa trên những gì tôi đoán là mô hình sử dụng của bạn, tôi khuyên bạn nên chống lại nó.

Hãy nhớ rằng có lẽ bạn sẽ phải tìm cách có các cuộc bầu cử tổng thể giữa các máy hoặc thực hiện khóa phân tán. Các giải pháp thiết bị khối chia sẻ yêu cầu một hệ thống tệp nhận biết đa chủ (như GFS) hoặc chỉ yêu cầu một nút gắn hệ thống đọc ghi. Các hệ thống tập tin nói chung không thích khi dữ liệu được thay đổi ở cấp thiết bị khối bên dưới chúng. Điều đó có nghĩa là khách hàng của bạn sẽ cần có khả năng cho biết đó là chủ và viết yêu cầu trực tiếp ở đó. Điều đó có thể trở thành một phiền toái lớn. Nếu GFS và tất cả các cơ sở hạ tầng hỗ trợ của nó là một tùy chọn, thì drbd ở chế độ đa chủ (họ gọi nó là "chính kép") có thể hoạt động tốt. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode để biết thêm thông tin về điều đó.

Bất kể bạn đi theo hướng nào, bạn đều có thể thấy rằng đây vẫn là một nỗi đau khá lớn để làm thời gian thực mà không chỉ cung cấp cho công ty SAN một xe tải tiền.

Tôi đã chuyển từ rsync sang ceph với sự trợ giúp của thiết lập Proxmox VE.

Bây giờ tôi đang quản lý 14TB trong một cụm với bản sao trực tiếp. Trong gần 4 năm.