High-availability MongoDB

High-availability MongoDB

Introduction

Tính sẵn sàng cao (HA) đề cập đến việc cải thiện tính khả dụng của hệ thống và ứng dụng bằng cách giảm thiểu thời gian chết do các hoạt động bảo trì thường xuyên (theo kế hoạch) và sự cố hệ thống đột ngột (không có kế hoạch).

Bài đăng này nói rộng rãi về Giải pháp cụm khả dụng cao cùng với một số Cấu hình cụm khả dụng cao MongoDB.

High-availability Cluster Solutions

Tính sẵn sàng cao của hệ thống máy tính có các biểu hiện khác nhau ở các cấp độ khác nhau:

(1) Network high availability

Nhờ sự phát triển nhanh chóng của lưu trữ mạng, công nghệ dự phòng mạng trải qua những cải tiến không ngừng. Ứng dụng chính để cải thiện tính sẵn sàng cao của các hệ thống CNTT nằm ở tính khả dụng cao của mạng. Các khía cạnh sẵn sàng cao và độ tin cậy cao của một mạng là khác nhau. Chúng tôi đạt được tính sẵn sàng cao của mạng thông qua dự phòng thiết bị mạng bằng cách kết hợp các thiết bị mạng dự phòng, chẳng hạn như bộ chuyển mạch dự phòng, bộ định tuyến, v.v.

(2) Server high availability

Chủ yếu, chúng tôi đạt được sự thống nhất sẵn sàng cao của các máy chủ sử dụng những cluster software or những software có tính availability

(3) Storage high availability

Chúng ta nên sử dụng những storage có tính sẵn sàng cao để đề cập đến việc đạt được khả năng lưu trữ cao bằng những software hoặc những công nghệ phần cứng. Các chỉ số kỹ thuật chính là chuyển đổi lưu trữ, sao chép dữ liệu và các tính năng snapshot dữ liệu. Khi một thiết bị lưu trữ bị lỗi, một thiết bị lưu trữ dự phòng khác có thể nhanh chóng tiếp quản dịch vụ lưu trữ mà không bị gián đoạn.

MongoDB High-availability Cluster Configuration

Một dạng rút gọn của cụm từ high-availability cluster là HA Cluster .

Cluster là tập hợp các máy tính cung cấp cho người dùng toàn bộ tài nguyên

Các hệ thống máy chủ này là các nút của cluster

Xây dựng một cluster có tính sẵn sàng cao đòi hỏi sự phân bổ hợp lý vai trò của nhiều máy chủ, cũng như các cơ chế phục hồi dữ liệu và tính nhất quán. Các phương pháp chính như sau:

(1) Master-slave Approach (Asymmetric)

Khi một master node đang chạy, Slave node ở trạng thái theo dõi và chuẩn bị; khi master node thất bại, slave node đảm nhận tất cả các nhiệm vụ của master. Sau khi master up tiếp tục các dịch vụ bình thường, các dịch vụ sẽ quay trở lại master node theo cài đặt của sysadmin một cách automation hoặc manual. Ngoài ra, nó đảm bảo tính nhất quán dữ liệu thông qua hệ thống lưu trữ được chia sẻ.

(2) Dual-machine Running Approach (Dual Active Mode)

Trong trường hợp running 2 node master chạy các dịch vụ của chúng cùng một lúc và monitor lẫn nhau . Khi một trong hai master node bị lỗi, master node khác sẽ ngay lập tức đảm nhận tất cả các tác vụ để đảm bảo mọi thứ chạy trong thời gian thực. Nó lưu trữ dữ liệu chính của hệ thống và tất cả cách dịch vụ , ứng dụng trong hệ thống lưu trữ được chia sẻ.

(3) Cluster Running Approach (Multi-active mode)

Trong trường hợp này thì nhiều master node hoạt động cùng nhau, mỗi node chạy 1 hoặc vài dịch vụ và mỗi node xác định một hoặc nhiều backup node cho các dịch vụ. Khi bất kỳ master node nào thất bại, các node master sẽ tiếp quản lý các dịch vụ đang chạy trên nó.

Các cách thực hành cấu hình cụm MongoDB cũng tuân theo các sơ đồ này, chủ yếu liên quan đến cấu trúc Master – slave , Replica set và cách tiếp cận Sharding.

Master-slave Structure

Nói chung, chúng tôi sử dụng kiến trúc master-Slave để phân chia sao lưu hoặc đọc-ghi. Cấu trúc tồn tại trong hai bộ phận cấu trúc, cấu trúc one-master-one-slave và cấu trúc one-master-multiple-slave.

Có hai vai trò chủ yếu:

(1) Master :

Master node có thể vừa read và write data. sau khi xử lý dữ liệu xong, phần op-log nó sẽ đồng bộ hóa các bản cập nhật cho tất cả các slave node được kết nối.

(2) Slave

slave node chỉ có thể đọc dữ liệu, nhưng không thể ghi dữ liệu. Nó tự động đồng bộ hóa dữ liệu từ master node

Chúng tôi không khuyến khích MongoDB sử dụng kiến trúc master-Slave vì không thể tự động khôi phục master node sau khi bị crash. Giải pháp thiết lập bản sao dự phòng sẽ là lý tưởng.

Kiến trúc master – slave vẫn không được sử dụng trừ khi số lượng node replica vượt quá 50. Thông thường, người ta không cần sử dụng quá nhiều node

Ngoài ra, kiến trúc master-slave không hỗ trợ chained structure. Chỉ có thể kết nối trực tiếp slave node với master node. Redis là kiến trúc master-Slave hỗ trợ cấu trúc chuỗi và cho phép chúng ta kết nối slave node với một slave node khác

