Привет Хабр! Я Иван, QA в Хайстекс. Уже несколько лет занимаюсь тестированием и внедрением решения Акура.

Этот материал родился из практики. Внутри компании мы регулярно поднимаем решения в OpenStack для тестов, пилотов и внедрений, и часто сталкиваемся с одними и теми же вопросами. Где-то не тот порт, где-то нестандартный эндпоинт, где-то сеть устроена чуть иначе, чем ожидаешь. Мелочи, которые на старте могут съедать часы.

Под катом – полное, пошаговое руководство по подготовке OpenStack и развертыванию контроллера Акуры. Это не документация в классическом смысле, а рабочий конспект. Поэтому по ходу статьи разберем процесс подготовки OpenStack и покажу, на что стоит обращать внимание при развертывании решений в этом окружении. Попутно затронем особенности платформы, которая остается одним из самых популярных open source облаков.

Если вам удобнее воспринимать информацию в видеоформате, есть запись с установкой Акуры. Можно посмотреть здесь. 

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

Отдельно хочу снять возможные опасения, которые часто возникают у тех, кто впервые сталкивается с Акурой. Мы не требуем от облака завышенных прав, а сама настройка оказывается куда проще, чем выглядит на бумаге. Если что-то пойдет не так, будет выведено понятное сообщение с указанием, куда смотреть. Ниже расскажу о том, что учесть, чтобы первый запуск прошел без сюрпризов.

Подготовка облака

Перед тем как поднимать Акуру, важно убедиться, что сама облачная площадка готова. На практике именно на этапе подготовки чаще всего появляются мелкие проблемы, которые потом выливаются в «почему инстанс не доступен». Ниже разберем минимальный набор шагов, который помогает избежать лишних попыток и перезапусков.

1. Проверка версии облака

Минимальная подходящая версия — 16 (Mitaka). Проверить версию можно в разделе System Information в интерфейсе самого облака. Если версия ниже, гарантировать корректную работу не получится.

2. Создание секьюрити-групп

Далее подготовим группы безопасности (Security groups). Таким образом мы зададим ограничения на входящий трафик на инстансах самой Акуры и агентов.

Для работы Акуры достаточно оставить открытыми на вход лишь несколько портов.

Создадим группу безопасности для самой Акуры.

Перейдем в Network/Security Groups, дадим группе имя (acura_sg) и добавим Ingress правила для:

  • ICMP-пакетов (All ICMP, чтобы можно было проверить доступность инстанса);

  • протокола TCP на 4443 и 443 портах (первый будет использоваться при первоначальной настройке (и в дальнейшем будет закрыт), а второй – при обычной работе с контроллером в браузере);

  • 12201 UDP порт для получения логов.

По аналогии добавим группу для облачных агентов, это вспомогательные инстансы, которые будут подниматься в OpenStack при валидации облака и дальнейшей работе продукта.

Создадим группу agent_sg с Ingress правилами:

  • All ICMP,

  • для протокола TCP на 80 и 15000 портах.

Если планируется доступ по ssh, можно открыть ещё 22-ой порт в обеих группах безопасности. Это не обязательно, но может пригодиться в будущем, например, для обновления контроллера или мониторинга нагрузки.

3. Подготовка флейворов

Далее подготовим флейворы, чтобы затем использовать их при поднятии инстансов. Для этого перейдем в Admin/Compute/Flavors. Минимальные требования для Акуры - 8 ядер CPU, 16 ГБ памяти и 200 ГБ дискового пространства, для облачных агентов - 2 ядра CPU, 4 ГБ памяти и 20 ГБ под основной диск.

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

4. Доступность сервисов

Из сети и проекта, в которых будет поднят инстанс Акуры, должен быть доступ до основных сервисов OpenStack: Keystone (Identity), вычислений (Compute), дисков (Volume), образов (Image) и сетей (Network) и конечно же до эндпоинта облака (Service Endpoint).

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

5. Сети

Вы можете подготовить порт для контроллера заранее, чтобы потом использовать его при создании инстанса.

6. (Необязательно) Загрузка ключ-пары для доступа из консоли

Если планируется консольный доступ к контроллеру, можно заранее загрузить ssh-ключ. Это не критичный шаг, но экономит время в будущем.

Подготовка облака закончена. Перед тем как двигаться дальше, отмечу: несмотря на то, что мы разбираем установку конкретного продукта, большая часть действий на этом этапе универсальна. Настройка security groups, подготовленные флейворы, проверка доступности сервисов OpenStack, работа через CLI при загрузке образов, правильная организация проекта и сетей – всё это пригодится при развертывании практически любого решения в OpenStack. Такой подход помогает сразу исключить типовые проблемы и экономит время ещё до старта установки.

