ZFS

Adaptec 5805 RAID6 vs ZFS RAIDZ2 performance

Вот, померял на досуге:
  • ASR-5805, 8 дисков в RAID-6, 2Tb-раздел в начале массива. Тестируем гигабайтным блоком, 40 гигов чтения/записи:
    • NTFS (Win7): 651Mb/sec чтение, 651Mb/sec запись.
    • UFS2+SUJ (FreeBSD 9.1): 585Mb/sec запись, 528Mb/sec чтение.
    • EXT4 (Ubuntu Server 11.10): 659/639
  • ZFS RAIDZ2 (FreeBSD 9.1), те же 8 дисков: 490Mb/sec на запись (dd bs=1024M), огорчился и не стал мерять дальше.
Так как эти ~650Mb/sec у меня из Убунты впрямую транслируются в SRP (SCSI RDMA Protocol), то я уже счастлив (подробности...

О сторадж-боксах

Звезды сошлись, руки дошли и я собрал таки стораджбокс, как и собирался уже полгода
Core i5-2300, 8GB RAM, Adaptec 5805, 8x1Tb HDD (6 штук старых Barracuda ES.2 SAS, два новых WD RE4), бутовый SSD, Mellanox Infiniband (2 порта 10G). И даже есть место для еще одного диска, хотя 5" ящики и не обдуваются.

Задача: вынести HDD из рабочей станции (где было 6x1Tb SAS + Adaptec) с целью уменьшения шума под...

Опять-снова о производительности ZFS

В процессе борьбы за увеличение количества PCI-e слотов в домашнем NAS, взял я кровные 300 баксов и отнес их в лабаз, где и приобрел:

  • 2x4GB памяти DDR3-1600
  • Процессор i3-2120
  • Материнку Gigabyte GA-Z68MA-D2H-B3 (3 длинных PCIe слота, x16, x8 и x4!)
На общую сумму 8800р или что-то вроде этого.

В сравнении с тем что было (Core2Quad Q9300, 8Gb), общий перформанс вырос не слишком сильно. make -j8 buildworld шел 44 минуты, а теперь идет 37. Это на SSD-диске.

...

O ZFS performance

Подтверждается старое правило: чем гуще горшок, тем пуще ZFS

Переставил новый массив из тестовой машины (i7-2.67Ghz) в несколько более медленную (Core2Quad Q9300 @2.5) и сразу вместо 350-360Mbyte/sec на запись получил 250-280.

На скорость диска не могу грешить, zpool scrub в обеих машинах в начале процесса рапортует в районе 500Mb/sec:

 pool: zdata
 state: ONLINE
  scan: scrub in progress since Tue Mar 20 14
...

Про ZFS, Advanced Format и ashift

Пару лет назад я уже исследовал ZFS на дисках с 4k-сектором, но тогда такой диск в массиве был только один (а остальные три - с 512b секторами) и какой-то значимой разницы я не нарыл.

Кроме того, том был загрузочный, а грузиться с тома где ashift не равен 9 тогдашние бутблоки не умели.

Поэтому овладев пятеркой 3Tb сигейтов я просто обязан был это опробовать.

Рассказываю.

Hardware

  • 5x Seagate ST3000DM001
  • ...

ZFS performance Q: hw RAID или RAIDZ(2)

А вот такой практический вопрос.

Есть, к примеру, 6-8 не очень быстрых дисков (7200 rpm, что-нибудь типа Barracuda ES или как они теперь правильно называются, Seagate Constellation?). Двухтерабайтников, скажем (потому и не 10k/15k).

К тому же примеру, есть какой-то 8-портовый контроллер. Вот прямо на руках есть Adaptec 5805. Покупать что-то еще новомодное и быстрое (столь хвалимые LSI 9280, к примеру) не хочется, жаба не велит.

Процессор на тазике будет достаточно быстрый, что-нть в духе i7-920, памяти тоже не пожалею (12G скорее всего).

Хочется на этом месте поднять ZFS (потому что очень удобно на практике), предположительно на FreeBSD, но солярку (в каком-то лице) тоже можно рассмотреть.

Собственно, вопрос:

А как это правильно конфигурировать то:

  • JBOD или 6(8) single-disk arrays и ZFS поверх?
  • Или RAID6 на контроллере и ZFS "на одном томе"?
Вопрос касается именно производительности, причем типичных паттернов я вижу два:
  • I like to move it, move it большими файлами (кино, бэкапы, да мало ли в хозяйстве больших файлов). Т.е. линейное чтение-запись во всей красе.
  • Доступ по iscsi, причем тома будут прямо вот средствами ZFS нарезаны. А на этих томах - всякое разное.

Интернеты - противоречивы. У одних бойцов RAIDZ несколько медленнее, у других - наоборот. Как правило, из тестов непонятно, куда RAIDZ упирался, мог ведь и банально в память/процессор.

Помимо RAIDZ2/RAID6 рассматриваю еще и вариант с mirror, но он для 8 дисков какой-то обидный.

FreeBSD ZFS performance: просто возьмите молоток побольше

Если поискать в этом блоге, особенно в каментах, то найдете что ZFS на трех дисках (RAIDZ) давала у меня скорость чтения/записи порядка 75-80 Mb/sec. Так оно и было до недавнего времени, пока я с этой скоростью не уперся в скорость на сети (samba).

Пришлось навести следствие. Выяснилось очень простое, хотя и не вполне очевидное:

  • У меня был даунклоченый Core2Duo: 1.86Ghz работающий на ~1.6, задаунклочил летом, по случаю жары, просто на всякий случай.
  • При этом при чтении с ZFS
  • ...

Поэтосамое по-настоящему

Если вы хотите поеба потрахаться по-настоящему, предлагаю такой вот метод:

  • Создаете ZFS-том терабайт эдак на шесть (меньше не пробовал) на FreeBSD 8.1-RELEASE/STABLE.
  • И записываете туда пару-тройку сотен тысяч файлов с русскими (и европейскими) именами в кодировке UTF-8.
Если вам очень повезет, то вы получите ненулевое количество каталогов в которых нельзя сделать ls или find (и естественно, все остальные, получающие список файлов, вроде du). Если повезет слегка, то ls работать будет, а вот rm * - нет. И...

gptzfsboot и все все все....

В копилку знаний сисадмина:

Если у вас ZFS, RAIDZ и загрузка с RAIDZ и вы ставили FreeBSD 8.1-RELEASE

То не поленитесь поапгрейдить бут-блоки на более свежие, те которые в 8.1 - не умеют грузиться с degraded array.

Подробности тут: www.freebsd.org/cgi/query-pr.cgi?pr=148655

Да, а если ваш массив в состоянии resilvering (навернувшийся диск заменили, но массив не успел перестроиться), то и новые бутблоки имеют шанс не загрузиться...

P.S. Нет, диск не ломался, это я просто like to move it, move it, все массивы в доме наращивал до размера побольше....

Народная мудрость

Примета:

Сделать zpool upgrade, но не сделать gpart bootcode ... -p gptzfsboot - означает поипаться от души поиметь немало веселых минут.

Особенно с учетом того, что zpool upgrade делается на лету, а отсутствие нужной версии boot loader становится заметно после перезагрузки. Которая у меня, например, случилась через две недели.

Хорошо еще, что это на домашнем сервере. Как такое лечить удаленно, имея обычную comconsole - я себе пока не представляю. Т.е. даже резервная загрузочная флэшка поможет условно, предполагая что там система времени заливки сервера, ибо нужных бутблоков там тоже не будет (слишком старые), следовательно там надо иметь /usr/src, апдейтить его до правильного, собирать бутблоки и прочая и прочая.

Всякие новомодные встроенные KVM, как у HP, конечно спасут - можно им образ с LiveFS по сети подсунуть для загрузки, а дальше все просто.

Наука о контактах

Вот такие вот приятные сообщения стал я получать от системы.

 Dec 15 07:39:40 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Dec 15 08:02:37 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Dec 15 08:31:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Dec 15 08:55:29 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Dec 15 08:58:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Dec 15 09:01:10...

root on ZFS

Для тонких ценителей.
zroot on / (zfs, local)
zroot/home on /home (zfs, local)
zroot/tmp on /tmp (zfs, local, nosuid)
zroot/usr on /usr (zfs, local)
..... и еще с десяток томов под разные нужды....
3 диска, RAIDZ1, 4 терабайта места, "домашний роутер".

Но пришлось раз 10 подойти к снаряду на виртуальной машине, прежде чем многочисленные мелкие грабли оказались обнаружены.

В частности, расширять root pool нельзя, поэтому идея-фикс по переносу данных без многократного переписывания данных не проканала. А была она такая:

  • Было два двухтерабайтника в зеркале, место кончилось, купил третий.
  • Разбиваем зеркало, из двух дисков (один старый, один новый) делаем RAIDZ1, переписываем туда данные.
  • Добавляем второй старый диск в тот же RAID.
Увы, пришлось вылить на внешние диски, собрать массив, налить обратно....

По органолептическим ощущениям, диски сильно меньше нагружены, чем в gmirror, отчего меньше греются. Какой-то статистики наберу за неделю, расскажу....

SSD рулят

Потестировал тут SSD-диск (G.Skill Falcon, 128Gb) на одной read-only задаче. Два дня тестировал.

Если не вдаваться в подробности, то это большая (в примере было 90Gb) база данных со случайным доступом. Запросы к ней бывают короткие и длинные, при этом короткие на обычных дисках упираются в seek, а длинные ограничены и скоростью линейного чтения тоже.

Получилось:

  • Короткие запросы (коих большинство) ускорились примерно в 15 раз.
  • Длинные - в 4-5 раз.

Кроме того, для длинных запросов не падает общий throughput под параллельной нагрузкой (несколько одновременных запросов), тогда как для HDD - падает.

Сравнивалось с зеркалом (round-robin) из двух современных небыстрых десктопных дисков (WD Caviar Green, 2Tb), FreeBSD 8, UFS, холст, масло. Памяти 2 гигабайта, пролетаем мимо кэширования (в реальной жизни памяти на такие данные обычно несколько больше, но не в 10 раз).

Понятно, что если сравнивать с быстрыми SAS, то они в разы быстрее, но не в 15. Ну и дороже десктопных HDD они тоже в разы (и как бы не бОльшие).

Да, ZFS (но с одним диском) тоже смотрел, скорость записи сильно больше, скорость линейного чтения - сильно меньше. Как-то ее надо настраивать, наверное.

Долго потом думал, куды сунуть новое приобретение, в ноутбук или в десктоп. Засунул в ноут, он стал реактивнее десктопа, одно удовольствие работать. Заказал в десктоп еще и чую, что одним дело не закончится (опять же, надо гибридную ZFS потестировать, с ZIL на SSD оптимизированном под линейную запись и L2ARC оптимизированном под произвольное чтение)

Вот так разводят нашего брата.

P.S. Этот угол ноутбука теперь холодный.

Pages

Subscribe to ZFS