Установка через Ansible Tarantool Enterprise

Ansible Tarantool Enterprise (ATE) — это набор плейбуков для развертывания и последующего обслуживания продуктов Tarantool Enterprise. Инсталлятор Ansible Tarantool Enterprise — это основной способ установки Tarantool DB.

Ansible Tarantool Enterprise используется для развертывания кластера на промышленном сервере. Инструкция по запуску кластера через ATE приведена в разделе Запуск кластера через Ansible Tarantool Enterprise.

Содержание:

• Способы установки
• Настройка среды
  • Подготовка к использованию
  • Расчет дисковой емкости
  • Предварительная настройка сервера под Tarantool

• Установка с использованием Ansible
• Установка с использованием Docker

Инсталлятор Ansible Tarantool Enterprise поставляется в виде пакета, доступного в личном кабинете на сайте Tarantool.

Для установки с помощью ATE Tarantool DB также поставляется в виде пакета, доступного в личном кабинете на сайте Tarantool. Узнать больше: Публикуемые версии.

Есть два способа установки Tarantool DB с помощью ATE:

• через Ansible;
• через Docker.

В обоих вариантах используется один и тот же установочный пакет Tarantool DB, но пакет инсталлятора ATE нужно выбирать под конкретный вариант установки:

• tarantool-enterprise-<VERSION>.tar.gz — пакет для установки через Ansible;
• ansible-tarantool-enterprise-<VERSION>.tar.gz — пакет для установки через Docker.

Здесь:

• VERSION — версия инсталлятора Ansible Tarantool Enterprise.

Конечный результат установки Tarantool DB через ATE одинаков для обоих вариантов.

Минимальные системные требования под инсталлятор Ansible Tarantool Enterprise:

• 4 Core 2.6ГГц +;
• 4 Гб RAM.

Подробные требования к серверу под ATE описаны в документации по инсталлятору ATE.

Смотрите также: Требования к инфраструктуре для Tarantool DB.

Перед запуском сценариев развертывания подготовьте:

• инвентарь — описание топологии и настроек Tarantool DB (см. ниже);
• пользователя для подключения к серверам по ssh. Может быть root. Должен иметь sudo права на логин под локального пользователя tarantool;
• приватный ssh-ключ пользователя для подключения к серверам;
• пакеты для нужного типа установки (Ansible-коллекция или Docker-контейнер).

