Вопрос: zpool import на томе 50 ТБ берет навсегда: что он делает?


У нас есть канал волоконных каналов, управляемый двумя серверами NFS OpenSolaris 2009.06.

  • Сервер 1 управляет 3-мя небольшими томами (300 ГБ приводов на 15 Кбит / с). Он работает как шарм.
  • Сервер 2 управляет 1 большим объемом 32 дисков (2TB 7200 RPM приводов) RAID6. Общий размер составляет 50 ТБ.
  • Оба сервера имеют Zpool версии 14 и ZFS версии 3.

Медленный сервер 50TB был установлен несколько месяцев назад и работал нормально. Пользователи заполнены 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 часов (до обновления программного обеспечения)?


5
2017-12-17 17:23


Источник


Я обновляюсь до последнего OpenSolaris. После первой части maverick.homelinux.net/blog/?p=270 - Aleksandr Levchuk
Как-то после обновления программного обеспечения bigdata был установлен. Оно работает! Я до сих пор не знаю, что это такое, что заняло более 24 часов, поэтому вопрос остается открытым. - Aleksandr Levchuk
После обновления все начало работать. zpool import работали быстро, но большинство из 1000 файловых систем были там. Я побежал zpool destroy -r - это заняло около 5 секунд за fs. Скрипт, который запускает все 1000 параллельно, занял 2 минуты. - Aleksandr Levchuk


Ответы:


С ZFS вы действительно хотите позволить ему напрямую манипулировать дисками, поскольку это улучшает параллелизм. Единственный диск с 50 ТБ, который вы ему дали, является точкой удушья.

Этот скрипт DTrace отслеживает только системные вызовы. Реальное действие происходит внутри ядра, и если вы хотите увидеть, что потребляет большую часть процессора, используйте сценарий «hotkernel» из набора DTrace Toolkit.

Когда вы импортируете пул, ZFS считывает конфигурацию с диска и проверяет его. После того как пул будет импортирован, он начнет монтировать все эти файловые системы 1000 и созданные моментальные снимки. Это может занять некоторое время. Если вы включили функцию дедупликации (с которой вы не пользуетесь snv_111), потребуется больше времени, так как она должна загружать таблицу дедупликации (DDT).

Выключение системы никогда не будет хорошим вариантом, особенно на OpenSolaris snv_111. Вы не указали конфигурацию своего пула (статус zpool), но если у вас есть устройства slog и они не работают, вы не сможете импортировать пул (это было недавно рассмотрено в Solaris 11 Express snv_151a).

Мой совет заключается в том, что вы экспортируете каждый из 32 дисков по отдельности и создаете несколько raidz2 vdev, чтобы у вас было больше голов читать / писать. Не создавайте огромные vdev с> 8 дисками, потому что производительность будет ужасной.

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


4
2017-12-18 10:09





'zfs import' более или менее просто вернул конфигурацию ваших vdevs (из «zpool.cache») напрямую. Я догадываюсь, что навечно заканчивалось, это была ваша транзакция удаления.

Учитывая, что ZFS является транзакционным, и что вы удалили 1000 файловых систем, каждый из которых имеет 24 моментальных снимка, у вас было очень интенсивное удаление, необходимое для проверки ссылочных указателей на 24 000 снимков. Учитывая время поиска этих глав SATA и все обновления деревьев, которые необходимо выполнить.


1
2017-12-17 21:52



+1 Спасибо! Звучит разумно, но есть одно противоречие. Я запускал 1000 zfs destroy s последовательно - я отключил питание перед первым destroy имел шанс закончить, и zfs не знал, что я хотел destroy 999 больше. - Aleksandr Levchuk