En RHV, KVM Host usa Sanlock para detectar la conectividad con el dominio de almacenamiento. Cuando Sanlock se habilita, abrirá el demonio wdmd (demonio de multiplexación de vigilancia) y enviará keepalive con cierto latido. sanlock IO al almacenamiento no se completa dentro de un tiempo fijo, sanlock deja de enviar keepalive a wdmd. Cuando se agote el tiempo de espera, el demonio wdmd que controla /dev/watchdog registrará errores, advirtiendo que el perro guardián no se mantiene vivo, y pronto caducará y luego se activará y reiniciará el host KVM.
$ systemctl status sanlock ● sanlock.service - Shared Storage Lease Manager Loaded: loaded (/usr/lib/systemd/system/sanlock.service; disabled; vendor preset: disabled) Active: active (running) since Mon 2020-07-13 15:03:26 NZST; 1 months 19 days ago Process: 1041 ExecStart=/usr/sbin/sanlock daemon (code=exited, status=0/SUCCESS) Main PID: 1044 (sanlock) Tasks: 7 Memory: 18.6M CGroup: /system.slice/sanlock.service ├─1044 /usr/sbin/sanlock daemon └─1045 /usr/sbin/sanlock daemon Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
$ systemctl status wdmd ● wdmd.service - Watchdog Multiplexing Daemon Loaded: loaded (/usr/lib/systemd/system/wdmd.service; disabled; vendor preset: disabled) Active: active (running) since Mon 2020-07-13 15:03:26 NZST; 1 months 19 days ago Process: 1131 ExecStart=/usr/sbin/wdmd (code=exited, status=0/SUCCESS) Process: 1112 ExecStartPre=/lib/systemd/systemd-wdmd watchdog-check (code=exited, status=0/SUCCESS) Main PID: 1133 (wdmd) Tasks: 1 Memory: 2.3M CGroup: /system.slice/wdmd.service └─1133 /usr/sbin/wdmd Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
El demonio sanlock escribe continuamente en el almacenamiento a un intervalo fijo para renovar sus arrendamientos. Sanlock marcará el host KVM como DESCONOCIDO, GRATUITO, EN VIVO, CON FALLA y MUERTO según el resultado de sanlock IO al almacenamiento.
desconocido:
El host KVM tiene un contrato de arrendamiento del almacenamiento, pero el bloqueo de clúster no puede determinar si el host está vivo o muerto todavía. Por lo general, duraría de 10 a 20 segundos, pero es posible que esto persista hasta 80 segundos antes de que el host KVM se considere activo o falle.
Gratis:
No hay concesión para este ID de host.
En vivo:
El host KVM ha renovado su arrendamiento en los últimos 80 segundos. Es posible que esté renovando su contrato de arrendamiento ahora o no, solo podemos saberlo volviendo a verificar más tarde.
Fallo:
El anfitrión no ha renovado su arrendamiento por 80 segundos. Duraría 60 segundos antes de que el huésped se considere muerto. Cuando el estado del host KVM se marca como 'Error', verá los registros relacionados a continuación:
2020-08-31 21:35:01 1665117 [1044]: s1 check_our_lease warning 72 last_success 1665045 2020-08-31 21:35:02 1665118 [1044]: s1 check_our_lease warning 73 last_success 1665045 2020-08-31 21:35:03 1665119 [1044]: s1 check_our_lease warning 74 last_success 1665045 2020-08-31 21:35:04 1665120 [1044]: s1 check_our_lease warning 75 last_success 1665045 2020-08-31 21:35:05 1665121 [1044]: s1 check_our_lease warning 76 last_success 1665045 2020-08-31 21:35:06 1665122 [1044]: s1 check_our_lease warning 77 last_success 1665045 2020-08-31 21:35:07 1665123 [1044]: s1 check_our_lease warning 78 last_success 1665045 2020-08-31 21:35:08 1665124 [1044]: s1 check_our_lease warning 79 last_success 1665045 2020-08-31 21:35:09 1665125 [1044]: s1 check_our_lease failed 80 2020-08-31 21:35:10 1665125 [1044]: s1 all pids clear 2020-08-31 21:35:21 1665137 [3859]: 8d627013 aio timeout RD 0x7f56e00009b0:0x7f56e00009c0:0x7f56f0299000 ioto 10 to_count 4 2020-08-31 21:35:21 1665137 [3859]: s1 delta_renew read timeout 10 sec offset 0 /rhev/data-center/mnt/[mountpoint]/[SD_UUID]/dom_md/ids 2020-08-31 21:35:21 1665137 [3859]: s1 renewal error -202 delta_length 20 last_success 1665045
Muerto:
El anfitrión no ha renovado su arrendamiento por 140 segundos.
Si sanlock IO to storage no se completa dentro de un tiempo fijo, el demonio sanlock entrará en recuperación. La recuperación comienza cuando el daemon sanlock intenta eliminar (SIGTERM) cualquier pid que use concesiones en el almacenamiento afectado. Si algún pid no sale después de 10 SIGTERM durante 10 segundos, sanlock intentará matar (SIGKILL). Si los pids aún no salen dentro de un tiempo fijo, el perro guardián se activará y reiniciará el host. Si todos los pid salen dentro del tiempo necesario, el perro guardián se renovará y no se activará.