Пример инвентаря для Tarantool DB

 
all:  children:    ROUTERS:      hosts:        router-1:        router-2:        router-3:        router-4:        router-5:        router-6:    STORAGES:      hosts:        storage-1-1:        storage-1-2:        storage-2-1:        storage-2-2:    STORAGES_GROUP_1:      hosts:        storage-1-1:        storage-1-2:    STORAGES_GROUP_2:      hosts:        storage-2-1:        storage-2-2:    replicaset_router_01:      hosts:        router-1:      vars:        failover_priority:        - router-1        replicaset_alias: router-1        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    replicaset_router_02:      hosts:        router-2:      vars:        failover_priority:        - router-2        replicaset_alias: router-2        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    replicaset_router_03:      hosts:        router-3:      vars:        failover_priority:        - router-3        replicaset_alias: router-3        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    replicaset_router_04:      hosts:        router-4:      vars:        failover_priority:        - router-4        replicaset_alias: router-4        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    replicaset_router_05:      hosts:        router-5:      vars:        failover_priority:        - router-5        replicaset_alias: router-5        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    replicaset_router_06:      hosts:        router-6:      vars:        failover_priority:        - router-6        replicaset_alias: router-6        roles:        - vshard-router        - crud-router        - failover-coordinator        - space-explorer        - migrator        - dictionary.roles.router    shard_1:      hosts:        storage-1-1:        storage-1-2:      vars:        failover_priority:        - storage-1-1        - storage-1-2        replicaset_alias: shard-1        roles:        - vshard-storage        - crud-storage        - space-explorer        - expirationd        - dictionary.roles.storage    shard_2:      hosts:        storage-2-1:        storage-2-2:      vars:        failover_priority:        - storage-2-1        - storage-2-2        replicaset_alias: shard-2        roles:        - vshard-storage        - crud-storage        - space-explorer        - expirationd        - dictionary.roles.storage    tarantooldb_test_env_1:      hosts:        storage-1-1:        router-1:        router-2:        router-3:      vars:        ansible_user: '{{ super_user }}'        ansible_host: '{{ internal_ip }}'    tarantooldb_test_env_2:      hosts:        storage-2-1:        router-4:        router-5:        router-6:      vars:        ansible_user: '{{ super_user }}'        ansible_host: '{{ internal_ip }}'    tarantooldb_test_env_3:      hosts:        storage-1-2:        storage-2-2:      vars:        ansible_user: '{{ super_user }}'        ansible_host: '{{ internal_ip }}'  hosts:    storage-1-1:      config:        advertise_uri: '{{ internal_ip }}:3301'        http_port: 8091        log: /app/logs/tarantooldb/storage-1-1.log        memtx_memory: 536870912 #512MiB        vinyl_cache: 0        vinyl_memory: 0    storage-1-2:      config:        advertise_uri: '{{ internal_ip }}:3302'        http_port: 8092        log: /app/logs/tarantooldb/storage-1-2.log        memtx_memory: 536870912 #512MiB        vinyl_cache: 0        vinyl_memory: 0    storage-2-1:      config:        advertise_uri: '{{ internal_ip }}:3303'        http_port: 8093        log: /app/logs/tarantooldb/storage-2-1.log        memtx_memory: 536870912 #512MiB        vinyl_cache: 0        vinyl_memory: 0    storage-2-2:      config:        advertise_uri: '{{ internal_ip }}:3304'        http_port: 8094        log: /app/logs/tarantooldb/storage-2-2.log        memtx_memory: 536870912 #512MiB        vinyl_cache: 0        vinyl_memory: 0    router-1:      config:        advertise_uri: '{{ internal_ip }}:3305'        http_port: 8095        log: /app/logs/tarantooldb/router-1.log        vinyl_cache: 0        vinyl_memory: 0    router-2:      config:        advertise_uri: '{{ internal_ip }}:3306'        http_port: 8096        log: /app/logs/tarantooldb/router-2.log        vinyl_cache: 0        vinyl_memory: 0    router-3:      config:        advertise_uri: '{{ internal_ip }}:3307'        http_port: 8097        log: /app/logs/tarantooldb/router-3.log        vinyl_cache: 0        vinyl_memory: 0    router-4:      config:        advertise_uri: '{{ internal_ip }}:3308'        http_port: 8098        log: /app/logs/tarantooldb/router-4.log        vinyl_cache: 0        vinyl_memory: 0    router-5:      config:        advertise_uri: '{{ internal_ip }}:3309'        http_port: 8099        log: /app/logs/tarantooldb/router-5.log        vinyl_cache: 0        vinyl_memory: 0    router-6:      config:        advertise_uri: '{{ internal_ip }}:3310'        http_port: 8100        log: /app/logs/tarantooldb/router-6.log        vinyl_cache: 0        vinyl_memory: 0  vars:    ansible_ssh_common_args: -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null      -o StrictHostKeyChecking=no    ansible_ssh_retries: 5    cartridge_app_directory: /app/tarantool/tarantooldb    cartridge_app_group: tarantool    cartridge_app_name: tarantooldb    cartridge_app_user: tarantool    cartridge_bootstrap_vshard: true    cartridge_defaults:      log_level: 5      enable_synchro_mode: true    etcd_cluster_prefix: /cluster    cartridge_instances_templates:    - storage-[0-9]-[0-9]    - router-[0-9]    cartridge_keep_num_latest_dists: 10    cartridge_log_dir_parent: /app/logs/tarantooldb    cartridge_memtx_dir_parent: /app/snap/tarantooldb    cartridge_run_dir: /app/tarantool/tarantooldb/run    rhel8: true    cartridge_cluster_cookie: tarantooldb-test

Перед началом работы укажите в файле инвентаря значения этих переменных:

• {{ super_user }} — имя пользователя для подключения по SSH. Указывается в параметре ansible_user. Совпадает с переменной окружения SUPER_USER_NAME (см. Переменные окружения);
• {{ internal_ip }} — внутренний IP-адрес. Указывается в параметрах ansible_host и advertise_uri.

Разбить дисковое пространство необходимо согласно рекомендациям для оптимальной работы экземпляров Tarantool:

• журналы (logs) – 2 GB * количество экземпляров Tarantool, но не менее 15 GB;
• журнал упреждающей записи (WAL) – 40–50% от RAM, используемого всеми экземплярами Tarantool;
• снимки данных (snapshots) – 100–110% от RAM, используемого всеми экземплярами Tarantool.

Разбейте диски согласно расчетам и подключите директории с помощью команды mount. Дополнительная информация по расчету дисковой емкости приведена в соответствующем разделе.

См. документацию по инсталлятору Ansible Tarantool Enterprise, раздел Предварительная настройка сервера под Tarantool.

Для установки Ansible-коллекции инсталлятора Ansible Tarantool Enterprise требуется архив с инсталлятором ATE, полученный по почте или скачанный в личном кабинете tarantool.io из раздела ansible. Архив имеет вид tarantool-enterprise-<VERSION>.tar.gz, где VERSION — нужная версия инсталлятора ATE.

