Này Habr!
Chúng tôi xin nhắc bạn rằng chúng tôi đã phát hành một ứng dụng cực kỳ thú vị và hữu ích khác về các mẫu Kubernetes. Tất cả bắt đầu với "" Brendan Burns, và nhân tiện, chúng tôi có công việc trong lĩnh vực này . Hôm nay chúng tôi mời bạn đọc một bài viết từ blog MinIO phác thảo ngắn gọn các xu hướng và chi tiết cụ thể về các mẫu lưu trữ dữ liệu trong Kubernetes.
Kubernetes đã thay đổi căn bản các mô hình triển khai và phát triển ứng dụng truyền thống. Giờ đây, nhóm có thể phát triển, thử nghiệm và triển khai ứng dụng chỉ trong vài ngày—trên nhiều môi trường, tất cả đều nằm trong cụm Kubernetes. Công việc như vậy với các thế hệ công nghệ trước đây thường mất hàng tuần, nếu không muốn nói là hàng tháng.
Khả năng tăng tốc này được thực hiện nhờ tính trừu tượng do Kubernetes cung cấp - nghĩa là do bản thân Kubernetes tương tác với các chi tiết cấp thấp của máy vật lý hoặc máy ảo, cho phép người dùng khai báo bộ xử lý mong muốn, dung lượng bộ nhớ mong muốn và số lượng vùng chứa trường hợp, trong số các tham số khác. Với một cộng đồng khổng lồ hỗ trợ Kubernetes và việc áp dụng nó liên tục mở rộng, Kubernetes dẫn đầu trong số tất cả các nền tảng điều phối container với biên độ rộng.
Khi việc sử dụng Kubernetes ngày càng tăng thì sự nhầm lẫn về mô hình lưu trữ của nó cũng tăng theo..
Với việc mọi người đang tranh giành một miếng bánh Kubernetes (tức là lưu trữ dữ liệu), khi nói về việc lưu trữ dữ liệu, tín hiệu sẽ bị chìm trong rất nhiều nhiễu.
Kubernetes là hiện thân của một mô hình hiện đại để phát triển, triển khai và quản lý ứng dụng. Mô hình hiện đại này tách việc lưu trữ dữ liệu khỏi tính toán. Để hiểu đầy đủ về sự tách rời trong bối cảnh Kubernetes, bạn cũng cần hiểu ứng dụng có trạng thái và không có trạng thái là gì cũng như cách lưu trữ dữ liệu phù hợp với điều đó. Đây là lúc cách tiếp cận API REST được S3 sử dụng có lợi thế rõ ràng so với cách tiếp cận POSIX/CSI của các giải pháp khác.
Trong bài viết này, chúng ta sẽ nói về các mẫu lưu trữ dữ liệu trong Kubernetes và đặc biệt đề cập đến cuộc tranh luận giữa các ứng dụng có trạng thái và không có trạng thái để hiểu rõ hơn sự khác biệt giữa chúng là gì và tại sao nó lại quan trọng. Phần còn lại của văn bản sẽ xem xét các ứng dụng và mẫu lưu trữ dữ liệu của chúng dựa trên các phương pháp hay nhất để làm việc với vùng chứa và Kubernetes.
Vùng chứa không quốc tịch
Về bản chất, container có trọng lượng nhẹ và phù du. Chúng có thể dễ dàng dừng, loại bỏ hoặc triển khai sang nút khác - tất cả chỉ trong vài giây. Trong một hệ thống điều phối vùng chứa lớn, các hoạt động như vậy diễn ra mọi lúc và người dùng thậm chí không nhận thấy những thay đổi đó. Tuy nhiên, việc di chuyển chỉ có thể thực hiện được nếu vùng chứa không có bất kỳ sự phụ thuộc nào vào nút mà nó được đặt. Những thùng chứa như vậy được cho là có tác dụng không quốc tịch.
Vùng chứa trạng thái
Nếu một vùng chứa lưu trữ dữ liệu trên các thiết bị được gắn cục bộ (hoặc trên một thiết bị khối), thì kho dữ liệu chứa nó sẽ phải được chuyển đến một nút mới, cùng với chính vùng chứa đó, trong trường hợp xảy ra lỗi. Điều này rất quan trọng vì nếu không ứng dụng đang chạy trong vùng chứa sẽ không thể hoạt động bình thường vì nó cần truy cập dữ liệu được lưu trữ trên phương tiện cục bộ. Những thùng chứa như vậy được cho là có tác dụng có trạng thái.
Từ quan điểm thuần túy kỹ thuật, các vùng chứa trạng thái cũng có thể được chuyển sang các nút khác. Điều này thường đạt được bằng cách sử dụng hệ thống tệp phân tán hoặc khối lưu trữ mạng được gắn vào tất cả các nút đang chạy vùng chứa. Bằng cách này, các khối chứa truy cập vào khối lượng để lưu trữ dữ liệu liên tục và thông tin được lưu trữ trên các đĩa nằm trên toàn mạng. Tôi sẽ gọi phương pháp này là “cách tiếp cận container trạng thái", và phần còn lại của bài viết tôi sẽ gọi như vậy để thống nhất.
Theo cách tiếp cận vùng chứa trạng thái điển hình, tất cả các nhóm ứng dụng được gắn vào một hệ thống tệp phân tán duy nhất—một loại bộ nhớ dùng chung nơi chứa tất cả dữ liệu ứng dụng. Mặc dù có thể có một số biến thể nhưng đây là cách tiếp cận cấp cao.
Bây giờ chúng ta hãy xem tại sao cách tiếp cận vùng chứa trạng thái lại là một mô hình phản đối trong thế giới lấy đám mây làm trung tâm.
Thiết kế ứng dụng dựa trên nền tảng đám mây
Theo truyền thống, các ứng dụng sử dụng cơ sở dữ liệu để lưu trữ thông tin có cấu trúc và đĩa cục bộ hoặc hệ thống tệp phân tán, nơi tất cả dữ liệu phi cấu trúc hoặc thậm chí bán cấu trúc đều được lưu trữ. Khi khối lượng dữ liệu phi cấu trúc tăng lên, các nhà phát triển nhận ra rằng POSIX quá ồn ào, tốn nhiều chi phí đáng kể và cuối cùng cản trở hiệu suất ứng dụng khi chuyển sang quy mô thực sự lớn.
Điều này chủ yếu góp phần vào sự xuất hiện của một tiêu chuẩn mới để lưu trữ dữ liệu, tức là lưu trữ dựa trên đám mây, hoạt động chủ yếu dựa trên API REST và giải phóng ứng dụng khỏi việc bảo trì gánh nặng việc lưu trữ dữ liệu cục bộ. Trong trường hợp này, ứng dụng sẽ chuyển sang chế độ không trạng thái một cách hiệu quả (vì trạng thái được lưu trữ từ xa). Các ứng dụng hiện đại được xây dựng từ đầu với yếu tố này. Theo quy định, bất kỳ ứng dụng hiện đại nào xử lý dữ liệu thuộc loại này hay loại khác (nhật ký, siêu dữ liệu, đốm màu, v.v.) đều được xây dựng theo mô hình hướng đám mây, trong đó trạng thái được chuyển sang hệ thống phần mềm dành riêng cho việc lưu trữ.
Cách tiếp cận vùng chứa trạng thái buộc toàn bộ mô hình này quay trở lại chính xác nơi nó bắt đầu!
Bằng cách sử dụng giao diện POSIX để lưu trữ dữ liệu, các ứng dụng hoạt động như thể chúng ở trạng thái và do đó, chúng rời xa các nguyên lý quan trọng nhất của thiết kế lấy đám mây làm trung tâm, tức là khả năng thay đổi kích thước của các luồng xử lý ứng dụng tùy thuộc vào dữ liệu đến input.load, di chuyển đến nút mới ngay khi nút hiện tại bị lỗi, v.v.
Xem xét kỹ hơn tình huống này, chúng tôi thấy rằng khi chọn một kho lưu trữ dữ liệu, chúng tôi nhiều lần phải đối mặt với tình thế khó xử giữa POSIX và REST API, NHƯNG với các vấn đề POSIX ngày càng trầm trọng hơn do tính chất phân tán của môi trường Kubernetes. Đặc biệt,
- POSIX đang trò chuyện: Ngữ nghĩa POSIX yêu cầu mỗi thao tác phải được liên kết với siêu dữ liệu và bộ mô tả tệp giúp duy trì trạng thái của thao tác. Điều này dẫn đến chi phí đáng kể không có giá trị thực. API lưu trữ đối tượng, đặc biệt là API S3, loại bỏ các yêu cầu này, cho phép ứng dụng kích hoạt và sau đó “quên” lệnh gọi. Phản hồi của hệ thống lưu trữ cho biết hành động đó có thành công hay không. Nếu thất bại, ứng dụng có thể thử lại.
- Hạn chế mạng: Trong hệ thống phân tán, có nghĩa là có thể có nhiều ứng dụng đang cố gắng ghi dữ liệu vào cùng một phương tiện được đính kèm. Do đó, không chỉ các ứng dụng sẽ cạnh tranh với nhau về băng thông truyền dữ liệu (để gửi dữ liệu đến phương tiện truyền thông) mà chính hệ thống lưu trữ cũng sẽ cạnh tranh về băng thông này bằng cách gửi dữ liệu qua các đĩa vật lý. Do tính đáng tin cậy của POSIX, số lượng cuộc gọi mạng tăng lên nhiều lần. Mặt khác, API S3 cung cấp sự phân biệt rõ ràng giữa các cuộc gọi mạng giữa những cuộc gọi bắt nguồn từ máy khách đến máy chủ và những cuộc gọi xảy ra trong máy chủ.
- Безопасность: Mô hình bảo mật POSIX được thiết kế cho sự tham gia tích cực của con người: quản trị viên định cấu hình các cấp độ truy cập cụ thể cho từng người dùng hoặc nhóm. Mô hình này khó có thể thích ứng với một thế giới lấy đám mây làm trung tâm. Các ứng dụng hiện đại phụ thuộc vào các mô hình bảo mật dựa trên API, trong đó quyền truy cập được xác định là một tập hợp các chính sách, tài khoản dịch vụ, thông tin xác thực tạm thời, v.v. được phân bổ.
- Khả năng quản lý: Vùng chứa trạng thái có một số chi phí quản lý. Chúng ta đang nói về việc đồng bộ hóa quyền truy cập song song vào dữ liệu, đảm bảo tính nhất quán của dữ liệu, tất cả điều này đòi hỏi phải xem xét cẩn thận về việc sử dụng mẫu truy cập dữ liệu nào. Phần mềm bổ sung phải được cài đặt, giám sát và định cấu hình, chưa kể nỗ lực phát triển bổ sung.
Giao diện lưu trữ dữ liệu vùng chứa
Mặc dù Giao diện lưu trữ vùng chứa (CSI) đã giúp ích rất nhiều cho sự phát triển của lớp khối lượng Kubernetes, gia công một phần cho các nhà cung cấp lưu trữ bên thứ ba, nhưng nó cũng vô tình góp phần vào niềm tin rằng cách tiếp cận vùng chứa trạng thái là phương pháp được khuyến nghị cho lưu trữ dữ liệu trong Kubernetes.
CSI được phát triển như một tiêu chuẩn để cung cấp hệ thống lưu trữ tệp và khối tùy ý cho các ứng dụng cũ khi chạy trên Kubernetes. Và, như bài viết này đã chỉ ra, tình huống duy nhất trong đó cách tiếp cận vùng chứa trạng thái (và CSI ở dạng hiện tại) có ý nghĩa là khi bản thân ứng dụng là một hệ thống cũ trong đó không thể thêm hỗ trợ cho API lưu trữ đối tượng .
Điều quan trọng là phải hiểu rằng việc sử dụng CSI ở dạng hiện tại, tức là gắn khối lượng khi làm việc với các ứng dụng hiện đại, chúng ta sẽ gặp phải những vấn đề gần như tương tự nảy sinh trong các hệ thống tổ chức lưu trữ dữ liệu theo kiểu POSIX.
Một cách tiếp cận tốt hơn
Trong trường hợp này, điều quan trọng là phải hiểu rằng hầu hết các ứng dụng vốn không được thiết kế dành riêng cho công việc có trạng thái hoặc không có trạng thái. Hành vi này phụ thuộc vào kiến trúc hệ thống tổng thể và các lựa chọn thiết kế cụ thể được thực hiện. Hãy nói một chút về các ứng dụng có trạng thái.
Về nguyên tắc, tất cả dữ liệu ứng dụng có thể được chia thành nhiều loại:
- Dữ liệu nhật ký
- Dữ liệu dấu thời gian
- Dữ liệu giao dịch
- metadata
- Hình ảnh vùng chứa
- Dữ liệu Blob (đối tượng lớn nhị phân)
Tất cả các loại dữ liệu này đều được hỗ trợ rất tốt trên các nền tảng lưu trữ hiện đại và có một số nền tảng dựa trên đám mây được thiết kế để cung cấp dữ liệu ở từng định dạng cụ thể này. Ví dụ: dữ liệu giao dịch và siêu dữ liệu có thể nằm trong cơ sở dữ liệu gốc đám mây hiện đại như CockroachDB, YugaByte, v.v. Hình ảnh vùng chứa hoặc dữ liệu blob có thể được lưu trữ trong sổ đăng ký docker dựa trên MinIO. Dữ liệu dấu thời gian có thể được lưu trữ trong cơ sở dữ liệu chuỗi thời gian như InfluxDB, v.v. Chúng tôi sẽ không đi vào chi tiết về từng loại dữ liệu và ứng dụng của nó ở đây, nhưng ý tưởng chung là tránh việc lưu trữ dữ liệu liên tục dựa vào việc gắn đĩa cục bộ.
Ngoài ra, việc cung cấp một lớp bộ nhớ đệm tạm thời đóng vai trò là kho lưu trữ tệp tạm thời cho các ứng dụng thường rất hiệu quả, nhưng các ứng dụng không nên phụ thuộc vào lớp này làm nguồn đáng tin cậy.
Lưu trữ ứng dụng trạng thái
Mặc dù trong hầu hết các trường hợp, việc giữ cho các ứng dụng không có trạng thái là rất hữu ích, nhưng những ứng dụng được thiết kế để lưu trữ dữ liệu - chẳng hạn như cơ sở dữ liệu, kho đối tượng, kho khóa-giá trị - phải ở trạng thái. Hãy xem lý do tại sao các ứng dụng này được triển khai trên Kubernetes. Hãy lấy MinIO làm ví dụ, nhưng các nguyên tắc tương tự cũng áp dụng cho bất kỳ hệ thống lưu trữ gốc đám mây lớn nào khác.
Các ứng dụng gốc trên nền tảng đám mây được thiết kế để tận dụng tối đa tính linh hoạt vốn có của các vùng chứa. Điều này có nghĩa là họ không đưa ra giả định nào về môi trường mà họ sẽ được triển khai. Ví dụ: MinIO sử dụng cơ chế mã hóa xóa nội bộ để cung cấp cho hệ thống đủ khả năng phục hồi để duy trì hoạt động ngay cả khi một nửa số ổ đĩa bị lỗi. MinIO cũng quản lý tính toàn vẹn và bảo mật dữ liệu bằng cách sử dụng hàm băm và mã hóa phía máy chủ độc quyền.
Đối với các ứng dụng tập trung vào đám mây như vậy, khối lượng liên tục cục bộ (PV) thuận tiện nhất làm kho lưu trữ dự phòng. Quang điện cục bộ cung cấp khả năng lưu trữ dữ liệu thô, trong khi các ứng dụng chạy trên các quang điện này sẽ thu thập thông tin một cách độc lập để mở rộng quy mô dữ liệu và quản lý nhu cầu dữ liệu ngày càng tăng.
Cách tiếp cận này đơn giản hơn nhiều và có khả năng mở rộng đáng kể hơn so với các PV dựa trên CSI, vốn đưa các lớp quản lý và dự phòng dữ liệu của riêng chúng vào hệ thống; vấn đề là các lớp này thường xung đột với các ứng dụng được thiết kế ở trạng thái.
Một phong trào mạnh mẽ hướng tới việc tách dữ liệu khỏi các phép tính
Trong bài viết này, chúng ta đã nói về cách các ứng dụng được định hướng lại để hoạt động mà không lưu trạng thái, hay nói cách khác, việc lưu trữ dữ liệu được tách rời khỏi hoạt động tính toán trên đó. Để kết luận, chúng ta hãy xem xét một số ví dụ thực tế về xu hướng này.
, một nền tảng phân tích dữ liệu nổi bật, có truyền thống ở trạng thái và được triển khai trên HDFS. Tuy nhiên, khi Spark chuyển sang thế giới lấy đám mây làm trung tâm, nền tảng này ngày càng được sử dụng không trạng thái bằng cách sử dụng `s3a`. Spark sử dụng s3a để chuyển trạng thái sang các hệ thống khác, trong khi bản thân các thùng chứa Spark hoạt động hoàn toàn không trạng thái. Đặc biệt, những doanh nghiệp lớn khác trong lĩnh vực phân tích dữ liệu lớn, , , Họ cũng đang chuyển sang làm việc với việc tách biệt việc lưu trữ dữ liệu và tính toán trên đó.
Các mô hình tương tự cũng có thể được nhìn thấy trên các nền tảng phân tích lớn khác, bao gồm Presto, Tensorflow to R, Jupyter. Bằng cách giảm tải trạng thái cho các hệ thống lưu trữ đám mây từ xa, việc quản lý và mở rộng quy mô ứng dụng của bạn trở nên dễ dàng hơn nhiều. Ngoài ra, nó còn tạo điều kiện thuận lợi cho tính di động của ứng dụng với nhiều môi trường khác nhau.
Nguồn: www.habr.com