СХД и multipath: программа проверки отказа одного пути
Как связать два контроллера, независимые пути и прикладную проверку переключения.
Начните с полной схемы доступа
Два контроллера СХД — только часть проекта устойчивого доступа к данным. Нарисуйте путь от приложения через операционную систему сервера, адаптер, коммутацию и порт контроллера до нужного тома. Для второго пути повторите этот рисунок. Он помогает увидеть общие элементы: один адаптер, одну фабрику, общую линию питания или неправильно выбранный порт.
Перечислите хосты и тома, которым нужна такая схема. Файловые ресурсы, блочные устройства и локальные диски описывают отдельно. Если в проекте используются разные протоколы, не подменяйте проверку одного из них успешным тестом другого: результат должен относиться к действительному способу доступа приложения.
Потребуйте матрицу совместимости
До заказа согласуйте версии ОС, драйверов, адаптеров, прошивки СХД и поддерживаемый механизм многопутевого доступа. DM Multipath в Linux объединяет несколько путей к одному устройству в логическое устройство. Без такого корректного объединения система может видеть пути как отдельные устройства. Это функция программного стека, а не автоматическое следствие наличия нескольких кабелей.
Попросите интегратора сохранить применяемую конфигурацию, идентификатор тома и подтверждение поддерживаемого сочетания компонентов. Для NVMe и других вариантов доступа отдельно уточните подходящий механизм: инструкция для одного протокола не является универсальной инструкцией для любой СХД. Настройки таймеров согласуются с производителем и приложением.
Определите критерий до испытания
Зафиксируйте, что означает успешное переключение для пользователя: допустимая пауза записи, время ответа приложения, отсутствие повреждения контрольного набора и сохранение согласованной нагрузки. Слова «без простоя» без метода измерения дают слишком мало информации для приёмки. Согласуйте также, как приложение ведёт себя при краткой задержке и по каким журналам это будет видно.
Разделите проверку маршрута и проверку производительности. Сначала установите штатную схему и убедитесь, что все предусмотренные пути видимы и находятся в ожидаемом состоянии. Затем соберите исходные результаты чтения, записи и прикладных операций. В протоколе нужны характеристики нагрузки, а не только показатель скорости одного копирования.
Моделируйте один отказ за раз
Ответственный специалист проводит тест на отдельном контуре и выводит из работы только элемент, указанный в программе: например, один маршрут. В типовой схеме из документации DM Multipath отказ адаптера, кабеля, коммутатора или порта контроллера позволяет перейти к альтернативному пути при правильной конфигурации. Это пример архитектуры; конкретное поведение вашей сборки подтверждается её руководствами и испытанием.
Во время переключения фиксируйте состояние путей, сообщения ОС, события СХД и результаты операций приложения. После возврата элемента проверьте устойчивость схемы и отсутствие повторяющихся переключений. Не моделируйте одновременно несколько аварий: иначе будет трудно определить причину замечания и сравнить результат с согласованным сценарием.
Передайте эксплуатационные документы
В комплект приёмки включите схему путей, идентификаторы томов, версии компонентов, настройки, журнал испытания и порядок действий при потере резервирования. Отдельно перечислите ограничения: какой отказ проверен, какой не моделировался и где остаются общие точки. Это полезнее универсального заявления об отказоустойчивости всей инфраструктуры.
Смена ОС, прошивки или состава адаптеров может потребовать повторной проверки совместимости. Поэтому сохраните первоначальный состав и согласуйте процедуру изменения. Для запроса на подбор СХД приложите эту схему вместе с нагрузкой и требованиями к переключению: поставщики смогут рассчитать сравнимые варианты, а ИТ-служба получит основу для осмысленной приёмки.