Описание переменных окружения для установки через AccentOS Firstboot

Работа с репозиториями

  • Импорт GPG-ключей для авторизации репозитория пакетов ПО:

    APTKEY0
    …
    APTKEY999
    

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

    Пример:

    export APTKEY0="http://$REPO_IP/train-accentos-sign/dists/train-accentos/pubkey.gpg"
    
  • Формирование файла /etc/apt/sources.list с определениями расположения репозиториев:

    REPO0
    …
    REPO999
    

    Пример:

    export REPO0="deb http://$REPO_IP/smolensk smolensk contrib main non-free"
    export REPO1="deb http://$REPO_IP/devel-smolensk smolensk contrib main non-free"
    export REPO6="deb http://$REPO_IP/train-accentos-sign train-accentos contrib main non-free"
    export REPO9="deb http://$REPO_IP/update202111-smolensk smolensk contrib main non-free"
    export REPO10="deb http://$REPO_IP/devel-update202111-smolensk smolensk contrib main non-free"
    
  • Отключение интерактивной установки пакетов debian:

    export DEBIAN_FRONTEND="noninteractive"
    
  • Установка часового пояса.

    Переменная TIMEZONE_FILE предназначена для указания актуального часового пояса и заполняется в формате расположения файла, соответствующего часовому поясу территориального расположения серверов.

    Пример:

    export TIMEZONE_FILE=Europe/Moscow
    
  • Определение настроек сети развертывания.

    Префикс сети размещения узлов облака указывается в переменной NET:

    export NET=10.40.21
    