Replica Set

Cơ chế thiết lập bản sao của MongoDB có hai mục đích chính:

• Một là để dự phòng dữ liệu để phục hồi thất bại. Khi phần cứng bị lỗi hoặc node bị hỏng vì các lý do khác, bạn có thể sử dụng bản sao để khôi phục.

• Mục đích khác là để phân chia đọc-ghi. Nó định tuyến các yêu cầu đọc đến bản sao để giảm áp lực đọc trên nút chính.

1.Replica set with the primary and secondary nodes

Replica là một tập hợp các MongoDB instance có chung nội dung dữ liệu. Nó chủ yếu liên quan đến ba vai trò:

(a) Primary node

Primary node nhận tất cả các yêu cầu ghi, sau đó đồng bộ hóa các thay đổi cho tất cả các nút phụ. Một bộ bản sao chỉ có thể có một primary node

Khi primary node lỗi, các secondary node khác hoặc node gắn cờ (Trọng tài) sẽ chọn lại một primary node. và node chính này nhận được yêu cầu đọc để xử lý request theo mặc định. Nếu bạn muốn chuyển tiếp các yêu cầu đọc đến một secondary node, bạn cần sửa đổi cấu hình kết nối trên máy khách.

(b) Secondary nodes

Khi 1 secondary node duy trì cùng một tập dữ liệu với primary node. Khi primary node failed, các secondary tham gia vào việc bầu chọn primary node .

© Arbiter nodes

Một Arbiter node không lưu trữ dữ liệu hoặc tham gia vào cuộc bầu cử primary node, nhưng nó thực hiện bỏ phiếu bầu cử. Arbiter node có thể giảm các yêu cầu phần cứng để lưu trữ dữ liệu, vì arbiter chạy với nhu cầu tối thiểu về tài nguyên phần cứng. Tuy nhiên, điều quan trọng là người ta không nên triển khai Arbiter node trên cùng một máy chủ với các node dữ liệu khác trong môi trường production

Lưu ý: Số lượng node có khả năng chuyển đổi dự phòng tự động trong bộ bản sao phải là số lẻ để tránh ràng buộc khi tham gia bỏ phiếu tại cuộc bầu cử nút chính.

(d) Primary node election

Dịch vụ sẽ vẫn không bị ảnh hưởng nếu secondary node bị hỏng, nhưng nếu primary node bị hỏng, hệ thống sẽ bắt đầu bầu lại nút chính:

2.Establish a replica set using the arbiter node

Replica bao gồm số data n chẵn, cộng với nút trọng tài:

Sharding Technology

Khi lượng dữ liệu tương đối lớn, chúng ta cần phải phân đoạn và chạy dữ liệu trên các máy chủ khác nhau để giảm áp suất CPU, memory và IO. sharding ở đây được đề cập đến “Database sharding technology”

Công nghệ sharding của MongoDB tương tự như phân chia theo chiều ngang và phân tách dọc của MySQL. database chủ yếu áp dụng theo hai cách tiếp cận sharding: mở rộng theo chiều dọc và sharding theo chiều ngang.

Mở rộng theo chiều dọc đề cập đến mở rộng cluster, cụ thể là thêm nhiều tài nguyên CPU hoặc memory or disk space

Sharding theo chiều ngang có nghĩa là bảo vệ dữ liệu để cung cấp dịch vụ một cách thống nhất thông qua cluster được hiển thị bên dưới:

(1) MongoDB sharding architecture:

(2) Roles in MongoDB sharding architecture :

A. Data shards

Một data shard phục vụ để lưu trữ dữ liệu để đảm bảo tính sẵn sàng cao nhất và tính nhất quán của dữ liệu. Nó có thể là một cá thể MongoDB riêng hoặc replica set

Shard nói chung là một bản replica được thiết lập trong môi trường production được thiết kế để ngăn chặn các điểm lỗi đơn lẻ trong phân đoạn dữ liệu. Một phân đoạn chính tồn tại trong số tất cả các phân đoạn có chứa bộ sưu tập dữ liệu không được bảo vệ:

B. Query routers

Một bộ định tuyến (router) là một ví dụ mongos. Client có kết nối trực tiếp với mongos, các router này đọc và ghi yêu cầu đến phân đoạn data được chỉ định.

Một cụm Sharding có thể có một mongos instance or multiple mongos instance để giảm bớt áp lực từ các yêu cầu của máy khách.

C. Configuration servers

Một máy chủ cấu hình lưu metadata của cluster, bao gồm các rule routing cho từng phân đoạn.

Conclusion:

Để đảm bảo rằng một cluster trong môi trường production ít tồn tại điểm thất bại, điều quan trọng là cung cấp một cluster được Sharding cho  high availability. Ngoài việc giới thiệu kỹ lưỡng các mối quan tâm về tính khả dụng liên quan đến việc triển khai MongoDB với các điểm nổi bật về các tình huống lỗi tiềm ẩn và độ phân giải có sẵn của chúng, bài đăng này cho thấy các tính năng phân biệt của các giải pháp cụm khả dụng cao.

Hơn nữa, nó khám phá công nghệ Sharding và mô tả đầy đủ vai trò của kiến trúc Sharding MongoDB như áp dụng cho các phân đoạn dữ liệu, bộ định tuyến truy vấn và máy chủ cấu hình.

Reference:

https://www.alibabacloud.com/blog/High-availability-MongoDB-Cluster-Configuration-Solutions_p490866?spm=a2c41.11248211.0.0