У нас есть оптоволоконный канал san, управляемый двумя серверами OpenSolaris 2009.06 NFS.
Медленный сервер на 50 ТБ был установлен несколько месяцев назад и работал нормально. Юзеры залили 2ТБ. Я провел небольшой эксперимент (создал 1000 файловых систем и имел по 24 снимка на каждой). Все, что касается создания, доступа к файловым системам с помощью моментальных снимков и монтирования некоторых из них по NFS.
Когда я попытался уничтожить 1000 файловых систем, первая fs заняла несколько минут, а затем не удалось сообщить, что fs использовалась. Я выдал сообщение о выключении системы, но это заняло более 10 минут. Я не стал ждать дольше и выключил питание.
Теперь при загрузке OpenSolaris зависает. Индикаторы на 32 дисках быстро мигают. Я оставил его на 24 часа - все еще мигает, но нет прогресса.
Я загрузился в системный снимок до создания zpool и попробовал импортировать zpool.
pfexec zpool import bigdata
Такая же ситуация: мигают светодиоды и импорт зависает навсегда.
При отслеживании процесса "zpool import" отображается только системный вызов ioctl:
dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'
ioctl 2499
Есть способ исправить это? Редактировать: Да. Обновление OpenSolaris до svn_134b помогло:
pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6
Теперь у меня zfs версии 3. Bigdata zpool остается в версии 14. И он снова в производстве!
Но что он делал с тяжелым доступом к вводу-выводу более 24 часов (до обновления программного обеспечения)?
С ZFS вы действительно хотите, чтобы он напрямую управлял дисками, поскольку это улучшает параллелизм. Единственный диск на 50 ТБ, который вы ему дали, - это точка удушья.
Этот сценарий DTrace отслеживает только системные вызовы. Настоящее действие происходит внутри ядра, и если вы хотите увидеть, что потребляет большую часть ЦП, используйте сценарий 'hotkernel' из DTrace Toolkit.
Когда вы импортируете пул, ZFS считывает конфигурацию с диска и проверяет ее. После того, как пул будет импортирован, он начнет монтировать все те файловые системы и моментальные снимки 1000, которые вы создали. Это может занять некоторое время. Если бы у вас была включена дедупликация (чего вы не сделали, так как вы использовали snv_111), это заняло бы еще больше времени, так как она должна загрузить таблицу дедупликации (DDT).
Выключение системы никогда не является хорошим вариантом, особенно для OpenSolaris snv_111. Вы не опубликовали конфигурацию пула (статус zpool), но, если у вас есть тяжелые устройства, и они не работают, вы не сможете импортировать пул (это было недавно решено в Solaris 11 Express snv_151a).
Я советую экспортировать каждый из 32 дисков по отдельности и создать несколько raidz2 vdev, чтобы у вас было больше головок для чтения / записи. Не создавайте огромные vdev с> 8 дисками, потому что производительность будет ужасной.
Если вы не можете позволить себе отключать систему так долго (большинство людей этого не делают), внимательно изучите снимки файловой системы ZFS и способы их репликации на удаленный сервер с помощью zfs send / receive. Это позволит вам быстро запустить отказоустойчивый сервер.
'zfs import' - это более или менее просто чтение конфигурации ваших vdev (из 'zpool.cache') напрямую. Я предполагаю, что для завершения здесь требовалась вечность, так это ваша транзакция удаления.
Учитывая, что ZFS является транзакционной и что вы удалили 1000 файловых систем, каждая из которых содержит 24 снимка, у вас было очень интенсивное удаление, необходимое для проверки ссылочных указателей на 24 000 снимков. Учитывая время поиска этих головок SATA и все обновления дерева, которые необходимо было сделать.