Рубрика «балансировка трафика»

Распределение нагрузки в облаке IaaS-провайдера помогает эффективно использовать ресурсы виртуальных машин. Существует множество методов распределения нагрузки, но в сегодняшнем материале мы подробно остановимся на одних из самых популярных статических методах: round-robin, CMA и threshold algorithm. Под катом поговорим о том, как они устроены, в чем их характерные особенности и где они используются.

Знакомство с облаком: как работают статические методы распределения трафика - 1Читать полностью »

Каждого представляет Джеральд Брофловски, адвокат из Саус Парка, который рассчитывает получить неплохую комиссию. Противоположную сторону каждого представляет… Джеральд Брофловски! Кажется, папу Кайла ждут нехилые бабосы независимо от исхода дела.

South Park, серия 306, «Панда—сексуальное домогательство»

Smug Alert!

Не так давно наши коллеги рассказали на конференции HighLoad++ о решении задачи балансировки нагрузки в облаках Google и Amazon, а также DNS-балансировки с использованием сервиса gdnsd. Это отличное введение в тему, с которым стоит познакомиться всем, кого жизнь уже заставила завести несколько фронтендов. И практическое руководство, если вы вынуждены иметь дело с облачным хостингом.

К счастью, бывают случаи, когда вы можете позволить себе удовольствие работать с реальным оборудованием, а не с облаками. Автор этих строк обожает реальное оборудование и готов часами рассказывать про его плюсы:
Читать полностью »

Балансировка нагрузки с Pacemaker и IPaddr (Active-Active cluster) - 1

Хочу рассказать вам еще об одном способе балансировки нагрузки.
Про Pacemaker и IPaddr (ресурс-агент) и настройке его для Active/Passive кластера сказано уже и так достаточно много, но информации по организации полноценного Active/Active кластера, используя этот модуль я нашел крайне мало. Постараюсь исправить эту ситуацию.

Для начала расскажу подробнее чем такой метод балансировки примечателен:

  • Отсутсвие внешнего балансировщика — На всех нодах в кластере настраивается один общий виртуальный IP-адрес. Все запросы отправляются на него. Ноды отвечают на запросы на этот адрес случайно и по договоренности между ссобой.
  • Высокая доступность — Если одна нода падает ее обязаности подхватывает другая.
  • Простота настройки — Настройка осуществляется всего в 3-5 команд.
    Читать полностью »

Что делать, когда не работает prepend - 1

Хотим поделиться переводом серии заметок из блога Расса Уайта (Russ White), где он поднимает вопрос использования AS-PATH Prepend при подключении к Интернет-провайдерам по BGP.
При подключении организации к двум и более провайдерам по BGP могут возникать несколько задач. Например, избежать асимметричной маршрутизации, т. е., добиться, чтобы ответные пакеты возвращались через того же провайдера, через которого инициируется сессия. Или, наоборот, добиться равномерного распределения трафика по каналам провайдеров, не принимая во внимание асимметричную маршрутизацию. В обоих случаях влиять на маршрутизацию Интернет-провайдеров в сторону корпоративной сети можно с помощью BGP-атрибута AS-PATH. Но, к сожалению, данный подход далеко не всегда помогает добиться нужного результата. О проблемах использования AS-PATH Prepend как раз и пойдёт речь.Читать полностью »

Недавно обзавёлся задачей по балансировке трафика между несколькими usb-модемами. В итоге родилось решение коим и хочу поделиться с читателим.

На момент написания статьи это balancing_v0.5.2-alpha.

Изначально задача формулировалась примерно так:

Есть пучёк armhf девайсов c Ubuntu Trusty на борту.
У них есть несколько подключений к интернету. Обычно это основное проводное подключение (eth0) и несколько HiLink usb-модемов Huawei E303 (eth1-eth5). Через каждое из этих подключений нужно поднять openvpn-клиентов к единственному серверу и через них уже балансировать трафик.

Всё бы ничего, но у этих модемов нет возможности изменения подсети и шлюза (гвоздями прибиты 192.168.1.1/24), причём прошивок с реализацией этой возможности тоже не нашлось (в отличии, например от E3272 для которого есть прошивки с таким функционалом). Кроме того даже если бы и нашлись, то vpn-подключения всё равно были бы в одной подсети и с одинаковым шлюзом. Т.е. без продвинутой маршрутизации (policy routing) не обойтись.

Ах, да, ещё надо мониторить каждое подключение и отключать/включать, если порвалось/возобновилось. Т.е. маршрутизацией нужно управлять динамически.
Читать полностью »

По городам и весям или как мы балансируем между узлами CDN Когда вы выросли настолько, что появились узлы в разных городах, возникает задача распределения нагрузки между ними. Задачи такой балансировки могут быть разными, но цель, как правило, одна: сделать так, чтобы было хорошо. У меня дошли руки рассказать о том, как это делают обычно, и как это сделано в ivi.ru.

В предыдущей статье я рассказал, что CDN у нас свой, при этом тщательно избегал подробностей. Пришла пора поделиться. Рассказ будет в стиле поиска решения, каким он мог бы быть.
Читать полностью »

Я упомянул, что разработал балансировщик на Go, хотя есть мнение, что фронтендом должен быть ngnix.

У меня есть такое чувство, что в комментах люди бывает фантазируют, о чем угодно. Возможно кто-то думает, что и я брешу и нет балансировщика на Go. Поэтому, я решил выложить код балансировщика сразу. Этот код был написан в “особой ситуации” за 4 часа, и потом работал примерно в такой форме 2 недели без перегрузки так, как “все” были в Греции. Код не красив и даже содержит ошибки, но так как он работал и балансировал, то уже чего то стоит.

Под катом почти оринальный скорописный балансировщик. Я убрал оригинальные константы и код декодирования кук.
Читать полностью »

Спасибо Хабру, много полезного тут для себя нашел. Думаю, пора «отдавать долги».
Хочу описать алгоритм, который работает больше года на моем шлюзе для балансировки каналов (Гбит трафика, 8k клиентов, 2 провайдера, AS на 1k адресов, большинство клиентов за NAT). Возможно, кому-то пригодится. Во всяком случае, ничего похожего не встречал и когда специально искал — не нашел. Так что полностью мое детище.
Конечно, указанный алгоритм нельзя считать универсальным, подойдет только в подходящих условиях.

Итак, исходные:
— Шлюз на Linux (Debian 6). Используется пакет quagga (бывший zebra).
— Два провайдера (пусть будут ТТК и РТК). Каждый дает канал определенной толщины, «лишнее» режет.
— AS на 1k адресов (пусть будет 1.1.144.0/22). AS0000.
— Большинство клиентов имеют серые адреса (пусть будет 192.168.0.0/16), «клиентские» сети 192.168.1-99.0/24, на шлюзе натятся.
— Небольшая часть клиентов имеют белые адреса в пространстве моей AS.

Задача:
Обеспечить равномерную загрузку каналов ТТК и РТК входящим трафиком для исключения перегрузки каналов.
Читать полностью »

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

  • Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
  • Подключаемся к провайдеру по BGP
  • Организуем резервирование и распределение нагрузки между несколькими линками
  • Рассмотрим вариант резервирования без использования BGP – IP SLA

Читать полностью »

Предистория

Рано или поздно системный администратор сталкивается с необходимостью распределить трафик по нескольким каналам, при этом естественно желание чтобы каждый канал использовался по максимуму. Столкнувшись с подобной необходимостью, и решив не изобретать велосипед, обратился к помощи поисковиков. Так как сервер у меня на Ubuntu, то обратил свое внимание на статью http://help.ubuntu.ru/wiki/ip_balancing. Реализовал «Способ 1», но при тесте были замечены следующие критичные проблемы: при использовании ссылок на некоторых сайтах они не открывались (например при попытке включить музыку на ресурсе «ВКонтакте»). Причина очевидна — запрос шел через другой канал. Обдумав ситуацию, решил скомбинировать подход к балансировке. Логика проста — больше всего съедает трафика торренты и им подобные программы, поэтому разделяем трафик. В итоге трафик с портами до 11000 распределяем приблизительно равномерно по количеству абонентов — подсетями, трафиком с портами 11000-60000 выравниваем загрузку каналов.
Читать полностью »