Kiến trúc Cassandra

KIẾN TRÚC CASSANDRA

Hệ thống Cassandra là hệ thống gồm một hoặc nhiều node độc lập kết hợp với nhau tạo thành một cluster. Trong một cluster, tất cả các node đều ngang hàng với nhau, có vai trò như nhau, độc lập và kết nối với toàn bộ các node còn lại. Mặt khác, mỗi node trong cluster đều có quyền chấp nhận các request đọc / ghi, bất kể dữ liệu nằm ở đâu trong cluster.

1. Kết nối giữa các node

a. Giao thức Gossip

Cassandra sử dụng một giao thức gọi là gossip để tìm ra thông tin về trạng thái và vị trí của những node thành viên trong cluster. Gossip là một giao thức giao tiếp ngang hàng (peer to peer). Mỗi node định kì sẽ trao đổi thông tin của chính nó cho những node khác trong cluster và ngược lại.

Trong Cassandra, gossip chạy mỗi giây và trao đổi thông điệp trạng thái với 3 node khác trong cluster. Thông tin trao đổi bao gồm thông tin về chính nó và về những node khác mà chúng đã gossip. Nhờ đó, mỗi node sẽ nhanh chóng biết về tất cả các node còn lại. Thông điệp gossip có một thông số version kết hợp với nó để trong suốt quá trình trao đổi gossip, những thông tin cũ sẽ được thay thế cập nhật bởi những thông tin mới hơn.

b. Cluster membership và seed nodes

Khi một node được khởi động, nó sẽ xem file cấu hình cassandra.yaml để xác định tên cluster chứa nó và các nút khác trong cluster được cấu hình trong file, được biết với tên là seed node.

Để ngăn chặn sự đứt đoạn trong truyền thông gossip, tất cả các node trong cluster phải có cùng một danh sách các seed node được liệt kê trong file cấu hình. Mặc định, một node sẽ phải nhớ tất cả những node mà nó đã từng gossip kể cả khi khởi động lại. Seed node sẽ không có mục đích nào khác ngoài việc cập nhật một node mới khi nó tham gia vào cluster. Tức là khi một node mới tham gia vào cluster, nó sẽ liên lạc với các seed node để cập nhật trạng thái của tất cả các node khác trong cluster.

Failure Detection là phương pháp mỗi node xác định các node khác trong hệ thống có đang hoạt động hay không. Thông tin của Failure Detection được dùng để tránh định tuyến những yêu cầu của người dùng đến những node không còn hoạt động hay những node vẫn đang hoạt động nhưng có hiệu suất thấp.

c. Failure Detection

Quá trình gossip sẽ theo dõi hoạt động của các node từ một node dưới dạng trực tiếp (các node trực tiếp gossip) hoặc gián tiếp (thông qua node gossip trung gian). Cassandra có một tham số điều chỉnh độ nhạy cho Failure detection là phi_convict_threshold (được cấu hình trong file cassandra.yaml); đồng thời Cassandra có một cơ chế tính toán ngưỡng phi cho mỗi node. Nếu phi nhỏ hơn phi_convict_threshold thì node đó còn sống, ngược lại thì đã bị lỗi.

Khi một node bị lỗi, nó sẽ không được tự động xóa khỏi cluster. Các node khác trong cluster vẫn thực hiện gossip định kỳ với node bị hỏng để xác định nó được khôi phục hay chưa. Để quản lý (thêm, bớt) node trong cluster, cần sử dụng công cụ nodetool.

2. Phân vùng dữ liệu


Trong Cassandra, dữ liệu được quản lý bởi cluster được hình dung như một vòng tròn. Vòng tròn này được chia thành các khoảng bằng nhau dựa trên số lượng node có trong cluster. Mỗi node được gán một token trước khi đưa vào cluster, token này dùng để xác định vị trí của node trong vòng và vùng dữ liệu mà nó chịu trách nhiệm quản lý.

Dữ liệu sẽ được phân vùng dựa trên khóa hàng (row key). Ví dụ như trong hình bên dưới, giả sử ta có một cluster đơn giản gồm 4 node, row key được đánh số từ 0 – 100. Mỗi node được gán một token lần lượt là 0, 25, 50, 75. Node đầu tiên có token là 0 chịu trách nhiệm quản lý vùng dữ liệu Data range 4 (76+ wapping range).

Có 2 loại phân vùng dữ liệu: Random partitioner và Byte Ordered partitioner.

Random Partitioner - Phân vùng ngẫu nhiên: là phân vùng mặc định cho cassandra cluster, các nhà phát triển cassandra khuyến cáo nên lựa chọn cách phân vùng này. Phân vùng ngẫu nhiên sử dụng các hàm băm phù hợp để xem node nào sẽ lưu trữ row nào. Random Partitioner sử dụng thuật toán MD5 để băm dữ liệu, các rowkey sau khi bị băm sẽ có các giá trị nằm trong khoảng từ 0 đến  – 1. Khoảng giá trị của token thường được tính bằng phạm vi băm chia cho số lượng node.

Byte ordered partitioner: đây là partitioner được Cassandra support sớm nhất. Theo phương pháp này khóa được lưu trữ theo thứ tự các raw byte thay vì chuyển đổi chúng sang các chuỗi mã hóa. Token được tính dựa vào các giá trị thực tế của dữ liệu, sử dụng hệ thập lục phân cho các ký tự đầu trong khóa. Ưu điểm của phương pháp này là khi đã biết được cấu trúc dữ liệu, ta có thể tìm kiếm dữ liệu rất nhanh. Nhược điểm của phương pháp này chính là khi dữ liệu trên một khoảng nào đó quá lớn, một vài node sẽ phải quản lý nhiều dữ liệu trong khi các node khác lại không thể hiện được vài trò của nó trên hệ thống do quản lý ít dữ liệu. Đây gọi là hiện thượng mất cân bằng (not balancing).

