Проверка управляющего узла после включения в VK Private Cloud

Перед включением управляющего узла перейдите в Портал мониторинга (Zabbix).

Если через 20 минут после включения на восстановленном узле отображаются ошибки, исправьте их.

Получите список сервисов systemd units, на который произошла ошибка:

 
$ sudo systemctl list-units --failed

Если есть сервис с ошибкой:

1. Запустите сервис:

    
   $ sudo systemctl start <СЕРВИС>

   Здесь <СЕРВИС> — имя сервиса, в работе которого возникла ошибка.

2. Проверьте статус сервиса:

    
   $ sudo systemctl status <СЕРВИС>

   Здесь <СЕРВИС> — имя сервиса, в работе которого возникла ошибка.

   Пример вывода команды

1. Получите список инстансов сервисов:

    
   $ sudo ls /srv/mysql/

   Пример вывода команды

2. Получите статус сервиса:

   1. Подключитесь к сервису.

       
      $ sudo mysql -S /srv/mysql/keystone/socket/<ИМЯ_СЕРВИСА>.sock

   2. Получите статус сервиса:

       
      MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_%';

      Пример вывода команды

3. Выполните проверку всех кластеров Galera:

    
   $  for i in $(ls /srv/mysql/); do echo ""; echo $i; sudo mysql -S /srv/mysql/$i/socket/$i.sock -u root --execute 'SHOW STATUS WHERE Variable_name RLIKE "^(wsrep_cluster_size|wsrep_local_state_comment|wsrep_ready|wsrep_local_index)$"'; done

   Пример вывода команды

1. Получите список используемых кластеров PostgreSQL:

    
   $ sudo grep -r STOLON_CLUSTER_NAME /etc/stolon/

   Пример вывода команды

2. Получите статус кластера:

    
   $ stolonctl status --cluster-name <КЛАСТЕР> --store-backend consul

   Здесь <КЛАСТЕР> — имя кластера.

   Пример вывода команды

О восстановлении Breeze — в статье При авторизации в Портале самообслуживания возвращается ответ с кодом 500.

О восстановлении Dusk — в статье При авторизации в Портале самообслуживания возвращается ответ с кодом 500.

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

 
$ sudo kubectl get componentstatus

 
$ sudo kubectl get nodes

Статус восстановленного узла должен быть Ready.

Для получения статусов deployments и pods, выполните команды:

 
$ sudo kubectl get deployments -A

Все deployments должны быть N/N — READY.

Если есть поды с ошибками, удалите их:

 
$ sudo kubectl delete po ${POD_NAME} -n ${NAMESPACE} --grace-period=0 --force

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

 
$ sudo kubectl get po -A -o wide | grep rabbit

Проверьте инстанс:

 
$ sudo kubectl exec -it rabbitmq-barbican-0 -n rabbitmq rabbitmqctl cluster_status

Если в кластере есть ошибки:

1. Удалите под с ошибкой:

    
   $ sudo kubectl delete po ${POD_NAME} -n ${NAMESPACE} --grace-period=0 --force

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

    
   $ sudo kubectl delete po ${POD_NAME_1} ${POD_NAME_2} ${POD_NAME_3} -n ${NAMESPACE} --grace-period=0 --force

3. Убедитесь, что кластер собрался успешно.

Управляющий узел имеет несколько инстансов etcd (отдельный для k8s и отдельные сервисные). Информацию по инстансу для k8s можно получить следующими командами (команды нужно выполнять на узле, который был восстановлен):

 
$ sudo etcdctl endpoint health --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd.crt --key=/etc/etcd/etcd.keyhttps://10.30.3.13:2379 is healthy: successfully committed proposal: took = 14.171465ms$ sudo etcdctl endpoint status --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd.crt --key=/etc/etcd/etcd.keyhttps://127.0.0.1:2379, e50bea327e252cb3, 3.5.0, 47 MB, false, false, 3, 895594, 895594,

Статус эндпоинтов должен быть healthy.

Чтобы проверить статусы остальных инстансов etcd:

1. Получите список всех etcd инстансов:

    
   $ sudo ls /etc/etcd/etcd-*

   Пример вывода команды

2. Получите статус инстанса etcd:

    
   $ sudo grep ETCD_ADVERTISE_CLIENT_URLS /etc/etcd/<ИНСТАНС>/etcd.conf  | cut -d '=' -f2"http://10.30.3.13:29379"$ sudo etcdctl endpoint health --endpoints=http://10.30.3.13:29379http://10.30.3.13:29379 is healthy: successfully committed proposal: took = 4.487889ms$ sudo etcdctl endpoint status --endpoints=http://10.30.3.13:29379http://10.30.3.13:29379, 27a3ca2c9ee54c54, 3.5.0, 20 kB, false, false, 3, 190858, 190858,

   Здесь <ИНСТАНС> — имя инстанса.

