Настоящий документ содержит описание функциональных характеристик экземпляра программного обеспечения CEE Hypervisor (Cloud Execution Environment), предоставленного для экспертной оценки. Документ предназначен для специалистов, проводящих анализ функциональной полноты и соответствия системы заявленным требованиям.

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

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

Раздел 1. Управление виртуальными машинами

1.1. Создание виртуальной машины

Система обеспечивает создание виртуальных машин с заданными параметрами. При создании ВМ пользователь указывает следующие параметры:

имя виртуальной машины

количество виртуальных процессоров

объем оперативной памяти

путь к образу диска

тип операционной системы

размер дискового хранилища

признак автоматического запуска после создания

Процесс создания включает валидацию входных параметров, проверку доступности ресурсов на выбранном вычислительном узле, генерацию XML-конфигурации для libvirt, определение домена в libvirt, запуск ВМ и сохранение метаданных в базе данных. Система поддерживает как размещение на конкретном узле, так и автоматический выбор узла с наименьшей нагрузкой.

1.2. Запуск виртуальной машины

Функция запуска ВМ обеспечивает перевод виртуальной машины из остановленного состояния в выполнение. Система проверяет существование ВМ, определяет вычислительный узел размещения, выполняет команду запуска домена через libvirt и обновляет состояние ВМ. При повторном запуске уже работающей ВМ возвращается соответствующее уведомление.

1.3. Остановка виртуальной машины

Поддерживаются два режима остановки: мягкая остановка с отправкой сигнала ACPI гостевой операционной системе и принудительная остановка с немедленным завершением работы ВМ. Система контролирует успешность операции и обновляет состояние в базе данных.

1.4. Удаление виртуальной машины

Удаление ВМ включает остановку работающей машины, удаление определения домена из libvirt, удаление метаданных из базы данных и освобождение ресурсов. При наличии снапшотов система запрашивает подтверждение на их удаление.

1.5. Получение списка виртуальных машин

Система предоставляет список всех виртуальных машин с их текущим состоянием, включая идентификатор, имя, количество процессоров, объем памяти, состояние, тип ОС, узел размещения и время создания. Поддерживается фильтрация по состоянию, узлу и владельцу.

1.6. Получение информации о виртуальной машине

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

Раздел 2. Управление образами

В системе CEE Hypervisor управление образами виртуальных машин реализовано по аналогии с сервисом Glance в платформе OpenStack. Образы представляют собой шаблоны операционных систем и приложений, на основе которых создаются виртуальные машины. Модуль управления образами обеспечивает централизованное хранение, каталогизацию и распространение образов по вычислительным узлам кластера. Поддерживаются образы в форматах ISO (установочные диски) и QCOW2 (готовые диски виртуальных машин), что позволяет как выполнять чистую установку ОС, так и быстро разворачивать предварительно настроенные системы.

2.1. Загрузка образов

Система обеспечивает загрузку образов операционных систем в форматах ISO и QCOW2. Процесс включает прием файла, проверку формата, сохранение в директорию хранения, установку прав доступа и логирование операции. Поддерживается загрузка на все узлы или на конкретный узел.

2.2. Получение списка образов

Функция предоставляет список доступных образов с указанием имени файла, размера, типа, полного пути и узлов размещения.

2.3. Удаление образов

Удаление образа выполняется после проверки отсутствия зависимостей от запущенных ВМ. При наличии зависимостей возвращается предупреждение с перечнем использующих образ машин.

2.4. Клонирование образов

Система поддерживает создание клонов через механизм снапшотов QEMU с использованием команды qemu-img create. Клонирование позволяет быстро разворачивать новые ВМ на основе шаблонов.

Раздел 3. Управление снапшотами

Снапшот (снимок состояния) представляет собой сохраненное состояние виртуальной машины в конкретный момент времени. Снапшот включает полную копию состояния диска виртуальной машины, а также может включать состояние оперативной памяти и состояние всех устройств ВМ.

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

В системе CEE Hypervisor снапшоты реализованы через механизмы QEMU и libvirt, обеспечивающие эффективное хранение изменений с использованием технологии copy-on-write (копирование при записи). Это позволяет создавать снапшоты с минимальными накладными расходами дискового пространства, сохраняя только изменения относительно базового состояния.

3.1. Создание снапшота

Система создает снимки состояния виртуальных машин, сохраняя состояние диска, оперативной памяти и устройств ВМ. При создании указываются имя и описание снапшота.

3.2. Восстановление из снапшота

Восстановление возвращает ВМ к сохраненному состоянию с остановкой машины, восстановлением диска и памяти и опциональным запуском.

3.3. Получение списка снапшотов

Для каждой ВМ доступен список снапшотов с именем, описанием, датой создания, размером и типом.

3.4. Удаление снапшота

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

Раздел 4. Кластерное управление

