[ English | русский | Indonesia ]

Настройка inventory¶

В этой главе вы найдете информацию о том, как настроить динамический inventory OpenStack-Ansible в соответствии с вашими потребностями.

Введение¶

Общие службы OpenStack и их конфигурация определяются OpenStack-Ansible в файле настроек /etc/openstack_deploy/openstack_user_config.yml.

Дополнительные службы следует определить с помощью файла YAML в /etc/openstack_deploy/conf.d, чтобы управлять размером файла.

Каталог /etc/openstack_deploy/env.d содержит все файлы YAML в развернутой среде, позволяя оператору определять дополнительные сопоставления групп. Этот каталог используется для расширения скелета среды или изменения значений по умолчанию, определенных в каталоге inventory/env.d.

Чтобы понять, как работает динамический inventory, см. Понимание inventory.

Предупреждение

Никогда не редактируйте и не удаляйте файл /etc/openstack_deploy/openstack_inventory.json. Это может привести к проблемам с inventory: существующие хосты и контейнеры будут неуправляемыми, а вместо них будут созданы новые, что нарушит существующее развертывание.

Ограничения конфигурации¶

Членство в группах¶

При добавлении групп помните следующее:

Группа может содержать хосты
Группа может содержать дочерние группы

Однако, группы не могут содержать дочерние группы и хосты.

Группа lxc_hosts¶

Когда сценарий динамического inventory создает имя контейнера, хост, на котором находится контейнер, добавляется в группу inventory lxc_hosts.

Использование этого имени для группы в конфигурации приведет к ошибке выполнения.

Развертывание непосредственно на хостах¶

Чтобы развернуть компонент непосредственно на хосте, а не в контейнере, установите свойство is_metal в значение true для группы контейнеров в разделе container_skel в соответствующем файле.

Использование container_vars и сопоставление групп контейнеров с группами хостов осуществляется одинаково для службы, развернутой непосредственно на хосте.

Вы также можете использовать опцию no_containers, чтобы указать хост, на котором будут развернуты все службы.

Примечание

Компонент cinder-volume по умолчанию развертывается непосредственно на хосте. См. файл env.d/cinder.yml для этого примера.

Пример: запуск всех контроллеров без контейнеров¶

Например, если вы хотите запустить все свои контроллеры на bare metal, вам нужно будет добавить в файл openstack_user_config.yml следующее.

infra_hosts:
  infra1:
    ip: 172.39.123.11
    no_containers: true
  infra2:
    ip: 172.39.123.12
    no_containers: true
  infra3:
    ip: 172.39.123.13
    no_containers: true

Пример: запуск Galera на выделенных хостах¶

Например, чтобы запустить Galera непосредственно на выделенных хостах, вам необходимо выполнить следующие шаги:

Измените раздел container_skel файла env.d/galera.yml. Например:
```
container_skel:
  galera_container:
    belongs_to:
      - db_containers
    contains:
      - galera
    properties:
      is_metal: true
```
Примечание

Для развертывания в контейнерах на этих выделенных хостах уберите свойство is_metal: true.
Назначьте группу контейнеров db_containers (из предыдущего шага) группе хостов, предоставив раздел physical_skel для группы хостов в новом или существующем файле, например env.d/galera.yml. Например:
```
physical_skel:
  db_containers:
    belongs_to:
      - all_containers
  db_hosts:
    belongs_to:
      - hosts
```
Определите группу хостов (db_hosts) в файле conf.d/ (например, galera.yml). Например:
```
db_hosts:
  db-host1:
    ip: 172.39.123.11
  db-host2:
    ip: 172.39.123.12
  db-host3:
    ip: 172.39.123.13
```
Примечание

Каждое из имен пользовательских групп в этом примере (db_containers и db_hosts) является произвольным. Выберите собственные имена групп, но убедитесь, что ссылки согласованы во всех соответствующих файлах.

Добавление вложенных виртуальных групп¶

Если вы хотите создать пользовательскую группу для произвольного объединения хостов и контейнеров внутри этих хостов, но пропустить генерацию новых контейнеров, вам следует использовать свойство is_nest в container_skel и пропустить определение структуры belongs_to. Свойство is_nest добавит хост-контейнеры в качестве дочерних элементов в такую группу.

Пример: определение зон доступности¶

Хорошим примером использования свойства is_nest является описание зон доступности. Так как при работе с несколькими AZ удобно определять переменные, специфичные для AZ, например имя AZ, для всех хостов в этой AZ. А использование group_vars — лучший способ гарантировать, что все хосты, принадлежащие к одной AZ, будут иметь одну и ту же конфигурацию.

Предположим, у вас есть 3 контроллера, и каждый из них размещен в разных Зонах доступности. В каждой Зоне доступности также есть вычислительный узел. И мы хотим, чтобы каждый хост или контейнер, который физически размещен в определенной AZ, был частью своей собственной группы (т. е. azN_all)

Для этого нам необходимо:

Определите группы хостов в conf.d или openstack_user_config.yml, чтобы назначить хосты в соответствии с их зонами доступности:

