Corosync: положу вашу сеть. Быстро, дешево, качественно. #2
Продолжение. Начало здесь.
Ещё в прошлый раз выяснилось, что коммутаторы ни при чём. С тех пор мы построили отдельный полностью независимый физический сегмент сети. Взяли отдельный свитч, раскидали от него провода до отдельных сетевух в серверах, перенесли управляющий трафик от corosync-а на эту отдельную сетку, и... проблема осталась в своём первоначальном виде.
То есть, когда начинаешь собирать кластер (на отдельной изолированной сети безо всяких там транков-агрегаций), падает прод на соседней сети. Из чего можно сделать вывод, что corosync-овский трафик тупо забивает буфера приёма-передачи Linux-ового ядра. До такого состояния, что ядро перестает реагировать на LACP PDU.
Осталось понять на каком именно этапе начинает "захлёбываться" обработка. Но учитывая, что счётчик dropped frames на самой сетевухе не растёт, больше похоже, что затык где-то на этапе копирования страниц памяти из DMA-кольца в адресное пространство ядра. Либо выход за пределы бюджета поллинга.
Кодеры cosorync-а, конечно, молодцы, что слов нет. Это называется, "с такими друзьями врагов не надо". Сам установил, сам запустил, сам же свой прод и положил. Красота!
Пока не совсем ясно, валится ли оно по исходящему трафику или по входящему. Но вероятнее последнее, т.к. исходящий PPS там точно не превышает 2000 (проверено экспериментально). А вот входящий может запросто оказаться под 50...60 kPPS, но пока это только догадки.
Дальше будем пробовать увеличивать бюджет поллинга NAPI, расширять буфера, привязывать конкретные очереди конкретных Ethernet-портов к конкретным ядрам (CPU affinity), отвязывать софт и прочие прерывания от "сетевых" ядер. Изгаляться, короче.
В этой всей истории больше всего неприятны три обстоятельства.
- На проде особо не поэкспериментируешь, а в лабораторных условиях такую ситуацию не воспроизведёшь.
- Даже если мы докопаемся до причин, вряд ли сможем их в корне исправить. Потому что по всей видимости, это сугубо архитектурные просчеты в самом corosync-е.
- Production-нагрузка (весьма немаленькая кстати) не способна даже рядом уложить сетку / серваки с такой лёгкостью, как это делает какая-то сугубо вспомогательная служебная софтинка.
Мне вот искренне интересно, может ли хотя бы чисто теоретически в данной ситуации как-то помочь OpenVSwitch. Он же изначально разрабатывался с таким прицелом, чтобы подменить собой "родной" драйвер сетевого адаптера и отстранить ядро от процесса обработки сетевого трафика, копируя данные напрямую из буфера сетевого адаптера сразу в приложение. Правда, и приложение в таком случае должно понимать такой "финт ушами". Что-то мне не верится, что corosync относится к подобной категории.
Словом, развлекуха продолжается.