В системе CEE Hypervisor управление кластером и обеспечение отказоустойчивости реализованы на базе нескольких ключевых компонентов. Балансировка нагрузки и отказоустойчивость уровня управления обеспечиваются HAProxy, который распределяет входящие запросы между контроллерами и автоматически исключает недоступные узлы из пула. Управление кластером осуществляется через специальные инфраструктурные виртуальные машины (infra-ВМ), которые создаются на узлах контроллеров независимо от самой платформы CEE на самом раннем этапе развертывания системы. Эти infra-ВМ содержат служебные компоненты, обеспечивающие работу кластера, и не участвуют в выполнении пользовательских нагрузок.

4.1. Инфраструктурные виртуальные машины (infra-ВМ)

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

Назначение infra-ВМ:

размещение служебных сервисов управления кластером

обеспечение работы механизмов оркестрации

выполнение функций мониторинга и координации

размещение HAProxy для балансировки нагрузки

размещение компонентов управления базой данных кластера

Характеристики infra-ВМ:

создаются автоматически в процессе деплоя (ansible/terraform)

работают на узлах контроллеров, но изолированы от них

имеют фиксированную конфигурацию ресурсов (CPU, память, диск)

управляются через CEE Hypervisor как обычные ВМ, но имеют особый статус

автоматически восстанавливаются при сбоях

не учитываются в балансировке пользовательских нагрузок

Состав infra-ВМ:

На каждой infra-ВМ развертываются следующие компоненты:

HAProxy для балансировки трафика между контроллерами

агенты мониторинга и сбора метрик

компоненты синхронизации состояния кластера

локальные кэши и очереди сообщений

вспомогательные скрипты для управления отказоустойчивостью

4.2. HAProxy и отказоустойчивость

HAProxy (High Availability Proxy) обеспечивает балансировку нагрузки и отказоустойчивость на уровне управления кластером. Он работает на инфраструктурных виртуальных машинах и выполняет следующие функции:

Балансировка запросов:

распределение входящих API-запросов между доступными контроллерами

равномерная загрузка управляющих узлов

поддержание нескольких алгоритмов балансировки (round-robin, leastconn, source)

терминация SSL-соединений для разгрузки контроллеров

Мониторинг доступности:

периодическая проверка здоровья каждого контроллера (active/passive checks)

мониторинг состояния сервисов на контроллерах (API, база данных, WebSocket)

автоматическое исключение недоступных узлов из пула

уведомление администратора при изменении состояния узлов

Обеспечение отказоустойчивости:

автоматическое переключение трафика при отказе контроллера

прозрачное для клиента восстановление соединений

поддержка механизмов graceful degradation

сохранение сессий при переключении (при необходимости)

Конфигурация HAProxy:

HAProxy настраивается автоматически в процессе деплоя инфраструктурных ВМ с учетом топологии кластера:

text

global

    daemon

    maxconn 4096

defaults

    mode http

    timeout connect 5s

    timeout client 50s

    timeout server 50s

frontend cee_api_frontend

    bind *:8000

    default_backend cee_api_servers

backend cee_api_servers

    balance roundrobin

    option httpchk GET /api/health

    server ctrl-01 192.168.10.10:8000 check inter 3s fall 3 rise 2

    server ctrl-02 192.168.10.11:8000 check inter 3s fall 3 rise 2

    server ctrl-03 192.168.10.12:8000 check inter 3s fall 3 rise 2

4.3. Регистрация вычислительных узлов

Система поддерживает динамическую регистрацию вычислительных узлов в кластере через infra-ВМ. При регистрации узла:

узел отправляет heartbeat-сигнал инфраструктурным ВМ

infra-ВМ проверяют доступность libvirt на узле

выполняется сбор информации о ресурсах узла (CPU, память, хранилище)

узел добавляется в пул доступных вычислительных ресурсов

информация о узле сохраняется в базе данных и синхронизируется между infra-ВМ

HAProxy обновляет конфигурацию при необходимости

4.4. Мониторинг состояния узлов

Инфраструктурные ВМ осуществляют непрерывный мониторинг состояния всех узлов кластера через механизм heartbeat. Для каждого узла отслеживаются:

доступность (online/offline) через ICMP и TCP-проверки

текущая загрузка CPU (средняя за 1, 5, 15 минут)

использование оперативной памяти и swap

свободное дисковое пространство на разделах

количество запущенных ВМ и их состояние

статус libvirt и QEMU

сетевые задержки и потери пакетов

При обнаружении недоступности узла в течение заданного количества интервалов heartbeat, узел помечается как "offline", информация синхронизируется между всеми infra-ВМ, и администратор получает уведомление через настроенные каналы оповещения.

4.5. Балансировка нагрузки

Система автоматически распределяет создаваемые виртуальные машины по вычислительным узлам на основе данных, собираемых infra-ВМ:

текущая загрузка CPU на узлах (сглаженная за последние 5 минут)

доступная оперативная память с учетом резервирования

свободное дисковое пространство на хранилищах образов

наличие требуемого образа на узле или время его загрузки

текущее количество запущенных ВМ на узле

исторические данные о производительности узла

ограничения и квоты проектов

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

4.6. Миграция виртуальных машин

Система поддерживает live-миграцию виртуальных машин между вычислительными узлами. Процесс миграции координируется инфраструктурными ВМ:

Подготовка миграции:

проверка доступности целевого узла через infra-ВМ

оценка достаточности ресурсов на целевом узле

синхронизация необходимых образов (если требуется)

резервирование ресурсов на целевом узле

Выполнение миграции:
5. передача состояния памяти ВМ на целевой узел с использованием протоколов libvirt
6. синхронизация изменений диска (при использовании общего хранилища)
7. переключение сетевых соединений на новый узел через обновление правил HAProxy
8. завершение работы исходного экземпляра ВМ и освобождение ресурсов

Завершение миграции:
9. обновление метаданных ВМ в базе данных
10. синхронизация информации между infra-ВМ
11. обновление мониторинга и метрик
12. уведомление клиента о завершении миграции

4.7. Отказоустойчивость контроллеров и infra-ВМ

Система обеспечивает многоуровневую отказоустойчивость:

Уровень инфраструктурных ВМ:

infra-ВМ работают на каждом узле контроллера, образуя кластер из трех экземпляров

все infra-ВМ активны и обрабатывают трафик параллельно

при отказе одной infra-ВМ, HAProxy на других продолжает обслуживать запросы

состояние синхронизируется между всеми infra-ВМ через распределенное хранилище

Уровень контроллеров:

при отказе контроллера, HAProxy на infra-ВМ исключает его из балансировки

клиентские запросы автоматически перенаправляются на работающие контроллеры

операции с уже запущенными ВМ продолжаются без прерывания

восстановившийся контроллер автоматически возвращается в пул после проверки здоровья

Уровень HAProxy:

HAProxy работает на каждой infra-ВМ, исключая единую точку отказа

клиенты могут подключаться к любому экземпляру HAProxy

при отказе одного экземпляра HAProxy, клиенты переключаются на другие

конфигурация HAProxy синхронизируется между всеми экземплярами

4.8. Автоматическое восстановление после сбоев

Инфраструктурные ВМ реализуют механизмы автоматического восстановления:

Обнаружение сбоя:

потеря heartbeat от вычислительного узла в течение заданного времени

недоступность сервисов на контроллере

сбой виртуальной машины на вычислительном узле

Реакция на сбой:

перезапуск упавших сервисов на том же узле (до 3 попыток)

при невозможности восстановления на том же узле - поиск альтернативного узла

для критических ВМ - автоматический перезапуск на другом узле

обновление состояния в базе данных и синхронизация между infra-ВМ

Восстановление:

после восстановления узла он автоматически возвращается в пул

запущенные на нем ВМ проходят проверку целостности

информация о восстановлении логируется и отправляется администратору

4.9. Управление кластером через API

Инфраструктурные ВМ предоставляют API для управления кластером:

Управление узлами:

добавление нового вычислительного узла в кластер

исключение узла из кластера (плановое, например, для обслуживания)

получение детальной информации о состоянии узлов

ручное переключение активного контроллера

Управление миграцией:

запуск ручной миграции ВМ на указанный узел

настройка политик автоматической балансировки

просмотр истории и статуса миграций

Управление отказоустойчивостью:

настройка параметров heartbeat и порогов срабатывания

конфигурирование правил автоматического восстановления

просмотр журнала событий отказоустойчивости

4.10. Мониторинг состояния кластера

Инфраструктурные ВМ агрегируют и предоставляют информацию о состоянии кластера:

общая панель состояния всех узлов кластера

графики нагрузки и доступности в реальном времени

история отказов и восстановлений

прогнозирование проблем на основе анализа трендов

оповещения о критических событиях и предупреждения

Раздел 5. Мониторинг и метрики

В системе CEE Hypervisor сбор, хранение и анализ метрик реализованы на базе Prometheus — ведущей открытой системы мониторинга с мощным языком запросов и эффективной моделью хранения временных рядов. Prometheus выполняет периодический сбор метрик со всех компонентов системы, предоставляет возможность гибкой выборки данных и генерации оповещений на основе заданных правил. При необходимости визуализации собранных данных может быть интегрирована Grafana — платформа для создания аналитических дашбордов, предоставляющая широкие возможности настройки отображения метрик и построения сложных систем визуального мониторинга.

5.1. Архитектура мониторинга

Система мониторинга CEE Hypervisor построена по следующей архитектуре:

экспортеры: компоненты, собирающие метрики с вычислительных узлов, виртуальных машин и сервисов CEE, и предоставляющие их в формате, понятном Prometheus

сервер Prometheus: центральный компонент, выполняющий сбор, хранение и обработку метрик

Alertmanager: компонент для управления оповещениями, их маршрутизации и отправки в различные каналы

Grafana (опционально): система визуализации для создания информативных дашбордов

5.2. Сбор метрик с вычислительных узлов

Prometheus через своих экспортеров собирает следующие метрики с каждого вычислительного узла:

загрузка процессора (общая и по отдельным ядрам)

использование оперативной памяти (всего, свободно, используется, кэш)

дисковый ввод-вывод (операции чтения/записи, latency, очередь)

сетевой трафик (входящий/исходящий, ошибки, потерянные пакеты)

количество запущенных процессов и состояние системы

температура и частота процессора (при наличии поддержки оборудования)

состояние файловых систем и использование inode

