у нас 4T hdd и чото боль при скрабе возникает порой

без ssd под журналы?

у нас 4T hdd и чото боль при скрабе возникает порой

делайте скраб ночью по крону

без ssd под журналы?

Нет, для журналов партиция SSD ... /dev/sda : /dev/sda1 other, 21686148-6449-6e6f-744e-656564454649 /dev/sda2 other, linux_raid_member /dev/sda3 ceph journal, for /dev/sde1 /dev/sda4 ceph journal, for /dev/sdf1 /dev/sda5 ceph journal, for /dev/sdh1 /dev/sde : /dev/sde1 ceph data, active, cluster ceph, osd.1, journal /dev/sda3 ...

Приветствую, подскажите пожалуйста, если кто вкурсе,- нужно ограничить запуск ВМ без диска в cinder только определенными compute нодами, смотрю в сторону кастомного фильтра для nova scheduler, но не понимаю как определить стартует ВМ с диском в cinder или локальным, в 'filter_properties -> request_spec -> instance_properties' вижу только что параметр 'image_ref' пустой при запуске Вм с cinder диском, но этот параметр будет заполнен если "кто-то" сделал rebuild ВМ с указанием образа, а затем попытался сделать resize.

делайте скраб ночью по крону

Типа osd scrub begin/end hour ?

хм, спасибо за совет

Типа osd scrub begin/end hour ?

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

ok, попробую так пожить - посмотрим, спасибо!

https://gitlab.cern.ch/ceph/ceph-scripts/blob/master/tools/scrubbing/ceph-scrub-summary.py

скриптик для скрабинга

Приветствую, подскажите пожалуйста, если кто вкурсе,- нужно ограничить запуск ВМ без диска в cinder только определенными compute нодами, смотрю в сторону кастомного фильтра для nova scheduler, но не понимаю как определить стартует ВМ с диском в cinder или локальным, в 'filter_properties -> request_spec -> instance_properties' вижу только что параметр 'image_ref' пустой при запуске Вм с cinder диском, но этот параметр будет заполнен если "кто-то" сделал rebuild ВМ с указанием образа, а затем попытался сделать resize.

Не уверен, что совсем правильное решение и имеено то, что ты хочешь. А не лучше ли сделать разные flavor для этого? Один для дисков локальных, один - только cinder. Для разных flavor в properties запихиваешь aggregate_instance_extra_specs, включаешь фильтр AggregateInstanceExtraSpecsFilter, compute на которых надо и не надо запускать инстансы с cinder-диском объединяешь в разные host aggregates

Не уверен, что совсем правильное решение и имеено то, что ты хочешь. А не лучше ли сделать разные flavor для этого? Один для дисков локальных, один - только cinder. Для разных flavor в properties запихиваешь aggregate_instance_extra_specs, включаешь фильтр AggregateInstanceExtraSpecsFilter, compute на которых надо и не надо запускать инстансы с cinder-диском объединяешь в разные host aggregates

да, спасибо, думал над таким решением, но оно нам мало подходит- это надо дублировать все flafor , плюс в целом есть ноды на которых можно запускать ВМ и с диском в cinder и с локальным, при таком подходе будет жесткое разделение- здесь мы стартуем только ВМ с cinder, а здесь только локальные.

дублирование flavor - да, не так удобно разделение серверов - нет, host aggregates в отличие от availability zone могут пересекаться, т.е. хост может быть сразу в нескольких host aggregate`ах, если только это не AZ

дублирование flavor - да, не так удобно разделение серверов - нет, host aggregates в отличие от availability zone могут пересекаться, т.е. хост может быть сразу в нескольких host aggregate`ах, если только это не AZ

вот за это спасибо- не знал, но дублирование flavor уже плохо- у клиентов путаница может быть

