Hitachi VSP E-Series для критичных приложений: чек-лист SLA

С чего начинается высокий SLA для критичных систем

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

Чаще всего SLA «ломают» не редкие катастрофы, а приземленные вещи: пропало питание в стойке, один контроллер ушел в перезагрузку, отвалилась SAN-сеть, неверно настроили multipath, администратор запустил рискованное действие в рабочее время. Поэтому выбор СХД уровня Hitachi VSP E-Series для критичных приложений имеет смысл только вместе с продуманной схемой внедрения: резервирование по питанию и портам, корректные зоны, понятный план изменений и распределенная ответственность.

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

Перед тем как обсуждать IOPS и объем, зафиксируйте базовые параметры доступности и восстановления. Минимум нужны:

• RPO (сколько данных можно потерять),
• RTO (как быстро нужно восстановиться),
• плановые окна (когда разрешены изменения),
• допустимые риски (какие редкие события бизнес готов принять).

Полезные вопросы к бизнесу, чтобы разговор был про SLA, а не про «скорость»:

• Что считается простоем: недоступность приложения, деградация, потеря части функций?
• Сколько минут простоя в месяц реально допустимы для каждой системы?
• Какая потеря данных приемлема: 0 секунд, 5 минут, 1 час?
• Есть ли «пиковые» периоды, когда любые работы запрещены (отчетность, платежные окна)?
• Кто принимает решение об остановке, откате и запуске аварийного плана?

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

Как превратить SLA в понятные технические требования

SLA полезен только тогда, когда его можно перевести в цифры и проверки. Начните с простого: какой простой вообще допустим. Например, 99,99% доступности - это около 52 минут простоя в год, а 99,9% - уже примерно 8 часов 46 минут. Эти минуты и часы важно разложить по причинам: аварии, деградации, восстановление, плановые работы.

Разделяйте доступность сервиса и доступность хранилища. СХД может быть доступна, а бизнес-сервис - нет из-за сбоя на уровне приложений, сети SAN или кластеров. Поэтому требования стоит фиксировать на двух уровнях: что обеспечивает платформа хранения (отказоустойчивость, время замены компонентов, режим обслуживания), и что требуется всей системе целиком (включая серверы, сеть и процессы).

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

Чтобы SLA был проверяемым в эксплуатации, заранее договоритесь о метриках и порогах. Обычно имеет смысл контролировать:

• 95/99-й процентиль задержки чтения и записи;
• время работы в режиме деградации (после отказа компонента);
• фактическое время возврата к нормальной производительности;
• скорость и успешность восстановления из копий;
• время реакции и прибытия сервиса по инциденту.

Отдельно зафиксируйте, что считается плановыми работами. Входит ли обновление микрокода, замена батарей, расширение полок, тест DR. Для критичных систем на базе Hitachi VSP E-Series обычно хотят обслуживание без остановки и четкое окно работ, чтобы плановые действия не превращались в незапланированный простой.

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

Высокий SLA начинается с простого правила: любая одиночная поломка не должна останавливать сервис. Для СХД уровня Hitachi VSP E-Series это означает не только «два контроллера», а дублирование всего пути от приложения до дисков и обратно.

Что именно должно быть продублировано

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

• Контроллеры: два контроллера (active-active или с автоматическим takeover), зеркалирование кэша и защита кэша (batteries/flash) по требованиям платформы.
• Порты и внутренние пути: front-end и back-end, шины и подключение полок так, чтобы отказ одной линии не делал часть дисков недоступной.
• Питание: минимум два независимых блока питания в СХД, желательно от разных PDU/линий в стойке.
• Охлаждение: резервные вентиляторы и понятное поведение при отказе одного модуля (без перегрева и «просадки» производительности).
• Доступ к сети хранения: две независимые SAN-фабрики (Fabric A и Fabric B), отдельные коммутаторы, порты и кабели.

Даже идеальная СХД не спасет, если на хостах один путь. Multipath должен быть настроен и проверен: два HBA (или два сетевых порта для iSCSI/NVMe-oF), разные слоты/шины, разные коммутаторы. Важно не просто «включить», а убедиться, что при обрыве одного пути ввод-вывод продолжается без зависаний и ручных действий.

Как проверить, что на схеме нет SPOF

Полезный прием - устроить «мысленное выключение» каждого элемента и посмотреть, что будет с доступом к LUN/томам.

