Может ли ZFS справиться с внезапной потерей мощности? (Какие события приводят к невозможности восстановления пула, если сам диск не вышел из строя или стал ненадежным)

Какова вероятность того, что ZFS будет в согласованном состоянии (даже если некоторые данные были потеряны) и пул будет пригоден для использования / чтения при перезагрузке?

ZFS работает как система управления транзакционной базой данных, поскольку старые данные не обновляются при обновлении, как в традиционных файловых системах. Вместо этого новые данные записываются в другое место на диске, затем структуры метаданных файловой системы обновляются, чтобы указывать на новые данные, и только после этого блок старых данных освобождается для повторного использования файловой системой. Таким образом, внезапная потеря питания приведет к тому, что старая копия данных останется на месте, если новые обновления данных не будут на 100% зафиксированы в постоянном хранилище. Вы не будете заменять половину блока или что-либо подобное, что приведет к повреждению данных.

Кроме того, ZFS использует сложную схему контрольных сумм, которая позволяет файловой системе обнаруживать неверно записанные или поврежденные данные.

Если вы используете ZFS с избыточным хранилищем, эта же схема позволяет файловой системе выбирать между двумя или более избыточными копиями данных при восстановлении файловой системы. То есть, если у вас есть две копии данного блока, и только одна из них соответствует его сохраненной контрольной сумме, файловая система знает, что она должна восстановить поврежденную копию / копии с чистой.

Эти исправления могут происходить на лету, когда вы пытаетесь прочитать или изменить данные, после чего файловая система может понять, что запрошенные блоки не являются полностью кошерными, или во время zfs scrubоперации. Распространено запланировать периодическое выполнение скраба в пулах ZFS, в которых есть файлы, к которым редко обращаются, поскольку в противном случае файловая система не обнаружила бы потерю аппаратных данных при нормальной работе. Пулы ZFS, работающие на изощренном оборудовании, обычно показывают некоторое количество фиксированных блоков после каждой очистки.

Очистка вроде как fsckдля других файловых систем типа Unix, за исключением того, что это происходит онлайн, когда файловая система монтируется и используется; это происходит в фоновом режиме и только когда пул в противном случае простаивает. Кроме того, fsckреализации обычно проверяют только метаданные, но не данные, а контрольные суммы ZFS, и поэтому могут обнаруживать ошибки в обоих. Если эти механизмы целостности решают, что один из блоков должен быть заменен, он может использовать контрольные суммы, чтобы решить, какой копией заменить поврежденные копии.

Предполагая, что носители, оборудование и программное обеспечение по-прежнему работают надежно / должным образом, что еще могло пойти не так, чтобы в результате была потеря пула?

Насколько я знаю, такого случая нет. Либо одна из трех упомянутых вами вещей потерпела неудачу, либо ZFS смонтирует пул и выполнит чтение из него.

Очевидно, недостаточная избыточность + отказ диска (или другая серьезная проблема с оборудованием) - один из случаев

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

Возьмите простое двустороннее зеркало. Я думаю, вы думаете о том, что один из дисков физически удален из компьютера или, по крайней мере, недоступен по какой-то причине. Но представьте, что сектор 12345 поврежден на обоих дисках. Тогда все хитрые контрольные суммы и избыточность в ZFS не могут вам помочь: обе копии повреждены, поэтому весь блок, содержащий этот сектор, не может быть прочитан.

Но вот умный немного: так как ZFS является как файловая система и менеджер томов - в отличие от хлестать вверх, как аппаратного RAID + ext4 или LVM2 + ext4 - это zpool statusкоманда покажет вам, какой файл необратимо поврежден. Если вы удалите этот файл, пул немедленно вернется в неповрежденное состояние; проблема была устранена Сбои, которые отделяют файловую систему от частей RAID и LVM, не могут этого сделать.

Какие ситуации должны возникнуть до того, как это не может произойти, и что должно произойти для их возникновения?

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

По этой причине с сегодняшними чрезвычайно большими дисками - 100 триллионов бит! - Я рекомендую вам настроить ZFS (или любую другую систему RAID или LVM в этом отношении) как минимум с двойной избыточностью. В терминах ZFS это означает raidz2, 3- сторонние зеркала или выше.

Тем не менее, ZFS обычно хранит дополнительные копии всех метаданных файловой системы сверх обычных уровней избыточности, используемых для обычных файловых данных. Например, двустороннее зеркало будет хранить 2 копии обычных пользовательских данных, но 4 копии всех метаданных. Вы можете набрать это обратно для производительности, но вы не можете отключить его полностью.

В руководстве ZFS есть глава о режимах сбоев ZFS, которая может показаться вам полезной.

Поскольку мои комментарии становятся длиннее, этот ответ кажется полезным. Уоррен Янг уже правильно изложил все основные соображения в своем ответе, поэтому я просто сосредоточусь на части «зеркально отражать или не зеркально отображать устройство SLOG?».

Ситуация выглядит следующим образом:

Я подхожу к своей системе ZFS и без предупреждения отключаюсь и случайно вырываю P3500 ZIL на полпути через очень тяжелый сеанс входящих данных, и система сразу же зависает. Благодаря хорошим БП и МБ, другие жесткие диски и твердотельные накопители не подвержены влиянию электрических переходных процессов. Каждый второй диск / том был избыточным, кроме ЗИЛа. Я только что потерял некоторые последние данные, весь пул, или "это зависит", и если это зависит, то от чего? )

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

Теперь вопрос о том, что выбрать:

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

Это зависит от вашей ситуации (как всегда):

