Тестирование «РУСТЭК-платформа»
В связи с уходом некоторых вендоров из России мы решили потестировать отечественные системы виртуализации. Одним из главных критериев для нас как облачного провайдера было наличие мультитенантности. Именно по этой причине среди прочих взяли на тестирование отечественную систему виртуализации «РУСТЭК — платформа» и программный комплекс управления и оркестрации платформ виртуализации «РУСТЭК–ЕСУ». В этой статье расскажем именно про «РУСТЭК — платформа».
Что такое «РУСТЭК-платформа»
Платформа РУСТЭК — это российская сервисная платформа виртуализации для создания и управления ИТ-инфраструктурой. Продукт создан российской компанией ООО «РУСТЭК», входит в единый реестр отечественного ПО (№ 981) и соответствует требованиям к импортозамещению. Ближайший зарубежный аналог — продукт VMware vCenter. Функционал платформы РУСТЭК включает в себя:
Система управления — собственная разработка на базе OpenStack;
Гипервизор — KVM;
Специализированная ОС, оптимизированная под задачи платформы;
Единый интерфейс для установки, обновления и масштабирования (конфигуратор);
API для интеграции с другими системами;
Развитая ролевая модель для обеспечения разделения прав при работе с платформой;
Учёт текущей загрузки платформы;
Автоматический перезапуск виртуальных машин (ВМ) на других физических серверах (высокая доступность);
Горячая миграция ВМ на другие физические серверы;
Автоматическая балансировка нагрузки между узлами кластера;
Поддержка наиболее популярных российских и зарубежных ОС;
Веб-портал для администраторов и пользователей.
* (из документации РУСТЭК)
Тестовый стенд
Для тестирования построили вот такой стенд:
Платформу решили установить на 3 сервера. В качестве хранилища использовали кластер из двух Starwind серверов подключённых по ISCSI. Для работы High Availability необходим доступ до IPMI серверов (VLAN 887) из сети управления кластером (VLAN 886).
Теперь переходим непосредственно к установке РУСТЭК-платформы версии 2021.2.3
Загружаемся с образа и входим с учётными данными root/rustack, удаляем разделы с дисков командой wipefs и приступаем к установке ОС «РУСТЭК платформа» на сервер, выполнив команду
rustack-os-install
Откроется конфигуратор из 5 пунктов:
Здесь необходимо указать настройки сетевого интерфейса сети управления, выбрать диск на который будет производиться установка и пароль для сервера. После того как настройки указаны, нажимаем «Применить конфигурацию сервера» и РУСТЭК-платформа установится на сервер. Проделываем операцию на всех трёх серверах.
По умолчанию РУСТЭК ориентирован на блочное хранилище NFS, и по информации из документации, все можно настроить из конфигуратора кластера. Но у нас-то хранилище подключается по ISCSI.
Для доступа к хранилищу мы выделили по 2 отдельных сетевых интерфейса на каждом сервере. Сначала редактируем файл настроек сети и создаём отдельный bond для ISCSI. Добавляем в /etc/conf.d/net
slaves_bond1="eno51 eno52"
mode_bond1="active-backup"
miimon_bond1="100"
config_bond1="172.16.50.111/24"
mtu_bond1="9000"
И активируем его:
ln -s /etc/init.d/net.lo /etc/init.d/net.bond1 && rc-update add net.bond1 && /etc/init.d/net.bond1 start
Теперь необходимо подключить хранилище ISCSI:
echo "InitiatorName=$(iscsi-iname)" > /etc/iscsi/initiatorname.iscsi
rc-update add iscsid && /etc/init.d/iscsid start
iscsiadm -m iface -I iface0 -o new && iscsiadm -m iface -I iface0 --op=update -n iface.net_ifacename -v bond1
iscsiadm --mode discoverydb --type sendtargets --interface=iface0 --portal 172.16.50.10 --discover && iscsiadm --mode discoverydb --type sendtargets --interface=iface0 --portal 172.16.50.20 –discover
iscsiadm --mode node --targetname iqn.2008-08.com.starwindsoftware:10.0.110.110-rustack --interface=iface0 --portal 172.16.50.10:3260 --login && iscsiadm --mode node --targetname iqn.2008-08.com.starwindsoftware:10.0.110.120-rustack --interface=iface0 --portal 172.16.50.20:3260 –login
iscsiadm --mode node --targetname iqn.2008-08.com.starwindsoftware:10.0.110.110-rustack --interface=iface0 --portal 172.16.50.10:3260 -o update -n node.startup -v automatic && iscsiadm --mode node --targetname iqn.2008-08.com.starwindsoftware:10.0.110.120-rustack --interface=iface0 --portal 172.16.50.20:3260 -o update -n node.startup -v automatic
Дальше необходимо включить multipath, для чего отредактируем конфигурационный файл:
defaults {
user_friendly_names no
find_multipaths yes
}
blacklist_exceptions {
## property (ID_WWN|SCSI_IDENT_.*)
property (ID_WWN|SCSI_IDENT_.*|ID_SERIAL)
}Перезапускаем multipathd
/etc/init.d/multipathd restart
Узнаём и записываем WWID подключённого таргета (в дальнейшем он нам пригодится при установке кластера).
rustack-01 ~ # multipath -ll
2917b2a1fe2703a28 dm-1 STARWIND,STARWIND
size=900G features='0' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=50 status=enabled
`- 4:0:0:0 sde 8:64 active ready runningНу, а теперь печальная печаль — все эти действия необходимо повторить на всех серверах, которые будут входить в кластер (и если добавлять дополнительный сервер в кластер — тоже).
После того, как подключили хранилище ко всем нодам, можно настроить кластер. Выполнять установку кластера лучше из консоли сервера или посредством ssh c использованием менеджера терминалов tmux. При попытке развернуть кластер просто по ssh (без tmux) скрипт развёртывания кластера завис на одной из операций (с чем это связано — не могу сказать, но после запуска развёртывания кластера в консоли всё отработало штатно). Для запуска развёртывания кластера выполняем команду rustackctl на одном из серверов, и видим знакомое окно конфигуратора, но с другими пунктами меню.
Если кратко, то для развёртывания кластера, нам необходимо указать общие настройки, добавить хосты на которых будем разворачивать кластер и после этого применить созданную конфигурацию ко всем хостам.
А теперь поподробней. Заходим в общие настройки
Указываем виртуальный IP — свободный IP-адрес в сети управления. после развёртывания кластера на этом IP будет висеть web-консоль управления платформой;
MTU физических интерфейсов — указываем побольше (хранилка же по ISCSI подключена);
Диапазон VLAN — задание не менее двух VLAN виртуальных сетей пользователей. Один из диапазонов VLAN используется для внутренних нужд платформы РУСТЭК;
Внешний VLAN — задание диапазона VLAN. Если не предполагается доступ к ВМ из интернета — любое (не пересекающееся с диапазоном из предыдущего пункта) значение из диапазона от 2 до 4094. Допускается оставить значение по умолчанию;
CIDR внешней сети — задание сети для внешних адресов ВМ. Если не предполагается доступ к ВМ из интернета, оставить значение по умолчанию;
Начало диапазона внешних IP — задание первого адреса из пула внешних адресов ВМ. Если не предполагается доступ ВМ к интернету, оставить значение по умолчанию;
Конец диапазона внешних IP — задание последнего адреса из пула внешних адресов ВМ;
Шлюз внешней сети — задание шлюза для сети внешних адресов ВМ. Если не предполагается доступ ВМ к интернету, оставить значение по умолчанию.
Так как у нас хранилка подключена по ISCSI, то «тип дискового хранилища» «тип дискового хранилища для образов» выбираем OCFS2, и заполняем «Список WWID для OCFS2» значениями, которые получили, пока настраивали ISCSI. Можно указать несколько WWID, но после применения конфигурации примонтируется только одно хранилище. Второе придётся прописать в конфигах ручками (вендор обещал исправить такое поведение в ближайшем релизе).
Так, задали по минимуму настройки для кластера. Теперь будем добавлять хосты.
В Конфигураторе предусмотрено 5 шаблонов хостов (на самом деле 4). Отличаются они набором запускаемых служб.
Manual — руками выбираем, какие службы будут запущены на хосте;
All-in-one — все запускаем на одном хосте, HA — нет (это не наш вариант);
Primary — набор служб для первичного контроллера
Secondary — набор служб для вторичного контроллера
Compute — набор служб для вычислительного узла.
Если режим высокой доступности (HA) не нужен, а хостов больше одного — то можно на один хост настроить роль «All-in-one», а на остальные хосты — «Compute».
В документации от новой версии появились замечательные таблички, в которых указано, какие службы и на каких хостах должны работать. Здесь приведу такую табличку для нашего мини-кластера высокой доступности:
Кстати, по умолчанию в шаблоне «Primary» служба «Вычислительный узел» отключена. Включаем её, ибо нечего благородным ядрам зазря простаивать.
Добавляем наши хосты в кластер. Включаем службы на хостах, как указано в таблице. Возвращаемся в главное меню Конфигуратора и нажимаем кнопку «Применить конфигурацию РУСТЭК» и «Откиньтесь на спинку кресла и отдохните…». А в этот время ansible создаст кластерное хранилище настроек и настроит все необходимые службы на хостах. После того, как Ansible скажет нам, что он справился и всё хорошо (если нехорошо, то смотрим /var/log/rustack-ansible.log), выходим из конфигуратора.
Наступает следующий эпизод квеста «найди пароль от панели управления». На самом деле тут всё просто. Выполняем волшебную команду:
python3 -c "import yaml;print({k:v for k,v in dict(yaml.safe_load(open('/etc/openstack/clouds.yml'))['clouds']['rustack' ]['auth']).items() if k in ('username','password')})"
и получаем наши логин и пароль от панели управления:
{'username': 'admin', 'password': 'fk985KXh'}
Кстати, судя по документации, к новой версии пароль получить стало проще:
cat /var/lib/rustack-ansible/creds/keystone/admin_pass
Когда все квесты пройдены, можно зайти в панель управления платформой и начать создавать свою виртуальную инфраструктуру.
Ошибка второго дня использования
На следующий день после развёртывания платформы, при попытке войти в панель управления я лицезрел вот такое сообщение:
Погадав на кофейной гуще и перезапустив Redis, смог войти в панель управления. Но где-то в глубине души поселилась тревога, что где-то что-то не так. И действительно, спустя какое-то время я снова получил ту же ошибку и не смог попасть в панель управления. Пришлось подключать тяжелую артиллерию и смотреть логи, а логов генерится очень много. Среди кучи строк внимание заслужила одна:
«Nov 23 09:33:24 rustack-01 pgbouncer[5307]: accept() failed: Too many open files»
Отправил запрос вендору, и начал параллельно гуглить, что это за ошибка и как её победить? Но вендор оказался быстрей:
«В данном случае мы уперлись в выделенные лимиты, для pgbouncer —
/etc/security/limits.d/11-postgres.confЧтобы проверить наверняка, можно выполнить следующие команды
psql -U postgres -p 6432 -hpgbouncer -c "show lists;"
нас интересует значение used_clients, скорее всего, оно было под потолокдалее выполним
psql -U postgres -p 6432 -hpgbouncer -c "show pools;"
нас интересуют основные потребители коннектов, их мы и будем фиксить.»
Дело в том, что по умолчанию для большинства служб openstack по дефолту создаются воркеры по числу ядер, например для nova-conductor
workers = None | (Integer) Number of workers for OpenStack Conductor service. The default will be the number of CPUs available. |
Соответственно, если у вас CPU (s) — 64, получаем 64 воркера, каждый из которых создаёт нагрузку для pgbouncer и забирает файловый дескриптор, вот мы и упираемся в выделенные лимиты.
Чтобы пофиксить эту проблему (после того, как мы определили основные службы openstack, что потребляют коннекты pgbouncer), требуется на контроллерах в конфигурационных файлах соответствующих служб выставить конкретные значения для соответствующих воркеров и перезапустить эти службы.
Например, nova.conf
[DEFAULT]
…
osapi_compute_workers = 16
metadata_workers = 16
…
[conductor]
workers = 16
…Для тестовых стендов за глаза хватит 4/8, на проде можно выставить 16, для более точных настроек надо снимать статистику по нагрузке.
Оказалось, что тестовый стенд был слишком «жирным» для конфигурации по умолчанию. После изменения лимитов в конфигах и перезапуска служб всё штатно запустилось и работает по сей день.
Теперь кратко итоги по результатам установки
Минусы:
Ручное подключение ISCSI-хранилищ;
Нельзя настроить отдельный сетевой интерфейс для ISCSI в конфигураторе;
Некорректно монтируются ISCSI таргеты, если их больше одного;
На определённой итерации кластер так и не развернулся (возможно, виноват сам, что запустил установку по ssh без tmux).
Плюсы:
Поддержка вендора — просто огонь. Отвечают оперативно. В своём продукте ориентируются отлично. Если нужна помощь, подключаются в этот же или на следующий день;
Документация. Она есть и она постоянно дорабатывается.
Что ещё интересного есть в блоге Cloud4Y
→ Информационная безопасность и глупость: необычные примеры
→ NAS за шапку сухарей
→ Как распечатать цветной механический телевизор на 3D-принтере
→ Создание e-ink дисплея с прогнозом погоды
→ Аналоговый компьютер Telefunken RA 770
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.
