AWS Insight: Как работает ELB

    Привет! image

    Хочу поведать читателям Хабрахабра о сервисе Elastic Load Balancer, который входит в состав Enterprise Compute Cloud. Многие давно уже пользуются сервисом ELB, но не знают как работает сервис изнутри. Я немного владею этой информацией — многочасовые митинги с саппортом AWS иногда гораздо познавательнее документации на сайте.

    Итак, начнём с основ, потом перейдём к нюансам.

    Что такое ELB.


    Elastic Load Balancer — это сервис, предоставляющий балансировку запросов между инстансами EC2/VPC. Соответственно есть 2 типа ELB, которые
    • видны из интернета — EC2/VPC
    • не видны из интернета — VPC

    Возможности ELB


    ELB умеет проксировать следующие протоколы:
    • http
    • https
    • tcp
    • ssl (secure tcp)

    Причём как слушатели, так и получатели могут быть любой комбинации. Например http-http (просто прокси) или tcp — https (если SSL терминация производится на стороне инстансов)

    ELB умеет проксировать порты:
    • 25
    • 80
    • 443
    • 1024-65535

    Настройка ELB


    В консоли находим пункт Load Balancers и там тыцаем Create Load Balancer. Первый скрин — настройка портов и протоколов:


    Далее, т.к. мы выбрали HTTPS, нам нужен сертификат для терминации SSL. AWS спрашивает у нас настройки:


    Далее настраиваем хелсчек — проверка здоровья хоста. Если хелсчек положительный, инстанс будет в списке на балансировку. Отрицательный — на инстанс не будут отправляться запросы:


    Хелсчеки можно настроить на те же протоколы, что и балансировку, на http/https можно добавить имя странички или путь.

    Ну и в финале — нужно выбрать инстансы, которые вы хотите добавить под ELB (на скриншоте просто пример)


    Последний скрин — как всегда проверка деталей:


    Просмотрели, решили, что всё ок и создали ELB.

    Как настроить домен на ELB


    У EC2 ELB есть 3 адреса, по которым к ним можно обращаться. Это не IP адреса, а URL:
    • myelb-1161081434.us-east-1.elb.amazonaws.com (A Record)
    • ipv6.myelb-1161081434.us-east-1.elb.amazonaws.com (AAAA Record)
    • dualstack.myelb-1161081434.us-east-1.elb.amazonaws.com (A or AAAA Record)


    Есть 2 пути настроить свой домен на ELB и зависят они от того, какие серверы имён вы используете. Рекомендуется использовать Amazon Route 53, т.к. он интегрирован с ELB и там всё легко настраивается через A запись:


    Если же вы используете другие DNS сервисы/серверы — ваш путь CNAME.

    Sticky session


    ELB способен обрабатывать куки для Sticky session. Эти функции можно настроить в конфигурации после создания ELB:


    Автомасштабирование ELB


    Тут хотелось бы рассказать о том, как масштабируется ELB и как он себя ведёт под нагрузкой. Я уже опубликовывал статью, в которой сравнивал производительность ELB, NGINX и HAproxy. Там я затронул момент масштабирования. ELB вертикально промасштабировался с t1.micto до m1.small:
    image

    По словам представителей техподдержки Amazon Web Services при увеличении нагрузки на ELB проходит от одной до семи минут перед тем, как произойдёт масштабирование сервера. IP адрес может быть поменян, поэтому не рекомендуется использовать IP адреса для доменов (я описал выше выход из ситуации).

    Для отдельных случаев ELB может быть «разогрет» до нужного шейпа, чтобы выдерживать большие нагрузки. «Разогрев производится» через запросы в техподдержку.

    Автомасштабирование EC2/VPC


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

    У ELB ещё есть много нюансов работы, но основное я рассказал.

    Есть ли у вас опыт работы с ELB? Интересные факты?
    EPAM
    405.41
    Компания для карьерного и профессионального роста
    Share post

    Comments 48

      +4
      А как ведет себя ELB с точки зрения отказоустойчивости? Что будет, если одна из зон датацентра ляжет, не затронет ли это ELB?
        +1
        Официальное мнение амазона: нехрен все яйца в одной корзине держать и мучать их дурацкими вопросами.

        >Incoming traffic is load balanced equally across all Availability Zones enabled for your load balancer, so it is important to have approximately equivalent numbers of instances in each zone. For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones. As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a. As a best practice, we recommend you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones. So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.
        docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/arch-loadbalancing.html

        Это нормально, для примера, мне они просто не смогли ответить на вопрос, что будет если я уберу таймауты у политик масштабирования и в заказе повиснет больше спотов, чем может влезть в группу, а потом заказы выполнятся.
        Ответ был: просто не делайте этого и проставьте таймауты.
          0
          За отказоустойивостью ELB стоит AWS. Они сами перевезут в другую зону, если под ним стоят инстансы из живой зоны.
            0
            А где ни будь гарантируют такое письменно?
              –1
              Это подтверждено опытом.
              +1
              Как долго ELB будет переезжать из одной зоны в другую, каков будет downtime? Будет ли это seamless или придется менять DNS'ы вручную?
                –1
                Адреса у ELB всегда одинаковые. Поменяются IP. По поводу времени, не считал. Но опыт последних даунтаймов в us-east-1 говорит о том, что всё очень быстро. HA конфигурации, с зональным распределением отработали отлично.
                  +1
                  Спасибо за ответы и содержательную статью, теперь буду спать спокойнее ^_^
                    +1
                    Даунтайм будет ровно на то время которое вы выставите в TTL CNAME'a. При условии, что амазон оперативно перевез ваш ELB в другую зону конечно же:)
                      –1
                      Чессгря, у них как-то всё быстро работает. На всех проектах зоны хостим в Route53 — это даёт преимущество перед другими сервисами.
                        +1
                        Так я не против, что быстро:) Я и сам не жалуюсь на Route53, благо давно перехали туда со всяких годедди.

                        Просто синейм резолвится в IP. Соответвенно, чем длиннее у вас TTL, тем дольше ждать нового балансера. Ведь они не зря у ELB IPшники меняют.
                          0
                          Вы привязываете CNAME к ELB?
                            +1
                            Нет, юзаем Alias, а там кстати TTL 60s, что в приницпе тоже самое. Если только они не направляют трафик на новый ELB не меняя IP.
                              0
                              Да, в последнее время я заметил тенденцию, что они не меняли IP при скейлинге. Вы тоже?
                                0
                                Не замечал, надо будет как раз понаблюдать.
                                  +1
                                  Вот, полезный документик http://aws.amazon.com/articles/1636185810492479

                                  И там говорится, что если клиент не резолвит днс вашего балансера раз в минуту, то новые мощности балансера, который отресайзился на больший ему будут недоступны. Соответвенно они меняют IP при скейлинге.

                                  Там же написано о «прогреве» балансера. Именно этот сомнительный пункт без цифр меня до сих пор пугает.
              +2
              ИМХО самая предсказуемая и спокойная часть AWS.

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

              Старт инстанса в амазоне есть великое таинство. Конечно у них есть приоритеты ondemand>reserved>spot (по коммерческим соображениям), но разброс их времени старта перекрывается и сильно завязаны на типы. У меня и деменды стартовали по 15 минут и споты вспыхивали моментально, после приобретения. Фактически амазон не предоставляет никаких гарантий. Только гарантии насчет принадлежности к группе приоритетов.

              Плюс, насколько я понял из своих экспериментов, резервирование EBS (больше — дольше) тоже лочит процесс старта. ELB по хорошему диск толком не нужен.
                +1
                А где, простите, сама информация о том, как работает ELB? Все, что вы написали, можно легко найти в документации за несколько минут. Я, например, ждал инфы о технологии проксирования, о том, как происходит терминация SSL, задействован ли NAT… статья ни о чем.
                  0
                  Это информация под NDA у них. Мне редко говорят что-то такое, и то перед релизами. К сожалению, это закрытая информация.
                    +2
                    И толку тогда с такой статьи? Статусом партнера можно и более продуктивно понтоваться.
                    +3
                    По некоторым неофициальным данным — для проксирования HTTP и терминации SSL ранее использовалось проприетарное решение их разработки, а сейчас сильно модифицированный NGINX.
                    Чего в их балансире не работает:
                    — баланирование на портах менее чем 1024 (т.е. зарезервированные порты) — не позволят
                    — UDP как только не пытайтесь
                    — «волшебные» TCP пакеты тоже не балансируются — поэтому если ВДРУГ Вы решили сделать игровой сервис с несовсем стандартной структурой пакетов — то Вам неповезло.

                    По поводу терминации SSL ничего интересного нету — есть почти везде и для всех серверов.
                    +10
                    Зачем вы меня обманули? В начале статьи пообещали рассказать о внутренностях, а на самом деле статья — пересказ документации. Зря потерял время.
                      +1
                      Для отдельных случаев ELB может быть «разогрет» до нужного шейпа, чтобы выдерживать большие нагрузки. «Разогрев производится» через запросы в техподдержку.


                      Это воощбе прекрасно, имхо. А, если у меня рекламная кампания внезапно сработала на 100%, вместо ожидаемых 50%. Опять же никакой конкретики. Большие нагрузки это сколько? У меня больше или меньше, а когда тогда «просить» у саппорта масштабирование? Не всегда очевидно.
                        +1
                        Масштабирование происходит автоматически. Если инстанс не выдерживает, то масштабируется дальше. Разогрев это для отдельного случая, например первый запуск продакшна — чтоб инфраструктура сразу была готова к хайлоаду.
                          +1
                          Кмк, если хочешь быть уверен — делай все сам.
                          Ротацию nginx настроить дело незайтейливое. С AS конечно сложнее будет, так как нужно будет ловить в том или ином виде сигналы о подъеме инстансов и обновлять конфигурацию.
                          +1
                          Пока используем для вебсокетов, т.к. легче повесить отдельный сертификат, плюс не заморачиваться разбором трафика tcp-http на 80-м порту.
                            +1
                            А как балансируете вебсокеты?
                            ELB же не умеет делать sticky balancing для TCP/SSL (i.e. ws/wss).
                              +1
                              Так все тем же rr, сессия открылась и даржится с обоих сторон, закрылась когда нужно, в след раз попадет на другой сервер, ну и ладно. Вообще правильно так писать бекенды, что бы было неважно на какой попал клиент. Не всегда получается, но все же.
                                +1
                                Ага, знакомая картина. Тогда часто возникает другой вопрос.
                                Вот допустим у нас стоит ферма апп-серверов, которые держат tcp (ws, etc) соединения с клиентами через ELB. И дальше где-то на бекенде возникает необходимость послать сообщение клиенту X. Как определяете сервер, который нужно пнуть чтобы сообщение ушло этому клиенту?

                                Сам апп-сервер может роутить месиджи любым клиентам, которые сейчас к нему приконекчены — держит in-memory ConcurrentMap и нет проблем.
                                А какие best-practices вы знаете, чтобы роутить месиджы к самим апп-серверам?

                                На моем конкретном проекте этих краевых серверов мало, и я делаю broadcast запрос по ним в рамках одного региона Amazon. Но наверняка есть варианты лучше.
                                  +1
                                  Тут уже вам врядли подскажу best-practices, но осмелюсь предположить, что можно хранить сообщения клиентам в редисе например, а апп-серверами проверять не стоит ли для какого то клиента джоб и забирать, если так.
                                    0
                                    Можно придумать многов вариантов. Я бы остановлися на каком-то который использует по максимуму существующие сервисы AWS: DynamoDB, SNS, SQS и т.д.
                                      +1
                                      А вот тут не соглашусь.Использую AWS сервисы только, если преимущества против своих перевешивают.
                                        0
                                        Иногда, самым главным преимуществом является то, что это не нужно настраивать. Оно уже есть и стоит не дорого.
                                          +1
                                          Само собой это примущество. Но бывает, что это нужно еще донести до разработчиков, а потом задуматься как резервировать в случае капута:)
                                  +1
                                  Есть сервис SNS, подпишите на топик все апп серверы. Все апп серверы получат сообщение, а если к ним приконнекчен искомый юзер, то сообщение будет ему послано.

                                  Сейчас SQS интегрирован с SNS. Стало легко комбинировать очереди и подписки.
                                    –1
                                    Тут имелись ввиду сообщения внутри открытых вебсокетов и оповещения серверов, что нужно отправить что-то новое клиенту внутри нужного коннекта.
                            +1
                            По словам представителей техподдержки Amazon Web Services при увеличении нагрузки на ELB проходит от одной до семи минут перед тем, как произойдёт масштабирование сервера. IP адрес может быть поменян, поэтому не рекомендуется использовать IP адреса для доменов (я описал выше выход из ситуации).


                            У Амазона TTL для зоны 3-5 минут? Поменяют они адрес, но в кеше DNS серверов останутся старые записи.
                              +1
                              Да ттл у амазона маленький.
                                +1
                                маленький — это 60секунд — минимум меньше которого большинство сетевых устройств иначе игнорирует это свойство.
                                  +1
                                  Для этого случая там стоит 60 сек. Все есть в их документации.
                              +1
                              Кстати, а организовывал кто нибудь статистику по ELB, я имею ввиду когда ка какой бекенд выкинуло, 500 и т.д.?
                                0
                                Такие беды бывают только, когда в регионе фейлы. В обычное время, у меня всё ок. Во всяком случае Мониторгинг системы не рапортят о 500 ошибках.
                                +1
                                Сейчас как раз используем ELB и AS в одном проекте. К сожалению до сих пор AWS не позволяет настроить гибридный AS при котором по возможности создаются spot instances, а при невозможности — ondemand. Есть правда вот такой путь, но времени попробовать пока не было. Была еще мысль написать свой собственный монитор, но как я понял Cloudwatch умеет только либо выполнять AS policy, либо послать notify на email. Остается вариант написать свой ping, который будет долбить во все инстансы каждые 30 секунд и проверять метрики через Cloudwatch API
                                А вообще штука хорошая — серьезно пока не подводила
                                  0
                                  А как обеспечиваете HA на уровне самого ELB? В случае, если сам ELB упал.

                                  Сами инстансы, которые стояли за ним, могут быть или живы, или мертвы (допустим, отрубился весь регион и мы хотим переключить его клиентов на другие континенты).
                                    0
                                    Это уже формально не HA, а DR — Disaster Recovery. Тут уже обычные AWS тулзы не подходят. Нужны бекапы в другой регион, репликации, синхронизации и тому подобные обычные вещи.
                                    0
                                    Сегодня обнаружили неприятную для нас особенность ELB. Неактивные коннекты обрубаются через 60 секунд.
                                      +1
                                      Оставлю для потомков:) Таймаут повышается через запрос в саппорт.

                                    Only users with full accounts can post comments. Log in, please.