LINUX.ORG.RU

Ceph v0.87 Giant

 ,


5

5

29-го октября тихо и незаметно вышла 7-я мажорная версия ceph 0.87 «Giant».
Основная идея Ceph — быть свободным и полностью распределенным хранилищем без единой точки отказа, расширяемым до эксабайтного уровня.

Список основных изменений:

  • Ускорение RADOS: внесены изменения в OSD и клиентской части librados, которые увеличивают пропускную способность на flash-бекэндах и улучшают параллелизм и масштабируемость на быстрых машинах.
  • CephFS: исправлены различные ошибки в CephFS, которые приводили к проблемам стабильности и производительности. К сожалению, CephFS всё еще не рекомендована к промышленному применению.
  • Код для локального восстановления: OSD теперь поддерживают erasure-coding схемы, которые содержат дополнительные блоки данных для уменьшения IO во время восстановления после отказа одиночного OSD.
  • Деградация vs ошибочное расположение: репорты о состоянии кластера Ceph во время вывода‘ceph -s’ и сопутствующих команд теперь делают различие между данными, которые находятся в состоянии деградации, и данными, которые неверно расположены(неверное расположение в кластере). Это важно, так как в последнем случае это не приводит к возможной потере данных.
  • Улучшения в мониторинге: мониторы теперь пишут данные асинхронно, что улучшает общую отзывчивость.

Полный список изменений доступен по ссылке.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от ugoday

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

Я понимаю, возможно, что производительность падает не линейно с ростом числа виртуалок. Разработчики CEPH, по моему наблюдению, рассматривают кластер от 100-тен машин.

Во всяком случае, они не предполагали, например, что многие придумают установить в одну ноду n-дисков и, например 1 или 2 SSD, что напрашивается, при небольшом количестве нод.

Скрипты инициализации написаны таким образом, что простым путём, можно только разделить ноды на полностью hdd и полностью SSD. Если предполагается смешанное использование, то надо дорабатывать механизм инициализации.

Я бы хотел построить кластер из, например 5-10 машин.

Кстати, 250 мегабит получилось при 2-х копиях данных. При 3-х производительность не пропорционально сильно проседает.

При этом я не выявил узкоен место. Ни сеть, ни диски, ни процессор не были нагружены даже на 50%.

riv1329 ()
Ответ на: комментарий от Deleted

Зачем ты запустил их на виртуальных машинах?

По нескольким причинам: 1. На них нет нагрузки никакой, таким образом на результатах не должно сказатся. 2. Хост-система очень мощьная и по дисковому io в том числе.

Как именно? В бондинг объединил? И через какую сеть клиенты общались с хранилищем?

Как написал выше, и в соответствии с рекомендациями, подключил их к разным коммутаторам. В них использовал 2 разные ip-подсети класса С.

В конфигах CEPH обозначил одну как fronend, вторую как backend.

Клиента (гипервизор) соеденит через frontend

CRUSH лучше руками не трогать. В случае трёх нод в этом вообще нет никакого смысла.

Считаю спорным это утверждение. Я трогал не руками (как в старых версиях) а утилитами. Тем не менее, задействовать cache-pool без манипуляций с CRUSH-map невозможно. А без cache-pool, даже сами разработчики производительности не обещают.

А tmpfs даст ещё больше! =)

Такая производительность меня вполне устроит :-)

Тем не менее, я ожидал что-то не сильно хуже DRDB

riv1329 ()
Ответ на: комментарий от riv1329

Во всяком случае, они не предполагали, например, что многие придумают установить в одну ноду n-дисков и, например 1 или 2 SSD, что напрашивается, при небольшом количестве нод.

Скрипты инициализации написаны таким образом, что простым путём, можно только разделить ноды на полностью hdd и полностью SSD. Если предполагается смешанное использование, то надо дорабатывать механизм инициализации.

Я не совсем понял о чём ты. Разницы между HDD и SSD в юзерспейсе вообще нет. Где создашь разделы для ceph - там оно и будет хранить все данные.

Сейчас вообще круто сделано: используется хелпер для udev, который отлавливает разделы OSD по меткам в GPT.

Я бы хотел построить кластер из, например 5-10 машин.

Я свой «кластер» собрал из семи серваков ibm x3550 практически минимальной конфигурации и свитча juniper ex4200. От каждого сервака к свитчу у меня идёт четыре гигабитных линка, объединённых в два bonding-интерфейса: для обмена между OSD и для «клиентов». Делал я вс это просто ради интереса так как железо всё равно простаивало, так что отдельных машин для клиентов у меня нет, и всё что есть - работает на этих же системах. Конкретных цифр по производительности у меня не осталось, помню только, что производительность меня устроила и скорость записи/чтения вышла заметно выше, чем с локальных дисков.

Могу в понедельник попробовать замерить ещё раз.

Deleted ()
Ответ на: комментарий от riv1329

