Giả sử một tình huống trong đó bạn chỉ có một phiên bản Redis trong quá trình sản xuất của mình và nó không thành công tại một số thời điểm do một số lý do. Ứng dụng của bạn lưu trữ dữ liệu trong kho dữ liệu Redis và bây giờ nguồn dữ liệu duy nhất của bạn đã chết. Một cách để kiểm soát các loại kịch bản này là duy trì kiến trúc chủ-tớ nơi các nô lệ có thể sao chép nút chính cho đến khi nó hoạt động trở lại. Các cụm Redis hỗ trợ tính khả dụng cao ở một mức độ nào đó với cách tiếp cận bản sao tổng thể. Redis Sentinel là một cách tiếp cận khác cung cấp một cách đáng tin cậy hơn để duy trì tính khả dụng cao của các phiên bản Redis. Nó giám sát nút chính của Redis để tìm lỗi và kích hoạt quá trình chuyển đổi dự phòng ngay lập tức, quá trình này sẽ thúc đẩy nút phụ hiện có thành một nút chính hoàn toàn mới.
Hơn nữa, Redis sentinel hoạt động như một người trung gian nơi các khách hàng kết nối và yêu cầu địa chỉ IP của nút Chính mới nhất. Vì vậy, sentinel được kết nối cung cấp địa chỉ nút chính ngay lập tức.
Ngoài ra, lỗi của nút chính được xác nhận nếu nhiều lính canh đồng ý rằng một nút chính nhất định không thể truy cập hoặc khả dụng. Điều này kết thúc giai đoạn phát hiện lỗi và quá trình chuyển đổi dự phòng bắt đầu ngay lập tức. Do đó, Redis sentinel có thể được coi là một hệ thống phân tán với các thuộc tính cụ thể.
Thỏa thuận của các lính canh dựa trên giá trị đại biểu sẽ được thảo luận trong phần sau.
Giá trị của ai
Giá trị Quorum là số lượng tối đa các vệ tinh cần được thỏa thuận khi nút chính ngừng hoạt động. Giá trị này chỉ được sử dụng để xác định lỗi trong nút chính. Quá trình chuyển đổi dự phòng bắt đầu với sự ủy quyền của nhiều nút lính canh có sẵn để tiến hành với một người lính canh được chọn làm lãnh đạo.
Đặc điểm của Redis Sentinel
Cơ quan giám sát được biết đến là nơi cung cấp cơ chế sẵn sàng cao cho kho dữ liệu Redis. Ngoài ra, một số khả năng khác có thể được liệt kê.
- Sentinel liên tục theo dõi trạng thái của các nút chủ và nút phụ trong hệ thống Redis của bạn.
- Bất cứ khi nào có lỗi hoặc có vấn đề gì xảy ra với các phiên bản Redis của bạn, trạm gác có thể thông báo cho quản trị viên hoặc các ứng dụng được kết nối bằng cách sử dụng API sentinel.
- Giai đoạn chuyển đổi dự phòng được chỉ đạo bởi lính canh bằng cách quảng bá một bản sao làm bản chính mới. Các bản sao còn lại được định cấu hình để sử dụng bản chính mới. Cuối cùng, các máy khách tương ứng sẽ được thông báo về địa chỉ nút chính mới.
- Ngoài ra, Redis sentinel là nhà cung cấp cấu hình cho các máy khách được kết nối, nơi các máy khách có thể yêu cầu địa chỉ của phiên bản chính hiện có sẵn và nếu xảy ra sự cố đột ngột, sentinel cam kết đẩy địa chỉ nút chính mới ngay lập tức.
Trong phần tiếp theo, chúng tôi sẽ định cấu hình Redis sentinels với các phiên bản master-replica và sử dụng API sentinel để giám sát các nút.
Cấu hình Sentinel
Đầu tiên, chúng ta tạo hai phiên bản Redis tại các cổng 7000 và 7001. Cổng 7000 sẽ là nút chính và một nút còn lại sao chép nút chính. Cả hai phiên bản đều sử dụng các tệp cấu hình sau tương ứng:
Cấu hình nút chính
Hải cảng 7000không kích hoạt cụm
cluster-config-file node.conf
cluster-node-timeout 5000
phụ thuộc vào Vâng
Cấu hình nút nô lệ
Hải cảng 7001không kích hoạt cụm
cluster-config-file node.conf
cluster-node-timeout 5000
phụ thuộc vào Vâng
Cả hai phiên bản sẽ bắt đầu bằng cách cung cấp tệp cấu hình được liên kết với mỗi phiên bản. Chúng ta có thể sử dụng lệnh sau để bắt đầu các phiên bản Redis riêng biệt:
redis-server redis.conf
Hãy kết nối với phiên bản Redis bắt đầu ở cổng 7001 như sau:
redis-cli -P 7001
Bây giờ, chúng ta có thể làm cho phiên bản này trở thành một bản sao của cái chính đang chạy ở cổng 7000. Lệnh REPLICAOF có thể được sử dụng như sau:
replicaof 127.0.0.1 7000
Đúng như dự đoán, phiên bản đang chạy ở cổng 7001 đã trở thành nút bản sao của nút chính chạy ở cổng 7000.
Bây giờ, chúng tôi đã sẵn sàng cấu hình ba vệ tinh Redis để giám sát phiên bản chính ở trên. Chúng ta cần có ba tệp cấu hình để tạo ba phiên bản sentinel tại các cổng 5000, 5001 và 5002 như được hiển thị trong hình sau.
Mỗi sentinel.conf tệp trông giống như sau ngoại trừ số cổng sẽ được thay đổi:
Hải cảng 5000masternode giám sát sentinel 127.0.0.1 7000 hai
sentinel down-after-milieconds masternode 5000
masternode thời gian chờ chuyển đổi dự phòng sentinel 60000
Bây giờ, đã đến lúc điều hành ba lính canh. Bạn có thể sử dụng tệp thực thi redis-sentinel cùng với đường dẫn đến sentinel.conf tệp cấu hình để tạo một phiên bản sentinel. Nếu không, chúng ta vẫn có thể gọi tệp thực thi redis-server bằng cách chỉ định đường dẫn đến sentinel.conf và lá cờ –Sentinel .
Hãy bắt đầu mỗi lính canh bằng lệnh sau:
redis-server sentinel.conf --sentinel
Sentinel đầu tiên đã được bắt đầu ở cổng 5000. Tương tự, bạn cũng có thể bắt đầu hai phiên bản còn lại.
Bây giờ, thiết lập sentinel Redis của chúng tôi đã được thiết lập và chạy như thể hiện trong hình minh họa sau:
Trong phần sau, chúng ta sẽ khám phá thêm về API Sentinel và cách chúng ta có thể sử dụng nó để truy xuất thông tin liên quan đến nút chính Redis.
API Sentinel
Redis cung cấp một API giám sát riêng biệt để giám sát các bản chính và bản sao được liên kết, đăng ký nhận thông báo và sửa đổi cài đặt trạm gác. Hơn nữa, một số cách sử dụng được liệt kê sau đây.
- Kiểm tra trạng thái của các cá thể Redis master và slave được giám sát
- Thông tin chi tiết về các lính canh khác
- Nhận thông báo kiểu đẩy từ các trạm gác trong trường hợp chuyển đổi dự phòng
Lệnh SENTINEL có thể được sử dụng với các lệnh con liên quan của nó để truy vấn, cập nhật hoặc đặt các chốt giám sát và các nút được giám sát của Redis.
Kiểm tra trạng thái của nút chính
Theo dõi hoặc kiểm tra tình trạng nút chính theo thời gian là rất quan trọng. Lệnh sau API sentinel có thể được sử dụng để truy xuất các chi tiết chính:
SENTINEL MASTER < Managed_master_name >
Managed_master_name: Tên của nút chính được chỉ định trong tệp cấu hình sentinel mà chúng tôi đã tạo ở bước trước đó.
Hãy sử dụng lệnh này để truy vấn trạng thái chính trong thiết lập của chúng tôi. Trong trường hợp của chúng tôi, tên nút chính là 'masternode'.
Nút chính SENTINEL MASTER
Một số phần thông tin đã được truy xuất và một số phần quan trọng như num-nô lệ, cờ và num-khác-lính canh.
Các cờ tài sản được đặt thành bậc thầy có nghĩa là chủ nhân có sức khỏe tốt. Bất cứ khi nào nút chính gặp sự cố, s_down hoặc o_down cờ sẽ được hiển thị. Bất động sản num-other-sentinels được đặt thành 2 có nghĩa là Redis sentinel đã nhận ra hai trạm canh khác cho nút chính. Ngoài ra, num-nô lệ thuộc tính hiển thị các bản sao có sẵn cho nút chính. Trong trường hợp này, nó được đặt thành 1 vì chúng ta chỉ có một bản sao.
Nhận thông tin về các bản sao được kết nối
Chúng tôi có thể kiểm tra các bản sao được kết nối với nút chính bằng lệnh phụ SENTINEL sau:
SENTINEL REPLICAS < Managed_master_name >
Trong ví dụ này, tên chính là 'masternode'.
SENTINEL bản sao masternode
Đúng như dự đoán, Sentinel đã phát hiện ra nút nô lệ đang chạy ở cổng 7001.
Nhận thông tin về các Sentinel được liên kết
Tương tự, chúng ta có thể truy vấn các chi tiết liên quan đến các vệ tinh khác được liên kết với nút chính hiện tại bằng cách sử dụng lệnh con SENTINEL sau:
SENTINEL SENTINELS < master_node_name >
Trong trường hợp này, chúng tôi sẽ tìm nạp thông tin liên quan đến nút chính có tên là ‘masternode’.
Masternode của SENTINEL sentinels
Lấy địa chỉ nút chính
Như đã đề cập trong phần trước, Redis sentinel là nhà cung cấp cấu hình cho các máy khách được kết nối. Vì vậy, nó có khả năng cung cấp địa chỉ IP nút chính và cổng hiện đang chạy cho các máy khách được yêu cầu. Lệnh con Sentinel API sau đây có thể được sử dụng để truy xuất thông tin được đề cập.
SENTINEL NHẬN-MASTER-ĐỊA CHỈ-THEO TÊN < master_node_name >
Hãy thực hiện lệnh trên cho tình huống của chúng ta như sau:
sentinel get-master-addr-by-name masternode
Chúng tôi chỉ thảo luận về một số lệnh API sentinel. Một số lệnh con khác có sẵn như sentinel-failover, sentinel info-cache, sentinel master, v.v. Hơn nữa, nhiều lệnh cũng có sẵn để sử dụng cho mục đích quản trị. Trong phần sau, chúng ta sẽ tập trung vào quá trình chuyển đổi dự phòng Redis sentinel.
Quy trình chuyển đổi dự phòng Sentinel
Vì sentinel của chúng tôi được định cấu hình, chúng tôi có thể kiểm tra giai đoạn fail-over. Hãy để nút chính của chúng ta ở trạng thái ngủ trong 300 giây, mô phỏng sự cố trong nút chính.
gỡ lỗi ngủ 300
Nút chính đang chạy ở cổng 7000 hiện không thể truy cập được. Vì vậy, các lính canh được liên kết sẽ thông báo rằng tổng thể không khả dụng với + sdown biến cố. Sau đó, điều này sẽ được đặt thành + odown trong đó 2 lính canh xác nhận nút chính bị hỏng theo giá trị túc số. Cuối cùng, giai đoạn chuyển đổi dự phòng sẽ bắt đầu và lý tưởng nhất là bản sao nên được thăng cấp thành bản chính mới.
Hãy kiểm tra lại địa chỉ IP của nút chính và cổng.
sentinel get-master-addr-by-name masternode
Như mong đợi, bản sao trước đó đã được thăng cấp lên bản chính mới, có nghĩa là quá trình chuyển đổi dự phòng sentinel thành công. Điều này kết thúc việc triển khai và thử nghiệm ba thiết lập sentinel của chúng tôi cho cặp bản sao chính duy nhất.
Sự kết luận
Redis sentinel là cách tiếp cận đáng tin cậy nhất để đảm bảo tính khả dụng cao của một bản sao chính Redis nhất định. Một trạm cảnh sát có khả năng giám sát, thông báo và bắt đầu chuyển đổi dự phòng tự động mà không cần sự can thiệp của con người. Ngoài ra, nhiều vệ tinh cùng đồng ý về thực tế là nút chính không thể truy cập được và giá trị đại biểu được sử dụng làm số lượng tối đa các vệ tinh cần được thỏa thuận khi kiểm tra tính khả dụng của cá thể chính. Redis sentinel cung cấp một API dễ sử dụng để truy xuất thông tin về tình trạng của nút chính và các bản sao liên quan cũng như thực hiện các tác vụ quản trị.