3PAR 8000 и 9000 после вендорскойподдержки

—

от автора

3PAR 8000/9000 после вендорской поддержки: как посчитать запас жизни СХД

В первой статье блога мы рассказали, кто мы, и разобрали приёмку сервера по журналам BMC. Эта статья про массивы HPE 3PAR, с которыми у нас тот же подход, что и с серверами: покупаем рабочие, проверяем, инициализируем и прогоняем тестами под конкретного клиента, продаём с гарантией и закрываем её собственным складом запчастей. Услуг обслуживания и восстановления чужих инсталляций мы не оказываем.

Текст для владельцев 3PAR, у которых закончилась вендорская поддержка: как по паспорту массива и телеметрии дисков оценить, сколько он ещё проживёт, что должно лежать на полке с запчастями и что в этих массивах ломается в жизни. Практика собрана на десятках машин, прошедших через наш склад, в том числе история, где три «мёртвых» диска ожили от одной команды.

Начнём с дат. 31 августа 2026 года по опубликованному графику HPE закончилась поддержка всей серии 3PAR 8000, моделей 8200, 8400, 8440 и 8450 разом. Серия 9000 продержится ненамного дольше: у 9450 в календаре стоит 1 мая 2027-го. Одна из самых массовых enterprise-СХД российских ЦОДов 2015–2022 годов официально вышла из жизненного цикла вендора.

Для российских владельцев в этих датах меньше драмы, чем кажется. HPE ушла из России ещё в 2022-м: контрактной поддержки, доступа к порталу с прошивками и вендорских замен у большинства местных инсталляций нет уже четвёртый год. EOSL сделал официальным для всего мира то, что здесь давно повседневность: массив живёт ровно настолько, насколько выстроена его собственная система жизнеобеспечения.

Сами массивы при этом никуда не деваются. Они стоят в стойках, держат продакшн и будут держать его ещё годами: инсталляций в стране тысячи, и мало кто побежит менять рабочую СХД из-за даты в чужом календаре, тем более по ценам 2026 года на новое железо.

Что означает конец поддержки

В словах «End of Support Life» пугает неопределённость, поэтому разложим их на три списка: что вы теряете, что остаётся и чего не будет ни при каком сценарии.

Что вы теряете. Новые версии и патчи 3PAR OS: всё, что вышло, уже вышло. Вендорскую замену запчастей по контракту. Телеметрию и предиктивную аналитику InfoSight в том виде, в каком она привязана к активному контракту. Формальную строчку «поддерживается производителем» для аудиторов и страховщиков.

Российских инсталляций половина этого списка не касается с 2022 года: контрактные замены и портал поддержки закончились вместе с уходом вендора из страны. Для них EOSL меняет формулировку, «поддержки нет временно» превращается в «поддержки нет навсегда». Про прошивки отдельно: последние выпущенные версии 3PAR OS и патчи физически существуют, вопрос только в источнике. Покупая массив на вторичном рынке, требуйте от поставщика обновления до последних доступных версий как части предпродажной подготовки. Мы делаем именно так, и это нормальный отраслевой стандарт.

Что остаётся. Сам массив со всей функциональностью: лицензии 3PAR бессрочные и живут на самой системе (на серии 9450 вообще всё включено в базовую поставку). Документация и база знаний, накопленная за десятилетие эксплуатации: по этим машинам написано и наговорено больше, чем по многим живым линейкам. Рынок запчастей, о котором ниже. И независимый сервис: инженеров, глубоко знающих 3PAR, в стране много, именно потому что парк огромен.

Чего не остаётся ни при каком сценарии. Патчей безопасности. Если массив смотрит управляющими интерфейсами в сегмент, куда есть доступ извне, EOSL становится аргументом за изоляцию управляющей сети (что стоило сделать и до EOSL), а для части регулируемых отраслей формальным поводом для миграции, который не обойти инженерными доводами.

Дальше про то, как принять это решение на цифрах.

Паспорт массива: с чего начинается расчёт запаса жизни

Первый шаг скучный: собрать фактическое состояние. Удивительно, у скольких массивов, отработавших 6–8 лет, этой информации нет нигде, кроме самой системы.

Минимальный паспорт складывается из вывода нескольких команд CLI:

showsys            # модель, серийник, System ID
showversion -a -b  # версия 3PAR OS и патчи
shownode -d        # состояние нод, кэша, батарей
showcage -d        # полки и их прошивки
showpd -i          # каждый диск: модель, прошивка, WWN
showpd -s          # состояние дисков
showlicense        # что лицензировано
checkhealth -svc -detail   # полная самодиагностика

Из этого паспорта сразу видно три вещи, определяющие запас жизни: насколько свежая у вас 3PAR OS (последние выпуски веток 3.3.1/3.3.2 стабильны и известны наизусть всему рынку), в каком состоянии расходники, батареи кэша и диски, и какие лицензии уже есть (докупить их после EOSL не выйдет, что есть, с тем и жить).

Телеметрия дисков: где живёт риск

