Какие аналоги виртуальных коммутаторов для linux существуют?

виртуальных коммутаторов наподобие и помимо openvswitch и brctl
brctl

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

vde switch

//captcha:111

Причем тут гугл? В данном случае я задаю вопрос на ЛОРе, не заметно? -)

Никакие

Обоснование?

Есть тупой бридж, которому сто лет, есть более или менее новый и фичастый OVSwitch. Есть ещё VXLAN, но это не то чтобы свич, скорее туннель. Всё. Какое тебе ещё обоснование нужно?

Всё.

Но ведь... VDE switch тоже есть!

Оно вообще в юзерспейсе работает, судя по всему - на энтерпрайз не тянет. При таком раскладе можно и OpenVPN сюда записать :)

А что, если не в ядре - так сразу не ынтерпрайз?

Да ТС вроде не настаивает на ынтерпрайзности.

ынтерпрайз бывает очень разным, где то уже считают, что kvm/openvz/xen/vmware пережиток прошлого и надо юзать только докер.

сейчас вообще сложно говорит о том, что где и кому нужно.

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

Тут всё просто: не в ядре == много переключений и перегонка траффика между kernel/userspace == медленно.

Откуда капча у ★★★★★?

А при чем тут «быстрота» и «энтерпрайзность»? Это как бы не совсем неравнозначные понятия, и порой даже быстродействие не является основополагающей составляющей понятия «энтерпрайзности». И далеко не все «энтерпрайзное» располагается в ядре.

Под энтерпрайзностью обычно подразумевается высокая нагрузка и надёжность. Если есть решения, которые могут это обеспечить - будут использованы они. Всё что касается сетевого взаимодействия и используется под большой нагрузкой - в ядре. Это IPSEC, роутинг, бриджинг, openvswitch, даже обработку l2tp/ppp/PPTP и ту вынесли в ядро (см. accel-ppp) что позволило резко увеличить производительность. Не зря ведь люди столько сил прикладывают чтобы это сделать, правда? ;)

хотя другие конторы просто покупают cisco и ставят перед своими серверами и вообще не трогают сетевую составляющую ОС.

Для каких-то целей - да, но цыска это тоже во многих случаях не панаецея и глюков в их устройствах просто море, насмотрелся. Очень крупные компании стараются уйти от vendor lock-in и использовать открытые решения. Та же лицокнига разрабатывает как свои свичи, так и стоечное оборудование и такие компании как раз главные пользователи и контрибьюторы в линукс и подобные открытые проекты.

Да и всё что сложнее шифрования и свитчинга\роутинга достаточно сложно (читай - дорого или невозможно) реализовать в аппаратных ASICах, поэтому типичная задача L7-балансировки решается проще на стандартном оборудовании через тот же HAProxy.

Ну вот именно, что обычно(но далеко не всегда, надо заметить) понимается, в том числе нагрузка и надежность, но это вовсе не означает, что эти решения должны размещаться именно на уровень ядра, особенно когда вынос в ядро предполагает уже замедление работы самого ядра, в свою очередь, из-за его перегруженности кодом итд. Так что это в любом случае, «палка о двух концах».

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

но это вовсе не означает, что эти решения должны размещаться именно на уровень ядра

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

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

У вас плохое понимание функционирования ядра. «Перегруженность кодом» это административная и архитектурная проблема, а не проблема производительности. Код, который просто имеется в ядре но не выполняется не замедляет его работы.

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

Ещё раз повторяю - это всё хорошо до тех пор, пока нужные алгоритмы можно реализовать в железе ASICов. Даже простой ASIC разработать - это *очень* дорогая забава. А если ты захочешь, к примеру, реализовать nginx в железе - то тут ждёт большой облом. Если бы такие девайсы были, то бохатые конторы вроде гугля и яндекса пользовались бы такими балансировщиками. Но их нет.

Поэтому у каждого продукта своя ниша - простые задачи (роутинг, свитчинг, может L4) решают ASICи, всё что сложнее и выше - уже обычный софт и процессоры.

///Поэтому у каждого продукта своя ниша - простые задачи (роутинг, свитчинг, может L4) решают ASICи, всё что сложнее и выше - уже обычный софт и процессоры.///

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

///Если работа конкретной подсистемы подразумевает передачу большого количества данных между ядром (драйвер сети) и юзерспейсом (виртуальный коммутатор в виде процесса) - то означает. Процесс переключения между ядром и юзерспейсом и передача между ними данных - процесс очень ресурсоёмкий.///

Но опять таки, возникает проблема перегруженности кодом и струкрутрами ядра.

///У вас плохое понимание функционирования ядра. «Перегруженность кодом» это административная и архитектурная проблема, а не проблема производительности. Код, который просто имеется в ядре но не выполняется не замедляет его работы.///

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

