Комментарии 20
Сколько стоят такие крутые коробки? Предполагаю, что цена для обычного домашнего использования неподъемная, и еще и привязка к инфраструктуре производителя.
MKazakov_croc, эти устройства терминируют TCP у себя, или гоняют его в сеть в пакетном режиме? Мне кажется, терминирование TCP на устройстве выиграет в скорости и стабильности во всех случаях, т.к. нет зависимости от алгоритмов congestion control на клиентах, не нужно гонять ретрансмиссии от клиента в сеть, если пакеты теряются, можно быстро их переотправлять, точнее управлять TCP-окном и буферами.
Низкоуровневый алгоритм для TCP работает на MPTCP, для UDP — на собственной реализации поверх ARQ-протокола KCP
Я поискал-поискал с полгода, и понял, что для домашнего использования и использования в малом бизнесе никаких вменяемых предложений и нет. Все какое-то либо неудачное, либо крайне дорогое, либо с привязкой к собственным серверам. Решил делать своё, т.к. у меня есть и необходимые знания, и понимание, как это должно работать. Прежде всего меня интересует исходящий канал, поэтому упор делаю на вещиние видео с мероприятий через 3 и более LTE/3G-канала.
По цене получается около $600, вместе с 3 портативными LTE-модемами Cat 6 с батареей, способной работать около 12 часов. Кому-нибудь такое, кроме меня, интересно?
MKazakov_croc, эти устройства терминируют TCP у себя, или гоняют его в сеть в пакетном режиме? Мне кажется, терминирование TCP на устройстве выиграет в скорости и стабильности во всех случаях, т.к. нет зависимости от алгоритмов congestion control на клиентах, не нужно гонять ретрансмиссии от клиента в сеть, если пакеты теряются, можно быстро их переотправлять, точнее управлять TCP-окном и буферами.
Низкоуровневый алгоритм для TCP работает на MPTCP, для UDP — на собственной реализации поверх ARQ-протокола KCP
Я поискал-поискал с полгода, и понял, что для домашнего использования и использования в малом бизнесе никаких вменяемых предложений и нет. Все какое-то либо неудачное, либо крайне дорогое, либо с привязкой к собственным серверам. Решил делать своё, т.к. у меня есть и необходимые знания, и понимание, как это должно работать. Прежде всего меня интересует исходящий канал, поэтому упор делаю на вещиние видео с мероприятий через 3 и более LTE/3G-канала.
По цене получается около $600, вместе с 3 портативными LTE-модемами Cat 6 с батареей, способной работать около 12 часов. Кому-нибудь такое, кроме меня, интересно?
Было бы интересно open-source решение.
Чем Linux bonding инкапсулированный в кучку L2 vpn-каналов не решение?
Это будет ужасно работать. Bonding предназначен для объединения одинаковых линков, с одинаковой скоростью и одинаковой задержкой передачи. Если вы попытаетесь объединить, скажем, два LTE-канала, один со скоростью 10 мегабит и пингом 50 мс, а другой — 40 мегабит и 100 мс, то вы, в лучшем случае, получите небольшое увеличение скорости самого медленного канала, а обычно — характеристики самого медленного канала.
Если работать на уровне L2, то нужно учитывать алгоритмы управления TCP-окном и перегрузом. Они не любят, когда пакеты приходят вразнобой, а с каналами с разной задержкой это обязательно будет происходить. Поэтому, нужно либо буферизировать данные и выполнять перестановку пакетов в правильном порядке, либо придумывать другие костыли, либо переходить на уровень L3, с локальным терминированием TCP.
В общем, это далеко не такая простая задача, какой она кажется.
Если работать на уровне L2, то нужно учитывать алгоритмы управления TCP-окном и перегрузом. Они не любят, когда пакеты приходят вразнобой, а с каналами с разной задержкой это обязательно будет происходить. Поэтому, нужно либо буферизировать данные и выполнять перестановку пакетов в правильном порядке, либо придумывать другие костыли, либо переходить на уровень L3, с локальным терминированием TCP.
В общем, это далеко не такая простая задача, какой она кажется.
Для наколеночного решения есть вариант с L3 без необходимости как-то его особо терминировать. Когда-то его настраивал на базе Cisco, там это, если память не изменяет, называется NAT load balancing. Идея простая — часть соединений забрасывается в один канал, часть — в другой, деление возможно, например, по младшим битам src и/или dst адресов или просто в разнобой. При обрыве одного из каналов он выключается из этой схемы — разумеется, соединения приходится переустанавливать. Уверен, аналог можно накатать на iptables под линуксом. Конечно, это не то, про что статья, но имхо наиболее простой вариант для дома.
Bonding предназначен для объединения одинаковых линков, с одинаковой скоростью и одинаковой задержкой передачи
Новый Network Teaming поддерживает веса для каждого порта, их можно изменять в реальном времени, проверяя качество канала внешней утилитой.
Если работать на уровне L2, то нужно учитывать алгоритмы управления TCP-окном и перегрузом.
Согласен, но поверх этого можно развернуть какой-нибудь ip-туннель через tcp, он и будет гарантировать доставку каждого пакета.
По поводу буферизации — идея хорошая, но сходу у меня идей нет на этот счет, может знаете какое-нибудь простое unixway-решение?
Согласен, но поверх этого можно развернуть какой-нибудь ip-туннель через tcp, он и будет гарантировать доставку каждого пакета.У нас уже TCP, зачем нам пересылать TCP внутри TCP? Дело не в гарантии доставки, а в скорости работы. Существующие распространенные алгоритмы congestion control плохо работают и со скачущим пингом, и вообще с разными каналами. У вас TCP-окно будет подстраиваться под самый плохой канал (и в смысле скорости, и в смысле задержки), и быстрый канал будет утилизироваться на малый процент.
Хорошего unix-way-решения в принципе не может быть, оно будет всегда плохое. Корректных решений два:
1. MPTCP с локальным терминированием TCP.
2. Свой ARQ-протокол с инкапсуляцией в UDP и локальным терминированием TCP.
Дикий оверхед.
как раз вчера глядя на эту статью пошел гуглить, что есть в оперсорсе — нашел github.com/VrayoSystems/vtrunkd но еще не попробовал.
Сам городил на openvpn + бондинг + маршрутизация + баш-костылики — ужасно работало.
CC: ValdikSS
Сам городил на openvpn + бондинг + маршрутизация + баш-костылики — ужасно работало.
CC: ValdikSS
Я думаю интересно многим, как и SOHO, так и «для дома для семьи». Пост бы с примерами конфигурации. Если там ничего секретного нет.
Домашнее использование – это не про SD-WAN.
Наверное единственное, где он может быть применим дома – это дорогие фрилансеры, которые должны гарантированно что-то коммитить в основную инфраструктуру головного офиса, но и тут переткнуть руками LTE модем или проводной канал будет проще.
Малому же бизнесу SD-WAN предпочтительнее в виде покупки его у оператора в рамках канала.
В случае же покупки у того же cloud provider, что хранит основные ИТ-ресурсы компании, ценник будет выше чем 600$, но проценты, а не в разы.
Разворачивание решение SD-WAN целиком на своих ресурсов для малого бизнеса не очень интересно, поскольку это нивелирует его основное преимущество в возможности снизить требования к своим ИТ-специалистам и минимизацию выездов ИТшников на площадки.
Наверное единственное, где он может быть применим дома – это дорогие фрилансеры, которые должны гарантированно что-то коммитить в основную инфраструктуру головного офиса, но и тут переткнуть руками LTE модем или проводной канал будет проще.
Малому же бизнесу SD-WAN предпочтительнее в виде покупки его у оператора в рамках канала.
В случае же покупки у того же cloud provider, что хранит основные ИТ-ресурсы компании, ценник будет выше чем 600$, но проценты, а не в разы.
Разворачивание решение SD-WAN целиком на своих ресурсов для малого бизнеса не очень интересно, поскольку это нивелирует его основное преимущество в возможности снизить требования к своим ИТ-специалистам и минимизацию выездов ИТшников на площадки.
Это в РФ избалованны быстрым широкополосным доступом. В Европе это не так, зато почти везде можно поймать wifi от какого-нибудь ресторана или учреждения.
ценник будет выше чем 600$, но проценты, а не в разы.О, тогда ладно. Коробки для вещания видео стоят от $5000, поэтому я и думал, что и здесь такие цены.
Все настройки делаются через Versa Director. Там веб-интерфейс. Настройка интерфейсов, к примеру, выглядит так:
Versa Director отправляет этот конфиг на филиальное устройство. На самом устройстве это видится в виде Juniper-подобного листинга:
interfaces {
vni-0/1 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
address 11.11.11.11/24;
}
}
}
}
vni-0/2 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
address 172.89.45.1/24;
}
}
}
}
vni-0/32 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
dhcp;
}
}
}
}
vni-0/34 {
enable true;
promiscuous false;
unit 0 {
enable true;
family {
inet {
address 172.20.20.1/24;
}
inet6;
}
Versa Director отправляет этот конфиг на филиальное устройство. На самом устройстве это видится в виде Juniper-подобного листинга:
interfaces {
vni-0/1 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
address 11.11.11.11/24;
}
}
}
}
vni-0/2 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
address 172.89.45.1/24;
}
}
}
}
vni-0/32 {
enable true;
unit 0 {
vlan-id 0;
enable true;
family {
inet {
dhcp;
}
}
}
}
vni-0/34 {
enable true;
promiscuous false;
unit 0 {
enable true;
family {
inet {
address 172.20.20.1/24;
}
inet6;
}
Для домашнего использования, возможно, действительно окажется дороговато. Целевая аудитория SD-WAN это энтерпрайз с большим количеством удалённых площадок.
Цена опять же сильно зависит от функционала, который вы приобретаете. У Versa можно выбирать из Basic/Advanced SD-WAN, NGFW, UTM, CG-NAT.
То, что вы описываете с терминированием TCP, это скорее про оптимизацию трафика. Конкретно Versa этим не занимается. В решении Versa вы определяете типы трафика по L2-L7-характеристикам и устанавливаете для них SLA и действия, которые предпримет железка, при нарушении этих SLA. Можно начать дуплицировать пакеты в другой канал, если потери в первом превышают 2%, можно перекинуть весь поток на более качественный канал, если в текущем задержки превышают заданное значение и т.п.
Цена опять же сильно зависит от функционала, который вы приобретаете. У Versa можно выбирать из Basic/Advanced SD-WAN, NGFW, UTM, CG-NAT.
То, что вы описываете с терминированием TCP, это скорее про оптимизацию трафика. Конкретно Versa этим не занимается. В решении Versa вы определяете типы трафика по L2-L7-характеристикам и устанавливаете для них SLA и действия, которые предпримет железка, при нарушении этих SLA. Можно начать дуплицировать пакеты в другой канал, если потери в первом превышают 2%, можно перекинуть весь поток на более качественный канал, если в текущем задержки превышают заданное значение и т.п.
Для дома, я думаю, хватит OpenWRT c mwan3.
Правильно ли я понимаю, что сам оператор связи ( в вашем тесте это MTC и Мегафон) должны поддерживать SD-WAN? или заслуга SD-WAN заключается в том, что CPE железка устанавливает 2 BGP сессии через 2-ух провайдеров для сигнализации к контроллеру, от него она получает обо всех других удаленных офисах, а также тип балансировки (per-packet, per-session) опять же через 2 активные BGP Сессии? и как CPE узнает, что первый канал может 10 Мбит, в второй — 50? Это нужно задавать в настройках вручную? То есть по сути versa как и другой SD-WAN провайдер предлает WEB-интерфейс для удаленного управления CPE, а также «услуги» в виде BGP route-reflector-a?
продавец перетыкает шнурок из одной «коробки» в другуюТо есть это в том случае когда у нас резервирование не только через несколько модемов, но и физическое резервирование CPE устройств? т.е они работают только в режиме Active-Standby?
BGP нужен для передачи маршрутной информации сайтов организации и на базе этого принимается решение о построении динамических туннелей. Сама BGP сессия устанавливается в служебном IPSec туннеле.
Оператор не должен поддерживать SD-WAN и с ним не надо пириться по BGP (за исключением MPLS каналов связи).
Тип балансировки (per-packet, per-session) задается вручную, но per-application.
Полоса пропускания задается вручную при настройке филиальной железки на Versa Director, плюс есть возможность настройки трафик-shaping под эту полосу.
Резервирование в Active-Active режиме обеспечивается за счёт установки 2-х коробок на сайт.
Про «перетыкание провода», это о том что делать, если сломалось устройство на небольшом сайте, где нет админов.
Versa это вендор, который предлагает решение SD-WAN с поддержкой multi-tenancy, аналитики и функций безопасности. Все компоненты вы можете развернуть в своей инфраструктуре и полностью ими управлять.
Основное отличие от других производителей решений SD-WAN – это средства аналитики и безопасность (например, NGFW на базе NFV).
SD-WAN, можно сравнить с DMVPN у Cisco, только с SD-WAN вы можете:
— быстро настраивать и подключать конечные устройства через Director (Zero-Touch-Provisioning)
— для конкретных приложений определять, что делать с их трафиком в зависимости от текущих потерь, задержек, джиттера
— определять типы трафика на базе URL
— балансировать трафик приложений по пакетам по сессиям, переключать его с канала на канал, копировать пакеты в параллельный канал для нивелирования потерь.
Оператор не должен поддерживать SD-WAN и с ним не надо пириться по BGP (за исключением MPLS каналов связи).
Тип балансировки (per-packet, per-session) задается вручную, но per-application.
Полоса пропускания задается вручную при настройке филиальной железки на Versa Director, плюс есть возможность настройки трафик-shaping под эту полосу.
Резервирование в Active-Active режиме обеспечивается за счёт установки 2-х коробок на сайт.
Про «перетыкание провода», это о том что делать, если сломалось устройство на небольшом сайте, где нет админов.
Versa это вендор, который предлагает решение SD-WAN с поддержкой multi-tenancy, аналитики и функций безопасности. Все компоненты вы можете развернуть в своей инфраструктуре и полностью ими управлять.
Основное отличие от других производителей решений SD-WAN – это средства аналитики и безопасность (например, NGFW на базе NFV).
SD-WAN, можно сравнить с DMVPN у Cisco, только с SD-WAN вы можете:
— быстро настраивать и подключать конечные устройства через Director (Zero-Touch-Provisioning)
— для конкретных приложений определять, что делать с их трафиком в зависимости от текущих потерь, задержек, джиттера
— определять типы трафика на базе URL
— балансировать трафик приложений по пакетам по сессиям, переключать его с канала на канал, копировать пакеты в параллельный канал для нивелирования потерь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устойчивый канал на базе программно-определяемых сетей SD-WAN: решаем проблемы выбора маршрутов