Контроллеры 3PAR отказывают редко, это дублированные вычислительные узлы без механики. Батареи и блоки питания расходники с понятной заменой. Главный статистический риск массива на седьмом году жизни это диски. У дисков есть особенность, которую мы вынесли из собственного парка, и на ней стоит остановиться.

Диски одной партии стареют синхронно. Массив обычно комплектуется дисками с одной фабрики, из одной партии, и живут они в одинаковых условиях под одинаковой нагрузкой. Когда у одного диска партии начинает расти счётчик grown defects (дефекты, накопленные сверх заводской карты), его соседи с высокой вероятностью идут следом с отставанием в месяцы. Мы наблюдали это вживую: в связке SAS-дисков одного возраста с наработкой около 43 тысяч часов у первого диска счётчик дорос до 129 дефектов, у второго до 23 с парой нескорректированных ошибок, остальные пока молчали. Так выглядит партия, вышедшая на участок деградации; списывать это на один неудачный диск не получится.

Для 3PAR это означает: смотреть телеметрию нужно по каждому диску, а не по среднему, и группировать по партиям. Массив, у которого 40 дисков одной партии на седьмом году, и массив с дисками трёх возрастов это два разных профиля риска при одинаковом выводе checkhealth.

Раз в квартал снимайте showpd -e (счётчики ошибок по каждому диску) и ведите динамику. Рост grown defects на нескольких дисках одной партии означает, что спарки этой ёмкости пора закупать уже сейчас, пока они дёшевы и доступны.

Матрица запчастей: что должно лежать на полке

Экономика жизни после EOSL стоит на том, что запчасти к 3PAR доступны и дёшевы, следствие огромного установленного парка. Диски в фирменных салазках, контроллерные ноды, модули кэша, блоки питания, полки DCS8/DCN2, SFP: всё это есть на рынке в количестве.

Прежде чем считать запас, полезно знать, что вообще ломается. Наша гарантийная статистика по проданным 3PAR за годы выглядит скучно: почти всё, что менялось, это диски. Блоки питания редко. Контроллерные ноды единичные случаи за всё время. Оптические SFP-модули мы не меняем практически никогда. Массив спроектирован с дублированием всего, что дублируется, и его слабое место механика и flash-носители, то есть диски.

Отсюда разумный запас для массива в продакшне:

Компонент

Частота замен (наша гарантийная статистика)

Сколько держать

Диски используемых ёмкостей/типов

основная статья замен, почти всё, что вообще меняется

2–3 на каждые ~20 в массиве; докупка при росте дефектов партии

Батарейный модуль ноды

меняется по календарному сроку, а не по отказу

1–2

Блок питания ноды/полки

редко

по одному на тип

Контроллерная нода

единичные случаи за годы

отдельно можно не покупать, закрывается донорским массивом

SFP-модули

практически никогда

пара про запас, стоят недорого

Отдельная стратегия, которой мы закрываем собственный гарантийный ЗИП, это донорский массив. Второй такой же 3PAR, купленный на вторичном рынке по цене металлолома с точки зрения нового железа, закрывает все позиции матрицы разом, включая ноды. Для компании с одним боевым массивом это часто дешевле, чем собирать полку запчастей по позициям.

Три истории из практики: что ломается и как это выглядит

История первая: три «мёртвых» диска, ожившие от одной команды

Принимали массив 8450 после чужой эксплуатации. После инициализации система показывает три диска в состоянии, которое выглядит как приговор:

— 0:9:0   unknown  0 RPM  failed   0 MiB  0 GB   vacated, prolonged_not_ready
— 0:10:0  unknown  0 RPM  failed   0 MiB  0 GB   vacated, prolonged_not_ready
— 0:14:0  unknown  0 RPM  failed   0 MiB  0 GB   vacated, prolonged_not_ready

Модель не читается, ёмкость нулевая, обороты нулевые, статус failed, рядом алерты Severity: Major с рекомендацией «Replace Drive». Стандартная реакция: списать три диска и заказать замену.

В списке задач системы при этом висела упавшая задача:

Id 1-3  sstart_pd_-2  failed
   Error  Expecting a non-negative integer, got: -2

sstart_pd это штатная задача раскрутки диска (spin start). Система пыталась раскрутить диски сама, но подставила в задачу псевдоидентификатор −2 (его получают диски, ещё не заведённые в конфигурацию), собственный валидатор отбил отрицательное число, задача умерла, и диски просто остались нераскрученными. Дальше статусы выстроились цепочкой: не раскрутился, prolonged not ready, failed.

Диски всё это время были исправны, сломался только автоматический spin-up.

Лечение: одна команда на диск, адресация по WWN в обход багнутого идентификатора:

controlpd spinup <WWN диска>

Через тридцать секунд все три диска определились: тип FC, 10K, честные 900 ГБ. После заведения в систему состояние normal, плюс 2,4 ТиБ ёмкости. Ремонт не стоил ничего и занял по минуте на диск.

С тех пор до любого списания мы проверяем одно правило: комбинация failed + vacated + prolonged_not_ready + unknown/0GB это подпись нераскрученного диска, а не мёртвого. Сначала showtask на предмет упавшего sstart_pd, потом controlpd spinup, и только потом заказ замены. Оговорка для массивов с данными: вендорская документация предупреждает не запускать процедуры обслуживания на failed-диске до завершения реконструкции. Дождитесь её, потом экспериментируйте.

