дыра записи: какие уровни RAID затронуты?

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

Я думаю есть 2 возможные определения того, что это за «дыра для записи» RAID-массива.

На упомянутой вами странице «дыра для записи» используется для обозначения несогласованности массива RAID. Чтобы понять это, вы должны принять во внимание принцип работы RAID-массива. Операции записи отправляются на разные диски массива. Но поскольку диски независимы, нет гарантии относительно того, в каком порядке операции записи действительно передаются (дисками) на физический носитель. Другими словами, когда вы записываете блоки в массив RAID, операции записи не атомарны. Это не проблема при нормальной работе массива. Но это может быть в таких случаях, как отключение питания или любой другой критический сбой.

Внутренняя несогласованность RAID-массива может произойти на каждом уровне RAID, который имеет какую-либо избыточность данных: RAID 1, 4, 5, 6 и т.д. синхронизируется между различными дисками массива.

Существует несколько возможных стратегий решения проблем несогласованности RAID-массива:

• Программный RAID-массив Linux MD по умолчанию использует стратегию «синхронизации» при сборке RAID-массива, помеченного как «грязный». То есть для массивов RAID 1 один из дисков считается мастером, и его данные копируются на другие диски. Для RAID 4/5/6 считываются блоки данных. Затем блоки четности регенерируются и записываются на диски. Процесс синхронизации может быть очень длительным. Чтобы сделать это намного быстрее, есть функция, называемая «растровое изображение» с намерением записи, которая отслеживает горячие фрагменты массива. Эта функция растрового изображения значительно сократит продолжительность процесса синхронизации в обмен на некоторую потерю производительности во время операций записи.

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

• Существует также стратегия CoW (копирование при записи), о которой я расскажу чуть позже.

Другое возможное определение «дыры для записи» относится к проблемам потери данных в RAID 4/5/6 при определенных обстоятельствах (уровни RAID 1 и 10 не подвержены этому виду «дыры для записи»). Я цитирую Определение Нила Брауна рассматриваемой проблемы:

"Отверстие для записи - это простая концепция, которая применяется к любой схеме RAID с чередованием + четностью, например, RAID4, RAID5, RAID6 и т. Д. Проблема возникает, когда массив запускается из-за нечистого завершения работы. без доступности всех устройств, или если ошибка чтения обнаружена до восстановления четности после нечистого завершения работы."

То есть у вас есть, например, массив RAID 5, и произошло событие отключения питания. RAID попытается привести массив в согласованное состояние. Но один из дисков больше не работает или некоторые его секторы не читаются. Следовательно, четность не может быть восстановлена ​​из блоков данных, поскольку некоторые из них отсутствуют. Можно сказать: да, но у нас есть избыточность в массиве. Значит, мы могли бы использовать четность для восстановления недостающих блоков данных, не так ли? Ответ - нет. Если вы сделаете это, вы можете получить данные мусора, потенциально, в некоторых блоках данных. Это очень серьезная проблема. Дело не в том, что некоторые блоки данных были записаны или нет (современные журналируемые файловые системы не имеют с этим никаких серьезных проблем). Дело в том, что некоторые блоки данных массива потеряны или (если регенерированы) являются мусором. В любом случае здесь есть серьезная проблема.

Если мы возьмем это более строгое определение «отверстия для записи», мы увидим, что это особый угловой случай, который случается только при определенных обстоятельствах. Должен произойти критический сбой, например, отключение питания. И, кроме того, какой-то диск должен выйти из строя (полностью или частично). Но для RAID 4/5/6 (уровни с блоками четности) риск есть.

Этот риск можно предотвратить, используя двухэтапную стратегию записи (или используя технику ведения журнала, которая была объяснена ранее). С помощью журнала все блоки данных могут быть безопасно записаны на диски даже в этих угловых корпусах. Аппаратный RAID с батареями с батарейным питанием, если он правильно реализован, не подвержен каким-либо проблемам с "дырами для записи". Программный RAID-массив Linux MD также получил писать с функцией журнала несколько лет назад это эффективно предотвращало проблему «дыры для записи».

Я не так хорошо знаком с ZFS, но думаю, что он использует метод CoW (копирование при записи) в массивах RAID-Z, чтобы избежать проблем с «дырами для записи». Он запишет все данные плюс четность в какое-то неиспользуемое пространство, а затем обновит виртуальную ссылку на эти физические блоки. При использовании этого двухэтапного процесса операции записи гарантированно будут атомарными. Так что проблема с отверстием для записи эффективно предотвращается.

Семестр отверстие для записи используется для описания двух похожих, но разных проблем, возникающих при работе с RAID-массивами без защиты от батарей:

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

