Cấu hình mạng liên vùng (Cross-Region Networking)
Bước đầu tiên để TiDB hoạt động xuyên vùng là thiết lập kết nối mạng Layer 3 giữa các VPC của các nhà cung cấp đám mây khác nhau. Chúng ta sẽ sử dụng VPC Peering qua AWS Transit Gateway hoặc Azure VNet Peering tùy thuộc vào hạ tầng, ở đây giả định bạn đã có 2 VPC: `vpc-region-a` và `vpc-region-b`.
Mục đích: Đảm bảo các Pod trong Kubernetes cluster ở Region A có thể ping và trao đổi gói tin trực tiếp với Pod ở Region B qua private IP, không đi qua public internet.
Trên máy chủ quản trị (Ubuntu 24.04), bạn cần cập nhật Security Group và Route Table để cho phép lưu lượng từ CIDR của vùng kia. Dưới đây là ví dụ cấu hình cho AWS (tương tự cho GCP/Azure).
Thêm rule cho phép traffic từ VPC Region B vào Region A:
aws ec2 create-vpc-peering-connection --vpc-id vpc-region-a --peer-vpc-id vpc-region-b --region us-east-1 --tags Key=Name,Value=Peering-A-B
Kết quả mong đợi: API trả về trạng thái `pending-acceptance` cho VPC Peering Connection.
Chấp nhận kết nối peering từ phía Region B:
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-1234567890abcdef --region us-west-2
Kết quả mong đợi: Trạng thái chuyển sang `active`.
Cập nhật Route Table của Region A để chuyển hướng traffic của CIDR Region B qua Peering Connection:
aws ec2 create-route --route-table-id rtb-11111111 --destination-cidr-block 10.20.0.0/16 --vpc-peering-connection-id pcx-1234567890abcdef --region us-east-1
Kết quả mong đợi: Route mới được thêm vào bảng định tuyến, cho phép traffic đến 10.20.0.0/16 đi qua peering connection.
Thực hiện tương tự cho Route Table của Region B. Sau khi hoàn tất, test connectivity bằng lệnh ping từ một máy chủ ảo trong Region A đến một máy chủ ảo trong Region B (dùng private IP):
ping 10.20.5.10
Kết quả mong đợi: Thấy phản hồi `64 bytes from 10.20.5.10: icmp_seq=1 ttl=128 time=25 ms`.
Cấu hình Topology-aware Scheduling trong TiDB Operator
Sau khi mạng đã thông, chúng ta cần chỉ dẫn cho TiDB Operator biết cách phân bổ các thành phần TiKV vào các vùng khác nhau dựa trên topology. Điều này giúp TiDB tự động cân bằng dữ liệu và tránh single point of failure.
TiDB Operator sử dụng Kubernetes Taints và Tolerations kết hợp với Labels để thực hiện điều này. Chúng ta sẽ tạo một custom resource `TiDBCluster` với cấu hình `topologyAwareScheduling`.
Trước tiên, gắn Label vào các Node của Kubernetes trong từng Region. Giả sử bạn có 2 Node Pool: `region-a-pool` và `region-b-pool`.
Áp dụng Label cho các Node ở Region A:
kubectl label nodes --all zone=region-a --overwrite
Kết quả mong đợi: Tất cả node trong cluster hiện tại (Region A) được gắn label `zone=region-a`.
Áp dụng Label cho các Node ở Region B (thực hiện trên cluster của Region B hoặc nếu dùng Single Cluster Multi-Region architecture):
kubectl label nodes --all zone=region-b --overwrite
Kết quả mong đợi: Node mới ở Region B có label `zone=region-b`.
Bây giờ, tạo file cấu hình `tidbcluster-cross-region.yaml` để triển khai cluster mới hoặc mở rộng cluster hiện có. File này sẽ được lưu tại `/opt/tidb/config/tidbcluster-cross-region.yaml`.
Đường dẫn đầy đủ: `/opt/tidb/config/tidbcluster-cross-region.yaml`. Nội dung hoàn chỉnh:
apiVersion: pingcap.com/v1alpha1
kind: TiDBCluster
metadata:
name: tidb-cross-region
namespace: tidb
spec:
pd:
replicas: 5
storage: 100Gi
topologyAwareScheduling:
enable: true
labelKey: "zone"
maxReplicas: 2
tikv:
replicas: 9
storage: 200Gi
topologyAwareScheduling:
enable: true
labelKey: "zone"
maxReplicas: 2
nodeSelector:
# Đảm bảo TiKV có thể chạy trên cả 2 vùng
node.kubernetes.io/instance-type: "c5.xlarge"
tidb:
replicas: 2
tls:
enabled: false
cluster:
# Cấu hình mạng để PD có thể liên lạc với TiKV ở vùng khác
crossCluster:
enabled: true
# IP range của region B cần được whitelist trong PD nếu cần
allowlist:
- 10.20.0.0/16
Giải thích: Tham số `topologyAwareScheduling.enable: true` bật tính năng cân bằng topology. `labelKey: "zone"` chỉ định TiDB Operator sẽ dựa vào label `zone` trên Node để phân tán Pod. `maxReplicas: 2` giới hạn tối đa 2 TiKV/PD trong cùng một zone để đảm bảo dữ liệu được phân tán.
Áp dụng cấu hình vào cluster:
kubectl apply -f /opt/tidb/config/tidbcluster-cross-region.yaml
Kết quả mong đợi: Kubernetes tạo các Pod TiKV và PD. Bạn sẽ thấy các Pod mới được schedule vào các Node có label `zone=region-b`.
Verify trạng thái scheduling bằng cách liệt kê các Pod và xem label của Node chúng đang chạy:
kubectl get pods -n tidb -o wide | grep tidb-cross-region
Kết quả mong đợi: Danh sách Pod hiện ra, cột `NODE` sẽ hiển thị tên node của cả Region A và Region B.
Để xác nhận chính xác topology, sử dụng lệnh describe để xem scheduler đã phân bổ như thế nào:
kubectl describe pd tidb-cross-region-pd-0 -n tidb | grep -A 5 "NodeAffinity"
Kết quả mong đợi: Thấy cấu hình NodeAffinity hoặc PreferredSchedulingTerm liên quan đến label `zone`.
Triển khai và cân bằng TiKV sang vùng khác
Sau khi cấu hình Topology-aware, TiDB Operator sẽ tự động kích hoạt cơ chế "Region Replication" để sao chép dữ liệu từ các TiKV cũ (Region A) sang các TiKV mới (Region B) để đảm bảo độ bền (Durability) và khả năng chịu lỗi (Availability).
Bước này bao gồm việc mở rộng số lượng TiKV và quan sát quá trình cân bằng dữ liệu (Balance) qua PD.
Để bắt đầu mở rộng, chúng ta tăng số lượng TiKV trong manifest. Giả sử hiện tại có 3 TiKV ở Region A, chúng ta muốn mở rộng lên 9 TiKV (3 ở A, 6 ở B hoặc phân tán đều).
Chỉnh sửa file cấu hình đã tạo ở bước trước, tăng `replicas` của `tikv` lên 9:
kubectl edit tidbcluster tidb-cross-region -n tidb
Trong trình soạn thảo, tìm dòng `replicas: 9` dưới phần `tikv`. Lưu và thoát.
Kết quả mong đợi: TiDB Operator tạo thêm 6 Pod TiKV mới. Các Pod này sẽ được schedule vào các Node có label `zone=region-b` do cơ chế `topologyAwareScheduling`.
Kiểm tra trạng thái của các Pod mới:
kubectl get pods -n tidb -l app.kubernetes.io/component=tikv -o wide
Kết quả mong đợi: Tổng cộng 9 Pod, trong đó 6 Pod mới có trạng thái `Running` và nằm trên các node của Region B.
Quá trình quan trọng nhất là "Data Balance". PD sẽ tự động di chuyển các Region dữ liệu từ TiKV cũ sang TiKV mới để cân bằng load và đảm bảo replication factor.
Để xem tiến độ cân bằng, sử dụng `tidb-admin` hoặc truy cập Dashboard PD. Dưới đây là lệnh dùng `pd-ctl` để xem trạng thái store:
pd-ctl -u http://tidb-cross-region-pd:2379 store
Kết quả mong đợi: Danh sách các Store. Bạn sẽ thấy các Store mới (từ Region B) có trạng thái `up` và số lượng `region_count` đang tăng dần.
Kiểm tra chi tiết quá trình cân bằng vùng (Region Balance):
pd-ctl -u http://tidb-cross-region-pd:2379 config get region-schedule
Kết quả mong đợi: Thấy thông số `max-merge-region-size` và `split-merge-interval` đang hoạt động. Đặc biệt, nếu bật `enable-cross-region-replication`, bạn sẽ thấy các rule replication liên quan đến zone.
Để xác nhận dữ liệu đã được phân tán đúng theo topology, kiểm tra số lượng Region trên mỗi Store:
pd-ctl -u http://tidb-cross-region-pd:2379 store | grep -E "region_count|store_id"
Kết quả mong đợi: Các Store ở Region A và Region B có số `region_count` tương đối bằng nhau (ví dụ: ~1000 region/store), chứng tỏ dữ liệu đã được cân bằng.
Test khả năng chịu lỗi bằng cách giả lập mất một vùng (tạm thời kill một Pod TiKV ở Region A):
kubectl delete pod tidb-cross-region-tikv-0 -n tidb
Kết quả mong đợi: TiDB vẫn hoạt động bình thường, không bị lỗi connection. PD tự động chuyển hướng read/write sang các replica ở Region B. Khi Pod bị xóa, Kubernetes sẽ tự động tạo lại Pod mới ở Region A (nếu còn slot) hoặc giữ nguyên cấu hình.
Verify lại trạng thái cluster sau sự cố:
kubectl get pods -n tidb -l app.kubernetes.io/component=tikv
Kết quả mong đợi: Pod bị xóa đã được thay thế bằng Pod mới, và trạng thái cluster vẫn là `Running`.
Điều hướng series:
Mục lục: Series: Triển khai Database Multi-Cloud với TiDB và Ubuntu 24.04
« Phần 3: Triển khai TiDB Cluster đầu tiên với cấu hình cơ bản
Phần 5: Cấu hình High Availability và Disaster Recovery cho TiDB Multi-Cloud »