Считаю спорным это утверждение. Я трогал не руками (как в старых версиях) а утилитами. Тем не менее, задействовать cache-pool без манипуляций с CRUSH-map невозможно. А без cache-pool, даже сами разработчики производительности не обещают.

А ты пробовал без cache pool? Если я правильно понимаю как он работает и зачем вообще сделан, то в случае небольшого числа машин он наоборот должен приводить к лишним тормозам.

Такая производительность меня вполне устроит :-)

Я к тому, что сравнивать ceph с zfs некорректно. С drbd - уже ближе по смыслу, да.

Deleted ()

А все-же кто-нибдь пробовал альтернативы?

Я подожду ещё годик и попробую ceph опять, на новом оборудовании.

Тем не менее, совместить вычислительные ноды с нодами хранения - это очень заманчивая идея, по многим причинам. Особенно это актуально при небольшом количестве нод в кластере.

Для себя я остановился на sheepdog для следующего тестирования. Задача - построить хранилище для запуска виртуалок с 1с, вероятно в файловом режиме.

Меня несколько отпугнуло от sheepdog оформнение их сайта. Не поизводит впечатление серьёзного проэкта.

Тем не менее, после изучения ceph, я поменял свое мнение.

Решения, которые мне понравились в sheepdog:

  • схемы резервирования не только Mirror x3 но и основанные на избыточности. Я гулбоко не вникал, но разработчики обещают уменьшение iops на дисках хранилища и экономию места при сохранении отказоустойчивости.
  • локальное кэширование на SSD и отложенная запись в кластер через лог на локальных SSD.
  • на первый взгляд, значительно проще в настройке
  • хвастают, что taobao.com работает на их детище

Что понравилось в ceph и, на мой взгляд, необходимо:

  • Снимки
  • Инкрементальная репликация снимков
  • Гибкость настройки алгоритма реплакации данных
  • Впечателние такое, что на большом количестве дисков, действительно может «всех уделать».
  • Мощьно развивается
  • Подробная и обширная документация
riv1329 ()
Ответ на: комментарий от Deleted

Я не совсем понял о чём ты. Разницы между HDD и SSD в юзерспейсе вообще нет.

Я имел в виду способ создания cach-pool. Для этого надо, грубо говоря, создать файловые системы на дисках и запустить по osd для каждого диска.

cache-pool - это пул, собранный исключительно из ssd-дисков и который может кэшировать в резиме отложенной записи операции Могу в понедельник попробовать замерить ещё раз. и записи в основной pool

Могу в понедельник попробовать замерить ещё раз.

Буду весьма признателен. С меня результаты по sheepdog, как будут готовы.

riv1329 ()
Ответ на: комментарий от Deleted

А ты пробовал без cache pool? Если я правильно понимаю как он работает и зачем вообще сделан, то в случае небольшого числа машин он наоборот должен приводить к лишним тормозам.

Пробовал, значительно медленнее. На 3-х нодах и гигабите - неюзабельно.

Я к тому, что сравнивать ceph с zfs некорректно. С drbd - уже ближе по смыслу, да.

Разумеется. В настоящий момент работает именно на zfs. По этому контраст был ещё разительнее.

riv1329 ()
Ответ на: комментарий от Deleted

Думал о такой конфигурации, но не пробовал. По bcache не всё так просто. Если не ошибаюсь, bcache, выполняя свои функции, по крайней мере в 2 раза уменьшает количество iops от тех, которые даёт кеширующее устройство из-за того, что тоже производит запись своих внутреннних метаданных после каждой записи полезных данных.

Потом возникают вопросы с trimm - это важно для SSD и может приводить к падению производительности в сотни раз. Попробуйте intel 520 запполнить данными, а потом минут 20 погрузить слуйчайной записью. Будет около 100 iops - что не отличается от обычного жесткого диска.

В общем, надо пробовать.

Но я пробовал просто разместить диски в ssd-пуле. Никакого драматического роста проиводительности не заметил. Нагрузка на SSD по мнению atop была в пределах 10%.

riv1329 ()
Ответ на: комментарий от Deleted

Ещё пояснение.

Я не совсем понял о чём ты. Разницы между HDD и SSD в юзерспейсе вообще нет.

Представь, что в ноде 6 обычных накопителей и 2 SSD - их надо соотнести с разными пулами. Как это сделать? А надо в CRUS-map добавить еще один корень иерархии, и назвать его, например SSD. А потом все osd которые сохраняют данные на файловые системы смонтированные с ssd-накопителей, вручную переместить в эту иерархию, не забыв создать узлы на уровне серверов и стоек и сообтветствующим образом, вручную, назначит веса.

Такой способ предложили разработчики в их списке рассылки.

Допускаю, что ситуация за пол-года могла изменится и сейчас повилась какая-то автоматизация. Разумеется не очень сложно написать что-то на bash для автоматизации.

anonymous ()
Ответ на: комментарий от Deleted

Если не затруднит.

Могу в понедельник попробовать замерить ещё раз.

Там есть возможность замапить rdb image в локальное блочное устройство.