• Если у вас просто обычное хранилище данных (классический файловый сервер), вы не получите (или вообще ничего) от перемещения ZIL на устройство SLOG, потому что SMB асинхронен и может справиться с внезапной потерей питания. Я считаю, что для NFS это зависит от вашего выбора / программного обеспечения, но в настоящее время большинство людей используют SMB на всех трех основных системах.
• Если вам нужна скорость и целостность (в основном для баз данных и хранилищ виртуальных машин), вы будете (должны) работать с ним, sync=alwaysи вам понадобится устройство SLOG для ZIL, или оно будет очень очень медленным. В этих случаях вы можете либо зеркально отразить устройство SLOG, либо решить, что событие «внезапный аппаратный сбой SSD / контроллера или внезапное отключение питания» достаточно редкое для его запуска. Затем вы можете решить, является ли стоимость оправданной или нет (в большинстве случаев это так, поскольку остальное оборудование довольно дорого, но все же намного дешевле, чем коммерческие предложения).
• Если вы хотите покоя, но у вас ограниченный бюджет, я могу порекомендовать Intel SSD 730. Он продается как продукт «для геймеров» или «энтузиастов», но очень похож на внутреннюю линию 3700 меньшего размера, если сравнивать таблицы данных., У этого также есть суперконденсаторы, поскольку несколько источников на веб-состоянии. Конечно, официально Intel не допустит этого, потому что тогда никто не будет покупать дорогие.

Изменить: в отношении вашего комментария:

NFS / ESXi / sync будет основным вариантом использования. Поскольку затраты и риск лежат на моих плечах, я пытаюсь понять риск, а не получить рекомендованный подход - если отдельный ZIL выходит из строя как часть перебоя в питании (независимо от того, был ли он предназначен для резервирования или защиты от потерь, и т.д.), но это никак не влияет, возможна ли потеря / повреждение только для данных, полученных ZIL и еще не записанных в пул (в худшем случае данные последних нескольких секунд), и восстанавливаемых, или есть способы внезапного сбоя питания ZIL + ( предполагая, что нет другого вида сбоя в то же самое время), может ли пул быть неисправимым?

Все пункты действительны только в предположении вашего примера, и ни одно из следующих утверждений не соответствует действительности: (a) ошибки в ZFS, (b) полный сбой оборудования всех дисков пула, (c) человеческая ошибка / злоба.

• Данные вашего пула будут в безопасности, а целостность данных в покое будет сохранена, это означает, что вы можете импортировать пул, и он не будет поврежден с точки зрения ZFS. Это нормальное поведение потери мощности в ZFS и часть его конструкции.
• После восстановления питания обычно читается ZIL, чтобы восстановить потерянные транзакции (аналогично СУБД). Теперь возможно следующее:
  • Ваше устройство SLOG не повреждено, или поврежденные части можно восстановить с зеркала SLOG: все работает как обычно (после возможного восстановления), поэтому ваши последние 5 секунд записываются обратно в пул.
  • Устройство SLOG повреждено: невозможно выполнить откат ZIL. Я не знаю, пробовал ли частичный откат, но с вашей точки зрения это не будет иметь большого значения (потому что вам нужны все транзакции), поэтому я предполагаю, что ваши последние 5 секунд отбрасываются.

С точки зрения пула, даже этот наихудший случай довольно хорош - 5 секунд потеряно, но пул импортируется (если его версия не менее 19 ). Но с точки зрения приложения, это может быть критической ошибкой - приложение просто записало 5 секунд данных синхронизации, получило подтверждение того, что оно было записано успешно, и после перезагрузки данные отсутствуют, но приложение не знает этого. Точная ошибка зависит от приложения. СУБД, возможно, стала несовместимой и нуждающейся в ремонте, большой файл данных может быть нечитаемым, системные файлы могут вызвать сбои в обнаружении, зашифрованный раздел хранилища может быть полностью неустранимым - все из-за того, что его часть отсутствует / неверна.

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

Вы можете прочитать хорошее резюме по Solaris ZFS, синхронным операциям записи и объяснению ZIL, а также некоторые подробности о части ситуаций потери данных о последствиях потери устройства ZFS ZIL SLOG, насколько я понимаю . Документация Oracle немного короткая, но в ней также упоминается, что при нормальной работе ZIL автоматически перемещается из SLOG в пул устройств при сбое SLOG (конечно, у вас есть 5 секунд уязвимости).

Страница man также предлагает информацию об импорте пулов без ZIL:

 zpool import -a [-DfmN] [-F [-n]] [-c cachefile|-d dir] [-o mntopts] [-o property=value]... [-R root]  -m Allows a pool to import when there is a missing log device. Recent transactions can be lost because the log device will be discarded. 

Я использую ZFS на 4 серверах, а также свой ноутбук на 5+ лет. У меня было несколько сбоев питания на серверах с интенсивной записью (неисправное встроенное ПО ИБП, сообщающее о ложных данных) и я не заметил ЛЮБЫХ * ошибок данных / проблем с монтированием пула (это не означает, что не было потери данных из-за последней транзакции, которая не завершила запись, как описано ранее / КПС)

* за исключением одного события, когда я отклонился от руководства по ZFS: у меня был ZFS на одном диске (iSCIS SAN LUN отображен на хосте) внутри KVM Guest, и после первоначального копирования данных я забыл изменить режим кэширования с WriteBack на WriteThrough. Пул (5 ТБ) был читаем, но сообщалось об ошибках более 20 КБ. Мне пришлось воссоздавать пул, используя данные с сервера резервного копирования - благодаря снимкам zfs и отправке / получению zfs я потерял только (то есть это могло быть намного хуже) 2 минуты данных. Используйте ECC-память, отключите всю буферизацию записи (по крайней мере, без BBU / FBU - тема для другой истории), RTFM и ZFS отлично работают.