Отказоустойчивая пара Aruba Mobility Controller 7000: проект и тесты

Что значит «переключение без потери сессий» на практике

Фраза «переключение без потери сессий» обычно означает не «идеально ноль пакетов потеряно», а то, что пользователь не замечает сбоя. Звонок в мессенджере не обрывается, VPN не требует повторного логина, веб-форма не сбрасывается, а RDP или VDI просто замирает на секунду и продолжает работать.

В отказоустойчивой паре Aruba Mobility Controller 7000 важны два слоя: как быстро контроллеры меняются ролями и что именно они успевают передать друг другу, чтобы клиенты не «стартовали с нуля». Если при переключении меняется IP-адрес шлюза, теряются ключи шифрования или расходятся политики, клиент почти всегда переподключится, даже если Wi-Fi сигнал отличный.

Чаще всего обрывы происходят из-за вполне приземленных причин: меняется адресация или маршрут и трафик идет другим путем; не сохраняется состояние безопасности и начинается повторная аутентификация; не переносится таблица состояний (например, для гостевого доступа, NAT или межсетевых правил); таймеры приложений короче, чем реальное время восстановления; часть клиентов «паникует» и агрессивно пересканирует сеть.

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

Заранее договоритесь о реалистичном критерии «без потери». Для веб-сессий допустима короткая пауза, а для голоса уже 2-3 секунды тишины могут считаться провалом. И это зависит не только от контроллеров, но и от клиентов, драйверов, настроек VPN и поведения конкретных приложений.

Выбор схемы отказоустойчивости для серии 7000

Для контроллеров Aruba 7000 чаще всего выбирают схему active-standby: один узел обслуживает клиентов, второй держит актуальное состояние и готов принять нагрузку. Это понятный вариант для одной площадки и одной пары, когда важнее предсказуемость переключения, чем максимальная утилизация оборудования. В этой модели проще согласовать с сетью, безопасностью и эксплуатацией, что именно считается «без потери сессий».

Схема N+1 нужна, когда контроллеров больше двух и вы хотите один «запасной» узел на несколько основных. Она оправдана в крупных инсталляциях, где нагрузка распределена, а простой одного контроллера не должен выбить площадку по емкости. Цена здесь не только в железе, но и в дисциплине: важно доказать расчетами, что при отказе любого узла оставшиеся выдержат пик, а критичные SSID не уйдут в перегруз.

В паре должно совпадать то, что напрямую влияет на поведение клиентов при переключении: производительность и интерфейсы, версия ПО и патчи, набор лицензий и включенных функций, базовая конфигурация (VLAN, политики, роли, RADIUS/LDAP, сертификаты), а также схема управления адресами, чтобы клиенты и точки доступа не «увидели» смену узла.

Риски лучше оценить до закупки и тем более до тестов. Спросите владельцев сервисов, что для них чувствительнее всего к короткой паузе: голос и видео (звонки, ВКС), IoT (сканеры, датчики), терминальные сессии (VDI/RDP), критичные бизнес-системы (кассы, медсистемы, СКУД). Простой пример: если в больнице по Wi-Fi работают тележки с медкартами и одновременно идут звонки через Wi-Fi, то критерий успеха будет заметно жестче, чем «клиент переподключился за 30 секунд». Здесь active-standby обычно проще довести до прогнозируемого результата, а N+1 требует аккуратного расчета емкости и приоритетов трафика.

Что проверить до проектирования: сеть, сервисы и зависимости

Перед тем как рисовать схему отказоустойчивой пары Aruba Mobility Controller 7000, зафиксируйте рамки работ. Согласуйте окно изменений, критерии успеха (что именно считаем «без потери сессий») и понятный план отката. Откат должен быть реалистичным: кто выполняет, сколько времени занимает, что именно возвращаем в исходное состояние.

Дальше проверьте адресацию и сегменты, которые будут затронуты. Частая причина проблем в HA - когда management, пользовательские VLAN, гостевой сегмент и служебные сети пересекаются, нет маршрутизации или на пути стоят разные правила. Убедитесь, что для контроллеров и точек доступа заранее определены адреса и шлюзы, а также где именно будет жить VIP (если он используется в вашей схеме).

