Устранение неполадок

Ошибка может возникнуть при исполнении команд Start / Stop / Restart или в процессе развертывания на аналогичных шагах. Связана с невозможностью пользователя управлять systemd-сервисами.

Возможные причины:

1. Не выполнена команда loginctl enable-linger tarantool

   • Можно проверить наличием файла /var/lib/systemd/linger/tarantool.

2. Отсутствуют файлы в /run директории пользователя tarantool:

   /run/user/$(id -u tarantool)/systemd

   • Попробовать заново вызвать команду loginctl enable-linger tarantool, но это помогает не всегда.
   • Пересоздать пользователя tarantool с тем же UID и GID.
   • Создать файлы по аналогии.

Возникает при запуске сервисов на RHEL 8, AstraLinux, RedOS.

Ошибка может возникнуть на этапах конфигурации кластера. Например, сценарий Settings. Связана с некорректным запуском процесса Tarantool.

1. Проверьте наличие параметров User=tarantool и Group=tarantool в unit-файле systemd.

Известно о трех ошибках:

1. CartridgeCfgError: Socket bind error (/udp): Address already in use
2. HttpInitError: <…> Can't create tcp_server: Address already in use
3. RemoteControlError: Can't start server on :: Address already in use

Эти ошибки можно заметить только в логах Tarantool.

Проблема вызвана тем, что при старте не может быть использован бинарный (например, 3301) или HTTP (например, 8081) порт. В результате экземпляр Tarantool не сможет сконфигурироваться и упадет с ошибкой.

1. Из текста ошибки определите, какой порт занят.

2. С помощью unix-команды lsof определите, какое приложение в данный момент использует данный порт.

    
   sudo lsof -i :<port>

   Без sudo-прав можно посмотреть только процессы текущего пользователя.

3. Определите тип подключения.

    
   # Исходящее подключение на порту 50858TCP 192.168.100.17:50858->google.com:https (ESTABLISHED)# Ожидание входящих запросов на порту 3301TCP localhost:3301 (LISTEN)

4. Дальнейшие действия зависят от найденного приложения и типа подключения.

   1. Это исходящее подключение:

      • Настройте параметр сети, отвечающий за пул исходящих портов. Например, так:

       
      echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range/etc/rc.d/init.d/network restart

   2. Это входящее подключение:

      • Для Google Chrome / etcd / nginx / любого другого приложения определите, можно ли изменить параметры, чтобы освободить этот порт.
      • Для Tarantool -- скорее всего, у вас неверная топология кластера или запущено несколько кластеров одновременно. Обратитесь в техподдержку Tarantool за консультацией.

Ошибка возникает при запуске экземпляров Tarantool с помощью systemd. Как правило, на RHEL 7.

• Проверьте, что на всех серверах создан systemd сервис-файл в директории /etc/systemd/system.

Ошибка возникает при запуске экземпляров Tarantool, nginx или etcd с помощью systemd.

1. Убедитесь, что корректно выставлены sudoers-права для администраторов. Права должны предусматривать запуск команд без пароля, то есть должно быть ключевое слово NOPASSWD.
2. Проверьте название приложения, cartridge_app_name. Переменная используется для формирования имени сервис-файла в формате < cartridge_app_name >@.service. Если название файла не совпадает с переменной в файле-инвентаре hosts.yml, исправьте это.

Ошибка подключения к серверу по SSH. Возникает в начале исполнения сценариев, требующих подключения.

Возможные причины:

1. На SSH-ключе установлен пароль (passphrase). Инсталлятор на текущий момент не поддерживает интерактивный ввод пароля.

   • Создайте новый ключ без использования passphrase.

2. Публичная часть ключа не была добавлена на сервер как доверенная.

   • Скопируйте публичную часть на все сервера с помощью команды ssh-copy-id.

    
   ssh-copy-id -i ~/.ssh/mykey user@host

   Другой вариант -- добавить вручную в файл ~/.ssh/authorized_keys для пользователя администратора.

Возникает в процессе запуска экземпляра Tarantool.

Возможные причины:

1. Процесс не может создать рабочие директории.
   • Проверьте корректность путей в сервис-файле systemd.
   • Проверьте корректность всех путей из переменных в инвентаре.

Вариант 1: Конфигурационный файл SSH

Создайте конфигурационный файл и укажите необходимые значения для jumphost IP, jumphost user, IP/FQDN сервера(ов) под Tarantool, super user.

 
Host jump  User <jumphost user>  HostName <jumphost IP>  UserKnownHostsFile /dev/null  IdentityFile /ansible/.ssh/id_private_key  StrictHostKeyChecking noHost <IP/FQDN>  User <super user>  ProxyJump jump  UserKnownHostsFile /dev/null  StrictHostKeyChecking no

Добавьте к команде запуска ATE подключение конфигурации с помощью опции -v (volume):

 
-v ${SSH_CONFIG_FILE}:/root/.ssh/config:Z

Например:

 
docker run --network host -it --rm \  -v ${SSH_CONFIG_FILE}:/root/.ssh/config:Z \  -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \  -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \  -e SUPER_USER_NAME=${SUPER_USER_NAME} \  ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \  ansible-playbook -i /ansible/inventories/hosts.yml \  --extra-vars '{      "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",      "super_user":"'${SUPER_USER_NAME}'",      "tarantool_shared_become_user":"tarantool",      "tarantool_configure_logrotate":"true"  }' \  playbooks/logrotate.yml

Вариант 2: Опция ProxyCommand

Добавьте опцию ProxyCommand к переменной инвентаря ansible_ssh_common_args. Подставьте свои значения <jumhost user> и <jumhost IP>.

 
ansible_ssh_common_args: -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null      -o StrictHostKeyChecking=no -o ProxyCommand="ssh -W %h:%p <jumhost user>@<jumhost IP> -i /ansible/.ssh/id_private_key      -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

Команды docker run будут работать без дополнительных изменений.