az1_infra_hosts: &infra_az1
  az1-infra1:
    ip: 172.39.123.11

az2_infra_hosts: &infra_az2
  az2-infra2:
    ip: 172.39.123.12

az3_infra_hosts: &infra_az3
  az3-infra3:
    ip: 172.39.123.13

shared_infra_hosts: &controllers
  <<: *infra_az1
  <<: *infra_az2
  <<: *infra_az3

az1_compute_hosts: &computes_az1
  az1-compute01:
    ip: 172.39.123.100

az2_compute_hosts: &computes_az2
  az2-compute01:
    ip: 172.39.123.150

az3_compute_hosts: &computes_az3
  az3-compute01:
    ip: 172.39.123.200

compute_hosts:
  <<: *computes_az1
  <<: *computes_az2
  <<: *computes_az3

az1_hosts:
  <<: *computes_az1
  <<: *infra_az1

az2_hosts:
  <<: *computes_az2
  <<: *infra_az2

az3_hosts:
  <<: *computes_az3
  <<: *infra_az3

Создайте файл env.d/az.yml, который будет использовать свойство is_nest и позволит всем инфраструктурным контейнерам быть частью группы AZ

component_skel:
  az1_containers:
    belongs_to:
      - az1_all
  az1_hosts:
    belongs_to:
      - az1_all

  az2_containers:
    belongs_to:
      - az2_all
  az2_hosts:
    belongs_to:
      - az2_all

  az3_containers:
    belongs_to:
      - az3_all
  az3_hosts:
    belongs_to:
      - az3_all

container_skel:
  az1_containers:
    properties:
      is_nest: true
  az2_containers:
    properties:
      is_nest: true
  az3_containers:
    properties:
      is_nest: true

Теперь вы можете использовать файл group_vars, чтобы применить переменную ко всем контейнерам и хостам bare metal в AZ. Например, /etc/openstack_deploy/group_vars/az1_all.yml:
```
---
az_name: az1
cinder_storage_availability_zone: "{{ az_name }}"
```

Развертывание без указания типа компонента на хост (или более одного)¶

Когда OpenStack-Ansible генерирует свой динамический inventory, настройка соответствия определяет, сколько контейнеров аналогичного типа развернуто на одном физическом хосте.

Using shared_infra_hosts as an example, consider this openstack_user_config.yml configuration:

shared_infra_hosts:
  infra1:
    ip: 172.29.236.101
  infra2:
    ip: 172.29.236.102
  infra3:
    ip: 172.29.236.103

Three hosts are assigned to the shared_infra_hosts group, OpenStack-Ansible ensures that each host runs a single database container, a single Memcached container, and a single RabbitMQ container. Each host has an affinity of 1 by default, which means that each host runs one of each container type.

Если вы развертываете автономное объектное хранилище (swift), вы можете пропустить развертывание RabbitMQ. Если вы используете эту конфигурацию, ваш файл openstack_user_config.yml будет выглядеть следующим образом:

shared_infra_hosts:
  infra1:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.101
  infra2:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.102
  infra3:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.103

В этой конфигурации на каждом хосте развертываются контейнер Memcached и контейнер базы данных, но не контейнеры RabbitMQ.

Исключить службу или компонент из развертывания¶

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

Удалите связь physical_skel между группой контейнеров и группой хостов, удалив соответствующий файл, расположенный в каталоге env.d/.
Не запускайте плейбук, который устанавливает компонент. Если вы не укажете компонент для запуска непосредственно на хосте с помощью свойства is_metal, для этого компонента будет создан контейнер.
Измените Добавление вложенных виртуальных групп на 0 для группы хостов. Подобно второму варианту, указанному здесь, если вы не указали компонент для непосредственного запуска на хосте с помощью свойства is_metal, для этого компонента создается контейнер.

Наличие сети SSH, отличной от сети управления OpenStack¶

В некоторых средах сеть SSH, используемая для доступа к узлам с хоста развертывания, и сеть управления различаются. В этом случае важно, чтобы службы прослушивали правильную сеть, а Ansible использовал сеть SSH для доступа к управляемым хостам. В этих случаях вы можете определить ключ management_ip при определении хостов в файле openstack_user_config.yml.

management_ip будет использоваться как management_address для узла, в то время как ip будет использоваться как ansible_host для доступа к узлу по SSH.

Пример:

shared_infra_hosts:
  infra1:
    ip: 192.168.0.101
    management_ip: 172.29.236.101

Настройка inventory

Настройка inventory¶

Введение¶

Ограничения конфигурации¶

Членство в группах¶

Группа lxc_hosts¶

Развертывание непосредственно на хостах¶

Пример: запуск всех контроллеров без контейнеров¶

Пример: запуск Galera на выделенных хостах¶

Добавление вложенных виртуальных групп¶

Пример: определение зон доступности¶

Развертывание без указания типа компонента на хост (или более одного)¶

Исключить службу или компонент из развертывания¶

Наличие сети SSH, отличной от сети управления OpenStack¶

openstack-ansible 32.1.0.dev90

Page Contents