Чтобы проверить работу кластера Zookeeper, на восстановленном узле:

1. Проверьте статус сервиса:

    
   $ sudo systemctl status zookeeper

   Пример вывода команды

2. Проверьте состояния в кластере сервиса Zookeeper:

    
   $ echo mntr | nc localhost 2181 | grep state

   Пример вывода команды

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

1. Проверьте статус public_haproxy:

    
   $ sudo systemctl status public_haproxy

   Пример вывода команды

2. Проверьте статус private_haproxy:

    
   $ sudo systemctl status private_haproxy

   Пример вывода команды

3. В случае ошибки, перезапустите сервис:

    
   $ sudo systemctl restart private_haproxy

4. Проверьте логи сервиса и убедитесь, что нет ошибок:

    
   $ sudo systemctl status private_haproxy$ sudo journalctl -f -u private_haproxy

   Пример вывода команды

Для проверки статуса кластера consul необходимо выполнить следующие команды на управляющем узле:

 
$ sudo consul members listNode

 
$ sudo  consul operator raft list-peers

Статус всех узлов, включая восстановленный, должен быть alive. Статус одного из узлов кластра должен быть leader.

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

1. Выполните bash-скрипт из файла openrc.sh:

    
   $ sudo su# . ~/openrc.sh

2. Проверьте статусы сервисов сompute:

    
   # openstack compute service list

   Пример вывода команды

3. Поверьте статусы сервисов network:

    
   # openstack network agent list

   Пример вывода команды

4. Поверьте статусы сервисов volume:

    
   # openstack volume service list

   Пример вывода команды

Все сервисы восстановленного узла должны быть в статусе enabled и state up.

Если один из агентов на восстановленном узле не работает, перезапустите соответствующий сервис на узле:

 
# sudo systemctl restart <СЕРВИС>

Здесь <СЕРВИС> — имя сервиса (из столбца Binary)

Чтобы получить статусы инстансов clickhouse-server, на втором или третьем управляющем узле:

1. Получите список инстансов ClickHouse:

    
   # ls /var/lib/clickhouse/vkcloud_ch_*

   Пример вывода команды

2. Подключитесь к инстансу:

    
   # grep tcp_port /var/lib/clickhouse/<ИНСТАНС>/config.xml<tcp_port>9008</tcp_port># clickhouse-client --port 9008ClickHouse client version 22.9.7.34 (official build).Connecting to localhost:9008 as user default.Connected to ClickHouse server version 22.9.7 revision 54460.

   Здесь <ИНСТАНС> — имя инстанса.

3. Получите информацию о доступных кластерах и серверах, которые в них входят:

    
   SELECT * FROM system.clusters LIMIT 2 FORMAT Vertical;

   Пример вывода команды

   Значения параметров errors_count и estimated_recovery_time должны быть равны 0.

Портал просмотра журналов событий (OpenSearch) отвечает за сбор логов Платформы.

Через 15-20 минут после включения управляющего узла убедитесь, что в логах нет ошибок:

1. Перейдите в Портал просмотра журналов событий (OpenSearch).

2. Для диагностики используйте фильтр field host.name=$<NODE_NAME>. Здесь <NODE_NAME> — имя включенного управляющего узла. Выполните поиск по словам error, traceback, failed.

В Портале самообслуживания проверьте создание объектов виртуализации:

1. Сеть и подсеть.

2. Инстанс БД.

3. Кластер Kubernetes.

 
Tarantool dusk_xx@domain.name downstream set "stopped"

 
$ sudo systemctl restart tarantool@dusk_xx.service

 
Rabbit Dead rabbitmq:rabbitmq-<ПОД>

 
Agent neutron-metadata-agent@<ДОМЕН> is downAgent neutron-l3-agent@<ДОМЕН> is downAgent neutron-openvswitch-agent@<ДОМЕН> is downAgent neutron-dhcp-agent@<ДОМЕН> is down

 
$ sudo systemctl restart neutron-<АГЕНТ>

 
Systemd unit proxysql.service is Failed

 
$ sudo systemctl restart proxysql.service

 
HAProxy, backend <БЭКЕНД> public is DOWN on <ДОМЕН>

 
Tarantool dusk_xx@domain.name  upstream lag > 1

 
$ sudo systemctl restart tarantool@dusk_xx.service

 
Tarantool breeze_xx@domain.name  upstream lag > 1

 
$ sudo systemctl restart tarantool@breeze_xx.service