company_banner

Интересна ли вам услуга LoadBalancer?

     

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Интересна ли вам услуга LoadBalancer?

    • 25,0%Да, HTTP264
    • 12,0%Да, DNS127
    • 2,6%Да, RTSP28
    • 5,4%Нет, будет дорого57
    • 14,5%Нет, проще самому сделать153
    • 1,6%Хочу балансировать... (написал в комментах)17
    • 61,4%Ты что такое? давай до свидания648
    Selectel
    ИТ-инфраструктура для бизнеса

    Комментарии 18

      +1
      Если оно будет торчать с нескольких площадок одним адресом и гонять трафик можно будет в чужие ДЦ — то да, оно может быть интересной.
        0
        Если оно будет торчать с нескольких площадок одним адресом

        Если две разные железки будут иметь один адрес, то это называется anycast. Для TCP, особенно в случае неконтролируемой глобальной маршрутизации, ну очень нежелательно, никто так не делает. Если же сеть будет анонситься с двух разных точек, но внутри сети все пути ведут на один балансировщик, то смысл так делать? Навернулся балансировщик или ЦОД целиком, и до свидания. Плюс маршрутизация трафика будет неоптимальной.
        А вот active/standby в двух разных локациях уже интереснее. Но тоже не очень здорово.

        Наиболее популярное решение — DNS балансировщики раскидывают запросы по HTTP (или прочим) балансировщикам, каждый из которых обслуживает только свою площадку. Это если надо делать воистину отказоустойчивый и территориально распределенный сервис.
          0
          Делают, и вполне успешно, надо сказать.
            +2
            Никогда не слышал про глобальную балансировку TCP методом anycast. У кого-то, может, и достаточно крутые яйца для этого, но обычно это чревато тем, что юзеров из AS, равноудаленных от обеих анонсирующих адрес ASок, будет постоянно кидать туда-сюда, и при каждом перебрасывании текущая сессия будет рваться.
            Для UDP, если общение будет лишь в виде запрос-ответ (без продолжения беседы) — да, anycast великолепен.

            Точно ничего не путаете? Может, просто одна сеть анонсируется в две стороны, но принимает коннекты одна и та же железка?
              0
              OpenDNS так делает
                +1
                А по какому транспортному протоколу работает DNS (за исключением передачи зоны целиком) — не подскажете? :)

                Рут хинты тоже так делают. И?
                0
                Ну понятно, что у тех, кто так делает — яйца крутые =)
                В рамках одного HTTP запроса перекидываний не происходит. Так что всё ок (конечно, проектировать с умом надо приложение).
                Да и анонсы идут с разными приоритетами, чтобы совсем уже такого не происходило часто.
                  +1
                  В рамках одного HTTP запроса перекидываний не происходит.

                  Один запрос = один пакет, так что логично черт возьми… Но я говорил про то, что одна TCP сессия может начаться с одним балансировщиком (SYN — SYN ACK — ACK — DATA), а закончиться с другим (DATA — RST (ты вообще кто такой, почему не представился по форме, где SYN???)).
                  проектировать с умом надо приложение

                  Причем тут приложение, когда мы говорим о сетевом стеке на L3-L4? От приложения тут уже мало что зависит.
                  Да и анонсы идут с разными приоритетами

                  Какие еще приоритеты, вы про что сейчас?
                  У BGP в глобальных сетях есть лишь один «приоритет» (абсолютно неприменимый термин на самом деле), работающий на все AS дальше первой — AS_PATH, и одно средство манипуляции им — prepend. Поставить маленький — и кто-то все равно окажется на «терминаторе». Поставить большой — и никто не будет пользоваться соответствующим маршрутом, и балансировки уже нет, есть лишь фейловер, реализованный крайне некрасиво.
                    0
                    > сессия может начаться с одним балансировщиком
                    Только если по пути стоят ну очень тупые роутеры, которые флашат маршруты для существующих соединений. В противном случае сессия просто порвется и установится заново (что в рамках http приемлимо, опять же).
                    В реальной жизни я такого не встречаю.

                    > Причем тут приложение
                    Если приложение спроектировано так, что оно не страдает от падающих tcp-сессий — то оно будет работать в таких условиях.

                    > есть лишь фейловер,
                    А такие решения и нужны для HA, не для балансировки.
                    Для правильной балансировки нужны умные DNS серверы, которые отдают пользователям только одну A/AAAA запись (если речь о http, опять же). RR тут не поможет.

                    В любом случае, я в архитектуру балансировки подробно не вдавался. Там и OSPF играет роль и трафик может уйти с одного бордера в балансировщик в другом ДЦ — много всяких «если», в общем.
                    Факт же в том, что при одном IP, горящем с 3х бордеров я имею нагрузку на все ДЦ в соотношении ~60/20/20. Как оно реализовано — меня на самом деле не очень заботит, мне хорошо от того, что эта конструкция всегда доступна и всегда пересылает трафик в риалы, с коими я и работаю.
                      0
                      Только если по пути стоят ну очень тупые роутеры, которые флашат маршруты для существующих соединений.

                      Вы разве не в курсе, что роутерам вообще плевать на соединения, они их не отслеживают? Ну дела :) Срочно учить модель 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 (но в итоге он все равно попадет на один и тот же балансировщик, а не на два разных!). Однако, тут проблема лишь в ненужной нагрузке на каналы между площадками. Такой подход не вызовет нестабильности — если только какой-либо дебил не догадался поставить по независимому файрволу за каждым из бордеров. Но раз говорите, что сервис работает нормально — это вряд ли.
                        0
                        Вы мыслите в несколько ограниченных рамках.

                        Нет, я не путаю HTTP и TCP сессии. Да, я умею растягивать один логический кластер на в теории безлимитное кол-во хостов. С матами и стонами я там даже DB с hot-swap-master подниму. С репликацией сессий, блекджеком и шлюхами. Лишь бы код, который в кластере логику обрабатывать будет, поддерживал всё это.

                        А дальше я опущу ересь про «причёмтутdnsиunicast», а просто в ответ на:
                        > пакет входит в ЦОДе 1 и от него летит в ЦОД 2, хотя мог сразу войти через ЦОД 2 (но в итоге он все равно попадет на один и тот же балансировщик, а не на два разных!)
                        спрошу:
                        «С хуябы?».

                        Нет, я понимаю, что глобально маршрутизируюемые сети не принято зажигать на нескольких машинах, и что справиться с этим сможет только очень опытный NOC. Но всё же ;)
                          0
                          Вы действительно совсем-совсем не понимаете TCP :)
          0
          Ну нельзя было последний пункт таким делать) Не надо быть Чуровым, чтобы любую статистику перевернуть, сделав одним из пунктов вариант

          [v] Пыщ, пыщ, я Бэтмен!
            –8
            LB от Селектел точно не нужен.
              0
              А есть ли особый смысл пока траффик внутри датацентра платный?
                0
                Ключевое слово «пока», кто знает, что будет.
                0
                Внешний LB — хорошая альтернатива для быстрого и дешевого старта. Только вот вопрос о деньгах — думаю будет убийственным.

                Сделаете это за $30 в месяц?
                  0
                  В итоге в России так и не найти услугу load balancer для облачных виртуальных серверов. 2015 год, Карл!

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое