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

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

  Определение подчиненных сетевых интерфейсов, объединяемых в единый интерфейс 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¶

export KEYSTONE_TOKEN_EXPIRATION=3600

export GLANCE_DRIVE=/dev/mapper/360000000000000000e00000000010001

export GLANCE_DRIVE=/dev/mapper/lvm-glance

export GLANCE_DRIVE=/dev/sdb

export GLANCE_DRIVE_FS=ocfs2

export GLANCE_DRIVE_MAPPED=vdb

export GLANCE_DRIVE_MAPPED=sdb

export GLANCE_DRIVE_MAPPED=/mapper/360000000000000000e00000000010001

export ENABLE_CLEAR_GLANCE_DRIVE=yes

export GNOCCHI_DRIVE=/dev/mapper/360000000000000000e00000000020001

export GNOCCHI_DRIVE_FS=ocfs2

export GNOCCHI_DRIVE_MAPPED=vdc

export ENABLE_CLEAR_GNOCCHI_DRIVE=yes

export NOVA_DRIVE=/dev/mapper/360000000000000000e00000000030001

export NOVA_DRIVE_FS=ocfs2

export NEUTRON_DHCP_AGENTS_COUNT=2

export DVR=no

export DVR=yes

export DOCKER_POOL_NAME=volumes

export DOCKER_POOL_SIZE=30720

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

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 - свой тип хранилища и так далее.