morf Опубликовано 15 марта, 2021 (изменено) · Жалоба 34 минуты назад, maa1 сказал: morf Выводы по виртуальным средам, номер раз: - худшие результаты были на гипервизорах с использованием паравиртуальных сетевых драйверов (Vmxnet3). В ~4-6 раз хуже самых лучших результатов + куча дропов. Ваше мнение - это проблема ROS или проблема ESXi? вы писали в поддержку микротика с этой проблемой? вы пробовали последнюю версию ESXi 7 U2? 1. Это не проблема ROS, это скорее проблема слишком больших накладных расходах: виртуальный сетевая, виртуальный свитч, сетевая подсистема самой хостовой машины. Тем более аналогичная проблема воспроизводилась на разных гиппервизорах: esxi, xen, proxmox. 2. Не думаю, что это их проблема. Я пробовал использовать VyOS и получил +- похожие результаты. 3. Тогда почему на других гипервизорах ситуация воспроизводится ? Я не думаю, что это проблема, мне кажется - это просто особенность использования виртуальных подсистем. Это нужно просто принять и смирится с тем, что виртуальный маршрутизатор всегда будет хуже хардварного. Изменено 15 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maa1 Опубликовано 15 марта, 2021 · Жалоба morf это скорее проблема слишком больших накладных расходах: виртуальный сетевая, виртуальный свитч мне кажется - это просто особенность использования виртуальных подсистем Но на виртуализации гоняют не только маршрутизаторы, но и гораздо более серьёзные вещи. И если бы и там наблюдались описанные вами проблемы ( В ~4-6 раз хуже самых лучших результатов + куча дропов ), то VMware давно бы поставили раком. Так что более вероятна проблема во взаимодействии ROS и виртуализации. Не думаю, что это их проблема. Я пробовал использовать VyOS и получил +- похожие результаты Они обе на базе Linux. Ради интереса - наблюдаются ли проблемы с pfSense/OPNsense (которые на FreeBSD)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 15 марта, 2021 · Жалоба 2 часа назад, maa1 сказал: Но на виртуализации гоняют не только маршрутизаторы, но и гораздо более серьёзные вещи. А что может быть серьезнее маршрутизатора? Он принял пакет, быстро обработал и отправил. Почти все операции это ввод - вывод через сетевой интерфейс. Если сравнить с неким нагруженным WEB сервером, или базой данных, то там операции уже уходят в другие подсистемы сервера, и виртуалка не нагружается до упора по одному направлению действия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 15 марта, 2021 (изменено) · Жалоба 8 часов назад, maa1 сказал: ади интереса - наблюдаются ли проблемы с pfSense/OPNsense (которые на FreeBSD)? Кстати, да. Забыл упомянуть про pfsense. Я о нем писал в самом начале темы. Те же грабли только сбоку. При одинаковом трафике, но разных гиппервизорах и разных программных маршрутизатора огромная разница по использованию CPU сервера. Я на такое не согласен. Изменено 15 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 марта, 2021 · Жалоба 6 часов назад, maa1 сказал: Так что более вероятна проблема во взаимодействии ROS и виртуализации. Что на Hyper-V, что на Vmware объективно есть проблемы с утилизацией сетевого интерфейса более чем на 70% - обычно это не удается. Сделать можно немногое: уходить на большую канальную скорость в принципе, привязываться к LACP тиме (если трафик многие к одному), SR-IOV (но тут уже прощай миграция и т.п.). Что кассется хреновых результатов топикстартера именно на VmWare, то сдается мне, не были соответствующим образом увеличены ring buffers. Статейка старая, но из разряда "о вечном". Плохая новость, что я сам сталкивался с игнорированием любых выставляемых значений в гостевой машине с Linux - видимо, зависит от конкретной версии драйвера виртуальной сети в поставке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 15 марта, 2021 (изменено) · Жалоба 2 часа назад, jffulcrum сказал: Что кассется хреновых результатов топикстартера именно на VmWare, то сдается мне, не были соответствующим образом увеличены ring buffers. Напоминает танцы с бубном, но справедливости ради, хочу напомнить, что ROS я так же поднимал на XenServer и Proxmox. Ничего нового. Вообще вся эта свистопляска с виртуализацией была затеяна только ради High Available с автоматической миграцией и запуском на резервном серваке. Изменено 15 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maa1 Опубликовано 16 марта, 2021 · Жалоба morf - SR-IOV не поддерживается RouterOS от слова вообще. Начиная с 7.1beta3 поддерживается. Вы не тестировали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 16 марта, 2021 (изменено) · Жалоба 48 минут назад, maa1 сказал: morf - SR-IOV не поддерживается RouterOS от слова вообще. Начиная с 7.1beta3 поддерживается. Вы не тестировали? Вы верно заметили, но на момент публикации темы SR-IOV еще не поддерживался. К сожалению, сейчас нет возможности поднять стенд. SR-IOV это, по-сути, виртуальные адаптеры сетевой карты, только прокинутые в виртуалку. Не знаю, уменьшает ли это накладные расходы по сравнению с традиционной виртуальной сетевой (к примеру vmxnet3). И с большой вероятность, после включение SR-IOV потеряется возможность сделать кластер с High Available, что теряет смысл в виртуализации, в принципе. Получится виртуализация ради виртуализации, а хотелось бы автоматическую миграцию в случае аварии на одном из кластеров. Изменено 16 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 марта, 2021 · Жалоба В 16.03.2021 в 12:25, morf сказал: Не знаю, уменьшает ли это накладные расходы по сравнению с традиционной виртуальной сетевой (к примеру vmxnet3) ессно уменьшает. не надо данные гонять через хост, нет лишних переключений контекста. по идее - по производительности эквивалентно пробросу реальной карты в гостя. В 16.03.2021 в 12:25, morf сказал: И с большой вероятность, после включение SR-IOV потеряется возможность сделать кластер с High Available, что теряет смысл в виртуализации, в принципе. Получится виртуализация ради виртуализации, а хотелось бы автоматическую миграцию в случае аварии на одном из кластеров. так миграция - она скорее для планового/аварийного обсуживания, вернее - минимизации простоя при нем; если хост умер вообще - мигрировать уже нечено и никак, просто стартует виртуалка на втором сервере кластера, с простоем в минуту пускай (пока забутается). ну а еще виртуализация - это способ сократить кол-во железок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 20 марта, 2021 · Жалоба 13 часов назад, NiTr0 сказал: ну а еще виртуализация - это способ сократить кол-во железок. Количество железок если это куча веб серверов или подобных задач. Роутинг, всякие там 1С базы и прочее, выгодно делать на отдельных серверах. Ну это не понятно для тех, кто не учился на технических специальностях, где с самого начала рисовали отдельный сервер даже для DNS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 марта, 2021 · Жалоба 2 часа назад, Saab95 сказал: Роутинг, всякие там 1С базы и прочее, выгодно делать на отдельных серверах если это роутинг пары сот мегабит (да и гигабита даже) - то нахрен для него не надо отдельная железяка. туда же и 1С, да - венда в proxmox/vmware это таки куда лучше, чем венда на отдельном сервере. как минимум - сервер апгрейдится тупо перетыкиванием дисков, а не переустановкой/многочасовыми плясками с бубном вокруг драйверов стореджа. ну а кто не осилил под 1С выделить отдельный сторедж из пары дисков в рэйде - тот может и дальше рисовать отдельные сервера под ДНС... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 20 марта, 2021 · Жалоба 4 часа назад, Saab95 сказал: Роутинг, всякие там 1С базы и прочее, выгодно делать на отдельных серверах Это если у тебя реальный highload, когда нагрузку не поделить и надо выжимать всё из железяки. Бывает, но не часто. Ну или если на нормальное железо денех нет - все еще встречаю в дикой природе серверные, набитые лютым самосбором. Каждый раз внушает леденящий душу восторг... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 20 марта, 2021 (изменено) · Жалоба 20 часов назад, NiTr0 сказал: ессно уменьшает. не надо данные гонять через хост, нет лишних переключений контекста. по идее - по производительности эквивалентно пробросу реальной карты в гостя. Я делал тесты с прокидыванием через pci passthrough. Лучше, чем виртуальная сетевая, но все ещё хуже, чем на реальном железе. Примерно в 2 раза. 20 часов назад, NiTr0 сказал: миграция - она скорее для планового/аварийного обсуживания, вернее - минимизации простоя при нем; если хост умер вообще - мигрировать уже нечено и никак, просто стартует виртуалка на втором сервере кластера, с простоем в минуту пускай (пока забутается). Я имел ввиду непрерывную миграцию. Если основной хост падает, то тут же стартует копия этой виртуальной машины на другом сервере. Никакие костыли типа VRRP с этим не сравнятся, практически горячий резерв. Если бы схема взлетела и не было так много накладных расходов, то делать bras'ы из программных маршрутизаторов (RouterOS, VyOS, Pfsense, Linux/BSD, ...) было бы одно удовольствие. Изменено 20 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 марта, 2021 · Жалоба В 20.03.2021 в 15:05, morf сказал: Я делал тесты с прокидыванием через pci passthrough. Лучше, чем виртуальная сетевая, но все ещё хуже, чем на реальном железе. Примерно в 2 раза. что к слову довольно странно, не должна виртуализация так производительность садить. В 20.03.2021 в 15:05, morf сказал: Я имел ввиду непрерывную миграцию а какие накладные расходы на нее будут?... постояная синхронизация содержимого RAM - довольно накладная по производительности штука как по мне. и уж тем более для брасов такое не надо - там классического VRRP + синхронизации коннтрака с головой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 23 марта, 2021 · Жалоба 23 часа назад, NiTr0 сказал: а какие накладные расходы на нее будут?... постояная синхронизация содержимого RAM - довольно накладная по производительности штука как по мне. и уж тем более для брасов такое не надо - там классического VRRP + синхронизации коннтрака с головой. Хорошо, даже если не постоянная, хотя бы порционная с последними изменениями в состоянии виртуального жесткого диска. Не знаю, как Вам, но мне VRRP не показался удобным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
7sergeynazarov7 Опубликовано 23 марта, 2021 (изменено) · Жалоба Добрый день имеется сервер Hpgen8 e2697 и intel x520 da имеется на изернет интерфейсах потери rx drops кто как решал ? Спасибо. работает все qinq Изменено 23 марта, 2021 пользователем 7sergeynazarov7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 23 марта, 2021 · Жалоба Для начала просто игнорировать, если нет реальных проблем - не рвутся сессии, не выпадают пинги и т.п. Если уж очень интересно, то перекрыть внешний трафик и смотреть, растут ли дальше. Если да - Torch смотреть, что именно прилетает на порт, скорее всего какой-то хлам от флудящего соседа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 23 марта, 2021 (изменено) · Жалоба 1 час назад, 7sergeynazarov7 сказал: Добрый день имеется сервер Hpgen8 e2697 и intel x520 da имеется на изернет интерфейсах потери rx drops кто как решал ? Спасибо. работает все qinq Я это уже проходил. Лекарство на скрине. Только не спрашивает, а что, да почему. Просто сделайте и все :) Изменено 23 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
7sergeynazarov7 Опубликовано 24 марта, 2021 · Жалоба 12 hours ago, morf said: Я это уже проходил. Лекарство на скрине. Только не спрашивает, а что, да почему. Просто сделайте и все :) Cпасибо за помощь, но скрин решил не открыться ))) 12 hours ago, jffulcrum said: Для начала просто игнорировать, если нет реальных проблем - не рвутся сессии, не выпадают пинги и т.п. Если уж очень интересно, то перекрыть внешний трафик и смотреть, растут ли дальше. Если да - Torch смотреть, что именно прилетает на порт, скорее всего какой-то хлам от флудящего соседа. Фишка такая если ставить на ethernet очередь ethernet-default то более менее малая потеря, если что-то другое растет как на дрожах. Вроде реальных проблем не замеченно, но все таки вдруг есть лекарство ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 24 марта, 2021 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
7sergeynazarov7 Опубликовано 24 марта, 2021 · Жалоба 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 может быть из-за этого ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 24 марта, 2021 (изменено) · Жалоба 1 минуту назад, 7sergeynazarov7 сказал: Это как понял для абонентов ? Нет, это для физических интерфейсов. Клиентам можешь ставить, либо pfifo, либо pcq. 1 минуту назад, 7sergeynazarov7 сказал: queue interface set ether1 queue=multi-queue-ethernet-default X520 многопоточная сетевуха и ей полюбому нужно указывать multi-queue-ethernet-default. Изменено 24 марта, 2021 пользователем morf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
7sergeynazarov7 Опубликовано 24 марта, 2021 · Жалоба 2 minutes ago, morf said: Нет, это для физических интерфейсов. Клиентам можешь ставить, либо pfifo, либо pcq. X520 многопоточная сетевуха и ей полюбому нужно указывать multi-queue-ethernet-default. Спасибо большое. Очень помогли, по результату отпишусь ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
7sergeynazarov7 Опубликовано 24 марта, 2021 (изменено) · Жалоба Вопрос как все таки лучше с hyper-threading или без не тестировали уважаемый morf ? Что так сказать более больше пропустит пакетов. Изменено 24 марта, 2021 пользователем 7sergeynazarov7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morf Опубликовано 24 марта, 2021 · Жалоба 53 минуты назад, 7sergeynazarov7 сказал: Вопрос как все таки лучше с hyper-threading или без не тестировали уважаемый morf ? Что так сказать более больше пропустит пакетов. У меня стоит с HT, меня устраивает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...