Техническая поддержка
Чтобы помочь нашим специалистам быстрее решить вашу проблему, предлагаем просмотреть описанные ниже шаги:
Web
В случае ошибки задачи в Web-интерфейсе перейдите в журнал задач, выберите нужную задачу и сделайте скрин ошибки. Если в ошибке вы видите сообщение Некоторые дочерние задачи были завершены с ошибкой., то значит, что это мультизадача и надо выбрать дочернюю задачу внизу окна мультизадачи и там сделать дополнительно скрин ошибки. Наиболее полезной информацией является поле Ответ от узлов, где указаны id узлов и их ответ. От части узлов в рамках задачи может прийти положительный ответ, а от других нет, тогда эта задача перейдет в статус PARTIAL.
Пример сообщения об ошибке
Пример сообщения об ошибке мультизадачи
Пример сообщения об ошибке дочерней задачи мультизадачи
В случае ошибки в Web-интерфейсе Internal Server Error
перейдите в CLI контроллера и скопируйте
результат вывода команд log controller-web
и log controller-async
(желательно только часть,
где фигурирует сообщение об ошибке).
CLI
Скопируйте ошибку в СLI или сделайте скрин вывода ошибки вместе с введённой командой. Скопируйте
результат вывода команды log cli
.
Выгрузка событий
При наличии доступа к Web-интерфейсу SpaceVM создайте архив из вкладки Журнал-События по кнопке Действия - Выгрузить события с наиболее подходящими фильтрами.
Фильтрация журналов
Чем точнее фильтры будут использованы при создании архива, тем быстрее служба технической поддержки сможет разобраться и отреагировать.
SpaceVM Bugzilla
Для удобства можно создать баг в SpaceVM Bugzilla или посмотреть там известные баги.
Регистрация пользователя в системе Bugzilla
Для регистраций в системе отслеживания ошибок необходимо перейти по ссылке https://bugzilla.spacevm.ru/. В стартовом окне системы отслеживания ошибок выбираем доступный язык интерфейса EN | RU-RU, по-умолчанию EN. Для регистраций ошибки необходимо перейти в «Open a New Account\Зарегистрировать нового пользователя». В окне «Create a new Space Bugzilla account\Регистрация пользователя Space Bugzilla», в поле «Email address\Адрес электронной почты» указываем почту на которую будут приходить уведомления.
Нажимаем на кнопку «Send\Зарегистрироваться», на почту будет отправлено электронное письмо с подтверждением, содержащее ссылку для продолжения создания учетной записи. Срок действия ссылки истечет, если учетная запись не будет создана в течение 3дней. Необходимо перейти по ссылке. В открытом окне «Create a new user account for ‘e-mail’\Создания учетной записи для ‘e-mail’» заполняем поля: «Real Name\Полное имя», «Type your password\Введите пароль» и «Confirm your password\Повторите ввод пароля». Нажимаем на кнопку «Create\Создать», окно создание учетной записи будет закрыто с уведомлением об успешном создание учетной записи.
Создание "Bug\Ошибка"
Переходим по ссылке https://bugzilla.spacevm.ru/ нажимаем «Log In\Войти» и указываем логин и пароль. После аутентификаций, переходим «Search\Найти» и просматриваем уже созданные кейсы, перед создание нового, чтобы избежать создание дублей. Если подобных кейсов нет, то переходим «File a Bug\Зарегистрировать ошибку». В окне «First, you must pick a product on which to enter a bug\Прежде всего, выберите продукт, к которому относится ошибка». Будут доступны пространства: SpaceVM и Space VDI.
Выбираем пространство, например Space VM, указываем компонент «Component\Компонент» в зависимости от ошибки\пожелания\вопроса. Указываем версию «Version\Версия», «Severity\Серьезность», «Hardware\Платформа», «OS\ОС», «Тип тикета» и «Summary\Аннотация». В поле «Description\Описание» описываем ошибку\пожелание\вопрос. Если необходимо приложить скриншоты, то нажимаем на кнопку «Add an attachment\Добавить приложение». Дальше нажимаем на «Submit Bug\Зарегистрировать ошибку». «Bug\Ошибка» создана.
Диагностика при потере связи контроллера с узлами
-
Проверить, пингуется ли узел с контроллера по адресу интерфейса управления.
-
Если узел пингуется, зайти c контроллера через
node ssh [management_ip]
и проверить статус сервиса супервизора узла черезservices list
. -
Если сервис супервизора узла активен, посмотреть его журналы через
log node
. Супервизор циклически проверяет статус связи с контроллером и логирует о неудачных попытках. Если узел не может подключиться к контроллеру, хотя пингует его, возможно, стоит рестартовать супервизор контроллера черезservices restart controller-engine
. -
Удостоверьтесь через
node config
, что поля node_id, controller_ip, controller_id актуальные. -
Если сервис супервизора узла неактивен, запустить его через
services start node-engine
. -
Если узел не пингуется, то можно через Web-интерфейс контроллера проверить статус электропитания узла через IPMI. При необходимости включить или перезагрузить.
-
Если узел не пингуется, то через IPMI сервера проверить состояние линка физического интерфейса, используемого для управления. Интерфейс можно посмотреть через
net show ports -v
, у нужного интерфейса будет строка used by: default. Если он в DOWN, то поднять его черезnet conf ports set-up -i [имя интерфейса]
.
Диагностика при потере связи по ssh контроллера с узлами
-
На контроллере в
/var/lib/ecp-veil/.users/veil-controller/.ssh/
лежат файлы приватного ключаid_rsa
и публичного ключаid_rsa.pub
(генерируются у каждого контроллера свой при установке и проверяются при каждом обновлении), которые используются для взаимодействия контроллер - узел. -
При добавлении узла к контроллеру публичный ключ контроллера копируется в
/root/.ssh/authorized_keys
и в/var/lib/ecp-veil/.users/veil-node/.ssh/authorized_keys
. -
Для взаимодействия узел-узел ключ не используется. Для некоторых задач между узлами, например, живая миграция, каждый раз генерируется временный ssh ключ, который удаляется после завершения задачи.
-
В случае ошибки доступа контроллера к узлу (например, при ошибке Permission Denied во время загрузки образа на пул данных этого узла) можно сходить на этот узел по ssh и скопировать содержимое файла
/var/lib/ecp-veil/.users/veil-controller/.ssh/id_rsa.pub
в/var/lib/ecp-veil/.users/veil-node/.ssh/authorized_keys
. -
Передобавить ssh-ключи контроллера на узел можно через команду CLI
node repair_ssh
.
Диагностика при ошибках grpc
-
На контроллере в каталоге
/var/lib/ecp-veil/controller/local_data/
лежат файлы grpc сертификатов{node_id}.crt
для каждого узла, которые используются для взаимодействия контроллер - узел. -
При добавлении узла к контроллеру генерируется grpc сертификат и копируется в
/var/lib/ecp-veil/node/local_data/node.crt
и в/var/lib/ecp-veil/node/local_data/node.key
. -
Соответственно, контроллер при grpc запросе ищет у себя в каталоге
/var/lib/ecp-veil/controller/local_data/
файл с id узла, читает его и с содержимым делает запрос. Сервисnode-engine
на узле при старте ищет в/var/lib/ecp-veil/node/local_data/
файлnode.key
и принимает только запросы c верным сертификатом. -
Если на контроллере по какой-то причине отсутствует нужный сертификат для конкретного узла, то можно скопировать его с узла на контроллер (или удалить на узле, тогда запросы будут идти нешифрованными).
Действия при ошибках сервиса статистики
-
Возможна ситуация ошибки хранилища статистики prometheus. Быстрым способом починки является очистка хранилища, перенастройка и перезапуск сервиса. Ниже показана последовательность из 3 действий:
-
system statistics clear
(Очистка БД prometheus. Необходимо выполнить в случае ошибки БД, делаетrm -rf /var/log/prometheus/metrics2/*
) -
system statistics reload
(Перенастройка конфигурации экспортеров prometheus согласно БД контроллера.) -
service restart prometheus
(Перезагрузка сервиса prometheus.) -
Также рекомендуется проверить состояние сервиса статистики (
services status prometheus
) и ошибки сервиса в syslog (ошибки, связанные с prometheus). На контроллере можно проверить работу сервиса статистики, перейдя через браузер по адресуhttp://{controller_ip}:9090/
. Список подключенных экспортеров узлов с их статусами к контроллеру можно увидеть по адресуhttp://{controller_ip}:9090/classic/targets
. На узле можно проверить работу сервисов сбора статистики узла и ВМ, перейдя через браузер по адресамhttp://{node_ip}:9100/
(статистика узла) иhttp://{node_ip}:9177/
(статистика ВМ). -
Можно включить grafana в CLI контроллера через
grafana start
и перейти в браузер по адресуhttp://{controller_ip}:3000/
(admin/admin).
Действия при ошибках установки
-
Процесс установки в целом состоит из 2 частей: до и после первой перезагрузки.
-
До первой перезагрузки идёт базовая установка пакетов: как Space пакетов, так и зависимостей. Генерируется сервис, который запустит после 1 перезагрузки скрипт подготовки системы к работе.
-
После 1 перезагрузки запускается этот скрипт. Он циклично (до 10 раз) проверяет системы к готовности и поэтапно донастраивает её, пока не сочтет, что всё готово. Процесс подготовки можно отслеживать через команду CLI
log first_boot
. -
В конце скрипта подготовки запускается скрипт инициализации сети: создаются коммутаторы default и blackhole, внутренний интерфейс mgmt, адрес, выданный физическому интерфейсу в первой части установки снимается и назначается на mgmt, mgmt подключается к default, первый физический интерфейс в состоянии UP тоже подключается к default. Процесс инициализации сети можно отслеживать через команду CLI
log net_init
. -
Если установка не завершается, стоит посмотреть вывод команд CLI
log first_boot
,log net_init
,log first_tests
. -
Если установка не завершается, можно повторно запустить скрипт подготовки системы к работе через команду CLI
system init
.
Пример (система автонастройки началась и не завершилась. Возможно, сервер был перезагружен в процессе подготовки или были какие-то причины, не дающие завершиться процессу).
-
Если видно по
log first_boot
, что процесс не завершился, то стоит запустить командуsystem autotest
, и посмотреть, будут ли там ошибки. -
Если не инициализировалась сеть, то можно после завершения установки переинициализировать её через команду CLI
net init
. -
Если в выводе команды
ip a
нет mgmt, default, то можно после завершения установки переинициализировать сеть через команду CLInet init
.
Действия при ошибках 1 части установки
Необходимо получить лог инсталлятора.
После возникновения ошибки:
-
Проверьте дату и время на хосте (должны быть актуальные)
-
перейдите в виртуальную консоль 4 (Ctrl-Alt-4 на виртуальной IPMI клавиатуре или физической, если установка с физического терминала), там сделайте скрин экрана и создайте баг в https://bugzilla.spacevm.ru/ или отправьте в ЛК.
-
перейдите в виртуальную консоль 2 (Ctrl-Alt-2 на виртуальной IPMI клавиатуре или физической, если установка с физического терминала), там создайте какой-нибудь каталог типа /flash, подключите к серверу флэш-накопитель, отформатированный в fat32 или ext¾ и примонтируйте его в этот каталог. После этого скопируйте на неё /var/log/syslog с сервера и создайте баг в https://bugzilla.spacevm.ru/ или отправьте в ЛК.
Для монтирования флэш-накопителя и переноса журналов на него необходимо:
-
опознать букву устройства флэш-накопителя при помощи команды blkid, либо подсмотреть в 4 консоли полученную флэшкой букву при её подключении, также нужно обратить внимание, находится ли файловая система на флэш-накопителе в разделе или прямо на устройстве (если есть раздел, а устройство имеет букву, скажем, sdc, то раздел будет sdc1)
-
создать в удобном месте каталог для монтирования, скажем, ~/usb mkdir ~/usb
-
примонтировать раздел (если он есть) или сам флэш-накопитель в этот каталог: mount /dev/sdc1 ~/usb или mount /dev/sdc ~/usb
-
если всё правильно, теперь можно проверить место на флэш-накопителе через df -h
-
далее скопируйте всё из /var/log и отмонтируйте флэшку
Проверка целостности установочного медиа (флэш-накопителя, например)
- Загрузиться в режиме Space Live
- Дождаться приглашения командной строки.
- Увидеть, где примонтировано загрузочное устройство (команда mount, например /run/live/medium)
- Перейти в этот каталог (cd /run/live/medium)
- Запустить команду md5sum -c md5sum.txt
- Так как накопительной статистики по ошибкам здесь нет, можно скрыть вывод по файлам без ошибок: md5sum -c md5sum.txt | grep -v ': OK'