• Выключите на схеме один контроллер: остается ли доступ, не теряется ли кэш, не падает ли производительность до неприемлемого уровня.
• Уберите один SAN-коммутатор: сохраняется ли путь через вторую фабрику.
• Отключите один HBA/порт на сервере: продолжает ли приложение работать.
• Обесточьте одну PDU: не отключатся ли сразу оба БП СХД или оба блока питания сервера.
• Порвите один кабель (FC/Ethernet): есть ли физически второй, и не идет ли он тем же маршрутом.

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

Защита данных внутри СХД: не только про RAID

RAID часто воспринимают как главный ответ на вопрос надежности. Но для критичных систем этого мало: при высоком SLA важно, что происходит с данными во время отказа диска, во время восстановления массива и во время плановых работ. Это особенно заметно, когда Hitachi VSP E-Series берут под базы данных, виртуализацию и финансовые транзакции.

RAID-уровень подбирают под профиль нагрузки. Для «тяжелых» случайных записей (например, OLTP) важнее предсказуемая задержка. Для больших объемов и крупных дисков ключевой риск - долгий rebuild, когда второй отказ становится заметно вероятнее. На практике выигрывает не «самый быстрый RAID», а тот, который переживет восстановление без потери данных и без резкой деградации производительности.

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

Что проверить до закупки и в эксплуатации

Вот практичные пункты, которые часто забывают:

• Snapshots: частота и глубина хранения. Снимки должны защищать от логических ошибок, но не перегружать массив метаданными и дополнительной записью.
• Шифрование: где хранятся ключи, кто имеет доступ, как проходит восстановление после замены контроллера или аварии.
• Жизненный цикл дисков: плановая замена партиями по возрасту, чтобы не получить серию отказов из одной поставки.
• Мониторинг деградации: пороги, уведомления и действия инженера до того, как начнутся rebuild и жалобы пользователей.

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

Схемы репликации и DR: выбираем по RPO/RTO, а не по моде

Если вы рассматриваете Hitachi VSP E-Series для критичных приложений, начните не с названий технологий, а с двух цифр: RPO (сколько данных можно потерять) и RTO (как быстро система должна вернуться в работу). Все остальное - способ обеспечить эти цифры.

Локальная отказоустойчивость (внутри одной площадки) закрывает поломки контроллеров, полок, портов, путей SAN, иногда даже части сети. DR (вторая площадка) нужен, когда вы учитываете пожар, отключение питания на объекте, недоступность здания или массовую аварию в городе.

Синхронная репликация подходит, когда RPO близок к нулю. Но она требовательна к задержке и стабильности каналов: каждую запись нужно подтвердить с двух сторон, иначе приложение начнет ждать. Поэтому заранее проверьте реальную латентность, джиттер и резервирование каналов, а не только скорость по договору.

Асинхронная репликация проще по сетям, но RPO становится измеримым. Его удобно считать как максимум из: среднего объема изменений, окна передачи и времени, когда репликация останавливается из-за обслуживания или сбоев. Обязательно учитывайте пики (например, закрытие дня) и рост очереди передачи.

Выбор active-active или active-passive часто упирается в операции.

Active-passive обычно проще для приложений и поддержки: один центр работает, второй готов принять нагрузку.

Active-active дает меньше RTO, но требует дисциплины: одинаковых настроек, контроля разделения сети и понятных правил, кто главный в спорных ситуациях.

Короткий практический минимум для DR-плана:

• Зафиксировать RPO/RTO по каждому сервису, а не «в целом по системе».
• Описать триггеры переключения и кто принимает решение, чтобы избежать ложных переключений из-за сбоя приложения.
• Тестировать переключение по расписанию и после крупных изменений.
• Протоколировать результаты: время, потери данных, ручные шаги, что не сработало.
• Разделить сценарии: авария площадки, авария СХД, авария приложения, человеческая ошибка.

Пример: платежная система требует RTO 30 минут и RPO 0-5 минут. Часто получается комбинированная схема: локальная отказоустойчивость для «мелких» отказов и асинхронная репликация на вторую площадку с регулярными тестами, чтобы RPO держался в пределах пиковых нагрузок.

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

Микрокод в СХД обновляют не ради галочки. Для систем с высоким SLA это способ закрывать баги и уязвимости, но это же один из частых источников незапланированного простоя, если подойти без правил. Для критичных конфигураций на Hitachi VSP E-Series заранее опишите, когда вы обновляетесь, как проверяете совместимость и что делаете, если что-то пошло не так.

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

Перед любыми работами проверьте совместимость не только на уровне СХД, но и вокруг нее. Часто проблема не в самом микрокоде, а в связке: версии multipath на хостах, HBA-драйверы, прошивки коммутаторов SAN, параметры zoning и firmware на FC-адаптерах.

