Если я сделаю что-то вроде RAIDZ2 с 10 или около того дисками, то в гостевых операционных системах, если я использую файловую систему, например ext3 / 4, будет ли гостевая файловая система такой же безопасной, как если бы она также использовала ZFS?
Причина, по которой я спрашиваю, заключается в том, что после прочтения некоторых рекомендуется, чтобы при использовании ZFS у вас было 1 ГБ ОЗУ на 1 ТБ хранилища (в итоге у меня будет около 20-40 ТБ). Если у меня ZFS и на хосте, и на гостях, мне потребуется вдвое больше ОЗУ.
Да и нет. Если у вас есть ZFS внизу, а затем создайте zvols и предложите их с использованием блочного протокола - или - вы предлагаете протокол на уровне файлов (NFS, CIFS) и создаете файлы как диски (.vmdk, .vhd и т. Д.) , вы получаете некоторую безопасность, но часто клиент (в данном случае операционная система виртуальной машины) не обязательно настроен по умолчанию таким образом, чтобы теперь вы были защищены так, как вы могли ожидать.
Причина этого в том, что во многих настройках файловых систем по умолчанию предпочтение отдается производительности, иногда в ущерб безопасности. Вот почему даже при использовании локального жесткого диска машине Windows может потребоваться выполнить CHKDSK после внезапного отключения питания (и аналогично Linux может потребоваться выполнение команды fsck). Вам нужно будет поискать ОС и рассматриваемую файловую систему, чтобы определить, какие изменения, если таковые имеются, вам необходимо внести в нее, чтобы заставить ее более регулярно синхронизироваться с ее базовым диском и / или включить любое ведение журнала, которое файловая система поддерживает.
Кроме того, параметры, которые вы используете от клиента (ОС виртуальной машины) до сервера (ZFS) по используемому вами протоколу, также имеют некоторое влияние. Один из наиболее печально известных - это iSCSI через COMSTAR для производных от Illumos / Solaris. По умолчанию для большинства из них «КОМСТАР» устанавливает новые LU с включенным «кешем записи». Это, по умолчанию, не будет передавать все входящие операции ввода-вывода в ZFS как синхронизирующие, а вместо этого будет делать это только в том случае, если клиент (ОС виртуальной машины) специально пометил как таковой. В зависимости от других настроек довольно часто операционная система виртуальной машины передает / не передает все свои операции ввода-вывода в качестве синхронизации, поэтому она не переходит в ZFS в качестве синхронизации, поэтому она не использует дисковую механику ZIL, и, следовательно, вы не застрахованы от событий потери питания.
Основная проблема здесь в том, что, хотя сама ZFS предназначена для защиты от повреждений и буквально не имеет даже утилиты в стиле fsck, поскольку ZFS, как правило, не может `` повредить '' себя, эта логика не обязательно справедливо для файловых систем внутри .vmdk или zvols, если эти файловые системы верхнего уровня не синхронизируют каждый ввод-вывод на диск, как только они его получают (а параметры по умолчанию редко делают это). Это также не будет выполняться, если ваша настройка ZFS не использует ZIL (например, потому что вы его отключили) или ваше базовое хранилище, на котором находится ZFS, игнорирует или не отправляет команды очистки кеша (например, потому что вы сказал ZFS не делать этого). В этих сценариях ZFS всегда должна быть согласованной на диске, но проблема в том, что после сбоя питания, когда он возвращается, он будет согласованным с 'X' секунд назад - он загрузится без повреждений в ZFS, но будет как дела были 5-30 секунд назад. Это нормально для ZFS, но, возможно, не так хорошо для файловой системы внутри этих файлов zvols / disks-as-files (.vmdk). Этот 5-секундный «откат», если хотите, мог быть критически важными метаданными для файловой системы внутри этого .vmdk, и он становится сломанным или даже не загружается на более высоком уровне. Между тем ZFS по-прежнему считает, что все в порядке.
Чтобы ваша ОС верхнего уровня была максимально безопасной, должны выполняться все следующие условия:
Если файловая система вашей клиентской ОС не сдерживает записи, нет посредника, потребляющего ваши запросы данных синхронизации, а ZFS как задняя часть настроена правильно для синхронизации и сама находится в надлежащем хранилище, в этот момент вы должны иметь все ожидания, что любое событие потери питания будет иметь минимальное влияние на файловые системы виртуальной машины. В худшем случае им понадобится быстрый chkdsk / fsck при загрузке, если даже это, и никогда не должно быть значительно повреждено или полностью потеряно. Чем больше из приведенного выше списка не соответствует действительности, тем выше вероятность значительного повреждения.
Как всегда, я должен также упомянуть, СОХРАНИТЕ РЕЗЕРВНЫЕ КОПИИ. Даже если вы сделаете все вышеперечисленное и создадите среду, полностью защищенную от потери питания, ничто из этого не защитит вас от вирусов на виртуальных машинах, хакеров, ошибки, совершенной через 36 часов бодрствования, недовольного сотрудника, серьезного проблемы с оборудованием или (не) стихийные бедствия.
RAID используется только для физических дисков, чтобы предотвратить потерю данных из-за сбоя диска.
RAIDZ2 предоставляет возможности, подобные RAID6, за исключением того, что он работает на уровне файлов, а не на уровне диска. Таким образом, любая защита, предлагаемая RAIDZ2, автоматически распространяется на гостей, когда они являются файлы.