Каковы последствия производительности виртуальных машин на хосте ZFS?

Я подумываю о переходе с ext3 на ZFS для хранения данных на моем хосте Debian Linux с использованием ZFS в Linux . Одна из важнейших особенностей ZFS, которая мне действительно нужна, - это гарантия целостности данных. Я бы с нетерпением ждал возможности тривиально наращивать объем хранилища по мере увеличения потребностей в хранилище.

Тем не менее, я также запускаю несколько виртуальных машин на одном хосте. (Хотя обычно в моем случае на хосте одновременно работает только одна виртуальная машина.)

Принимая во внимание контрольную сумму данных ZFS и поведение копирования при записи, а также тот факт, что образы дисков виртуальных машин являются сравнительно большими файлами (в настоящее время размер образа диска моей основной виртуальной машины составляет 31 ГБ), каковы последствия производительности для гостевой виртуальной машины такого миграция? Какие шаги я могу предпринять, чтобы уменьшить возможное негативное влияние на производительность?

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

Аппаратные средства довольно сложны для системы класса рабочей станции, но не будут в значительной степени уступать высокопроизводительному серверу (32 ГБ ОЗУ с редко используемым> 10 ГБ, 6-ядерный процессор 3,3 ГГц, в настоящее время используется 2,6 ТБ). свободного места на диске dfи в общей сложности около 1,1 ТБ; переход на ZFS, скорее всего, добавит еще немного свободного места ), и я не планирую запускать дедупликацию данных (так как включение дедупликации просто не добавит много в моей ситуации). План состоит в том, чтобы начать с конфигурации JBOD (очевидно, с хорошим резервным копированием), но я могу в конечном итоге перейти к настройке двустороннего зеркала, если этого потребуют условия.

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

ZFS на приличном (то есть, усиленном) оборудовании, вероятно, будет быстрее, чем другие файловые системы, вы, вероятно, захотите создать ZIL в быстром (т. Е. SSD) месте. По сути, это место для кэширования записей (ну, больше похоже на журнал в ext3 / 4). Это позволяет коробке ack записывать как записываемые на диск до того, как фактические шпиндели получат данные.

Вы также можете создать L2 ARC на SSD для кэша чтения. Это замечательно в среде виртуальных машин, где вы можете поставить физические диски на колени, загрузив несколько виртуальных машин одновременно.

Диски попадают в VDEV, VDEV - в zpools (пожалуйста, используйте целые диски за раз). Если это небольшая система, вам может потребоваться один zpool и (если вас не слишком беспокоит потеря данных) один VDEV. VDEV - это место, где вы выбираете уровень RAID (хотя вы также можете использовать MIRROR VDEV, если у вас достаточно дисков). Самый медленный диск в VDEV определяет, насколько быстрым является весь VDEV.

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

IMO самый большой недостаток ZFS в том, что если ваша файловая система заполнена (скажем, 75% +), она становится ОЧЕНЬ медленной Просто не ходи туда.

31ГБ действительно совсем не большой ...

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

Очевидно, что ZFS будет использовать хороший кусок оперативной памяти для кэширования, что может сделать ваши виртуальные машины более «быстрыми» в общем случае (если вы не заняты чтением или записью). Я не уверен в том, как настроена ZFS в Linux, но вам, возможно, придется ограничить ARC, если это возможно, чтобы он не ушел со всей вашей оперативной памятью (учитывая, что вам понадобится приличный кусок памяти для вашей хост-системы и виртуальные машины).

Я бы включил сжатие (в наши дни советую включать его, если у вас нет веских причин не делать этого). Помните, что это должно быть сделано до помещения данных в файловую систему. Большинство людей удивляются, обнаружив, что на самом деле это происходит быстрее, поскольку алгоритмы сжатия обычно работают быстрее, чем дисковый ввод-вывод. Я сомневаюсь, что это вызовет большую проблему с производительностью вашего 6-ядерного процессора. Я не ожидал, что виртуальные машины будут сильно сжимать, но мне удалось превратить ~ 470 ГБ данных виртуальной машины в 304 ГБ только с настройкой сжатия по умолчанию.

Не беспокойтесь о дедупликации, позже она снова станет преследовать вас, и вы потратите недели на перестановки данных, пытаясь от них избавиться.

Если вы сталкиваетесь с проблемами производительности, то очевидный ответ - добавить SSD как ZIL / L2ARC или даже оба. Не идеально использовать одно устройство для обоих, но, скорее всего, оно все же улучшит производительность в пуле, содержащем небольшое количество дисков / vdevs.

Чтобы добавить: я действительно попытался бы начать с избыточной конфигурации, если это возможно (в идеале зеркала), или преобразовать в зеркала с полосы как можно скорее. Хотя ZFS будет проверять все данные и обнаруживать ошибки на лету (или во время очистки), она не сможет ничего с этим поделать (без использования copy = 2, которое удвоит использование диска). Вам останется только сказать, что в файлах есть ошибки (возможно, образы дисков вашей виртуальной машины), с которыми вы не сможете справиться без удаления и повторного создания этих файлов.

В зависимости от ваших вариантов использования и виртуальных машин, я бы рассмотрел следующее. Позвольте операционной системе хоста позаботиться о файлах, которые вы храните в томах ZFS.

Если возможно, создайте только LUN для каждой виртуальной машины, содержащей только операционную систему и необходимые двоичные файлы. И представить хранилище для отдельных данных как общие ресурсы через NFS, samba или iSCSI (или zvols, как указано в комментариях). ZFS может отслеживать каждый файл с помощью контрольной суммы и времени доступа и т. Д. Конечно, если скорость не так важна, вы также можете включить сжатие в некоторых хранилищах данных. Преимущество будет отсутствующим слоем другой файловой системы. Если вы создадите LUN ​​для второго Virtual Harddrive и создадите файловую систему NTFS поверх этого, ZFS должна обработать большой двоичный двоичный объект, который не знает ни содержимого, ни файлов, и поэтому не может использовать кэш ZIL или ARC в так же, как файлы самолета.

Упоминая ACL, ZFS может использовать ACL через NFSv4 или Samba (если включено). Я признаю, что использую ZFS во FreeBSD, и не могу гарантировать, как включить Sambas ACL, сопрягающиеся с томами ZFS. Но я уверен, что это не должно иметь большого значения.

Дедупликация в сочетании с кэшем чтения является большим преимуществом, когда речь идет об экономии места и улучшении массового чтения (Boot storm), поскольку все виртуальные машины начинают читать одни и те же блоки.

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

Возможности безграничны с ZFS;)

РЕДАКТИРОВАТЬ: Надеюсь, я объяснил это немного лучше, сейчас

РЕДАКТИРОВАТЬ 2: Личное мнение: рассмотрите возможность использования RAIDZ2 (RAID6), так как вы можете выдержать двойной сбой диска! Если у вас остался один запасной диск, он никогда не будет ошибаться, но двух быстрых отказов диска должно быть достаточно для быстрого реагирования. Я просто постет свой скрипт для мониторинга состояния диска здесь