Загрузка образов в OpenStack

Предположим, у вас уже есть машина, на которую загружены все необходимые файлы: архив с образом контроллера Акуры и образ облачного агента. Рекомендую использовать машину с консольным клиентом OpenStack.  В ходе подготовки мы будем загружать в облак�� большие файлы. Не всегда это получается стабильно сделать через UI, поэтому использование Openstack CLI предпочтительно.

Для начала распакуем архив с контроллером.

# tar -xvzf Controller_DR_OpenStack_<release_id>.tar.gz

После распаковки загрузим его в облако. Обратите внимание на параметры, которые переданы в CLI. Особенно важен формат диска. Забегая вперед замечу, что для клауд-агента он будет другим.

# openstack image create --disk-format raw --container-format bare --shared --file tmp/Controller_DR_OpenStack_<release_id_ad_hash> --min-disk 80 --min-ram 16384 Acura_4_3_1 --fit-width

Аналогично поступим с облачным агентом. Снова обращаем внимание на формат.

# openstack image create --disk-format qcow2 --container-format bare --shared --file Agent_<some_hash>.qcow2 --min-disk 20 --min-ram 4096 CA_v4_3_1 --fit-width

Вообще, образ агента есть на самом контроллере и при валидации облака он бы был загружен в облако. Но мы здесь рассмотрим более общий случай. Иногда в качестве обновления решения образ облачного агента может быть поставлен отдельно. Кроме того, Вы можете захотеть переименовать образ в облаке. Далее будет показано, какие настройки позволят продолжить работать в таком случае.

Создание инстанса контроллера

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

Заходим в UI Опенстека, выбираем ранее загруженный образ, нажимаем Launch, даем инстансу какое-то имя.

Задаем размер вольюма - 200ГБ.

Выбираем flavor с минимальными требованиями.

Далее сети. В данном случае, сеть не указываем, указываем только порт, поскольку он был создан ранее. Если у вас DHCP, то можно на этом этапе указать сеть и адрес будет выдан автоматически.

Теперь секьюрити группы. Выбираем ранее созданную для контроллера группу acura_sg.

И ключ-пара. Если она вам нужна, и вы не подготовили ее ранее, можете на данном этапе ее создать, и публичную часть загрузить в OpenStack. Напоминаю, что чтобы впоследствии доступ заработал, также необходимо не забыть добавить в Security groups отдельное правило на SSH, но это можно будет сделать и позднее.

Основные настройки заданы, можем запускать поднятие инстанса.

В соответствующей вкладке Опенстека мы увидим, что инстанс в переходит в статус running. Если зайдем в подробности, то увидим в частности:

  • используемый флейвор;

  • адрес, который получил контроллер;

  • его группу безопасности;

  • ключ-пару, если она была задана;

  • имя образа, использованного для поднятия.

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

Хотя машина достаточно быстро доходит до экрана логина, сервисы продолжают подниматься ещё какое-то время — их там действительно много. Первичный запуск занимает около 10–20 минут. После этого можно переходить по адресу инстанса и продолжать настройку в браузере.

Вводим в строку браузера IP инстанса, используется протокол https.

Когда контроллер полностью загрузится, вы увидите приглашение к прохождению начальной настройки.

В следующей главе перейдем к первичной настройке Акуры через веб-интерфейс и разберем ключевые параметры, которые важно задать правильно на этом этапе.

Первоначальная настройка

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

Данные организации и настройки SMTP

Вводим название вашей организации. Задаем имя пользователя, который будет проводить настройки в дальнейшем, и пароль.

Далее вводим лицензионный ключ, который вам предоставил Хайстекс и указываем настройки SMTP-сервера, который будет использоваться для отправки уведомлений о событиях. Это может быть ваш собственный SMTP-сервер или какой-то публичный. Мы в примере будем использовать публичный. Тип шифрования по умолчанию SSL, но также поддерживается TLS, либо вариант без шифрования.

Указываем имя пользователя SMTP, он же, в нашем случае, будет использоваться для тестовых e-mail. И пароль.

Если у вас на вашем SMTP-сервере SMTP FROM является обязательным полем, то важно его заполнить.

Нажимаем Далее, после чего будет произведена проверка настроек SMTP. Когда этот шаг будет успешно пройден, перейдем к настройке целевого облака.

Валидация облака

В данном случае будет проводиться проверка корректности настроек подключения к OpenStack. Для удобства настройки поделены на 2 вкладки, начнем с основной.

Точка доступа Keystone API – указывается основной endpoint облака.

Тип аутентификации – можно использовать различные. В данном случае будем использовать пароль.

