Диагностика и обслуживание

Порядок выполнения быстрой диагностики неисправностей Платформы:

1. Проверьте работоспособность сервисов Платформы (см. раздел Проверка работоспособности сервисов).

2. Убедитесь, что доступны основные веб-интерфейсы Платформы:

   1. Портал управления доступом (Keycloak).
   2. Портал администратора Платформы.
   3. Портал самообслуживания.
   4. Портал мониторинга (Zabbix).
   5. Портал логирования (OpenSearch).

1. Проверьте, что все systemd сервисы на всех серверах кластера запущены без ошибок.

   Команда запуска проверки сервиса

    
   systemctl list-units --failed

   Ожидаемый результат

    
   0 loaded units listed. Pass --all to see loaded but inactive units, too.To show all installed unit files use 'systemctl list-unit-files'.

   Если обнаружены сервисы с ошибкой, проверьте логи и перезапустите сервис.

   Просмотр логов и перезапуск сервиса на примере public_haproxy

    
   journalctl -f --no-pager -u public_haproxysystemctl restart public_haproxy

Основные веб-интерфейсы Платформы:

• Портал управления доступом (Keycloak).
• Портал администратора Платформы.
• Портал самообслуживания.
• Портал мониторинга (Zabbix).
• Портал логирования (OpenSearch).

Адрес: https://<KEYCLOAK_PUBLIC_ENDPOINT_DOMAIN>.

Логин / пароль для входа:

 
admin/${vault_keycloak_password}

Алгоритм проверки:

1. Выполните вход с помощью учётной записи администратора Платформы в Keycloak.
2. Выберите область безопасности (realm) MCS.
3. Создайте группу в разделе «Manage» → «Groups» (см. официальную документацию).
4. Создайте пользователя в разделе «Manage» → «Users» (см. официальную документацию).
5. Добавьте созданного пользователя в группу, созданную ранее (см. официальную документацию).

Ожидаемый результат:

Выполнен вход в Портал управления доступом. Создана группа и пользователь в ней.

Адрес: https://<SUPERADMIN_PUBLIC_ENDPOINT_DOMAIN>/.

Логин / пароль для входа:

 
superadmin/${vault_iam_sync_user_password}

Алгоритм проверки:

1. Убедитесь, что существует хоть одна группа с пользователем (см. раздел Портал управления доступом (Keycloak)).
2. Выполните вход с помощью учётной записи администратора Платформы в Портал администратора.
3. Создайте проект в разделе «Управление проектами» → «Проекты».
4. Предоставьте права группе пользователей (см. раздел Предоставление доступа к проекту).

Ожидаемый результат:

Выполнен вход в Портал администратора Платформы. Создан новый проект. Добавлена права доступа к выбранному проекту.

Адрес: https://<MCS_PUBLIC_URL>.

Логин / пароль для входа:

• используйте данные учётных записей, реквизиты которых есть в Портале управления доступом (см. раздел Портал управления доступом (Keycloak)).

Алгоритм проверки:

1. Убедитесь, что существует пользователь, для которого настроен доступ в проект (см. раздел Портал администратора Платформы).
2. Выполните вход в Портал самообслуживания при помощи учётной записи пользователя, убедитесь, что есть доступ к проекту.
3. Перейдите в раздел «Облачные вычисления», активируйте сервисы согласно предложенной инструкции и создайте ВМ. Шаги по созданию ВМ см. в Руководстве пользователя Платформы.

Ожидаемый результат:

Выполнен вход в Портал самообслуживания при помощи учётной записи пользователя. Создана новая ВМ.

Адрес: https://<MONITORING_ENDPOINT_FQDN>/zabbix/.

Логин / пароль для входа:

 
${vault_zabbix_api_user}/${vault_zabbix_api_user}

Алгоритм проверки:

1. Выполните вход с помощью учётной записи администратора Платформы в Zabbix.

Ожидаемый результат:

Выполнен вход в Портал мониторинга (Zabbix).

Адрес: https://<LOGS_ENDPOINT_FQDN>.

Логин / пароль для входа:

 
admin/${opensearch_users.admin.no_hash_password}

