ага

В пиках до 13-14?

попробуй прометеус, там готовые метрики и интеграция с графаной

да я телеграф с инфлаксом заебенил

пики до 10-13 где-то

да я телеграф с инфлаксом заебенил

что за телеграф?

https://github.com/influxdata/telegraf

https://github.com/influxdata/telegraf/tree/master/plugins/inputs/ceph - плагин для ceph

попробуй прометеус, там готовые метрики и интеграция с графаной

Паша Прометей советует, завтра опять морозы будут

https://github.com/influxdata/telegraf

говно, потому что exec

гы, а прометеевский похоже через rados работает

гы, а прометеевский похоже через rados работает

Ага

Там на go exporter написан

мы ж про https://github.com/digitalocean/ceph_exporter

?

Да

угу

Я его вертел

можно телеграф попатчить наверное

Я его вертел

в смысле "да вертел я его"? )

можно телеграф попатчить наверное

горбатого могила исправит. всмысле, MogileFS.

http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-September/004194.html

We also just started having our 850 Pros die one after the other after about 9 months of service. 3 down, 11 to go... No warning at all, the drive is fine, and then it's not even visible to the machine. According to the stats in hdparm and the calcs I did they should have had years of life left, so it seems that ceph journals definitely do something they do not like, which is not reflected in their stats.

https://wiki.fd.io/view/VPP_Sandbox/turbotap

горбатого могила исправит. всмысле, MogileFS.

больше похоже на костыль ЖЖ, который выкинули в опенсоурс

больше похоже на костыль ЖЖ, который выкинули в опенсоурс

Ты про телеграф?

Ты про телеграф?

MogileFS

MogileFS

То была скорее шутка про название. Но да, хз зачем оно надо

@spuzirev ты сегодня про свой сетап ceph рассказывал. А что у тебя за сеть?

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

@spuzirev ты сегодня про свой сетап ceph рассказывал. А что у тебя за сеть?

4х1g на хост, одна сеть, шейпинг поверх

Но это легаси.

мы планировали расти там. будет, скорее всего, 10g на хост, 400g (или 240g) на стойку, spine-leaf, leaf - 48x10G+4x100G (или 48x10G+6x40G), spine - 32x100G (или 32х40G)., первая итерация роста - до 80 хостов мб. сеть немного оверкилл, но с заложенным потенциалом для роста.

4х1g на хост, одна сеть, шейпинг поверх

оно вам для образов виртуалок?

и есть какие-то цифры в плане скорости такой конструкции?

Щас основное использование - rgw, расширение будет для rbd.

и есть какие-то цифры в плане скорости такой конструкции?

Мм, кластера сефа в такой конфигурации сети у меня нет. Он умозрителен.

В целом клос сети - ок, но есть нюансы.

Щас основное использование - rgw, расширение будет для rbd.

Привет! А расскажи плз, что за диски у вас под осд и как журналы сделаны - на этих же винтах разделами или отдельно ssd нашинкованы?

2Т диски, 8hdd+2ssd для журналов на каждой ноде. Диск содержит один раздел, xfs.

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

видимо, пора тоже думать в сторону ssd под osd

у нас 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

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

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

красивости