У меня есть NAS-устройство Solaris 11 на базе ZFS с 12 дисками SATA по 1 ТБ со скоростью вращения 7,2 тыс. Об / мин в зеркальной конфигурации.
Он предоставляет 2 службы из одного пула - сервер NFS для небольшой фермы виртуальных машин и сервер CIFS для небольшой группы для размещения общих файлов. В cifs ZFS дедупликация включена, а в файловой системе NFS ZFS дедупликация отключена. Компрессия везде отключена. Я делаю снимки каждой файловой системы каждый день и сохраняю последние 14 снимков.
Я сталкивался с проблемой производительности в тех случаях, когда я перемещаю, копирую или удаляю большой объем данных при прямом подключении к NAS по SSH. По сути, кажется, что процесс блокирует все другие операции ввода-вывода, вплоть до остановки виртуальных машин из-за того, что они получают тайм-ауты диска.
У меня есть несколько теорий относительно того, почему это должно быть так, но я хотел бы получить представление о том, что я могу сделать дальше.
Либо:
1) оборудование недостаточно хорошее. Я не так уверен в этом - система представляет собой HP X1600 (одиночный процессор Xeon) с 30 ГБ оперативной памяти. Несмотря на то, что диски имеют всего лишь 7.2k SATA, они должны выдавать максимум 80 IOPS каждый, что должно дать мне более чем достаточно. Но счастлив, что ошибся.
2) Я неправильно настроил - более чем вероятно. Стоит ли везде отключать дедупликацию? Я работаю в предположении, что RAM = хороша для дедупликации, следовательно, даю разумное количество RAM.
3) Solaris тупо планирует ввод-вывод. Возможно ли, что местный rm команда полностью блокирует ввод-вывод для nfsd? Если да, то как мне это изменить?
При использовании ZFS и моментальных снимков следует помнить, что ничто не является бесплатным, и поскольку вы удаляете большие объемы данных и ожидаете, что моментальные снимки будут продолжать поддерживать эти данные для вас, особенно если у вас есть большое количество снимков, когда вы проводите ваши удаления, снимки должны быть обновлены соответствующим образом, чтобы отразить изменения в файловой системе. Я предполагаю, что у вас есть 6 VDEV, в основном 6 зеркал в пуле, что означает, что вам действительно нужно выполнить эти изменения для всех дисков, поскольку данные довольно равномерно распределены по каждому VDEV. При включенной дедупликации ситуация значительно усложняется, особенно если соотношение хорошее, а если соотношение плохое, не используйте его. По сути, если соотношение хорошее или отличное, у вас есть большое количество ссылок, все из которых, конечно же, являются метаданными, и все они должны быть обновлены вместе со снимками и метаданными, связанными со снимками. Если ваши файловые системы имеют небольшой размер блоков, ситуация становится еще более сложной, потому что количество ссылок. намного больше для набора данных размером 4 КБ по сравнению с набором данных 128 КБ.
В принципе, есть несколько вещей, которые вы можете сделать, кроме: 1) Добавить высокопроизводительные твердотельные накопители в качестве устройств кэширования и настроить файловую систему на использование устройств кэширования только для метаданных, 2) уменьшить количество операций удаления / уничтожения большого объема, 3) повторно рассмотрите возможность использования дедупликации. Но вы не можете просто отключить дедупликацию в пуле или файловой системе. Если этот параметр включен для всего пула, вам придется заново создать пул, или, если он установлен для отдельной файловой системы, уничтожение и повторное создание файловой системы решит проблему.
В Nexenta мы очень осторожны с дедупликацией, когда рекомендуем ее клиентам. Во многих случаях это прекрасное решение, и заказчик не может без него жить. И в этих случаях у нас часто есть клиенты, использующие 96 ГБ ОЗУ или более для поддержки большего количества метаданных и DDT в ОЗУ. Как только метаданные ДДТ отправляются на вращающийся носитель, все буквально останавливается. Надеюсь это поможет.
Вариант №2, скорее всего, причина. Dedup работает лучше всего, когда таблица дедупликации (DDT) полностью умещается в памяти. Если этого не происходит, то он перетекает на диск, и поиск DDT, который должен идти на диск, выполняется очень медленно, что приводит к блокирующему поведению.
Я бы подумал, что 30 ГБ ОЗУ - это достаточно, но размер DDT напрямую зависит от количества данных, подлежащих дедупликации, и от того, насколько хорошо дедупликация работает с вашими данными. Свойство дедупликации устанавливается на уровне набора данных, но поиск выполняется по всему пулу, поэтому существует только один DDT для всего пула.
Видеть эта ветка обсуждения zfs по расчету размера ДДТ. По сути, это одна запись DDT на уникальный блок в пуле, поэтому, если у вас большой объем данных, но низкий коэффициент дедупликации, это означает больше уникальных блоков и, следовательно, больший DDT. Система пытается сохранить ДДТ в ОЗУ, но часть его может быть удалена, если память понадобится для приложений. Наличие кэша L2ARC может помочь предотвратить попадание DDT на диски основного пула, поскольку он будет вытеснен из основной памяти (ARC) в L2ARC.