Метрики собираются через библиотеку psutil и экспортируются в формате, совместимом с Prometheus, через специальный экспортер, встроенный в компоненты CEE.

5.3. Сбор метрик с виртуальных машин

Для каждой виртуальной машины Prometheus собирает:

использование CPU (в процентах от выделенного и в абсолютных значениях)

использование памяти (в процентах от выделенной и в абсолютных значениях)

дисковые операции (чтение/запись, количество операций, latency)

сетевой трафик (входящий/исходящий, количество пакетов)

время работы (uptime) и состояние ВМ

метрики гостевой системы (при установке агентов)

5.4. Сбор метрик с сервисов CEE

Отслеживается состояние и производительность самих компонентов CEE:

доступность и время ответа API-эндпоинтов

количество активных WebSocket-соединений

время выполнения операций с libvirt

частота и длительность миграций ВМ

состояние очередей и производительность базы данных

частота ошибок при выполнении операций

5.5. Хранение и обработка метрик

Prometheus обеспечивает:

периодический сбор метрик с заданным интервалом (по умолчанию 15 секунд)

хранение метрик в формате временных рядов на локальном диске

эффективное сжатие данных для экономии пространства

поддержку долговременного хранения через интеграцию с внешними системами

мощный язык запросов PromQL для агрегации, фильтрации и анализа метрик

5.6. Визуализация метрик

Встроенная визуализация

Фронтенд CEE Hypervisor обеспечивает отображение метрик в реальном времени с использованием библиотеки Chart.js:

графики загрузки CPU по ядрам и общая

графики использования памяти с разбивкой по типам

графики дискового и сетевого ввода-вывода

исторические данные за выбранный период (час, день, неделя, месяц)

тепловые карты загрузки кластера

Интеграция с Grafana

При необходимости более глубокой аналитики система может быть интегрирована с Grafana:

подключение Prometheus в качестве источника данных

создание специализированных дашбордов для разных ролей пользователей

настройка сложных визуализаций (смешанные графики, таблицы, статусные панели)

организация единого окна мониторинга для всей инфраструктуры

шаблонизация дашбордов для быстрого развертывания

аннотации событий (миграции, создание ВМ, сбои) на графиках

Примеры предустановленных дашбордов Grafana:

общая панель состояния кластера

детальный мониторинг вычислительных узлов

мониторинг отдельной виртуальной машины

панель производительности хранилища

сетевая аналитика и статистика трафика

5.7. Экспорт метрик

Система поддерживает экспорт метрик в формате Prometheus через стандартный эндпоинт /metrics, что позволяет:

интегрировать CEE Hypervisor с существующей инфраструктурой мониторинга предприятия

использовать внешние инсталляции Prometheus для централизованного сбора метрик

применять федеративные модели сбора данных для крупных кластеров

5.8. Оповещения о событиях

Alertmanager обеспечивает гибкую систему оповещений на основе правил, заданных в Prometheus:

Базовые правила оповещения:

недоступность вычислительного узла (отсутствие heartbeat более заданного времени)

критическая загрузка CPU на узле или ВМ (выше 90% в течение 5 минут)

исчерпание свободной оперативной памяти

заполнение дискового пространства хранилища (более 85%, более 95%)

высокая нагрузка дискового ввода-вывода

сетевые сбои и потери пакетов

сбои миграции виртуальных машин

длительное выполнение операций с ВМ

Каналы оповещений:

webhook для интеграции с внешними системами (Slack, Telegram, Microsoft Teams)

отправка электронной почты через SMTP

запись в лог-файлы

системные уведомления (systemd journal)

SNMP-ловушки для интеграции с корпоративными системами мониторинга

5.9. Исторические данные и тренды

На основе данных Prometheus система обеспечивает:

анализ трендов использования ресурсов для планирования мощностей

выявление пиковых нагрузок и периодичности в потреблении ресурсов

прогнозирование исчерпания ресурсов на основе исторических данных

отчеты об использовании ресурсов по проектам и пользователям

аудит производительности для оптимизации размещения ВМ

5.10. Мониторинг через API

Все метрики доступны для программного доступа через API системы:

получение текущих метрик в формате JSON

запрос исторических данных за произвольный период

получение статуса оповещений и правил

управление правилами сбора метрик (включение/отключение)

Раздел 6. Безопасность и управление доступом

В системе CEE Hypervisor функции аутентификации, авторизации и управления проектами реализованы по аналогии с сервисом Keystone в платформе OpenStack. Keystone выступает центральным каталогом пользователей и сервисов, обеспечивая единую точку интеграции для всех компонентов системы. Он отвечает за проверку подлинности пользователей, выдачу токенов доступа, управление ролями и разграничение прав доступа на уровне проектов. Кроме того, Keystone ведет реестр всех сервисов системы и их эндпоинтов, что позволяет другим компонентам обнаруживать друг друга и взаимодействовать через единый каталог.

6.1. Управление пользователями

Система через Keystone обеспечивает полный жизненный цикл учетных записей пользователей:

создание пользователей с указанием имени, пароля и контактной информации

блокировка и разблокировка учетных записей

сброс и смена паролей

удаление пользователей из системы

