Когда отсутствие избыточности надёжнее — миф об избыточности

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

RAID — прекрасный пример того, как недостаток целостного мышления в отношении рисков может привести к странным решениям. Рассмотрев не редкий сценарий, мы увидим, как цель защиты от отказа диска может фактически привести к увеличению риска даже при добавлении дополнительной избыточности. В этом сценарии мы сравним массив из двенадцати дисков — двенадцать трёхтерабайтных SATA-дисков в едином массиве. Нередко можно услышать о людях, выбирающих RAID 5 для такого сценария, чтобы получить «максимальную ёмкость и производительность» при «достаточной защите от отказа».

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

То, что пугает нас при операции resilver RAID 5, — это возможность возникновения неисправимой ошибки чтения (URE). Когда это происходит, операция восстановления останавливается и массив оказывается в нерабочем состоянии: все данные на массиве теряются. На обычных SATA-дисках частота URE составляет 10^14, то есть один раз на каждые двенадцать терабайт операций чтения. Это означает, что шеститерабайтный массив, проходящий resilver, имеет примерно пятидесятипроцентный шанс столкнуться с URE и отказать. Пятьдесят процентов вероятности отказа — это невероятно высокий показатель. Представьте, если бы у вашего автомобиля был пятидесятипроцентный шанс потери колёс при каждой поездке. Таким образом, при небольшом (по нынешним меркам) шеститерабайтном массиве RAID 5 на SATA-дисках с URE 10^14, в случае потери одного диска, у нас лишь пятидесятипроцентный шанс на восстановление массива при условии немедленной замены диска. Это не учитывает риск отказа второго диска — только риск ошибки URE. И это при условии, что диски полностью простаивают, кроме операции resilver. Если диски активно используются для других задач одновременно, шансы возникновения чего-либо плохого — URE или отказа второго диска — начинают резко возрастать.

При двенадцатитерабайтном массиве вероятность полной потери данных в ходе операции resilver приближается к ста процентам — то есть RAID 5 в этом случае лишён какой-либо функциональности. Шанс на выживание всегда есть, но он очень мал. При шести терабайтах можно сравнить операцию resilver с игрой в русскую рулетку с одним патроном и шестью барабанами, нажимая на курок три раза. При двенадцати терабайтах нужно нажать шесть раз! Это не лучшие шансы.

Но мы говорим не о двенадцатитерабайтном массиве. Мы говорим о тридцатишеститерабайтном — что звучит внушительно, но сегодня это размер, который легко могут иметь как домашние пользователи, так и малый бизнес. Каждый крупный производитель серверов, а также почти все производители бюджетных систем хранения предлагают сегодня системы хранения в этом ценовом диапазоне менее чем за 10 000 долларов. Resilver RAID 5 с одним отказавшим диском на тридцатишеститерабайтном массиве — это как играть в русскую рулетку, один патрон, шесть барабанов, и нажимать на курок восемнадцать раз! Данные практически обречены. Добавьте к этому невероятное количество времени, необходимое для восстановления массива такого размера, и риск отказа второго диска в период восстановления начинает становиться весьма серьёзной угрозой. Я встречал оценки времени resilver в недели или месяцы на некоторых системах. Это долго — работать без возможности потерять ещё один диск. Когда мы говорим о часах или днях, риски достаточно невелики, но всё же присутствуют. Когда речь идёт о неделях или месяцах непрерывной нагрузки — а операции resilver крайне интенсивны для дисков — частота отказов резко возрастает.

С массивом такого размера можно фактически допустить, что потеря одного диска означает потерю всего массива, оставляя нас вовсе без защиты от отказа диска. Теперь, если рассмотреть диск с такой же или лучшей производительностью и такой же или большей ёмкостью под управлением RAID 0, который также не обеспечивает никакой защиты от потери диска, нам понадобится лишь одиннадцать из тех же дисков, что и для массива RAID 5 из двенадцати. Это означает, что вместо двенадцати жёстких дисков, каждый из которых имеет примерно трёхпроцентный шанс ежегодного отказа, у нас будет только одиннадцать. Уже это делает наш массив RAID 0 более надёжным, поскольку дисков для отказа меньше. Мало того, что дисков меньше, — нет необходимости записывать блок чётности и пропускать блоки чётности при чтении, что незначительно снижает механический износ массива RAID 0 при той же нагрузке, давая ему самое незначительное дополнительное преимущество в надёжности. Массив RAID 0 из одиннадцати дисков будет идентичен по ёмкости массиву RAID 5 из двенадцати дисков, но будет обладать несколько лучшей пропускной способностью и задержкой. Победа во всём. Плюс экономия от отсутствия необходимости в дополнительном диске.