История вторая: диски, которые исправны, но заперты навсегда (почти)

Пополняли дисковую ёмкость с вторичного рынка: партия enterprise SAS SSD от чужого списанного массива. Диски физически идеальны, а 3PAR их не принимает: SedState: owned_by_other_system, любая запись даёт Data protect / Access denied.

Это самошифрующиеся диски (SED): прошлый владелец списал массив, не выполнив штатную деинициализацию, и криптозамок каждого диска остался привязан к его системе. Официальная позиция вендора для такого случая: «верните поставщику». Из CLI массива это не лечится вообще, by design, это защита от кражи данных.

Лечится снаружи массива. У каждого SED на наклейке напечатан PSID, заводской 32-символьный код сброса. Диск подключается к обычному SAS HBA в IT-режиме, и командой PSIDrevertAdminSP замок снимается, данные при этом уничтожаются криптографически. Сложность одна: код набран мелко, и в нём полно пар-близнецов вроде 8/B, I/1, 5/S, 0/D. Ошиблись символом, получили отказ, а лимит неверных попыток у диска конечный, после него замок закрывается навсегда. Через эту процедуру у нас прошло больше пятидесяти дисков, ни один не заблокировался, но каждую наклейку снимали крупным планом и сверяли код посимвольно до отправки команды.

Ещё одна грабля из той же истории, уже наша собственная: форматирование диска в родной для 3PAR 520-байтовый сектор нельзя прерывать. Один раз SSH-сессия с удалённым sg_format оборвалась на середине, диск остался в состоянии Medium format corrupted и не принимался массивом, пока формат не прогнали заново локально, от начала до конца. Формат только на локальной машине или в screen/tmux, никаких «запущу по ссылке через два прыжка».

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

История третья: батарея ноды как таймер

В нодах 3PAR стоят батарейные модули с одной задачей: при пропадании питания дать ноде время сбросить кэш записи на энергонезависимый носитель. У батарей есть паспортный срок службы, и массив его честно отсчитывает. Когда срок вышел или батарея перестала держать заряд, система больше не доверяет кэшу и переводит запись в сквозной режим, мимо кэша. Снаружи это выглядит как «массив вдруг стал тормозить», и на возрастных 3PAR это самая частая причина такой жалобы. Состояние и сроки показывает showbattery, замена горячая. На живом контракте батарею привозили по алерту; после EOSL это ваша собственная позиция в матрице запчастей.

Сколько это стоит: рамка для расчёта на три года

Сведём в методику. Запас жизни массива после EOSL считается по четырём строкам:

1.      Паспорт: модель, версия OS, лицензии, состояние нод и батарей. Час работы, ноль рублей.

2.      Телеметрия дисков: динамика ошибок по партиям за 2–3 квартала. Отсюда прогноз замен на горизонт.

3.      Матрица запчастей: полка спарков или донорский массив. Для типового 8400 с полусотней дисков полный комплект спарков вместе с донором стоит несопоставимо меньше новой СХД той же ёмкости.

4.      Репетиция миграции: даже если вы остаётесь на 3PAR, план и проверенная процедура переезда данных должны существовать, хотя бы потому, что решение «остаёмся» принимается спокойно только тогда, когда есть проверенный путь «уходим». Единая архитектура 3PAR тут играет за вас: данные между моделями линейки мигрируют штатными средствами без остановки, с 8200 на 8400 или 9450 можно переехать, не гася продакшн.

Если по итогам расчёта массив здоров, диски не в зоне партийной деградации, спарки на полке и нагрузка не требует фич нового поколения, эксплуатация ещё 3–5 лет после EOSL инженерно обоснована. Если же диски посыпались партией, лицензий не хватает и бизнес требует NVMe-скоростей, расчёт покажет, что деньги на поддержание жизни лучше вложить в миграцию.

Когда после EOSL оставаться не стоит

Ситуации, в которых мы сами отговариваем заказчиков от продления жизни:

· регуляторные или страховые требования активной вендорской поддержки: их инженерией не обойти;

· управляющие интерфейсы массива невозможно изолировать от недоверенных сетей: без патчей безопасности это растущий риск;

· нагрузка упёрлась в архитектурные потолки платформы: нужны NVMe-native задержки или ёмкости за пределами линейки;

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

Что считать вместо даты

Дата в календаре вендора это событие в бухгалтерии вендора. В стойке события другие: счётчики ошибок дисков, срок батарей, наличие спарков на полке и проверенный план миграции. Пока эти четыре параметра под контролем, 3PAR 8000/9000 остаётся тем, чем был последние десять лет: надёжной рабочей машиной с низкой ценой владения. Как только контроль потерян, действующая поддержка вас бы всё равно не спасла.

Команды для паспорта выше, методика тоже. А если по дороге встретите три «мёртвых» диска, вы знаете, с какой команды начать.

ссылка на оригинал статьи https://habr.com/ru/articles/1103236/