Apache CloudStack — зрелая платформа для частного облака, которая превращает несколько серверов с KVM в управляемый пул виртуальных машин. В отличие от OpenStack, здесь меньше компонентов и понятнее путь от установки до первой ВМ. Ниже — практический сценарий на Debian 12: управляющий узел, KVM-хосты, NFS-хранилище и диагностика типовых сбоев.

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

CloudStack делится на management server и вычислительные хосты. Первый хранит конфигурацию в MySQL или MariaDB, отдаёт веб-интерфейс и API, управляет системными виртуальными машинами. Вторые работают под libvirt и KVM. Ресурсы описываются иерархией zone, pod, cluster, host: зона — это дата-центр, pod — стойка или сегмент сети, cluster — группа однотипных гипервизоров.

Для теста хватит трёх машин: management с 4 vCPU и 8 ГБ RAM, KVM-хост с поддержкой VT-x или AMD-V и NFS-сервер. Нужны статическая адресация, синхронизация времени и отдельная сеть для служебного трафика. Management и агент KVM общаются по TCP 8250 и 16509, поэтому эти порты не должны смотреть в интернет.

Подготовка базы данных

Устанавливаем MySQL и задаём параметры, которые рекомендуются для CloudStack: длинный таймаут блокировок и запас соединений. Отдельный пользователь базы ограничивает последствия ошибки в конфигурации.

sudo apt install -y mysql-server
sudo mysql -e "CREATE USER 'cloud'@'localhost' IDENTIFIED BY 'StrongPass'; GRANT ALL ON *.* TO 'cloud'@'localhost';"
mysql -u cloud -p -e "SELECT VERSION();"

В файле /etc/mysql/mysql.conf.d/cloudstack.cnf добавляем настройки и перезапускаем службу:

[mysqld]
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=1000

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

Установка management server

Подключаем репозиторий Apache CloudStack для Debian 12 и ставим пакет. Ветку фиксируем явно, чтобы обновление не приехало неожиданно вместе с зависимостями.

wget -qO- https://download.cloudstack.org/release.asc | sudo gpg --dearmor -o /usr/share/keyrings/cloudstack.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudstack.gpg] https://download.cloudstack.org/debian bookworm 4.20" | sudo tee /etc/apt/sources.list.d/cloudstack.list
sudo apt update && sudo apt install -y cloudstack-management
sudo cloudstack-setup-databases cloud:StrongPass@localhost --deploy-as=root
sudo cloudstack-setup-management

Скрипт создаст схему и службу. Проверка: systemctl status cloudstack-management, затем вход на http://IP:8080/client. Стандартная учётная запись admin с паролем password — её нужно сменить сразу после первого входа, а сам интерфейс закрыть от внешних сетей.

Настройка KVM-хоста

На вычислительном узле ставим агент и libvirt. CloudStack управляет гипервизором по TCP, поэтому включаем прослушивание, но закрываем порт файрволом со стороны гостевых сетей.

sudo apt install -y cloudstack-agent qemu-kvm libvirt-daemon-system
sudo sed -i 's/^#listen_tls.*/listen_tls = 0/' /etc/libvirt/libvirtd.conf
sudo sed -i 's/^#listen_tcp.*/listen_tcp = 1/' /etc/libvirt/libvirtd.conf
sudo sed -i 's/^#auth_tcp.*/auth_tcp = "none"/' /etc/libvirt/libvirtd.conf
sudo systemctl restart libvirtd && sudo systemctl enable cloudstack-agent

В /etc/libvirt/qemu.conf проверьте vnc_listen = «0.0.0.0» и запуск от root — этого требует агент. В libvirtd.conf должны быть заданы auth_tcp = «none» и прослушивание TCP, а сам демон в Debian запускается с ключом —listen через /etc/default/libvirtd. Без этого управляющий сервер не подключится к гипервизору. Убедитесь, что chrony синхронизирован: расхождение времени ломает TLS и регистрацию хоста. Для проверки виртуализации подойдёт команда egrep -c ‘(vmx|svm)’ /proc/cpuinfo: ноль означает, что её надо включить в BIOS.

Зона, хранилище и первая ВМ

В интерфейсе создайте зону с advanced networking, pod и cluster типа KVM. Для первичного хранилища подойдёт NFS: на сервере экспортируйте каталог и разрешите доступ только с хостов кластера.

sudo apt install -y nfs-kernel-server
echo "/srv/primary 10.20.0.0/24(rw,sync,no_root_squash)" | sudo tee -a /etc/exports
sudo exportfs -ra
showmount -e 10.20.0.10

Вторичное хранилище нужно для шаблонов и ISO. Шаблон системной ВМ заливается скриптом cloud-install-sys-tmplt из пакета cloudstack-common; ссылку на образ берите на официальной странице загрузок, а не из случайного форума. После добавления хоста запустите проверку инфраструктуры и создайте экземпляр из шаблона.

Сети и системные ВМ

В advanced-зоне CloudStack поднимает виртуальный роутер, который выполняет NAT, DHCP, DNS и проброс портов. Ему нужен пул адресов и шлюз, выделенные под гостевую сеть; management-трафик через него не идёт. Проверьте, что пул не пересекается с существующей адресацией и что на коммутаторе разрешены нужные VLAN.

Системные ВМ SSVM и CPVM — обычные KVM-домены. Если они не запускаются, новая машина не получит шаблон и адрес. Не удаляйте их вручную через virsh: платформа пересоздаст домен, но состояние задания может остаться в ошибке. Смотрите очередь задач и журнал management-сервера.

Для доступа к API заведите отдельного пользователя с ограниченными правами и подписывайте запросы ключами. Не давайте приложениям учётную запись администратора: одна утечка ключа превращается в полный контроль над зоной.

Диагностика

Первый инструмент — cloudstack-status: он показывает состояние служб и базы. Дальше смотрим журналы управления и агента, а на хосте — список доменов libvirt.

sudo cloudstack-status
sudo journalctl -u cloudstack-management -n 100 --no-pager
sudo tail -f /var/log/cloudstack/management/management-server.log
sudo virsh list --all

Типовые причины сбоев: хост не подключается — агент не слушает 8250 или 16509, либо рассинхронизировано время; системная ВМ не стартует — не включена виртуализация или мешает AppArmor; NFS не монтируется — нет прав no_root_squash и доступа по сети. Проверяйте цепочку по порядку: сеть, время, libvirt, хранилище, логи CloudStack. Не начинайте с переустановки management-сервера: в девяти случаях проблема находится на уровне маршрутизации или прав доступа.

Чек-лист перед продакшеном

  • Отдельные сети для управления, гостей и хранилища, доступ к API только через ограниченный периметр.
  • Резервное копирование MySQL и конфигурации, регулярная проверка восстановления на тестовом стенде.
  • Мониторинг свободного места на primary и secondary, состояния system VM и очередей заданий.
  • Зафиксированные версии пакетов и план обновления management-серверов по одному.
  • Сменённые пароли по умолчанию и закрытый доступ к 16509 из внешних сетей.

Итог

CloudStack даёт предсказуемый способ поднять частное облако без десятка микросервисов: management server, KVM-хосты, NFS и аккуратная сеть. Начните с тестового стенда, пройдите путь до работающей ВМ, а затем автоматизируйте развёртывание и добавьте резервное копирование. Главные риски здесь не в коде, а в сети и времени — их проверка занимает минуты и экономит часы разбора инцидентов.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте