Проблемы Возможности соединения филиала

Мы столкнулись с аналогичными проблемами, и увеличение пропускной способности почти не помогло. Основные проблемы, которые у нас были, были с SharePoint и CRM. Однако передача файлов также была болезненной.

Мы протестировали, а затем установили оптимизаторы WAN Riverbed Steelhead в офисах, и разница была поразительной. Количество обращений в службу поддержки CRM и SharePoint упало почти до нуля, и пользователи были намного счастливее. Это не обязательно улучшит Skype и другие приложения реального времени, но может высвободить пропускную способность, поэтому приложения реального времени увидят улучшение.

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

Установка была очень простой, и мы работали менее чем за час. Текущая настройка позволяет дополнительно оптимизировать трафик.

У меня нет связи с Riverbed, и я просто очень довольный пользователь.

установите openwrt или производную в качестве шлюза, включите sqm-скрипты или qos-скрипты с fq_codel с правильно измеренными реальными скоростями входящего и исходящего трафика и установите чуть ниже.

Пример результатов: http://burntchrome.blogspot.com/2014_05_01_archive.html

Есть несколько очевидных возможностей для того, что следует проверить дальше:

• Может быть, указанная провайдером пропускная способность в 20 Мбит/с предназначена только для входящего трафика. Если исходящий трафик в каждой точке меньше, то связь между двумя точками никогда не сможет использовать полную входящую пропускную способность ни в той, ни в другой точке.
• Если любая из этих точек насыщена в одном направлении, вы можете столкнуться с повышенной латентностью при прохождении по кругу и падением пакетов. В мягких случаях разбухания буфера это может увеличить задержку на десятки миллисекунд, в одном крайнем случае я видел, что это приводит к 60-секундному времени на обход.
• Возможно, некоторые из хостов имеют дело с тем, что они находятся за NAT. Если вы находитесь за NAT, Skype может перенаправлять ваши звонки через других пользователей Skype. Если вы не находитесь за NAT, Skype может перенаправлять звонки других пользователей через ваших хостов. Обе ситуации могут привести к плохим результатам работы пользователей.
• У вас может быть несколько уровней NAT. Если вы не проверили, то не можете быть уверены в том, что в вашем ЦП есть как NAT, так и CGN, развернутая провайдером

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

Если связь с вашим сайтом насыщена в одном или обоих направлениях, вам может понадобиться управлять пропускной способностью. Управление входящей пропускной способностью не является тривиальным, потому что к тому времени, как она достигнет вашего оборудования, она уже будет потреблять полосу пропускания на входящем канале. Если вы сталкиваетесь с этой конкретной проблемой, решением может стать запрет на прямой доступ ваших пользователей к каналу ISP. Вместо этого вы направляете весь трафик через туннель в хорошо связанное место (100 Мбит/с и более в центре обработки данных с задержкой не более 1 мс на магистральную линию). Как только вы маршрутизируете весь трафик через туннель, вы можете управлять пропускной способностью при входе в туннель.

Если у вас есть NAT на каждом сайте, и хосты, находящиеся за NAT, являются частью вашей проблемы, вы можете получить некоторое преимущество от туннеля между сайтами, таким образом, хосты на каждом сайте могут общаться друг с другом без использования NAT. (Я не знаю, могут ли Skype и Hangouts извлечь из этого выгоду)

Туннель между двумя сайтами будет возможен даже в том случае, если один из сайтов находится за CGN. Но если оба сайта находятся за CGN, то туннель между ними не будет надежным. Если вы случайно оказались в такой ситуации и все же нашли необходимость в туннеле между сайтами, у вас есть два варианта. Либо вы получаете публичный IPv4 адрес как минимум на одном из сайтов, либо вы получаете IPv6 на обоих сайтах.

Комбинирование туннеля с туннелем между сайтами может усложнить управление пропускной способностью, поскольку у вас есть два источника, посылающих пакеты по одному каналу, и ни один из них не знает в реальном времени о том, сколько посылает другой источник. Эту проблему можно решить, забыв о туннеле между сайтами, и вместо этого направить весь трафик с одного сайта через выбранную хорошо подключенную точку, независимо от того, общаетесь ли вы с другим сайтом или с внешним.

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

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