Отдельно подтвердите базовые сервисы и зависимости. В HA ломается не «Wi-Fi вообще», а конкретные функции, завязанные на инфраструктуру.

Минимальный набор проверок перед дизайном

• Время: NTP доступен из нужных VLAN, время совпадает на контроллерах, коммутаторах и сервисах.
• Имена и адреса: DNS резолвит нужные записи, нет конфликтов в IP и DHCP scope.
• Выдача адресов: DHCP для пользователей и гостя работает стабильно, понятны опции (если используются).
• Безопасность: сертификаты и цепочки доверия готовы (особенно для 802.1X/порталов), сроки не «на исходе».
• Аплинки: LACP или статические каналы настроены одинаково, STP не заблокирует порт неожиданно, MTU согласован, QoS для голоса включен на нужных участках.

Наконец, подготовьте «набор для тестов»: список точек доступа по моделям и прошивкам и набор клиентских устройств, которые реально есть в сети (Windows, macOS, iOS/Android, терминалы, Wi-Fi телефоны). Если в офисе есть Wi-Fi телефония и VDI, включите эти сценарии в будущие проверки. Иначе легко получить красивый отчет, но реальные жалобы после ввода.

Пошаговый дизайн пары: адреса, роли и каналы синхронизации

Дизайн HA начинается с простого: кто активный, кто резервный, и как вы будете управлять парой. Для отказоустойчивой пары Aruba Mobility Controller 7000 чаще всего выбирают Active-Standby: один контроллер ведет трафик и сессии, второй постоянно готов принять нагрузку.

Сразу договоритесь о модели управления: отдельные адреса для каждого контроллера (для администрирования) и единая «точка входа» для тех сервисов, которые не должны менять адрес при переключении.

Адреса и роли

Адресная схема должна переживать failover без перенастройки AP и без «прыжков» шлюза для клиентов. Обычно это достигается виртуальными IP (VIP) или общими сервисными адресами, которые «переезжают» на резервный контроллер при аварии.

Практичный порядок проектирования:

• Назначьте роли и закрепите их: active, standby, плюс отдельные management-IP для каждого.
• Определите VIP для ключевых функций (например, адрес, на который «смотрят» AP или сервисы аутентификации), чтобы при переключении ничего не менялось.
• Выделите отдельный канал для heartbeat и state sync (желательно изолированный от пользовательского трафика) и зафиксируйте требования: стабильная задержка, отсутствие потерь, достаточная полоса.
• Проверьте, что маршрутизация и ACL одинаково пропускают нужные потоки к обоим контроллерам (RADIUS, DNS, DHCP, NTP, журналы). Иначе резервный «встанет», но не сможет обслуживать.

Каналы синхронизации и запас по мощности

Если канал синхронизации перегружен или нестабилен, «переключение без потери сессий» превращается в частичное восстановление: клиенты переподключаются, приложения рвутся.

Перед финальным дизайном соберите базовый профиль нагрузки: пиковое число клиентов и одновременных сессий (с запасом), количество туннелей/SSID и объем шифрования (это нагрузка на CPU), пропускную способность uplink и state sync в часы пик, доступность лицензий и функций на обоих узлах, а также запас по памяти и CPU, чтобы standby выдержал всю нагрузку один.

Если, например, в больнице Wi-Fi используют врачи с голосовой связью и телеметрией, заранее закладывайте VIP для критичных сервисов, отдельный стабильный канал синхронизации и одинаковые правила доступа к RADIUS/DNS. Тогда при отказе активного контроллера клиенты чаще всего продолжают работу без заметного обрыва.

Как добиться сохранения сессий: состояние, ключи и политики

В Wi-Fi «переключение без потери сессий» почти всегда означает одно: при сбое активного контроллера клиенты не должны заново проходить полный цикл подключения и аутентификации, а прикладные соединения должны пережить короткую паузу. Для этого в отказоустойчивой паре Aruba Mobility Controller 7000 важно заранее договориться, что именно должно сохраняться, и убедиться, что это действительно синхронизируется.

