Active/Active или Active/Passive: как контроллеры СХД ведут себя под нагрузкой и при отказе

Инженеры ЦОД знают неприятный сценарий: оба контроллера на панели зелёные, все пути в ОС видны, а задержка базы растёт без очевидной причины. Чаще всего проблема не в RAID и не в дисках. Хост отправляет I/O к LUN через путь, который для данной логической единицы не является оптимальным.

Термин Active/Active нужно читать аккуратно. Он описывает доступность обоих контроллеров, но не обязательно симметрию маршрутов. Для проектирования SAN важны три вещи: кто обслуживает I/O к конкретному LUN, какие пути multipath считает предпочтительными и что произойдёт с незавершёнными операциями при отказе одного контроллера.

Что происходит в Active/Passive

В схеме Active/Passive один контроллер обслуживает тома и фронтальные подключения. Второй остаётся в резерве: он принимает на себя работу после отказа активного узла или при плановом переключении. До failover его вычислительный ресурс не используется для штатной обработки I/O конкретного сервиса.

• Для LUN существует рабочая сторона и резервная сторона.
• Multipath использует активный путь, а резервный держит для переключения.
• При отказе требуется смена владения ресурсами и восстановление рабочих путей.
• Короткая пауза I/O зависит от ОС, драйвера multipath, тайм-аутов приложения и настройки SAN.

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

Active/Active: два варианта

У Active/Active есть два практических режима. В симметричной реализации оба контроллера могут обслуживать I/O к одному LUN по равноценным путям. В асимметричной реализации оба контроллера остаются активными, однако для конкретного LUN часть путей считается оптимизированной, а часть — активной, но неоптимизированной.

ALUA — Asymmetric Logical Unit Access — сообщает хосту, какие target port group оптимизированы для конкретного LUN. Путь Active/Optimized ведёт к контроллеру, который обслуживает данный LUN напрямую. Путь Active/Non-Optimized остаётся доступным, но I/O может быть передан между контроллерами по внутреннему interconnect. Это добавляет задержку и расходует внутренние ресурсы пары.

ALUA и SLUA: не путайте термины

ALUA — стандартная модель асимметричного доступа к логической единице в SCSI. Её ключевая идея проста: хост должен знать не только о доступности путя, но и о его качестве для конкретного LUN. Поэтому multipath читает статусы групп портов и строит политику маршрутизации вокруг Active/Optimized.

В документации NIMBUS для СХД «Гром» и «Молния» указана Active/Active-архитектура с режимами ALUA/SLUA. Практический вывод для инженера не меняется: не стоит считать все видимые пути автоматически равноправными. Перед вводом СХД в эксплуатацию нужно проверить, как host multipath распознал состояние путей к каждому LUN и какие маршруты использует при реальной нагрузке.

• ALUA помогает хосту отличить оптимизированный маршрут от неоптимизированного.
• Наличие двух контроллеров не отменяет настройку multipath на стороне хоста.
• Round Robin нельзя включать вслепую: он должен обходить оптимизированные пути к конкретному LUN.
• Статусы путей необходимо проверять после создания LUN, изменения zoning и обновления host multipath.

Как переживается отказ контроллера

Отказоустойчивость контроллерной пары — не один механизм, а цепочка. Хост должен иметь несколько физических путей, SAN — независимые фабрики или сегменты, контроллеры — согласованное состояние кэша, а multipath — корректные тайм-ауты и политику повторных попыток. Если хотя бы один слой собран с ошибкой, два контроллера не обеспечат ожидаемой непрерывности.

В СХД NIMBUS «Гром» и «Молния» заявлены два контроллера, зеркальный кэш, защита кэша и горячая замена. Эти свойства важны при потере одного узла: данные, принятые в кэш до сбоя, не должны зависеть от единственной контроллерной памяти, а обслуживание I/O должно продолжаться через оставшуюся сторону. Поддержка ALUA/SLUA относится к front-end-маршрутизации и помогает хосту выбирать доступные пути.

Практический сценарий для ЦОД

Представим кластер виртуализации с двумя fabric Fibre Channel и несколькими datastore. Каждый сервер подключён к обоим контроллерам через независимые коммутаторы. Для каждого LUN администратор проверяет, что multipath видит несколько путей, выделяет Active/Optimized и не направляет постоянный поток на Active/Non-Optimized.

После этого проводится контролируемый тест: на рабочем LUN создаётся предсказуемая нагрузка, затем один front-end-путь отключается, а потом моделируется недоступность одного контроллера. Контролируют не только доступность ВМ, но и задержку I/O, логи multipath, статусы путей и отсутствие ошибок файловой системы. Такой порядок позволяет проверить отказоустойчивость до аварии, а не во время неё.

Для систем с SAS-нагрузкой, смешанными сценариями и расширением ёмкости подойдёт СХД NIMBUS «Гром» для ЦОД. Для критичных БД и низких задержек применяется All-Flash NVMe-платформа «Молния». В обоих случаях финальную политику multipath нужно сверять с операционной системой, HBA, версией драйвера и фактическими статусами путей.

Чек-лист перед запуском

• Подключите каждый host к обоим контроллерам по независимым путям.
• Разделите SAN-фабрики или Ethernet-сегменты так, чтобы отказ одного коммутатора не отрезал сервер от СХД.
• Проверьте обнаружение всех LUN и всех путей на каждом хосте.
• Убедитесь, что multipath различает оптимизированные и неоптимизированные маршруты.
• Настройте балансировку с учётом ALUA, а не только с учётом количества путей.
• Протестируйте потерю пути, перезагрузку контроллера и возврат контроллера в пару.
• Зафиксируйте базовые значения latency, IOPS и ошибок до перевода системы в промышленную эксплуатацию.

FAQ

Active/Active всегда быстрее Active/Passive?

Не всегда. Преимущество Active/Active проявляется, когда host multipath корректно использует доступные оптимизированные пути и нагрузка распределена по LUN и контроллерам. При отправке I/O через неоптимизированные маршруты ALUA можно получить дополнительную внутреннюю пересылку и рост задержки.

Зачем нужен ALUA, если оба контроллера активны?

ALUA передаёт host multipath информацию о предпочтительности путей к конкретному LUN. Это позволяет направлять штатный I/O по Active/Optimized-маршрутам, а Active/Non-Optimized оставлять для переходных ситуаций и отказов.

Можно ли балансировать трафик по всем путям Round Robin?

Только после проверки политики multipath для конкретной ОС и статусов ALUA. Корректная схема балансирует запросы по оптимизированным путям, а не безусловно по каждому видимому target path.

Что защищает данные при отказе контроллера?

Нужна совокупность механизмов: два контроллера, зеркальный кэш, защита кэша, несколько host-путей и multipath. В СХД NIMBUS «Гром» и «Молния» заявлены зеркальный кэш, защита кэша и горячая замена компонентов.

ALUA и метрокластер — одно и то же?

Нет. ALUA относится к выбору путей между host и контроллерами СХД. Метрокластер — отдельная функция ПО «Юпитер» для распределённой отказоустойчивости между площадками; в документации NIMBUS он указан вместе с удалённой репликацией, но не является её синонимом.

Гром

система хранения данных

В реестре

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

Заказать

Подробнее

Молния

система хранения данных

В реестре

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

Заказать

Подробнее