Как-то так: rbd map mypool/my-test-image-rw --id admin --keyfile secretfile

Можно на такойм устройстве запустить fio на чтение и запись при глубине очереди 32 и 1

Сколько iops выдаёт и какая средняя латентность?

И какая при этом нагрузка по iops на диски хранилища, если там нет других задачь?

Готовый конфиг fio есть тут http://habrahabr.ru/post/154235/

Осторожно, может заставит хранилище призадуматься.

А ещё есть команда тестирования производительности пула https://www.safaribooksonline.com/library/view/mastering-proxmox/978178398082...

rados –p <pool> bench –b <blockSize> <seconds> <seq> -t <threads>

Только не прерывайте её через ctrl-c, а то она не удалить за собой записанные в pool объекты.

Последний тест объектами по 4МБ у меня выдавал 500Мбит.

Прошу прощения за такую наглосьть :-)

anonymous ()
Ответ на: комментарий от ugoday

а что более интересные механзимы выработки parity уже отменили? ну там сетевой RAID6 вполне выживет если 2 из 8 нод умрут. Все же не такая избыточность.. а тут даже не raid0, тут в разы больше надо всего..

anonymous ()

Re: А все-же кто-нибдь пробовал альтернативы?

Тем не менее, совместить вычислительные ноды с нодами хранения - это очень заманчивая идея, по многим причинам. Особенно это актуально при небольшом количестве нод в кластере.

Я думаю что те кто считают свою математику - совсем не обрадуются что их вычислительные ноды вдруг начали тупить из-за IO. Да и какой умный человек купил в вычислительные ноды диски? явна у вас есть лишние деньги на оплату электричества.. А может и добавочная электростанция? Если взять что нить из top500..

anonymous ()
Ответ на: комментарий от anonymous

а что более интересные механзимы выработки parity уже отменили?

Конечно нет. Так что если тебе не нужны возможности ceph, то можешь просто его не использовать.

ugoday ★★★★★ ()
Ответ на: комментарий от anonymous

У sheepdog есть.

https://github.com/sheepdog/sheepdog/wiki/Erasure-Code-Support

Я тоже не понимаю, почему не реализовали. 3 копии - это для кворума, т.е. если одна не исправна, то исправная определяется по 2-м одинаковым копиям. Но ведь можно контрольные суммы добавить.

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

Тем не менее, разработчики sheepdog утверждают, что:-

For a simple test on my box, aligned-4k write get 1.5x faster than replication at most, while read get 1.15x faster, compared with copies=3 (4:2 scheme)

For 6 nodes cluster with 1000Mb/s NIC, I got the following result:

replication(3 copies): write 36.5 MB/s, read 71.8 MB/s erasure code(4 : 2) : write 46.6 MB/s, read 82.9 MB/s

И мне эти цифры нравятся намного больше. Кстати, в ceph я результат получил блтже к первому. У меня получилось 250Mbit.

riv1329 ()

Не совсем полнял аргументы. Если можно, поподробнее?

Я вычислительными нодавми назвал те машины, где кроме дисков, размещен гипервизор и виртуальные машины.

Почему вычислительные ноды должны тупить из-за io? Как сказывается на электропотреблении перенос дисков из выделенных нод в вычислительные?

riv1329 ()
Ответ на: Если не затруднит. от anonymous

Итак, конфиг моего игрушечного кластера вот такой:

  • Семь серваков IBM System x3550 M4 Server [7914AC1]
  • 64 GiB RAM в каждом сервере
  • 27 дисков IBM-ESXS ST91000640SS (1 TB, 7200 RPM, SAS, по сути это Seagate с наклейкой «IBM») в сумме на все сервера
  • Один Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (шесть ядер, по два «потока» на каждое) в каждом сервере.
  • CentOS 6.6 с ядром 3.14.*.

От каждого сервака идёт четыре кабеля gigabit ethernet до свитча Juniper EX4200. Они попарно объединены в бондинг: один для «клиентской сети», другой для «кластерной сети» (для репликации между OSD).

Для начала, тесты на таком же сервере, в котором два таких же диска объединены в аппаратный RAID1 на IBM ServeRAID M5110 (правда тут fedora 20 вместо centos 6, но не думаю, что это существенно):

# dd bs=4M if=/dev/zero of=/dev/sda6 oflag=direct
dd: error writing ‘/dev/sda6’: No space left on device
21000+0 records in
20999+0 records out
88080351744 bytes (88 GB) copied, 1675.12 s, 52.6 MB/s
fio (конфиг с хабра, iodepth=1):
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.1.2
Starting 2 processes