3. Snitches

Snitch là một thành phần có thể cấu hình của Cassandra dùng để định nghĩa cách mà những node được nhóm với nhau trong toàn cấu trúc mạng (thuộc về data center nào / rack nào). Cassandra sẽ dùng thông tin này để định tuyến giữa các node trong cluster sao cho hiệu quả nhất, hay phân bố bản sao dữ liệu sao cho phù hợp (mỗi rack đều cần có ít nhất một bản sao dữ liệu).

Snitch được cấu hình trong tệp cassandra.yaml. Tất cả các node trong cluster nên dùng cùng một cấu hình snitch. Có nhiều loại snitch khác nhau: SimpleSnitch, DseSimpleSnitch, RackInferringSnitch, PropertyFileSnitch, EC2Snitch, EC2MultiRegionSnitch. Khi gán token, các node thuộc các rack khác nhau sẽ được đặt luân phiên. Ví dụ: rack1, rack2, rack3, rack1, rack2, rack3…

4. Nhân bản dữ liệu (Data replication)

Nhân bản là quá trình lưu trữ các bản sao của dữ liệu trên nhiều nút để đảm bảo độ tin cậy và khả năng chịu lỗi. Khi bạn tạo một keyspace (không gian khóa) trong Cassandra, bạn phải có chính sách quyết định vị trí các bản sao: số lượng bản sao và cách những bản sao được phân phối trên các node trong cluster.

Tổng số bản sao của dữ liệu trên cluster được gọi là Replication factor (RF). Nếu gía trị replication factor là 1 - nghĩa là chỉ có một bản sao của mỗi hàng trên một node; nếu replication factor là 2 - nghĩa là có hai bản sao của mỗi hàng, mỗi bản nằm trên mỗi node khác nhau. Tất cả các bản sao có mức độ quan trọng ngang nhau, tất nhiên số replication factor không được vượt quá tổng số node trong cluster.

Giả sử RF = 2. Khi đó có 2 bản sao được ghi vào 2 node khác nhau. Giả sử một node trong đó bị lỗi, việc ghi dữ liệu cho node đó được giấu đi bằng cách nào đó và sẽ được ghi lại khi node đó được sửa chữa, trừ khi nó bị lỗi đủ lâu thì Cassandra sẽ hủy tác vụ.

Có hai chiến lược nhân bản dữ liệu là: Simple strategy và Network topology strategy.

a. Simple strategy

Simple strategy được đặt làm mặc định khi tạo keyspace trong CLI (Command Line Interface) và phải khai báo tường minh trong CQL (Cassandra Query Laguage). Simple strategy đặt bản sao đầu tiên lên node được quyết định bởi partitioner. Bản sao tiếp theo được đặt ở node tiếp theo theo chiều kim đồng hồ mà không cần phải phải xem xét nó thuộc vị trí nào trong cluster.

b. Network topology strategy

Áp dụng cho dữ liệu phân bố ở nhiều Data center và biết được sơ đồ mạng. Do các node ở cùng một rack có nguy cơ cùng hỏng cao nên quy tắc chạy vòng theo chiều kim đồng hồ sẽ ưu tiên lựa chọn node sao lưu tiếp theo khác rack với node sao lưu trước nó.

5. Client request

Tất cả node trong Cassandra là ngang hàng. Một yêu cầu đọc / ghi của client có thể request đến bất cứ node nào trong cluster. Khi một client kết nối tới node và đưa cho một yêu cầu đọc / ghi, node đó đóng vai trò như một điều phối viên (coordinator) đến các node còn lại. Client gửi yêu cầu đến coordinator và coordinator quyết định node nào trong ring nên nhận yêu cầu dựa vào cấu hình partitioner và replica placement strategy.

a. Yêu cầu ghi dữ liệu




Với yêu cầu ghi dữ liệu, coordinator sẽ gửi dữ liệu đến tất cả các node chứa row được ghi. Miễn là tất cả các node chứa bản sao đang hoạt động và sẵn sàng, chúng sẽ nhận tác vụ ghi bất kể thông số consistent level của client là gì đi chăng nữa. Consistent level chỉ quyết định có bao nhiêu node bản sao phải phản hồi để xem như là tác vụ đó thành công hay chưa.

b. Yêu cầu đọc dữ liệu

Với yêu cầu đọc dữ liệu, có hai loại truy vấn đọc dữ liệu mà coordinator có thể gửi: Đọc trực tiếp và đọc sửa chữa (read repair). Số lượng bản sao trong request đọc trực tiếp được quyết định bởi Consistent level bởi client. Những bản sao không nhận được request đọc trực tiếp sẽ nhận được request đọc sửa chữa.

Coordinator gửi request đọc trực tiếp tới các node được quyết định bởi consistent level. Dữ liệu phản hồi từ các node này được so sánh xem chúng có nhất quán với nhau hay không. Nếu không nhất quán thì bản sao có dữ liệu gần đây nhất sẽ được lấy làm kết quả để trả về cho người dùng. Mặt khác, để đảm bảo tất cả bản sao đều có phiên bản dữ liệu gần đây nhất, coordinator cũng gửi các request đọc sửa chữa tới các bản sao khác, sau đó so sánh xem dữ liệu có nhất quán và bị lỗi thời hay không? Nếu có thì sẽ được cập nhật bản ghi gần đây nhất.

Nhận xét

Bài đăng phổ biến từ blog này

Mô hình dữ liệu trong Cassandra

Các loại cấu trúc liên kết mạng (Network Topology)