Comments 18
Если оно будет торчать с нескольких площадок одним адресом и гонять трафик можно будет в чужие ДЦ — то да, оно может быть интересной.
Если оно будет торчать с нескольких площадок одним адресом
Если две разные железки будут иметь один адрес, то это называется anycast. Для TCP, особенно в случае неконтролируемой глобальной маршрутизации, ну очень нежелательно, никто так не делает. Если же сеть будет анонситься с двух разных точек, но внутри сети все пути ведут на один балансировщик, то смысл так делать? Навернулся балансировщик или ЦОД целиком, и до свидания. Плюс маршрутизация трафика будет неоптимальной.
А вот active/standby в двух разных локациях уже интереснее. Но тоже не очень здорово.
Наиболее популярное решение — DNS балансировщики раскидывают запросы по HTTP (или прочим) балансировщикам, каждый из которых обслуживает только свою площадку. Это если надо делать воистину отказоустойчивый и территориально распределенный сервис.
Делают, и вполне успешно, надо сказать.
Никогда не слышал про глобальную балансировку TCP методом anycast. У кого-то, может, и достаточно крутые яйца для этого, но обычно это чревато тем, что юзеров из AS, равноудаленных от обеих анонсирующих адрес ASок, будет постоянно кидать туда-сюда, и при каждом перебрасывании текущая сессия будет рваться.
Для UDP, если общение будет лишь в виде запрос-ответ (без продолжения беседы) — да, anycast великолепен.
Точно ничего не путаете? Может, просто одна сеть анонсируется в две стороны, но принимает коннекты одна и та же железка?
Для UDP, если общение будет лишь в виде запрос-ответ (без продолжения беседы) — да, anycast великолепен.
Точно ничего не путаете? Может, просто одна сеть анонсируется в две стороны, но принимает коннекты одна и та же железка?
OpenDNS так делает
Ну понятно, что у тех, кто так делает — яйца крутые =)
В рамках одного HTTP запроса перекидываний не происходит. Так что всё ок (конечно, проектировать с умом надо приложение).
Да и анонсы идут с разными приоритетами, чтобы совсем уже такого не происходило часто.
В рамках одного HTTP запроса перекидываний не происходит. Так что всё ок (конечно, проектировать с умом надо приложение).
Да и анонсы идут с разными приоритетами, чтобы совсем уже такого не происходило часто.
В рамках одного HTTP запроса перекидываний не происходит.
Один запрос = один пакет, так что логично черт возьми… Но я говорил про то, что одна TCP сессия может начаться с одним балансировщиком (SYN — SYN ACK — ACK — DATA), а закончиться с другим (DATA — RST (ты вообще кто такой, почему не представился по форме, где SYN???)).
проектировать с умом надо приложение
Причем тут приложение, когда мы говорим о сетевом стеке на L3-L4? От приложения тут уже мало что зависит.
Да и анонсы идут с разными приоритетами
Какие еще приоритеты, вы про что сейчас?
У BGP в глобальных сетях есть лишь один «приоритет» (абсолютно неприменимый термин на самом деле), работающий на все AS дальше первой — AS_PATH, и одно средство манипуляции им — prepend. Поставить маленький — и кто-то все равно окажется на «терминаторе». Поставить большой — и никто не будет пользоваться соответствующим маршрутом, и балансировки уже нет, есть лишь фейловер, реализованный крайне некрасиво.
> сессия может начаться с одним балансировщиком
Только если по пути стоят ну очень тупые роутеры, которые флашат маршруты для существующих соединений. В противном случае сессия просто порвется и установится заново (что в рамках http приемлимо, опять же).
В реальной жизни я такого не встречаю.
> Причем тут приложение
Если приложение спроектировано так, что оно не страдает от падающих tcp-сессий — то оно будет работать в таких условиях.
> есть лишь фейловер,
А такие решения и нужны для HA, не для балансировки.
Для правильной балансировки нужны умные DNS серверы, которые отдают пользователям только одну A/AAAA запись (если речь о http, опять же). RR тут не поможет.
В любом случае, я в архитектуру балансировки подробно не вдавался. Там и OSPF играет роль и трафик может уйти с одного бордера в балансировщик в другом ДЦ — много всяких «если», в общем.
Факт же в том, что при одном IP, горящем с 3х бордеров я имею нагрузку на все ДЦ в соотношении ~60/20/20. Как оно реализовано — меня на самом деле не очень заботит, мне хорошо от того, что эта конструкция всегда доступна и всегда пересылает трафик в риалы, с коими я и работаю.
Только если по пути стоят ну очень тупые роутеры, которые флашат маршруты для существующих соединений. В противном случае сессия просто порвется и установится заново (что в рамках http приемлимо, опять же).
В реальной жизни я такого не встречаю.
> Причем тут приложение
Если приложение спроектировано так, что оно не страдает от падающих tcp-сессий — то оно будет работать в таких условиях.
> есть лишь фейловер,
А такие решения и нужны для HA, не для балансировки.
Для правильной балансировки нужны умные DNS серверы, которые отдают пользователям только одну A/AAAA запись (если речь о http, опять же). RR тут не поможет.
В любом случае, я в архитектуру балансировки подробно не вдавался. Там и OSPF играет роль и трафик может уйти с одного бордера в балансировщик в другом ДЦ — много всяких «если», в общем.
Факт же в том, что при одном IP, горящем с 3х бордеров я имею нагрузку на все ДЦ в соотношении ~60/20/20. Как оно реализовано — меня на самом деле не очень заботит, мне хорошо от того, что эта конструкция всегда доступна и всегда пересылает трафик в риалы, с коими я и работаю.
Только если по пути стоят ну очень тупые роутеры, которые флашат маршруты для существующих соединений.
Вы разве не в курсе, что роутерам вообще плевать на соединения, они их не отслеживают? Ну дела :) Срочно учить модель OSI!
Если в таблице маршрутизации есть два равнозначных маршрута, и не включен per-packet loadbalancing (а иногда он бывает включен), то на основании L3/L4 заголовков вычисляется хеш и в зависимости от него выбирается, куда следовать (по крайней мере так действует CEF). Что-то изменилось — один и тот же хеш начнет давать одному пакету из одной и той же сессии другой next hop.
А изменение маршрутов в глобальной маршрутизации — явление совершенно обыденное.
В противном случае сессия просто порвется и установится заново (что в рамках http приемлимо, опять же).
Вы путаете разрыв сессии с потерей небольшого количества пакетов. В рамках HTTP разрыв сессии означает как минимум «браузер не смог загрузить страницу, нажмите F5». Допустимо ли это? Определенно нет. Ну а так как примерно никто не настраивает репликацию сессий между площадками — посетитель интернет-магазина к примеру после закидывания на другую площадку обнаружит, что корзина резко опустели.
Если приложение спроектировано так, что оно не страдает от падающих tcp-сессий
Падение TCP сессии — одно. Закидывание клиента на другой сервер или кластер — другое.
Для правильной балансировки нужны умные DNS серверы, которые отдают пользователям только одну A/AAAA запись (если речь о http, опять же). RR тут не поможет.
Именно это я и писал чуть выше. И это касается не только HTTP.
DNS прекрасно работает с anycast, но этот подход неприменим к основанным на TCP сервисам.
Если, конечно, в ТЗ не сказано «половина сессий клиентов может дропаться, ничего страшного».
трафик может уйти с одного бордера в балансировщик в другом ДЦ
Этого, само собой, надо всеми силами избегать. В факапной ситуации класса «или так, или никак» (ну там все каналы на одной из площадок слегли) это еще допустимо, но в иных случаях — нет.
при одном IP, горящем с 3х бордеров я имею нагрузку на все ДЦ в соотношении ~60/20/20.
Один префикс вещается сразу с трех площадок? Опять же, ни разу не элегантное решение. Пакет входит в ЦОДе 1 и от него летит в ЦОД 2, хотя мог сразу войти через ЦОД 2 (но в итоге он все равно попадет на один и тот же балансировщик, а не на два разных!). Однако, тут проблема лишь в ненужной нагрузке на каналы между площадками. Такой подход не вызовет нестабильности — если только какой-либо дебил не догадался поставить по независимому файрволу за каждым из бордеров. Но раз говорите, что сервис работает нормально — это вряд ли.
Вы мыслите в несколько ограниченных рамках.
Нет, я не путаю HTTP и TCP сессии. Да, я умею растягивать один логический кластер на в теории безлимитное кол-во хостов. С матами и стонами я там даже DB с hot-swap-master подниму. С репликацией сессий, блекджеком и шлюхами. Лишь бы код, который в кластере логику обрабатывать будет, поддерживал всё это.
А дальше я опущу ересь про «причёмтутdnsиunicast», а просто в ответ на:
> пакет входит в ЦОДе 1 и от него летит в ЦОД 2, хотя мог сразу войти через ЦОД 2 (но в итоге он все равно попадет на один и тот же балансировщик, а не на два разных!)
спрошу:
«С хуябы?».
Нет, я понимаю, что глобально маршрутизируюемые сети не принято зажигать на нескольких машинах, и что справиться с этим сможет только очень опытный NOC. Но всё же ;)
Нет, я не путаю HTTP и TCP сессии. Да, я умею растягивать один логический кластер на в теории безлимитное кол-во хостов. С матами и стонами я там даже DB с hot-swap-master подниму. С репликацией сессий, блекджеком и шлюхами. Лишь бы код, который в кластере логику обрабатывать будет, поддерживал всё это.
А дальше я опущу ересь про «причёмтутdnsиunicast», а просто в ответ на:
> пакет входит в ЦОДе 1 и от него летит в ЦОД 2, хотя мог сразу войти через ЦОД 2 (но в итоге он все равно попадет на один и тот же балансировщик, а не на два разных!)
спрошу:
«С хуябы?».
Нет, я понимаю, что глобально маршрутизируюемые сети не принято зажигать на нескольких машинах, и что справиться с этим сможет только очень опытный NOC. Но всё же ;)
Ну нельзя было последний пункт таким делать) Не надо быть Чуровым, чтобы любую статистику перевернуть, сделав одним из пунктов вариант
[v] Пыщ, пыщ, я Бэтмен!
[v] Пыщ, пыщ, я Бэтмен!
LB от Селектел точно не нужен.
А есть ли особый смысл пока траффик внутри датацентра платный?
Внешний LB — хорошая альтернатива для быстрого и дешевого старта. Только вот вопрос о деньгах — думаю будет убийственным.
Сделаете это за $30 в месяц?
Сделаете это за $30 в месяц?
В итоге в России так и не найти услугу load balancer для облачных виртуальных серверов. 2015 год, Карл!
Sign up to leave a comment.
Интересна ли вам услуга LoadBalancer?