Чем проще, тем лучше, или когда ELB не нужен

    Скорее всего, передовой облачный провайдер Amazon Web Services в первую очередь ассоциируется с EC2 (виртуальные инстансы) и ELB (балансировщик). Типичная схема разворачивания web-сервиса — EC2 инстансы за балансировщиком (Elastic Load Balancer).Преимуществ у такого подхода очень много, в частности, у нас «из коробки» есть проверка состояния нод, мониторинг (количество запросов, логи), легко настраивамое авто-масштабирование и т.д. Но далеко не всегда ELB — лучший выбор для распределения нагрузки, а иногда и вовсе не подходящий инструмент.

    Под катом я покажу два примера использования Route 53 вместо Elastic Load Balancer-а: первый — из опыта компании Loggly, воторой — из моего личного.

    Loggly


    Loggly — сервис централизованного сбора и анализа логов. Инфраструктура развернута в облаке AWS. Основную работу по сбору логов выполняют так называемые коллекторы — приложения, написанные на C++, котороые принимают информацию от клиентов по TCP, UDP, HTTP, HTTPS. Требования к коллекторам очень серьёзные: работать максимально быстро и не терять ни одного пакета! Другими словами, приложение должно собирать все логи, не смотря на интесивность входящего трафика. Естественно, коллекторы должны горизонтально масштабироваться, и трафик между ними должен распределяться равномерно.

    Первый блин комом


    Ребята из Loggly для балансировки сначала решили использовать ELB.



    Первая проблема, с которой они столкнулись, была производительность. При десятках тысяч событий в секунду задержка на балансировщике начала расти, что было несопоставимо с назначением коллекторов. Далее проблемы посыпались, как спелые яблоки: невозможно пересылать трафик на порт 514, не поддерживается UDP, ну и известная проблема «холодного баласировщика» Pre-Warming the Load Balancer — проявляется при резком возрастании нагрузки.

    Замена на Route53


    Далее начали искать замену ELB. Оказалось, что простой DNS round robin полностью устраивает, и Route53 решает задачу распределения трафика, исключая проблемы с ELB. Без промежуточного звена в виде балансировщика задержка уменьшилась, так как трафик начал идти напрямую от клиентов к инстансам с коллекторами. Никакого дополнительного «разогрева» не требуется при резких увеличениях объёмов сообщений. Также Route53 проверяет «здоровье» коллекторов и повышает доступность системы в целом, потери информации сводятся к нулю.

    Вывод


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

    Percona Cluster


    В нашей инфраструктуре основное хранилище данных — это Percona Cluster. Множество приложений используют его. Основными требованиями были отказоустойчивость, производительность и минимальные усилия по поддержке его. Хотелось один раз сделать и забыть.

    Со стороны приложения решили использовать постоянное для каждого окружения (dev, test, live) DNS имя для общения с кластером. Тем самым облегчили жизнь разрабочикам и себе по конфигурации и сборке приложений.

    ELB не подошёл


    Балансировщик нам не подошёл примерно по тем же причинам, что и в случае Loggly. Сразу подумали о HA Proxy в качестве балансировки нагрузки, тем более, что Percona советуют использовать именно такое решение. Но получать ещё одну точку отказа в виде HA Proxy сервера не хотелось. Кроме того, дополнительные расходы на содержание и администрирование никому не нужны.

    Route53 + Percona


    Когда обратили внимание на этот сервис в качестве распределителя нагрузки и проверки состояния серверов кластера, казалось что в несколько кликов получим нужный результат. Но, после детального изучения документации, нашли фундаментальное ограничение, которое рубило на корню всю архитектуру окружения и кластера в нем. Дело в том, что Percona Cluster, как и большинство остальных серверов, расположены в приватных подсетях, а Route 53 может проверять только публичные адреса!

    Огорчение длилось не долго — возникла новая идея: проверку состояния сделать самим и использовать Route 53 API для обновления DNS записи.

    Итоговое решение


    На проекте повсеместно для мониторинга системных сервисов используется Monit. Его и настроили для следующих автоматических действий:
    • Проверка порта MySQL
    • Изменение DNS записи при отсутствии ответа
    • Отсылка нотификации
    • Попытка перезапустить сервис

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

    Заключение


    Два случая, описанные в статье, показывают, что Route 53 иногда для распределения нагрузки и обеспечения отказоустойчивости подходит гораздо лучше, чем ELB. В то же время, API облачных провайдеров позволяет обходить многие ограничения их же сервисов.
    EPAM
    Компания для карьерного и профессионального роста

    Comments 14

      +2
      запускать несколько elb и делать на них round-robin в route53 не пробовали?
        0
        Возможно я не верно вас понял, но если речь о втором случае с percona cluster, то elb совершенно излишен, так как все ноды находятся в одном регионе и все что нам нужно это раунд робин для запросов. На мой взгляд, все дело в том, что elb заточен изначально был под типичные web приложения.
          +3
          он и заточен под типичные веб-приложения.
          я, на самом деле, крайне удивлен, что у вас возникла идея использовать elb для балансировки SQL.
          вы только на websocket'ы не смотрите, а то будет очередная статья-разоблачение «какой elb отстой».
            0
            Во-первых, статья — не разоблачение, а лишь два случая использования Route53. Факты описанные в статье, давно известны.
            Во-вторых, отметать балансировщик только потому, что он «заточен под веб», без детального рассмотрения глупо.
        +1
        Я тоже применяю monit буквально для всего :-)

        Крайне полезной оказалась конструкция "… ELSE IF SUCCEEDED THEN ..."
          0
          У нас правило: любой application cookbook, который конфигурирует сервис, должен и монит конфиг для него добавлять.
          +2
          Использование DNS-only в качестве балансировщика сулит кучей сложно-отдебаживаемых проблем.
            0
            А приведите-ка пример.

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

                Проблема может возникнуть и с ELB за Route53, так как elb скейлится, периодически его IP меняются.
                  0
                  ELB при смене ІР продолжает обслуживать старую ІР некоторое время.
                    0
                    Для этого существует Connection Draining, по-дефолту выставленный в 300 секунд.
                    0
                    А если такой failover DNS использовать? http://www.zoneedit.com/failover.html
              • UFO just landed and posted this here

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