Создание автономной лаборатории: Тестовый стенд без облака и с ограниченным бюджетом

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

Значение тестовых стендов

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

Различные VoIP-сервисы могут быть реализованы множеством способов, а значит, возникает потребность в возможности легко воспроизводить и модифицировать такие конфигурации.

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

В основе любого современного VoIP-сервиса лежат следующие ключевые элементы:

• Сетевая инфраструктура (маршрутизация, VLAN и т. п.);
• Центры обработки данных, физические или виртуальные;
• Системы резервного копирования;
• Мониторинг состояния оборудования и сервисов.

Платформы для обучения и тестирования

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

• Персональный компьютер с VirtualBox, QEMU или Virt-Manager;
• Серверы, приобретённые на вторичном рынке (в том числе с AliExpress);
• Мини-компьютеры (например, RockPi, Raspberry Pi);
• Облачные решения, если бюджет позволяет

Однако при наличии даже ограниченных ресурсов можно построить полностью автономную лабораторию. В качестве примера был реализован стенд на основе двух RockPi (аналогов Raspberry Pi), недорогого маршрутизатора MikroTik hAP lite и шлюза LTEX-A8 с аналоговыми портами FXS.

Аппаратная архитектура и особенности

Первоначально стенд состоял из двух RockPi 4B+, каждый из которых оснащён ARM-процессором (Cortex-A72 и Cortex-A53), 4 ГБ оперативной памяти и базовым GPU (не задействован). MikroTik hAP lite использовался в качестве маршрутизатора. Особенностью сборки стало отказоустойчивое питание роутера от RockPi через самодельный провод с MOSFET, что привело к частичной работоспособности схемы — питание шло, но при переключении источника (например, на Powerbank) возникали перебои, связанные с отсутствием конденсатора в hAP lite.

Были подключены IP-телефоны Fanvil, старые аналоговые телефоны, а также шлюз LTEX-A8, обеспечивающий FXS-подключения.

Особенности работы с MikroTik hAP lite

Из-за ограниченного числа портов (4 Ethernet) возникли сложности с доступом в интернет. Решением стал VLAN 10, который был настроен на каждом порту MikroTik, где запускался DHCP-клиент. Далее схема NAT’а позволила подключить лабораторию к интернету через MAP2ND и основной домашний роутер.

Программная платформа: Proxmox на ARM

В качестве гипервизора на RockPi использовался Proxmox. Официально Proxmox не поддерживает архитектуру ARM, поэтому применялись альтернативные сборки:

• PIMAX — устаревший форк для Raspberry Pi (не подходит для RockPi).
• Proxmox Port — активно развивающийся проект, поддерживающий множество ARM-платформ, включая RockPi. Установка производится на базовую систему Armbian, доступны ISO-образы.

Особенности архитектуры ARM (Big.LITTLE) требуют учёта гетерогенности ядер при настройке CPU affinity в виртуалках. Используя lscpu и cat /proc/cpuinfo, можно определить номера ядер одного типа и указать их вручную в настройках виртуальной машины для корректной работы KVM.

Автоматизация и шаблоны

Для упрощения и стандартизации развёртывания были созданы шаблоны виртуальных машин:

• Память: увеличена с 512 МБ до 768 МБ;
• Cloud-Init: использован для конфигурации пользователей, паролей, SSH-ключей;
• Regenerate Image: применялся при клонировании шаблонов для сброса SSH-фингерпринтов.

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

Минимально жизнеспособный кластер Proxmox требует как минимум трёх нод, чтобы при отказе одной сохранить кворум и возможность управления. После добавления третьего RockPi были отпечатаны корпуса с радиаторами. В загруженном состоянии (по два Asterisk и по два OpenSIPS на каждую ноду) объём потребляемой памяти был значительным, но допустимым.

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

На стенде были реализованы:

• Asterisk в разных сценариях (direct call, проксирование через OpenSIPS);
• OSPF-анонсирование маршрутов;
• Проверка устойчивости работы при отключении сетевых интерфейсов;
• Настройка маршрутизации и NAT’а;
• Проведение звонков с IP-телефонов и аналоговых устройств.

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