@socketpair ку, а ты не сохранил у себя нигде список что ты сюда выкидывал по твоему best choice по хардам? Я чет не могу найти нормально его((

benching Model=OCZ-TRION150 RAW: Write cache: True, iodepth: 1, sync: True => 938 IOPS RAW: Write cache: True, iodepth: 32, sync: True => 11127 IOPS RAW: Write cache: False, iodepth: 1, sync: True => 903 IOPS RAW: Write cache: False, iodepth: 32, sync: True => 981 IOPS benching Model=Samsung SSD 850 PRO 256GB RAW: Write cache: True, iodepth: 1, sync: True => 918 IOPS RAW: Write cache: True, iodepth: 32, sync: True => 9827 IOPS RAW: Write cache: False, iodepth: 1, sync: True => 415 IOPS RAW: Write cache: False, iodepth: 32, sync: True => 8899 IOPS benching Model=Corsair Force GT RAW: Write cache: True, iodepth: 1, sync: True => 2269 IOPS RAW: Write cache: True, iodepth: 32, sync: True => 14624 IOPS RAW: Write cache: False, iodepth: 1, sync: True => 19603 IOPS RAW: Write cache: False, iodepth: 32, sync: True => 15167 IOPS benching Model=OCZ-VERTEX3 RAW: Write cache: True, iodepth: 1, sync: True => 1127.89 IOPS RAW: Write cache: True, iodepth: 32, sync: True => 22032.25 IOPS RAW: Write cache: False, iodepth: 1, sync: True => 15133.19 IOPS RAW: Write cache: False, iodepth: 32, sync: True => 33692.46 IOPS benching Model=OCZ-VECTOR150 RAW: Write cache: True, iodepth: 1, sync: True => 348 IOPS RAW: Write cache: True, iodepth: 32, sync: True => 3825 IOPS RAW: Write cache: False, iodepth: 1, sync: True => 27814 IOPS RAW: Write cache: False, iodepth: 32, sync: True => 85686 IOPS

@AnswerX

Одно не пойму, почему на ссд отключение кэша ПОВЫШАЕТ иопсы?

а на магнитных понижает

кэш ссд против записи на ссд?

Я наверное что-то не так понимаю

Кэш ssd против кэш хдд?

няня я у них поел

Добрый день! Есть небольшая инсталляция CEPH как RBD для виртуаллок, Время от времени в логах цефа мелькает что-то подобное : 2017-01-11 05:05:14.794513 osd.24 1.31.101.2:6826/13859 433 : cluster [WRN] 5 slow requests, 1 included below; oldest blocked for > 31.094524 secs 2017-01-11 05:05:14.794517 osd.24 1.31.101.2:6826/13859 434 : cluster [WRN] slow request 31.094221 seconds old, received at 2017-01-11 05:04:43.700249: osd_op(c lient.3683335.0:29076167 12.e28bc218 rbd_data.35594b3078dd49.00000000000000c4 [stat,set-alloc-hint object_size 4194304 write_size 4194304,write 3850240~16384] sna pc 0=[] ack+ondisk+write+known_if_redirected e12031) currently waiting for rw locks

Может быть кто-то глубже погружался в вопрос, с чем могут быть связаны эти задержки на OSD ?

Нагрузка на кластер вот такая: 2017-01-11 05:05:28.348193 mon.0 1.31.101.1:6789/0 1498935 : cluster [INF] pgmap v10794138: 726 pgs: 2 active+clean+scrubbing+deep, 724 active+clean; 5964 GB da ta, 17862 GB used, 34520 GB / 52382 GB avail; 101613 B/s rd, 40109 kB/s wr, 7038 op/s

John, привет погляди историю повыше, похоже, такая же история, что и в моём случае

John, привет погляди историю повыше, похоже, такая же история, что и в моём случае

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

Возможно причина в активности active+clean+scrubbing+deep, и она порядочно нагружает OSD

в нашем случае просто SATA-винты не вывозят когда PG скрабится и в неё приходит клиент за данными, начинаются тупняки если смотреть в мониторинг, то у харда как раз ~120 МБ/с на чтение в это время

пацаны из firstvds вообще махнули шашкой и поставили SSD для OSD https://habrahabr.ru/company/first/blog/314106/

И те кто ceph гоняет, что у вас за сеть?

2X10G под internal и 2x10G под external, хотя под external 2x10G пока сильно избыточно выходит.

в нашем случае просто SATA-винты не вывозят когда PG скрабится и в неё приходит клиент за данными, начинаются тупняки если смотреть в мониторинг, то у харда как раз ~120 МБ/с на чтение в это время

У нас SAS 10K + журнал на SSD , да похоже, что не вытягивает....

Я ещё не пробовал скраббинг по расписанию запускать Но, судя по тому, что у Церна есть специально нарисованный для этого скрипт, такая необходимость, всё-таки, существует 😄

Я ещё не пробовал скраббинг по расписанию запускать Но, судя по тому, что у Церна есть специально нарисованный для этого скрипт, такая необходимость, всё-таки, существует 😄

У Вас FT ? или Erasure code ?

У Вас FT ? или Erasure code ?

FT?

FT?

Сорри, replicated =)

Я ещё не пробовал скраббинг по расписанию запускать Но, судя по тому, что у Церна есть специально нарисованный для этого скрипт, такая необходимость, всё-таки, существует 😄

Нам помогло это ослабить проблему со слоу реквестс

Сорри, replicated =)