readtest: (groupid=0, jobs=1): err= 0: pid=21581: Tue Nov 11 01:06:26 2014
  read : io=10240MB, bw=348452B/s, iops=85, runt=30814609msec
    slat (usec): min=8, max=256, avg=31.50, stdev= 7.42
    clat (usec): min=1, max=133700, avg=11715.89, stdev=7187.21
     lat (usec): min=37, max=133720, avg=11748.05, stdev=7187.09
    clat percentiles (usec):
     |  1.00th=[  572],  5.00th=[ 3056], 10.00th=[ 3920], 20.00th=[ 5472],
     | 30.00th=[ 7008], 40.00th=[ 8512], 50.00th=[10048], 60.00th=[12480],
     | 70.00th=[14912], 80.00th=[17536], 90.00th=[20864], 95.00th=[25728],
     | 99.00th=[33024], 99.50th=[35584], 99.90th=[49920], 99.95th=[63744],
     | 99.99th=[77312]
    bw (KB  /s): min=  214, max= 1972, per=100.00%, avg=340.23, stdev=53.28
    lat (usec) : 2=0.01%, 4=0.01%, 20=0.01%, 50=0.08%, 100=0.19%
    lat (usec) : 250=0.27%, 500=0.45%, 750=0.12%, 1000=0.02%
    lat (msec) : 2=0.48%, 4=8.89%, 10=39.45%, 20=38.58%, 50=11.38%
    lat (msec) : 100=0.10%, 250=0.01%
  cpu          : usr=0.10%, sys=0.31%, ctx=2623977, majf=0, minf=29
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=21582: Tue Nov 11 01:06:26 2014
  write: io=10240MB, bw=314263B/s, iops=76, runt=34166970msec
    slat (usec): min=10, max=266, avg=32.00, stdev= 7.51
    clat (msec): min=1, max=524, avg=12.99, stdev= 8.25
     lat (msec): min=1, max=524, avg=13.03, stdev= 8.25
    clat percentiles (usec):
     |  1.00th=[ 3024],  5.00th=[ 4128], 10.00th=[ 4896], 20.00th=[ 6240],
     | 30.00th=[ 7456], 40.00th=[ 8768], 50.00th=[10432], 60.00th=[12352],
     | 70.00th=[15936], 80.00th=[19328], 90.00th=[25728], 95.00th=[28800],
     | 99.00th=[36608], 99.50th=[40704], 99.90th=[57088], 99.95th=[67072],
     | 99.99th=[83456]
    bw (KB  /s): min=  145, max=  614, per=100.00%, avg=306.98, stdev=76.80
    lat (msec) : 2=0.04%, 4=4.31%, 10=43.42%, 20=34.49%, 50=17.60%
    lat (msec) : 100=0.15%, 250=0.01%, 500=0.01%, 750=0.01%
  cpu          : usr=0.09%, sys=0.27%, ctx=2623759, majf=0, minf=22
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2621440/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=10240MB, aggrb=340KB/s, minb=340KB/s, maxb=340KB/s, mint=30814609msec, maxt=30814609msec
  WRITE: io=10240MB, aggrb=306KB/s, minb=306KB/s, maxb=306KB/s, mint=34166970msec, maxt=34166970msec

Disk stats (read/write):
  sda: ios=2621496/2622540, merge=778/163, ticks=30658018/46170835, in_queue=76820293, util=100.00%
fio (конфиг с хабра, iodepth=32):
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.1.2
Starting 2 processes

readtest: (groupid=0, jobs=1): err= 0: pid=21209: Mon Nov 10 13:39:58 2014
  read : io=10240MB, bw=574379B/s, iops=140, runt=18693932msec
    slat (usec): min=2, max=262, avg=18.51, stdev= 5.26
    clat (usec): min=41, max=1777.8K, avg=228171.95, stdev=192810.00
     lat (usec): min=59, max=1777.8K, avg=228191.03, stdev=192810.00
    clat percentiles (msec):
     |  1.00th=[   12],  5.00th=[   25], 10.00th=[   39], 20.00th=[   70],
     | 30.00th=[  112], 40.00th=[  149], 50.00th=[  182], 60.00th=[  219],
     | 70.00th=[  258], 80.00th=[  338], 90.00th=[  494], 95.00th=[  644],
     | 99.00th=[  889], 99.50th=[  979], 99.90th=[ 1156], 99.95th=[ 1205],
     | 99.99th=[ 1352]
    bw (KB  /s): min=  220, max= 1697, per=100.00%, avg=562.41, stdev=113.58
    lat (usec) : 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.03%, 10=0.72%, 20=2.79%, 50=10.59%
    lat (msec) : 100=13.23%, 250=40.85%, 500=22.01%, 750=7.32%, 1000=2.01%
    lat (msec) : 2000=0.43%
  cpu          : usr=0.14%, sys=0.30%, ctx=2617941, majf=0, minf=56
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=21210: Mon Nov 10 13:39:58 2014
  write: io=10240MB, bw=547232B/s, iops=133, runt=19621320msec
    slat (usec): min=3, max=248, avg=20.13, stdev= 5.99
    clat (msec): min=2, max=1813, avg=239.49, stdev=210.17
     lat (msec): min=2, max=1813, avg=239.51, stdev=210.17
    clat percentiles (msec):
     |  1.00th=[   11],  5.00th=[   23], 10.00th=[   36], 20.00th=[   63],
     | 30.00th=[  104], 40.00th=[  149], 50.00th=[  186], 60.00th=[  225],
     | 70.00th=[  273], 80.00th=[  392], 90.00th=[  537], 95.00th=[  676],
     | 99.00th=[  938], 99.50th=[ 1045], 99.90th=[ 1205], 99.95th=[ 1270],
     | 99.99th=[ 1401]
    bw (KB  /s): min=  227, max= 3486, per=100.00%, avg=536.50, stdev=197.01
    lat (msec) : 4=0.02%, 10=0.82%, 20=3.29%, 50=11.50%, 100=13.46%
    lat (msec) : 250=36.62%, 500=22.55%, 750=8.51%, 1000=2.56%, 2000=0.67%
  cpu          : usr=0.14%, sys=0.31%, ctx=2623480, majf=0, minf=26
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2621440/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=10240MB, aggrb=560KB/s, minb=560KB/s, maxb=560KB/s, mint=18693932msec, maxt=18693932msec
  WRITE: io=10240MB, aggrb=534KB/s, minb=534KB/s, maxb=534KB/s, mint=19621320msec, maxt=19621320msec

