@crazych1

Нужна ли защита ZIL zfs?

Собственно что хочу сделать? Создать не дорогой, но производительный сторедж(хранилище данных) доступное по iscsi для esxi.
Мои предлопожения как это лучше сделать:
1. Использовать апаратный ред 10 Adaptec ASR6805E(есть в наличии) Батарейки у него нет и вроде как докупить тоже нельзя, если я не прав буду рад если кто знает какую можно поставить. Поэтому кеш на нем будет выключен.
2. Использовать zfs на разделе
3. Использовать 8 гигов памяти для кеша первого уровня
4. Использовать SSD MLC 30 гигов для кеша 2 уровня
5. Использовать SSD SLC 30 гигов для ZIL. Вот тут как раз вопрос, потеря этого раздела, повлечет потерю данных записываемых на раздел? И проблемы записи на него будут ли где то отображаться в логах? Учитывая что диск может быстро выйти из строя, это наверное узкое и важное место.

Может я что то не так делаю? Может есть какие то рекомендации к более оптимальному построения стореджа. Или проще и дешевле купить вместо ssd дисков сразу рейд с батарейкой и ssd кешем(цена насколько я знаю от 60т.р. начинается)?

В хранилище будет 4 диска по 2 терабайта WD Black RE
Заранее спасибо за помощь
  • Вопрос задан
  • 3497 просмотров
Решения вопроса 1
heathen
@heathen
Выбор между аппаратным RAID (с SSD кэшем и батарейкой) и ZFS - вопрос экономической целесообразности, и только. Примите во внимание сказанное ниже, посчитайте, сколько будет стоить железо для ZFS, и сколько - аппаратный RAID. После этого думайте. При этом учтите, что величина кэша на чтения у аппаратного RAID - фиксированная (если мы о разумных деньгах говорим). Кэш на запись не так критичен в данном случае.

Так вот, что касается ZFS и быстродействия:

0.1. В первую очередь выбор будет решать поддержка ECC-памяти у вашего сервера-хранилища. ZFS очень критично относится к ошибкам RAM, а собственных механизмов для защиты от них у неё нет. Само собой, никто вам не гарантирует неприятности в случае отсутствия ECC, но единичные сбои в памяти - случаи не эксклюзивно редкие, поэтому решать вам.
0.2. Не используйте встроенные SATA-контроллеры. Купите LSA 3008 в IT-режиме и к нему всё цепляйте. Может быть, ваш имеющийся RAID-контроллер можно использоваться (но в JBOD-режиме, понятное дело), но он тоже может дать какой-то оверхед (если там даже для JBOD используется кэширование или ещё что хитрое).

1. Первое, во что стоит вложиться для оптимизации производительности чтения ZFS - это оперативная память. Больше памяти - быстрее операции чтения (ARC находится именно в памяти). Если у вас менее 16ГБ ОЗУ и возможности поставить больше нет - задумайтесь, нужен ли вам ZFS. Лучше вложить деньги в память, чем в SSD под L2ARC.
2. Для оптимизации операций случайной записи вам понадобится, как вы правильно заметили, SLOG, он же ZIL, на SSD. Правила следующие для него:
2.1. Во-первых, это должно быть устройство, предназначенное для ЦОД с максимально допустимым TBW (total bytes written). Не покупайтесь на дешевизну пользовательских SSD, это выйдет вам боком. Если говорить о Samsung, то смотрите в сторону 843 DC (именно DC, не Pro и не Evo), а лучше - Intel S3700. Учитывая, что вам нужен диск на 100GB - это не принципиально дорого получится. 1 DWPD и ниже - плохо, 3 - более-менее, 5-10 - отлично. Ну, и устройства для ЦОД имеют конденсаторы, поэтому при падении питания то, что в кэше диска, будет таки скинуто в основную память. Но повторюсь: обязательно смотрите условия гарантии и максимально допустимые объемы записи в день\всего.
2.2. По поводу того, что случится, если выйдет из строя устройство с ZIL. ZFS на запись работает следующим образом. Все транзакции, синхронные и асинхронные, кэшируются в памяти. В случае синхронных транзакций подтверждение приложению, отправившему транзакцию, будет отправлено только в случае завершения дисковых операций, в случае асинхронных - сразу же. Так вот, чтобы сократить время ожидания, ZFS скидывает каждую синхронную транзакцию на ZIL и отправляет приложению подтверждение. Теперь, если сервер неожиданно выйдет из строя, асинхронные транзакции будут потеряны (они только в памяти были), но вот синхронные будут восстановлены последовательно из ZIL и записаны на диск. Если же выйдет из строя SLOG-устройство, на котором у нас ZIL, во в процессе работы сервера, то ZFS запишет всё на диски основного массива из памяти, и далее начнёт использовать под ZIL основной пул.
Я это рассказал, чтобы вы понимали механику и смогли информированный выбор сделать. Т.е., с одной стороны, вы потеряете критичные данные только в том случае, если одновременно выйдет из строя SSD и сервер выключится по тем или иным причинам. Но если сервер включился, до перезагрузки существовала очередь синхронных транзакций, а SLOG-устройство неисправно, вы потеряете все незавершённые транзакции (что в случае с VM почти наверняка будет означать кучу проблем). Причём пул будет в аварийном состоянии, и вам придётся вручную его импортировать и "отмотать" назад до последней успешной транзакции. В качестве защиты можно поставить два SSD и mirror'ить zil между ними (прямо средствами ZFS), но это, понятное дело, снизит скорость.
Само собой, в случае проблем с диском (любым) вам и ОС ругаться будет, и ZFS том пометит как degraded. А превентивно - пользуйтесь smartmontools :-)
2.3. Большой ZIL вам не нужен, буквально несколько GB. Т.е. если у вас 1 диск, я бы отдал немного под систему, 5-10GB под ZIL, остальное - под L2ARC, если два диска, то зеркало под систему, зеркало - под ZIL (zpool add tank log mirror /dev/sda2 /dev/sdb2) и остатки на каждом разделе - под l2arc (zpool add tank cache /dev/sda3 /dev/sdb3). l2arc будет stripe'иться, что ещё увеличит скорость чтения.

Но, вообще говоря, 4 диска - это семечки для ZFS. На таком количестве дисков правильно подобранный SSD даже на операциях последовательной записи может дать прирост. Ну, и в случае хранилища под виртуализацию - только stripe + mirror, понятное дело. И маленький совет - купите пятый диск для hot spare. Просто на всякий пожарный.

Ну, и самое важное: качественный UPS must have.

P.S. Не используйте ZFS on Linux. Лучше Фря.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@crazych1 Автор вопроса
c08510811d7b4312b9ce0541a5b1c1bd.png

Да, Вы правы, создавалось 2 зеркала и запись на оба.
Мерилось все утилитой gstat путем замера через zabbix раз в 5 секунд
нагрузка на случайное чтение создавалась путем запуска дефрагментации на виртуальной машине работающей на разделе подключенным через ISCSI ESXI 5.5
И в этот момент проводился замер.
А собственно скорость записи замерялась путем копирования файла с сетевой шары на виртуалку.

Параметры сервера
FreeNAS-9.3-STABLE-201509220011
Intel(R) Xeon(R) CPU X3440 @ 2.53GHz
память DDR3 16Gb

Может попробывать 10 рейд развернуть на отдельном контроллере без кеширования, а раздел и кеширование уже средствами ZFS?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы