Dự phòng là khả năng hệ thống tiếp tục hoạt động ngay cả khi một số lỗi xảy ra. Nó gợi ý rằng các chức năng của hệ thống được đảm nhận bởi các thành phần thứ cấp nếu các thành phần chính bị lỗi hoặc nếu nó là cần thiết. Vì vậy, nếu bạn dịch nó sang môi trường đa đám mây PostgreSQL, điều đó có nghĩa là khi nút chính của bạn bị lỗi (hoặc một lý do khác như chúng tôi sẽ đề cập trong phần tiếp theo) trong nhà cung cấp đám mây chính của bạn, bạn phải có khả năng quảng bá nút dự phòng trong cái thứ hai để giữ cho hệ thống hoạt động.
Nói chung, tất cả các nhà cung cấp dịch vụ đám mây đều cung cấp cho bạn tùy chọn chuyển đổi dự phòng trong cùng một nhà cung cấp đám mây, nhưng có thể bạn cần chuyển đổi dự phòng sang một nhà cung cấp đám mây khác. Tất nhiên, bạn có thể làm điều đó theo cách thủ công, nhưng bạn cũng có thể sử dụng một số tính năng của ClusterControl như tự động chuyển đổi dự phòng hoặc thúc đẩy hành động của nô lệ để thực hiện việc này một cách thân thiện và dễ dàng.
Trong blog này, bạn sẽ thấy lý do tại sao bạn cần chuyển đổi dự phòng, cách thực hiện thủ công và cách sử dụng ClusterControl cho tác vụ này. Chúng tôi sẽ giả sử bạn đang chạy cài đặt ClusterControl và đã tạo cụm cơ sở dữ liệu của bạn trong hai nhà cung cấp đám mây khác nhau.
Chuyển đổi dự phòng được sử dụng để làm gì?
Có một số cách sử dụng chuyển đổi dự phòng.
Lỗi chính
Nếu nút chính của bạn không hoạt động hoặc ngay cả khi Nhà cung cấp đám mây chính của bạn có một số vấn đề, bạn phải chuyển đổi dự phòng để đảm bảo tính khả dụng của hệ thống. Trong trường hợp này, cần có một cách tự động để thực hiện việc này để giảm thời gian chết.
Di chuyển
Nếu bạn muốn di chuyển hệ thống của mình từ Nhà cung cấp dịch vụ đám mây này sang Nhà cung cấp dịch vụ đám mây khác bằng cách giảm thiểu thời gian ngừng hoạt động, bạn có thể sử dụng chuyển đổi dự phòng. Bạn có thể tạo bản sao trong Nhà cung cấp đám mây thứ cấp và khi nó được đồng bộ hóa, bạn phải dừng hệ thống của mình, quảng bá bản sao và chuyển đổi dự phòng, trước khi bạn trỏ hệ thống của mình đến nút chính mới trong Nhà cung cấp đám mây thứ cấp.
Bảo trì
Nếu bạn cần thực hiện bất kỳ tác vụ bảo trì nào trên nút chính PostgreSQL của mình, bạn có thể quảng bá bản sao của mình, thực hiện tác vụ và xây dựng lại nút chính cũ của mình dưới dạng nút dự phòng.
Sau đó, bạn có thể xúc tiến nút chính cũ và lặp lại quá trình xây dựng lại trên nút chờ, trở lại trạng thái ban đầu.
Bằng cách này, bạn có thể làm việc trên máy chủ của mình mà không gặp rủi ro ngoại tuyến hoặc mất thông tin khi thực hiện bất kỳ tác vụ bảo trì nào.
Nâng cấp
Có thể nâng cấp phiên bản PostgreSQL của bạn (kể từ PostgreSQL 10) hoặc thậm chí nâng cấp Hệ điều hành của bạn bằng cách sử dụng bản sao lôgic mà không có thời gian chết, vì nó có thể được thực hiện với các công cụ khác.
Các bước sẽ giống như chuyển sang Nhà cung cấp đám mây mới, chỉ khác là bản sao của bạn sẽ ở phiên bản PostgreSQL hoặc OS mới hơn và bạn cần sử dụng bản sao lôgic vì bạn không thể sử dụng tính năng phát trực tuyến nhân rộng giữa các phiên bản khác nhau.
Chuyển đổi dự phòng không chỉ dành cho cơ sở dữ liệu mà còn cả ứng dụng. Làm thế nào để họ biết cơ sở dữ liệu nào để kết nối? Bạn có thể không muốn phải sửa đổi ứng dụng của mình, vì điều này sẽ chỉ kéo dài thời gian ngừng hoạt động của bạn, vì vậy, bạn có thể định cấu hình Load Balancer để khi nút chính của bạn không hoạt động, nó sẽ tự động trỏ đến máy chủ đã được thăng cấp.
Có một phiên bản Load Balancer không phải là lựa chọn tốt nhất vì nó có thể trở thành một điểm lỗi duy nhất. Do đó, bạn cũng có thể thực hiện chuyển đổi dự phòng cho Load Balancer, bằng cách sử dụng một dịch vụ như Keepalived. Bằng cách này, nếu bạn gặp sự cố với Bộ cân bằng tải chính của mình, Keepalived sẽ di chuyển IP ảo sang Bộ cân bằng tải thứ cấp của bạn và mọi thứ tiếp tục hoạt động minh bạch.
Một tùy chọn khác là sử dụng DNS. Bằng cách thúc đẩy nút chờ trong Nhà cung cấp đám mây thứ cấp, bạn trực tiếp sửa đổi địa chỉ IP của tên máy chủ trỏ đến nút chính. Bằng cách này, bạn tránh phải sửa đổi ứng dụng của mình và mặc dù nó không thể được thực hiện tự động nhưng đây là một giải pháp thay thế nếu bạn không muốn triển khai Load Balancer.
Cách chuyển đổi dự phòng PostgreSQL theo cách thủ công
Trước khi thực hiện chuyển đổi dự phòng thủ công, bạn phải kiểm tra trạng thái sao chép. Có thể khi bạn cần chuyển đổi dự phòng, nút dự phòng không được cập nhật, do lỗi mạng, tải cao hoặc một vấn đề khác, vì vậy bạn cần đảm bảo nút dự phòng của mình có tất cả (hoặc gần như tất cả thông tin. Nếu bạn có nhiều hơn một nút chờ, bạn cũng nên kiểm tra xem nút nào là nút nâng cao nhất và chọn nó để chuyển đổi dự phòng.
postgres=# SELECT CASE WHEN pg_last_wal_receive_lsn()=pg_last_wal_replay_lsn()
postgres-# THEN 0
postgres-# ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
postgres-# END AS log_delay;
log_delay
-----------
0
(1 row)Khi bạn chọn nút chính mới, trước tiên, bạn có thể chạy lệnh pg_lsclusters để lấy thông tin cụm:
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
12 main 5432 online,recovery postgres /var/lib/postgresql/12/main log/postgresql-%Y-%m-%d_%H%M%S.logSau đó, bạn chỉ cần chạy lệnh pg_ctlcluster với hành động xúc tiến:
$ pg_ctlcluster 12 main promoteThay vì lệnh trước đó, bạn có thể chạy lệnh pg_ctl theo cách này:
$ /usr/lib/postgresql/12/bin/pg_ctl promote -D /var/lib/postgresql/12/main/
waiting for server to promote.... done
server promotedSau đó, nút dự phòng của bạn sẽ được thăng cấp thành nút chính và bạn có thể xác thực nó bằng cách chạy truy vấn sau trong nút chính mới của mình:
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)Nếu kết quả là “f”, thì đó là nút chính mới của bạn.
Bây giờ, bạn phải thay đổi địa chỉ IP cơ sở dữ liệu chính trong ứng dụng của mình, Load Balancer, DNS hoặc triển khai mà bạn đang sử dụng, như chúng tôi đã đề cập, việc thay đổi thủ công này sẽ làm tăng thời gian ngừng hoạt động. Bạn cũng cần đảm bảo kết nối của mình giữa các nhà cung cấp có thể hoạt động bình thường, ứng dụng có thể truy cập vào nút chính mới, người dùng ứng dụng có đặc quyền truy cập nó từ một nhà cung cấp đám mây khác và bạn nên xây dựng lại (các) nút dự phòng trong điều khiển từ xa hoặc thậm chí trong nhà cung cấp đám mây cục bộ, để sao chép từ chính mới, nếu không, bạn sẽ không có tùy chọn chuyển đổi dự phòng mới nếu cần.
Cách chuyển đổi dự phòng PostgreSQL bằng ClusterControl
ClusterControl có một số tính năng liên quan đến sao chép PostgreSQL và chuyển đổi dự phòng tự động. Chúng tôi sẽ cho rằng bạn đã cài đặt máy chủ ClusterControl và nó đang quản lý môi trường PostgreSQL Đa đám mây của bạn.
Với ClusterControl, bạn có thể thêm bao nhiêu nút chờ hoặc nút Load Balancer tùy ý mà không bị giới hạn IP mạng. Điều đó có nghĩa là không nhất thiết nút dự phòng phải nằm trong cùng một mạng nút chính hoặc thậm chí trong cùng một nhà cung cấp đám mây. Về chuyển đổi dự phòng, ClusterControl cho phép bạn thực hiện việc đó theo cách thủ công hoặc tự động.
Chuyển đổi dự phòng thủ công
Để thực hiện chuyển đổi dự phòng thủ công, hãy đi tới ClusterControl -> Chọn Cụm -> Nút và trong Hành động nút của một trong các nút dự phòng của bạn, hãy chọn "Thúc đẩy Slave".
Theo cách này, sau vài giây, nút chờ của bạn trở thành nút chính, và những gì là chính của bạn trước đây, được chuyển sang chế độ chờ. Vì vậy, nếu bản sao của bạn ở trong một nhà cung cấp đám mây khác, thì nút chính mới của bạn sẽ ở đó, thiết lập và chạy.
Tự động chuyển đổi dự phòng
Trong trường hợp tự động chuyển đổi dự phòng, ClusterControl phát hiện các lỗi trong nút chính và thúc đẩy nút dự phòng có dữ liệu mới nhất làm nút chính mới. Nó cũng hoạt động trên phần còn lại của các nút dự phòng để chúng tái tạo từ nút chính mới này.
BẬT tùy chọn “Autorecovery”, ClusterControl sẽ thực hiện chuyển đổi dự phòng tự động như cũng như thông báo cho bạn về sự cố. Bằng cách này, hệ thống của bạn có thể phục hồi trong vài giây mà không cần sự can thiệp của bạn.
ClusterControl cung cấp cho bạn khả năng định cấu hình danh sách trắng / danh sách đen để xác định cách bạn muốn máy chủ của mình được xem xét (hoặc không được tính đến) khi quyết định lựa chọn ứng viên chính.
ClusterControl cũng thực hiện một số kiểm tra đối với quá trình chuyển đổi dự phòng, ví dụ:theo mặc định, nếu bạn quản lý để khôi phục nút chính bị lỗi cũ của mình, nó sẽ không được giới thiệu lại tự động vào cụm, không phải là nút chính cũng như ở chế độ chờ, bạn sẽ cần phải làm điều đó theo cách thủ công. Điều này sẽ tránh khả năng mất dữ liệu hoặc không nhất quán trong trường hợp chế độ chờ của bạn (mà bạn đã quảng bá) bị trì hoãn tại thời điểm xảy ra sự cố. Bạn cũng có thể muốn phân tích vấn đề một cách chi tiết, nhưng khi thêm nó vào cụm của bạn, bạn có thể sẽ mất thông tin chẩn đoán.
Cân bằng tải
Như chúng tôi đã đề cập trước đó, Load Balancer là một công cụ quan trọng cần xem xét để chuyển đổi dự phòng của bạn, đặc biệt nếu bạn muốn sử dụng chuyển đổi dự phòng tự động trong cấu trúc liên kết cơ sở dữ liệu của mình.
Để chuyển đổi dự phòng được minh bạch cho cả người dùng và ứng dụng, bạn cần một thành phần ở giữa, vì nó không đủ để quảng bá một nút chính mới. Đối với điều này, bạn có thể sử dụng HAProxy + Keepalived.
Để thực hiện giải pháp này với ClusterControl, hãy chuyển đến Cluster Actions -> Add Load Balancer -> HAProxy trên cụm PostgreSQL của bạn. Trong trường hợp bạn muốn triển khai chuyển đổi dự phòng cho Load Balancer của mình, bạn phải định cấu hình ít nhất hai phiên bản HAProxy và sau đó, bạn có thể cấu hình Keepalived (Cluster Actions -> Add Load Balancer -> Keepalived). Bạn có thể tìm thêm thông tin về cách triển khai này trong bài đăng trên blog này.
Sau đó, bạn sẽ có cấu trúc liên kết sau:
HAProxy được định cấu hình theo mặc định với hai cổng khác nhau, một cổng đọc-ghi và một chỉ đọc.
Trong cổng đọc-ghi, bạn có nút chính của mình là trực tuyến và các nút còn lại là ngoại tuyến. Trong cổng chỉ đọc, bạn có cả nút chính và nút chờ trực tuyến. Bằng cách này, bạn có thể cân bằng lưu lượng đọc giữa các nút. Khi ghi, cổng đọc-ghi sẽ được sử dụng, cổng này sẽ trỏ đến nút chính hiện tại.
Khi HAProxy phát hiện ra rằng một trong các nút, dù là chính hoặc ở chế độ chờ, không thể truy cập được, nó sẽ tự động đánh dấu là ngoại tuyến. HAProxy sẽ không gửi bất kỳ lưu lượng nào đến nó. Việc kiểm tra này được thực hiện bằng các tập lệnh kiểm tra tình trạng được cấu hình bởi ClusterControl tại thời điểm triển khai. Những điều này kiểm tra xem các phiên bản đã hoạt động chưa, chúng đang trong quá trình khôi phục hay ở chế độ chỉ đọc.
Khi ClusterControl quảng bá một nút chính mới, HAProxy đánh dấu nút cũ là ngoại tuyến (cho cả hai cổng) và đặt nút được quảng bá trực tuyến trong cổng đọc-ghi. Bằng cách này, hệ thống của bạn tiếp tục hoạt động bình thường.
Nếu HAProxy đang hoạt động (đã gán một địa chỉ IP Ảo mà hệ thống của bạn kết nối) không thành công, Keepalived sẽ tự động di chuyển IP Ảo này sang HAProxy thụ động. Điều này có nghĩa là hệ thống của bạn sau đó có thể tiếp tục hoạt động bình thường.
Sao chép theo cụm trong đám mây
Để có môi trường Đa đám mây, bạn có thể sử dụng hành động ClusterControl Add Slave trên cụm PostgreSQL của bạn, cũng như tính năng Sao chép cụm từ thành cụm. Hiện tại, tính năng này có một hạn chế đối với PostgreSQL là cho phép bạn chỉ có một nút từ xa, nhưng chúng tôi đang nỗ lực để sớm loại bỏ hạn chế đó trong một bản phát hành trong tương lai.
Để triển khai nó, bạn có thể kiểm tra phần “Sao chép theo cụm-thành-cụm trong đám mây” trong bài đăng blog này.
Khi có sẵn, bạn có thể quảng bá cụm từ xa sẽ tạo một cụm PostgreSQL độc lập với một nút chính chạy trên nhà cung cấp đám mây thứ cấp.
Vì vậy, trong trường hợp cần thiết, bạn sẽ có cùng một cụm chạy trong một nhà cung cấp đám mây mới chỉ trong vài giây.
Kết luận
Bắt buộc phải có quy trình chuyển đổi dự phòng tự động nếu bạn muốn có ít thời gian chết nhất có thể, đồng thời sử dụng các công nghệ khác nhau như HAProxy và Keepalived sẽ cải thiện quá trình chuyển đổi dự phòng này.
Các tính năng của ClusterControl mà chúng tôi đã đề cập ở trên sẽ cho phép bạn nhanh chóng chuyển đổi dự phòng giữa các Nhà cung cấp đám mây khác nhau và quản lý thiết lập một cách dễ dàng và thân thiện.
Điều quan trọng nhất cần xem xét trước khi thực hiện quá trình chuyển đổi dự phòng giữa các Nhà cung cấp dịch vụ đám mây khác nhau là kết nối. Bạn phải đảm bảo rằng ứng dụng của bạn hoặc các kết nối cơ sở dữ liệu của bạn sẽ hoạt động như bình thường bằng cách sử dụng nhà cung cấp đám mây chính và phụ trong trường hợp chuyển đổi dự phòng và vì lý do bảo mật, bạn phải hạn chế lưu lượng truy cập chỉ từ các nguồn đã biết, vì vậy chỉ giữa Đám mây Nhà cung cấp và không cho phép nó từ bất kỳ nguồn bên ngoài nào.