Пароли хранятся в базе данных в хешированном виде с использованием bcrypt. При аутентификации Keystone проверяет учетные данные и при успешной проверке выпускает JWT-токен, который используется для всех последующих запросов к API системы.

6.2. Управление проектами

Keystone реализует концепцию проектов (тенантов) для логической изоляции ресурсов и пользователей. Проект представляет собой организационную единицу, объединяющую виртуальные машины, образы, сети и другие ресурсы:

создание проектов с уникальным именем и описанием

назначение пользователей в проекты с определенными ролями

изоляция ресурсов между проектами (пользователи видят только ресурсы своих проектов)

квотирование ресурсов на уровне проектов (ограничение на количество ВМ, объем памяти, дисковое пространство)

архивирование и удаление проектов с каскадным удалением всех связанных ресурсов

6.3. Управление ролями и правами доступа

Keystone поддерживает гибкую ролевую модель, определяющую, какие действия пользователь может выполнять в рамках проекта или системы в целом:

Системные роли (глобальные):

администратор системы: полный доступ ко всем функциям и проектам

аудитор: просмотр всех логов и метрик без права внесения изменений

Роли уровня проекта:

владелец проекта: полное управление ресурсами внутри проекта, добавление и удаление участников

оператор: создание и управление ВМ, образами, снапшотами в рамках проекта

наблюдатель: просмотр ресурсов проекта без права внесения изменений

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

6.4. Каталог сервисов

Keystone ведет реестр всех сервисов, входящих в состав CEE Hypervisor, и их эндпоинтов:

регистрация сервиса при его запуске (тип сервиса, имя, описание)

публикация эндпоинтов для доступа к сервису (публичные, внутренние, административные)

обнаружение сервисов другими компонентами системы через запросы к каталогу

версионирование API и поддержка множественных эндпоинтов для разных регионов или сетей

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

6.5. Аутентификация пользователей

Реализована JWT-аутентификация с проверкой учетных данных, хешированием паролей bcrypt и генерацией токенов с ограниченным временем жизни. Keystone поддерживает множество методов аутентификации:

аутентификация по паролю (имя пользователя и пароль)

аутентификация по токену (использование ранее выданного токена)

аутентификация по сертификатам (для сервисных учетных записей)

поддержка внешних источников аутентификации (LDAP, Active Directory)

6.6. Авторизация и проверка прав

При каждом запросе к API Keystone проверяет наличие у пользователя соответствующих прав:

извлечение токена из запроса и его валидация

определение пользователя и его ролей в контексте запрашиваемого проекта

проверка соответствия запрашиваемого действия ролевым разрешениям

кеширование результатов проверки для повышения производительности

6.7. Аудит действий

Ведется лог аудита всех значимых действий с фиксацией времени, пользователя, IP-адреса, типа операции, объекта и результата. Аудит охватывает:

все действия аутентификации (успешные и неуспешные попытки входа)

изменения в пользователях, проектах и ролях

доступ к ресурсам с нарушением прав

административные действия в системе

6.8. Изоляция ресурсов

При включенной многоарендности обеспечивается изоляция ВМ и ресурсов между пользователями с учетом квот и прав доступа к образам. Keystone гарантирует, что:

пользователь видит только ресурсы своих проектов

ресурсы одного проекта не доступны из другого проекта

квоты на уровне проекта предотвращают исчерпание общих ресурсов одним проектом

образы могут быть приватными (внутри проекта) или общими (доступными нескольким проектам)

Раздел 7. Сетевое взаимодействие

В системе CEE Hypervisor управление сетевыми ресурсами реализовано по аналогии с сервисом Neutron в платформе OpenStack. Neutron обеспечивает абстракцию физических сетевых ресурсов и предоставляет сетевое подключение как сервис (Networking-as-a-Service), позволяя создавать сложные виртуальные сети, маршрутизаторы, плавающие IP-адреса и правила безопасности без необходимости ручной настройки физического оборудования. Благодаря модульной архитектуре, Neutron поддерживает различные драйверы реализации, включая стандартные мосты Linux, Open vSwitch (OVS) и высокопроизводительный DPDK для приложений, требующих минимальных задержек и максимальной пропускной способности.

7.1. Архитектура Neutron

Neuron построен по модульной схеме, состоящей из следующих компонентов:

Сервер Neutron (neutron-server):

принимает и обрабатывает API-запросы на создание и управление сетевыми ресурсами

взаимодействует с базой данных для хранения состояния сети

передает команды агентам на вычислительных узлах

Плагины и драйверы:

реализуют конкретные механизмы сетевой коммутации

поддерживают различные технологии (Linux Bridge, OVS, DPDK)

обеспечивают расширяемость для поддержки нового оборудования

Агенты Neutron:

запускаются на каждом вычислительном узле

выполняют локальные сетевые операции

взаимодействуют с локальным коммутатором и гипервизором

DHCP-агент:

обеспечивает автоматическую выдачу IP-адресов виртуальным машинам

управляет изолированными DHCP-серверами для каждой сети

L3-агент:

реализует маршрутизацию между виртуальными сетями

обеспечивает NAT и плавающие IP-адреса

