Как указано в вопросе.

Предположим, я хочу иметь эквивалент скриптованной “кнопки аварийного выключения” для моего пула FreeNAS — что-то, что я могу запустить из GUI или выполнить в консоли/SSH, чтобы очень быстро закрыть все, что может читать или записывать в него, размонтировать файловую систему и — в идеале — погасить диски или разделы, которые он использует.

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

Варианты, предлагаемые командами ZFS, не выглядят многообещающими: команда zpool offline работает только с отдельными устройствами, поэтому может возникнуть состояние гонки, если запись происходит, пока диски удаляются по одному; zpool export требует опцию -f, если она используется, и предупреждение, что -f может привести к потере данных. Можно проверить все открытые дескрипторы файлов, использующие пул или его устройства (тысячи или сотни тысяч?), и принудительно закрыть каждый из них, но это может привести к состоянию гонки, так как это не останавливает создание новых дескрипторов в то же время. Я также не должен считать, что вся активность ZFS управляется списком удаленных серверных демонов файлов для отправки им сигналов завершения, потому что некоторая файловая активность, вероятно, будет локальной (cron/CLI/отсоединенные сессии).

Таким образом, если смотреть, как лучше всего безопасно и быстро вывести в офлайн весь пул, похоже, что umount может быть моим лучшим вариантом — он работает на уровне файловой системы и может быстро вывести в офлайн всю файловую систему как монолитное целое, после чего zpool export, похоже, сможет завершить работу и погасить любую внутреннюю активность безопасным образом без опции -f, сохраняя сами данные в гарантированно последовательном состоянии. Если ведется грубая активность диска (восстановление или проверка), то это, вероятно, возобновится или перезапустится, когда пул будет позже снова выведен в онлайн.

Но даже umount, похоже, не выполняет это полностью, потому что также могут использоваться iSCSI-цели zvol. Данные внутри них по своей природе не могут быть последовательно сохранены, поскольку сервер не знает их структуры, поэтому удаленные инициаторы должны будут провести восстановление данных, насколько это возможно, когда они снова подключатся. Меня это устраивает, но я не уверен, требуется ли какая-то команда для принудительного завершения или вывода целей в офлайн или это лучшее практическое решение. (Примечание: принудительное завершение соединений имеет те же проблемы, что и закрытие отдельных дескрипторов файлов).

Я понимаю, что в случае внезапного вывода пула из состояния RW, когда происходят записи, будет некоторый вид потери данных или проблема. Но если только не нарушается целостность (на уровне пула ZFS и файловой системы), то это хорошо — любые используемые файлы/iSCSI-цели, которые обновляются, будут вынуждены полагаться на удачу, что файловые блоки находятся в ZFS-последовательном, но недействительном состоянии данных из-за выхода в офлайн в процессе записи. Это неизбежно и не является проблемой для вопроса.

Итак, какие шаги мне действительно нужно выполнить, чтобы как можно быстрее вывести в офлайн используемый пул, обеспечивая при этом гарантированную сохранность и последовательность пула — и будет ли ручное umount файловой системы ZFS, которая используется (как часть решения), безопасным или это несет риск повреждения данных?

Обновление: Упомяну здесь на случай, если это окажется полезным для кого-то. Принятый ответ гласит, что export -f может иметь проблемы с zvols (iSCSI и т.д.). На основании этого намека я обнаружил, что iSCSI-обработчик, используемый FreeNAS, может принудительно выйти из сессий, и имеет другие полезные подкоманды, которые могут быть выданы заранее — см. man ctladm. Каким бы образом вы не использовали ваши zvols, вероятно, существует какая-то команда для завершения сессий на них.)

Отказ от ответственности: У меня нет под рукой многих ссылок и источников, чтобы подтвердить все нижеизложенное, и я не тестировал это обширно. Это просто резюме того, что я читал за последние пять-семь лет о ZFS и его работе, и некоторый ограниченный собственный тест (не скоординированный, но в основном случайные перезагрузки).

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

Данные в состоянии покоя / последовательность на диске

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

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

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

Данные в процессе / режимы записи и потеря последних n секунд

Синхронные и асинхронные записи

Обычно ZFS собирает несколько транзакций, чтобы ускорить дорогие записи на вращающиеся диски — позиционирование записывающей головки HDD занимает гораздо больше времени, чем фактическая запись, поэтому вы захотите поставить в очередь как можно больше и затем записать все в последовательном (более быстром!) порядке (помните, у нас есть CoW, это работает здесь совершенно естественным образом).

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

Чтобы бороться с этим, был добавлен ZIL (журнал намерений ZFS). Все синхронные транзакции собираются в этом журнале (который по умолчанию хранится на медленном диске пула, но может храниться на более быстрых, зеркально отображенных SSD, которые называются устройствами SLOG) и после того, как они сохранены, отправляется сообщение “запись успешна” к приложению, которое может продолжать выполнять свои задачи (больше не длинные блокировки). Кроме того, все асинхронные транзакции выполняются без ZIL, поэтому они могут быть быстрее — предусмотрено, что приложение вызывает правильные операции записи для своих данных (синхронные vs асинхронные).

Свойства ZFS

Теперь к более интересной части — что происходит с вашими записями? Здесь нам нужно различать режим работы файловой системы (это свойство ZFS и может быть установлено индивильно для каждой файловой системы). Три возможных режима (из man-страниц):

sync=standard
  Это вариант по умолчанию. Синхронные транзакции файловой системы
  (fsync, O_DSYNC, O_SYNC, и так далее) записываются (в журнал намерений)
  и далее все записанные устройства сбрасываются, чтобы гарантировать
  что данные стабильны (не кэшируются контроллерами устройства).

sync=always
  Для сверхосторожных, каждая транзакция файловой системы
  записывается и сбрасывается в устойчивое хранилище вызовами
  системных функций. Это, очевидно, влечет за собой большую
  потерю производительности.

sync=disabled
  Синхронные запросы отключены. Транзакции файловой системы
  фиксируются на стабильном хранилище только при следующем завершении
  группы транзакций DMU, что может занять много секунд.
  Эта настройка обеспечивает наивысшую производительность.
  Однако это очень опасно, так как ZFS игнорирует запросы
  синхронных транзакций приложений, таких как базы данных
  или NFS. Установка sync=disabled на активной корневой или
  /var файловой системе может привести к несоответствующему
  поведению, потере данных приложения и увеличенной
  уязвимости к атакам с повторением.
  Эта настройка НЕ влияет на консистентность данных на диске ZFS.
  Администраторы должны использовать это только когда они понимают
  эти риски.

Вы заметите, что даже если выбрано disabled, ваш макет пула/внутренняя последовательность не затронута — вы просто потеряете последние 5 секунд данных и это может привести к тому, что ваши файлы окажутся в неверном состоянии (например, потому что у вас есть ВМ сверху, которая ожидает синхронной записи, но вы предоставили только асинхронное zvol-хранилище данных).

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

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

Экспорт/импорт пула:

Из документации о zpool export:

Команда пытается размонтировать любые смонтированные файловые системы в пуле перед продолжением. Если любая из файловых систем не удается размонтировать, вы можете принудительно размонтировать их, используя опцию -f.

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

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

Это означает примерно три вещи:

• -f принуждает пул экспортироваться, принудительно размонтируя все файловые системы, даже если они активны (без учета блокировок или приложений, которые в данный момент пишут в них)
• Это не работает с zvols
• Вы не должны разделять пулы и использовать их на разных системах (будьте осторожны с ситуациями отказа)

Резюме:

• Если вам важна консистентность на диске, вы готовы использовать export -f или полное выключение
• Если вам важны все данные, используйте sync=always и быстрые SSD
• Что касается iSCSI/NFS как хранилищ для ВМ, этот обзор может быть также полезным (выдержка: используйте NFS или отключите кеш записи iSCSI на госте/хосте ВМ; завершите ВМ перед снятием снимка ZFS, ZFS будет в порядке в любом случае, но гостевая ВМ будет только в консистентном состоянии после сбоя)

