Elasticsearch Bài học 44: Split-brain Problem - Cấu hình Master Node để không vỡ Cluster

Trong một hệ thống phân tán, nỗi sợ lớn nhất không phải là một Node bị cháy ổ cứng (vì đã có Replica lo), mà là sự cố mạng (Network Partition).

Hãy tưởng tượng bạn đang triển khai cụm Elasticsearch cho hệ thống AFC Metro gồm 2 Data Center (DC): DC A ở Bến Thành và DC B ở Suối Tiên. Đường truyền cáp quang giữa 2 DC đột ngột bị đứt. Lúc này, các Node ở Bến Thành không nhìn thấy các Node ở Suối Tiên và ngược lại.

Nếu không được cấu hình đúng, cả 2 bên sẽ tự bầu ra một Master Node mới và tự hoạt động độc lập. Một cụm ban đầu bị xé toạc làm hai cụm riêng biệt. Mọi luồng ghi từ API quẹt thẻ sẽ bị ghi đè loạn xạ lên 2 cụm này. Khi đường truyền mạng được nối lại, 2 cụm sẽ va vào nhau và không có cách nào ghép nối lại dữ liệu bị xung đột.

Đó chính là thảm họa kinh hoàng mang tên Split-brain (Hội chứng não chia cắt).

1. Cơ chế phòng thủ "Quorum" (Đa số quá bán)

Để chống lại Split-brain, các hệ thống phân tán (bao gồm cả Elasticsearch, Kafka, Zookeeper) đều sử dụng một nguyên lý chung: Bầu cử theo cơ chế Quorum (Đa số quá bán).

Công thức của Quorum là:

Quorum = (Tổng số Master-eligible Nodes / 2) + 1 (Làm tròn xuống)

• Tại sao phải là đa số quá bán?

  Nếu cụm của bạn có 3 Master-eligible Node (Node có quyền ứng cử Master), Quorum sẽ là (3 / 2) + 1 = 2.

  Nếu mạng bị đứt làm đôi (1 bên có 2 Node, 1 bên có 1 Node), bên có 2 Node sẽ đủ phiếu (Quorum = 2) để bầu ra Master và tiếp tục hoạt động. Bên có 1 Node sẽ không đủ phiếu, nó sẽ tự phế truất, ngừng nhận request ghi để bảo vệ tính toàn vẹn dữ liệu (Data Consistency).

• Tại sao KHÔNG BAO GIỜ thiết kế cụm có 2 Master Node?

  Nếu cụm có 2 Node, Quorum = (2/2) + 1 = 2.

  Chỉ cần 1 Node chết hoặc đứt cáp, Node còn lại chỉ có 1 phiếu (không đạt Quorum = 2). Toàn bộ cụm sẽ "đóng băng" (không thể bầu Master, không thể ghi dữ liệu). Có 2 Node lại dễ sập hơn có 1 Node!

  $\rightarrow$ Quy tắc vàng: Tổng số Master-eligible Nodes luôn luôn phải là Số lẻ (3, 5, 7).

2. Elasticsearch 7.x và 8.x giải quyết Split-brain như thế nào?

Nếu bạn từng làm việc với Elasticsearch 6.x trở về trước, bạn sẽ phải tự cấu hình tay tham số discovery.zen.minimum_master_nodes. Nếu cấu hình sai tay, cụm sẽ vỡ nát.

Tuy nhiên, từ Elasticsearch 7.x trở đi (và cả bản 8.x hiện tại), tính năng này đã bị khai tử. Elasticsearch giới thiệu một kiến trúc mới Tự động hoàn toàn (Auto-bootstrapping & Voting Configuration).

Quá trình khởi tạo an toàn diễn ra như sau:

Khi bạn dựng một cụm mới hoàn toàn, bạn KHÔNG cần tự tính Quorum. Bạn chỉ cần khai báo danh sách các Node có quyền làm Master trong file elasticsearch.yml ở tham số cluster.initial_master_nodes:

YAML

# Cấu hình trên Node 1
node.name: master-node-1
cluster.initial_master_nodes: ["master-node-1", "master-node-2", "master-node-3"]

Khi bạn bật 3 Node này lên lần đầu tiên, chúng sẽ nhìn vào mảng initial_master_nodes này, tự động "kết nghĩa vườn đào", khóa chặt danh sách cử tri lại và tự động tính toán Quorum là 2.

Sự kỳ diệu của Auto-scaling:

Sau khi cụm đã hình thành, nếu bạn gắn thêm Node số 4 và số 5 vào cụm (để Scale up), Elasticsearch sẽ tự động cập nhật cấu hình Voting (Danh sách cử tri) ở background và nâng Quorum lên thành 3. Bạn tuyệt đối không bao giờ phải lo lắng về việc tính toán lại Quorum khi thêm/bớt Node nữa. Dấu chấm hết cho thảm họa Split-brain do cấu hình sai.

3. Dedicated Master Nodes (Thiết kế phần cứng cho Production)

Trở lại với Bài 42 (Data Tiers), khi hệ thống E-commerce hay AFC của bạn lớn lên, việc bắt một Node vừa làm "Công nhân bốc vác" (Data Node) vừa làm "Quản đốc" (Master Node) là cực kỳ nguy hiểm.

Khi Data Node bị quá tải do một truy vấn Deep Paging hoặc Aggregations khổng lồ, RAM của nó sẽ cạn kiệt, CPU chạy 100%. Lúc này, tiến trình Java sẽ bị "Garbage Collection" (Dọn rác) đóng băng (Stop-The-World) mất vài giây. Vì Node này đang kiêm luôn vai trò Master, việc nó bị đóng băng vài giây khiến các Node khác tưởng nó đã "chết". Chúng lập tức tổ chức bầu cử Master mới, gây ra sự xáo trộn toàn bộ Cluster và rớt request API.

Best Practice (Thiết kế Dedicated Master): Hãy tách biệt hoàn toàn não bộ và cơ bắp.

• Tạo đúng 3 server nhỏ (Ví dụ: 2 Core CPU, 4GB RAM, ổ cứng HDD nhỏ xíu) chỉ để làm Master Node.

• Khai báo trong elasticsearch.yml của 3 con này:

  YAML

  node.roles: [ master ] # Tuyệt đối không có "data"
  
  

• Các server bự (16 Core, 64GB RAM, SSD) sẽ chỉ đóng vai trò Data Node:

  YAML

  node.roles: [ data ]
  
  

Nhờ thiết kế này, cho dù Data Node có cày cuốc đến cháy máy, 3 Dedicated Master Node vẫn ung dung đứng ngoài, nhẹ nhàng giám sát trạng thái cụm. Cluster của bạn sẽ trở nên vững như bàn thạch.

Như vậy, bạn đã có một Cluster an toàn trước lỗi con người (nhờ Snapshot - Bài 43) và an toàn trước lỗi phần cứng mạng (nhờ Quorum Master - Bài 44). Nhưng để tốc độ xử lý đạt đỉnh, việc tối ưu không chỉ nằm ở kiến trúc, mà còn nằm ở cách tinh chỉnh cấu hình của chính cỗ máy ghi/đọc.