Deployment of etcd on AWS EC2
Bài tóm tắt etcd 2017 3. Quy mô lớn Độ khó: Trung bình
etcd · 2017 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Hướng dẫn thiết kế (không phải câu chuyện một công ty), chuyển từ tài liệu cũ của etcd. Giá trị nằm ở các đánh đổi cho một kho đồng thuận mạnh trên cloud; nhận định ghi "theo etcd".
Bối cảnh
- etcd là kho key-value nhất quán mạnh, replicate đồng bộ bằng Raft; là nền cho control plane Kubernetes, lock phân tán, config, secret.
- Vì mọi ghi phải qua quorum, thêm node làm etcd chậm đi (leader phải phối hợp với nhiều thành viên hơn). Cách trực tiếp để nhanh hơn là cho mỗi thành viên nhiều disk I/O, mạng, CPU, RAM hơn, tức là scale dọc.
Thay đổi chính (các đánh đổi theo etcd)
- Không dùng Auto Scaling Group (ASG) để scale số node: hiệu năng tỉ lệ nghịch với số thành viên, và thêm/bớt thành viên phải sửa runtime configuration qua lifecycle hook, phức tạp. Nhưng dùng ASG để giữ số node cố định thì tốt: rải máy qua AZ, thay máy hỏng, tự chữa lành.
- Topology: tối thiểu 3 thành viên trên ít nhất 2 AZ để được coi là HA ở mức region. Latency thêm vì trải AZ thường không đáng kể. Nhưng nếu ứng dụng dùng etcd chỉ chạy ở một AZ thì trải etcd qua AZ có thể không có nghĩa. Placement group (chung một AZ) giảm latency mạng nhưng chịu lỗi kém hơn.
- Độ bền khi mất thành viên: ba lớp: replication (mọi dữ liệu ở mọi thành viên; càng nhiều miền lỗi độc lập càng khó mất hẳn); snapshot của etcd v3 đủ rẻ (vài phút) để chạy thường xuyên và đẩy lên S3; EBS là block device qua mạng, vòng đời tách khỏi máy EC2, tách ra và snapshot độc lập được, nên một etcd một node trên EBS đã có độ bền khá.
- Đĩa: EBS hay instance store: EBS latency cao hơn, throughput thấp hơn, dao động hơn instance store (gắn thẳng vào host). Ưu tiên hiệu năng hơn an toàn dữ liệu thì dùng instance store (dữ liệu mất theo máy). EBS dao động có thể làm cụm etcd mất ổn định; Provisioned IOPS ổn định hơn general purpose SSD.
- Bước tiếp: etcd-operator trên Kubernetes (backup định kỳ lên S3, thay node hỏng, khôi phục từ backup khi mất quorum vĩnh viễn).
Bài học cho SWE
- Hệ đồng thuận mạnh không scale ngang để nhanh hơn: thêm node là thêm độ bền và chịu lỗi, đổi lại ghi chậm hơn. Muốn nhanh thì máy mạnh hơn hoặc chia dữ liệu (Failover, replica và dự phòng dữ liệu).
- Autoscaling dùng để giữ số lượng (tự chữa lành), không phải để co giãn, với hệ có thành viên cố định.
- Đĩa qua mạng (EBS) đổi hiệu năng lấy vòng đời tách khỏi máy: máy chết dữ liệu còn; đĩa gắn liền (instance store) nhanh hơn nhưng mất theo máy (Tách compute khỏi storage).
- HA của một thành phần chỉ có nghĩa khi đi cùng HA của thứ dùng nó: không cần etcd đa AZ cho ứng dụng một AZ (Độ tin cậy và multi-region).
- Replication không thay được snapshot: snapshot đẩy ra ngoài (S3) là đường lui khi mất quorum.
Liên quan
#etcd#Raft#AWS#EC2#EBS#Instance store#Auto Scaling Group#Availability Zone#Snapshot#Quorum#Capacity planning
Được nhắc tới trong
Công ty (1)