[ English | Deutsch | русский | English (United Kingdom) | 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, настройка соответствия определяет, сколько контейнеров аналогичного типа развернуто на одном физическом хосте.

Используя shared-infra_hosts в качестве примера, рассмотрим следующую конфигурацию openstack_user_config.yml:

shared-infra_hosts:
  infra1:
    ip: 172.29.236.101
  infra2:
    ip: 172.29.236.102
  infra3:
    ip: 172.29.236.103

Три хоста назначаются в группу shared-infra_hosts, OpenStack-Ansible гарантирует, что каждый хост запускает один контейнер базы данных, один контейнер Memcached и один контейнер RabbitMQ. Каждый хост имеет значение affinity 1 по умолчанию, что означает, что каждый хост запускает один контейнер каждого типа.

Если вы развертываете автономное объектное хранилище (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 31.1.1.dev1

Page Contents