Scaling LinkedIn's Hadoop YARN cluster beyond 10,000 nodes

LinkedIn · 2021 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Cụm Hadoop gấp đôi mỗi năm; cụm lớn nhất khoảng 10.000 node năm 2021. HDFS (một NameNode giữ mọi metadata) chạm giới hạn trước nên được đầu tư từ 2016; YARN ResourceManager nhẹ hơn nên được để yên tới đầu 2019.
• Sự cố gộp cụm (2019): để tận dụng compute nhàn rỗi, compute của cụm phụ (dùng cho làm mờ dữ liệu) được gộp vào cụm chính thành một partition riêng (khoảng 4.000 + 2.000 node). Hai tháng sau, job chờ hàng giờ mới được cấp dù cụm còn nhiều tài nguyên; tốc độ cấp container có lúc rơi từ khoảng 600 xuống 50/giây trong nhiều giờ.

Thay đổi chính

• Bỏ khoá thừa: thao tác đắt (DNS) nằm trong khối synchronized; đưa ra ngoài được khoảng 10%.
• Định nghĩa lại công bằng: Capacity Scheduler ưu tiên queue dùng ít nhất; queue job ngắn churn nhanh (MapReduce của partition phụ) luôn trông "ít dùng" nên giữ scheduler, queue job Spark dài chờ hàng giờ. Vá tạm: chọn queue ngẫu nhiên đều, đóng góp upstream (YARN-9770).
• Nguyên nhân gốc: khi một node heartbeat, scheduler vẫn thử khớp các ứng dụng xin partition kia với node đó dù chắc chắn thất bại. Sửa để chỉ xét ứng dụng cùng partition với node; trường hợp xấu nhất nhanh 9 lần (YARN-9730).
• Đo và báo: ứng dụng đang chờ, throughput cấp container (thấp kéo dài 30 phút là dấu hiệu, nhưng phải phân biệt với cụm đầy), tốc độ xử lý heartbeat (từng bắt được một tính năng serialize thừa trạng thái container).
• DynoYARN: giả lập cụm YARN cỡ tuỳ ý bên trong YARN (30 NodeManager giả trong một container 50 GB; cụm 1.200 node chỉ cần 8 máy) và phát lại audit log production, có thể nhân workload 1,5–2 lần. Kết quả: mục tiêu p95 chờ dưới 10 phút giữ được tới khoảng 11.000 node, 12.000 node thì gần 20 phút; từ tốc độ tăng gấp đôi suy ra còn bao lâu. Mở mã nguồn.
• Không dùng YARN Federation: control plane là CLI làm tay, thêm phụ thuộc (MySQL, ZooKeeper) và nhiều tính năng chưa từng chạy. Global Scheduling đa luồng không cải thiện trong mô phỏng.
• Robin: chia thành các sub-cluster khoảng 5.000 node; mỗi job nằm trọn trong một sub-cluster. Robin là "load balancer cho YARN" với REST API trả về cụm cho mỗi job; Azkaban hỏi Robin trước khi submit nên người dùng vẫn thấy một cụm logic. Robin stateless, chạy trên Kubernetes, quyết định theo snapshot tài nguyên định kỳ. Chính sách thắng trong mô phỏng: cụm có nhiều tài nguyên tuyệt đối nhất. Hai sub-cluster YARN dùng chung một HDFS; chia máy mỗi rack đều cho hai bên (rack-striping) để giữ data locality.

Vì sao

• Scheduler đơn luồng có trần cứng; tối ưu chỉ đẩy trần lên ít so với tốc độ tăng gấp đôi, nên phải scale ngang bằng cách chia cụm.

Bài học cho SWE

• Gộp hai cụm có workload khác hẳn có thể làm lộ giả định công bằng của scheduler.
• Dựng công cụ mô phỏng bằng workload thật để biết còn bao lâu trước khi chạm trần, thay vì đợi người dùng báo chậm.
• Nếu đơn vị việc (job) nằm gọn trong một cụm con, một lớp định tuyến đơn giản rẻ hơn federation đầy đủ.

Liên quan

• LinkedIn 2018 (cùng ý tưởng cho HDFS) · LinkedIn 2021 · LinkedIn 2019
• Load test và kiểm chứng capacity · Multi-tenancy và cô lập tenant