управляет шлюзами для доступа во внешние сети

7.2. Типы драйверов сетевой коммутации

7.2.1. Open vSwitch (OVS)

Open vSwitch представляет собой многофункциональный виртуальный коммутатор с открытым исходным кодом, поддерживающий стандартные протоколы управления и мониторинга.

Преимущества OVS:

поддержка стандартных протоколов управления (OpenFlow, OVSDB)

расширенные возможности мониторинга и трассировки трафика

поддержка туннельных протоколов (VXLAN, GRE, Geneve)

гибкая политика качества обслуживания (QoS)

возможность интеграции с аппаратными коммутаторами

поддержка групп безопасности на уровне портов

Конфигурация OVS в CEE Hypervisor:

Настройка OVS на вычислительном узле выполняется автоматически при деплое или может быть выполнена вручную:

text

# Установка пакетов OVS

sudo apt install openvswitch-switch openvswitch-common

# Создание интеграционного моста

sudo ovs-vsctl add-br br-int

# Создание туннельного моста для overlay-сетей

sudo ovs-vsctl add-br br-tun

# Подключение физического интерфейса (если требуется)

sudo ovs-vsctl add-port br-eth1 eth1

# Просмотр конфигурации

sudo ovs-vsctl show

7.2.2. DPDK (Data Plane Development Kit)

DPDK представляет собой набор библиотек и драйверов для высокоскоростной обработки пакетов в пользовательском пространстве, позволяющий достичь производительности, сравнимой с аппаратными коммутаторами.

Требования к использованию DPDK:

поддержка сетевой картой технологии DPDK (проверка через dpdk-devbind)

выделение значительных страниц памяти (hugepages) для работы DPDK

изоляция ядер CPU для обработки пакетов (CPU pinning)

дополнительная настройка BIOS (включение VT-d, SR-IOV)

значительные ресурсы оперативной памяти для буферов пакетов

Преимущества DPDK:

минимальные задержки при обработке пакетов (единицы микросекунд)

высокая пропускная способность (до 10-100 Гбит/с)

предсказуемая производительность без "зависаний"

снижение нагрузки на ядро операционной системы

поддержка точной синхронизации времени (PTP)

Проверка совместимости сетевой карты:

text

# Просмотр доступных сетевых интерфейсов

dpdk-devbind --status

# Пример вывода для совместимой карты

Network devices using DPDK-compatible driver

============================================

0000:03:00.0 'Ethernet Controller X710 for 10GbE SFP+' drv=vfio-pci

0000:03:00.1 'Ethernet Controller X710 for 10GbE SFP+' drv=vfio-pci

Конфигурация DPDK в CEE Hypervisor:

Настройка узла для работы с DPDK требует предварительной конфигурации системы:

text

# Настройка hugepages (в /etc/default/grub)

GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=8"

# Выделение ядер для DPDK

# изоляция ядер через isolcpus в параметрах ядра

# Привязка интерфейса к драйверу vfio-pci

dpdk-devbind --bind=vfio-pci 0000:03:00.0

dpdk-devbind --bind=vfio-pci 0000:03:00.1

7.3. Управление виртуальными сетями

Neutron через выбранный драйвер обеспечивает полный цикл управления виртуальными сетями:

Создание сети:

поддержка плоских (flat) сетей без изоляции

изолированные сети VLAN с тегированием 802.1Q

overlay-сети VXLAN для масштабируемых мультитенантных сред

сети GRE для совместимости с существующей инфраструктурой

Создание подсетей:

определение диапазона IP-адресов (CIDR)

настройка пулов DHCP для автоматической выдачи адресов

указание шлюза по умолчанию и DNS-серверов

поддержка IPv4 и IPv6

Управление портами:

создание виртуальных портов для подключения ВМ

назначение фиксированных или плавающих IP-адресов

привязка правил безопасности к портам

мониторинг статистики трафика на портах

7.4. Маршрутизация и NAT

L3-агент Neutron обеспечивает маршрутизацию между сетями и доступ во внешние сети:

Виртуальные маршрутизаторы:

создание логических маршрутизаторов для связи между сетями проекта

поддержка статической и динамической маршрутизации

изоляция маршрутизации между разными проектами

Плавающие IP-адреса:

назначение публичных IP-адресов виртуальным машинам

динамическое связывание и отвязывание плавающих IP

поддержка 1:1 NAT для доступа из внешних сетей

SNAT (Source NAT):

обеспечение доступа ВМ в интернет без публичных IP

маскирование исходящего трафика под адрес шлюза

балансировка исходящих соединений

7.5. Группы безопасности

Neutron реализует межсетевое экранирование на уровне портов:

Правила групп безопасности:

разрешающие правила (deny по умолчанию, allow явно)

фильтрация по протоколам (TCP, UDP, ICMP)

ограничение по портам источника и назначения

фильтрация по CIDR или другим группам безопасности

Примеры правил:

text

# Разрешить SSH (порт 22) из любой сети

направление: ingress

протокол: TCP

порт назначения: 22

удаленный CIDR: 0.0.0.0/0

# Разрешить весь трафик между ВМ в группе

направление: ingress

