Tự động mở rộng quy mô với Apache Helix và Apache YARN
Nếu Apache Helix là một khuôn khổ quản lý cụm chung mã nguồn mở để giải quyết những thách thức về cân bằng tải, cấu hình lại hoạt động, theo dõi tình trạng và phát hiện lỗi. Thì Apache Hadoop YARN lại là một trình quản lý và điều khiển tài nguyên chung cho các ứng dụng phân tán quy mô lớn. Đến từ MapReduce, YARN thúc đẩy HDFS và giới thiệu phân bổ tài nguyên dựa trên vùng chứa để triển khai, quản lý và giám sát ứng dụng có thể mở rộng. Vậy tự mở rộng quy mô với Apache Helix và Apache YARN bằng cách nào nhanh nhất?
Hãy cùng với Bizfly Cloud tìm hiểu cách tự mở rộng quy mô với Apache Helix và Apache YARN qua bài viết dưới đây.
Quy trình tự động mở rộng quy mô với Apache YARN và Apache Helix
Mỗi khuôn khổ giải quyết các khía cạnh bổ sung của vòng đời của các hệ thống:
- YARN tự động hóa việc triển khai dịch vụ, phân bổ tài nguyên và phân phối mã.
- Helix tập trung vào vận hành dịch vụ, quản lý trạng thái, cấu hình lại và xử lý lỗi.
Việc tích hợp các khả năng của Helix và YARN có tiềm năng rất lớn: chúng có thể hỗ trợ toàn bộ vòng đời của một ứng dụng phân tán, từ khởi động, khôi phục lỗi và tiến hóa cho đến lần hủy cấp phép cuối cùng.
Tính năng tự động mở rộng quy mô với Helix và YARN
Tương tự như Amazon Auto Scaling, kích thước của một cụm sẽ được điều chỉnh lên và xuống tự động dựa trên các mục tiêu do nhà điều hành xác định mà không vi phạm các ràng buộc. Ngoài việc tiết kiệm chi phí và mở rộng quy mô nhanh chóng khi nhu cầu tăng lên, hệ thống còn tự động khôi phục các lỗi một phần bằng cách thay thế các trường hợp bị lỗi. Các khả năng tự động mở rộng quy mô này độc lập với một nhà cung cấp dịch vụ đám mây cụ thể, vì vậy bạn có thể triển khai chúng tại chỗ hoặc sử dụng chúng trong các đám mây doanh nghiệp riêng và kết hợp.
Giải pháp dựa trên các bản phân phối đã được thử nghiệm và chưa sửa đổi của Helix và YARN, được kết hợp bằng cách sử dụng kiến trúc phân lớp. Có hai loại cụm hiện diện trong một triển khai:
- Cụm được quản lý: điều này giống như việc triển khai Helix thông thường với bất kỳ số lượng nút điều khiển và người tham gia nào.
- Cụm meta: thu thập các số liệu, thực hiện lập kế hoạch năng lực và đưa các vùng chứa ứng dụng vào cụm được quản lý theo yêu cầu.
Kiến trúc chuyên sâu
Cụm meta sẽ thực hiện ba nhiệm vụ chính:
- Giám sát cụm và lập kế hoạch năng lực: điều này được giải quyết bằng mô hình mục tiêu hiệu suất.
- Triển khai và giám sát vùng chứa: những người tham gia vào cụm được quản lý được tạo và phá hủy bởi các nhà cung cấp phiên bản vùng chứa.
- Cấu hình động và xử lý lỗi: được giải quyết bằng chức năng Helix hiện có bằng cách triển khai các nhà cung cấp phiên bản vùng chứa với tư cách là những người tham gia.
Tự động mở rộng quy mô
Chúng ta sẽ bắt đầu với một số bài tập kéo giãn, di chuyển mục tiêu trong khoảng từ 0 đến 1.000.000 Tps. Đường màu xanh lam mô tả mục tiêu, đường màu đỏ là Tps đo được. Màu vàng là số lượng phiên bản Redis thực tế trong cụm cho quá trình chạy thử nghiệm kéo dài 2 giờ.
Ngay cả một mô hình đơn giản dựa trên mức trung bình và nội suy tuyến tính cũng đã hoạt động tốt và duy trì Tps gần với mục tiêu.
Tự phục hồi lỗi
Lỗi 1: Để giới thiệu cơ chế khôi phục lỗi được sử dụng bởi tiện ích mở rộng Helix, hãy cùng theo dõi các lỗi quy trình ngẫu nhiên vào máy chủ thử nghiệm của mình trong khi chạy hệ thống ở mục tiêu 1M Tps không đổi. Trong 2 giờ chạy, chúng tôi bắt đầu với 5% lỗi quy trình mỗi phút, sau 40 phút chuyển sang 10% mỗi phút và sau 80 phút chuyển sang tỷ lệ lỗi đáng kể 20% mỗi phút.
Ngay cả trong điều kiện hỏng hóc khắc nghiệt nhất, hệ thống vẫn có thể phục hồi liên tục và quay trở lại mục tiêu Tps.
Lỗi thứ 2: Lúc này các lỗi ngày càng lớn hơn và cuối cùng là một lỗi hệ thống thảm khốc. Lần chạy sau 2 giờ được đặt lại thành mục tiêu 1 triệu Tps. Sau khi chạy ở trạng thái ổn định trong 15 phút sẽ đưa ra các lỗi nút vật lý, làm giảm một phần lớn các quy trình máy chủ và mất một lượng đáng kể tài nguyên cùng một lúc. Các nút được đưa trở lại trực tuyến một phút sau đó và chúng nhất thiết phải đạt được tps mục tiêu, tức là cụm được cung cấp quá mức với biên độ 25%.
Điều này cho thấy khả năng hệ thống tự động loại bỏ các tài nguyên và kết hợp các tài nguyên mới một cách nhanh chóng. Ba lần tăng đột biến đầu tiên xảy ra khoảng 33% trường hợp cùng một lúc, ba lần thứ hai gặp sự cố 66% trường hợp và lần tăng đột biến cuối cùng là lỗi hệ thống hoàn toàn (100%) và yêu cầu khởi động hoàn toàn bộ đệm phân tán.
Mức tăng đột biến 33% thất bại ban đầu không có tác động lâu dài. Sau một phút, hệ thống trở lại hoạt động gần như bình thường, chỉ thêm một hoặc hai trường hợp nữa sau khi các tài nguyên bị lỗi trở lại trực tuyến. 66% lỗi mất nhiều thời gian hơn một chút để phục hồi, khoảng 2 phút, nhưng vẫn không ảnh hưởng lâu dài.
Tuy nhiên, một tác dụng phụ trên mô hình đích có thể được quan sát thấy, cần một thời gian để điều chỉnh các đặc tính quy trình hơi khác và gây ra một số hiện tượng chập chờn. Sự cố hệ thống hoàn chỉnh cuối cùng được xử lý trên cơ sở nỗ lực cao nhất. Quay lại 1 triệu Tps mất khoảng 5 phút: tài nguyên không có sẵn trong phút đầu tiên và hoạt động khởi động gây ra bởi YARN sau khi tài nguyên trở lại sẽ bị ảnh hưởng. Ngoài ra, mô hình mục tiêu cần một thời gian để điều chỉnh. Tuy nhiên, hệ thống được phục hồi hoàn toàn và tự động.
Tất nhiên, tự động mở rộng quy mô và thời gian khôi phục phụ thuộc nhiều vào khối lượng công việc cần thiết để khởi động một quy trình riêng lẻ.
Kết luận
Trên đây là những giải đáp về tự động mở rộng quy mô với Apache Helix và Apache Hadoop YARN. Nếu như có bất kỳ thắc mắc bạn hãy liên hệ ngay với chúng tôi để được giải đáp ngay nhé. Hãy theo dõi chúng tôi để cập nhật tin tức mới nhất mỗi ngày.
Bizfly Cloud hiện đang là nhà cung cấp các dịch vụ máy chủ đám mây tốt nhất Việt Nam. Hiện nay có rất nhiều doanh nghiệp lớn đang sử dụng dịch vụ máy chủ đám mây của chúng tôi như: Vingroup, VTV, Thu Cúc, Ahamove, VNtrip, Sapo, SSI... Quý khách hàng quan tâm hãy liên hệ ngay với công ty để nhận được hỗ trợ và tư vấn sớm nhất nhé. Cảm ơn bạn đã theo dõi bài viết.
