ZFS внутри виртуальной машины
Следует ли мне использовать ZFS внутри виртуальной машины? Согласно существующей информации (в частности, этот поток , который я процитирую ниже) это не лучшая идея, если не предусмотрены определенные меры (например, использование VT-d). Основная проблема якобы заключается в том, что гипервизор может сообщать о блок должен быть записан, хотя на самом деле он еще не был написан.Якобы ZFS особенно чувствительна к такому несоответствию по сравнению с другими файловыми системами:
Особенности того, почему это так плохо, связаны с его дизайном без fsck.
В этом обсуждении также было признано, что:
Единственный сценарий, в котором «указатель, записанный до данных» превращается в «указатель записан, но данные отсутствуют», по-прежнему является событием сбоя ОС или гипервизора, насколько это возможно. Могу представить.
Но каковы худшие последствия в случае такой аварии?
- Повреждение или потеря файлов, записанных во время сбоя?
- Повреждение или потеря любого другого файла в наборе данных?
- Повреждение или потеря любого файла в наборе данных, который не был изменен во время сбоя, например, моментального снимка, который был сделан задолго до сбоя?
Возможно ли какое-либо скрытое повреждение, которое не может быть обнаружено с помощью скраба?
Я попытался смоделировать сбой, используя VirtualBox и выбрав Close / Power Off, когда данные были записаны в ZFS внутри виртуальной машины. Я проделал это примерно 20 раз, но не смог обнаружить никаких проблем. Возможно, этот метод тестирования не подходит. Есть ли лучшие способы поэкспериментировать с этим?
Практически любой современный гипервизор (VMWare, Xen, KVM, HyperV, даже VirtualBox) поддерживает прохождение барьера: когда виртуальная машина явно сбрасывает что-то на диск (с помощью барьера / FUA), гипервизор будет передать барьер вниз к хосту, заставляя те же сбросы, которые выполняются гостевой ОС. Другими словами, никаких повреждений не ожидается для важных / длительных операций записи (как та, которая используется самой файловой системой для обновления своих метаданных).
Хотя большинство гипервизоров можно настроить на игнорирование сбросов, это может поставить под угрозу любую ] файловые системы - XFS, EXT4 и т. д. будут подвержены серьезным повреждениям не меньше, чем ZFS.
Вернемся к основному вопросу: использовать ZFS внутри гостевой ОС совершенно безопасно, и у меня есть личный опыт работы с подобными настроить. Это позволит гостю использовать расширенные функции, такие как сжатие, моментальные снимки и отправка / получение. Однако это может привести к несколько более низкой производительности гостевой системы (ZFS не предназначена для использования в качестве файловой системы, победившей в тестах). Более того, поскольку многие сети SAN реализуют одни и те же функции на уровне образа диска, вам следует оценить, стоит ли влияние на производительность из-за двойного CoW дополнительной гибкости на уровне гостя.
По причинам, указанным выше, я обычно использую ZFS. на уровне образа диска / гипервизора при использовании XFS или EXT4 внутри самих виртуальных машин. Однако в сценарии, когда у меня нет видимости базового SAN / хранилища (и его политик моментальных снимков / сжатия / репликации), я иногда использую ZFS на гостевом уровне.
В этих случаях добавленные функции более чем компенсируют производительность воздействие по сравнению, например, с простой настройкой XFS. И у меня вообще нет проблем со стабильностью / долговечностью.
Примечание: VT-d полезен только в том случае, если вы планируете передавать необработанные диски (или другие аппаратные устройства) самому гостю. Если вы используете виртуальный диск на основе файла или тома, вы не используете VT-d.