С выходом Nutanix Community Edition 2.0 на форумах стал часто появляться один и тот же вопрос – при попытке сформировать кластер из 3-4 узлов, которые развернуты в виде виртуальных машин на VMware vSphere, кластер не собирается и «висит» на попытке запуска службы Medusa на двух узлах. При этом на одном из узлов служба запущена.
Иногда можно встретить ошибку следующего характера (особенно, если попытаться остановить\запустить кластер вручную):
Medusa ERROR: Cassandra gossip failedДалее детальнее про проблему и ее решение.
Для начала посмотрим, как выглядит проблема. При создании кластера, процедура зависает на попытке запустить кластерные службы:
Waiting on 192.168.100.221 (Up) to start: Medusa DynamicRingChanger Pithos InsightsDB Athena Mercury Mantle Stargate InsightsDataTransfer Ergon GoErgon Cerebro Chronos Curator Prism Hera CIM AlertManager Arithmos Catalog Acropolis Uhura NutanixGuest Tools MinervaCVM ClusterConfig APLOSEngine APLOS PlacementSolver Lazan Polaris Delphi Security Flow Anduril XTrim ClusterHealth
Waiting on 192.168.100.222 (Up, ZeusLeader) to start: DynamicRingChanger Pithos InsightsDB Athena Mercury Mantle Stargate InsightsDataTransfer Ergon GoErgon Cerebro Chronos Curator Prism Hera CIM AlertManager Arithmos Catalog Acropolis Uhura NutanixGuestTools MinervaCVM ClusterConfig APLOSEngine APLOS PlacementSolver Lazan Polaris Delphi Security Flow Anduril XTrim ClusterHealth
Waiting on 192.168.100.223 (Up) to start: Medusa DynamicRingChanger Pithos InsightsDB Athena Mercury Mantle Stargate InsightsDataTransfer Ergon GoErgon Cerebro Chronos Curator Prism Hera CIM AlertManager Arithmos Catalog Acropolis Uhura NutanixGuestTools MinervaCVM ClusterConfig APLOSEngine APLOS PlacementSolver Lazan Polaris Delphi Security Flow Anduril XTrim ClusterHealthВ данном случае видно, что на одном из трех узлов служба Medusa запущена, на двух других она пытается запуститься.
Если в этот момент посмотреть статус кластера, он будет выглядеть следующим образом:
CVM: 192.168.100.221 Up
Zeus UP [12587, 12730, 12731, 12743, 12754, 12772]
Scavenger UP [15573, 15679, 15680, 15681]
Xmount UP [15570, 15654, 15655, 15697]
SysStatCollector UP [18337, 18402, 18403, 18404]
IkatProxy UP [18816, 18885, 18886, 18887]
IkatControlPlane UP [19124, 19181, 19182, 19184]
SSLTerminator UP [19206, 19425, 19426]
SecureFileSync UP [19241, 19506, 19507, 19508]
Medusa DOWN []
DynamicRingChanger DOWN []
CVM: 192.168.100.222 Up, ZeusLeader
Zeus UP [5305, 5353, 5354, 5355, 5364, 5382]
Scavenger UP [7764, 8082, 8083, 8084]
Xmount UP [7761, 8043, 8044, 8069]
SysStatCollector UP [10674, 10739, 10740, 10741]
IkatProxy UP [11153, 11226, 11227, 11228]
IkatControlPlane UP [11451, 11538, 11539, 11547]
SSLTerminator UP [11465, 11613, 11614]
SecureFileSync UP [11622, 11698, 11699, 11700]
Medusa UP [11994, 12062, 12063, 12065, 12317]
DynamicRingChanger DOWN []
Pithos DOWN []
CVM: 192.168.100.223 Up
Zeus UP [11866, 11914, 11915, 11916, 11926, 11943]
Scavenger UP [15261, 15364, 15365, 15366]
Xmount UP [15258, 15337, 15338, 15388]
SysStatCollector UP [17819, 17884, 17885, 17886]
IkatProxy UP [18342, 18418, 18419, 18420]
IkatControlPlane UP [18833, 18895, 18896, 18897]
SSLTerminator UP [18847, 18941, 18942]
SecureFileSync UP [18952, 19041, 19042, 19043]
Medusa DOWN []
DynamicRingChanger DOWN []
В логах на CVM можно встретить следующие записи:
2023-03-26 11:15:36,254Z ERROR Thread-6 configuration_validator.py:442 Duplicate Serial number discovered for serial drive-scsi0-0-0-1
2023-03-26 11:15:36,255Z ERROR Thread-6 configuration_validator.py:442 Duplicate Serial number discovered for serial drive-scsi0-0-0-0
2023-03-26 11:16:00,151Z ERROR Thread-5 disk_manager.py:2992 Disk /dev/sda with serial drive-scsi0-0-0-0 is not mounted in hades proto, skipping the disk
2023-03-26 11:16:00,716Z ERROR Thread-5 disk_manager.py:2992 Disk /dev/sdb with serial drive-scsi0-0-0-1 is not mounted in hades proto, skipping the diskСмущают следующие строки:
Duplicate Serial number discovered for serial drive-scsi0-0-0-1
Duplicate Serial number discovered for serial drive-scsi0-0-0-0Посмотрим список дисков на каждой из нод с CVM:
nutanix@CVM1:~$ list_disks
Slot Disk Model Serial Size
0 -------- ------------ ----------------- ------
1 /dev/sdb Virtual disk drive-scsi0-0-0-1 214 GB
2 /dev/sda Virtual disk drive-scsi0-0-0-0 429 GB
nutanix@CVM2:~$ list_disks
Slot Disk Model Serial Size
0 -------- ------------ ----------------- ------
1 /dev/sdb Virtual disk drive-scsi0-0-0-1 214 GB
2 /dev/sda Virtual disk drive-scsi0-0-0-0 429 GB
nutanix@CVM3:~$ list_disks
Slot Disk Model Serial Size
0 -------- ------------ ----------------- ------
1 /dev/sdb Virtual disk drive-scsi0-0-0-1 214 GB
2 /dev/sda Virtual disk drive-scsi0-0-0-0 429 GBКак можно заметить, на всех нодах у нас одинаковые «серийные номера дисков», что неверно. Очевидно, это и является причиной проблемы.
Заметить проблему можно еще на этапе инсталляции кластера, если обратить внимание на серийные номера дисков:
При типичном создании виртуальных машин серийных номеров не видно вообще.
Проблема в том, что по умолчанию vSphere не передает в гостевую ОС UUID выделенных ей дисков.
Решение достаточное просто – необходимо добавить параметр disk.EnableUUID = “TRUE” в конфигурационный файл всех VM с Nutanix CE. Сделать это можно в меню Advanced Parameters виртуальной машины:
В итоге, этот параметр должен быть добавлен для всех VM:
Теперь необходимо переустановить CE. Заметить изменения можно будет сразу:
Серийные номера дисков отображаются корректно, и они различны на всех узлах будущего кластера. Этот же результат подтвердит команда list_disks.
Теперь проблем с конфигурацией кластера быть не должно (по крайней мере с запуском Medusa).
Обратите внимание, что данный момент важен не только для Nutanix Community Edition. Многие кластерные приложения, например, Oracle Real Application Cluster, так же хотят знать о UUID дисков и без указания disk.EnableUUID = “TRUE” может возникнуть проблема на этапе формирования таких кластеров.
