Как мне восстановить после частичного сбоя Ovirt и GlusterFS?

Я управляю 3-узловым кластером Ovirt 4.3.7 с размещенным механизмом; узлы также являются узлами glusterfs. Системы:

• ovirt1 (узел на 192.168.40.193)
• ovirt2 (узел на 192.168.40.194)
• ovirt3 (узел на 192.168.40.195)
• ovirt-engine (двигатель на 192.168.40.196)

Службы ovirt-ha-agent и ovirt-ha-broker постоянно перезапускаются на ovirt1 и ovirt3, и это не кажется нормальным (первое уведомление, которое мы получили этой проблемы были логи заполнения этих сервисов в этих системах).

Все индикаторы консолей GUI показывают, что overt-engine работает на ovirt3. Я попытался перенести overt-engine на ovirt2, но без дальнейших объяснений потерпел неудачу.

Пользователи могут без проблем создавать, запускать и останавливать виртуальные машины на всех трех узлах.

Я вижу следующий вывод gluster-eventaapi status и hosted-engine --vm-status на каждом из узлов:

ovirt1:

[root@ovirt1 ~]# gluster-eventsapi status
Webhooks: 
http://ovirt-engine.low.mdds.tcs-sec.com:80/ovirt-engine/services/glusterevents

+---------------+-------------+-----------------------+
|      NODE     | NODE STATUS | GLUSTEREVENTSD STATUS |
+---------------+-------------+-----------------------+
| 192.168.5.194 |          UP |                    OK |
| 192.168.5.195 |          UP |                    OK |
|   localhost   |          UP |                    OK |
+---------------+-------------+-----------------------+
[root@ovirt1 ~]# hosted-engine --vm-status
The hosted engine configuration has not been retrieved from shared storage. Please ensure that ovirt-ha-agent is running and the storage server is reachable.

ovirt2 :

[root@ovirt2 ~]# gluster-eventsapi status
Webhooks: 
http://ovirt-engine.low.mdds.tcs-sec.com:80/ovirt-engine/services/glusterevents

+---------------+-------------+-----------------------+
|      NODE     | NODE STATUS | GLUSTEREVENTSD STATUS |
+---------------+-------------+-----------------------+
| 192.168.5.195 |          UP |                    OK |
| 192.168.5.193 |          UP |                    OK |
|   localhost   |          UP |                    OK |
+---------------+-------------+-----------------------+
[root@ovirt2 ~]# hosted-engine --vm-status


--== Host ovirt2.low.mdds.tcs-sec.com (id: 1) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : ovirt2.low.mdds.tcs-sec.com
Host ID                            : 1
Engine status                      : {"reason": "vm not running on this host", "health": "bad", "vm": "down_unexpected", "detail": "unknown"}
Score                              : 0
stopped                            : False
Local maintenance                  : False
crc32                              : e564d06b
local_conf_timestamp               : 9753700
Host timestamp                     : 9753700
Extra metadata (valid at timestamp):
    metadata_parse_version=1
    metadata_feature_version=1
    timestamp=9753700 (Wed Mar 25 17:45:50 2020)
    host-id=1
    score=0
    vm_conf_refresh_time=9753700 (Wed Mar 25 17:45:50 2020)
    conf_on_shared_storage=True
    maintenance=False
    state=EngineUnexpectedlyDown
    stopped=False
    timeout=Thu Apr 23 21:29:10 1970


--== Host ovirt3.low.mdds.tcs-sec.com (id: 3) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : False
Hostname                           : ovirt3.low.mdds.tcs-sec.com
Host ID                            : 3
Engine status                      : unknown stale-data
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : 620c8566
local_conf_timestamp               : 1208310
Host timestamp                     : 1208310
Extra metadata (valid at timestamp):
    metadata_parse_version=1
    metadata_feature_version=1
    timestamp=1208310 (Mon Dec 16 21:14:24 2019)
    host-id=3
    score=3400
    vm_conf_refresh_time=1208310 (Mon Dec 16 21:14:24 2019)
    conf_on_shared_storage=True
    maintenance=False
    state=GlobalMaintenance
    stopped=False

ovirt3:

[root@ovirt3 ~]# gluster-eventsapi status
Webhooks: 
http://ovirt-engine.low.mdds.tcs-sec.com:80/ovirt-engine/services/glusterevents

+---------------+-------------+-----------------------+
|      NODE     | NODE STATUS | GLUSTEREVENTSD STATUS |
+---------------+-------------+-----------------------+
| 192.168.5.193 |        DOWN |           NOT OK: N/A |
| 192.168.5.194 |          UP |                    OK |
|   localhost   |          UP |                    OK |
+---------------+-------------+-----------------------+
[root@ovirt3 ~]# hosted-engine --vm-status
The hosted engine configuration has not been retrieved from shared storage. Please ensure that ovirt-ha-agent is running and the storage server is reachable.

Я предпринял следующие шаги:

1. обнаружил, что журналы для ovirt-ha-agent и ovirt-ha-broker службы некорректно вращаются на узлах ovirt1 и ovirt3; журналы показывают одинаковый отказ на обоих узлах. Broker.log содержит этот оператор, который часто повторяется:

MainThread::WARNING::2020-03-25 18:03:28,846::storage_broker::97::ovirt_hosted_engine_ha.broker.storage_broker.StorageBroker::(__init__) Can't connect vdsm storage: [Errno 5] Input/output error: '/rhev/data-center/mnt/glusterSD/ovirt2:_engine/182a4a94-743f-4941-89c1-dc2008ae1cf5/ha_agent/hosted-engine.lockspace'

2. обнаружил, что документация RHEV предлагает запустить hosted-engine --vm-status , чтобы понять проблему; этот вывод (см. выше) предполагает, что ovirt1 не является полностью частью кластера.
3. Я спросил на форуме Овирта вчера утром, но, поскольку я здесь новенький, мой вопрос требует рассмотрения модератором, а этого еще не произошло (если не все пользователи этого кластера внезапно начали работать из дома, и внезапно зависящее от этого, я бы не стал беспокоиться о том, чтобы ждать несколько дней).

Как мне выйти из этой ситуации? (Я думаю, мне нужно сначала восстановить что-то в кластере glusterfs, но я не могу найти подсказку или у меня нет языка для формирования правильного запроса.)

ОБНОВЛЕНИЕ: после перезапуска glusterd на ovirt3, кластер glusterfs выглядит исправным, но без изменений в поведении служб ovirt.