Chúng tôi có một cụm GlusterFS mà chúng tôi sử dụng cho chức năng xử lý của mình. Chúng tôi muốn tích hợp Windows vào nó, nhưng đang gặp một số khó khăn khi tìm ra cách tránh sự cố đơn điểm là máy chủ Samba phục vụ âm lượng GlusterFS.
Luồng tệp của chúng tôi hoạt động như thế này:
- Các tệp được đọc bởi một nút xử lý Linux.
- Các tập tin được xử lý.
- Kết quả (có thể nhỏ, có thể khá lớn) được ghi lại vào tập GlusterFS khi chúng được thực hiện.
- Kết quả có thể được ghi vào cơ sở dữ liệu thay thế hoặc có thể bao gồm một số tệp có kích thước khác nhau.
- Nút xử lý chọn một công việc khác ngoài hàng đợi và GOTO 1.
Gluster là tuyệt vời vì nó cung cấp một khối lượng phân tán, cũng như sao chép ngay lập tức. Khả năng phục hồi thảm họa là tốt đẹp! Chúng tôi thích nó.
Tuy nhiên, vì Windows không có máy khách GlusterFS riêng, chúng tôi cần một số cách để các nút xử lý dựa trên Windows của chúng tôi tương tác với kho lưu trữ tệp theo cách tương tự. Các tiểu bang GlusterFS tài liệu rằng cách để cung cấp truy cập Windows là để thiết lập một máy chủ Samba trên đỉnh của một khối lượng gắn GlusterFS. Điều đó sẽ dẫn đến một luồng tập tin như thế này:
Điều đó có vẻ như là một điểm thất bại đối với tôi.
Một tùy chọn là phân cụm Samba , nhưng dường như dựa trên mã không ổn định ngay bây giờ và do đó không hoạt động.
Vì vậy, tôi đang tìm kiếm một phương pháp khác.
Một số chi tiết chính về các loại dữ liệu chúng tôi ném xung quanh:
- Kích thước tệp gốc có thể ở bất kỳ đâu từ vài KB đến hàng chục GB.
- Kích thước tệp được xử lý có thể ở bất kỳ đâu từ vài KB đến GB hoặc hai.
- Một số quy trình, chẳng hạn như đào trong tệp lưu trữ như .zip hoặc .tar có thể khiến RẤT NHIỀU ghi thêm khi các tệp được chứa được nhập vào kho lưu trữ tệp.
- Số lượng tập tin có thể vào 10 triệu.
Khối lượng công việc này không hoạt động với thiết lập Hadoop "kích thước công việc tĩnh". Tương tự, chúng tôi đã đánh giá các cửa hàng đối tượng kiểu S3, nhưng thấy chúng thiếu.
Ứng dụng của chúng tôi là tùy chỉnh được viết bằng Ruby và chúng tôi có môi trường Cygwin trên các nút Windows. Điều này có thể giúp chúng tôi.
Một tùy chọn tôi đang xem xét là một dịch vụ HTTP đơn giản trên một cụm máy chủ có gắn khối lượng GlusterFS. Vì tất cả những gì chúng tôi đang làm với Gluster về cơ bản là các hoạt động GET / PUT, có vẻ như có thể dễ dàng chuyển sang phương thức truyền tệp dựa trên HTTP. Đặt chúng phía sau một cặp cân bằng tải và các nút Windows có thể HTTP PUT với nội dung trái tim nhỏ màu xanh của chúng.
Những gì tôi không biết là làm thế nào sự gắn kết của GlusterFS sẽ được duy trì . Lớp proxy HTTP giới thiệu đủ độ trễ giữa khi nút xử lý báo cáo rằng nó được thực hiện bằng ghi và khi nó thực sự hiển thị trên ổ đĩa GlusterFS, tôi lo lắng về các giai đoạn xử lý sau này khi cố gắng lấy tệp sẽ không tìm nó. Tôi khá chắc chắn rằng việc sử dụng direct-io-mode=enabletùy chọn gắn kết sẽ giúp ích, nhưng tôi không chắc liệu điều đó có đủ không . Tôi nên làm gì khác để cải thiện sự gắn kết?
Hay tôi nên theo đuổi một phương pháp khác hoàn toàn?
Như Tom chỉ ra dưới đây, NFS là một lựa chọn khác. Vì vậy, tôi đã chạy thử nghiệm. Vì các tệp được đề cập ở trên có tên do khách hàng cung cấp mà chúng tôi cần giữ và có thể đến bằng bất kỳ ngôn ngữ nào, chúng tôi cần phải giữ nguyên tên tệp. Vì vậy, tôi đã xây dựng một thư mục với các tệp này:
Khi tôi gắn kết nó từ hệ thống Server 2008 R2 đã cài đặt Máy khách NFS, tôi nhận được một danh sách thư mục như thế này:
Rõ ràng, Unicode không được bảo tồn. Vì vậy, NFS sẽ không làm việc cho tôi.
ctdbổn định và sẵn sàng cho việc sử dụng sản xuất và câu đầu tiên trong liên kết bạn đưa ra làm cho câu thứ hai không hợp lệ vì nếu không bao giờ được cập nhật. Tôi đã lên kế hoạch thiết lập điều này, nhưng trước khi tôi nhận được điều này, tôi đã chuyển việc sang một môi trường gần như không có cửa sổ.