LINUX.ORG.RU

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

 


0

1

Господа, а есть какой-нибудь способ на кластере виртуальных машин симулировать состояние сети, в которой происходит ужасное?

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

Рутовый доступ к машинкам есть, к гипервизору - нет.

Есть какой-нибудь готовый софт, чтобы не писать самому?

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

★★★★☆

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

Ip0 ★★★★ ()

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

essir ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1 )
Ответ на: комментарий от stevejobs

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

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

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

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

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

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

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

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

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

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

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

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

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

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