протокол: любой

удаленная группа: default

# Разрешить ICMP (ping) из подсети управления

направление: ingress

протокол: ICMP

удаленный CIDR: 192.168.10.0/24

7.6. Распределенная маршрутизация (DVR)

Для крупных кластеров Neutron поддерживает распределенную маршрутизацию:

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

устранение единой точки отказа в центральном маршрутизаторе

снижение нагрузки на сеть при трафике между ВМ на одном узле

улучшение производительности для east-west трафика

7.7. Интеграция с аппаратными коммутаторами

Neutron может интегрироваться с физическим сетевым оборудованием:

управление через протокол OpenFlow

интеграция с Cisco Nexus, Arista, Mellanox

использование SR-IOV для прямого доступа ВМ к сетевым картам

поддержка аппаратного ускорения для DPDK

7.8. Мониторинг сетевой инфраструктуры

Система обеспечивает сбор и отображение сетевых метрик:

статистика по каждому порту (пакеты, байты, ошибки)

загрузка сетевых интерфейсов вычислительных узлов

состояние туннелей VXLAN/GRE

метрики производительности OVS и DPDK

обнаружение сетевых аномалий и атак

7.9. Конфигурация Neutron в CEE Hypervisor

Настройка Neutron выполняется через конфигурационные файлы, создаваемые в процессе деплоя инфраструктурных ВМ:

text

[neutron]

core_plugin = ml2

service_plugins = router, firewall, metering

dhcp_agents_per_network = 2

[ml2]

type_drivers = flat, vlan, vxlan, gre

tenant_network_types = vxlan

mechanism_drivers = openvswitch, l2population

[ml2_type_vxlan]

vni_ranges = 1:1000

[ovs]

bridge_mappings = physnet1:br-eth1

datapath_type = system  # или "netdev" для DPDK

Раздел 8. Администрирование

В системе CEE Hypervisor администрирование реализовано через двухуровневую модель представления, разделяющую интерфейс администратора и интерфейс пользователя проекта. Основной пользователь admin обладает неограниченными правами во всей системе и отвечает за настройку глобальных параметров, управление пользователями, распределение ресурсов и конфигурацию инфраструктурных компонентов. Интерфейс системы разделен на две логические вкладки: "Проект" и "Админ", каждая из которых предоставляет соответствующий уровень доступа и возможностей.

8.1. Модель интерфейса администрирования

Вкладка "Проект"

Вкладка проекта предназначена для повседневной работы пользователей и операторов в рамках конкретного проекта. В этой вкладке:

отображаются только ресурсы, принадлежащие данному проекту

пользователь видит только те виртуальные машины, образы, сети и снапшоты, к которым у него есть доступ

при создании ресурсов доступны только упрощенные настройки, не требующие знания инфраструктурных деталей

интерфейс ориентирован на решение прикладных задач пользователя

Например, при создании сети в рамках проекта пользователь указывает только имя сети. Система автоматически выбирает подходящий тип сети, диапазон VLAN и другие параметры на основе настроек проекта и глобальных политик.

Вкладка "Админ"

Вкладка администратора предоставляет полную видимость и контроль над всеми ресурсами кластера:

отображаются все ресурсы всех проектов без ограничений

администратор видит техническую информацию о каждом ресурсе (тип сети, идентификатор VLAN, физический узел размещения и т.д.)

доступны расширенные параметры при создании и настройке ресурсов

предоставляются инструменты для мониторинга состояния всей инфраструктуры

доступны журналы аудита и системные логи всех компонентов

8.2. Управление пользователями и ролями

Администратор через интерфейс вкладки "Админ" управляет учетными записями пользователей и их правами:

Создание и управление пользователями:

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

блокировка и разблокировка учетных записей

сброс паролей пользователей

удаление пользователей из системы (с предварительным переносом или удалением ресурсов)

просмотр истории активности пользователя

Назначение прав и ролей:

назначение пользователей в проекты с указанием роли (владелец, оператор, наблюдатель)

изменение роли пользователя в проекте

назначение глобальных ролей (администратор, аудитор)

управление группами пользователей для массового назначения прав

Управление проектами:

создание новых проектов с указанием названия и описания

назначение владельцев проекта

установка квот и ограничений для проекта

приостановка и архивирование проектов

удаление проектов с каскадным удалением всех связанных ресурсов

8.3. Управление квотами и ограничениями

Администратор устанавливает глобальные ограничения ресурсов и квоты по умолчанию для новых проектов:

Глобальные ограничения:

максимальное количество проектов в системе

максимальное количество пользователей

суммарные лимиты ресурсов по всему кластеру

резервирование ресурсов для системных нужд

Квоты проекта по умолчанию:

максимальное количество виртуальных машин в проекте

максимальное суммарное количество vCPU для всех ВМ проекта

максимальный суммарный объем оперативной памяти (ГБ)

максимальный объем дискового хранилища (ГБ)

максимальное количество сетей и подсетей

максимальное количество плавающих IP-адресов

максимальное количество снапшотов

Индивидуальные настройки проекта:

Администратор может изменять квоты для конкретного проекта, превышая или уменьшая значения по умолчанию:

увеличение лимитов для проектов с высокими потребностями

временное увеличение квот под конкретные задачи

установка предупреждений при приближении к лимитам

просмотр текущего использования ресурсов по каждому проекту

8.4. Администрирование сетевых ресурсов

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

Создание сети от имени администратора:

Пользователь проекта указывает только имя сети, тогда как администратор может задать:

тип сети (flat, VLAN, VXLAN, GRE)

идентификатор VLAN (для сетей VLAN)

сегментационный ID (для VXLAN/GRE)

физический интерфейс, к которому привязана сеть

MTU (максимальный размер пакета)

параметры изоляции и мультиарендности

привязку к конкретным вычислительным узлам

Создание подсети:

Администратор дополнительно может указать:

пул исключенных адресов (не выдаваемых по DHCP)

статические маршруты для подсети

параметры DHCP (время аренды, опции)

DNS-серверы, отличные от глобальных

Настройка маршрутизации:

создание сложных топологий с множеством маршрутизаторов

настройка статической маршрутизации между проектами

конфигурация BGP для взаимодействия с внешними маршрутизаторами

настройка политик QoS на портах маршрутизаторов

8.5. Администрирование образов

При управлении образами администратор имеет дополнительные возможности:

Загрузка и управление образами:

загрузка образов в общее хранилище, доступное всем проектам

назначение образов конкретным проектам

установка метаданных образов (минимальные требования к ресурсам, архитектура, версия ОС)

конвертация между форматами (raw, qcow2, vmdk)

создание цепочек снапшотов для шаблонов

Политики хранения образов:

настройка автоматической репликации образов на все вычислительные узлы

установка политик кэширования образов

ограничение на максимальный размер загружаемого образа

контроль версий и устаревание образов

8.6. Администрирование вычислительных узлов

Администратор управляет инфраструктурой вычислительных узлов:

Управление узлами:

добавление новых вычислительных узлов в кластер

вывод узлов из эксплуатации (с предварительной миграцией ВМ)

мониторинг состояния и производительности узлов

обновление программного обеспечения на узлах

настройка параметров гипервизора (CPU pinning, hugepages, NUMA)

Настройка политик планирования:

установка весов для алгоритмов балансировки

создание групп узлов с особыми характеристиками (GPU, быстрые диски)

привязка проектов к определенным группам узлов

настройка резервирования ресурсов для системных нужд

8.7. Администрирование хранилища

Управление системой хранения данных:

Управление пулами хранения:

создание и настройка пулов хранения (локальные, NFS, Ceph)

мониторинг использования дискового пространства

настройка политик восстановления при сбоях

управление снапшотами на уровне хранилища

Настройка типов дисков:

создание классов хранения с разными характеристиками (SSD, HDD, high-performance)

установка цен и квот для разных классов

настройка политик thin provisioning

8.8. Аудит и мониторинг для администратора

Администратор имеет доступ к расширенным инструментам мониторинга:

Журнал аудита:

просмотр всех действий всех пользователей

фильтрация по пользователю, проекту, типу операции, времени

экспорт аудита для внешних систем

настройка оповещений о подозрительных действиях

Системные логи:

доступ к логам всех компонентов CEE

просмотр логов вычислительных узлов и контроллеров

интеграция с централизованными системами сбора логов (ELK, Loki)

Метрики и оповещения:

просмотр всех метрик Prometheus без ограничений

создание и настройка правил оповещений

управление каналами оповещений

просмотр истории инцидентов

8.9. Управление конфигурацией системы

Администратор управляет глобальной конфигурацией CEE Hypervisor:

Параметры системы:

настройка эндпоинтов сервисов

конфигурация параметров аутентификации (время жизни токенов, методы аутентификации)

настройка интеграции с внешними системами (LDAP, Active Directory)

управление лицензиями и ограничениями

Политики безопасности:

настройка требований к сложности паролей

установка политик блокировки при множественных неудачных попытках входа

настройка сессий и таймаутов

управление сетевыми политиками изоляции

8.10. Примеры расширенных действий администратора

Создание сети с явным указанием VLAN:

text

POST /api/admin/networks

    "name": "production-vlan-101",

    "project_id": "project-123",

    "type": "vlan",

    "vlan_id": 101,

    "physical_network": "physnet1",

    "mtu": 9000,

    "shared": false,

    "description": "Выделенная VLAN для production-среды"

Установка индивидуальных квот проекта:

text

POST /api/admin/quotas/project-456

    "instances": 50,

    "cores": 100,

    "ram_mb": 409600,

    "volumes_gb": 5000,

    "floating_ips": 20,

    "networks": 10,

    "snapshots": 30

Создание образа с метаданными:

text

POST /api/admin/images

    "name": "ubuntu-22.04-server",

    "file": "ubuntu-22.04.qcow2",

    "format": "qcow2",

    "min_ram_mb": 2048,

    "min_disk_gb": 20,

    "architecture": "x86_64",

    "os_type": "linux",

    "os_distro": "ubuntu",

    "os_version": "22.04",

    "visibility": "public",

    "projects": ["project-123", "project-456"]

Заключение

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