[morf]

34 минуты назад, maa1 сказал:

morf

Выводы по виртуальным средам, номер раз:

- худшие результаты были на гипервизорах с использованием паравиртуальных сетевых драйверов (Vmxnet3). В ~4-6 раз хуже самых лучших результатов + куча дропов.

 

Ваше мнение - это проблема ROS или проблема ESXi?

вы писали в поддержку микротика с этой проблемой?

вы пробовали последнюю версию ESXi 7 U2?

1. Это не проблема ROS, это скорее проблема слишком больших накладных расходах: виртуальный сетевая, виртуальный свитч, сетевая подсистема самой хостовой машины. Тем более аналогичная проблема воспроизводилась на разных гиппервизорах: esxi, xen, proxmox.

2. Не думаю, что это их проблема. Я пробовал использовать VyOS и получил +- похожие результаты.

3. Тогда почему на других гипервизорах ситуация воспроизводится ?

 

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

Изменено 15 марта, 2021 пользователем morf

[maa1]

morf

это скорее проблема слишком больших накладных расходах: виртуальный сетевая, виртуальный свитч

мне кажется - это просто особенность использования виртуальных подсистем

Но на виртуализации гоняют не только маршрутизаторы, но и гораздо более серьёзные вещи. И если бы и там наблюдались описанные вами проблемы ( В ~4-6 раз хуже самых лучших результатов + куча дропов ), то VMware давно бы поставили раком.

Так что более вероятна проблема во взаимодействии ROS и виртуализации.

 

Не думаю, что это их проблема. Я пробовал использовать VyOS и получил +- похожие результаты

Они обе на базе Linux.

Ради интереса - наблюдаются ли проблемы с pfSense/OPNsense (которые на FreeBSD)?

[Saab95]

2 часа назад, maa1 сказал:

Но на виртуализации гоняют не только маршрутизаторы, но и гораздо более серьёзные вещи.

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

 

Если сравнить с неким нагруженным WEB сервером, или базой данных, то там операции уже уходят в другие подсистемы сервера, и виртуалка не нагружается до упора по одному направлению действия.

[morf]

8 часов назад, maa1 сказал:

ади интереса - наблюдаются ли проблемы с pfSense/OPNsense (которые на FreeBSD)?

Кстати, да. Забыл упомянуть про pfsense. Я о нем писал в самом начале темы. Те же грабли только сбоку. При одинаковом трафике, но разных гиппервизорах и разных программных маршрутизатора огромная разница по использованию CPU сервера. Я на такое не согласен. 

Изменено 15 марта, 2021 пользователем morf

[jffulcrum]

6 часов назад, maa1 сказал:

Так что более вероятна проблема во взаимодействии ROS и виртуализации.

Что на Hyper-V, что на Vmware объективно есть проблемы с утилизацией сетевого интерфейса более чем на 70% - обычно это не удается. Сделать можно немногое: уходить на большую канальную скорость в принципе, привязываться к LACP тиме (если трафик многие к одному), SR-IOV (но тут уже прощай миграция и т.п.).

 

Что кассется хреновых результатов топикстартера именно на VmWare, то сдается мне, не были соответствующим образом увеличены ring buffers. Статейка старая, но из разряда "о вечном". Плохая новость, что я сам сталкивался с игнорированием любых выставляемых значений в гостевой машине с Linux - видимо, зависит от конкретной версии драйвера виртуальной сети в поставке. 

[morf]

2 часа назад, jffulcrum сказал:

Что кассется хреновых результатов топикстартера именно на VmWare, то сдается мне, не были соответствующим образом увеличены ring buffers.

Напоминает танцы с бубном, но справедливости ради, хочу напомнить, что ROS я так же поднимал на XenServer и Proxmox. Ничего нового.

 

Вообще вся эта свистопляска с виртуализацией была затеяна только ради High Available с автоматической миграцией и запуском на резервном серваке. 

Изменено 15 марта, 2021 пользователем morf

[maa1]

morf

- SR-IOV не поддерживается RouterOS от слова вообще.

 

Начиная с 7.1beta3 поддерживается. Вы не тестировали?

[morf]

48 минут назад, maa1 сказал:

morf

- SR-IOV не поддерживается RouterOS от слова вообще.

 

Начиная с 7.1beta3 поддерживается. Вы не тестировали?