Отдельно проговорите, что обновляется по частям: контроллеры, диски, интерфейсные модули. Иногда «безопасное» обновление контроллера ломается из-за устаревшей прошивки конкретной партии дисков или модуля.

Чтобы окно обслуживания не «съело» SLA, заранее фиксируйте три вещи:

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

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

Требования к сервису: как не ошибиться в поддержке под 24/7

Поддержка 24/7 нужна не «вообще», а под конкретные риски. Для критичных приложений на базе Hitachi VSP E-Series заранее решите, какие события должны закрываться ночью и в выходные, а какие могут подождать до рабочего времени.

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

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

В договоре отдельно фиксируйте SLA на реакцию и SLA на восстановление.

Реакция - время до «инженер на связи и начал разбор».

Восстановление - время до возврата сервиса в рабочее состояние. Временное решение тоже считается, если оно снимает простой.

Проверьте, что в договоре прописано именно восстановление. Иначе можно получить быстрый ответ в чате и простой на несколько часов.

Запчасти, мониторинг, эскалация и отчетность

Перед подписанием уточните практические вещи, которые реально решают исход инцидента:

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

Простой пример: ночью «краснеет» репликация, но пользователи пока работают. Если мониторинг не 24/7, проблему увидят утром, и вы потеряете RPO. Если мониторинг есть, но нет запчастей в регионе, восстановление упрется в логистику. Поэтому требуйте не обещания, а измеримые пункты и понятный процесс.

Пошаговый выбор конфигурации под высокий SLA

Чтобы конфигурация реально держала высокий SLA, начинайте не с модели и количества дисков, а с того, как живет приложение: профиль нагрузки, пики, сколько минут простоя в год допустимо и есть ли ночные окна. Сразу фиксируйте прогноз роста на 12-36 месяцев, иначе через год SLA начнет «сыпаться» из-за банальной нехватки ресурсов.

Дальше выберите целевой SLA и переведите его в деньги. Когда у бизнеса появляется понятная цена минуты простоя, проще согласовать уровень резервирования, схему DR и сервис.

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

• собрать требования приложений: IOPS/задержка, объемы, окна работ, рост, критичность по сервисам;
• определить SLA и допустимый простой, утвердить «бюджет риска»;
• зафиксировать RPO/RTO и выбрать репликацию и DR под эти цифры;
• спроектировать отказоустойчивость end-to-end: хосты, SAN, массив, питание, площадки;
• согласовать политику обновлений микрокода, график тестов переключения и критерии приемки.

Не ограничивайтесь «СХД с резервными блоками». SLA чаще падает на стыках: один SAN-коммутатор без пары, одинаковые трассы кабелей, два контроллера или два блока питания в одном стойковом PDU, неучтенный лимит портов или очередей на хосте.

Простой пример: платежная система требует RPO близкое к нулю и RTO до 15 минут. Это почти всегда означает синхронную репликацию в пределах достижимой задержки между площадками, плюс заранее отработанный сценарий переключения приложений и сети. Если площадки далеко, синхронность может стать недостижимой. Тогда честнее выбрать асинхронную репликацию с приемлемым RPO и компенсировать это процессами.

Отдельно закрепите, как вы будете жить с обновлениями и авариями. В договоренностях должны быть не общие слова, а проверяемые параметры:

• окна и частота обновлений микрокода, порядок отката при проблеме;
• регулярность DR-тестов и что считается успешным переключением;
• время реакции и время восстановления (не путать);
• наличие запчастей и инженеров 24/7, маршрутизация эскалаций;
• что и как измеряется при приемке: задержка, пропускная способность, работа при отказе узла.

Если вы привлекаете интегратора, попросите один документ с матрицей «требование -> техническое решение -> тест». Он быстро показывает, закрыт ли SLA на деле, а не на бумаге.

Частые ошибки при выборе СХД под высокий SLA

Даже дорогая СХД не спасает от простоя, если требования и архитектура собраны «по ощущениям». Ниже ошибки, которые чаще всего встречаются при выборе Hitachi VSP E-Series для критичных приложений и в целом при выборе СХД под высокий SLA.

Ошибки в архитектуре и расчетах

Первый тип проблем - когда резервирование есть на бумаге, но не в реальном пути данных. Покупают систему с двумя контроллерами, а затем оставляют один SAN-коммутатор, один HBA в сервере или один путь в настройках multipath. В результате отказ не контроллера, а «мелочи» сверху останавливает весь сервис.

