Назад | Перейти на главную страницу

Рекомендации по созданию производственной 140-дисковой (420 ТБ) ZFS zpool

Мне было поручено построить большой zpool для системы записи данных. Использование ZFS в Linux (0.6.4.2), в CentOS 6.5.

Технические характеристики оборудования:

DL380 Gen8
ОЗУ 80 ГБ
2x HP HBA H221
2x HP D6000, каждый с 70 дисками SAS 3 ТБ каждый

Есть некоторые особые обстоятельства:

О зеркалировании не может быть и речи, нам не хватило бы места для хранения. Общий требуемый объем необходимого ТБ практически установлен. Добавление устройств D6000 невозможно.
В центре обработки данных будет 2 таких zpool, использующих избыточность на уровне приложений. Таким образом, потеря всего пула проблематична, но не критична. Все данные также будут скопированы на ленту.
Использование карт HP Accelerator сейчас не вариант (слишком дорого)
Использование карт PCIe NVMe невозможно из-за ограничений ядра 2.6.32.

Требования к производительности:

Производительность записи не критична, в основном идет постоянный поток записи, примерно со скоростью 4 МБ / с.
Производительность чтения полезна, но на самом деле нет никакого горячего набора данных, очень случайного, какие данные могли бы или могли быть прочитаны, в зависимости от необходимости.
Индексирование очень важно. После полной загрузки zpool будет около 1,5 миллиона файлов, поэтому получение списка этих файлов должно быть как можно быстрее. Тут помогает ARC, много оперативной памяти?

Я планирую построить zpool следующим образом:

14 VDEV's 10 дисков, RaidZ2.
Сжатие на
Автоматическая замена на
перерыв

У меня нет хороших вариантов SLOG и L2ARC. Использование твердотельных накопителей HP на самом деле не вариант, поскольку они должны работать как одно устройство на оборудовании Raid0. Из того, что я прочитал на этом сайте, это напрашивается на неприятности.

Мои вопросы:

Было бы неплохо, конечно, больше оперативной памяти, но действительно ли она мне нужна?
Стоит ли ожидать серьезных проблем после загрузки в zpool более 95% данных. Меньшая производительность - это нормально, как уже говорилось, требования к производительности довольно низкие.
Рекомендуются любые другие макеты vdev без уменьшения доступного хранилища.
Следует учесть какие-либо особые настройки ZFS? Я по крайней мере рассматриваю возможность увеличения доли метаданных, хранящихся в ARC. Имеет смысл помочь со скоростью индексирования?
Стоит ли ожидать каких-либо проблем, связанных с использованием устройств L2ARC и SLOG?
Любые другие советы, как заставить вышеуказанное работать, очень признательны!

zfs zfsonlinux

Больше оперативной памяти может быть хорошим вариантом. Если производительность чтения не критична, но операции с метаданными являются: я бы рекомендовал установить "primarycache" на "metadata" для ваших файловых систем. Если у вас есть твердотельные накопители для L2ARC, вы также можете выбрать использование памяти (ARC) для кэширования «всего» и вторичного кэша (L2ARC) в качестве «метаданных». Обратите внимание, что наоборот не работает (L2ARC заполняется из ARC).

Стоит ли ожидать серьезных проблем после загрузки в zpool более 95% данных

Да и нет. Это будет зависеть от платформы / версии. Старые версии имеют огромное снижение скорости при 80% емкости. Чтобы исправить это: убедитесь на 100%, что ваши slabtables хранятся в памяти! (Солярис: metaslab_debug = 1). По умолчанию более старые версии хранят в памяти только 2 плиты на диск. Это убьет производительность. Я думаю, что FreeBSD и более новые версии делают это по умолчанию. Однако вам понадобится немного памяти (особенно с таким количеством дисков).

В любом случае я бы рекомендовал использовать устройство SLOG (ЗИЛ). Это обеспечит немедленное подтверждение вашей записи, но запись на медленные диски каждые x секунд. Это полезно, потому что вам нужно сделать только один проход по пластине для нескольких записей. Это оставляет больше дискового времени для чтения и т. Д.

Я не рекомендую использовать ZFS в Linux для таких больших сред. Система распределения памяти все еще не идеальна на 100%, из-за чего ZFS и Linux борются за память.