Как настроить глобальную балансировку нагрузки с помощью Digital Ocean DNS и Nginx?

Рабочее Решение

у меня была дикая поездка за последние несколько месяцев, выясняя всю глобальную настройку HA. Тонны удовольствия, и я, наконец, решил с установкой, которая работает очень хорошо, и ничего похожего на тот, который изложен в приведенном выше вопросе.

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

обзор

в итоге я переместил все свое развертывание в AWS. Я люблю Digital Ocean, но откровенная реальность заключается в том, что AWS на световые годы опережает их (и всех, действительно), когда дело доходит до услуг, предлагаемых под одной крышей. Мои ежемесячные расходы немного выросли, но как только я закончил настройку и оптимизацию, я получил решение, которое стоит около $ 75 / месяц в регионе для самого базового развертывания (2 экземпляра за вязом). И новый регион может быть развернут и развернут в течение 30 минут.

Глобальная Балансировка

я быстро узнал (благодаря ответу @Brad выше), что попытка раскрутить мой собственный глобальный балансирующий DNS-слой безумна. Было чертовски весело выяснить, как работает такой слой, но за исключением того, чтобы сесть на самолет и поскрести костяшки пальцев, устанавливая оборудование стоимостью в миллионы долларов вокруг мир, я не собирался сворачивать свой собственный.

когда я, наконец, понял, что я искал, я нашел своего нового лучшего друга:AWS Route 53. Он предлагает надежную сеть DNS с о 50 с лишним узлов в мире и возможность делать некоторые действительно крутые трюки маршрутизации, такие как маршрутизация на основе местоположения, маршрутизация на основе задержки (что является своего рода удивительным) и AWS Alias записывает, что "автоматически" трафик маршрута к другим сервисам AWS вы будете использовать (например ELB для балансировки нагрузки).

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

Я оставлю это до вас, чтобы сделать домашнее задание на других поставщиков:www.f5.com, www.dyn.com, www.akamai.com, www.dnsmadeeasy.com. В зависимости от ваших потребностей, может быть лучше решение для вас, но это работает очень хорошо для меня.

Сеть Доставки Контента

сервис Route 53 интегрируется с AWS Cloudfront очень красиво. Я настраиваю ведро S3, которое я использую для хранения всех статических медиафайлов, которые мои пользователи будут загружать, и я настроил дистрибутив Cloudfront на источник из my media.myapp.com ведро S3. Есть и другие поставщики CDN, так что делайте покупки. Но оно становится очень хорошо отзывы и Оснастки для установки.

балансировка нагрузки и завершение SSL

в настоящее время я использую AWS эластичный балансировщик нагрузки чтобы сбалансировать нагрузку на мои экземпляры приложений, которые живут в Группа Автоматического Масштабирования. Запрос сначала получает ELB, после чего SSL завершается и запрос передается экземпляру в режиме автоматического масштабирования Группа.

Примечание: одно гигантское предостережение для ELB заключается в том, что, по иронии судьбы, он не очень хорошо справляется с массивными шипами. Это может занять до 15 минут для ELB, чтобы вызвать масштабирование события для себя, создавая 500 / таймауты в то же время. Считается, что постоянное увеличение трафика происходит очень хорошо, но если вас ударит Спайк, он может вас подвести. Если вы знаете, что вас ударят, вы можете "позвонить вперед" , и AWS разогреет ваш ELB для вас, который довольно нелепо и анти-шаблон по сути AWS, но я представляю, что они либо работают над ним, либо игнорируют его, потому что это не такая уж большая проблема. Вы всегда можете раскрутить свой собственный HAProxy или nginx и слой балансировки нагрузки, если ELB не работает для вас.

Группа Автоматического Масштабирования

каждая область имеет ASG который запрограммирован для того чтобы масштабировать когда нагрузка проходит некоторую метрику:

IF CPU > 90% FOR 5 MINUTES: SCALEUP
IF CPU < 70% FOR 5 MINUTES: SCALEDN

Я еще не поставил комбинацию ELB/ASG через свои шаги. Это немного ниже моего списка дел, но я знаю, что есть много других, использующих эту настройку, и у нее, похоже, нет никаких серьезных проблем с производительностью.

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

1. создайте AMI, настроенный по своему вкусу.
2. создать конфигурацию запуска, которая использует ОИМ вы создали.
3. создайте группу автоматического масштабирования, использующую созданную конфигурацию запуска, чтобы определить, какой AMI и тип экземпляра запускать для любого события масштабирования.

