1. Mở rộng cụm Database (Scale-out) bằng cách thêm Node TServer
Mục tiêu của bước này là tăng dung lượng lưu trữ và thông lượng xử lý của cụm YugabyteDB bằng cách thêm các node mới vào nhóm tserver. Khi thêm node, hệ thống sẽ tự động kích hoạt quá trình phân phối lại dữ liệu (rebalancing) để cân bằng tải.
1.1. Chuẩn bị giá trị Replica mới
Trước khi triển khai, bạn cần xác định số lượng node mới sẽ thêm vào. Giả sử hiện tại bạn có 3 node và muốn mở rộng lên 6 node (thêm 3 node nữa). Bạn sẽ sử dụng Helm upgrade để điều chỉnh giá trị replicaCount trong chart YugabyteDB.
Thực hiện lệnh upgrade Helm để tăng số lượng replica của tserver lên 6:
helm upgrade yugabyte yugabyte/yugabyte-db \
--namespace yugabyte \
--set tserver.replicaCount=6 \
--set tserver.resources.requests.memory=2Gi \
--set tserver.resources.limits.memory=4Gi \
--set tserver.resources.requests.cpu=2 \
--set tserver.resources.limits.cpu=4 \
--set tserver.storageClass=standard
Kết quả mong đợi: Helm sẽ báo "Release 'yugabyte' has been upgraded." và Kubernetes sẽ tạo ra 3 pod tserver mới. Các pod này sẽ chuyển sang trạng thái Running sau khi khởi động xong.
1.2. Kiểm tra trạng thái cụm sau khi mở rộng
Sau khi các pod mới sẵn sàng, bạn cần xác nhận rằng YugabyteDB đã nhận diện các node mới và bắt đầu quá trình phân phối lại dữ liệu.
Chạy lệnh sau để liệt kê các node trong cụm:
yb-admin list_nodes --master_addresses=tserver-0.yugabyte:7100
Kết quả mong đợi: Danh sách trả về sẽ hiển thị 6 node (3 node cũ + 3 node mới). Trạng thái của các node mới sẽ là UNREACHABLE ban đầu rồi chuyển sang LIVE. Bạn sẽ thấy thông báo về việc tablet đang được di chuyển (rebalancing).
2. Điều chỉnh Replication Factor cho Keyspace quan trọng
Replication Factor (RF) quyết định số lượng bản sao dữ liệu được lưu trữ trên các node khác nhau. Tăng RF giúp tăng tính sẵn sàng (availability) và khả năng chịu lỗi, nhưng sẽ tốn thêm dung lượng và ảnh hưởng đến độ trễ ghi (write latency).
2.1. Tăng Replication Factor cho Keyspace YSQL
Giả sử bạn có một keyspace quan trọng tên là production_db đang có RF=3 và bạn muốn tăng lên RF=5 để chịu được lỗi mất 2 node cùng lúc.
Truy cập vào shell của master node để thực thi lệnh điều chỉnh:
kubectl exec -it yugabyte-tserver-0 -- /opt/yugabyte/bin/yb_admin --master_addresses=tserver-0.yugabyte:7100
Trong shell của yb_admin, thực hiện lệnh thay đổi RF:
modify_keyspace production_db --placement "1,1,1" --num_replicas 5
Kết quả mong đợi: Hệ thống sẽ xác nhận thay đổi và bắt đầu tạo thêm các bản sao (tablet replicas) mới trên các node khác trong cụm. Quá trình này có thể mất vài phút tùy thuộc vào lượng dữ liệu.
2.2. Xác minh Replication Factor mới
Để kiểm tra xem RF đã được áp dụng thành công hay chưa, bạn sử dụng lệnh describe keyspace.
describe_keyspace production_db
Kết quả mong đợi: Trong phần thông tin trả về, dòng num_replicas sẽ hiển thị giá trị là 5. Bạn cũng có thể thấy danh sách các tablet thuộc keyspace này đang ở trạng thái ONLINE.
3. Thu hẹp cụm Database (Scale-in) và phân phối lại dữ liệu
Scale-in là quá trình giảm số lượng node để tiết kiệm chi phí tài nguyên. YugabyteDB sẽ tự động di chuyển các tablet từ node bị loại bỏ sang các node còn lại trước khi node đó bị xóa.
3.1. Thực hiện thu hẹp cụm bằng Helm
Giả sử bạn muốn giảm số lượng node từ 6 về 3. Bạn thực hiện lệnh upgrade Helm với giá trị replicaCount thấp hơn.
helm upgrade yugabyte yugabyte/yugabyte-db \
--namespace yugabyte \
--set tserver.replicaCount=3
Kết quả mong đợi: Kubernetes sẽ loại bỏ 3 pod tserver dư thừa (thường là các pod có chỉ số cao nhất, ví dụ tserver-3, tserver-4, tserver-5). YugabyteDB Master sẽ phát hiện sự kiện node rời đi và tự động kích hoạt quá trình di chuyển tablet.
3.2. Theo dõi quá trình di chuyển dữ liệu (Rebalancing)
Khi scale-in, dữ liệu trên các node bị xóa phải được di chuyển sang các node còn lại. Nếu quá trình này chưa hoàn tất, các node cũ sẽ không được xóa hoàn toàn (pending termination).
Sử dụng lệnh sau để xem trạng thái của các tablet đang được di chuyển:
yb-admin list_tablets --tablet_server_addresses=tserver-0.yugabyte:7100,tserver-1.yugabyte:7100,tserver-2.yugabyte:7100
Kết quả mong đợi: Bạn sẽ thấy trạng thái của các tablet thay đổi từ REPLICATING sang ONLINE trên các node còn lại. Khi tất cả tablet đã được phân bổ đều trên 3 node, quá trình scale-in sẽ hoàn tất.
4. Giám sát quá trình Rebalancing dữ liệu
Việc giám sát quá trình rebalancing là cực kỳ quan trọng để đảm bảo hiệu năng hệ thống không bị ảnh hưởng quá mức trong khi dữ liệu đang được di chuyển.
4.1. Sử dụng YB-Monitor Dashboard
YugabyteDB cung cấp giao diện web YB-Monitor để trực quan hóa quá trình này. Bạn cần mở port của master node để truy cập.
Port-forward dịch vụ master node (thường là port 7000 cho giao diện web):
kubectl port-forward svc/yugabyte-tserver 7000:7000 -n yugabyte
Truy cập http://localhost:7000 trên trình duyệt. Chuyển sang tab Cluster hoặc Operations.
Kết quả mong đợi: Bạn sẽ thấy biểu đồ hoặc thanh tiến trình hiển thị Rebalancing đang diễn ra. Các chỉ số Tablets being moved sẽ giảm dần về 0 khi quá trình hoàn tất.
4.2. Kiểm tra qua Command Line (CLI)
Để giám sát chi tiết hơn qua CLI, bạn sử dụng lệnh get_tablet_stats để xem số lượng tablet trên mỗi node.
yb-admin get_tablet_stats --master_addresses=tserver-0.yugabyte:7100
Kết quả mong đợi: Bạn sẽ thấy danh sách các node và số lượng tablet trên mỗi node. Khi rebalancing hoàn tất, số lượng tablet trên các node còn lại sẽ xấp xỉ bằng nhau (ví dụ: mỗi node có khoảng 1/3 tổng số tablet).
5. Chiến lược Scaling cho Workload Đọc vs Ghi
Việc mở rộng hệ thống cần dựa trên đặc thù của workload. YugabyteDB cho phép tách biệt quy mô cho Read (Read-only) và Write (Read-Write).
5.1. Chiến lược cho Workload Ghi nhiều (Write-Heavy)
Đối với workload ghi nhiều, nút thắt cổ chai thường là I/O disk và mạng. Chiến lược scaling là:
- Tăng số lượng node tserver (scale-out) để tăng tổng dung lượng disk và băng thông mạng.
- Giữ Replication Factor ở mức tối thiểu cần thiết (ví dụ RF=3) để giảm chi phí ghi (vì mỗi lệnh ghi phải được ghi lên 3 node).
- Sử dụng loại ổ cứng NVMe SSD cho tất cả node.
Cấu hình Helm gợi ý cho write-heavy:
helm upgrade yugabyte yugabyte/yugabyte-db \
--namespace yugabyte \
--set tserver.replicaCount=9 \
--set tserver.storageClass=fast-ssd \
--set tserver.resources.requests.cpu=4 \
--set tserver.resources.limits.cpu=8
Kết quả mong đợi: Thông lượng ghi (write throughput) tăng lên tuyến tính gần như số lượng node mới thêm vào.
5.2. Chiến lược cho Workload Đọc nhiều (Read-Heavy)
Đối với workload đọc nhiều, bạn có thể tận dụng các node chỉ đọc (Read-only nodes) hoặc tăng Replication Factor để có nhiều bản sao dữ liệu hơn để phục vụ đọc.
- Tăng Replication Factor (ví dụ từ 3 lên 5) để tăng số lượng node có thể phục vụ đọc (YugabyteDB có thể đọc từ bất kỳ replica nào).
- Thêm các node tserver mới và cấu hình chúng chỉ nhận các replica đọc (nếu cần tối ưu hóa chi phí).
- Cấu hình Read Quorum thấp hơn (ví dụ RQ=1) nếu chấp nhận độ trễ nhất quán (consistency) thấp hơn để tăng tốc độ đọc.
Cấu hình tăng RF cho read-heavy (giả sử keyspace tên analytics_db):
kubectl exec -it yugabyte-tserver-0 -- /opt/yugabyte/bin/yb_admin --master_addresses=tserver-0.yugabyte:7100
modify_keyspace analytics_db --placement "1,1,1" --num_replicas 5
Kết quả mong đợi: Số lượng replica cho mỗi tablet tăng lên, cho phép phân tán tải đọc trên nhiều node hơn. Độ trễ đọc trung bình sẽ giảm do xác suất chọn được node gần nhất hoặc ít tải nhất tăng lên.
5.3. Xác minh hiệu năng sau khi điều chỉnh chiến lược
Sử dụng công cụ benchmark đi kèm YugabyteDB (như yb_bench) để đo lường hiệu năng trước và sau khi scaling.
kubectl exec -it yugabyte-tserver-0 -- /opt/yugabyte/bin/yb_bench --num_ops=100000 --num_clients=10 --num_threads=4 --num_tables=10 --table_size=100000 --num_key_value_pairs=1000 --key_size=10 --value_size=1000 --num_key_value_pairs=1000 --num_key_value_pairs=1000 --key_size=10 --value_size=1000
Kết quả mong đợi: Báo cáo benchmark sẽ hiển thị throughput (lần/giây) và latency (ms). Đối với write-heavy, throughput ghi phải tăng. Đối với read-heavy, latency đọc phải giảm hoặc throughput đọc tăng đáng kể.
Điều hướng series:
Mục lục: Series: Xây dựng hệ thống Database phân tán với YugabyteDB và Kubernetes
« Phần 4: Kết nối ứng dụng và thực thi truy vấn YSQL/YCQL
Phần 6: Cấu hình sao lưu và phục hồi (Backup & Restore) »