Недавно у нас развалился RAID 5. Один диск на первом году своей жизни умер сам от естественных причин. Такое может быть и в период трёхлетней гарантии — нечасто, но может. Мы вынули его, поставили на его место диск из горячего резерва — и во время ребилда в массиве умер второй диск. Данные умерли вместе с ним.

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

Это правда: ни одна схема резервирования никогда не гарантирует 100 %. Случается всякое. Диски из одной партии могут умереть в один день: у нас такое было только один раз несколько лет тому назад, но было. Разболтавшийся кулер может вызвать резонансные вибрации, которые убьют два массива целиком: такое было больше пяти лет тому назад, и мы долго расследовали ту ситуацию.

Бывает всё.

В России не очень принято выплачивать компенсации за простои и потерю данных. В прошлом году мы поняли, что это важно делать, и включили такие пункты в соглашение.

Это привело к целой цепочке последствий, в частности, к тому, что мы перешли на RAID 10 как на новый для нас стандарт хранения данных.

▍ Как было раньше

Чаще всего у нас идёт речь про восемь физических дисков в сервере (но местами есть где пять, а есть где десять) — это один контроллер. Плюс второй контроллер — для дисков с ОС. Плюс отдельно от этих массивов — для бекапа.

Раньше всё хранилось в RAID 5 (в абсолютном большинстве случаев) и в RAID 6.


RAID 5 — это один из относительно недорогих и достаточно эффективных способов хранения данных с резервированием, с защитой от отказа одного диска. Там резерв — N+1, то есть на пять физических дисков вам доступен объём четырёх дисков. Если один диск вылетает, то можно восстановить данные по избыточности с остальных: подойти к серверу, вынуть убившийся диск, поставить новый, подождать ребилда и спокойно работать дальше.

В большинстве случаев это рабочая ситуация. То есть делаешь тикет, меняешь диск из резерва, и все счастливы. Более того, в пределе такие массивы могут ждать замену диска и неделю (на клиентах мы не проверяли, но на личной машине для резерва сайта у нас был случай, что диска для него с ходу не нашлось, но провести замену всё равно успели). Но иногда бывает не так.


В RAID 6 резерв — уже N+2, то есть на четыре диска по объёму вам надо шесть дисков.


В RAID 10 — резервирование 2N: это два RAID 1, объединённых в RAID 0. То есть он быстрый и дублирует данные полностью. Статистически считается, что практическая вероятность выхода его из строя до потери данных настолько мала, что встретится всего пару раз за время работы хостинга на всех машинах во всех ЦОДах во всех странах.

Ещё надёжнее — RAID 51 (два RAID 5 в массиве RAID 1), конечно, но тут мы переходим уже к экономическим обоснованиям.

▍ Экономическое обоснование

Фактически переход на RAID 10 означает плюс два или плюс три диска в каждый сервер. Это дорого: диски, конечно, — расходники, но при этом недешёвые.

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

По железу отказов было относительно мало. Даже с учётом SLA и выплат компенсаций дополнительный расход на диски не окупает эту историю. В смысле мы понимаем, что будем выплачивать меньше в перспективе нескольких лет, но это всё равно не окупается.

Остаётся разница, которую мы для себя объяснили репутацией.

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

Если же мы потеряем данные пользователя, то это залёт. Потом нельзя продолжить работу просто так. Это очень больно бьёт по репутации, даже если это отдельная машина.

Поэтому — RAID 10.

▍ Редеплой сервера

Ещё одна особенность экономики — это замена дисков при редеплое сервера. Если по каким-то причинам нам надо вынуть сервер, поковыряться в нём и вернуть в ЦОД, то мы меняем в нём все диски на новые. Это прямо обязательное условие.

Сами диски сначала уходят в резерв резерва (они ещё рабочие, и если в hot swap лежит два новых диска, а потом вендор заменяет их за один рабочий день, то третий или четвёртый рабочие диски будут нелишними на всякий случай, чтобы потом заменить их на вендорские новые через день). Затем постепенно они списываются. Диски у нас довольно редко находятся в работе больше четырёх лет — разве что на промотарифах, которые когда-то были по 30 рублей.

▍ Но ведь… бекап?

Да, мы предлагаем делать бекап всем. Естественно, на машине, где крутится какой-то сервис, который, например, пережимает видео или обеспечивает коннект с каким-то API, делать бекап не надо. Он накатывается из образа и легко перезапускается. А вот если там сервис, где хранятся те же финансовые транзакции или бухгалтерия, — данные надо беречь.

Пользователи заказывают услугу бекапа менее чем в 3 % случаев. Да, у некоторых есть свой собственный внутри системы, но всё равно статистика показательная.

Пользователи, которые делают геораспределение, — их ещё меньше.

Казалось бы, ни одна система не может быть надёжной, и ответственные вещи всегда нужно хостить в нескольких разных местах — но нет. Практика — другая.

Поэтому потеря данных — это проблема хостинга, а не пользователя. В смысле можно хоть 100 раз говорить про важность бекапа и всего прочего, но всё равно виноват хостинг, даже если он ничего не гарантировал.

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