Ага, у нас replicated size = 3 min_size = 2 по дефолту

Ага, у нас replicated size = 3 min_size = 2 по дефолту

А тиринг есть ? Есть у меня идея попробовать tier1 из 5-х SSD над медленными 7200... На сколько оно вобще юзабельно будет по скорости.

А тиринг есть ? Есть у меня идея попробовать tier1 из 5-х SSD над медленными 7200... На сколько оно вобще юзабельно будет по скорости.

Была мысль попробовать, но потом отказались (по крайней мере, на время) - решили сперва максимум выкрутить из того, что имеется. Абзац документации http://docs.ceph.com/docs/master/rados/operations/cache-tiering/#a-word-of-caution меня слегка напряг. Пока что у нас основной профиль - это rgw. Когда rbd более активно использовать будем, вероятно, придётся и тиринг поковырять.

А тиринг есть ? Есть у меня идея попробовать tier1 из 5-х SSD над медленными 7200... На сколько оно вобще юзабельно будет по скорости.

возможно недочитал выше, а у тебя проблема с медленной записью или чтением ?

возможно недочитал выше, а у тебя проблема с медленной записью или чтением ?

Нет проблем нет, есть простой FR=3 , теоретически хочется понять , какие плюшки и какие проблемы нам дам использование тира из SSD над медленными дисками без журналов на ssd

Нет проблем нет, есть простой FR=3 , теоретически хочется понять , какие плюшки и какие проблемы нам дам использование тира из SSD над медленными дисками без журналов на ssd

у тайринга есть преимущество имхо только одно — быстрое чтение, ибо кешируется. А быструю запись имхо лучше реализовать через журналы на SSD.

у тайринга есть преимущество имхо только одно — быстрое чтение, ибо кешируется. А быструю запись имхо лучше реализовать через журналы на SSD.

+

при том с тирингом может вылезти куча сайд эффектов и архитектурных проебов, что и сказано в соответствующей доке

Энти SSD-журналы будут работать для всех пулов. А вот писание через тайринг требует чтобы все кто хотят быстро писать чтобы пейсали только в этот спецпул

@socketpair увидел твой список, thanx!

https://wiki.openattic.org/display/OP/List+of+Other+Ceph+Management+Tools

что из этого не говно?

https://wiki.openattic.org/display/OP

Нахрен вам эти дашборды

Нахрен вам эти дашборды

красивости

Юзал каламари, видел vsm. Оба говно

Vsm емнип нельзя прикрутить к существующему кластеру

каламари умерло. и требует старую еблунту

красивости

прометей с графаной прикрути, красивей будет и гибче

а мне надо кнопочки. типа удалить рбд образ например

а мне надо кнопочки. типа удалить рбд образ например

нарисуй

тыжпрограммист

rm-rbd.sh ))

господа, никто не пытался пользоваться rados на уровне k->v?

Нет проблем нет, есть простой FR=3 , теоретически хочется понять , какие плюшки и какие проблемы нам дам использование тира из SSD над медленными дисками без журналов на ssd

Вот тут чуваки tiering пробовали: http://www.osris.org/article/2016/11/16/ceph-cache-tiering-with-liqid-nvme-at-sc16

Ребят, а с cephfs имели кто дело? Говорят что там все печально

хороший вброс

)

@iaml1989

Вроде бы

хороший вброс

Прошу прощения если не так выразился

да, там всё печально

Потому что от других коллег узнал что ceph вполне норм , а cephfs не очень

но чтобы это понять надо самому её попытаться поднять под гентой из сорцов

но чтобы это понять надо самому её попытаться поднять под гентой из сорцов

Хорошая шутка

к сожалению, это не шутка, /me имел такой опыт

Под гентой чтобы совсем весело было?

Или личной жизни совсем нету?

откуда такое мнение про генту? НА "ОБС"?

/me работать, буду пожже если будут вопросы или желание поспорить :)

откуда такое мнение про генту? НА "ОБС"?

Ну под генту никто в продакшн сервера не пилит. Тоже самое можно сделать и под centos и под ubuntu, только без этой дрочи с сорцами

НА "ОБС", отсюда видно. Пока не потрогаеншь своими руками хотя бы в течении пары лет плотно - не поймешь. Все, я работать