Первое правило для отказоустойчивой пары Aruba Mobility Controller 7000 - один источник правды для конфигурации. Если часть настроек меняют на первом контроллере, а часть на втором, вы получите «почти одинаковые» политики. После failover поведение клиентов станет непредсказуемым. Зафиксируйте, кто вносит изменения, как они проверяются и как попадают на оба устройства.

Чтобы сессии жили после переключения, проверьте три слоя синхронизации:

• состояние клиентов и таблицы сессий (roaming, IP, политики, таймеры);
• данные аутентификации (например, результат 802.1X/роль пользователя) и то, где они хранятся;
• ключи шифрования и параметры безопасности SSID, где это применимо, чтобы клиент не видел «новую сеть».

Дальше сравните «лицом к лицу» SSID, роли, ACL, QoS и профили радио на обоих контроллерах. Даже небольшая разница, например в VLAN, captive portal, idle timeout или в правилах NAT, может оборвать VDI, голос или платежный терминал.

Отдельно определите критичный трафик. В клинике это может быть Wi-Fi телефония и медицинские системы, в банке - платежные приложения. Для них заранее включите логи и метрики, по которым видно успех: время переключения, число повторных аутентификаций, переассоциации, потери пакетов и рост задержки. Эти же показатели станут «паспортом» теста и основой для приемки работ, в том числе если проект ведет системный интегратор.

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

Тесты HA стоит планировать как небольшой проект: договориться о критериях успеха, подготовить наблюдение и собрать «базовую линию». Тогда результаты по отказоустойчивой паре Aruba Mobility Controller 7000 будут сравнимыми, а спорные моменты (был ли обрыв или краткая просадка) не останутся «на глаз».

Начните с матрицы сценариев. Она должна покрывать не только «красивое» переключение, но и типовые аварии, которые действительно случаются:

• плановое переключение ролей;
• полное отключение активного контроллера (питание);
• потеря uplink у активного контроллера;
• отказ коммутатора или порта, где подключен контроллер;
• обрыв или деградация канала синхронизации между контроллерами.

Дальше определите контрольные точки на клиентских устройствах. Выбирайте сервисы, где потеря сессии заметна сразу: голосовой звонок, видеозвонок, терминальная/VDI-сессия, отправка веб-формы, а также простые проверки сетевой связности (например, пинг до шлюза и до сервера приложения).

До запуска тестов зафиксируйте базовую линию: задержку и потери, jitter (для голоса), загрузку CPU контроллеров, занятость каналов и число клиентов. На этом фоне проще понять, что ухудшение связано именно с failover, а не с перегрузкой или помехами.

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

Роли на время теста лучше разделить. Один человек следит за клиентами и приложениями, второй смотрит логи и состояние контроллеров, третий контролирует коммутаторы и uplink. Так вы не пропустите момент переключения и быстрее поймете, где именно «рвется» сессия.

Пошаговые сценарии failover: от мягкого до аварийного

Ниже - набор сценариев, которые обычно дают честный ответ: получится ли переключение без заметной паузы для пользователей. Перед стартом договоритесь, что именно считается «без потери сессий»: например, голосовой звонок не рвется, VPN не падает, RDP не выкидывает, а веб-сессия не требует повторного входа.

Перед каждым тестом зафиксируйте исходное состояние: число клиентов на контроллерах, активные SSID, время, текущую загрузку, а также 2-3 «контрольных» пользователя с реальными приложениями (звонок, видеосвязь, корпоративный портал).

Набор тестов от мягкого к жесткому

• Контролируемое переключение (graceful): инициируйте planned switchover и наблюдайте за контрольными клиентами. Ожидаемо: краткая пауза в передаче, но приложения продолжают работу.
• Жесткое отключение питания активного: выключение (power off) показывает, выдержит ли схема реальную аварию. Засеките время до восстановления обслуживания.
• Обрыв uplink активного без выключения: имитируйте потерю связи с сетью (например, отключите порт). Важно, чтобы резервный стал активным из-за потери доступности, а не из-за «случайных» колебаний линка.
• Потеря канала синхронизации пары: разорвите только HA/синхронизацию, оставив оба контроллера в сети. Здесь важно избежать split brain и массовых переподключений без причины.
• Перезапуск части точек доступа: перезагрузите выборочно 10-20% AP и проверьте, что они поднимаются на корректном контроллере и не тянут за собой лавину повторных аутентификаций.

