Перейти к основному содержимому

Проверка оборудования и сети кластера

Требования к узлам, рекомендованные конфигурации кластера, требования к коммутации и сетевым сегментам относятся к vStack OS и описаны в её документации: «Требования к оборудованию и сети».

vStack Center показывает, какое оборудование кластер видит на самом деле: аппаратный инвентарь и диски приходят с узлов, а состояние агрегатов портов — от сетевой подсистемы. По этим данным после установки проверяют, что узлы собраны так, как планировали.

Где смотреть​

Заявленную конфигурацию удобно сверить с тем, что кластер реально видит, уже после установки. Аппаратная инвентаризация приходит с узлов и доступна и в веб-интерфейсе, и по API.

В веб-интерфейсе счётчики ядер и памяти по узлам лежат в разделе Server Nodes (Узлы): таблица со столбцами ID, Name, Health, CPU (Cores), RAM (GB). Диски и модули памяти конкретного узла — на странице узла, разделы Hardware и Disk props. Пулы слоя хранения — в разделе Storage Resources, таблица ZFS pools со столбцами GUID, Name, Health, Consuming, Scrubbing, Resilvering, Current node, Capacity (RAW).

pd-list​

Список физических дисков кластера. Показывает модель, размер и принадлежность пулу — по нему проверяют, что в пулах стоят только SSD или NVMe нужного объёма.

Доступ: только Cluster master. Требуется включённый feature flag feature.physical_disc_management.

{
"jsonrpc": "2.0",
"method": "pd-list",
"params": {
"auth": { "cookie": "..." }
},
"id": "1"
}

Ответ — карта по серийному номеру диска:

{
"jsonrpc": "2.0",
"id": "1",
"result": {
"code": 1,
"data": {
"S3Y1NX0M900XXX": {
"node_id": 1,
"device": "da0",
"model": "INTEL SSDSC2KB480G8",
"size": 480103981056,
"vdev_pool_name": "tank",
"pool_name": "tank",
"status": 0,
"lifecycle": 2,
"online_in_cluster": true
}
}
}
}

Ожидаемо: у каждого диска слоя хранения online_in_cluster равен true, а size не меньше требуемого объёма. Поле lifecycle показывает роль диска: 0 — свободен, 1 — размечен, 2 — в пуле, 3 — запасной, -1 — ошибка. Пока узел не сообщил роль, поле приходит пустым (null).

Ошибки: -403 — нет требуемой привилегии; -24201 — Physical disc management не включён.

node-hw-list​

Аппаратный инвентарь узлов по данным SMBIOS: производитель, число ядер, модули памяти. По нему сверяют модель процессора и объём памяти с требованиями.

Доступ: только Cluster master. Требуется включённый feature flag feature.hardware_inventory.

{
"jsonrpc": "2.0",
"method": "node-hw-list",
"params": {
"auth": { "cookie": "..." }
},
"id": "1"
}

Ответ — карта node_id → устройство → свойство:

{
"jsonrpc": "2.0",
"id": "1",
"result": {
"code": 1,
"data": {
"1": {
"0": {
"dev_id": 1,
"dev_name": "Processor",
"dev_serial": 0,
"3": { "prop_id": 3, "prop_name": "Manufacturer", "prop_value": "Intel" },
"4": { "prop_id": 4, "prop_name": "Core Count", "prop_value": 8 }
}
}
}
}
}

Ошибки: -403 — метод доступен только Cluster master; -26001 — Hardware inventory не включён.

portgroup-list​

Портовые группы (агрегаты) узлов: протокол агрегации, состав портов и их флаги. Метод показывает, собрался ли LACP на обоих коммутаторах.

Доступ: только Cluster master. Требуется включённый feature flag feature.network_ports_management.

{
"jsonrpc": "2.0",
"method": "portgroup-list",
"params": {
"auth": { "cookie": "..." },
"node_id": 1
},
"id": "1"
}

Ответ по узлу 1 с двумя агрегатами:

{
"jsonrpc": "2.0",
"id": "1",
"result": {
"code": 1,
"data": {
"1": {
"lagg10": {
"portgroup_name": "lagg10",
"portgroup_status": 1,
"portgroup_proto": "lacp",
"ports": {
"ix0": { "port_name": "ix0", "port_flag_active": 1, "port_status": 1 },
"ix1": { "port_name": "ix1", "port_flag_active": 0, "port_status": 0 }
}
}
}
}
}
}

Ожидаемо: portgroup_proto равен lacp, а у каждого порта агрегата port_flag_active и port_status равны 1. В примере выше порт ix1 погашен — линк до второго коммутатора не поднят.

Ошибки: -403 — метод доступен только Cluster master; -25001 — Network ports management не включён.

См. также​