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 остаётся тем, чем был последние десять лет: надёжной рабочей машиной с низкой ценой владения. Как только контроль потерян, действующая поддержка вас бы всё равно не спасла.

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

Комментарии (4)


  1. Fytyreryadom
    03.11.2026 16:52

    По grown defects. «Рост на нескольких дисках партии» понятно, а цифры какие? 129 у вас в примере уже деградация, а 10 за год это норма или сигнал? Хочется порог, чтобы забить в мониторинг.


    1. Kolomnin Автор
      03.11.2026 16:52

      Порога в абсолютных цифрах у нас нет, и в мониторинг мы забиваем не число, а прирост. Диск с десятью дефектами, которые стоят на месте год, нас не беспокоит. Диск, у которого за квартал прибавилось столько же, сколько за предыдущие три, попадает в список на наблюдение. Второй такой диск из той же партии означает, что спарки этой ёмкости покупаются сейчас. Нескорректированные ошибки в showpd -e весят больше любого количества grown defects: это данные, которые диск уже не смог отдать, после них диск меняем без обсуждения. Сам 3PAR тоже выводит диск в degraded по своим счётчикам, и этому сигналу стоит верить, но он приходит позже, чем динамика по партии.


  1. Lev3250
    03.11.2026 16:52

    Ещё hpe любят сыпать в мониторинг "ошибками" по нераскрученному hot spare диску, меняя весь статус контроллера на alert.


  1. WhiteSorcerer
    03.11.2026 16:52

    По SED. Как до покупки понять, что партия заперта под чужой системой? Продавец показывает SMART, там всё чисто, а что диск заперт, видно только когда он уже в массиве. И что делать, если наклейка с PSID затёрта или оторвана?