Таким образом, мы видим, что в больших массивах (большие по ёмкости, а не по количеству шпинделей) RAID 0 в определённых сценариях фактически превосходит RAID 5. При использовании обычных SATA-дисков это происходит при ёмкостях, доступных даже продвинутым домашним пользователям и многим малым предприятиям. Если перейти к корпоративным SATA-дискам или SAS-дискам, то ёмкость, при которой это происходит, становится очень высокой и сегодня не вызывает беспокойства, но через несколько лет, когда ёмкости дисков ещё вырастут, это станет актуальным. Но это наглядно показывает, насколько опасен RAID 5 при сегодняшних размерах. Все понимают колоссальные риски RAID 0, но бывает трудно осознать, что проблемы RAID 5 настолько серьёзны, что он может оказаться менее надёжным, чем RAID 0.

То, что RAID 5 может быть менее надёжным, чем RAID 0, в массиве такого размера только из-за операций resilver — лишь начало. В огромном массиве такого рода время resilver может быть столь долгим и наносить дискам такой ущерб, что отказ второго диска начинает становиться измеримым риском. А ещё существуют дополнительные риски, обусловленные ошибками контроллера массива, которые могут использовать алгоритмы resilver для уничтожения всего массива даже при отсутствии отказа диска. Поскольку RAID 0 (или RAID 1 или RAID 10) не имеет алгоритмов resilver, он не подвержен этому дополнительному риску. Эти риски сложно поддаются количественной оценке, но важно то, что они являются дополнительными рисками, которые накапливаются при использовании более сложной системы, тогда как более простая система без избыточности изначально была надёжнее.

Теперь, когда мы установили, что RAID 5 может быть менее надёжным, чем RAID 0, укажу на очевидные опасности RAID 0. RAID в целом используется для снижения риска отказа одного отдельного жёсткого диска. Мы все боимся, что единственный диск просто откажет и все данные будут потеряны. RAID 0, будучи большой полосой дисков без какой-либо избыточности, берёт риск потери данных от отказа одного диска и умножает его на количество дисков, где отказ любого диска вызывает полную потерю данных на всех дисках. Таким образом, в нашем примере из одиннадцати дисков, если какой-либо из одиннадцати откажет, всё будет потеряно. Очевидно, что это значительно опаснее, чем использование одного диска.

Я пытаюсь указать на то, что избыточность не означает надёжности. То, что нечто избыточно, как RAID 5, не гарантирует, что оно всегда будет надёжнее чего-то лишённого избыточности.

Мой любимый аналог здесь — рассмотреть дома во время торнадо. В первом сценарии мы строим дом из кирпича и раствора. Во втором сценарии мы строим два избыточных дома, каждый из соломы (наши строители, по-видимому, свиньи). Когда придёт торнадо (или Серый волк), какой из вариантов с большей вероятностью оставит нам стоящий дом? Очевидно, один кирпичный дом имеет значительные преимущества в надёжности перед избыточными соломенными домами. Избыточность не имела значения — в конечном счёте важна надёжность.

Избыточность часто вводит в заблуждение, потому что её легко количественно определить, но трудно квалифицировать. Избыточность — это вопрос чёрного и белого: является ли она избыточной? Да или нет. Просто. Надёжность не так проста. Надёжность касается частот и вероятностей отказов. Это статистика и анализ. Поскольку надёжность трудно выразить количественно значимым образом, особенно при представлении проекта бизнесменам, избыточность нередко становится простым заменителем этой сложной концепции.

Концепция использования избыточности для подмены вопросов надёжности также применяется к подсистемам весьма запутанными способами. Вместо того чтобы делать «систему» избыточной, стало обычной практикой делать избыточной высоконадёжную и недорогую подсистему и рассматривать избыточность подсистемы как применимую ко всей системе. Наиболее распространённый пример — контроллеры RAID в продуктах SAN. Вместо того чтобы иметь избыточный SAN (то есть два SAN), производители нередко делают избыточным один компонент, обычно не являющийся избыточным в обычных серверах, и называют SAN избыточным — подразумевая SAN, содержащий избыточность, что совершенно не одно и то же.

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

