Heartbeat phần mềm thịt STONITH trên nhân hoảng loạn

Tôi có một cụm hai nút với nhịp tim và DRBD quản lý tài nguyên mysql. Việc chuyển đổi dự phòng hoạt động rất tốt nếu tôi tạm dừng chính, khởi động lại hoặc ngắt kết nối mạng.

Tuy nhiên, nếu sơ cấp bị hoảng loạn hạt nhân (mô phỏng bằng cách chạy echo c > /proc/sysrq-trigger), thì thứ cấp không tiếp quản tài nguyên.

Đây là bản ghi nhịp tim trên thứ cấp trông như thế nào:

Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead
Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead.
Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device]
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10.
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.

Có ai có ý tưởng tại sao thứ cấp không tiếp quản trong tình huống này? Thông thường failover hoạt động rất tốt, nhưng tôi đang cố gắng mô phỏng hạt nhân hoảng loạn trên nút chính.

EDIT: Đây là cấu hình nhịp tim của tôi, ha.cf

# /etc/ha.d/ha.cf

logfile /var/log/ha-log

keepalive 1

deadtime 10

udpport 695

ucast eth0 rad11
auto_failback on
stonith_host rad10 meatware rad11
stonith_host rad11 meatware rad10
node rad10 rad11

Khi các nút cụm mất liên lạc với nhau, để tránh kịch bản phân tách não , trong đó cả hai nút nghĩ rằng chúng là chính và cố gắng chạy đồng thời tài nguyên được chia sẻ với thảm họa tiềm ẩn (đây đặc biệt là một vấn đề lớn trong hai cụm nút , bởi vì ai có số đại biểu nếu cả hai nút có một phiếu bầu cho nhau?), vì vậy để giảm thiểu điều này, một số cụm thực hiện các hình thức đấu kiếm khác nhau.

Trên trang wiki linux-ha:

Đấu kiếm là quá trình khóa tài nguyên khỏi một nút có trạng thái không chắc chắn.

Có một loạt các kỹ thuật đấu kiếm có sẵn.

Người ta có thể hoặc các hàng rào nút - sử dụng Hàng rào nút, hoặc hàng rào tài nguyên bằng cách sử dụng Tài nguyên hàng rào. Một số loại tài nguyên là Tài nguyên tự tạo hàng rào và một số loại không bị hỏng do sử dụng đồng thời và hoàn toàn không yêu cầu phải tạo hàng rào.

Khi một nút tạo ra sự tắt máy sạch, nó sẽ rời khỏi cụm và do đó, các nút khác sẽ biết những gì đang xảy ra và do đó sẽ tiếp nhận bất kỳ dịch vụ nào mà nút có thể đang chạy và sau đó tiếp tục. Khi nút thay vì rời khỏi cụm độc đáo sẽ bị hoảng loạn hạt nhân, các thành viên cụm khác sẽ không biết trạng thái của nút khác. Nó sẽ "không chắc chắn" theo quan điểm của họ, vì vậy thay vào đó họ sẽ thực hiện các hành động "đấu kiếm" được cấu hình, trong trường hợp STONITH có nghĩa là cố gắng loại bỏ nút thực sự bằng lực từ cụm (bằng cách đạp xe, v.v.).

Nhìn vào nhật ký của bạn, có vẻ như cơ chế meatware STONITH được chọn cho cấu hình cụm của bạn. Giống như tên cho thấy, nó ngụ ý cấp nguồn theo cách thủ công cho nút khác và sau đó chạy lệnh đã nói. Từ tài liệu :

đồ ăn thịt

Tên lạ và một khái niệm đơn giản. đồ thịt cần có sự giúp đỡ của con người để vận hành. Bất cứ khi nào được gọi, phần mềm thịt ghi lại thông báo mức độ nghiêm trọng CRIT sẽ hiển thị trên bảng điều khiển của nút. Sau đó, người vận hành phải đảm bảo rằng nút bị hỏng và đưa ra lệnh Meatclient (8) để thông báo cho phần mềm thịt rằng bạn có thể nói với cụm rằng nó có thể coi nút đó đã chết. Xem README.meatware để biết thêm thông tin.

Có nhiều cách khác để cấu hình hàng rào. Khi tạo một cụm, tôi thường nhận được hai công tắc APC cho PSU: s và cấu hình "APC faging" ( stonith -t apcmaster -h). Theo cách đó, khi một nút bị lỗi, nút kia sẽ khởi động lại một lần khởi động lại cứng bằng cách khởi động lại thành viên bị lỗi thông qua việc đăng nhập vào giao diện APC và gửi lệnh tắt / khởi động lại trên các khe PSU được kết nối (tôi nhận được hai để tránh một điểm lỗi duy nhất) .