Trong một bài trước, chúng tôi đã thảo luận về cách bạn có thể kiểm soát quá trình chuyển đổi dự phòng trong ClusterControl bằng cách sử dụng danh sách trắng và danh sách đen. Trong bài đăng này, chúng ta sẽ thảo luận về một khái niệm tương tự. Nhưng lần này chúng tôi sẽ tập trung vào tích hợp với các tập lệnh và ứng dụng bên ngoài thông qua nhiều hook do ClusterControl cung cấp.
Môi trường cơ sở hạ tầng có thể được xây dựng theo nhiều cách khác nhau, vì thường có nhiều tùy chọn để lựa chọn cho một phần nhất định của câu đố. Làm thế nào để chúng tôi xác định nút cơ sở dữ liệu để ghi vào? Bạn có sử dụng IP ảo không? Bạn có sử dụng một số loại khám phá dịch vụ không? Có thể bạn sử dụng các mục nhập DNS và thay đổi các bản ghi A khi cần thiết? Còn về lớp proxy? Bạn có dựa vào giá trị ‘read_only’ cho proxy của mình để quyết định người viết hay có thể bạn thực hiện các thay đổi được yêu cầu trực tiếp trong cấu hình của proxy? Môi trường của bạn xử lý các chuyển đổi như thế nào? Bạn có thể tiếp tục và thực hiện nó, hoặc có thể bạn phải thực hiện một số hành động sơ bộ trước? Ví dụ:tạm dừng một số quy trình khác trước khi bạn thực sự có thể thực hiện chuyển đổi?
Không thể cấu hình sẵn phần mềm chuyển đổi dự phòng để bao gồm tất cả các thiết lập khác nhau mà mọi người có thể tạo. Đây là lý do chính để cung cấp các cách khác nhau để kết nối vào quá trình chuyển đổi dự phòng. Bằng cách này, bạn có thể tùy chỉnh nó và giúp bạn có thể xử lý tất cả các yếu tố tinh vi trong thiết lập của mình. Trong bài đăng trên blog này, chúng ta sẽ xem xét cách có thể tùy chỉnh quy trình chuyển đổi dự phòng của ClusterControl bằng cách sử dụng các tập lệnh chuyển đổi dự phòng trước và sau khác nhau. Chúng tôi cũng sẽ thảo luận về một số ví dụ về những gì có thể đạt được với việc tùy chỉnh như vậy.
Tích hợp ClusterControl
ClusterControl cung cấp một số hook có thể được sử dụng để cắm các tập lệnh bên ngoài. Dưới đây, bạn sẽ tìm thấy danh sách những người có một số giải thích.
- Replication_onfail_failover_script - tập lệnh này thực thi ngay khi phát hiện ra rằng cần chuyển đổi dự phòng. Nếu tập lệnh trả về khác 0, nó sẽ buộc hủy bỏ quá trình chuyển đổi dự phòng. Nếu tập lệnh được xác định nhưng không được tìm thấy, quá trình chuyển đổi dự phòng sẽ bị hủy bỏ. Bốn đối số được cung cấp cho tập lệnh:arg1 ='all server' arg2 ='oldmaster' arg3 ='application', arg4 ='nô lệ của oldmaster' và được chuyển như sau:'scripname arg1 arg2 arg3 arg4'. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_pre_failover_script - tập lệnh này thực thi trước khi quá trình chuyển đổi dự phòng xảy ra, nhưng sau khi một ứng cử viên đã được bầu và có thể tiếp tục quá trình chuyển đổi dự phòng. Nếu tập lệnh trả về khác 0, nó sẽ buộc hủy bỏ chuyển đổi dự phòng. Nếu tập lệnh được xác định nhưng không được tìm thấy, quá trình chuyển đổi dự phòng sẽ bị hủy bỏ. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_post_failover_script - tập lệnh này thực thi sau khi quá trình chuyển đổi dự phòng xảy ra. Nếu tập lệnh trả về khác 0, một Cảnh báo sẽ được ghi vào nhật ký công việc. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_post_unsuccessful_failover_script - Tập lệnh này được thực thi sau khi nỗ lực chuyển đổi dự phòng không thành công. Nếu tập lệnh trả về khác 0, một Cảnh báo sẽ được ghi vào nhật ký công việc. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_failed_reslave_failover_script - tập lệnh này được thực thi sau khi một bản chính mới đã được thăng cấp và nếu việc tạo lại các nô lệ cho bản chính mới không thành công. Nếu tập lệnh trả về khác 0, một Cảnh báo sẽ được ghi vào nhật ký công việc. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_pre_switchover_script - tập lệnh này thực thi trước khi chuyển đổi diễn ra. Nếu tập lệnh trả về khác 0, nó sẽ buộc chuyển đổi không thành công. Nếu tập lệnh được xác định nhưng không được tìm thấy, trình chuyển đổi sẽ bị hủy bỏ. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
- Replication_post_switchover_script - tập lệnh này thực thi sau khi chuyển đổi diễn ra. Nếu tập lệnh trả về khác 0, một Cảnh báo sẽ được ghi vào nhật ký công việc. Tập lệnh phải có thể truy cập được trên bộ điều khiển và có thể thực thi được.
Như bạn có thể thấy, các hook bao gồm hầu hết các trường hợp mà bạn có thể muốn thực hiện một số hành động - trước và sau khi chuyển đổi, trước và sau khi chuyển đổi dự phòng, khi reslave không thành công hoặc khi chuyển đổi dự phòng không thành công. Tất cả các tập lệnh được gọi với bốn đối số (có thể có hoặc có thể không được xử lý trong tập lệnh, không bắt buộc tập lệnh phải sử dụng tất cả chúng):tất cả các máy chủ, tên máy chủ (hoặc IP - như nó được định nghĩa trong ClusterControl) của cái chính cũ, tên máy chủ (hoặc IP - như nó được định nghĩa trong ClusterControl) của ứng viên chính và cái thứ tư, tất cả các bản sao của cái cũ. Những tùy chọn đó sẽ giúp bạn có thể xử lý phần lớn các trường hợp.
Tất cả các hook đó phải được xác định trong một tệp cấu hình cho một cụm nhất định (/etc/cmon.d/cmon_X.cnf trong đó X là id của cụm). Một ví dụ có thể giống như sau:
replication_pre_failover_script=/usr/bin/stonith.py
replication_post_failover_script=/usr/bin/vipmove.shTất nhiên, các tập lệnh được gọi phải có thể thực thi được, nếu không cmon sẽ không thể thực thi chúng. Bây giờ chúng ta hãy dành một chút thời gian và thực hiện quá trình chuyển đổi dự phòng trong ClusterControl và xem khi nào các tập lệnh bên ngoài được thực thi.
Quá trình chuyển đổi dự phòng trong ClusterControl
Chúng tôi đã xác định tất cả các hook có sẵn:
replication_onfail_failover_script=/tmp/1.sh
replication_pre_failover_script=/tmp/2.sh
replication_post_failover_script=/tmp/3.sh
replication_post_unsuccessful_failover_script=/tmp/4.sh
replication_failed_reslave_failover_script=/tmp/5.sh
replication_pre_switchover_script=/tmp/6.sh
replication_post_switchover_script=/tmp/7.shSau đó, bạn phải khởi động lại quá trình cmon. Sau khi hoàn tất, chúng tôi đã sẵn sàng để kiểm tra chuyển đổi dự phòng. Cấu trúc liên kết ban đầu trông giống như sau:
Một tổng thể đã bị giết và quá trình chuyển đổi dự phòng bắt đầu. Xin lưu ý, các mục nhật ký gần đây hơn nằm ở trên cùng, vì vậy bạn muốn theo dõi quá trình chuyển đổi dự phòng từ dưới lên trên.
Như bạn có thể thấy, ngay sau khi công việc chuyển đổi dự phòng bắt đầu, nó sẽ kích hoạt hook ‘replication_onfail_failover_script’. Sau đó, tất cả các máy chủ có thể truy cập được đánh dấu là read_only và ClusterControl cố gắng ngăn máy chủ cũ chạy.
Tiếp theo, ứng cử viên chính được chọn, kiểm tra sự tỉnh táo được thực hiện. Sau khi được xác nhận, ứng viên chính có thể được sử dụng làm ứng dụng chính mới, ‘replication_pre_failover_script’ sẽ được thực thi.
Nhiều lần kiểm tra hơn được thực hiện, các bản sao bị dừng và hoàn thành bản chính mới. Cuối cùng, sau khi hoàn thành chuyển đổi dự phòng, một hook cuối cùng, ‘replication_post_failover_script’, được kích hoạt.
Khi nào thì Hooks có thể hữu ích?
Trong phần này, chúng ta sẽ xem xét một số trường hợp ví dụ mà việc triển khai các tập lệnh bên ngoài có thể là một ý tưởng hay. Chúng tôi sẽ không đi sâu vào bất kỳ chi tiết nào vì chúng liên quan quá chặt chẽ đến một môi trường cụ thể. Đây sẽ là danh sách nhiều đề xuất hơn có thể hữu ích để triển khai.
Tập lệnh STONITH
Shoot The Other Node In The Head (STONITH) là một quá trình đảm bảo rằng chủ cũ, đã chết, sẽ vẫn chết (và vâng .. chúng tôi không thích thây ma đi lang thang trong cơ sở hạ tầng của chúng tôi). Điều cuối cùng bạn có thể muốn là có một chủ cũ không phản hồi, sau đó trực tuyến trở lại và kết quả là bạn sẽ có hai chủ có thể ghi. Bạn có thể thực hiện các biện pháp phòng ngừa để đảm bảo rằng bản chính cũ sẽ không được sử dụng ngay cả khi hiển thị lại và an toàn hơn khi nó ở chế độ ngoại tuyến. Cách làm thế nào để đảm bảo nó sẽ khác nhau giữa các môi trường. Do đó, rất có thể, sẽ không có hỗ trợ tích hợp cho STONITH trong công cụ chuyển đổi dự phòng. Tùy thuộc vào môi trường, bạn có thể muốn thực thi lệnh CLI sẽ dừng (và thậm chí xóa) một máy ảo mà máy chủ cũ đang chạy. Nếu bạn có thiết lập tại chỗ, bạn có thể có nhiều quyền kiểm soát hơn đối với phần cứng. Có thể sử dụng một số loại quản lý từ xa (Đèn tắt tích hợp hoặc một số truy cập từ xa khác vào máy chủ). Bạn cũng có thể có quyền truy cập vào các ổ cắm điện có thể quản lý được và tắt nguồn ở một trong số chúng để đảm bảo máy chủ sẽ không bao giờ khởi động lại nếu không có sự can thiệp của con người.
Khám phá dịch vụ
Chúng tôi đã đề cập một chút về khám phá dịch vụ. Có nhiều cách người ta có thể lưu trữ thông tin về cấu trúc liên kết sao chép và phát hiện máy chủ nào là máy chủ. Chắc chắn, một trong những lựa chọn phổ biến hơn là sử dụng etcd hoặc Consul để lưu trữ dữ liệu về cấu trúc liên kết hiện tại. Với nó, một ứng dụng hoặc proxy có thể dựa vào dữ liệu này để gửi lưu lượng đến đúng nút. ClusterControl (giống như hầu hết các công cụ hỗ trợ xử lý chuyển đổi dự phòng) không tích hợp trực tiếp với v.v.d hoặc Consul. Nhiệm vụ cập nhật dữ liệu cấu trúc liên kết là của người dùng. Cô ấy có thể sử dụng các hook như replication_post_failover_script hoặc replication_post_switchover_script để gọi một số script và thực hiện các thay đổi cần thiết. Một giải pháp khá phổ biến khác là sử dụng DNS để hướng lưu lượng truy cập đến các phiên bản chính xác. Nếu bạn giữ cho Thời gian tồn tại của bản ghi DNS ở mức thấp, bạn sẽ có thể xác định miền, miền này sẽ trỏ đến miền chính của bạn (tức là write.cluster1.example.com). Điều này yêu cầu thay đổi bản ghi DNS và một lần nữa, các hook như replication_post_failover_script hoặc replication_post_switchover_script có thể thực sự hữu ích để thực hiện các sửa đổi cần thiết sau khi xảy ra chuyển đổi dự phòng.
Cấu hình lại proxy
Mỗi máy chủ proxy được sử dụng phải gửi lưu lượng truy cập đến các phiên bản chính xác. Tùy thuộc vào chính proxy, cách phát hiện chính được thực hiện có thể được mã hóa cứng (một phần) hoặc có thể tùy thuộc vào người dùng để xác định bất kỳ thứ gì họ thích. Cơ chế chuyển đổi dự phòng ClusterControl được thiết kế theo cách nó tích hợp tốt với các proxy mà nó đã triển khai và định cấu hình. Vẫn có thể xảy ra trường hợp có những proxy chưa được cài đặt bởi ClusterControl và chúng yêu cầu một số thao tác thủ công diễn ra trong khi thực hiện chuyển đổi dự phòng. Những proxy như vậy cũng có thể được tích hợp với quy trình chuyển đổi dự phòng ClusterControl thông qua các tập lệnh và móc bên ngoài như replication_post_failover_script hoặc replication_post_switchover_script.
Ghi nhật ký bổ sung
Có thể xảy ra trường hợp bạn muốn thu thập dữ liệu của quá trình chuyển đổi dự phòng cho mục đích gỡ lỗi. ClusterControl có nhiều bản in để đảm bảo có thể làm theo quy trình và tìm ra điều gì đã xảy ra và tại sao. Vẫn có thể xảy ra trường hợp bạn muốn thu thập thêm một số thông tin tùy chỉnh. Về cơ bản, tất cả các hook đều có thể được sử dụng ở đây - bạn có thể thu thập trạng thái ban đầu, trước khi chuyển đổi dự phòng, bạn có thể theo dõi trạng thái của môi trường ở tất cả các giai đoạn của chuyển đổi dự phòng.