Установите Ansible-коллекцию, используя ansible-galaxy:

 
ansible-galaxy collection install --force tarantool-enterprise-${VERSION}.tar.gz

Роль tarantool.enterprise.os_configure выполняет следующие функции:

• определяет, поддерживается ли текущая операционная система;
• создает systemd unit-файлы в домашней директории пользователя tarantool.

ATE не использует механизм gather_facts по умолчанию, поэтому многие плейбуки начинаются с тасков find_os.yml для определения операционной системы. Добавьте вызов роли tarantool.enterprise.os_configure перед использованием других ролей из ATE:

 
- ansible.builtin.import_role:    name: tarantool.enterprise.os_configure    tasks_from: find_os.yml

Запуск роли целиком (main.yml) создаст unit-файлы.

 
- ansible.builtin.import_role:    name: tarantool.enterprise.os_configure

Есть специальный набор переменных, которые регулируют, каким образом запускаются плейбуки:

• tarantool_shared_become_user — выставляет значение переменной ansible_become_user. Значение по умолчанию: tarantool;
• tarantool_shared_become_method — выставляет значение переменной ansible_become_method. Значение по умолчанию: sudo;
• tarantool_shared_become — выставляет значение параметра become в плейбуках. Значение по умолчанию: true;
• tarantool_shared_hosts — выставляет значение параметра hosts в плейбуках. Значение по умолчанию в большинстве плейбуков — all, исключением являются сценарии для TCF.

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

Предположим, у вас в инвентаре есть группы ACTIVE и RESERVE, которые состоят из активных и резервных экземпляров Tarantool соответственно. Сложный сценарий обновления без простоя можно сделать так:

 
- name: Switch leaders to RESERVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.switch_leaders_to  vars:    tarantool_shared_hosts: "RESERVE"- name: Update ACTIVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.update_internal  vars:    tarantool_shared_hosts: "ACTIVE"- name: Wait for cluster to become healthy  ansible.builtin.import_playbook: tarantool.enterprise.wait_is_healthy  vars:    tarantool_shared_hosts: "all"- name: Return leaders to ACTIVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.switch_leaders_to  vars:    tarantool_shared_hosts: "ACTIVE"- name: Update RESERVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.update_internal  vars:    tarantool_shared_hosts: "RESERVE"- name: Wait for cluster to become healthy  ansible.builtin.import_playbook: tarantool.enterprise.wait_is_healthy  vars:    tarantool_shared_hosts: "all"

Аналогичный механизм реализован в плейбуке tarantool.enterprise.update_2x из коллекции.

Роль используется для работы с приложениями на Tarantool Cartridge.

Полностью вшитая open-source роль tarantool.cartridge. Документация доступна на GitHub.

Особенности использования в составе коллекции:

• Необходимо корректно указать путь до директории custom_steps/ в переменной cartridge_custom_steps_dir;
• Переменная cartridge_scenario должна быть объявлена и иметь тип List. Можно использовать переменную cartridge_scenario_name, чтобы указать исполняемую последовательность по умолчанию. В таком случае указывать cartridge_scenario нужно только при желании изменить стандартное исполнение.

Для установки Tarantool DB с помощью Docker-образа требуется архив с инсталлятором Ansible Tarantool Enterprise, полученный по почте или скачанный в личном кабинете tarantool.io из раздела ansible. Архив с инсталлятором имеет вид ansible-tarantool-enterprise-<VERSION>.tar.gz, где VERSION — нужная версия инсталлятора ATE.

Загрузите образ инсталлятора в Docker:

 
docker load -i ansible-tarantool-enterprise-${VERSION}.tar.gz

Чтобы упростить работу с Docker-образом, можно добавить для него тег latest:

 
docker image tag ansible-tarantool-enterprise:${VERSION} ansible-tarantool-enterprise:latest

Инструкция по запуску кластера через ATE приведена в разделе Запуск кластера через Ansible Tarantool Enterprise.

В документации встречаются следующие переменные окружения:

• DEPLOY_TOOL_VERSION_TAG (string) — версия инсталлятора;

• LIMIT (string) — указание Ansible, на каких хостах или группах хостов производить действия.

• PACKAGE_NAME (string) — название архива Tarantool DB;

• PATH_TO_INVENTORY (string) — полный путь к файлу инвентаря;

• PATH_TO_PACKAGE (string) — путь к архиву Tarantool DB;

• PATH_TO_PRIVATE_KEY (string) — полный путь к приватному ключу;

• SUPER_USER_NAME (string) — имя пользователя для подключения по SSH.

Дополнительные переменные окружения описаны в каждом пункте по мере необходимости.