Описание переменных окружения для установки через 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 - свой тип хранилища и так далее.