Домен пользователя, Имя пользователя и Пароль, Домен целевого проекта – заполняете для своего облака.

ID целевого проекта. Выберите нужный, зайдя в Identity/Projects.

Служебная сеть Хайстекс. Это сеть, в которой будут подниматься облачные агенты. В простом случае можно указать ту же, в которой поднят инстанс контроллера.

Сеть с плавающим IP. Если вам нужно использовать доступ к Акура снаружи, а не только из внутренней сети, то здесь можно задать другую сеть. Аналогично можно задать публичный адрес панели управления Акура.

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

Это были основные параметры. Кроме них, есть дополнительные, заполнение которых может быть полезно в вашем случае. Посмотрим на самые часто используемые.

Например, здесь можно указать конкретный ID образа облачного агента. На одном из предыдущих шагов мы загрузили образ агентa в OpenStack, и теперь можем задать его ID, чтобы во время валидации и дальнейшей работы использовался именно он.

Если ID не указывать, Акура попытается найти ранее загруженный образ с зарезервированным именем. Если такого в облаке нет, контроллер автоматически выгрузит его сам.

Если вам необходимо, чтобы облачные агенты поднимались с публичным адресом, то такая опция тоже возможна. В нашем случае это не нужно, но это нередко используется.

Можно задать группу безопасности облачного агента: секьюрити группу, которую мы ранее создали предварительно (agent_sg).

Кроме этого, среди множества доступных параметров стоит обратить внимание на эндпоинты. Если в вашем OpenStack эндпоинты отдельных сервисов отличаются от эндпоинта облака, их нужно указать. 

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

Запускаем валидацию. Что произойдет дальше?

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

Таким образом Акура проверит, что может в этом облаке работать.

В процессе валидации Акура показывает последовательность этапов, которые проходит система. Если какой-то шаг не удастся выполнить, вы увидите сообщение об ошибке.

Дальше ждем, пока поднимется инстанс облачного агента. Когда в интерфейсе появится этап проверки связности, можно заглянуть в проект и посмотреть, что происходит.

Там увидим инстанс, созданный из указанного нами образа. Он должен полностью загрузиться. Далее Акура начнет выполнять тестовые операции: проверит возможность подключения и отсоединения диска, проверит сетевую связность и возможность выполнения других операций, которые потом будут использоваться в рабочем режиме. Все эти проверки проходят именно здесь, на этапе начальной настройки.

Если валидация завершилась успешно, появится соответствующее сообщение. На этом этапе можно впервые открыть уже запущенный и корректно настроенный контроллер Акуры.

Первый вход

После успешной валидации можно зайти в Акуру, используя данные, которые вы указали при первоначальной настройке. 

Перед нами интерфейс Disaster Recovery-установки. На стартовом экране отображается название организации, созданный ранее пользователь и версия продукта. Слева находится боковая панель — основной навигационный блок.

Разберем, что здесь может быть нам полезно?

Основные функции

В DR есть четыре цветные кнопки. Это ключевое отличие от миграционной версии Акуры, где кнопок всего две (включая «Мигрировать»).

Ниже расположены пункты, общие для дистрибутивов. 

Настройки

Здесь вы можете перенастроить SMTP, настраивать оповещения разного уровня, создавать пользователей, роли, изменять глобальные настройки кластера, в том числе изменять SSL-сертификат.

Отчеты

Раздел «Отчеты» предназначен для генерации различных итоговых данных по операциям, задачам и активности.

События

В «Событиях» отображается подробная история ключевых действий системы. Это расширенная и более детальная версия уведомлений из «колокольчика». Здесь же появляются сообщения об ошибках, если они возникали при настройке или работе.

Помощь

Кнопка «Помощь» открывает локальную документацию, которая хранится прямо на контроллере. Это особенно удобно, если Акура развернута в закрытом контуре.

На этом базовая часть установки заканчивается. Контроллер доступен, и можно двигаться дальше по рабочим задачам. Надеюсь, эта статья сэкономит вам время при очередной «прожарке фирменного стека». Если у вас есть свои наблюдения, нюансы или лайфхаки при работе с OpenStack, – делитесь в комментариях, дополним рецепт вместе.

Комментарии (2)


  1. achekalin
    29.11.2025 19:53

    Статья интересная, наверняка пригодится при развертывании опенстека, но Вы бы написали, что за Акура-то такая! Я вот только японские видики могу припомнить...


    1. iminmotion Автор
      29.11.2025 19:53

      Если коротко, то Акура - это решение для резервного копирования и миграции в облачные платформы. Поддерживаемых сценариев уже довольно много и продукт активно развивается.

      Например, летом выходила статья моей коллеги о резервном копировании машин из VMware в S3-хранилище Selectel.