После каждого теста: короткая сверка

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

Как понять, что тест прошел успешно: быстрые проверки

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

Начните с сетевой непрерывности. Если по требованиям у клиентов IP и шлюз должны остаться прежними, проверьте 5-10 устройств из разных SSID и VLAN: IP-адрес, маску, шлюз, время аренды DHCP. Массовая выдача новых адресов обычно означает, что где-то изменился путь до DHCP или просели тайминги.

Дальше проверьте аутентификацию и поведение существующих клиентов. Важно не только то, что новые подключения работают, но и то, что «старые» не ушли в бесконечные запросы 802.1X, не получили неожиданный reauth и не зависли на гостевом портале.

Мини-чек после переключения (10-15 минут)

• Клиенты: IP и шлюз не поменялись (если так задумано), пинг до шлюза стабильный.
• Аутентификация: 802.1X/PSK/гость проходят, нет всплеска повторных запросов и таймаутов.
• Приложения: тестовый звонок, RDP/VDI-сессия, отправка веб-формы без перезагрузки страницы.
• Точки доступа: все AP в ожидаемом состоянии, нет волны переподключений и долгого восстановления.
• Сеть: нет STP-событий, LACP-флапов, заметных задержек DHCP и провалов QoS-очередей.

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

Короткий отчет, который реально помогает

Зафиксируйте время начала и конца переключения, сколько клиентов и AP затронуто, были ли обрывы сессий и где именно. Отдельно отметьте ожидаемые эффекты (например, 1-2 секунды потери пакетов) и неожиданные (например, массовый reauth), чтобы было понятно, что исправлять перед вводом.

Типовые ошибки, из-за которых «без потери сессий» не получается

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

Первая ловушка - разные версии ПО и «почти одинаковые» конфиги. Достаточно одного отличающегося набора политик, VLAN, ролей или параметров шифрования, и после failover часть клиентов пройдет повторную аутентификацию или потеряет доступ к нужным ресурсам.

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

Третья ошибка - изменение адресации при переключении. Если при failover меняются IP, шлюз, виртуальные адреса или маршрут так, что клиенты внезапно видят другой путь, многие устройства реагируют разрывом: VoWiFi-звонок обрывается, терминал склада заново поднимает соединение, VPN-клиент начинает переподключение.

Еще несколько мест, где неприятные сюрпризы встречаются чаще, чем ожидают: DHCP и DNS не рассчитаны на всплеск повторных запросов; QoS для голоса настроен только на контроллере, но не повторен на коммутаторах и аплинках; тестируют «пинг и веб-страницу», но не проверяют реальные приложения и разные типы устройств.

Хороший индикатор проблемы: Wi-Fi остается «подключен», но критичное приложение зависает на 10-30 секунд и потом просит логин заново. Поэтому в тестах нужны живые сценарии: звонок, RDP/VDI, ERP, терминалы, мессенджеры, устройства врачей или кассы, а не только ICMP.

Чеклист перед вводом в эксплуатацию и перед переключением

Перед запуском HA часто «все выглядит правильно», но мелочи потом превращаются в разрыв сессий. Этот чеклист помогает зафиксировать базу и не тратить время на поиск причин во время теста. Для отказоустойчивой пары Aruba Mobility Controller 7000 важнее всего единообразие конфигурации и предсказуемость сетевых зависимостей.

Перед вводом в эксплуатацию

Убедитесь, что оба контроллера работают в одинаковых условиях: одна и та же версия ПО, одинаковые лицензии (если применимо), четко назначенные роли active/standby и понятные правила, кто и когда может стать активным.

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

Канал синхронизации пары проверьте не только на доступность, но и на стабильность: нет ли потерь, скачков задержки, ошибочной маршрутизации или фильтрации. Отдельно убедитесь, что NTP, DNS и DHCP работают устойчиво и имеют запас по производительности, потому что при переключении нагрузка и количество запросов обычно растут.

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

За день до теста подготовьте «набор правды» из реальных клиентов и приложений. Например, в больнице это могут быть телефоны для голосовой связи, ноутбуки врачей, терминалы учета и несколько IoT-устройств. Затем пройдитесь по пунктам:

