Мы храним файлы на FreeNAS 9.2 с помощью ZFS. Мне нравятся заявления о целостности данных, сделанные ZFS, поскольку в прошлом они случайно теряли данные на серверах, использующих ext3, XFS и ReiserFS, которые не подвергались жестокому обращению (отключение электроэнергии и т. Д.). Это было редко, но катастрофически, когда серверу требовалась перезагрузка, запускалась fsck и обнаруживалась масса ошибок.
Мы также используем этот же NAS в качестве целевого хранилища для виртуальных машин XenServer. Сначала я думал о том, как приятно иметь наши виртуальные машины с поддержкой ZFS, но теперь я подозреваю, что целостность действительно является доказательством отказа.
Если виртуальный диск виртуальной машины - это просто большой файл, содержащий ее собственную файловую систему (предположим, что по умолчанию рекомендуется ext4), то что предотвращает его повреждение в пределах этот виртуальный диск? Возможно, сетевой кабель вышел из строя и iSCSI не знает, что получил несколько неверных байтов для хранения (устойчиво в ZFS)? Я предполагаю, что между виртуальной машиной и общим хранилищем могут возникать и другие возможные сбои, которые «доверяющая» файловая система не обнаружит. Единственное решение - также использовать файловую систему с исправлением ошибок в виртуальной машине, такую как ZFS или btrfs?
Извините, ничто не мешает этому случиться с вашими гостями.
Защитите свою окружающую среду!
И черт возьми, даже в-ВМ В файловых системах ZFS могут возникать проблемы.
Every 3.0s: zpool status -v Fri Dec 27 12:49:47 2013
pool: vol1
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://zfsonlinux.org/msg/ZFS-8000-8A
scan: scrub in progress since Fri Dec 27 12:35:06 2013
42.1G scanned out of 46.3G at 48.9M/s, 0h1m to go
0 repaired, 90.80% done
config:
NAME STATE READ WRITE CKSUM
vol1 ONLINE 0 0 167
sdb ONLINE 0 0 448
errors: Permanent errors have been detected in the following files:
<metadata>:<0x67>
<metadata>:<0x6f>
<metadata>:<0x8e>
vol1/ppro:/isam/IM00013.ISI
vol1/ppro:/isam/IM00014.ISI
vol1/ppro:/isam/IM00015.ISI
vol1/ppro:/isam/IM00016.ISI