Вы верно заметили, но на момент публикации темы SR-IOV еще не поддерживался. К сожалению, сейчас нет возможности поднять стенд. SR-IOV это, по-сути, виртуальные адаптеры сетевой карты, только прокинутые в виртуалку. Не знаю, уменьшает ли это накладные расходы по сравнению с традиционной виртуальной сетевой (к примеру vmxnet3). И с большой вероятность, после включение SR-IOV потеряется возможность сделать кластер с High Available, что теряет смысл в виртуализации, в принципе. Получится виртуализация ради виртуализации, а хотелось бы автоматическую миграцию в случае аварии на одном из кластеров.

Изменено 16 марта, 2021 пользователем morf

[NiTr0]

В 16.03.2021 в 12:25, morf сказал:

Не знаю, уменьшает ли это накладные расходы по сравнению с традиционной виртуальной сетевой (к примеру vmxnet3)

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

В 16.03.2021 в 12:25, morf сказал:

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

так миграция - она скорее для планового/аварийного обсуживания, вернее - минимизации простоя при нем; если хост умер вообще - мигрировать уже нечено и никак, просто стартует виртуалка на втором сервере кластера, с простоем в минуту пускай (пока забутается).

 

ну а еще виртуализация - это способ сократить кол-во железок.

[Saab95]

13 часов назад, NiTr0 сказал:

ну а еще виртуализация - это способ сократить кол-во железок.

Количество железок если это куча веб серверов или подобных задач.

 

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

[NiTr0]

2 часа назад, Saab95 сказал:

Роутинг, всякие там 1С базы и прочее, выгодно делать на отдельных серверах

если это роутинг пары сот мегабит (да и гигабита даже) - то нахрен для него не надо отдельная железяка. туда же и 1С, да - венда в proxmox/vmware это таки куда лучше, чем венда на отдельном сервере. как минимум - сервер апгрейдится тупо перетыкиванием дисков, а не переустановкой/многочасовыми плясками с бубном вокруг драйверов стореджа.

ну а кто не осилил под 1С выделить отдельный сторедж из пары дисков в рэйде - тот может и дальше рисовать отдельные сервера под ДНС...

[jffulcrum]

4 часа назад, Saab95 сказал:

Роутинг, всякие там 1С базы и прочее, выгодно делать на отдельных серверах

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

[morf]

20 часов назад, NiTr0 сказал:

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

 Я делал тесты с прокидыванием через pci passthrough. Лучше, чем виртуальная сетевая, но все ещё хуже, чем на реальном железе. Примерно в 2 раза. 

 

20 часов назад, NiTr0 сказал:

миграция - она скорее для планового/аварийного обсуживания, вернее - минимизации простоя при нем; если хост умер вообще - мигрировать уже нечено и никак, просто стартует виртуалка на втором сервере кластера, с простоем в минуту пускай (пока забутается).

Я имел ввиду непрерывную миграцию. Если основной хост падает, то тут же стартует копия этой виртуальной машины на другом сервере. Никакие костыли типа VRRP с этим не сравнятся, практически горячий резерв. Если бы схема взлетела и не было так много накладных расходов, то делать bras'ы из программных маршрутизаторов (RouterOS, VyOS, Pfsense, Linux/BSD, ...) было бы одно удовольствие.

Изменено 20 марта, 2021 пользователем morf

[NiTr0]

В 20.03.2021 в 15:05, morf сказал:

Я делал тесты с прокидыванием через pci passthrough. Лучше, чем виртуальная сетевая, но все ещё хуже, чем на реальном железе. Примерно в 2 раза.

что к слову довольно странно, не должна виртуализация так производительность садить.

 

В 20.03.2021 в 15:05, morf сказал:

Я имел ввиду непрерывную миграцию

а какие накладные расходы на нее будут?... постояная синхронизация содержимого RAM - довольно накладная по производительности штука как по мне.

и уж тем более для брасов такое не надо - там классического VRRP + синхронизации коннтрака с головой.

[morf]

23 часа назад, NiTr0 сказал:

а какие накладные расходы на нее будут?... постояная синхронизация содержимого RAM - довольно накладная по производительности штука как по мне.

и уж тем более для брасов такое не надо - там классического VRRP + синхронизации коннтрака с головой.

Хорошо, даже если не постоянная, хотя бы порционная с последними изменениями в состоянии виртуального жесткого диска. Не знаю, как Вам, но мне VRRP не показался удобным. 

[7sergeynazarov7]

 Добрый день имеется сервер Hpgen8 e2697 и intel x520 da имеется на изернет интерфейсах потери rx drops кто как решал ? Спасибо. работает все qinq

