Только что заглянул в Elastic Load Balancers. Насколько я понимаю, они просто выполняют циклический перебор, равномерно распределяя подключения к серверам за ними. Так что же произойдет, если за ELB стоят экземпляры разного размера? Отправляет ли он больше подключений к более крупному экземпляру или продолжает равномерно распределять подключения, что означает, что вам действительно не следует использовать экземпляры разных размеров.
Насколько я понимаю, они просто выполняют циклический перебор, равномерно распределяя подключения к серверам за ними.
Вроде, но не совсем, я думаю - к сожалению, Amazon ELB документация по маршрутизации не существует, поэтому нужно собрать несколько частей, чтобы сделать вывод. Вот единственный фрагмент из Руководство разработчика Elastic Load Balancing Я в курсе, см. Раздел Прикрепленные сеансы в Обзор эластичной балансировки нагрузки:
По умолчанию балансировщик нагрузки направляет каждый запрос независимо к экземпляру приложения с наименьшей нагрузкой. Однако вы можете использовать функцию закрепления сеанса (также известную как привязка сеанса), которая позволяет подсистеме балансировки нагрузки привязать сеанс пользователя к конкретному экземпляру приложения. Это гарантирует, что все запросы, поступающие от пользователя во время сеанса, будут отправлены одному и тому же экземпляру приложения. [курсив мой]
Что теперь наименьшая нагрузка имею в виду именно? Опять же, единственное известное мне объяснение - это несколько расплывчатый ответ команды AWS с 2009 г. ELB Стратегия:
ELB слабо отслеживает, сколько запросов (или соединений в случае TCP) ожидает обработки в каждом экземпляре. Он не отслеживает использование ресурсов (таких как ЦП или память) в каждом экземпляре. В настоящее время ELB будет выполнять циклический поиск среди тех экземпляров, у которых, по ее мнению, меньше всего невыполненных запросов. [курсив мой]
Это имеет большой смысл с точки зрения их системной архитектуры и рассматриваемых вариантов использования, но, очевидно, не обеспечивает прозрачности и / или контроля маршрутизации, которые могут вам понадобиться или понадобятся для расширенных сценариев высокой доступности.
Обратите внимание, что, в зависимости от интерпретации, это может или не может немного противоречить более позднему ответу команды AWS на Elastic Load Balancing - Политики распределения нагрузки:
В игру вступает циклический перебор, но клиентские сеансы не всегда соблюдают TTL или кеш DNS, поэтому вы можете получить искаженные результаты и неравномерное распределение запросов. ELB не учитывает, какие экземпляры трафика / запросов получили на текущий момент в решениях о маршрутизации трафика. [курсив мой]
Конечно, вышеизложенное дополняется должным образом документированным, прозрачным и контролируемым проверки здоровья, что дает вам некоторое преимущество (потенциально временно) для удаления экземпляров из включения в маршрутизацию в первую очередь, как описано в вышеупомянутом ответе команды AWS на ELB Стратегия также:
Балансировщик нагрузки отслеживает состояние ваших экземпляров, зарегистрированных в балансировщике нагрузки. Когда балансировщик нагрузки обнаруживает проблему с экземпляром, он прекращает распределять трафик на него. Когда экземпляр снова станет работоспособным, балансировщик нагрузки перезапускает распределение трафика на него. Этот процесс позволяет вашему приложению автоматически реагировать на отказавшие экземпляры без вашего участия, кроме настройки проверки работоспособности.
Конечно, необычно, но я не понимаю, почему ELB не должен работать с пулом разных Типы инстансов Amazon EC2 а также - я сам не пробовал и рекомендую оба, Мониторинг вашего балансировщика нагрузки с помощью CloudWatch а также мониторинг ваших индивидуальных экземпляров EC2 и сопоставление результатов, чтобы в конечном итоге получить соответствующее понимание и уверенность в такой настройке.
Основываясь на утверждениях, сделанных до сих пор, алгоритм распределения чрезвычайно прост.
Внешний интерфейс ELB обычно представляет собой более одного экземпляра ELB, а распределение является циклическим.
Бэкэнд (ваши экземпляры) утверждает, что он:
ELB нечетко отслеживает, сколько запросов (или соединений в случае TCP) ожидает обработки в каждом экземпляре. Он не отслеживает использование ресурсов (таких как ЦП или память) в каждом экземпляре. В настоящее время ELB будет выполнять циклический поиск среди тех экземпляров, у которых, по ее мнению, меньше всего невыполненных запросов.
Это будет означать, что если у более крупного экземпляра будет меньше невыполненных запросов, то к нему будет перенаправлен больший трафик. Нет никакого способа гарантировать это.