Но опять таки, возникает проблема перегруженности кодом и струкрутрами ядра.

Перегруженность чего? И как оно влияет на его скорость? Это какие-то выдуманные метрики. От количества модулей в ядре его общая «скорость» не зависит напрямую никак.

а ядро-таки программа

Быть не может!

Это именно проблема производительности

Расскажите мне, пожалуйста, как независимый модуль в ядре (корректно написаный, конечно), влияет на производительность всего ядра?

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

Имею некоторое представление т.к. писал как обычные многопоточные программы на Си, так и модули ядра.

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

Не бухаете хотя бы месяц перед тем как использовать.

Для вас, erzent'ов, придумали обёртки над iptables, которые генерируют правила сами. Но всё же рекомендую прочитать iptables howto - перевод на русский есть уже лет 10 точно, если не 15.

Кроме того, нелишним будет разбираться в предметной области, поэтому нужны знания модели OSI

я https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=iptables&category=8 и http://www.cyberciti.biz/tips/linux-iptables-examples.html .

В итоге, чтобы сделать потерю пакетов, ограничение скорости, создать нат, закрыть десяток портов и открыть нужные. у меня ушло почти 2 часа.... в то время как в том же pfsense, кроме потери пакетов можно это было сделать за 12 минут. Если же говорить на счёт обёрток, то тот же ipfire глючное говно. а system-config-firewall-tui на centos minimal не работает, и нужные зависимости за собой не тянет.

Дарагой, я тебе один умный вещь скажу, только ты не обижайся: «ограничение скорости» это не про iptables

iptables —append FORWARD -p icmp -m limit —limit —jump ACCEPT

, считать конечно долго, но работает

Это не ограничение скорости, точнее можно считать ограничением но с очень большой погрешностью.

а мне и надо было, чтобы оно колебалось в районе 10-30 кбит/c.

В итоге, чтобы сделать

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

да, только в теме ни одного комммента по теме не было, а вся проблема оказалась в настройке интерфейса.

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

который таки находится в памяти во время работы системы

Ну и что, пусть себе находится. Пока его не исполняют - он ни на что не влияет. Вообще.

а также качество написания этого кода, в частно структур кода ядра и их расположени

Причём тут качество? Мы говорим о целесообразности переноса чего-либо в ядро, а не о том как это сделано и как вообще написано ядро.

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

Опять кто в лес кто по дрова. Конечно взаимодействие влияет, но не всякий модуль с чем-то там особенно взаимодействует, а если и взаимодействует, то через заранее определённые эффективные API.

Ладно, базар окончен я думаю.

В итоге, чтобы сделать потерю пакетов, ограничение скорости, создать нат, закрыть десяток портов и открыть нужные. у меня ушло почти 2 часа.... в то время как в том же pfsense, кроме потери пакетов можно это было сделать за 12 минут.

«В итоге, чтобы забить пару гвоздей и шурупов, а также посмотреть несколько образцов микроскопом А, у меня ушло 2 часа. При этом микроскопом Б я бы сделал это за 12 минут - он намного ухватистее - разве что шуруп забить не получилось.»

Да, очевидно что документация к микроскопу паршиво освещает вопрос забивания гвоздей. Ничего, что шейпинг трафика - задача для tc, а не iptables?

а мне и надо было, чтобы оно колебалось в районе 10-30 кбит/c.

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

10001 утилита, tc тоже не самая приятная утилита по документации. по крайне мере русская статья по ней на opennet ощущение, что писалась таким же знатоком русского языка, как я. А у меня по нему было еле 3 из-за запятых. И хоть я и могу написать на любую тему хоть 100 страниц, читать это далеко не приятно.

///Ну и что, пусть себе находится. Пока его не исполняют - он ни на что не влияет. Вообще.///

Плохо вы понимаете предмет. Влияют, и еще как, и когда находятся в памяти, и когда исползяются, потому что от архитектуры зависит способы исполнения и многое другое, которое влияет на скорость напрямую и косвенно.

///Причём тут качество? Мы говорим о целесообразности переноса чего-либо в ядро, а не о том как это сделано и как вообще написано ядро.///

Потому как в том числе от качества кода(понятие широкое кстати) зависит скорость работы программ, в том числе и в области ядра. Если вы этого не понимаете-то мне трудно будет вам что-либо дальше объяснять.

///Опять кто в лес кто по дрова. Конечно взаимодействие влияет, но не всякий модуль с чем-то там особенно взаимодействует, а если и взаимодействует, то через заранее определённые эффективные API.///

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

Дрзузья, а вы топик случаем не перепутали?

system-config-firewall-tui на centos minimal не работает

Лол, у меня тоже не работал, но это чинится за минуту.

да я не стал читать, конфиг мой был верен, а вот с интерфейсом накосячил.