Комментарии 15
Совершенно не понятно, из чего сделан вывод «производительность veth ниже». venet — это L3 устройство, с трекингом соединений, роутингом и еще кучей фарша, которое делает ядро. А veth тупо Ethernet устройство, которое почти в чистом виде выбрасывается во внешнюю сеть.
Вместо кривых линуксовых бриджей, которые ведут себя хрен-отладишь, рекомендую попробовать OpenVSwitch, а также могу подкинуть скрипт, чтобы OpenVZ сам добавлял устройства в требуемый виртульный свич.
Вместо кривых линуксовых бриджей, которые ведут себя хрен-отладишь, рекомендую попробовать OpenVSwitch, а также могу подкинуть скрипт, чтобы OpenVZ сам добавлял устройства в требуемый виртульный свич.
Совершенно не понятно, из чего сделан вывод «производительность veth ниже»
openvz.org/Differences_between_venet_and_veth
с трекингом соединений
git.openvz.org/?p=vzctl;a=commitdiff;h=a191a462579ee54b6adec9f32f44a3982379e78a
А veth тупо Ethernet устройство, которое почти в чистом виде выбрасывается во внешнюю сеть.
А это уже Ваша фантазия. Я могу Вам сказать, что вместо эмуляции L2 устройств, venet просто решает сетевой вопрос на уровне фильтров адресов и роутов.
Вместо кривых линуксовых бриджей, которые ведут себя хрен-отладишь, рекомендую попробовать OpenVSwitch, а также могу подкинуть скрипт, чтобы OpenVZ сам добавлял устройства в требуемый виртульный свич.
Оно всё равно неэквивалентно в плане безопасности и производительности venet. Спасибо, не нужно.
По поводу openvz.org/Differences_between_venet_and_veth я не уверен, что указанные там fast и fastest имеют отношение к реальному положению вещей.
По поводу этого git.openvz.org/?p=vzctl;a=commitdiff;h=a191a462579ee54b6adec9f32f44a3982379e78a — это было выкачено так недавно и во многом благодаря нашему вою не тему ужасающей деградации производительности на всей машине из-за трекинга.
Отключение трекинга — решение очень спорное. Оно растет из крайне высокой сложности «честной» изоляции коннтрекинга.
Мало того, трекинг соединений нужен довольно приличному количеству людей и нередко народ откатывают эту конфигурацию и возвращает трекинг со всеми его деградациями.
Кроме conntrack есть еще полностью не изолированные syn стадии установления соединения, которые, уверен, в venet почти всегда приводят к смерти машины от syn флуда, а вот в случае veth к подобному привести не должны.
По поводу этого git.openvz.org/?p=vzctl;a=commitdiff;h=a191a462579ee54b6adec9f32f44a3982379e78a — это было выкачено так недавно и во многом благодаря нашему вою не тему ужасающей деградации производительности на всей машине из-за трекинга.
Отключение трекинга — решение очень спорное. Оно растет из крайне высокой сложности «честной» изоляции коннтрекинга.
Мало того, трекинг соединений нужен довольно приличному количеству людей и нередко народ откатывают эту конфигурацию и возвращает трекинг со всеми его деградациями.
Кроме conntrack есть еще полностью не изолированные syn стадии установления соединения, которые, уверен, в venet почти всегда приводят к смерти машины от syn флуда, а вот в случае veth к подобному привести не должны.
OpenVSwitch десятком легких движений (с привлечением open flow) обеспечивает безопасность на уровне venet без всех его чудесных фич. Разве что он не особенно удобен в конфигурации.
Вот будь для veth удобная автогенерация настроек сетевых интерфейсов для ОС внутри контейнера по аналогии с venet (делается довольно банально), а также создание OVS свичей вместе с навешиванием IP/MAC/ARP фильтров — я бы всегда использовал veth. Или даже что-то класса vhost из KVM :)
Гибкость veth на порядки выше, venet — скомммутировать в пределах нескольких ДЦ — задача почти нереализуемая.
Вот будь для veth удобная автогенерация настроек сетевых интерфейсов для ОС внутри контейнера по аналогии с venet (делается довольно банально), а также создание OVS свичей вместе с навешиванием IP/MAC/ARP фильтров — я бы всегда использовал veth. Или даже что-то класса vhost из KVM :)
Гибкость veth на порядки выше, venet — скомммутировать в пределах нескольких ДЦ — задача почти нереализуемая.
Гибкость veth на порядки выше, venet — скомммутировать в пределах нескольких ДЦ — задача почти нереализуемая.
Неудачная попытка апеллировать к отказоустойчивости на уровне ДЦ, вылившаяся полным бредом. С коммутацией venet в разных ДЦ нет никаких проблем, уважаемый.
При чем тут отказоустойчивость? Пробросьте 100 приватных сетей между дата центрами без привлечения vxvlan или QnQ туннелей силами только venet. В путь!
Каким образом приватные сети будут доставлены до HN не имеет никакого значения, если адрес можно поднять на HN, то его можно и назначить контейнеру.
При чем тут HWN? Я четко уточнил — приватных сетей между контейнерами. Это не какая-то экзотическая конфигурация, а вполне постоянная потребность — оное есть у Amazon/Google/Heroku и прочих.
Что если Вам нужно несколько _приватных_ интерфейсов между десятком контейнеров даже в пределах одного ДЦ?
Как Вы обеспечите транзит пусть даже l3 трафика между машинами, если между аппаратными нодам стоит пара роутеров и свич? Поднимать OSPF и постоянно корректировать правила роутинга, если внутри контейнера вводится дополнительный интерфейс или меняется IP?
Что если Вам нужно несколько _приватных_ интерфейсов между десятком контейнеров даже в пределах одного ДЦ?
Как Вы обеспечите транзит пусть даже l3 трафика между машинами, если между аппаратными нодам стоит пара роутеров и свич? Поднимать OSPF и постоянно корректировать правила роутинга, если внутри контейнера вводится дополнительный интерфейс или меняется IP?
О, я могу продолжить! Например о тотально кривой работе IPv6 при использовании venet. NDP? Router solicitation? Нет уж! Ничего этого ждать не стоит :)
HN — хостнода
Что если Вам нужно несколько _приватных_ интерфейсов между десятком контейнеров даже в пределах одного ДЦ?Если контейнер L2, то деинкапсулировать на хостноде, в чём проблема
По поводу openvz.org/Differences_between_venet_and_veth я не уверен, что указанные там fast и fastest имеют отношение к реальному положению вещей.
То есть документации верить не стоит, а вот Вашему авторитетному мнению поверить стоит.
Отключение трекинга — решение очень спорное. Оно растет из крайне высокой сложности «честной» изоляции коннтрекинга.
Это не отключает conntrack в самих контейнерах.
Мало того, трекинг соединений нужен довольно приличному количеству людей и нередко народ откатывают эту конфигурацию и возвращает трекинг со всеми его деградациями.
В свете вышесказанного видно, что вы сочиняете на ходу.
Уважаемый, я отлично знаю, где эта опция отключает коннтреки, потому что сам внедрял ее ДО релиза как стандартной конфигурации в OpenVZ.
А вот в документации, боюсь, закрылась ошибка и ребята из OpenVZ обещают уточнить и разобраться — почему одно fast, а другое fastest.
А Вы показали себя изрядным хамом и проявили свою не особо высокую компетенцию во всей красе, удачи.
А вот в документации, боюсь, закрылась ошибка и ребята из OpenVZ обещают уточнить и разобраться — почему одно fast, а другое fastest.
А Вы показали себя изрядным хамом и проявили свою не особо высокую компетенцию во всей красе, удачи.
Кто вам обещал разобраться? Воображаемые друзья из воображаемого OpenVZ inc.? Его parallels разрабатывает. Сами они и упоминают вот что:
Источник
The veth mode has poorer scalability than the venet0 mode. This is caused by the fact that any broadcast packet meant for any veth virtual network adapter is duplicated and transmitted to all available veth network adapters, which requires the CPU(s) on the Hardware Node to process all the resulting broadcast packets and may noticeably degrade the system performance. So, we highly recommend that you create no more than 100 veth network adapters for every CPU on the Node.
Источник
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenVZ + venet + vlan/адреса из разных сетей