• подтверждены роли и состояние пары, нет фоновых ошибок и рассинхронизаций;
• виртуальные адреса отвечают как ожидается, точки и клиенты не «прыгают» между сетями;
• NTP/DNS/DHCP доступны, есть мониторинг и контакты дежурных;
• подготовлены тестовые учетные записи и сценарии: голос, VPN, VDI, критичные веб-сервисы;
• есть план отката с точными шагами и назначенными ответственными на каждый этап.

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

Пример: как тестировать HA в организации с критичными сервисами

Представим поликлинику: Wi-Fi телефония (голос), рабочие планшеты врачей, регистратура в МИС, плюс гостевой доступ в зале ожидания. Здесь «переключение без потери сессий» означает не только сохранение Wi-Fi подключения, но и отсутствие обрывов RTP для звонков и разрывов активной сессии в медицинской системе при отказе контроллера.

Нагрузку лучше разделять по смыслу, а не «как получилось». Для пары Aruba Mobility Controller 7000 обычно удобно иметь несколько SSID с разными ожиданиями: для персонала (Enterprise, строгие роли и доступы), для оборудования (предсказуемые ACL и минимум «сюрпризов»), для голоса (приоритет трафика и контроль задержек, если вы выделяете отдельный профиль), для гостей (изоляция и ограничения, где краткое переподключение допустимо).

Тест лучше делать ночью, но так, чтобы результат был понятен за 30 минут. Подготовьте короткий набор живых проверок: один активный звонок, одна сессия в МИС, один RDP/VDI или терминал регистратуры и одно устройство на гостевом SSID.

Ночной тест на 30 минут

Сначала зафиксируйте базу: уровень сигнала в зоне теста, какой контроллер активный, и что все клиенты прошли аутентификацию. Затем выполните 2-3 сценария: мягкое переключение (плановое), перезагрузка активного контроллера и «жесткий» вариант (например, отключение питания). Между сценариями возвращайте систему в исходное состояние.

Где возможны компромиссы

Жесткое требование «без переподключения» обычно оправдано для голоса и рабочих мест регистратуры. Для гостевого доступа и части IoT допустимо краткое переподключение, если оно укладывается в согласованный предел (например, 10-20 секунд) и не приводит к ручным действиям пользователя.

Успех теста в поликлинике - это когда звонок не обрывается, МИС не выкидывает на логин, а максимум, что замечает гость, - короткая пауза в загрузке страницы.

Следующие шаги: как закрепить результат и организовать поддержку

После удачных тестов HA важно зафиксировать то, что реально обеспечило переключение без потери сессий. Соберите короткий эталон: финальная схема (VLAN, IP, роли, порты), версия ПО, включенные функции, правила на коммутаторах и фаерволах, а также параметры, которые нельзя менять без повторной проверки (например, адреса, каналы синхронизации, таймеры и политики).

Рядом держите результаты приемочных тестов: какие сценарии прогоняли, что считали «успехом», какие метрики снимали. Это экономит часы, когда через полгода кто-то спросит: «почему у нас так настроено?».

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

Надежность пары держится на дисциплине контроля. Минимум, который стоит сделать регулярным: проверка состояния HA и синхронизации, алерты на потерю heartbeat, рассинхрон, перезагрузки и заполнение ресурсов, а также журнал изменений (кто и что менял и с чем это было согласовано).

Повторяйте тесты после событий, которые часто ломают «бесшовность»: обновление ArubaOS, замена коммутаторов/транков, новые правила безопасности, переход на другой RADIUS/PKI, изменения в DHCP/DNS. После апдейта ПО, например, переключение может стать быстрее, но клиенты начнут переподключаться из-за изменившихся таймеров или ключей.

Поддержка и ответственность

Назначьте владельца HA (кто принимает решения и дает «ок» на изменения) и окно для плановых проверок. Если своей экспертизы или времени не хватает, приемочные тесты и сопровождение удобнее отдавать интегратору с опытом WLAN.

Если вы в Казахстане, GSE.kz (gse.kz) может помочь с системной интеграцией, подготовкой тест-плана и дальнейшей поддержкой 24/7, чтобы изменения проходили через понятный контроль и не превращались в неожиданный простой.