▍ Это NVMe-RAID?

Нет. У нас везде — SSD: они хорошо соединяются в массивы.

NVMe, как мы писали, очень плохо соединяются в RAID: потеря производительности такая, что смысла в массивах уже и нет. Соответственно, хостеры, которые используют NVMe, практически не могут использовать RAID, если только у них не очень специфическое дорогое железо. Либо они банально приукрашивают.

Машины с NVMe у нас без RAID, но с регулярным бекапом (бесплатным, невидимым пользователю) на HDD/SSD. При развале NVMe пользователь получает машину в последнем забекапленном состоянии.

▍ Почему у вас хранение внутри сервера, а не в кластере в отдельной хранилке?

Кластер — это другой хороший отказоустойчивый подход. Но там уже сам кластер становится точкой отказа, и практика показывает, что не такой уж и редкой. Мы обмениваемся данными с коллегами и знаем, что и как бывает.

Поэтому архитектурное решение — много независимых нод с резервированием внутри них. Это решение минимизирует риски для нас и наших конкретных подходов. Кластеры могут оказаться лучше или дешевле для других условий. Это не религия, а взвешенное решение: возможно, если мы вырастем в 10 раз, то перейдём на кластеры.

Но с сегодняшней точки зрения отказ одного сервера гораздо менее болезненный, и легче решается, чем отказ кластера. Более того, при потере данных многим клиентам важнее скорее запустить новую виртуалку с возможностью накатить туда бекап из личных запасов клиента и потом подключить диск. Если удаётся считать данные с части дисков, то их восстановление на отдельном сервере происходит быстрее, чем в кластере, где процесс может быть сложнее из-за распределённого характера хранения.

Негативный опыт был и с RAID-схемами, и с кластерами. Если вы погуглите название любого хостера со словами «Потеря данных», то увидите, что такое было почти у каждого. Но самый страшный случай сферы — это когда пару лет назад один зарубежный хостер развалил хранилку с шифрованием. Тогда данные у них потерял не один клиент, а сразу много, и это было очень больно.

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

▍ Случаи, когда RAID 5 и 6 выходили из строя

Первая ситуация — равномерный износ дисков одной партии с одной датой производства. Если один умер на втором году жизни, то есть шансы, что его соседи находятся в таком же состоянии. На практике это оказалось известной городской легендой, потому что не подтверждается статистикой. На ребилд обычно времени хватает: речь идёт про разницу в месяцы, а не часы. Но, естественно, такие совпадения бывают, и обычно они легендарны, поэтому и запоминаются. У нас такое было.

Вторая ситуация — общий фактор. У нас однажды разболталось крепление системы охлаждения, и в течение нескольких дней на сервер подавалась равномерная вибрация. В конечном счёте это убило RAID 6, что до этого мы считали крайне маловероятным событием. Ещё из общих факторов были скачки питания, перевозка серверов (такое часто бывало у коллег) и так далее.

Самая тупая ситуация за время работы нашего VDS-хостинга — это когда лично я вытащил не тот диск во время ребилда в 2017 году. Сразу скажу, что я повёл себя, как сказочный идиот.

Я был на площадке по другим делам. В это время в одном из серверов вылетел диск из рейда. Чтобы не терять времени на создание тикетов, админ решил поиграть мной в «Аватара» и попросил заменить диск, раз уж я на месте.

Пошёл, забрал диск в ЗИПе, принёс к серверу, вынул проблемный диск, поставил новый. Начался ребилд. Я пошел дальше по своим делам.

Затем снова звонит админ и просит на всякий случай заменить ещё один диск. Почему-то я решил, что речь идёт о том же массиве. Я и сейчас не админ, хотя вникаю во все аспекты работы, а тогда опыта и вовсе было меньше. Не вдаваясь в подробности, я пошёл и вытащил во время ребилда второй диск.

Дальше результат понятен. Хорошо, что на сервере было немного клиентов и почти у всех были бекапы.

С тех пор, какие бы косячные решения ни принимались во время аварий, я прекрасно понимаю, что за них нельзя ругать. Во время аварии, когда надо принимать много ответственных решений в очень сжатые сроки, вы не взлетаете на крыльях адреналина до сверхэффективности, а деградируете до уровня тренировок. Если поведение у вас не отработано многократными повторами, то, скорее всего, вы потеряетесь. Я вот потерялся даже без аварии. И мне до сих пор стыдно.

▍ Гарантирует ли RAID 10 безопасность данных?

Нет.

Ещё раз: никакой рейд не может гарантировать сохранности данных ни при каких обстоятельствах.

Есть только более безопасные и менее безопасные.

Этот — более безопасный. Но всё равно случается всякое. Другое дело, что мы считаем: с введением RAID 10 другие риски становятся выше — от перегрева в ЦОДе до критического сбоя железа. Ну и человеческий фактор.

▍ Итак, основная причина, почему RAID 10

Просто потому, что мы жадные. Других причин, как обычно, нет!

© 2025 ООО «МТ ФИНАНС»

Telegram-канал со скидками, розыгрышами призов и новостями IT 💻