Привет, Хабр! Меня зовут Иван Звонилкин, я эксперт направления сервисной поддержки вычислительной инфраструктуры в компании K2Tех. Сегодня хочу рассказать, как в новых реалиях мы сохранили высокий уровень обслуживания систем хранения данных после ухода западных вендоров с российского рынка.
Энтерпрайзные СХД — пожалуй, самый сложный в обслуживании элемент ИТ-инфраструктуры. В отличие от серверов с их относительной открытостью, системы хранения — черные ящики с закрытым проприетарным ПО. И если раньше в критических ситуациях мы могли рассчитывать на поддержку вендоров, то в 2022 году оказались предоставлены сами себе.
Мы всегда стараемся искать и тестировать новые подходы к обслуживанию, чтобы работать на опережение и предотвращать проблемы до того, как они произойдут. Конечно, мы живем в реальном мире, и тоже сталкиваемся с черными кошками, «перебегающими дорогу и ломающими обрудование» в серверной. Но это не пугает команду, а наоборот стимулирует нестандартно мыслить для решения задачи.
В этот раз я расскажу о создании парка подменных СХД, которые позволяют безопасно обслуживать и ремонтировать критичные системы без риска потери данных заказчика. Поделюсь реальными кейсами, сложностями, с которыми столкнулись, и выводами, которые будут интересны всем, кто занимается эксплуатацией корпоративных СХД в текущих условиях.
Скрытый текст
Спойлер для самых нетерпеливых: да, при должной подготовке и правильном подходе можно обеспечить высокий уровень сервиса даже без поддержки вендора. И это не обязательно должно быть дорого.
Раньше за СХД отвечали вендоры — особенно во время ремонта. У них были четкие регламенты, сроки поставки запчастей и доступ к экспертам высшего уровня. Вендоры выступали непререкаемым авторитетом для заказчиков, а их планы по устранению проблем воспринимались как истина в последней инстанции. Если заказчик не мог сразу выполнить рекомендации, он всё равно подстраивался под вендора. Кто же станет спорить с производителем?
В те времена мы чувствовали поддержку «большого брата», который должен был помочь в сложной ситуации. Обычно работа по инструкциям производителей была удобной и эффективной. Впрочем, это не значит, что вендор был всегда прав. Вспоминается инцидент у одного заказчика после обновления большой распределенной СХД по вендорскому экшн-плану.
После того как половина узлов загрузилась с новой ОС, случился редкий баг — кластер просто не понял, перешла на них нагрузка или нет. Из-за этого автоматический откат прошивки пошёл наперекосяк, и система, чтобы не потерять данные, решила перезагрузить вообще все узлы и вернуться к старой версии.
СХД была недоступна всего шесть минут, но последствия ощущались еще долго — некоторые сервисы поднимались аж до 6 часов. Были остановлены склады, сервисы и работа персонала, что вело к упущенной прибыли, убыткам и другим потерям. Заказчик пригрозил штрафными санкциями, но размытые формулировки в соглашениях с вендором не позволяли рассчитывать на победу в суде.
Свобода маневра
Раньше мы не брали на полное обслуживание сложные системы хранения данных. Предполагалось, что наша команда обеспечивает базовую и среднюю поддержку (L1 и L2), а кейсы выше решает вендор. Даже обучение специалистов не предусматривало передачу знаний уровня L3. А теперь и L3-поддержка стала нашей, только практически без возможности получить консультацию производителя.
После ухода производителей с российского рынка заказчики стали требовать гарантий бесперебойной работы вендорского оборудования. Однако ни один самый гениальный инженер в сложившейся ситуации этого не гарантировал:что-либо всегда может пойти не так. И чем опытнее инженер, тем лучше он понимает, сколько незапланированных ситуаций может приключиться.
Некоторые крупные заказчики со значительными ресурсами минимизировали риски покупкой дополнительного оборудования. Перед началом работ они переносят данные на резервную СХД, и с основной можно спокойно работать. Вот только дублировать подобное оборудование — очень дорого.
Для большинства заказчиков из малого и среднего бизнеса работы приходится проводить прямо на продуктивной системе со всеми вытекающими рисками. Как защититься от возможных негативных последствий? По нашему опыту могу сказать, что тут два пути: выдерживать давление и постоянно быть в ожидании худшего или взять ситуацию в свои руки.
Жесткий стресс и вот — новый подход
Был у нас «переломный» кейс, показавший, что работать вдолгую без нормального резерва попросту невозможно.
Это был заказчик с небольшой вроде бы системой: всего 9 дисков, но это были NVMe диски емкостью 19 терабайт каждый. В моменте у нас в резерве было всего два или три таких накопителя. Однако в тот раз начался какой-то дисковый апокалипсис: SSD сыпались один за другим.
Мы заменили три за неделю — и резерв был исчерпан. Обычно больше и не резервируют, ведь есть средний процент поломок, и на этом строится вся логистика в нашей работе. Новые диски ждать долго, нужно чинить, а места для переноса такого количества данных у заказчика нет и... по SLA у нас намечается полная катастрофа. В срочном порядке начали поиск необходимых дисков по всем доступным каналам. С горем пополам проблему тогда решили, диски нашли и даже статью написали.
В принципе можно было бы арендовать систему хранения данных того же класса у партнеров, но на практике это не вариант. Никто не предоставит нам систему за миллионы рублей по первому звонку без документальной подстраховки. А это сплошная бюрократия: согласование стоимости и сроков, подписание договора. Оформление документов может затянуться на неделю, хотя нашим клиентам часто нужно решить проблему за сутки. А ещё надо учитывать время на перенос данных на временное хранилище.
В общем, после этого случая мы ясно поняли, что без собственного резерва СХД просто не обойтись. Если у К2Тех будет свой стратегический запас, то мы сможем давать заказчикам страховку в виде подменной СХД, снимая их опасения. А сами будем спокойно обслуживать их оборудование без рисков и нервов.
Подменный фонд
Итак, решено: делаем парк подменных СХД. Обсудили проект с инженерами и руководителями команд, и решили собирать два типа систем:
«Быстрые» СХД — набитые NVMe SSD с быстрыми контроллерами, но с относительно небольшой емкостью, например, 100 ТБ полезного объема. Это хороший вариант для высоконагруженных систем и баз данных.
«Емкие» СХД — большой полезный объем, 200–300 ТБ, но на шпиндельных дисках. Идеальны для холодных данных, бэкапов и других задач, где скорость не критична.
Чтобы обеспечить замену, нужно было минимум по две СХД каждого типа. Сейчас, опираясь на накопленный опыт, видим, что такого количества вполне достаточно. Большинство кейсов длится не больше пары недель, поэтому наложений пока не было. Хотя пересечения в использовании СХД одного типа на пару дней случались: одну только собирались вернуть, а вторую уже нужно было забирать.
Мы продолжаем собирать статистику и при необходимости скорректируем количество систем. Скорее всего, потребуется увеличить парк СХД с SSD, так как они оказались наиболее востребованными.
При выборе характеристик систем ориентировались на наиболее распространенные конфигурации, поскольку учесть все возможные пограничные варианты невозможно.
Быстрая СХД. Вариант 1: В каждом из двух контроллеров стоит 8-ядерный процессор Intel Skylake 2.3 ГГц, 128 ГБ кэша, интерфейсы 2×10 Гб Ethernet (iSCSI) + 4×32 Гб Fibre Channel для связи с хостами. Диски — 19.2 ТБ NVMe QLC (проприетарные FlashCore от IBM со сжатием до 2:1 на лету на уровне диска). Полезное пространство — 155 ТБ (без учёта сжатия). Всё это в компактном корпусе формата 1U.
Быстрая СХД. Вариант 2: В каждом из двух контроллеров установлены два 8-ядерных процессора Intel Skylake 1.7 ГГц, 128 ГБ кэша, интерфейсы 4×10 Гб Ethernet (iSCSI) + 8×16 Гб Fibre Channel для связи с хостами. Диски — 4.8 ТБ NVMe TLC (проприетарные FlashCore от IBM со сжатием до 2:1 на лету). Полезное пространство — 80 ТБ (без учёта сжатия). Корпус формата 2U.
Емкая СХД. Вариант 1: В каждом из двух контроллеров используется 32-ядерный ARM процессор Kunpeng 920 2.6 ГГц, 128 ГБ кэша, интерфейсы 4×1 Гб Ethernet (iSCSI) + 4×10/25 Гб Ethernet (iSCSI) + 4×32 Гб Fibre Channel для связи с хостами. Установлены диски NL-SAS для данных и отдельно 4 SAS SSD для кэширования. Полезное пространство — 200 ТБ. Корпус состоит из двух полок 2U+4U.
Емкая СХД. Вариант 2: В каждом из двух контроллеров стоит процессор Intel Xeon (вендор не раскрывает конкретную модель), 16 ГБ кэша, интерфейсы 4×32 Гб Fibre Channel для связи с хостами. Используются диски NL-SAS. Полезное пространство — 150 ТБ. Корпус формата 2U.
Наши инженеры не хотели, чтобы железо простаивало. Поэтому мы приняли решение в периоды, когда системы не задействованы у заказчиков, использовать их для обучения персонала. Для этого приобрели оборудование тех производителей, с которым даже новички могут быстро разобраться без особых проблем.
Дальше предстояло сделать процесс предоставления подменной СХД максимально комфортным: просто заявка от заказчика и обсуждение проблемы, согласование конфигурации — и поехали.
Признаюсь, мы немного схитрили: пока юристы готовили внутренние инструкции и регламенты, мы уже начали выдавать подменные СХД инженерам без лишней бюрократии внутри К2Тех. Да, теоретически это повышало риски в случае порчи или невозврата оборудования, но наши заказчики — не случайные люди, а серьезные компании. Мы сделали выбор в пользу их удобства, а потом уже дополнительно проработали с юристами процедуры и придумали, как проще зафиксировать новую практику в документах.
Подмена СХД на практике
ЦОДы большинства наших крупных клиентов расположены в Москве и Московской области. Для обслуживания этих объектов мы используем собственную службу доставки с выделенными автомобилями для срочных заказов. Одна машина всегда наготове, поэтому через 1–3 часа после принятия решения об отправке подменную СХД уже выгружают на площадке клиента.
Если речь идет о компактной 1U и 2U флеш-системе без движущихся элементов, можно обойтись минимальной упаковкой. Наши водители обучены правильному обращению с оборудованием и знают особенности его транспортировки. В города с авиасообщением запчасти отправляются экспресс-доставкой. Тут уже нужна правильная и надежная упаковка, за которую отвечает наш склад и логистика.
На объектах перенос данных обычно выполняют системные администраторы заказчика, а наши инженеры оказывают консультационную поддержку.
При переносе данных они вместе анализируют, как настроены LUN, пулы, RAID-группы и стараются воспроизвести это на подменной СХД. Зачастую на СХД объемом 200 ТБ полезных данных примерно 110 ТБ, а остальное пространство занимают тестовые и девопс-окружения, которые можно не переносить. Это позволяет существенно ускорить процесс миграции критически важных данных.
Подключение временной системы хранения к инфраструктуре заказчика происходит по стандартной процедуре: оборудование интегрируется в сеть хранения данных и подключается ко всем фабрикам по протоколу Fibre Channel.
Перенос данных проводится при помощи снапшотов или репликации, в зависимости от используемой системы виртуализации – VMware, OpenStack или других платформ. Заказчики обычно хорошо представляют особенности своих данных, а наши инженеры постоянно отрабатывают миграцию в лаборатории, так что, как правило, все проходит гладко с первой попытки.
После окончания обслуживания основной СХД заказчик уничтожает данные на подменной системе. Иногда мы подсказываем клиентам подходящий метод. По ГОСТУ для этого можно использовать специальный софт, он по нескольку раз перезаписывает диски особыми паттернами. Или просто «прибить» все LUNы на СХД и вытащить диски в случайном порядке — собрать данные после этого уже нереально.
Однако у большинства крупных компаний есть свои службы ИБ, которые решают этот вопрос самостоятельно. Вспоминается случай, произошедший еще до эпохи дорогостоящих СХД. Тогда мы предоставили заказчику подмену на дешевых SATA дисках. Привезли 10 штук, а увезти не смогли, оказалось — носители информации нельзя выносить с площадки клиента. Требование ИБ. В итоге диски у нас выкупили по остаточной стоимости. Теперь всегда уточняем этот момент, чтобы ненароком не оставить клиенту целую СХД.
Какое еще подменное оборудование мы предоставляем
Хотя в основном это подменные СХД, мы можем выручить и с другими типами оборудования. Серверы x86 обычно не спрашивают, их у большинства заказчиков и так достаточно. Да и с коммутаторами обычно проще решить вопрос ремонтом или полной заменой. Но бывали интересные случаи, когда нам приходилось выходить за рамки обычного подхода.
В середине 2022 года у одного крупного, входящего в топ-50, банка, возникла критическая ситуация с серверами Oracle на архитектуре SPARC. На кластере из двух таких машин крутился весь процессинг, и внезапно на одном из серверов вышла из строя плата. Контракт с вендором, как назло, перестал действовать в тот момент. Банк остался с единственным работающим сервером — это реальный риск для всего бизнеса.
Мы сами раньше не поддерживали такие сервера и нужной платы у нас не было. Пытались закупить, но поскольку они поставлялись в основном из США, а новые логистические схемы еще не наладились, заказы отменялись или бесконечно задерживались. Решение пришлось искать нестандартное: взяли лабораторный сервер совершенно другой модели, но на том же поколении процессоров. «Добили» его памятью и дисками из того, что было в наличии, и согласовали такое временное решение с заказчиком. Инженеры настроили всё ПО, и банк спокойно работал на нашем сервере пару месяцев, пока нужная плата наконец не доехала.
В другой раз выдали заказчику подменную СХД, но выяснилось, что у него не осталось свободных портов в SAN-сети для подключения. Пришлось отправлять целый комплект из трёх устройств: СХД и пару SAN-коммутаторов для организации независимых фабрик согласно лучшим практикам.
Кстати, о коммутаторах — иногда предоставляем на подмену SAN-коммутаторы Brocade. Это бывает нужно, когда на оборудовании заказчика требуется провести рисковую операцию с ПО, и клиент хочет перестраховаться, временно перенеся нагрузку на наше оборудование. А наши коллеги из направления сервиса и аутсорсинга телекоммуникационных решений аналогично выручают с подменными LAN-коммутаторами в похожих сценариях.
Когда подменная СХД дает бонус к уверенности
Поделюсь случаем из практики. Однажды мы столкнулись с проблемой, которую не могли решить никакими заменами запчастей. Все компоненты казались исправными, но производительность серьезно страдала: наблюдались просадки, выросла latency. Мы перепробовали все возможные методы и обновили прошивки до последних версий — ничего не помогало. Примерно как с Windows, когда всё тормозит без видимой причины.
В итоге решили пойти ва-банк и переустановить операционную систему СХД. Но тут уже не получилось бы просто сохранить текущую конфигурацию и переустановить систему с нуля, поскольку RAID-группы, пулы и прочие настройки жестко привязаны к конкретной СХД. Заказчик согласился на это только при условии, что мы сможем перенести все его сотни терабайт данных, протестировать и вернуть обратно. А закрыть заявку без переустановки мы не могли.
Кстати, вендор в такой ситуации, скорее всего, не стал бы выходить за рамки классического обслуживания железа и софта. У него есть план действий, который нужно выполнить. Если вы не можете перенести данные — делайте резервную копию на ленточную библиотеку. Мы же предложили обходной путь и сохранили данные заказчика.
В другой раз региональный заказчик при апгрейде самостоятельно подключал полки расширения к СХД и нарушил гайд по кабельному соединению. Там была сложная схема SAS-петель, и из-за ошибки часть дисков определялась некорректно. Проблема усугублялась тем, что каблирование никак не отображалось в логах — это чисто физическая структура, причем удаленная.
Поскольку это была рабочая продуктивная СХД с несколькими новыми полками, существовал риск потери доступа к данным во время замены контроллеров или SAS-кабелей. Заказчик категорически не соглашался на такой риск. Поэтому инженер, планируя выезд и опираясь на предыдущий опыт, самостоятельно принял решение о подмене СХД.
Кстати, у нас нет жесткого регламента, когда и что нужно подменять. Решение принимает инженер на самом первом и близком к проблеме уровне. Если он считает, что это оптимальное решение, то согласовывает с заказчиком и запрашивает СХД через складскую базу.
Потом, конечно, выяснилось, что заказчик просто неправильно подключил кабели. Казалось бы, подменную СХД можно было и не везти на объект, но в таких случаях всегда лучше перестраховаться.
И еще показательный случай. Требовалось заменить интерфейсную карту на СХД, через которую была подключена вся SAS-петля и, как следствие, зависели десятки дисков. Заказчик задал прямой вопрос о гарантиях: «Вы уверены, что после замены всё запустится и будет работать как положено?».
Снова дилемма для инженера, который понимает, что в процессе работы может возникнуть масса непредвиденных ситуаций. Чтобы не давать пустых обещаний, он честно перечислил все возможные риски, даже те, вероятность которых составляла примерно 0,01%. Заказчику этой информации вполне хватило, чтобы решение снова свелось к временной замене СХД на период ремонта.
В этот раз СХД пришлось отправлять из Москвы на самый край страны. Наземная доставка заняла целых 10 дней. Очень долго, но все участники были готовы ждать. К тому же у заказчика отсутствовали свободные FC-порты на коммутаторах, поэтому вместе с СХД пришлось отправить еще и два коммутатора. Мы собрали необходимое оборудование, отправили его и благополучно закрыли заявку.
Как видите, у нас сложился вполне рабочий сценарий сервисного обслуживания. Компетенции вендоров в отношении их оборудования могут превосходить наши, но мы компенсируем эту разницу дополнительными уровнями защиты. Это помогает обеспечивать стабильную работу системы даже при возникновении непредвиденных ситуаций.
Может показаться, что такой подход требует огромных вложений. На самом деле использование подменных СХД практически не влияет на общие затраты и стоимость сервиса. Мы равномерно распределяем расходы на подобные активы по годовому бюджету, так что они не создают неудобств.
В заключение: всегда найдется другое решение
После нескольких лет работы в новых реалиях могу с уверенностью сказать: уход вендоров — это вызов, но не приговор. Наш опыт с подменными СХД показал, что даже в отсутствие прямой поддержки производителя можно найти эффективные решения для обеспечения непрерывности бизнеса наших клиентов.
Подведу итоги:
Наш парк подменных СХД покрывает потребности большинства клиентов и обеспечивает бесперебойную работу их систем во время обслуживания.
Такой подход оказался не просто страховкой, но и полезным инструментом для развития компетенций. Подменные системы активно используются для обучения молодых специалистов, когда не задействованы у заказчиков..
Иногда простое решение (замена СХД с переносом данных) оказывается эффективнее и безопаснее, чем долгий и рискованный анализ сложной проблемы.
В текущих условиях главное — сохранять гибкость мышления и не бояться нестандартных решений. Помимо воспроизведения утраченной экспертизы вендора мы пошли по пути создания дополнительного уровня безопасности. Это позволило обеспечить клиентам спокойствие и уверенность, а нам — возможность проводить работы без стресса.
А как вы решаете проблемы с обслуживанием сложных систем в отсутствие поддержки вендора? Может быть, у вас есть другие успешные подходы? Делитесь в комментариях!
