+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Запрос на добавление функциональности: расширенная балансировка исходящего трафика. Нам нужно добавить более продвинутую балансировку исходящего трафика, чтобы, например, можно было выбирать бекенды на основе их загруженности, географического положения и

Запрос на добавление функциональности: расширенная балансировка исходящего трафика. Нам нужно добавить более продвинутую балансировку исходящего трафика, чтобы, например, можно было выбирать бекенды на основе их загруженности, географического положения и

RSS

eugenevdm

Guest

01.09.2005 04:04:00

Похоже, в RouterOS есть два способа для исходящего балансирования нагрузки: ECMP и маршрутизация по исходному адресу. Маршрутизация по исходному адресу неплоха, когда у тебя всего несколько клиентов, но как только у тебя начинают появляться сотни, и тебе приходится полагаться на несколько (дешёвых) каналов связи, чтобы равномерно распределять пропускную способность, маршрутизация по исходному адресу становится неидеальной, потому что ты не всегда можешь предсказать, насколько загружены будут конкретные группы клиентов. ECMP работает в этом плане неплохо, но у него есть свои проблемы, например, обрывы загрузок и определённые приложения, ориентированные на соединение (MSN, VoIP и т.д.), которые зависят от того, чтобы пакеты приходили в том же порядке / или с тем же исходным адресом, с которого они пришли. Я видел эту технологию на сайте Cisco под названием "Cisco Express Forwarding", которая упоминает механизм переключения под названием "Per-Destination". (Смотри http://www.cisco.com/warp/public/105/loadbal_cef.html) Похоже, преимущество в том, что "Поскольку балансирование нагрузки по назначению зависит от статистического распределения трафика, распределение нагрузки становится более эффективным по мере увеличения количества пар источник-назначение". Эх, была бы это отличная фича для RouterOS, правда?

lastguru

Guest

01.09.2005 12:36:00

ECMP не может разорвать никакое соединение, потому что он не работает на основе соединения, а на основе IP-пары. Быстрый поиск в Google показывает следующее (похожее упоминается в документации, мне кажется): ядро Linux выполняет многопутевую маршрутизацию по принципу flow-based. "Flow" здесь означает "все соединения с одинаковым источником и одинаковым назначением", так что если вы будете тестировать вашу ECMP-настройку, начиная несколько FTP-передач с клиента A на сервер B, то все пойдет через 1 интерфейс.

changeip

Guest

01.09.2005 18:34:00

Из руководства MT (2.9): Для каждой новой пары IP-адресов источника/назначения выбираются новые шлюзы. Это означает, что, например, одно FTP-соединение будет использовать только одну линию, но новое соединение с другим сервером будет использовать другую линию. ECMP-маршрутизация имеет ещё одну хорошую особенность: пакеты одного соединения не переупорядочиваются и поэтому не влияют на производительность TCP. Проблема в том, что эти IM-программы не поддерживают единое соединение на протяжении всего времени подключения — они очень мимолетны, хотя и используют TCP. Итак, когда вы входите в систему, вы можете использовать один IP-адрес в течение первых 5 минут, но когда их системы решают переключиться (используя балансировку нагрузки на своей стороне!) на другой сервер, они не связывают ваш предыдущий IP-адрес и тоже запутываются. Это приводит к таким симптомам, как повторный вход и выход из системы и т.д. Проблемы с реализацией протокола в приложении, а не с Mikrotik. ECMP — по каждой паре IP-адресов, без учета портов. Поэтому соединение с одним сервером на другом конце не должно вызывать проблем при использовании ECMP. Проблемы возникают, когда вы добавляете множество TCP-соединений к разным машинам, которые все вместе работают для удаленного сервера, например, сайт вроде hotmail или yahoo webmail и т.д. Единственный верный способ избавиться от всех этих проблем, по моему мнению, — это возможность отправлять пакеты из обоих шлюзов, используя один и тот же диапазон IP-адресов источника. Или использовать политический маршрутизатор и настроить его в соответствии с настройками вашей сети. Сэм.

kjagus

Guest

01.09.2005 21:10:00

Они должны, но не работают. Классические вещи, вроде скачивания из одного сервера, классическая система чата и т.д., сломались из-за ECMP, и никто не знает, что с этим делать. Я использовал ECMP несколько недель, пытался заставить это работать, спрашивал поддержку MT, других местных "гуру"... и потерял пару клиентов за это время… ECMP совершенно не работает с mt. Забудьте про эту "фишку".

rpingar Guest	#5 0 02.09.2005 05:57:00 Надежного способа связать upstream-соединения без помощи твоего провайдера не существует. ECMP не решит проблему с IM, IRC… и так далее. С уважением.

mp3turbo2 Guest	#6 0 12.09.2005 10:36:00 В целом, согласен. Я лично вижу роль ECMP только в контролируемой среде, к которой «открытый интернет» точно не относится. Причём, если подумать, ECMP можно использовать, чтобы почти удвоить скорость беспроводной передачи — вместо одной антенны на каждом конце нужно использовать две (четыре всего для одного соединения). Затем, используя ECMP, можно удвоить (или почти удвоить) скорость передачи. Ваше самое внешнее подключение к интернету должно быть только одно. Давайте сравним преимущества и недостатки двух ECMP-соединений с «ограниченной» связью, как у nstreme2: Преимущества ECMP: (теоретически) более высокая пропускная способность для всех объединенных TCP/UDP потоков, поскольку это должно объединить две независимые линии по 20 Мбит/с в одну, способную на «почти» 40 Мбит/с. Эта пропускная способность в 40 Мбит/с может динамически распределяться по каналам загрузки/отдачи, так что в один момент у вас может быть 30 Мбит/с на загрузку и 10 Мбит/с на отдачу, а в другой — 5 Мбит/с на загрузку и 35 Мбит/с на отдачу. Хотя один клиент не увидит преимущества более высокой скорости на одном потоке загрузки, у вас будет лучше общая пропускная способность, что очень значительное преимущество для вас. Nstreme2: почти реальная «полнодуплексная» работа, отдельные каналы TX/RX. Общая пропускная способность не удваивается, объедините две обычные полудуплексные линии по 20 Мбит/с, и у вас получится одна с 20 Мбит/с на загрузку И ПОЛНОСТЬЮ СОВРЕМЕННО 20 Мбит/с на отдачу. То есть, общая пропускная способность не будет 40 Мбит/с в одном направлении, как в первом случае, но у вас будет ПЕРФЕКТНЫЕ 20 Мбит/с. Иногда это важно.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры