Địa chỉ IP ảo là địa chỉ IP không tương ứng với giao diện mạng vật lý thực tế. Nó nổi giữa nhiều giao diện mạng và chỉ một giao diện hoạt động sẽ giữ địa chỉ IP để chịu lỗi và tính di động. ClusterControl sử dụng Keepalived để cung cấp tích hợp địa chỉ IP ảo với bộ cân bằng tải cơ sở dữ liệu nhằm loại bỏ bất kỳ điểm lỗi nào (SPOF) ở cấp độ cân bằng tải.
Trong bài đăng trên blog này, chúng tôi sẽ chỉ cho bạn cách ClusterControl định cấu hình địa chỉ IP ảo và những gì bạn có thể mong đợi khi chuyển đổi dự phòng hoặc sao lưu dự phòng xảy ra. Hiểu được hành vi này là rất quan trọng để giảm thiểu mọi gián đoạn dịch vụ và làm trơn tru các hoạt động bảo trì thỉnh thoảng cần được thực hiện.
Yêu cầu
Có một số yêu cầu để chạy Keepalived trong mạng của bạn:
- Giao thức IP 112 (Giao thức dự phòng bộ định tuyến ảo - VRRP) phải được hỗ trợ trong mạng. Một số mạng vô hiệu hóa hỗ trợ VRRP, đặc biệt là giao tiếp giữa các VLAN. Vui lòng xác minh điều này với quản trị viên mạng.
- Nếu bạn sử dụng multicast, mạng phải hỗ trợ yêu cầu multicast (sử dụng ip a | grep -i multicast). Nếu không, bạn có thể sử dụng unicast qua unicast_src_ip và unicast_peer tùy chọn. Việc sử dụng đa hướng rất hữu ích khi bạn có môi trường động như môi trường đám mây hoặc khi việc gán IP được thực hiện thông qua DHCP.
- Một tập hợp các bản sao VRRP phải sử dụng một virtual_router_id duy nhất giá trị đó không thể được chia sẻ giữa các trường hợp khác. Nếu không, bạn sẽ thấy các gói không có thật và có khả năng sẽ phá vỡ công tắc sao lưu chính.
- Nếu bạn đang chạy trên môi trường đám mây như AWS, bạn có thể cần sử dụng tập lệnh bên ngoài (gợi ý:sử dụng tùy chọn "thông báo") để phân tách và liên kết địa chỉ IP ảo (Elastic IP) để nó được nhận dạng và có thể định tuyến bởi bộ định tuyến.
Triển khai Keepalived
Để cài đặt Keepalived thông qua ClusterControl, bạn cần có hai hoặc nhiều bộ cân bằng tải được cài đặt hoặc nhập vào ClusterControl. Đối với việc sử dụng sản xuất, chúng tôi thực sự khuyên bạn nên chạy phần mềm cân bằng tải trên một máy chủ độc lập và không được đặt cùng với các nút cơ sở dữ liệu của bạn.
Sau khi bạn có ít nhất hai bộ cân bằng tải do ClusterControl quản lý, để cài đặt Keepalived và kích hoạt địa chỉ IP ảo, chỉ cần truy cập ClusterControl -> chọn cụm -> Quản lý -> Load Balancer -> Keepalived:
Hầu hết các trường đều tự giải thích. Bạn có thể triển khai một tập hợp Keepalived mới hoặc nhập các phiên bản Keepalived hiện có. Các trường quan trọng bao gồm địa chỉ IP ảo thực và giao diện mạng nơi địa chỉ IP ảo sẽ tồn tại. Nếu máy chủ đang sử dụng hai tên giao diện khác nhau, hãy chỉ định tên giao diện của máy chủ Keepalived 1, sau đó sửa đổi thủ công tệp cấu hình trên Keepalived 2 với tên giao diện chính xác sau này.
Phiên bản VRRP
Tại thời điểm viết bài hiện tại, ClusterControl v1.5.1 cài đặt Keepalived v1.3.5 (tùy thuộc vào hệ điều hành máy chủ) và sau đây là những gì được định cấu hình cho phiên bản VRRP:
vrrp_instance VI_PROXYSQL {
interface eth0 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 100
unicast_src_ip 10.0.0.246
unicast_peer {
10.0.0.204
}
virtual_ipaddress {
10.0.0.100 # the virtual IP
}
track_script {
chk_proxysql
}
# notify /usr/local/bin/notify_keepalived.sh
}ClusterControl định cấu hình cá thể VRRP để giao tiếp thông qua unicast. Với unicast, chúng ta phải xác định tất cả các đồng nghiệp unicast của các nút Keepalived khác. Nó ít năng động hơn nhưng hoạt động hầu hết thời gian. Với multicast, bạn có thể loại bỏ các dòng đó (unicast_ *) và dựa vào địa chỉ IP multicast để phát hiện và xem xét máy chủ. Nó đơn giản hơn nhưng nó thường bị chặn bởi các quản trị viên mạng.
Phần tiếp theo là địa chỉ IP ảo. Bạn có thể chỉ định nhiều địa chỉ IP ảo cho mỗi phiên bản VRRP, được phân tách bằng dòng mới. Đồng thời, cân bằng tải trong HAProxy / ProxySQL và Keepalived cũng yêu cầu khả năng liên kết với một địa chỉ IP phi địa phương, nghĩa là nó không được gán cho một thiết bị trên hệ thống cục bộ. Điều này cho phép một phiên bản cân bằng tải đang chạy liên kết với một IP không phải là địa phương để chuyển đổi dự phòng. Do đó, ClusterControl cũng định cấu hình net.ipv4.ip_nonlocal_bind =1 bên trong /etc/sysctl.conf.
Chỉ thị tiếp theo là track_script , nơi bạn có thể chỉ định tập lệnh cho quy trình kiểm tra sức khỏe được giải thích trong phần tiếp theo.
Kiểm tra sức khỏe
ClusterControl cấu hình Keepalived để thực hiện kiểm tra sức khỏe bằng cách kiểm tra mã lỗi được trả về bởi track_script. Trong tệp cấu hình Keepalived, theo mặc định, được đặt tại /etc/keepalived/keepalived.conf, bạn sẽ thấy một cái gì đó như sau:
track_script {
chk_proxysql
}Nơi nó gọi chk_proxysql chứa:
vrrp_script chk_proxysql {
script "killall -0 proxysql" # verify the pid existence
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}Lệnh "killall -0" trả về mã thoát 0 nếu có một quá trình được gọi là "proxysql" đang chạy trên máy chủ. Nếu không, cá thể sẽ phải tự giảm hạng và bắt đầu bắt đầu chuyển đổi dự phòng như được giải thích trong phần tiếp theo. Hãy lưu ý rằng Keepalived cũng hỗ trợ các thành phần Máy chủ ảo Linux (LVS) để thực hiện kiểm tra tình trạng, nơi nó cũng có khả năng cân bằng tải các kết nối TCP / IP, tương tự như HAProxy, nhưng điều đó nằm ngoài phạm vi của bài đăng blog này.
Mô phỏng chuyển đổi dự phòng
Đối với các thành phần VRRP, Keepalived sử dụng giao thức VRRP (giao thức IP 112) để giao tiếp giữa các phiên bản VRRP. Giá trị ưu tiên cao hơn của MASTER có nghĩa là master sẽ luôn có đặc quyền cao hơn để giữ địa chỉ IP ảo, trừ khi bạn định cấu hình phiên bản bằng "nopreempt". Hãy sử dụng một ví dụ để giải thích rõ hơn về quy trình chuyển đổi dự phòng và dự phòng. Hãy xem xét sơ đồ sau:
Có ba phiên bản ProxySQL phía trước ba nút MySQL Galera. Mọi máy chủ ProxySQL được định cấu hình với Keepalived as MASTER với số ưu tiên sau:
- ProxySQL1 - ưu tiên 101
- ProxySQL2 - mức độ ưu tiên 100
- ProxySQL3 - ưu tiên 99
Khi Keepalived được bắt đầu với tư cách là MASTER, trước tiên nó sẽ quảng cáo số ưu tiên cho các thành viên và sau đó tự liên kết với địa chỉ IP ảo. Trái ngược với trường hợp SAO LƯU, nó sẽ chỉ quan sát quảng cáo và chỉ gán địa chỉ IP ảo sau khi nó đã xác nhận rằng nó có thể tự nâng cấp lên MASTER.
Xin lưu ý rằng nếu bạn hủy quy trình "proxysql" hoặc "haproxy" theo cách thủ công thông qua lệnh kill, theo mặc định, trình quản lý quy trình systemd sẽ cố gắng khôi phục quy trình đang bị dừng một cách vô tội vạ. Ngoài ra, nếu bạn đã bật tính năng tự động khôi phục ClusterControl, ClusterControl sẽ luôn cố gắng bắt đầu quá trình ngay cả khi bạn thực hiện tắt sạch thông qua systemd (systemctl stop proxysql). Để mô phỏng lỗi một cách tốt nhất, chúng tôi khuyên người dùng nên tắt tính năng khôi phục tự động của ClusterControl hoặc chỉ cần tắt máy chủ ProxySQL để ngắt kết nối.
Nếu chúng tôi tắt ProxySQL1, địa chỉ IP ảo sẽ không được chuyển đến máy chủ tiếp theo có mức ưu tiên cao hơn tại thời điểm cụ thể đó (là ProxySQL2):
Bạn sẽ thấy thông tin sau trong nhật ký hệ thống của nút bị lỗi:
Feb 27 05:21:59 proxysql1 systemd: Unit proxysql.service entered failed state.
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: /usr/bin/killall -0 proxysql exited with status 1
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) failed
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 103 to 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 102, ours 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.Khi ở trên nút phụ, điều sau đã xảy ra:
Feb 27 05:22:00 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:22:01 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 avahi-daemon[346]: Registering new address record for 10.0.0.100 on eth0.IPv4.Trong trường hợp này, quá trình chuyển đổi dự phòng mất khoảng 3 giây, với thời gian chuyển đổi dự phòng tối đa sẽ là khoảng thời gian + Advert_int . Phía sau, điểm cuối cơ sở dữ liệu đã thay đổi và lưu lượng truy cập cơ sở dữ liệu đang được định tuyến qua ProxySQL2 mà ứng dụng không nhận thấy.
Khi ProxySQL1 trực tuyến trở lại, nó sẽ buộc phải tiến hành một cuộc bầu cử MASTER mới và tiếp quản địa chỉ IP do mức độ ưu tiên cao hơn:
Feb 27 05:38:34 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) succeeded
Feb 27 05:38:35 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 101 to 103
Feb 27 05:38:36 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:38:37 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 avahi-daemon[343]: Registering new address record for 10.0.0.100 on eth0.IPv4.Đồng thời, ProxySQL2 tự hạ cấp về trạng thái DỰ PHÒNG và xóa địa chỉ IP ảo khỏi giao diện mạng:
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 103, ours 102
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.
Feb 27 05:38:36 proxysql2 avahi-daemon[346]: Withdrawing address record for 10.0.0.100 on eth0.Tại thời điểm này, ProxySQL1 đã trực tuyến trở lại và trở thành bộ cân bằng tải hoạt động phục vụ các kết nối từ các ứng dụng và máy khách. VRRP thường sẽ xử lý máy chủ có mức độ ưu tiên thấp hơn khi máy chủ có mức độ ưu tiên cao hơn trực tuyến. Nếu bạn muốn giữ địa chỉ IP trên ProxySQL2 sau khi ProxySQL1 trực tuyến trở lại, hãy sử dụng tùy chọn "nopreempt". Điều này cho phép máy có mức ưu tiên thấp hơn duy trì vai trò chính, ngay cả khi máy có mức ưu tiên cao hơn trực tuyến trở lại. Tuy nhiên, để điều này hoạt động, trạng thái ban đầu của mục nhập này phải là DỰ PHÒNG. Nếu không, bạn sẽ thấy dòng sau:
Feb 27 05:50:33 proxysql2 Keepalived_vrrp[6298]: (VI_PROXYSQL): Warning - nopreempt will not work with initial state MASTERVì theo mặc định, ClusterControl định cấu hình tất cả các nút là MASTER, bạn phải định cấu hình tùy chọn cấu hình sau cho phiên bản VRRP tương ứng cho phù hợp:
vrrp_instance VI_PROXYSQL {
...
state BACKUP
nopreempt
...
}Khởi động lại quy trình Keepalived để tải những thay đổi này. Địa chỉ IP ảo sẽ chỉ bị lỗi đối với ProxySQL1 hoặc ProxySQL3 (tùy thuộc vào mức độ ưu tiên và nút nào khả dụng tại thời điểm đó) nếu quá trình kiểm tra tình trạng không thành công trên ProxySQL2. Trong nhiều trường hợp, chạy Keepalived trên hai máy chủ là đủ.