Disk stats (read/write):
  sda: ios=2613542/2621029, merge=8754/377, ticks=596867882/628723741, in_queue=2157967173, util=100.00%
После запуска FIO с iodepth=32 локально, на эту систему было невозможно зайти по ssh =).

Deleted ()
Ответ на: комментарий от Deleted

А теперь RBD (pool size = 2, min_size = 1, pg_num = 256, pgp_num = 256).

# dd bs=4M if=/dev/zero of=/dev/rbd/kvm.rbd/test oflag=direct
dd: writing `/dev/rbd/kvm.rbd/test': No space left on device
25601+0 records in
25600+0 records out
107374182400 bytes (107 GB) copied, 6309.42 s, 17.0 MB/s
fio (конфиг с хабра, iodepth=1):
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.0.13
Starting 2 processes

readtest: (groupid=0, jobs=1): err= 0: pid=24247: Tue Nov 11 06:25:33 2014
  read : io=10240MB, bw=2110.2KB/s, iops=527 , runt=4967232msec
    slat (usec): min=18 , max=531 , avg=75.55, stdev=23.28
    clat (usec): min=326 , max=583032 , avg=1810.87, stdev=4247.82
     lat (usec): min=373 , max=583137 , avg=1887.22, stdev=4245.58
    clat percentiles (usec):
     |  1.00th=[  660],  5.00th=[  772], 10.00th=[  844], 20.00th=[  964],
     | 30.00th=[ 1048], 40.00th=[ 1096], 50.00th=[ 1144], 60.00th=[ 1192],
     | 70.00th=[ 1224], 80.00th=[ 1272], 90.00th=[ 1336], 95.00th=[ 1528],
     | 99.00th=[28288], 99.50th=[36096], 99.90th=[40192], 99.95th=[40704],
     | 99.99th=[41216]
    bw (KB/s)  : min=  468, max= 4480, per=100.00%, avg=2113.93, stdev=359.16
    lat (usec) : 500=0.07%, 750=3.80%, 1000=19.94%
    lat (msec) : 2=71.83%, 4=0.41%, 10=1.25%, 20=1.13%, 50=1.55%
    lat (msec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
  cpu          : usr=0.87%, sys=4.30%, ctx=4429491, majf=0, minf=25
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=24248: Tue Nov 11 06:25:33 2014
  write: io=10240MB, bw=208020 B/s, iops=50 , runt=51617160msec
    slat (usec): min=17 , max=479 , avg=64.77, stdev=20.95
    clat (msec): min=2 , max=76835 , avg=19.62, stdev=310.03
     lat (msec): min=2 , max=76835 , avg=19.68, stdev=310.03
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    7], 10.00th=[    8], 20.00th=[    9],
     | 30.00th=[   10], 40.00th=[   11], 50.00th=[   13], 60.00th=[   14],
     | 70.00th=[   17], 80.00th=[   22], 90.00th=[   28], 95.00th=[   37],
     | 99.00th=[  102], 99.50th=[  141], 99.90th=[  255], 99.95th=[  363],
     | 99.99th=[  979]
    bw (KB/s)  : min=    0, max=  472, per=100.00%, avg=232.78, stdev=63.76
    lat (msec) : 4=0.05%, 10=30.49%, 20=47.30%, 50=18.97%, 100=2.13%
    lat (msec) : 250=0.95%, 500=0.07%, 750=0.02%, 1000=0.01%, 2000=0.01%
    lat (msec) : >=2000=0.01%
  cpu          : usr=0.11%, sys=0.48%, ctx=2824493, majf=0, minf=26
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2621440/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=10240MB, aggrb=2110KB/s, minb=2110KB/s, maxb=2110KB/s, mint=4967232msec, maxt=4967232msec
  WRITE: io=10240MB, aggrb=203KB/s, minb=203KB/s, maxb=203KB/s, mint=51617160msec, maxt=51617160msec
fio (конфиг с хабра, iodepth=32):
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.0.13
Starting 2 processes

readtest: (groupid=0, jobs=1): err= 0: pid=23525: Mon Nov 10 16:04:15 2014
  read : io=10240MB, bw=10660KB/s, iops=2665 , runt=983643msec
    slat (usec): min=10 , max=662 , avg=28.32, stdev=11.44
    clat (usec): min=315 , max=1381.5K, avg=11975.57, stdev=19103.46
     lat (usec): min=346 , max=1381.6K, avg=12004.26, stdev=19102.62
    clat percentiles (usec):
     |  1.00th=[  454],  5.00th=[  588], 10.00th=[  684], 20.00th=[  828],
     | 30.00th=[ 1128], 40.00th=[ 2544], 50.00th=[ 6240], 60.00th=[10560],
     | 70.00th=[16320], 80.00th=[23680], 90.00th=[32128], 95.00th=[37120],
     | 99.00th=[40704], 99.50th=[50432], 99.90th=[171008], 99.95th=[264192],
     | 99.99th=[765952]
    bw (KB/s)  : min=  308, max=19296, per=100.00%, avg=10681.96, stdev=1291.57
    lat (usec) : 500=2.36%, 750=12.59%, 1000=11.82%
    lat (msec) : 2=11.19%, 4=6.31%, 10=14.62%, 20=16.49%, 50=24.11%
    lat (msec) : 100=0.27%, 250=0.18%, 500=0.03%, 750=0.01%, 1000=0.01%
    lat (msec) : 2000=0.01%
  cpu          : usr=1.58%, sys=8.30%, ctx=2936264, majf=0, minf=56
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=23526: Mon Nov 10 16:04:15 2014
  write: io=10240MB, bw=2702.6KB/s, iops=675 , runt=3879993msec
    slat (usec): min=10 , max=753 , avg=33.18, stdev=11.22
    clat (msec): min=2 , max=1696 , avg=47.33, stdev=52.42
     lat (msec): min=2 , max=1696 , avg=47.36, stdev=52.42
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    9], 10.00th=[   10], 20.00th=[   14],
     | 30.00th=[   17], 40.00th=[   21], 50.00th=[   28], 60.00th=[   39],
     | 70.00th=[   52], 80.00th=[   76], 90.00th=[  112], 95.00th=[  149],
     | 99.00th=[  233], 99.50th=[  269], 99.90th=[  408], 99.95th=[  603],
     | 99.99th=[ 1004]
    bw (KB/s)  : min=   38, max= 5844, per=100.00%, avg=2705.81, stdev=704.68
    lat (msec) : 4=0.25%, 10=10.57%, 20=28.90%, 50=29.07%, 100=18.80%
    lat (msec) : 250=11.70%, 500=0.64%, 750=0.05%, 1000=0.02%, 2000=0.01%
  cpu          : usr=0.66%, sys=3.18%, ctx=2422222, majf=0, minf=26
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=2621440/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=10240MB, aggrb=10660KB/s, minb=10660KB/s, maxb=10660KB/s, mint=983643msec, maxt=983643msec
  WRITE: io=10240MB, aggrb=2702KB/s, minb=2702KB/s, maxb=2702KB/s, mint=3879993msec, maxt=3879993msec
Оба запуска fio на одной системе к каким-либо нехорошим последствиям не привели. В одном LXC-контейнере на этом же ceph-кластере работает zabbix, в котором никаких просадок и пробелов в данных не появилось.

rados bench пока не запускал.

Deleted ()
Ответ на: комментарий от Deleted

Кстати, может ещё стоит попробовать собрать fio с поддержкой librbd и потестить через него (не через ядрёный драйвер).

Deleted ()

эта штука подойдет для создания своего масштабируемого файлового хранилища ?

Ien_Shepard ★★★ ()
Ответ на: Если не затруднит. от anonymous

А ещё есть команда тестирования производительности пула https://www.safaribooksonline.com/library/view/mastering-proxmox/9781783980826/ch07s11.html

rados –p <pool> bench –b <blockSize> <seconds> <seq> -t <threads>

Только не прерывайте её через ctrl-c, а то она не удалить за собой записанные в pool объекты.

Лучше просто отдельный пул специально для теста сделать. Всё равно для тестов на чтение нужно тест на запись запускать с опцией --no-cleanup.

Последний тест объектами по 4МБ у меня выдавал 500Мбит.

Именно Мбит/с, а не Мбайт/с? А какая у тебя была конфигурация сети?

Вот мои результаты:

  • rados bench -p test 600 write --no-cleanup
     Maintaining 16 concurrent writes of 4194304 bytes for up to 600 seconds or 0 objects
     Object prefix: benchmark_data_devenv-msk-08_4700
       sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
         0       0         0         0         0         0         -         0
         1      16        73        57   227.951       228  0.305075  0.242811
         2      16       133       117    233.96       240  0.596935  0.249348
         3      16       190       174   231.962       228  0.201958   0.26599
         4      16       259       243   242.964       276  0.195911  0.257791
         5      16       316       300   239.963       228   0.16573  0.258369
         6      16       387       371   247.297       284  0.193719  0.253001
         7      16       452       436   249.107       260  0.190949  0.252608
         8      16       515       499   249.465       252  0.122166  0.250916
         9      16       573       557   247.522       232  0.234176   0.25438
        10      16       637       621   248.367       256  0.418247  0.251898
        11      16       696       680    247.24       236  0.176406  0.255059
    ...
       586      16     31058     31042   211.864       232  0.102548  0.301992
       587      16     31114     31098   211.885       224  0.160875  0.301937
       588      16     31174     31158   211.932       240  0.291307  0.301884
       589      16     31225     31209   211.919       204  0.190229  0.301898
       590      16     31287     31271    211.98       248  0.137897  0.301838
       591      16     31343     31327       212       224  0.276236  0.301825
       592      16     31403     31387   212.047       240  0.631427   0.30172
       593      16     31452     31436    212.02       196  0.385603  0.301755
       594      16     31498     31482   211.973       184  0.138787  0.301784
       595      16     31538     31522   211.886       160  0.112782  0.301635
       596      16     31598     31582   211.933       240   0.47876  0.301891
       597      16     31639     31623   211.853       164  0.156965  0.301857
       598      16     31678     31662   211.759       156  0.162763  0.302061
       599      16     31717     31701   211.666       156  0.229722  0.301949
    2014-11-11 20:45:42.090245min lat: 0.081268 max lat: 31.0728 avg lat: 0.30191
       sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
       600      16     31748     31732    211.52       124   2.62677   0.30191
     Total time run:         600.497695
    Total writes made:      31748
    Write size:             4194304
    Bandwidth (MB/sec):     211.478 
    
    Stddev Bandwidth:       60.1976
    Max bandwidth (MB/sec): 296
    Min bandwidth (MB/sec): 0
    Average Latency:        0.302608
    Stddev Latency:         0.699768
    Max latency:            31.0728
    Min latency:            0.081268
    
  • rados bench -p test 600 seq
       sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
         0       0         0         0         0         0         -         0
         1      16        90        74   295.896       296  0.067515  0.184663
         2      16       153       137   273.935       252  0.445111  0.217381
         3      16       217       201   267.945       256  0.066606  0.228496
         4      16       286       270    269.95       276  0.182263  0.226791
         5      16       358       342   273.551       288   0.21932  0.225644
         6      16       428       412   274.621       280  0.081951  0.228123
         7      16       494       478     273.1       264  0.255283  0.227516
         8      16       562       546   272.958       272  0.062602   0.22942
         9      16       630       614   272.849       272  0.360211  0.230854
        10      16       691       675   269.962       244   0.19671  0.233422
        11      16       754       738   268.326       252  0.097721  0.234748
        12      16       823       807   268.963       276  0.143652  0.233531
    ...
       462      16     30848     30832   266.912       256  0.238638  0.239619
       463      16     30914     30898   266.906       264  0.374107  0.239635
       464      16     30980     30964   266.899       264    0.2809   0.23972
       465      16     31048     31032    266.91       272  0.131859  0.239686
       466      16     31117     31101    266.93       276  0.052077  0.239685
       467      16     31185     31169   266.941       272  0.172254  0.239656
       468      16     31254     31238    266.96       276  0.586703  0.239639
       469      16     31323     31307   266.979       276  0.150466  0.239596
       470      16     31399     31383   267.058       304  0.006773  0.239559
       471      16     31464     31448   267.043       260  0.314708  0.239548
       472      16     31539     31523   267.113       300  0.071781  0.239473
       473      16     31612     31596   267.165       292  0.314251  0.239459
       474      16     31672     31656   267.108       240  0.187781   0.23947
       475      15     31748     31733   267.194       308  0.037953  0.239376
     Total time run:        475.413140
    Total reads made:     31748
    Read size:            4194304
    Bandwidth (MB/sec):    267.119 
    
    Average Latency:       0.239546
    Max latency:           1.79166
    Min latency:           0.005053
    
Deleted ()
Ответ на: комментарий от Deleted
  • rados bench -p test 600 rand
       sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
         0       0         0         0         0         0         -         0
         1      16        80        64   255.933       256  0.340058  0.180347
         2      16       155       139   277.946       300  0.328795  0.213076
         3      16       219       203   270.621       256  0.040468  0.213916
         4      16       289       273   272.957       280  0.005754  0.225305
         5      16       353       337    269.56       256  0.363916  0.226344
         6      16       421       405    269.96       272  0.006489  0.227665
         7      16       488       472   269.676       268  0.308446  0.227703
         8      16       565       549   274.463       308  0.006316  0.227251
         9      16       630       614   272.853       260  0.313572  0.227175
        10      15       692       677   270.764       252  0.617107  0.231292
    ...
       587      16     39572     39556   269.515       264   0.12373  0.237354
       588      16     39637     39621   269.499       260  0.201585  0.237369
       589      16     39697     39681   269.449       240  0.668986  0.237445
       590      16     39761     39745   269.426       256  0.198098  0.237464
       591      16     39833     39817   269.457       288  0.058107  0.237417
       592      16     39905     39889   269.488       288  0.305546  0.237408
       593      16     39979     39963   269.533       296  0.063371  0.237384
       594      16     40040     40024    269.49       244  0.371092  0.237397
       595      16     40118     40102   269.561       312  0.154232  0.237334
       596      16     40186     40170   269.565       272  0.315898  0.237322
       597      16     40252     40236   269.556       264   0.02158  0.237357
       598      16     40328     40312   269.614       304  0.263567  0.237311
       599      16     40403     40387   269.664       300  0.325939  0.237231
    2014-11-11 21:23:14.174881min lat: 0.005056 max lat: 1.82856 avg lat: 0.237243
       sec Cur ops   started  finished  avg MB/s  cur MB/s  last lat   avg lat
       600      16     40469     40453   269.655       264   0.32297  0.237243
     Total time run:        600.315295
    Total reads made:     40469
    Read size:            4194304
    Bandwidth (MB/sec):    269.652 
    
    Average Latency:       0.237307
    Max latency:           1.82856
    Min latency:           0.005056
    

После каждого теста я на всех узлах кластера сбрасывал кеши.

Итого:

  • Средняя скорость записи: 211.478 Мбайт/с (1691.824 Мбит/с)
  • Средняя скорость последовательного чтения: 267.119 Мбайт/с (2136.952 Мбит/с)
  • Средняя скорость чтения вразброс: 269.652 Мбайт/с (2157.216 Мбит/с)

Если учесть, что у меня клиентская сеть двухгигабитная, то получилось вполне неплохо. Чтение вышло даже быстрее двух гигабит, так как тест запускался на системе вместе с одним из OSD, так что часть данных читалась по TCP/IP с локалхоста.

Deleted ()
Ответ на: комментарий от Deleted

Именно Мбит/с, а не Мбайт/с

Да, именно.

У меня 3 ноды. Соеденены 2-мя коммутаторами, использующимися как back-end и front-end сети. В каждой ноде по 2 диска 5200rpm (в некоторых были диски 7200). Скорость подключения к коммутаторам 1 Гигабит.

Именно по этому я в мегабитах приводил результат измерения. Я не выявил узкого места, склоняюсь к тому, что оборудование имеет какое-то аппаратное ограничение. Я использовал довольно старые сервера. Сейчас стенд уже разобран, сокет LGA775, память DDR2 8Гб. Я

думаю, что производительонсть могла упираться в пропускную способность шин. Ведь на нодах было несколько потоков данных, при записи: от клиента к нодам, между нодами по back-end сети, внутри нод к контрллеру дисков. Ситуация могла быть еще хуже при использовании cache-pool.

Планирую ближайшее время повторить тестирование на другом оборудовании и сделать сравнение с sheepdog.

В sheepdog мне нравится идея локального журналирования и кэширования на ssd - это уменьшает бесполезный поток данных между нодами и в то-же время, по идее, должно работать корректно при миграции виртуальных машин, вовремя сбрасывая данные из журнала в кластер.

riv1329 ()
Ответ на: комментарий от riv1329

Да, именно.

У меня 3 ноды. Соеденены 2-мя коммутаторами, использующимися как back-end и front-end сети. В каждой ноде по 2 диска 5200rpm (в некоторых были диски 7200). Скорость подключения к коммутаторам 1 Гигабит.

Именно по этому я в мегабитах приводил результат измерения. Я не выявил узкого места, склоняюсь к тому, что оборудование имеет какое-то аппаратное ограничение. Я использовал довольно старые сервера. Сейчас стенд уже разобран, сокет LGA775, память DDR2 8Гб. Я

думаю, что производительонсть могла упираться в пропускную способность шин. Ведь на нодах было несколько потоков данных, при записи: от клиента к нодам, между нодами по back-end сети, внутри нод к контрллеру дисков. Ситуация могла быть еще хуже при использовании cache-pool.

Возможно всё упёрлось именно в диски. У меня вот тоже скорость записи скорее всего в диски упирается. Запуск теста fio просто на локальных дисках делает систему вообще неюзабельной на несколько часов =).

Планирую ближайшее время повторить тестирование на другом оборудовании и сделать сравнение с sheepdog.

Будет очень хорошо, если ты выложишь результаты где-нибудь здесь на ЛОРе.

Deleted ()
Ответ на: комментарий от Deleted

Будет очень хорошо, если ты выложишь результаты где-нибудь здесь на ЛОРе.

Разумеется, и тебя уведомлю по e-mail.

riv1329 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.