Расхождения в использовании процессора и памяти для кластеров ejabberd и Riak на AWS

Question

Я запускаю кластер с двумя узлами ejabberd (за балансировкой эластичной нагрузки), который, в свою очередь, соединяется с кластером Riak с тремя узлами (опять же через ELB) на AWS. Когда я загружаю платформу через Tsung (создавая 0,5 миллиона пользовательских регистраций), я замечаю, что загрузка процессора для узлов ejabberd отличается между собой примерно на 10%. Для узлов Riak загрузка процессора и памяти между узлами отличается примерно на 5%.

Узлы имеют идентичную конфигурацию, поэтому задаются вопросом, что может привести к этим нетривиальным различиям в использовании. Может ли кто-нибудь пролить свет здесь, пожалуйста,/просветите меня?

Это связано с балансировкой нагрузки? Или влияние сети? Я ожидаю, что после создания кластера (либо из ejabberd, либо из Riak KV) узлы все одинаковы по своему поведению, особенно для ejabberd, где вся база данных реплицируется по всему кластеру.

Не то, что эти различия являются проблемой, но было бы хорошо, чтобы понять внутреннюю работу кластеров здесь ...

Большое спасибо.

Answer 1

Elastic Load Balancing механизм

• DNS-сервер использует DNS круговой, чтобы определить, какой узел балансировки нагрузки в определенной за доступность зоны получит запрос
• выбранной проверку балансировки нагрузки для «липкой сессии» печенья
• Выбранные балансировки нагрузки посылает запрос на наименее загруженный экземпляр

и более подробно:

Наличие зоны (маловероятно, что ваш случай)

По умолчанию, балансировки нагрузки узла маршруты движения к серверным экземпляров в пределах одной и той же зоне доступности. Чтобы ваши задние экземпляры могли обрабатывать нагрузку на запрос в каждой зоне доступности, важно иметь приблизительно эквивалентное количество экземпляров в каждой зоне. Например, если у вас есть десять экземпляров в зоне доступности us-east-1a и два экземпляра в us-east-1b, трафик будет по-прежнему распределяться между двумя зонами доступности. В результате два экземпляра в us-east-1b должны будут обслуживать тот же объем трафика, что и десять экземпляров в us-east-1a.

Сессии (, скорее всего, ваш случай)

По умолчанию Балансировщик Нагрузки перенаправляет каждый запрос независимо от экземпляра сервера с наименьшей нагрузкой. Для сравнения, липкий сеанс связывает сеанс пользователя с конкретным экземпляром сервера, так что все запросы, поступающие от пользователя во время сеанса, будут отправляться на тот же экземпляр сервера.

AWS Elastic Beanstalk использует файлы cookie, созданные с помощью балансировки нагрузки, когда для приложения разрешены липкие сеансы. Балансировщик нагрузки использует специальный файл cookie, созданный с помощью балансировки нагрузки, для отслеживания экземпляра приложения для каждого запроса. Когда балансировщик получает запрос, он сначала проверяет, присутствует ли этот файл cookie в запросе. Если это так, запрос отправляется экземпляру приложения, указанному в файле cookie.Если cookie не существует, балансировщик нагрузки выбирает экземпляр приложения на основе существующего алгоритма балансировки нагрузки. Куки-файл вставляется в ответ для привязки последующих запросов от одного и того же пользователя к экземпляру этого приложения. Конфигурация политики определяет срок действия файла cookie, который устанавливает продолжительность действия для каждого файла cookie.

маршрутизация Алгоритм (менее вероятно, ваш случай)

балансировки нагрузки узел посылает запрос на здоровые экземпляры в пределах одной зоны доступности с использованием leastconns алгоритма маршрутизации. Алгоритм маршрутизации lessconns поддерживает back-end экземпляры с наименьшими соединениями или невыполненными запросами.

Источник: Elastic Load Balancing Terminology And Key Concepts

Надежда это помогает.