Я использую Nexentastor на вторичном сервере хранения, работающем на HP ProLiant DL180 G6 с 12 дисками Midline (7200 об / мин) SAS. Система имеет процессор E5620 и 8 ГБ оперативной памяти. Нет устройства ЗИЛ или L2ARC.
На прошлой неделе я создал разреженный zvol емкостью 750 ГБ с включенными дедупликацией и сжатием для совместного использования через iSCSI на хосте VMWare ESX. Затем я создал образ файлового сервера Windows 2008 и скопировал на виртуальную машину ~ 300 ГБ пользовательских данных. Убедившись в системе, я переместил виртуальную машину в хранилище NFS в том же пуле.
После запуска и работы с моими виртуальными машинами в хранилище данных NFS я решил удалить исходный файл zvol. Это остановило систему. Доступ к веб-интерфейсу Nexenta и NMC остановлен. В конце концов я смог добраться до сырой оболочки. Большинство операций ОС выполнялись нормально, но система зависала zfs destroy -r vol1/filesystem команда. Некрасиво. Я нашел следующие две записи об ошибке OpenSolaris и теперь понимаю, что машина будет заблокирована на неизвестный период времени. Прошло 14 часов, поэтому мне нужен план, чтобы восстановить доступ к серверу.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390
и
В будущем я, вероятно, воспользуюсь советом, данным в одном из обходных путей buzilla:
Workaround
Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.
Обновление: мне пришлось принудительно выключить систему. После перезагрузки система останавливается на Importing zfs filesystems. Так уже 2 часа.
Это было решено. Ключевым моментом является то, что для дедуплицированных томов перед удалением необходимо отключить флаг дедупликации. Это должно быть сделано на уровне пула, а также на уровне zvol или файловой системы. В противном случае удаление фактически дедуплицируется. Этот процесс требует времени, так как имеется ссылка на таблицу дедупликации ZFS. В этом случае помогает оперативная память. Я временно добавил в систему 16 дополнительных гигабайт оперативной памяти и вернул сервер в оперативный режим. Зпул импортирован полностью за 4 часа.
Мораль, вероятно, заключается в том, что дедупликация не слишком отполирована и что оперативная память важна для ее производительности. Я предлагаю 24 ГБ или больше, в зависимости от среды. В противном случае оставьте функцию дедупликации ZFS выключенной. Это определенно нецелесообразно для домашних пользователей или небольших систем.
Как давний пользователь устройств Sun / Oracle ZFS серии 7000, я могу без вопросов сказать вам, что дедупликация не отточена. Никогда не путайте продажи с доставкой! Продавцы скажут вам: «О, это исправлено». В реальной жизни - в моей реальной жизни - я могу сказать вам, что 24 ГБ недостаточно для обработки «таблиц ДДТ». То есть внутренний индекс, в котором хранится таблица дедупликации. Эта таблица должна находиться в системной памяти, чтобы каждый ввод-вывод перехватывался на лету, чтобы выяснить, нужно ли его записывать на диск или нет. Чем больше ваш пул хранения, тем больше данных изменяется, тем больше эта таблица и тем выше потребность в системной памяти. Эта память поступает за счет ARC (кеша), а иногда и самой ОС - вот почему вы испытываете зависания, поскольку определенные команды выполняются на переднем плане, а некоторые - в фоновом. Кажется, что удаление пула происходит на переднем плане, если вы не укажете иное в CLI. Мастера GUI этого не сделают.
Даже массовое удаление данных NFS в общей папке, определенной на дедуплицированном томе, доведет вашу систему до половины, если у вас недостаточно памяти для обработки «записей» в ZFS, сообщающих ей об удалении данных.
В общем, если вы не исчерпаете свою память и даже тогда не найдете способ зарезервировать память для ОС, ограничив ARC и DDT (и я не думаю, что вы можете ограничить DDT по своей природе, это просто индекс, привязанный точно к вашему вводу / выводу) - тогда вы попадаете во время больших удалений или десторирования zvol / pool.