Примечание

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

  • Сетевая конфигурация вычислительных узлов.

    Определение подчиненных сетевых интерфейсов, объединяемых в единый интерфейс bond:

    export BOND_SLAVES=""
    

    Тип объединения сетевых интерфейсов: lacp или active-backup:

    export BOND_MODE="lacp"
    

    Установка длины сетевых пакетов (MTU). Данный параметр напрямую зависит от настройки сетевого оборудования. Рекомендуется снижать до стандартного значения 1500 при вероятном обращении вычислительных узлов к сторонним службам сети, на которых используются стандартные значения:

    #export MTU=9000
    export MTU=1500
    
  • Настройки DNS.

    Временная зона DNS - зона расположенная на сервере Cobbler. Используется только на этапе установки операционных систем физических и виртуальных серверов:

    export DNS_ZONE=test.loc
    

    Прямая зона DNS облака формируется на базе переменной CLOUD_ZONE:

    export CLOUD_ZONE=accentos.loc
    

    На базе переменной DNS_REVERSE_ZONE формируется обратная зона облака:

    export DNS_REVERSE_ZONE=21.40.10.in-addr.arpa
    

    Определение расположения DNS-серверов:

    export CLOUD_DNS1=$NET.221
    export CLOUD_DNS2=$NET.222
    export CLOUD_DNS3=$NET.223
    

    В случае необходимости добавления дополнительных внешних зон можно воспользоваться скриптом install_bind9-forward-zone.

    Скрипт должен запускаться после скрипта установки bind9 и добавляет дополнительные зоны типа forward. Внешние зоны добавляются по одной в каждой переменной в формате перечисления в строке имени зоны и до четырех IP-адресов DNS-серверов. Номера переменных для указания внешних зон могут быть любыми в пределах от 0 до 999:

    export FORWARD_DNS_ZONE0="tnxos.loc 10.40.116.1 10.40.116.2"
    export FORWARD_DNS_ZONE2="stand.loc 10.40.116.1 10.40.116.2"
    
  • Настройки NTP:

    # сервера времени облака для взаимной синхронизации
    export CLOUD_NTP1=$NET.221
    export CLOUD_NTP2=$NET.222
    export CLOUD_NTP3=$NET.223
    export EXTERNAL_NTP=ru.pool.ntp.org
    

    При назначении переменной EXTERNAL_NTP непустого значения приводит к назначению данного значения как источника для серверов указанных в переменных CLOUD_NTP1, CLOUD_NTP2 и CLOUD_NTP3, которые в свою очередь являются источниками для остальных узлов облака.

    На момент написания данного документа алгоритм порядка синхронизации серверов следующий:

    • при задании значения переменной EXTERNAL_NTP - он прописывается как источник на серверах, прописанных в переменных CLOUD_NTP1, CLOUD_NTP2, CLOUD_NTP3.
    • если в качестве EXTERNAL_NTP указан один из серверов облака, ему назначается значение stratum равное 8 и время этого сервера используется как эталон. Данный вариант можно использовать при работе облака в изолированной среде.
    • для серверов, не указанных в переменных EXTERNAL_NTP, CLOUD_NTP1, CLOUD_NTP2, CLOUD_NTP3 в качестве источников используются непустые значения CLOUD_NTP1, CLOUD_NTP2, CLOUD_NTP3. Если все 3 переменные имеют пустое значение, то в качестве источника назначается значение переменной EXTERNAL_NTP.

    Таким образом рекомендуется заполнить переменную EXTERNAL_NTP либо адресов внешнего источника, либо адресом одного из серверов. Это может быть один серверов указанных в переменных CLOUD_NTP1, CLOUD_NTP2, CLOUD_NTP3. После чего задать значения переменным CLOUD_NTP1, CLOUD_NTP2, CLOUD_NTP3 (необязательно все).

  • Создание системы хранения на базе Ceph.

    Настройка Ceph заключается в объявлении адресов серверов мониторов Ceph, а также в объявлении размещения дисков под Ceph OSD на серверах.

    Адреса мониторов Ceph объявляются в виде IP-адресов через пробел. Число мониторов рекомендуется нечетным от 3 и выше:

    export CEPH_IPS="$NET.221 $NET.222 $NET.223"
    

    Формат объявления Ceph OSD заключается в назначении переменным CEPH_OSD0..CEPH_OSD999 значений в виде перечисления через пробел IP-адреса сервера и блочное устройство, которым может быть как физическое блочное устройство целиком, так и раздел устройства:

    export CEPH_OSD0="$NET.221 /dev/nvme0n1p4"
    export CEPH_OSD1="$NET.222 /dev/nvme0n1p4"
    export CEPH_OSD2="$NET.223 /dev/sda4"
    

    На всех серверах в настройках firstboot должен быть объявлен к выполнению скрипт install_ceph-cluster.

  • Глобальные настройки облака:

    # глобальный пароль
    export PASSWORD=qwertyuiop
    # имя и адрес сервера cobbler
    export COBBLER_HOST=cobbler.test.loc
    export COBBLER_IP=10.40.21.4
    

    Подключение ISCSI дисков

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

    Переменные TARGET_IP0..TARGET_IP999 должны иметь адреса и порты iscsi-серверов, на которых будут затребованы доступные таргеты для подключения:

    export TARGET_IP1=10.40.21.18:3260
    

    Переменные TARGET0..TRAGET999 должны иметь имена таргетов, которые должны быть представлены в сервере:

    export TARGET1=iqn.2007-02.com.example:nova
    export TARGET2=iqn.2007-02.com.example:glance
    export TARGET3=iqn.2007-02.com.example:gnocchi
    

    Так как имена дисков при каждом включении сервера могут быть меняться в зависимости от очередности текущего подключения, рекомендуется для решения данного вопроса запускать multipath.

  • Настройка кластера OCFS2.

    В устанавливаемом облаке может быть заявлено несколько непересекающихся кластеров OCFS2. Но каждая операционная система может быть в составе только одного кластера OCFS2. В случае пересечения 2х кластеров OCFS2 хотя бы на одном сервере, они должны быть объединены в один. Для каждого кластера переменные OCFS2_IPS и OCFS2_CLUSTER_NAME должны быть объявлены для всех узлов кластера. OCFS2_CLUSTER_NAME должно иметь уникальное значение для каждого кластера.

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

    export OCFS2_IPS="$NET.221 $NET.222 $NET.223"
    export OCFS2_CLUSTER_NAME=ocfs2
    export OCFS2_DRIVE=/dev/mapper/360000000000000000e00000000030001
    

    Кластер OCFS2 может быть использован для размещение дисков nova, для хранения образов glance и так далее.

    В общем случае создается один кластер OCFS2 для контроллеров и один или несколько кластеров OCFS2 для вычислительных узлов. Из-за высокой вероятности, что диски с файловой системой OCFS2 могут быть доступны и на других узлах файловые системы должны форматироваться с параметром –global-heartbeat, а каждой системе присваивается номер равный последнему октету IP-адреса для уникальности в рамках локальной сети. Объявление нескольких кластеров OCFS2 осуществляется либо созданием файлов со всем списком переменных для отдельных групп серверов, либо созданием общего файла с одинаковыми значениями переменных и различных файлов для отдельных групп серверов для различающихся значений переменных.

  • Использование VDO.

    Использование VDO в операционной системе Linux Astra возможно с ядром 5.10. Для этого используется скрипт install_vdo. Перед его запуском необходимо загрузить конфигурацию в виде списка переменных окружения.

    Для Debian пакеты для поддержки VDO отсутсвуют.

    Примеры настройки диска VDO

    Пример 1:

    export VDO0_DRIVE=/dev/vdс
    export VDO0_NAME=vdo-lvm
    export VDO0_N=8
    export VDO0_VG=vdo_name
    export VDO0_LV0_SIZE=100G
    export VDO0_LV1_SIZE=100G
    export VDO0_LV0_NAME=nova
    export VDO0_LV1_NAME=zun
    export VDO0_LV1_FS=xfs
    export VDO0_LV0_MOUNT=/var/lib/nova/instances
    export VDO0_LV1_MOUNT=/var/lib/docker
    

    В данном примере объявляется создание VDO диска vdo-lvm на базе блочного устройства, объявленного в переменной VDOn_DRIVE. Переменные могут иметь вид VDO0_DRIVE..VDO999_DRIVE. Если блочное устройство найдется, будет инициировано создание VDO диска с именем, указанным в переменной VDOn_NAME. Объем VDO диска будет заявлен размером более в VDOn_N раз больше, чем базовое блочное устройство. Коэффициент стоит выбирать исходя из планируемого характера данных - чем выше вероятность повторения хранимых данных, тем выше стоит сделать коэффициент. При наличии непустой переменной VDOn_VG будет создан LVM VG с именем указанной в данной переменной. После создания МП возможно создание LV и монтирование созданных логических дисков в систему. При монтировании вновь созданных логических дисков создается файловая система ext4, при желании можно использовать файловую систему xfs указав в переменной VDOn_LVx_FS=xfs. Имя LV и размер указываются соответственно в переменных VDOn_LVx_NAME и VDOn_LVx_SIZE.

    Пример 2

    Если в переменных не указываются данные по логическим дискам, то настройка будет ограничена созданием VG, например это удобно при настройке cinder-volume:

    export VDO1_DRIVE=/dev/vdb
    export VDO1_NAME=vdo-cinder
    export VDO1_N=20
    export VDO1_VG=cinder_volumes
    

    Пример 3

    Если создание использование LVM на VDO диске не актуально, то можно ограничиться созданием файловой системы на весь VDO диск без разбиения виртуального блочного устройства:

    export VDO2_DRIVE=/dev/vdd
    export VDO2_NAME=vdo-opt
    export VDO2_N=5
    export VDO2_MOUNT=/opt
    export VDO2_FS=xfs
    

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

    Рекомендации по выбору файловой системы:

    Для некоторых проектов Openstack ВАЖНО получить файловую систему с определенным функционалом. К примеру для OpenStack Zun, использующий квоты, лучшим выбором будет файловая система xfs и так далее.

