> Мы наблюдали, как строили кластеры на старых карточках Инфинибэнд и прочих нетрадиционных решениях. По результатам наблюдений мы отказались от этих вариантов и не рекомендуем их использовать нашим клиентам.
А можете рассказать, почему вам не нравятся решения на Инфинибэнд? Спасибо
По теме сетей? Тут очень обширно. Когда то (в 2000 году кажется) мне очень понравились Олиферы. Но вряд ли там будет объяснено про параллельные пути.
Давайте я коротко вам тут попытаюсь объяснить.
1. Как работает роутинг в Интернет: много много сетевых устройств соединены друг с другом. Объединение этих устройств образует граф. Чтобы дойти из одной точки графа в другую точку графа надо пройти какой-то путь в этом графе. Чаще всего таких путей может быть несколько. Но не все пути будут одинаковыми, один путь будет короче, другой длинее (как физически, так и по задержкам). Понятно, что чем короче путь — тем быстрее пакет дойдет до адресата. И было бы выгодно использовать этот маршрут. Но когда стали использовать этот принцип, быстро выяснилось, что некоторые дуги в этом графе (физические линки, оптика) не загружены трафиком, а некоторые перегружены трафиком. Поэтому с помощью некоторых технолочиских ухищрений трафик в этом графе научились отправлять по паралельным линкам. И иногда так получалось, что один пакет из tcp сессии шел через одного провайдера, а второй пакет через другого (обычно пытаются сделать так, чтобы одна tcp сессия шла всегда одинакова, но я видел огромное количество противоположенных примеров). Понятно, что сети у разных провайдеров разные, и часто так получалось, что у одного провайдера пакет подзадерживался то тут, то там (особенно если сеть у провайдера перегружена), а у другого провайдера пакет пролетал со свистом через всю сеть. И получалось, что пакеты приходили в разное время, хотя, казалось бы начинали они идти по сети почти одновренно.
2. Что касается QoS — Quality of Service то тут все просто. QoS обычно настраивают для того, чтобы обеспечить заданное качество обслуживание на сети. Одна из политик QoS — буферизация трафика. Как оно работает — когда видим, что линк у нас на 100Mb/s, а в него пытается проползти 1Gb/s, мы засовываем в линк столько, сколько влезет, а остальное складываем в буфер с мыслью: «а вдруг этот 1Gb/s станет жалким 1Mb/s, а мы потом успеем все в линк покидать». Буферизация приводит к тому, что один пакет задержался в буфере, а второй под шумок пролез параллельным путем.
Или был такой механизм как WFQ — когда маленькие пакеты получали приоритет перед большими при отправке через низкоскоростные интерфейсы. На более высокоскоростных интерфейсах это стало неважно.
Все что я попытался объяснить тут справедливо для Интернета и мало справедливо для обычной локальной сети (хотя для локальной сети большого предприятия это тоже может быть справедливо).
P.S.: Кстати еще по сетям очень рекомендую цикл статей на хабре — Сети для самых маленьких. Начало я не читал, честно говоря, но вот часть про MPLS написана просто очень отлично habrahabr.ru/post/246425
Если перемешивание сообщений было в udp то это нормально. Связано чаще всего с одной вещью — параллельные пути внутри сети. Часто бывает так, что пакет, который отправили позднее — пришел раньше.
Или же QoS (что редко встречается в современных сетях) — один пакет по какой-либо причине попридержали в буфере перед отправкой.
Насколько я помню (проверить сейчас не на чем), в стандартном клиенте telnet от Windows можно было через опции включить echo на экран.
Что-то типа set echo
Этот libcontainer? github.com/docker/libcontainer
Как то он про lxc, и ничего там по ключевому слову kvm не находится.
В proxmox есть API?
А openstack стабильнее libvirt-а?
А мне понравилось, как Вы сделали! Спасибо, прочитал с большим удовольствием! Вам удивительно хорошо получилось передать в такой короткой статье передать так много информации. Что еще сильно понравилось, статья не похожа на многочисленние введения в MPLS которые я видел. Потому как после обычных «введений» большей частью непонятно как MPLS работает внутри. А у вас все прозрачно описано! Спасибо!
Стоили DLU, фактом, меньше. В общем случае Cisco телефония сейчас стала и дороже более неудобная по лицензиям (во всяком случае для меня).
Нормальное взрослое решение, говорите? Как я понимаю вы cucm продаете?
Я cucm эксплуатирую с версии 3.x. И, честно говоря, не считаю что поддержка его обошлась бы дешевле чем астериска.
В крайнем случае в астериске всегда можно дописать что-то, чего в cucm сделать по факту нельзя.
Поговорите с людьми, которые использовали эту технолию на сетях, где таких стеков 1000+. Они вам расскажут удивительнейшие вещи.
Короче хочу make
В openvswitch-е и в linux kernel поддержка появилась.
Где еще нужно? Windows и ESXi?
А можете рассказать, почему вам не нравятся решения на Инфинибэнд? Спасибо
Давайте я коротко вам тут попытаюсь объяснить.
1. Как работает роутинг в Интернет: много много сетевых устройств соединены друг с другом. Объединение этих устройств образует граф. Чтобы дойти из одной точки графа в другую точку графа надо пройти какой-то путь в этом графе. Чаще всего таких путей может быть несколько. Но не все пути будут одинаковыми, один путь будет короче, другой длинее (как физически, так и по задержкам). Понятно, что чем короче путь — тем быстрее пакет дойдет до адресата. И было бы выгодно использовать этот маршрут. Но когда стали использовать этот принцип, быстро выяснилось, что некоторые дуги в этом графе (физические линки, оптика) не загружены трафиком, а некоторые перегружены трафиком. Поэтому с помощью некоторых технолочиских ухищрений трафик в этом графе научились отправлять по паралельным линкам. И иногда так получалось, что один пакет из tcp сессии шел через одного провайдера, а второй пакет через другого (обычно пытаются сделать так, чтобы одна tcp сессия шла всегда одинакова, но я видел огромное количество противоположенных примеров). Понятно, что сети у разных провайдеров разные, и часто так получалось, что у одного провайдера пакет подзадерживался то тут, то там (особенно если сеть у провайдера перегружена), а у другого провайдера пакет пролетал со свистом через всю сеть. И получалось, что пакеты приходили в разное время, хотя, казалось бы начинали они идти по сети почти одновренно.
2. Что касается QoS — Quality of Service то тут все просто. QoS обычно настраивают для того, чтобы обеспечить заданное качество обслуживание на сети. Одна из политик QoS — буферизация трафика. Как оно работает — когда видим, что линк у нас на 100Mb/s, а в него пытается проползти 1Gb/s, мы засовываем в линк столько, сколько влезет, а остальное складываем в буфер с мыслью: «а вдруг этот 1Gb/s станет жалким 1Mb/s, а мы потом успеем все в линк покидать». Буферизация приводит к тому, что один пакет задержался в буфере, а второй под шумок пролез параллельным путем.
Или был такой механизм как WFQ — когда маленькие пакеты получали приоритет перед большими при отправке через низкоскоростные интерфейсы. На более высокоскоростных интерфейсах это стало неважно.
Все что я попытался объяснить тут справедливо для Интернета и мало справедливо для обычной локальной сети (хотя для локальной сети большого предприятия это тоже может быть справедливо).
P.S.: Кстати еще по сетям очень рекомендую цикл статей на хабре — Сети для самых маленьких. Начало я не читал, честно говоря, но вот часть про MPLS написана просто очень отлично habrahabr.ru/post/246425
Или же QoS (что редко встречается в современных сетях) — один пакет по какой-либо причине попридержали в буфере перед отправкой.
В последнее время я больше слышу ansible. Как-то про chef и puppet забывать стали.
Что-то типа set echo
Как то он про lxc, и ничего там по ключевому слову kvm не находится.
В proxmox есть API?
А openstack стабильнее libvirt-а?
И вообще, чем libvirt плох?
Стоили DLU, фактом, меньше. В общем случае Cisco телефония сейчас стала и дороже более неудобная по лицензиям (во всяком случае для меня).
Нормальное взрослое решение, говорите? Как я понимаю вы cucm продаете?
Я cucm эксплуатирую с версии 3.x. И, честно говоря, не считаю что поддержка его обошлась бы дешевле чем астериска.
В крайнем случае в астериске всегда можно дописать что-то, чего в cucm сделать по факту нельзя.