Roundrobin cho các tệp đến

Một loạt các tệp mới với tên tệp duy nhất thường xuyên "xuất hiện" ¹ trên một máy chủ. (Giống như hàng trăm GB dữ liệu mới mỗi ngày, giải pháp nên có thể mở rộng thành terabyte. Mỗi tệp có dung lượng lớn vài megabyte, lên đến vài chục megabyte.)

Có một số máy xử lý các tệp đó. (Hàng chục, giải pháp nên có thể mở rộng đến hàng trăm.) Có thể dễ dàng thêm và xóa các máy mới.

Có các máy chủ lưu trữ tệp sao lưu mà trên đó mỗi tệp đến phải được sao chép để lưu trữ. Dữ liệu không được mất, tất cả các tệp đến phải được gửi trên máy chủ lưu trữ sao lưu.

Mỗi bí ẩn tệp đến được gửi đến một máy duy nhất để xử lý và nên được sao chép vào máy chủ lưu trữ sao lưu.

Máy chủ nhận không cần lưu trữ tệp sau khi gửi chúng trên đường đi.

Vui lòng tư vấn một giải pháp mạnh mẽ để phân phối các tệp theo cách, được mô tả ở trên. Giải pháp không được dựa trên Java. Các giải pháp Unix được ưa thích hơn.

Máy chủ dựa trên Ubuntu, được đặt trong cùng một trung tâm dữ liệu. Tất cả những thứ khác có thể được điều chỉnh cho các yêu cầu giải pháp.

¹ Lưu ý rằng tôi cố tình bỏ qua thông tin về cách các tệp được chuyển đến hệ thống tệp. Lý do là các tệp đang được gửi bởi các bên thứ ba bởi một số di sản khác nhau hiện nay (đủ kỳ lạ, thông qua scp và qua MQ). Có vẻ dễ dàng hơn để cắt giao diện cụm chéo ở cấp hệ thống tệp, nhưng nếu một hoặc một giải pháp khác thực sự sẽ yêu cầu một số vận chuyển cụ thể - vận chuyển kế thừa có thể được nâng cấp lên cấp độ đó.

Đây là một giải pháp cho những gì bạn đang tìm kiếm. Không có java nào liên quan đến việc tạo ra hệ thống này, chỉ có sẵn các bit Nguồn mở. Mô hình được trình bày ở đây có thể hoạt động với các công nghệ khác ngoài các công nghệ tôi đang sử dụng làm ví dụ.

1. Các tệp được HTTP POST gửi đến một địa chỉ DNS Round-Robin cụ thể.
2. Hệ thống POST các tệp sau đó thả một công việc vào hệ thống AMQP (Rabbit MQ ở đây), bằng cách sử dụng một cặp cân bằng tải khác, để bắt đầu quy trình xử lý.
3. Các bộ cân bằng tải nhận HTTP POST đều nằm trước một nhóm các máy chủ lưu trữ đối tượng OpenStack Swift.
   • Mỗi bộ cân bằng tải đều có hai hoặc nhiều máy chủ lưu trữ đối tượng OpenStack Swift phía sau chúng.
   • 'Round Robin không phải là HA' nếu các mục tiêu là HA. YMMV.
   • Để tăng độ bền, các IP trong RRDNS có thể là các cụm LB dự phòng nóng riêng lẻ.
4. Máy chủ Object Store thực sự có được POST sẽ chuyển tệp đến hệ thống tệp dựa trên Gluster.
   • Hệ thống Gluster phải được phân phối (còn gọi là phân đoạn) và sao chép. Điều này cho phép nó mở rộng đến mật độ ngớ ngẩn.
5. Hệ thống AMQP gửi công việc đầu tiên, tạo bản sao lưu, đến một nút xử lý có sẵn.
6. Nút xử lý sao chép tệp từ bộ lưu trữ chính sang bộ lưu trữ dự phòng và báo cáo thành công / thất bại khi cần thiết.
   • Chế độ thất bại xử lý không được sơ đồ ở đây. Về cơ bản, tiếp tục cố gắng cho đến khi nó hoạt động. Và nếu nó không bao giờ hoạt động, hãy chạy qua một quy trình ngoại lệ.
7. Khi sao lưu xong AMQP, sau đó gửi công việc Xử lý đến một nút xử lý có sẵn.
8. Nút xử lý kéo tệp vào hệ thống tệp cục bộ hoặc xử lý tệp trực tiếp từ Gluster.
9. Xử lý tiền gửi nút xử lý sản phẩm bất cứ nơi nào đi và báo cáo thành công cho AMQP.

Thiết lập này sẽ có thể ăn các tệp với tốc độ cực cao cho đủ máy chủ. Có thể thực hiện được tốc độ ăn vào tổng hợp 10GbE nếu bạn tăng kích thước đủ. Tất nhiên, việc xử lý nhiều dữ liệu nhanh như vậy sẽ cần nhiều máy chủ hơn trong lớp Máy xử lý của bạn. Thiết lập này sẽ mở rộng lên đến một nghìn nút và có thể vượt xa (mặc dù bao xa phụ thuộc vào chính xác, bạn đang làm gì với tất cả những điều này).

Những thách thức kỹ thuật sâu sẽ nằm trong quy trình quản lý quy trình làm việc ẩn bên trong quy trình AMQP. Đó là tất cả phần mềm và có thể được tùy chỉnh được xây dựng theo yêu cầu của hệ thống của bạn. Nhưng nó nên được nuôi dưỡng tốt với dữ liệu!

Vì bạn đã làm rõ rằng các tệp sẽ đến thông qua scp, tôi không thấy bất kỳ lý do nào để máy chủ ngoại vi tồn tại, vì cơ chế vận chuyển là thứ có thể được chuyển hướng ở lớp 3.

Tôi sẽ đặt một giám đốc LVS (cặp) ở phía trước, với một nhóm máy chủ xử lý phía sau và chính sách chuyển hướng vòng tròn. Điều đó giúp dễ dàng thêm và trừ các máy chủ vào / ra khỏi nhóm, điều này làm tăng độ tin cậy vì không có máy chủ đầu cuối nào bị đổ, và điều đó có nghĩa là chúng ta không phải giải quyết câu hỏi kéo / đẩy về việc lấy các tệp từ front-end đến các máy chủ xử lý vì không có front-end.

Mỗi máy chủ nhóm nên thực hiện hai điều khi nhận tệp - trước tiên, sao chép tệp đó vào bộ lưu trữ, sau đó xử lý tệp và gửi tệp trên đường đi.