Распределение служб облака по физическим и виртуальным серверам

Соответствие IP-адреса каждому физическому и виртуальному серверу определяется на уровне службы Cobbler.

  • Конфигурация высокой доступности.

    Конфигурация высокой доступности предполагает сохранение работоспособности при выходе из строя любого контроллера или узла базы данных. Для этого формируется минимум 3 контроллера и минимум 3 узла базы данных. Количество контроллеров или узлов БД может быть больше, но это число рекомендуется поддерживать нечетным, чтобы при разрыве и дальнейшем восстановлении связности сети большее число узлов формировало кворум для разрешения конфликтных ситуаций. Так же далее следуют рекомендации по комбинации служб на каждом хосту, но данные рекомендации не являются обязательными к исполнению и отдельные службы (Redis, RabbitMQ, etcd и т.д.) могут быть установлены на отдельные виртуальные или физические хосты.

    Адреса контроллеров Openstack:

    export CONTROLLER_IPS="$NET.234 $NET.235 $NET.236"
    

    Каждый контроллер Openstack по факту является самостоятельным и взаимодействует с остальными через сторонние службы (Redis, MariaDB, RabbitMQ и т.д.). При нормальном функционировании нагрузка на службы OpenStack распределяется балансировщиками haproxy, основываясь на задержке ответа. При недоступности одного контроллера другие контроллеры полностью заберут на себя всю нагрузку, ранее выполняемую неработоспособным контроллером.

    Имя контроллера облака - данное DNS имя является служебным и используется для доступа к контроллерам через балансировщик запросов. На тех узлах, которые используют локальный балансировщик, данное имя определяется на один из адресов localhost:

    export CONTROLLER_NAME=controller.$CLOUD_ZONE
    
  • Служба Memcache.

    На контроллерах обязательно должна устанавливаться и запускаться служба memcached. Для установки данной службы используется отдельный скрипт install_memcache, но отдельного имени для данной службы не назначается. В при настройке балансировщиков haproxy для данной службы используются адреса, указанные в переменной CONTROLLER_IPS, а при настройке конфигурационных файлов служб OpenStack указывается имя из переменной CONTROLLER_NAME.

    Адреса балансировщика внешних запросов haproxy:

    export HAPROXY_IPS="$NET.231 $NET.232 $NET.233"
    

    Данный балансировщик не используется для запросов с серверов облака. На каждый вычислительный узел и контроллер ставится свой балансировщик. Данный балансировщик не занимается балансировкой нагрузки для MariaDB, RabbitMQ, etcd и Redis.

  • Адреса кластера базы данных MariaDB.

    Рекомендуется устанавливать совместно с балансировщиком haproxy для глобальных запросов:

    export MYSQL_IPS="$NET.231 $NET.232 $NET.233"
    

    Кластер не балансируется haproxy для глобальных запросов и имеет свое служебное имя mysql в DNS-зоне, объявленной в переменной. На каждом ВУ и контроллере работоспособность кластера отслеживается с помощью локально установленного haproxy с целью максимально быстрого переключения с неработающего узла на работающий.

  • Адреса кластера службы очередей сообщений RabbitMQ.

    Рекомендуется устанавливать совместно с балансировщиком haproxy для глобальных запросов:

    export RABBITMQ_IPS="$NET.232 $NET.231 $NET.233"
    

    Кластер не балансируется haproxy и имеет свое служебное имя rabbitmq в DNS-зоне, объявленной в переменной На каждом ВУ и контроллере работоспособность кластера отслеживается с помощью локально установленного haproxy с целью максимально быстрого переключения с неработающего узла на работающий.

  • Адреса кластера etcd.

    Etcd используется для doker под управлением OpenStack Zun и рекомендуется к установке совместно с балансировщиком haproxy для глобальных запросов:

    export ETCD_IPS="$NET.231 $NET.232 $NET.233"
    

    Кластер не балансируется haproxy и имеет свое служебное имя etcd в DNS-зоне, объявленной в переменной. На каждом ВУ и контроллере работоспособность кластера отслеживается с помощью локально установленного haproxy с целью максимально быстрого переключения с неработающего узла на работающий.

  • Адреса БД Redis.

    База данных Redis c размещением данных в памяти используется AccentOS и рекомендуется к установке на контроллерах:

    export REDIS_IPS="$NET.234 $NET.235 $NET.236"
    
  • Адреса и настройки Consul.

    Инфраструктура Consul состоит из узлов, выполняющих серверную часть в кластере, и узлов, выполняющих функцию агента. Поэтому скрипт установки должен запускать на каждом узле, но активация серверной функции происходит только на узлах определенных в нижеуказанных настройках.

    Список узлов-серверов - обязательно в общих кавычках и каждый сервер в экранированных кавычках:

    export CONSUL_SERVERS="\"$NET.221\",\"$NET.222\",\"$NET.223\""
    

    Домен для узлов consul:

    export CONSUL_DOMAIN=consul
    

    Название датацентра, сформированного на базе серверов Consul:

    export CONSUL_DATACENTER="DC1"
    

    Пароль авторизации для синхронизации данных между узлами consul. Генерация пароля реализуется командой «consul keygen»:

    export CONSUL_SECRET="bnRHLmJ6TeLomirgEOWP2g=="
    

Настройки отдельных модулей Openstack

Keystone

Время действия токена KEYSTONE, которое по умолчанию 3600 (1 час):

export KEYSTONE_TOKEN_EXPIRATION=3600

Glance

Использование внешнего диска (iscsi или fibre channel) или отдельного блочного устройства.

Такой подход позволяет подключить более ёмкий сетевой диск для хранения образов или диск с поддержкой сжатия иили дедупликации (vdo, zfs или иное аппаратное обеспечение). Учитывая, что могут быть созданы образы различного целевого назначения на базе одной операционной системы, подобный подход может значительно удешевить стоимость хранения информации.

Имя устройства на стороне физического узла, используемого как гипервизор для виртуальной машины с установленным OpenStack Glance. Данное имя используется только для подключения блочного устройства к виртуальной машине с контроллером.

Пример устройства с multipath:

export GLANCE_DRIVE=/dev/mapper/360000000000000000e00000000010001

Пример блочного устройства LVM:

export GLANCE_DRIVE=/dev/mapper/lvm-glance

Пример отдельного физического диска:

export GLANCE_DRIVE=/dev/sdb

При подключении блочного устройства напрямую к виртуальной машине, минуя физический сервер, используемый в качестве гипервизора, например по ISCSI или при работе службы Glance непосредственно на физическом сервере - переменная должна быть пустой.

Использование сетевых ресурсов совместно с кластерной файловой системой позволяет одновременно использовать одно хранилище на нескольких контроллерах с целью повышения надежности и производительности службы. В AccentOS Firstboot создана поддержка файловой системы ext4 при работе только одного экземпляра службы Glance в составе облака и кластерной файловой системы ocfs2 при одновременном использовании нескольких экземпляров службы Openstack Glance:

export GLANCE_DRIVE_FS=ocfs2

Имя блочного устройства, монтируемого в систему внутри физического или виртуального сервера.

Имя может указываться как без указания префикса /dev, так и без него. Данное имя используется при монтировании блочного устройства в корневую файловую систему. Определение фактического имени внутри операционной системы сервера лежит на администраторе, так оно оно может зависеть от многих факторов и не соответствовать указанному явно в libvirt xml для виртуальной машины. Данный диск монтируется в папку /var/lib/glance/image.

Пример использования на виртуальной машине:

export GLANCE_DRIVE_MAPPED=vdb

Пример использования на физической машине с дополнительным жестким диском или сетевым диском без использования multipath:

export GLANCE_DRIVE_MAPPED=sdb

Пример использования диска multipath на физическом или виртуальном сервере. В случае виртуальной машины блочное устройство подключается напрямую, минуя гипервизор, например, по ISCSI:

export GLANCE_DRIVE_MAPPED=/mapper/360000000000000000e00000000010001

Принудительное форматирование выделенного блочного устройства. Форматирование осуществляется при явном указании в переменной ENABLE_CLEAR_GLANCE_DRIVE и одновременном создании базы данных для службы OpenStack Glance. Т.е. при пересоздании отдельного контроллера в конфигурации HA очистка диска проводиться не должна при доступной БД. Также при восстановлении конфигурации для сохранения содержимого образов Glance очистку можно явно запретить, если планируется дальнейшее восстановление содержимого БД:

export ENABLE_CLEAR_GLANCE_DRIVE=yes

Примечание

Код форматирования в скриптах в настоящий момент закомментирован!

Gnocchi

Использование внешнего диска (iscsi или fibre channel) или отдельного блочного устройства.

Такой подход позволяет подключить более ёмкий сетевой диск для хранения образов или диск с поддержкой сжатия иили дедупликации (vdo, zfs или иное аппаратное обеспечение). Учитывая, что могут быть созданы образы различного целевого назначения на базе одной операционной системы, подобный подход может значительно удешевить стоимость хранения информации. Имя устройства на стороне физического узла, используемого как гипервизор для виртуальной машины с установленным OpenStack Gnocchi. Как правило данное имя используется для подключения блочного устройства к виртуальной машине с контроллером.

Пример определения блочного устройства multipath:

export GNOCCHI_DRIVE=/dev/mapper/360000000000000000e00000000020001

Использование сетевых ресурсов совместно с кластерной файловой системой позволяет одновременно использовать одно хранилище на нескольких контроллерах с целью повышения надежности и производительности службы. В AccentOS Firstboot создана поддержка файловой системы ext4 при работе только одного экземпляра службы Gnocchi в составе облака и кластерной файловой системы ocfs2 при одновременном использовании нескольких экземпляров службы Openstack Gnocchi.

Пример определения файловой системы ocfs2:

export GNOCCHI_DRIVE_FS=ocfs2

Имя блочного устройства, монтируемого в систему внутри физического или виртуального сервера.

Имя может указываться как без указания префикса /dev, так и без него. Данное имя используется при монтировании блочного устройства в корневую файловую систему. Определение фактического имени внутри операционной системы сервера лежит на администраторе, так оно оно может зависеть от многих факторов и не соответствовать указанному явно в libvirt xml для виртуальной машины. Данный диск монтируется в папку /var/lib/glance/image:

export GNOCCHI_DRIVE_MAPPED=vdc

Принудительное форматирование выделенного блочного устройства.

Форматирование осуществляется при явном указании в переменной ENABLE_CLEAR_GNOCCHI_DRIVE и одновременном создании базы данных для службы Openstack Glance. Т.е. при пересоздании отдельного контроллера в конфигурации HA очистка диска проводиться не должна при доступной БД. Также при восстановлении конфигурации для сохранения содержимого образов Glance очистку можно явно запретить, если планируется дальнейшее восстановление содержимого БД:

export ENABLE_CLEAR_GNOCCHI_DRIVE=yes

Примечание

Код форматирования в скриптах в настоящий момент закомментирован!

Nova

Имя устройства на стороне физического узла, используемого как гипервизор для запуска виртуальных машин с помощью установленного OpenStack Nova. Как правило данное имя используется для подключения блочного устройства к виртуальной машине с контроллером. Данный диск монтируется в папку /var/lib/nova/instances. Пустое значение означает, что будет использоваться диск, на котором расположена папка /var/lib/nova - размещение данной или вышестоящей папки может быть определено при создании операционной системы:

export NOVA_DRIVE=/dev/mapper/360000000000000000e00000000030001

Определение типа файловой системы.

В настоящий момент поддерживаются файловая система ext4 для индивидуального подключения блочного устройства к вычислительному узлу или кластерная файловая система ocfs2 для подключения общего хранилища к двум и более вычислительным узлам.

Пример подключения файловой системы ocfs2:

export NOVA_DRIVE_FS=ocfs2

Neutron

Установка количества сетевых агентов по умолчанию:

export NEUTRON_DHCP_AGENTS_COUNT=2

Данный параметр указывает количество DHCP-агентов и, соответственно, агентов метаданных.

Настройка DVR (распределенного роутера).

