Я рассматриваю возможность перехода с ext3 на ZFS для хранения данных на моем хосте Debian Linux, используя ZFS в Linux. Одна убийственная особенность ZFS, которую я действительно хочу, - это гарантии целостности данных. Я с нетерпением жду возможности тривиального увеличения хранилища по мере увеличения моих потребностей в хранилище.
Однако я также запускаю несколько виртуальных машин на одном хосте. (Хотя обычно в моем случае на хосте одновременно работает только одна виртуальная машина.)
Учитывая поведение контрольной суммы данных и копирования при записи ZFS, а также тот факт, что образы дисков виртуальной машины представляют собой сравнительно большие файлы (размер файла образа диска моей основной виртуальной машины в настоящее время составляет 31 ГБ), каковы последствия такой миграции для производительности гостевой виртуальной машины? Какие шаги я могу предпринять, чтобы уменьшить возможное негативное влияние на производительность?
Я могу жить с меньшими гарантиями целостности данных на образах дисков ВМ, если это необходимо (я не делаю ничего критически важного внутри любой из ВМ) и могу легко отделить их от остальной файловой системы, но было бы неплохо, если бы я Мне не нужно (даже выборочно) отключать в значительной степени функцию, которая больше всего заставляет меня переходить на другую файловую систему.
Аппаратное обеспечение довольно мощное для системы класса рабочих станций, но не сравнится с высокопроизводительным сервером (32 ГБ ОЗУ, редко используется> 10 ГБ, 6-ядерный процессор с тактовой частотой 3,3 ГГц, в настоящее время можно использовать 2,6 ТБ дисковое пространство согласно df и всего около 1,1 ТБ бесплатно; переход на ZFS, скорее всего, добавить еще немного свободного места), и я не планирую запускать дедупликацию данных (поскольку включение дедупликации в моей ситуации ничего не изменит). Планируется начать с конфигурации JBOD (очевидно, с хорошими резервными копиями), но в конечном итоге я могу перейти к настройке двустороннего зеркала, если того потребуют условия.
ZFS на приличном (например, усиленном) оборудовании, вероятно, будет быстрее, чем другие файловые системы, вы, вероятно, захотите создать ZIL в быстром (например, SSD) месте. По сути, это место для кеширования записей (ну, больше похоже на журнал в ext3 / 4). Это позволяет box ack записывать данные как записываемые на диск до того, как фактические шпиндели получат данные.
Вы также можете создать L2 ARC на SSD для кеширования чтения. Это фантастика в среде виртуальных машин, где вы можете поставить физические диски на колени, загрузив несколько виртуальных машин одновременно.
Диски входят в VDEV, VDEV входят в zpools (пожалуйста, используйте диски целиком). Если это меньшая система, вам может потребоваться один zpool и (если вас не слишком беспокоит потеря данных) один VDEV. VDEV - это то место, где вы выбираете уровень RAID (хотя вы также можете MIRROR VDEV, если у вас достаточно дисков). Самый медленный диск в VDEV определяет, насколько быстрым будет весь VDEV.
ZFS - это целостность данных - причина того, что многие традиционные инструменты для обслуживания файловой системы (например, fsck) не существуют, заключается в том, что проблема, которую они решают, не может существовать в файловой системе ZFS.
ИМО, самый большой недостаток ZFS заключается в том, что если ваша файловая система приближается к полной (скажем, 75% +), она становится ОЧЕНЬ медленной. Только не ходи туда.
Поскольку ZFS работает на уровне блоков, размер файлов не имеет значения. ZFS требует больше памяти и ЦП, но по своей сути не намного медленнее файловой системы. Хотя вы должны знать, что RAIDZ не эквивалентен по скорости RAID5. RAID10 хорош там, где скорость является приоритетом.
31 ГБ на самом деле совсем не большой ...
В любом случае, в зависимости от файловой системы, которую вы используете в настоящее время, вы можете обнаружить, что ZFS немного медленнее, но с учетом характеристик вашего оборудования она может быть незначительной.
Очевидно, что ZFS будет использовать хороший кусок ОЗУ для кэширования, что может сделать ваши виртуальные машины более быстрыми при обычном использовании (когда не выполняете тяжелое чтение или запись). Я не уверен, как ZFS настроен в Linux, но вы может необходимо ограничить его ARC, если это возможно, чтобы он не убегал со всей вашей оперативной памятью (поскольку вам понадобится приличный кусок, оставшийся для вашей хост-системы и виртуальных машин).
Я бы включил сжатие (в наши дни советуют включать его, если у вас нет веской причины не делать этого). Помните, что это нужно сделать перед размещение данных в файловой системе. Большинство людей удивляются, обнаружив, что с ним он работает быстрее, поскольку алгоритмы сжатия обычно работают быстрее, чем дисковый ввод-вывод. Я сомневаюсь, что это вызовет серьезные проблемы с производительностью вашего 6-ядерного процессора. Я не ожидал, что виртуальные машины будут сильно сжиматься, но мне удалось превратить ~ 470 ГБ данных виртуальной машины в 304 ГБ только с настройкой сжатия по умолчанию.
Не беспокойтесь о дедупликации, он просто вернется, чтобы преследовать вас позже, и вы потратите недели, перетасовывая данные, пытаясь избавиться от него.
Если вы столкнетесь с проблемами производительности, очевидный ответ - добавить SSD как ZIL / L2ARC или даже оба. Не идеально использовать одно устройство для обоих, но, скорее всего, это все равно повысит производительность в пуле, содержащем небольшое количество дисков / vdev.
Чтобы добавить: я бы действительно попытался начать с избыточной конфигурации, если возможно (в идеале с зеркалами), или преобразовать в зеркала из полосы как можно скорее. Хотя ZFS будет проверять все данные и обнаруживать ошибки на лету (или во время очистки), она не сможет ничего с этим поделать (без использования copy = 2, что удвоит использование диска). Вы просто останетесь с сообщением об ошибках в файлах (возможно, в образах дисков виртуальной машины), с которыми вы не сможете многое сделать, не удаляя и не создавая заново эти файлы.
В зависимости от ваших вариантов использования и виртуальных машин я бы рассмотрел следующее. Пусть операционная система хоста позаботится о файлах, которые вы храните в томах ZFS.
Если возможно, создайте только LUN для каждой виртуальной машины, содержащую только операционную систему и необходимые двоичные файлы. И представьте хранилище для индивидуальных данных в виде общих ресурсов через NFS, samba или iSCSI (или zvols, как указано в комментариях). ZFS может отслеживать каждый файл с помощью контрольной суммы и времени доступа и т. Д. Конечно, если скорость не так важна, вы также можете включить сжатие в некоторых хранилищах данных. Преимущество заключается в отсутствии слоя другой файловой системы. Если вы создадите LUN для второго виртуального жесткого диска и создадите файловую систему NTFS поверх него, ZFS придется обрабатывать большой двоичный двоичный объект, который не знает ни содержимого, ни файлов, и, следовательно, не может использовать кеш ZIL или ARC в так же, как и файлы самолета.
Упомянув ACL, ZFS может использовать ACL через NFSv4 или Samba (если включено). Я должен признать, что использую ZFS на FreeBSD, и не могу точно сказать, как включить Sambas ACL, сопряженные с томами ZFS. Но я уверен, что это не должно иметь большого значения.
Дедупликация в сочетании с кешем чтения является большим преимуществом, когда дело доходит до экономии места и улучшения массового чтения (Boot Storm), поскольку все виртуальные машины начинают читать одни и те же блоки.
То же самое касается моментальных снимков ZFS для виртуальных машин и хранилищ данных. Вы можете создать простой сценарий оболочки, чтобы заморозить виртуальную машину, сделать снимок виртуальной машины и хранилища данных и продолжить работу, или просто только хранилище данных, и клонировать виртуальную машину, представляющую моментальный снимок исходной и протестировать некоторые вещи.
Возможности ZFS безграничны;)
РЕДАКТИРОВАТЬ: Надеюсь, теперь я объяснил это немного лучше
РЕДАКТИРОВАТЬ2: Личное мнение: подумайте об использовании RAIDZ2 (RAID6), так как вы можете выдержать двойной отказ диска! Если у вас остался один запасной диск, это никогда не будет ошибкой, но двух отказов диска должно хватить для быстрого реагирования. Я просто выложил свой скрипт для мониторинга статуса диска Вот