Алгоритм проверки:

1. Выполните вход с помощью учётной записи администратора Платформы OpenSearch.

Ожидаемый результат:

Выполнен вход в Портал логирования (OpenSearch).

Для обслуживания узлов кластера предусмотрен механизм их временного отключения. Инструкцию по выводу узлов из кластера см. в соответствующих разделах:

• Вывод вычислительного узла из кластера.
• Вывод управляющего узла (controller) из кластера.

Шаги по проверке работы основных сервисов и компонентов Платформы описаны в подразделах далее.

Чтобы проверить состояние Docker сервисов, на управляющем узле выполните команду:

 
docker ps -a | grep -v Up

Вывод данной команды должен быть либо пустым, либо содержать только пользовательские контейнеры.

RabbitMQ функционирует в Kubernetes, при этом на основные компоненты Платформы существует свой сервис RabbitMQ.

Чтобы проверить состояние кластера RabbitMQ, на управляющем узле выполните команды:

• Просмотр полного списка сервисов RabbitMQ:

   
  kubectl get pods -n rabbitmq

• Просмотр состояния отдельного сервиса RabbitMQ:

   
  kubectl -n rabbitmq exec <NAME> rabbitmqctl cluster_status

  , где <NAME> — наименование целевого сервиса RabbitMQ.

Все сервисы кластера RabbitMQ должны быть в запущенном состоянии, просмотр информации об отдельном сервисе RabbitMQ не должен содержать ошибок.

 
NAME                    READY   STATUS    RESTARTS   AGErabbitmq-ceilometer-0   1/1     Running   0          20drabbitmq-ceilometer-1   1/1     Running   0          20drabbitmq-ceilometer-2   1/1     Running   0          20drabbitmq-celery-0       1/1     Running   0          20d

 
Cluster status of node rabbit@rabbitmq-nova-0.rabbitmq-nova.rabbitmq.svc.kube ...BasicsCluster name: rabbit@rabbitmq-nova-0.rabbitmq-nova.rabbitmq.svc.kubeRunning Nodesrabbit@rabbitmq-nova-0.rabbitmq-nova.rabbitmq.svc.kuberabbit@rabbitmq-nova-1.rabbitmq-nova.rabbitmq.svc.kuberabbit@rabbitmq-nova-2.rabbitmq-nova.rabbitmq.svc.kubeMaintenance statusNode: rabbit@rabbitmq-nova-0.rabbitmq-nova.rabbitmq.svc.kube, status: not under maintenanceNode: rabbit@rabbitmq-nova-1.rabbitmq-nova.rabbitmq.svc.kube, status: not under maintenanceNode: rabbit@rabbitmq-nova-2.rabbitmq-nova.rabbitmq.svc.kube, status: not under maintenanceAlarms(none)Network Partitions(none)

Чтобы проверить состояние кластера MariaDB (mysql/galera):

1. На деплой-ноде найдите пароль от целевой БД (в данном случае — MySQL; в команде ниже <ENV> — наименование окружения):

    
   grep -r vault_cinder_mysql_password inventory/<ENV>/group_vars/<ENV>/vault.yml

2. На управляющем узле выполните команду:

    
   mysql -h <HOSTNAME> -u cinder -D cinder -p --execute "SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"

3. Введите пароль, полученный на шаге 1.

Ожидаемое состояние — Synced.

 
+---------------------------+--------+| Variable_name             | Value  |+---------------------------+--------+| wsrep_local_state_comment | Synced |+---------------------------+--------+

Чтобы проверить состояние мониторинга и логирования:

1. На узле, подлежащем проверке, выполните команду:

    
   docker ps -a | egrep 'zabbix|fulentd'

   Все контейнеры должны быть в запущенном (Up) состоянии.

2. Проверьте журналы контейнеров на наличие ошибок:

    
   docker logs --tail=100 fluentddocker logs --tail=100 mcs_zabbix_agent

Чтобы проверить состояние компонентов Nova:

1. Выполните подготовительные операции для подключения к OpenStack CLI по инструкции Вход для Администратора Платформы.