Изменено 23 марта, 2021 пользователем 7sergeynazarov7

[jffulcrum]

Для начала просто игнорировать, если нет реальных проблем - не рвутся сессии, не выпадают пинги и т.п. Если уж очень интересно, то перекрыть внешний трафик и смотреть, растут ли дальше. Если да - Torch смотреть, что именно прилетает на порт, скорее всего какой-то хлам от флудящего соседа. 

[morf]

1 час назад, 7sergeynazarov7 сказал:

 Добрый день имеется сервер Hpgen8 e2697 и intel x520 da имеется на изернет интерфейсах потери rx drops кто как решал ? Спасибо. работает все qinq

 

Я это уже проходил. Лекарство на скрине. Только не спрашивает, а что, да почему. Просто сделайте и все :) 
 

Изменено 23 марта, 2021 пользователем morf

[7sergeynazarov7]

12 hours ago, morf said:

Я это уже проходил. Лекарство на скрине. Только не спрашивает, а что, да почему. Просто сделайте и все :) 
 

 

Cпасибо за помощь, но скрин решил не открыться )))

 

12 hours ago, jffulcrum said:

Для начала просто игнорировать, если нет реальных проблем - не рвутся сессии, не выпадают пинги и т.п. Если уж очень интересно, то перекрыть внешний трафик и смотреть, растут ли дальше. Если да - Torch смотреть, что именно прилетает на порт, скорее всего какой-то хлам от флудящего соседа. 

Фишка такая если ставить на ethernet очередь ethernet-default то более менее малая потеря, если что-то другое растет как на дрожах. Вроде реальных проблем не замеченно, но все таки вдруг есть лекарство )

[morf]

7 минут назад, 7sergeynazarov7 сказал:

Cпасибо за помощь, но скрин решил не открыться )))

/system hardware set multi-cpu=no

/queue type set multi-queue-ethernet-default kind=mq-pfifo mq-pfifo-limit=500

/queue interface set ether1 queue=multi-queue-ethernet-default

 

Последней строкой каждому физическому интерфейсу присваиваете тип очереди multi-queue-ethernet-default.

Опережая вопрос "А зачем выключить multi-cpu, ведь это многоядерность", скажу сразу, что это не многоядерность нифига, а старое никому не нужное говнище и к многоядерности имеет посредственное отношение.

Изменено 24 марта, 2021 пользователем morf

[7sergeynazarov7]

2 minutes ago, morf said:

/system hardware set multi-cpu=no

/queue type set multi-queue-ethernet-default kind=mq-pfifo mq-pfifo-limit=500

/queue interface set ether1 queue=multi-queue-ethernet-default

 

последней строкой каждому физическому интерфейсу присваиваете тип очереди multi-queue-ethernet-default

 

/queue type set multi-queue-ethernet-default kind=mq-pfifo mq-pfifo-limit=500

Это как понял для абонентов ?

 

/system hardware set multi-cpu=no -->  сделано.

/queue interface set ether1 queue=multi-queue-ethernet-default  делал потери были, на на абонента стояли очередь PCQ может быть из-за этого ?

[morf]

1 минуту назад, 7sergeynazarov7 сказал:

Это как понял для абонентов ?

Нет, это для физических интерфейсов. Клиентам можешь ставить, либо pfifo, либо pcq.

 

1 минуту назад, 7sergeynazarov7 сказал:

queue interface set ether1 queue=multi-queue-ethernet-default 

X520 многопоточная сетевуха и ей полюбому нужно указывать multi-queue-ethernet-default.

Изменено 24 марта, 2021 пользователем morf

[7sergeynazarov7]

2 minutes ago, morf said:

Нет, это для физических интерфейсов. Клиентам можешь ставить, либо pfifo, либо pcq.

 

X520 многопоточная сетевуха и ей полюбому нужно указывать multi-queue-ethernet-default.

 

Спасибо большое. Очень помогли, по результату отпишусь )

[7sergeynazarov7]

Вопрос как все таки лучше с hyper-threading или без не тестировали уважаемый morf ? Что так сказать более больше пропустит пакетов.

Изменено 24 марта, 2021 пользователем 7sergeynazarov7

[morf]

53 минуты назад, 7sergeynazarov7 сказал:

Вопрос как все таки лучше с hyper-threading или без не тестировали уважаемый morf ? Что так сказать более больше пропустит пакетов.

 

У меня стоит с HT, меня устраивает.