• правильное определение отверстие для записи, что является потерей вся полоса избыточность данных из-за внезапного отключения питания во время обновления полосы, применимо только к RAID на основе четности.

Второе и правильное определение отверстия для записи требует дополнительных пояснений: давайте предположим, что 3-дисковый RAID5 с размером блока 64 КБ и размером полосы 128 КБ (+ размер четности для каждой полосы 64 КБ). Если питание пропадает после записи 4K на диск №1, но в течение обновления четности на диске №3, мы можем иметь поддельный (т.е. поврежденный) блок четности и необнаруженную проблему согласованности данных. Если позже диск №2 умирает и четность используется для восстановления исходных данных путем xoring диска №1 и диска №3, восстановленные 64КБ, первоначально находившиеся на диске №2 и не недавно написанные, тем не менее будут повреждены.

Это надуманный пример, но он должен выявить основную проблему, связанную с отверстие для записи: потеря нетронутых, неподвижных, несвязанных данных, разделяющих одну полосу с последними прерванными записями. Другими словами, если fileA был написан много лет назад, но имеет ту же полосу, что и только что написанный fileB, и система теряет питание во время обновления fileB, fileA будет в опасности.

Еще одна вещь, которую следует учитывать, - это политика записи массива: использование чтения / восстановления / записи (то есть: целые полосы перезаписываются, когда происходит частичная запись) по сравнению с чтением / изменением / записью (то есть: обновляются только затронутые фрагменты + четность). другой вид отверстия для записи.

Из вышеизложенного должно быть ясно, потому что RAID0 и RAID1 не имеют надлежащего отверстия для записи: они не имеют четности, которая может быть "рассинхронизированной", что приведет к недействительности всей полосы. Обратите внимание, что ножки зеркала RAID1 жестяная банка будут рассинхронизированы после некорректного завершения работы, но единственное повреждение будет связано с последними записанными данными. Ранее записанные данные (т.е. данные в состоянии покоя) не столкнутся с проблемами.

Как можно избежать, определив и обозначив подходящее отверстие для записи?

• HW RAID использует энергонезависимый кэш записи (например, BBU + DRAM или флеш-модуль с емкостной поддержкой) для постоянного хранения обновлений, которые должны быть записаны. Если питание отключено, HW RAID-карта повторно выполнит любую отложенную операцию, сбрасывая свой кеш на дисковые пластины при восстановлении питания и загрузке системы. Это защищает не только от надлежащей дыры для записи, но и от повреждения последних записанных данных;

• Linux MD RAID использует битовую карту записи, которая записывает подлежащие записи полосатые перед обновляя их. В случае потери питания грязный битовый массив используется для пересчета любых данных четности для затронутых полос. Это защищает только от настоящего отверстия для записи; последние записанные данные могут быть повреждены (если не поддерживаются fsync () + барьер записи). Тот же метод используется для повторной синхронизации несинхронизированной части массива RAID1 (чтобы убедиться, что две ветви зеркала синхронизированы, хотя для зеркал нет отверстия для записи);

• более новый Linux MD RAID5 / 6 должен иметь возможность использовать устройство ведения журнала / журнала, частично имитируя энергонезависимую кэш-память обратной записи соответствующей HW-карты RAID (и, в зависимости от конкретного патча / реализации, защиту как от дыр для записи, так и от повреждения последних записанных данных или только от дыр для записи);

• наконец, RAIDZ избегает обе дыра в записи и повреждение последних данных с использованием наиболее «элегантного», но влияющего на производительность метода: путем записи только полноразмерных полос (и ведения журнала любой синхронизированной записи в ZIL / SLOG).

Полезные ссылки:
https://neil.brown.name/blog/20110614101708
https://www.kernel.org/doc/Documentation/md/raid5-ppl.txt
https://www.kernel.org/doc/Documentation/md/raid5-cache.txt
https://lwn.net/Articles/665299/

Отверстие для записи может повлиять каждый Уровень RAID, кроме RAID-0; Конфигурации с чередованием (RAID-4/5/6) и зеркалированием (RAID-1) могут быть уязвимы просто из-за того, что атомарная запись невозможна на 2 или более дисках.

Я говорю «может», потому что проблема зависит от реализации. Не говоря уже о решениях файловых систем следующего поколения, таких как RAID-Z, классические реализации программного RAID также нашли способы решить эту проблему: mdadm имеет относительно недавно представила функцию журнала, которая использует выделенные кеш-диски, чтобы избежать этого, и даже если вы решите не использовать эту функцию, она также вызывает повторную синхронизацию после каждого нечистого завершения работы, таким образом обнаруживая и устраняя дыры для записи, как только это происходит.

Спасибо каналу #zfs irc за помощь!