Как и миф о надёжности RAID 5 и надёжности системы/подсистемы, совместные технологии хранения — такие как SAN и NAS — нередко подвергаются аналогичному подходу, особенно в контексте виртуализации. Существует распространённый сценарий, когда осуществляется проект виртуализации, и люди инстинктивно паникуют, поскольку единственный хост виртуализации представляет единую точку отказа: при его сбое одновременно откажут множество систем.

Использование термина «единая точка отказа» вызывает панику и является эффективным способом управлять беседой. Но SPOF, как мы его называем, хотя и то, от чего мы стараемся избавиться при возможности, может не быть концом света. Вспомним наш кирпичный дом. Это — SPOF. Наши два соломенных дома — нет. Тем не менее лёгкий ветерок уничтожит наше избыточное решение быстрее, чем надёжный SPOF. Поиск SPOF — отличный способ выявить точки уязвимости в системе, но не следует считать, что каждый SPOF должен быть сделан избыточным в каждом сценарии. Большинство предприятий обнаружат, что их наилучшая ценность — иметь многочисленные SPOF. Наша настоящая цель — надёжность при разумной стоимости; избыточность, как мы видели, не является заменой надёжности, это лишь инструмент, который мы можем использовать для достижения надёжности.

Теория, которой многие следуют при виртуализации, заключается в том, чтобы взять хост виртуализации и сказать: «Этот хост — SPOF, поэтому мне нужны два из них и использование функций высокой доступности для прозрачного переключения при отказе!» Это подстёгивается тем, что ведущий поставщик решений виртуализации зарабатывает деньги прежде всего на продаже дорогостоящих продуктов с функциями HA, а во вторую очередь — на том, что принадлежит крупному поставщику систем хранения. Поэтому продажа ненужных или даже опасных дополнительных совместных систем хранения для них выгодна и вполне может быть причиной, по которой они с самого начала продвигали виртуализацию. Избыточные хосты виртуализации с совместным хранилищем звучит замечательно, но может быть крайне ошибочным по нескольким причинам.

Первая причина: устранение исходного SPOF — хоста виртуализации — заменяется новым SPOF — совместным хранилищем. Это не даёт никакого результата. Допуская, что мы используем серверы и совместное хранилище сопоставимого качества, мы лишь переместили место нахождения риска, не изменив его величины. Вероятность отказа системы хранения примерно равна вероятности отказа исходного сервера. Но помимо того что мы тасуем SPOF как в игре в напёрстки, мы сделали нечто значительно, значительно худшее — мы ввели цепные или каскадные зависимости отказов.

В исходном сценарии у нас был один сервер. Если сервер работал — всё хорошо, если отказывал — нет. Просто. Теперь у нас два хоста виртуализации, один сервер хранения (SAN, NAS, что угодно) и сеть, соединяющая их. Мы уже определили, что риск отказа совместного хранилища примерно равен общему системному риску в исходном сценарии. Но теперь у нас есть дополнительные зависимости: сеть и два внешних узла виртуализации. Каждый из этих компонентов надёжнее хрупкого совместного хранилища (всё, что содержит механические диски, будет хрупким), но то, что они несут меньший риск, — не главное; главное то, что риски комбинируются.

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

Теперь, когда у нас есть вся эта избыточность, появляется ещё один риск для беспокойства. Управление всей этой избыточностью, всеми этими движущимися частями, требует значительно больших знаний, навыков и подготовки, чем управление простым, единственным сервером. Мы перешли от простого решения к очень сложному. По моему личному опыту, настоящая опасность подобных решений исходит не от отказа оборудования, а от человеческой ошибки. Мало того что почти ничего не сделано для предотвращения человеческих ошибок, способных вывести из строя эту новую систему, — мы добавили бесчисленные точки, где человек может случайно обрушить всю систему целиком — и с избыточностью, и без. Я видел это своими глазами; я слышал ужасные истории. Чем сложнее система, тем вероятнее, что человек случайно всё сломает.

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