Симуляция зашумленной глючащей сети

конечно есть

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

dummynet какой-нибудь.

Если есть вайфай, и все машины действуют по беспроводу, то адски непотребные условия можно устроить при помощи aircrack-ng

Успешно использовал netem для воспроизведения потери udp multicast пакетов через vpn канал(хотя это и не возможно, но доступ к живым данным был только такой, а делать тестовый разъём не было времени). Деталей не помню, но инструменты есть.

Помню был замешан в моём случае ещё iptables, поэтому видимо стоит ознакомиться со статьями вроде этой.

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

я обычно сторонник безумной сложности (чем сложнее - тем лучше, во имя Сатаны!). Но сейчас нет ни времени, не сил, просто хочется найти проблему, почему не собирается кластер, и пойти спать :( А чтобы найти проблему, ее нужно вначале симулировать на тестовой площадке...

похоже, придется разбираться :((

Ну тут всем нужны слишком разные случаи обычные. Вариант либо фрилансера нанять, либо посмотреть на готовые решения применимые к твоему конфигу. Ключевые слова netem <your cluster solution> qdisc.

Вот для докера чет гуглиться(чего именно не читал).

Кстати если там замешан pacemaker, там вроде что-то своё в virtual-ip было.

Но сейчас нет ни времени, не сил, просто хочется найти проблему, почему не собирается кластер, и пойти спать :(

Хм... Так с начала проспись, а потом, наверное, и симуляция не понадобится. :)

Вот тут можно найти примеры:

https://wiki.linuxfoundation.org/networking/netem

А разве можно эффективно найти изъяны, не зная куда нужно точно бить, по каким слабым местам? Вряд ли есть общее решение. Так почти во всем. Общие универсальные решения обычно ни о чем.

Мы когда тестировали средней сложности сетевой софт, писали специальные тесты. Я так понимаю, у вас система по сложнее будет, а значит, и тесты нужны еще более продуманные

узнать куда бить технически невозможно - это совершенно закрытая площадка, про которую нет вообще никаких данных кроме «кластер разваливается». Можно попробовать устранить самые часто встречающиеся изъяны за короткое время, ну и скажем полгода - чинить всё подряд, что придет в голову. И потом через полгода проверить, починилось ли.

Стек corosync/pacemaker в распределённой географически сети или на виртуалках без 100% выделенных ядер под таковые? Какое время отклика (пинг) между нодами?

Я года два назад трахался с таким кластером месяца 4, в итоге кластер был выкинут и задействовано альтернативное решение. Не живёт corosync ни в случае пинга выше 3-4 мс, ни в условиях виртуализации толком.

Точнее, с пингом там хитрее, зависит ещё от числа нод, но поскольку это виртуальное кольцо - считайте время доставки сообщения суммой всех пингов нод по кольцу (1-2-3-...-последняя-1). К времени доставки по кольцу в конфиге коросинка де факто прибит ряд параметров, если сетка «длинная», их надо тюнить. Теоретически там и при 50 мс всё должно работать, практически - работает кое-как. Может быть в случаях виртуалок сказывается ещё то, что процесс коросинка не всегда успевает исполняться в назначенное время.

Впрочем, может у вас и не corosync, так что дальше в детали лезть не буду.

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

До 100 мс - да, это уже печаль. Но тут надо детально разбираться, «править всё» не поможет. Придётся привлекать сетевых инженеров.

Если хочется засимулировать сферическое ужасное в вакууме - деградируйте линк до 10 мегабит на свитче, добавьте random drop через iptables (например так: -m statistic --mode random --probability 0.1 -j DROP), добавьте задержки через tc/netem.

Вот здесь расписано кем-то подробно: https://habrahabr.ru/post/237217/

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

Если хочется адаптировать систему на устойчивость: для начала откажитесь в критических к таймингу местах кластерного стека от TCP, чтобы избежать огромных задержек при больших потерях пакетов. Вообще при этом лучше всего если heartbeat-протокол сам по себе stateless, тогда потери сильно не страшны, и можно свободно варьировать тайминги/трафик в зависимости от состояния сети, но не знаю, ваш ли это случай.