MinIO có thể được triển khai theo cách phân tán nhằm sử dụng hiệu quả tài nguyên của nhiều tài nguyên lưu trữ và tính toán của máy vật lý hoặc máy ảo. Đây có thể là MinIO chạy trong môi trường đám mây riêng tư hoặc công cộng, chẳng hạn như với Amazon Web Services, Google Cloud Platform, nền tảng Azure của Microsoft và nhiều nền tảng khác. MinIO có thể triển khai theo một số loại cấu trúc liên kết – trong quá trình sản xuất, chúng tôi khuyên bạn nên triển khai Multi-Node Multi-Drive (MNMD). MinIO khuyến nghị sao chép trang web để cung cấp hỗ trợ khôi phục và chuyển đổi dự phòng cấp BC/DR cho việc triển khai trang web duy nhất của bạn, giúp bạn có thể thiết kế và tối ưu hóa cho trường hợp sử dụng của mình.
Trong bài đăng trên blog trước đây, chúng tôi đã thảo luận về một số phương pháp hay nhất nên sử dụng khi chọn phần cứng để triển khai MinIO của bạn . Chúng tôi đã đề cập đến nhiều khía cạnh khác nhau của phần cứng từ việc chọn vùng tốt nhất, ổ đĩa, cấu hình CPU và bộ nhớ phù hợp cũng như thậm chí một số cấu hình mạng được đề xuất. Mặc dù chúng tôi đã đề cập đến nhiều phương pháp hay nhất khác nhau dành cho thiết kế hệ thống, nhưng chúng tôi luôn có thể đi sâu hơn và hôm nay chúng tôi sẽ tìm hiểu một số điểm hay xung quanh việc thiết kế MinIO để đạt được hiệu suất tốt nhất từ ổ đĩa và mạng.
Trong bài đăng trên blog này, chúng ta sẽ đi sâu vào các cấu hình mạng mà bạn có thể định cấu hình MinIO cho các chiến lược sao chép và cấu trúc liên kết mạng khác nhau có thể được sử dụng để đảm bảo dữ liệu của bạn được lưu trữ và truy cập hiệu quả trong nhiều lần triển khai MinIO. Bạn không cần thực hiện bất kỳ cấu hình phức tạp nào chẳng hạn như thiết lập NIC ngoại quan/kép (điều này bổ sung thêm chi phí).
MinIO là phần phụ trợ lưu trữ tương thích với S3 dành cho các dịch vụ gốc đám mây. Nói chung, chúng tôi coi lưu lượng truy cập mạng là giữa các ứng dụng và cụm hoặc giữa các nút trong cụm. Do lưu lượng truy cập nội bộ, điều tối quan trọng là kết nối mạng giữa các nút càng nhanh càng tốt. Mỗi nhóm bao gồm một nhóm nút độc lập với các bộ xóa riêng. MinIO phải truy vấn từng nhóm để xác định bộ xóa chính xác mà nó hướng dẫn các hoạt động đọc và ghi, sao cho mỗi nhóm bổ sung sẽ thêm lưu lượng nút nội bộ tối thiểu nhưng tăng lên trên mỗi cuộc gọi. Nhóm chứa bộ xóa chính xác sẽ phản hồi lại thao tác, vẫn hoàn toàn trong suốt đối với ứng dụng.
Đã qua rồi cái thời doanh nghiệp có thể tồn tại với NIC 1 GbE hoặc 10 GbE. Khối lượng công việc của doanh nghiệp hiện đại sử dụng lý tưởng các NIC 100 GbE. Do những hạn chế về vật lý và chi phí hoạt động của giao thức TCP, những NIC này dự kiến sẽ cung cấp 80-90% băng thông khả dụng, thường là khoảng 10GB/giây cho các NIC 100 Gbps, lên tới 12GB/giây trên các mạng được cung cấp thực sự tốt. MinIO không cần bất kỳ cấu hình mạng bổ sung nào để tận dụng toàn bộ băng thông khi nó lắng nghe trên tất cả các giao diện. MinIO sẵn sàng hỗ trợ nghe trên nhiều giao diện mạng (NIC).
Bạn không cần bất kỳ cấu hình đặc biệt nào khác cho mạng MinIO, nhưng nếu tùy ý sử dụng một số kiến thức cơ bản về mạng mà chúng ta đã thảo luận trước đó, bạn có thể định tuyến lưu lượng truy cập MinIO thông qua một giao diện cụ thể.
Trong ví dụ này, chúng tôi sẽ sử dụng hệ điều hành Linux để minh họa, nhưng các kiến thức cơ bản về mạng đều giống nhau cho dù bạn sử dụng hệ điều hành nào. Việc triển khai có thể thay đổi một chút tùy thuộc vào cấu hình mạng nhưng điều này sẽ cho bạn ý tưởng.
Đầu tiên chúng ta sẽ bắt đầu bằng cách liệt kê bảng lộ trình
$ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18
Nếu bạn đã định cấu hình máy chủ MinIO của mình nằm trong phạm vi CIDR 10.56.98.16/28, giả sử một trong các địa chỉ IP của nút MinIO là 10.56.98.21 sẽ được định tuyến qua giao diện eth0 vì /28 khớp với mục nhập bảng định tuyến cho 10.56 0,98.0/24.
Nhưng nếu bạn muốn định tuyến lưu lượng truy cập MinIO qua eth1 thay vì eth0, chúng tôi cần thêm một tuyến cụ thể cho MinIO CIDR để mọi lưu lượng truy cập phù hợp với mạng con đó sẽ được định tuyến qua giao diện mạng cụ thể đó
$ ip route add 10.56.98.16/28 dev eth1
Sau khi tuyến đường được thêm vào, hãy liệt kê lại bảng định tuyến để xem nó trông như thế nào
$ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link
Bây giờ chúng ta thấy lộ trình cho /28 CIDR. Nếu bạn ping nút MinIO 10.56.98.21 thì giờ đây nó sẽ được định tuyến qua giao diện eth1. Điều này là do khi có hai tuyến trong đó /24 trùng với /28, nhìn chung tuyến có tiền tố dài nhất sẽ được ưu tiên (trong trường hợp này là /28) và sẽ được ưu tiên hơn bất kỳ tuyến có tiền tố ngắn hơn nào khác khi định tuyến lưu lượng. Đây được gọi là quy tắc tiền tố phù hợp dài nhất.
Bạn có thể xác minh lưu lượng truy cập từ 10.56.98.16/28 đang được định tuyến phù hợp nếu bạn ping 10.56.98.21 rồi kiểm tra tcpdump như bên dưới. Bạn sẽ nhận thấy rằng lưu lượng truy cập từ nguồn 10.56.98.18 đang được định tuyến qua eth1 đến 10.56.98.21.
$ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64
Như bạn có thể thấy với MinIO, không cần thêm cổng hoặc dịch vụ đặc biệt nào để đạt được sự phân tách lưu lượng. MinIO được thiết kế với ý tưởng đơn giản và chúng tôi luôn nghĩ đến việc xây dựng so với mua trong trường hợp này thay vì kiến trúc một thứ gì đó phức tạp như dịch vụ cổng, MinIO tận dụng những kiến thức cơ bản về mạng đã có sẵn ở lớp hệ điều hành để đạt được kết quả tương tự với ít chi phí nhất khả thi.
Chúng ta có thể đưa ý tưởng này tiến thêm một bước nữa. Ngày nay, các máy chủ có ít nhất 2 giao diện với tùy chọn bổ sung thêm. Vì vậy, thay vì để lưu lượng truy cập ứng dụng đi qua các giao diện giống như MinIO, bạn có thể để ứng dụng của mình chạy trên một khối CIDR riêng biệt (chọn một khối phù hợp với kích thước ứng dụng của bạn). Sự tách biệt này đảm bảo rằng lưu lượng MinIO để sao chép và cân bằng lại không ảnh hưởng đến hiệu suất của ứng dụng và ngược lại. Nó cũng cung cấp cho bạn khả năng giám sát và theo dõi lưu lượng truy cập để đảm bảo MinIO luôn có dung lượng và băng thông cần thiết để thực hiện các hoạt động mà không ảnh hưởng đến hiệu suất của nó.
Nhưng nếu bạn có MinIO trên các trang web hoặc khu vực khác nhau thì sao? Làm cách nào bạn có thể định cấu hình nó một cách hiệu quả để đảm bảo không có tắc nghẽn về hiệu suất? Chà, có một số loại cấu hình sao chép khác nhau mà MinIO cung cấp cho một số trường hợp sử dụng nghiêm ngặt nhất hiện có.
Một trong những chiến lược sao chép phổ biến nhất là sao chép từ trang này sang trang khác. Điều này cho phép bạn khởi động MinIO với một cụm duy nhất và mở rộng sang số N khi nhu cầu tăng lên. Giả sử bạn có ứng dụng ETL/ELT chạy trên 3 trang web khác nhau. Nói chung, dữ liệu chỉ có sẵn ở một trong các khu vực và các khu vực khác cần thu thập khối lượng dữ liệu khổng lồ trên khắp các khu vực để chạy quy trình của nó. Không cần phải nói, điều này không chỉ kém hiệu quả mà còn gây áp lực rất lớn lên cơ sở hạ tầng mạng và có khả năng gây tắc nghẽn cho các ứng dụng khác dùng chung mạng WAN.
Trong cấu hình sao chép site-to-site, bạn chỉ ghi dữ liệu vào cụm MinIO ở trang đầu tiên. Quá trình sao chép sẽ tự động sao chép dữ liệu sang các trang khác. Không cần thực hiện thêm thay đổi nào đối với ứng dụng ETL/ELT. Bạn chỉ cần trỏ các công việc trong mỗi trang web tới cụm MinIO tương ứng của chúng được hỗ trợ bởi proxy ngược chẳng hạn như Nginx và quá trình đọc sẽ nhanh hơn nhiều so với khi thực hiện qua mạng WAN giữa các khu vực như được hiển thị bên dưới.
Nhưng điều đó đặt ra câu hỏi, liệu có thể tinh chỉnh lưu lượng truy cập hơn nữa không? Giả sử bạn thêm tệp dữ liệu vào trang 1, nó sẽ ngay lập tức sao chép tệp đó sang các trang khác bất kể thời gian trong ngày. Đó có thể là thời điểm cao điểm khi có lẽ các công việc ETL/ELT khác đang chạy và đồng thời tài nguyên mạng đang được sử dụng để sao chép dữ liệu có thể không được sử dụng cho đến ngày hôm sau khi đợt tiếp theo được cho là sẽ chạy. Có thể làm gì trong trường hợp đó? Đây là lúc tính năng Sao chép hàng loạt của MinIO phát huy tác dụng. Sao chép hàng loạt cho phép bạn chọn loại dữ liệu bạn muốn sao chép tại một thời điểm cụ thể, nó hoàn toàn có thể cấu hình được. Trong trường hợp này, công việc sao chép hàng loạt có thể được đặt để chạy trong giờ nghỉ khi lưu lượng truy cập ở mức thấp nhất. Vì thời gian truy cập ứng dụng có thể thay đổi trong ngày, tuần và thậm chí cả tháng, đây là lúc việc giám sát lưu lượng mạng MinIO trở nên hữu ích để bạn có thể định cấu hình tác vụ hàng loạt của mình để chạy vào đúng thời điểm. Bạn có thể triển khai các trang ngang hàng ở các giá đỡ, trung tâm dữ liệu hoặc khu vực địa lý khác nhau để hỗ trợ các chức năng như BC/DR hoặc hiệu suất đọc/ghi cục bộ trong kho đối tượng MinIO được phân phối toàn cầu.
Tóm lại, kiến trúc mạng của MinIO là một trong những kiến trúc mạng đơn giản và dễ hiểu nhất hiện nay. Thay vì phát minh lại bánh xe, MinIO sử dụng các kiến thức cơ bản về mạng để đạt được sự tương đương với một số kho dữ liệu khác có thiết lập cổng và mạng phức tạp gần như không thể gỡ lỗi. Cho dù bạn có gỡ lỗi cùng một vấn đề bao nhiêu lần thì bạn vẫn có cảm giác như đây là lần đầu tiên bạn gặp phải vấn đề đó do tính chất khó hiểu của kiến trúc. Thay vào đó, MinIO tập trung vào các tính năng trừu tượng ở cấp độ cao hơn giúp nhà phát triển ứng dụng giảm bớt gánh nặng khỏi việc phải duy trì sao chép dữ liệu và thay vào đó tập trung vào việc lưu trữ và xử lý dữ liệu.
Như thường lệ, nếu bạn có bất kỳ câu hỏi nào về cấu hình Mạng MinIO hoặc cách thiết lập nó, hãy nhớ liên hệ với chúng tôi trên Slack hoặc tốt hơn là đăng ký đăng ký SUBNET !
Cũng được xuất bản ở đây .