Вторая типовая ошибка - не закрепить RPO и RTO в понятных цифрах. Фраза «должно работать всегда» приводит к спору в момент инцидента: для одних допустимы минуты, для других - только синхронная репликация и быстрый автоматический фейловер.

Третья - считать производительность по тестовой среде. Когда тестовые и боевые нагрузки смешаны, либо тесты не повторяют профиль IOPS/задержек, появляются неверные ожидания по отклику приложений и скорости восстановления.

Ошибки в эксплуатации и поддержке

Высокий SLA - это еще и дисциплина изменений. Если нет политики по микрокоду, окон обслуживания и критериев отката, обновление превращается в вынужденный эксперимент и риск незапланированного простоя.

Также недооценивают DR-процедуры. Репликация может быть настроена, но без регулярных тестов восстановления (и проверки прав доступа, сетей, DNS, порядка запуска) реальная авария вскрывает проблемы слишком поздно.

Экономия на сервисе почти всегда обходится дороже. В 24/7 среде критичны заранее согласованные уровни поддержки и ответственность за выезд и запчасти, иначе часы уходят на ожидание и согласования.

Короткий пример: у финансовой системы ночной расчет длится 2 часа. Если RTO не зафиксирован, при сбое можно «восстановиться к утру», но бизнес потеряет окно обработки. Если RTO закреплен как 15 минут, требования к репликации, запасу производительности и поддержке становятся конкретными и проверяемыми.

Пример сценария: финансовая система и требование 99,99%

Представим платежную систему банка, которая работает 24/7 и имеет SLA 99,99%. Это около 52 минут простоя в год, включая плановые работы. Есть два ЦОДа: основной и резервный. Цель простая: отказ отдельного узла, SAN-коммутатора или целой площадки не должен превращаться в долгий инцидент.

Для хранилища уровня Hitachi VSP E-Series обычно фиксируют RPO и RTO в цифрах еще до выбора схемы. Например: RPO 0 для большинства транзакций и RTO 15 минут при потере основного ЦОДа.

Репликация: синхронная или асинхронная

Если между ЦОДами небольшая задержка и канал стабилен, выбирают синхронную репликацию, чтобы получить RPO 0. Если расстояние большое или канал не гарантирует низкую задержку, берут асинхронную схему и честно принимают RPO, например 30-120 секунд, но выигрывают в устойчивости к проблемам связи.

Перед финальным решением проверьте:

• реальную задержку и джиттер на канале в часы пик;
• доступную полосу и ее резервирование;
• сценарий split-brain и правило, кто становится активным.

Минимум по резервированию и тестам

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

• два независимых SAN fabric и multipath на хостах;
• кластер приложений и баз данных с понятным кворумом;
• резервирование питания и сетей управления;
• отдельный план на отказ зоны, коммутатора и контроллера.

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

Для приемки и аудита заранее готовят комплект: схему архитектуры, матрицу RPO/RTO по сервисам, runbook переключения, протоколы тестов, журнал изменений (включая микрокод) и контакты поддержки 24/7 с целевыми временем реакции и эскалации.

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

Перед покупкой СХД под высокий SLA полезно сделать финальную проверку не только самой полки, но и всего окружения. Даже сильная платформа хранения не спасет, если простой случится из-за незамеченного SPOF или неоттестированного DR.

Быстрая проверка перед подписанием спецификации

Пройдитесь по пунктам и фиксируйте ответы письменно: что сделано, кто отвечает, как проверяется.

• SPOF: два независимых питания и цепочки электроснабжения, два SAN-коммутатора, две HBA на хост, разнесенные порты на СХД, multipath настроен и проверен. Отдельно проверьте DNS, учетные записи, права и доступ к консоли.
• DR и репликация: есть расписание тестов (не реже, чем принято у вас), понятные сценарии (авария площадки, потеря массива, логическая ошибка), назначены ответственные и замерено реальное время переключения.
• Микрокод: утвержден регламент обновлений, согласованы окна, проверена совместимость с ОС, HBA, SAN-микрокодом. Есть план отката и критерии, когда откатываемся.
• Сервис 24/7: прописаны времена реакции и восстановления, где физически лежат запчасти, кто и как эскалирует проблему, какие отчеты вы получаете после инцидента.
• Приемка: заранее определены тесты на отказ (pull-the-plug), критерии успешности и кто подписывает результаты.

После такой проверки обычно становится видно, чего не хватает в архитектуре или процессах.

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

Минимальный набор данных для обследования: список приложений и их RPO/RTO, текущие IOPS/задержки, карта SAN, версии ОС и драйверов, график изменений и окна работ.