2. Получите список сервисов на целевом узле:

    
   openstack compute service list | grep <HOSTNAME>

   Вывод должен показать состояние всех сервисов Nova на узле как up.

   Пример списка сервисов Nova

    
   openstack compute service list | grep <HOSTNAME>|  3 | nova-conductor   | <HOSTNAME>   | internal | enabled | up    | 2020-07-23T13:38:00.000000 || 33 | nova-scheduler   | <HOSTNAME>   | internal | enabled | up    | 2020-07-23T13:38:03.000000 || 42 | nova-consoleauth | <HOSTNAME>   | internal | enabled | up    | 2020-07-23T13:37:57.000000 |

Чтобы проверить состояние сервисов Cinder:

1. Выполните подготовительные операции для подключения к OpenStack CLI по инструкции Вход для Администратора Платформы.

2. Получите список состояний сервиса целевого узла:

    
   openstack volume service list | grep <HOSTNAME>

   Вывод должен показать состояние всех сервисов Cinder на узле как up.

   Пример списка сервисов Cinder

    
   openstack volume service list | grep <HOSTNAME>| cinder-scheduler | <HOSTNAME> | nova | enabled | up    | 2020-07-23T13:38:25.000000 || cinder-backup    | <HOSTNAME> | nova | enabled | up    | 2020-07-23T13:38:27.000000 |

Чтобы проверить журналы Neutron, на управляющем узле выполните команду:

 
ls -t /var/log/neutron/ | egrep -v 'log..' | grep neutron | xargs -l1 -I {} tail -n 200 /var/log/neutron/{} | grep -i error

Вывод данной команды должен быть пустым.

Чтобы проверить состояние сервисов Neutron:

1. Выполните подготовительные операции для подключения к OpenStack CLI по инструкции Вход для Администратора Платформы.

2. Получите список состояний сервиса, выполнив команду:

   Пример списка сервисов Neutron

    
   openstack network agent list | grep <HOSTNAME>| 02480c02-1827-4007-b31a-08c4cb599826 | Metadata agent            | <HOSTNAME>  | None  | True  | UP    | neutron-metadata-agent    || 67dd92dc-465e-4c28-a52d-9e76b85f66bb | Open vSwitch agent        | <HOSTNAME>  | None  | True  | UP    | neutron-openvswitch-agent || a0411328-04d9-46b3-a0a2-0c4e23b8eb06 | L3 agent                  | <HOSTNAME>  | nova  | True  | UP    | neutron-l3-agent          || a4647593-d7ad-42dd-90e6-b535fe9cb87e | BGP dynamic routing agent | <HOSTNAME>  | None  | True  | UP    | neutron-bgp-dragent       || bf2b46eb-74a5-40b6-bc40-e0e6fb035dd4 | DHCP agent                | <HOSTNAME>  | nova  | True  | UP    | neutron-dhcp-agent        || c02faf6d-e10b-483d-ba19-970baea03584 | Loadbalancerv2 agent      | <HOSTNAME>  | None  | True  | UP    | neutron-lbaasv2-agent     |

   Поле «Alive» должно иметь значение True, поле «State» — UP (для всех сетевых агентов). Если есть сервисы с выключенным агентом, выполните шаги:

   1. Зайдите на сервер <HOSTNAME> по SSH.

   2. Проверьте логи и перезагрузите выключенные сервисы:

      Просмотр логов и перезапуск сервиса на примере neutron-l3-agent

       
      journalctl -f --no-pager -u neutron-l3-agentsystemctl restart neutron-l3-agent

Чтобы проверить журналы Nginx, выполните команду:

 
ls -t /var/log/nginx/ | egrep -v 'log..' | grep error | xargs -l1 -I {} tail -n 200 /var/log/nginx/{} | grep -i error

Возможные виды выводимых ошибок:

• допустимые:

  • 30x — ошибки, связанные с попытками входа с неверными УЗ.
  • 40x — ошибки, связанные с неверными запросами пользователей.

• недопустимые:

  • 50x — ошибки, связанные с работой сервиса.