Как работает балансировка нагрузки CoreOS в облачной службе?

Скажем, у меня есть кластер CoreOS, развернутый где-то в каком-то облачном сервисе.

Теперь у меня есть, скажем, 4 машины, на которых запущено приложение node.js, которое следует всем 12-факторным принципам, и одна машина с Couchbase.

Как работает балансировка нагрузки в этом сценарии? Разве ОДИН ip не исчерпает себя в качестве балансировщика нагрузки, или это практически невозможно? Куда мне указать DNS, чтобы он работал правильно?

Раньше у меня был один IP-адрес с заранее установленным NGINX, который затем направлял входящие запросы в циклическом стиле.

Как это работает с CoreOS в облачной службе?


cloud load-balancing cluster-computing coreos
person dsp_099    schedule 13.03.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

DNS указывает на ваш облачный балансировщик нагрузки с выходом в Интернет, который в любом случае управляет уровнем клиентского уровня. В случае AWS это должно быть через запись CNAME.

Автоматически масштабируемые группы для каждого уровня потенциально могут снизить риск снижения доступности вашей инфраструктуры. Затем экземпляры Nginx настраиваются через облачную конфигурацию на случай, если требуется подготовка на этапе начальной загрузки.

  1. Двухуровневая архитектура (ваш сценарий)

    • What you need:
      1. Nginx instances cluster (client tier)
      2. Кластер базы данных (уровень данных)

    Каждый экземпляр Nginx прослушивает порт HTTP и использует восходящие потоки для выполнения маршрутизации (в зависимости от вашего распределения приложений NodeJS). Обнаружение службы достигается через etcd с использованием Registrator + SkyDNS / Consul или Weaver, поэтому вместо восходящего потока преобразователь Nginx может быть заменен внутренним DNS, предоставляемым такими инструментами.

  2. Трехуровневая архитектура

    • What you need:
      1. Nginx instances cluster (client tier)
      2. Кластер приложений (бизнес-уровень)
      3. Кластер базы данных (уровень данных)

    То же самое относится к инстансам Nginx, как и к двухуровневому, хотя клиентские уровни решают задачи приложений бизнес-уровня (с использованием внутреннего облачного балансировщика нагрузки), а также единиц, содержащихся локально. Бизнес-уровень будет вести себя аналогично первому клиенту в двухуровневой архитектуре, но с учетом правильной конфигурации групп безопасности.

В обоих случаях уровень данных образует независимый регион (SkyDNS) или центр обработки данных (Consul). Кроме того, вы можете в конечном итоге пропустить Nginx, но вам нужно будет публично открыть больше портов в ваших группах безопасности.

Получение знаний от:

Я смог построить:

TODO: версия для консула. Хотя есть пример для SkyDNS и Ambassadord.

Использованная литература:

** Дайте мне знать ваши комментарии.

person ericson.cepeda    schedule 01.04.2015
comment
Вау, отличный ответ. Мне нужно время, чтобы все это переварить, сейчас это немного выше моей головы. - person dsp_099; 02.04.2015