При выключенном режиме DVR весь исходящий трафик виртуальной сети во внешнюю сеть, идущий через виртуальные маршрутизаторы OpenStack с целью подмены адреса (NAT), проходит через определенный сервер или сервера, на которых располагаются L3-агенты. Это могут быть как контроллеры, так и ВУ, так как L3-агенты запускаются и там, и там. Количество используемых серверов зависит от типа маршрутизатора - для работы обычного маршрутизатора используется только 1 агент, для работы маршрутизатора высокой доступности - 3. Выбор конкретного агента для каждого виртуального маршрутизатора производится автоматически при создании виртуального маршрутизатора. Недостатком является высокое потребление ресурсов при высоком объеме сетевого трафика и рост сетевого отклика при неспособности оперативно транслировать весь проходящий трафик через L3- агента:

export DVR=no

При включении режима распределенного маршрутизатора исходящий трафик может подменить ВУ с запущенным L3-агентом и на котором запущена виртуальная машина, но обратный трафик транслируется как правило всеми ВУ, до которого дойдет ответный на запрос пакет. Данный режим несовместим с частью служб Openstack, например, с сетевым балансировщиком Octavia:

export DVR=yes

Zun

В настоящий момент реализовано использование на блочном устройстве ceph.

Название пула Ceph, в котором будет создано целевое блочное устройство RBD, которое затем будет примонтировано к операционной системе:

export DOCKER_POOL_NAME=volumes

Создаваемый размер блочного устройства для каждого ВУ:

export DOCKER_POOL_SIZE=30720

Алгоритм создания и подключения блочного устройства на сегодня реализован такой: на каждом вычислительном узле проверяется наличие конфигурации ceph на вычислительном узле и при положительном результате поиска создается блочное устройство с требуемым размером, которое настраивается для автоматического подключения и монтирования к операционной системе при запуске.

Используемый формат хранилища для Linux Astra Smolensk 1.6 - lvm, для Astra Linux Smolensk 1.7 - overlay2, который далее будет использоваться для всех версий дистрибутивов.

Если конфигурация Ceph не будет найдена - дополнительного блочного устройства подключено не будет. Как результат не будет доступно использование квот и гарантии работоспособности данной службы не будет.

Octavia

Данный проект в рамках Openstack предназначен для создания службы сетевого балансирования нагрузки для других служб, например требуется для работы OpenStack Magnum.

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

export OCTAVIA_MGMT_SUBNET=172.16.0.0/12

Диапазон выдаваемых адресов:

export OCTAVIA_MGMT_SUBNET_START=172.16.0.100
export OCTAVIA_MGMT_SUBNET_END=172.16.31.254

Список IP адресов, назначаемых агентам на контроллерах (по одному на каждый контроллер):

export OCTAVIA_MGMT_PORT_IP="172.16.0.2 172.16.0.3 172.16.0.4"

Настройка модулей AccentOS

Имя пользователя AOS для подключения к БД и другим службам:

export AOS_USER=aos

Пароль пользователя модулей AOS.

Пример явного назначения пароля:

export AOS_PASSWORD=password

Пример использования пароля по умолчанию:

export AOS_PASSWORD=$PASSWORD
export AOS_RABBIT_VHOST=aos

Для модулей AccentOS требуется предварительная установка Redis.

Устаревшие параметры:

Определение менеджера запуска служб Openstack и взаимосвязанных с ним служб. По умолчанию используется systemd. Возможной альтернативой является firstboot. Менеджер должен определять порядок запуска служб Openstack, настройку и запуск служб обслуживающих Openstack, если порядок этих служб важен для успешной работы:

#BOOT_MANAGER=firstboot
export BOOT_MANAGER=systemd

Изначально Firstboot был нацелен на использование Ceph в качестве сетевого хранилища:

export SHARED_DRIVE="ceph"
#export SHARED_DRIVE="fc"

В дальнейшем будет осуществляться отказ от данной переменной в целью настройки каждой службы OpenStack на использование отдельного сетевого хранилища данных. Например, Cinder может использовать несколько типов хранилищ, Nova - свой тип хранилища и так далее.