Обчитался про rabbitmq. Выяснил, что в тестах я его неправильно готовил, отчего кластер в виртуалке докера показал 200-220msgs/s, что маловато. Надо было использовать не всякие amqp-tools, что закрывают соединение после каждого сообщения, а таки понаписать что-нибудь на питоне. Впрочем, целью был не бенчмарк, а отработка работы с rabbitmq вообще и кластеризации в частности. Кластеризация работает как ожидалось.
2017-05-29 10:28:51

Участники:
@stanislavv - 12, @alex0b - 10, @oxpa - 5

@oxpa
кролик, говорят, надёжный, но медленный. Типа есть очереди шустрей
#2872884/1 2017-05-29 10:29:31
@alex0b
Херовато кластер себя чувствует при конце системных ресурсов на одной из нод (диск/ОЗУ). То что эта нода оживает только после ребута (и не всегда) это полбеды. Вот то что она может весь кластер подогнуть -вот что не ок. В общем нормальная штука, если не забрасывать и мониторить.
#2872884/2 2017-05-29 18:41:04
@stanislavv
При планируемой нагрузке оно съест вряд ли больше четверти минимальной вдс по памяти. Вот диск может... Впрочем, то, что один узел может накрыть весь кластер - не есть правильно...
#2872884/3 → /2 2017-05-30 06:15:56
@alex0b
не гарантировано, но преценденты были. прям вчера кластер из 6 нод разделился на два по три из за такой херни (кончился диск на одной из нод). причем реджоин смогли сделать только ребутом. хз, мы не админы, а разработчики, может что-то не понимаем/ не знаем. к слову, у него особое поведение при _штатном_ выключении/рестарте нод: порядок выключения/включения нод должен быть согласован - кто последний выключен, тот должен быть первым и включен быть.
#2872884/4 → /3 2017-05-30 06:21:47
@stanislavv
Понял, автоматически в случае чего кластер не поднимется... Ок, смотрим в сторону nsq или nats...
#2872884/5 → /4 2017-05-30 06:24:09
@alex0b
там есть настройки для этого: мы сейчас врубили - рестартовать ноду автоматом. смотрим. ну а в целом она у нас в продакшене на более сотни площадок. проблемы конечно были (с кем их не бывает?), но все так или иначе решаются. главное у нее довольно годная документация. я бы сказал больше что "да", чем отговаривал от ее использования.
#2872884/6 → /5 2017-05-30 06:32:40
@alex0b
ну и я говорил о штатном - если нода завешилась нештатно то включается алгоритм разрешения конфликтов
#2872884/7 → /5 2017-05-30 06:34:53
@stanislavv
Штатно кластер вообще не планируется выключать. Меня больше интересует вопрос на тему: а поднимется ли кластер кластером, если виртуалки будут жестко выключены...
#2872884/8 → /7 2017-05-30 06:37:43
@alex0b
тут вроде бы проблем не наблюдали, штормили их изрядно. есть ряд вопросов уже по поводу разработки, о том как надо создавать точки обмена, очереди, кто/как с какими настройками/политиками их декларирует. например из жестого: разработчик создает очередь durable (пакет кладетс на диск, во избежание потери), но очередь не кластеризует (ha), хотя кластер из двух нод. очередь создалась на home-ноде, а ее вырубают. на второй, соответсвенно ее нет, она переходит в состоние down. все ппц, приложение падает, матерится ничего сделать не может. кто дурак на самом деле понятно - надо правильно настраивать. или второй вариант: есть ha-очередь и в ней есть сообщения не доставленные, ребутаем master-ноду, а затем, вроде и дождавшись пока вторая _повыстся до мастера_ ребутаем и ее. есть вариант успеть до того как оно на самом деле перетечет (хотя отрапортовало) и в итоге получим очередь состояние которой вообще не понятно. всё, пора разваливать кластер и собирать заново.
#2872884/9 → /8 2017-05-30 06:51:45
@stanislavv
Ясно, такое лучше автоматизировать...
#2872884/10 → /9 2017-05-30 06:57:11
@alex0b
у нас есть тестировщик "быстрые-руки", именно он такие штуки обычно находит
#2872884/11 → /10 2017-05-30 06:58:08
@stanislavv
У нас вакансия тестировщика пока только открывается... Компания всё ж не разработкой занимается.
#2872884/12 → /11 2017-05-30 07:02:20
@oxpa
почитав комментарии: три года держал 3 инстанса на трёх нодах с десятком очередей. Всё что угодно было (винт переполнялся, ребутали по 1 и 2 нодам), но жило оно распрекрасно само и никогда не приходилось в него лезть, кроме первоначальной настройки. Но как ты понимаешь, 3 ноды это не сотня площадок )
#2872884/13 2017-05-30 08:53:53
@alex0b
на сотне площадок у нас по две ноды в кластере, и проблемы там все типичные. оно там фактически в необслуживающемся режиме: местные админы не лазают без нас, а для того чтобы они знали что нам надо написать, мы запилили службу мониторинга, которая сама некоторые проблемы решать пытается. многонодные кластера у нас внтури. резюмируя: все проблемы, которые я видел, из-за кривых рук и невнимательного чтения документации, не знания вариантов использования. кроме одной: была версия 3.6.3, которая иногда роняла самопроизвольно одну из нод (под виндой), хз почему.
#2872884/14 → /13 2017-05-30 08:58:31
@stanislavv
у меня очередей планируется пара сотен уже сейчас (если выносить из локальных gearmand)...
#2872884/15 → /13 2017-05-30 09:04:23
@oxpa
у меня там были зеноссовские очереди, которые достаточно активные (через них проходит обработка событий, а это сотни-тысяч item'ов в секунду иногда). И оно норм жевало. (Затыкалась ява, которая их разгребала, впрочем)
#2872884/16 → /15 2017-05-30 09:05:33
@stanislavv
Под чем крутилось в смысле ресурсов?
#2872884/17 → /16 2017-05-30 09:06:08
@oxpa
чтоб я помнил... ну что-то не шибко мощное: хьюлет, 4 винта в raid10, памяти гига 32. Но в те же 32 гига влезала ещё и zope с явой, которые всё это обрабатывали. И 4 инстанса zope сжирали около 20 гигов, чтоли.
#2872884/18 → /17 2017-05-30 09:08:35
@stanislavv
Меня больше процессор интересует. На конфигурации, когда 2 ядра отдавались 3 контейнерам, было не шибко быстро - порядка 200-220 публикаций в секунду. Конфиг - пустой, если что. Точнее, меня интересует - это нормально для такой конфигурации или какой-то глюк?
#2872884/19 → /18 2017-05-30 09:11:12
@oxpa
без понятия: ядер было 12 (с учётом HT) и использовались в моём случае 8+ всегда (la ниже 8 не падал). Но прям что кролик жрёт цпу я не видел. Я всегда упирался в другой софт. Но вообще, 200 сообщений в секунду, кажется, достаточно низким показателем даже для rmq (хотя он небыстрый, говорят)
#2872884/20 → /19 2017-05-30 09:16:01
@stanislavv
Именно поэтому и засомневался - уж больно маловато.
#2872884/21 → /20 2017-05-30 09:16:54
@alex0b
вот, да. мы своим основным софтом не смогли его ушатать, затыкались на вычерпывании.
#2872884/22 → /20 2017-05-30 09:48:17
@stanislavv
Хм... В моём случае вычёрпывалось в 4 потока со скоростью порядка 500-600 сообщений/сек. Проблемы были с отправкой.
#2872884/23 → /22 2017-05-30 09:53:17
@alex0b
Скажем так, нас вообще интересовала гарантированность доставки куда больше чем скорость.
#2872884/24 → /23 2017-05-30 09:56:32
@stanislavv
Это меня тоже интересует, но тут всё больше зависит от настроек очереди, если нет внезапных проблем. Но 200 сообщений в секунду - это всё ж маловато, причём иногда были проблемы с отправкой (порядка 0.1-0.2%), когда пытался запустить ещё один поток отправки.
#2872884/25 → /24 2017-05-30 10:03:03
@alex0b
для информации, ты на какой версии тестируешь?
#2872884/26 → /25 2017-05-30 10:30:02
@stanislavv
3.6.9
#2872884/27 → /26 2017-05-30 10:42:40