для обработки конфигурации и развертывания приложений при запуске любого экземпляра используется "Данные Пользователя" поле для ввода скрипта, который будет выполняться после запуска любого данного экземпляра. Это, возможно, худшая номенклатура в истории времени. Как" пользовательские данные " описывает сценарий запуска знает только автор. Во всяком случае, там вы вставляете скрипт, который обрабатывает все ваши apt-gets, mkdirs, git-клоны и т. д.

Экземпляры И Внутренняя Балансировка

Я также добавил дополнительный "внутренний балансировочный слой" с помощью Nginx, который позволяет мне "упаковать" весь мой узел.JS apps (app.myapp.com, api.myapp.com, mobile.myapp.com, www.myapp.com, etc.myapp.com) в каждом случае. Когда экземпляр получает запрос, переданный ему из ELB, nginx обрабатывает маршрутизацию запроса на правильный узел.порт js для любого данного приложения. Что-то вроде контейнеризации для бедных. Это имеет дополнительное преимущество, что в любое время одно из моих приложений должно разговаривать с другим (например, когда app. необходимо отправить запрос api.) это делается через localhost:XXXX вместо того, чтобы выходить через сеть AWS или сам интернет.

Эта настройка также максимизирует использование моих ресурсов, устраняя любой простоя инфраструктура, если слой приложения, на котором он размещается, получает легкий трафик. Это также устраняет необходимость иметь и ELB / ASG combo для каждого приложения, экономя больше денег.

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

есть также хорошее преимущество в том, что все экземпляры имеют роль IAM, что означает, что ваши AWS creds "запечены" к каждому экземпляру при рождении и доступны через ваш ENV vars. И AWS "автоматически" вращает ваши creds для вас. Очень безопасно, очень круто.

Проверяет Здоровье

если вы идете по маршруту вышеуказанной установки, плоской упаковки всех ваших приложений на одной коробке и работает внутренний балансировщик нагрузки, то вам нужно создать небольшую утилиту для обработки ELB проверки здоровья. Я создал дополнительное приложение под названием ping.myapp.com - ... И затем я настроил проверку работоспособности ELB для отправки любых проверок работоспособности в порт, на котором работает мое приложение ping, например:

Ping Protocol: HTTP
Ping Port:     XXXX
Ping Path:     /ping

это отправляет все проверки здоровья моему маленькому помощнику ping, который, в свою очередь, попадает localhost:XXXX/ping на всех приложениях, находящихся на экземпляре. Если все они возвращают ответ 200, мое приложение ping возвращает ответ 200 на проверку работоспособности ELB, и экземпляры живут еще 30 секунд.

Примечание: не используйте Автоматическое масштабирование проверки работоспособности при использовании ELB. Используйте проверки работоспособности ELB. Это немного сбивает с толку, я думал, что это одно и то же, но это не так. У вас есть возможность включить один или другой. Иди с ЭЛБ.

Уровень Данных

одна вещь, которая явно отсутствует в моей настройке, - это уровень данных. Я использую сочинять.Ио как мой поставщик управляемого уровня данных и я развертываю на AWS, поэтому я получаю очень низкую задержку между мои слои и слой данных. Я провел предварительное исследование о том, как я бы развернул свой слой данных по всему миру и обнаружил, что он очень сложный - и очень дорогой - поэтому я ударил его по моему списку как проблему, которую еще не нужно решать. В худшем случае я буду запускать свой уровень данных только в США-Восток и укреплять аппаратное обеспечение. Это не самое худшее в мире, так как мой API-это строго данные JSON на проводе, поэтому средний ответ относительно мал. Но я вижу это стать узким местом в очень большом, глобальном масштабе-если я когда-нибудь доберусь туда. Если у кого-то есть какой-либо вклад в этот слой, я хотел бы услышать, что вы должны сказать.

Та-Да!

Глобальная Высокая Доступность По Пивному Бюджету. Мне потребовалось всего 6 месяцев, чтобы понять это.

люблю слышать любой вклад или идеи от тех, кто случайно читает это.

вы можете использовать Anycast для своего веб-сервиса бесплатно, если используете Cloudflare free plan.

Digital Ocean теперь поддерживает балансировку нагрузки самих серверов. Это очень легко настроить и работает отлично! Избавляет вас от необходимости добавлять ненужные компоненты, такие как nginx (если вы хотите использовать только для балансировки нагрузки).

У нас были проблемы с использованием загрузки файлов SSL с nginx на цифровом океанском сервере, однако с момента обновления Digital Ocean мы удалили nginx и теперь используем функцию балансировки нагрузки Digital Ocean, и она работает так же, как нам нужно!