В ответ на последующие вопросы из комментариев (оставлены вопросы, на которые у меня нет полезных ответов):

(1) “хорошие новости/CoW” – что если верхние блоки собирались обновиться – найдет ли он всегда пригодный верхний блок (даже если указывающий на немного старые версии дерева метаданных)? Насколько плохо это может быть?

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

(2) Я знаком с TXG и использую ESXi. Используя ИБП APC + хороший БП/аппаратное обеспечение + P3700 NVMe ZIL, так что это достойное питание + быстрый ZIL. Но маловероятно, что текущие записи будут все синхронными, и как вы говорите, sync=always медленный. Но ваш ответ вызывает мысль, я, возможно, проведу некоторое тестирование производительности. Я использую дедупликацию (4x экономию, того стоит), так что записи и так медленные (нужно искать DDT). Причина – sync=always влияет только на запись, которая медленная из-за DDT. Но установка sync=always заставляет использовать ZIL, ZIL очень быстрый и это делает длинные TXG безопасными, что может означать, что доступ к диску более эффективен. Или это может убить задержки. Не знаю, что из этого! Возможно, придется попробовать!

У меня нет реального опыта с дедупликацией, так что я не могу ничего полезного сказать здесь, кроме того, что вы уже сделали хорошие выборы в аппаратуре (низкая задержка, высокая производительность случайной записи 64k, NVMe интерфейс). Это могло бы быть быстрее только если бы вы вложились в какой-то действительно дорогой постоянный RAM-диск (ZeusRAM и т.п.).

(6) Под “последовательностью на диске” вы имеете в виду ZFS доволен и пул самосовместим? Не беспокоюсь, если некоторые файлы/директории окажутся с недействительным содержимым или не перемещенными/удаленными, если пул внезапно исчезнет, или файловая система такая как NTFWS/VMFS на zvol получает внутреннюю порчу (т.е. как zvol ZFS он в порядке, но с точки зрения клиента ему нужно исправление fsck/chkdsk), при условии, что пул безопасен/последователен по мнению ZFS

Да. По сути “мой пул не испорчен, ура!” в многопользовательской установке — даже если у одного пользователя проблемы с его файлами, другие не страдают.

(7) Под “консистентным после сбоя” вы имеете в виду то, что я имею в виду (я думаю, вы имеете) – что ZFS будет в порядке, пул с точки зрения ZFS будет в порядке, но данные удаленного клиента могут быть испорчены с точки зрения этого клиента аналогично тому, как если бы клиент столкнулся с внезапным сбоем дискового ввода-вывода и записи были бы утеряны? == пул будет в порядке, клиент может потерять/неконсистентные данные и может понадобиться помощь для восстановления, как при любом другом сбое дискового ввода-вывода или сбое системы?

Да, по сути жесткое выключение питания ВМ вместо чистого завершения работы, а затем получение снимка — если включить его позже, fsck или подобное в зависимости от файловой системы будет запущено, и оно может жаловаться на некорректное выключение. Это в отличие от снимков ESXi, которые возобновляются в точке времени, как будто ничего не произошло, но им требуется взаимодействие с гостевой системой (установлены гостевые дополнения) и включают виртуальную память ВМ.

Вы можете совместите оба в вашу пользу: сначала возьмите снимок ESXi, затем после этого снимайте снимок ZFS хранилища данных (ESXi хранит свои снимки наряду с ВМ). Затем удалите свой снимок ESXi, но сохраните снимок ZFS (занимает гораздо меньше места из-за копий на уровне блоков). При восстановлении сперва восстановите снимок ZFS, а затем откатите к вашему (сохраненному) снимку ESXi, и вы возобновите там, где прекратили. napp-it (отличная система управления ZFS с веб-интерфейсом) имеет эту концепцию встроенной (по крайней мере для NFS хранилищ данных, я не проверял iSCSI, но предполагаю, что это аналогично).