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

Цель: предлагать моим пользователям высокодоступные услуги путем маршрутизации всех подключений к ближайшему «кластеру» серверов в SFO, Нью-Йорке, LON и, в конечном итоге, в Сингапуре.

Затем уровень глобальной балансировки направляет запрос на наименее подключенный сервер ...

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

Я знаю три способа получить то, что вы ищете:

1. 30-кратное перенаправление
   Ваши глобальные балансировщики получают HTTP-запрос, а затем перенаправляют его на группу серверов в или рядом с регионом, из которого, по их мнению, исходит запрос, на основе IP-адреса. Похоже на то, что вы пытались настроить. Этот метод имеет побочные эффекты для некоторых приложений, а также увеличивает время, необходимое пользователю для получения данных, поскольку вы добавляете массу накладных расходов. Это имеет смысл только в том случае, если ресурсы, на которые вы перенаправляете, очень большие, а локальный региональный кластер сможет обслуживать гораздо более эффективно.

2. Anycast (использование маршрутизации BGP)
   Это то, что крупные игроки, такие как Akamai, используют для своих CDN. По сути, в Интернете есть несколько серверов с одним и тем же маршрутизируемым IP-адресом. Предположим, у меня есть серверы в нескольких регионах, и у них есть IP-адрес 192.0.2.1. Если я нахожусь в США и пытаюсь подключиться к 192.0.2.1, а кто-то в Европе пытается подключиться к 192.0.2.1, вероятно, мы будем перенаправлены на ближайший сервер. При этом используется собственная маршрутизация Интернета для поиска наилучшего пути (в зависимости от состояния сети) для трафика. К сожалению, просто использовать этот метод нельзя. Вам нужен собственный номер AS и физическое оборудование. Если вы найдете поставщика VPS, который позволяет вам получить часть своего блока Anycast, дайте мне знать!

3. Geo-DNS
   Некоторые поставщики DNS предоставляют услуги, которые часто продаются как Geo-DNS. У них есть множество DNS-серверов, размещенных на произвольных адресах, которые могут направлять трафик на ваши ближайшие серверы. Если клиент запрашивает европейский DNS-сервер, он должен вернуть адрес серверов вашего европейского региона, а не некоторых других регионов. Есть много вариантов сервисов Geo DNS. Другие просто поддерживают базу данных гео-IP и возвращают сервер для региона, который, по их мнению, ближе, точно так же, как метод перенаправления, но для DNS до того, как будет сделан HTTP-запрос. Обычно это хороший вариант по цене и простоте использования.

Перенаправляются ли последующие запросы на тот же IP-адрес?

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

А как насчет сеансов?

Именно поэтому вам нужна такая липкость. Когда дело доходит до данных сеанса, вам нужно будет найти способ поддерживать все ваши серверы в актуальном состоянии. На самом деле это не всегда гарантировано. Как вы с этим справитесь, зависит от вашего приложения. Можете ли вы сохранить экземпляр Redis или что-то еще, чтобы все ваши серверы надежно поражались со всего мира? Вам действительно нужны данные сеанса в каждом регионе? Или у вас могут быть основные серверы приложений, работающие с данными сеанса, в одном месте?

Любые примеры DNS?

Задайте для них отдельные вопросы. У всех успешная установка выглядит по-разному.

А как насчет SSL / TLS?

Если вы проксируете данные, только ваши глобальные балансировщики должны обрабатывать HTTPS. Если вы перенаправляете, то все серверы должны его обработать.

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

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

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

Обзор

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

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

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

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

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

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

Сеть доставки контента

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

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

В настоящее время я использую AWS Elastic Load Balancer для балансировки нагрузки между экземплярами моих приложений, которые находятся в Auto-Scaling Group. Запрос сначала принимается ELB, после чего SSL прерывается, и запрос передается экземпляру в группе Auto-Scaling.

ПРИМЕЧАНИЕ. Одно важное предостережение для ELB заключается в том, что, по иронии судьбы, он не очень хорошо справляется с массивными всплесками. ELB может занять до 15 минут, чтобы инициировать событие масштабирования для себя, создавая тем временем 500 таймаутов. Предполагается, что устойчивый, постоянный рост трафика обрабатывается достаточно хорошо, но если вы столкнетесь с резким скачком, он может вас подвести. Если вы знаете, что вас ударит, вы можете «позвонить заранее», и AWS разогреет ваш ELB для вас, что довольно нелепо и противоречит сути AWS, но я полагаю, что они либо работают над или игнорирование этого, потому что это не такая уж большая проблема. Вы всегда можете запустить свой собственный HAProxy или Nginx load- балансирующий слой, если ELB у вас не работает.

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

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

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

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

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

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

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

Также есть приятное преимущество в том, что все экземпляры имеют роль IAM, что означает, что ваши кредиты AWS" запекаются "для каждого экземпляра при рождении и доступны через ваши переменные ENV. А AWS «автоматически» меняет ваши кредиты за вас. Очень безопасно, очень круто.

Проверки работоспособности

Если вы пойдете по пути вышеописанной настройки, упакуйте все свои приложения в одну коробку и запустите внутренний балансировщик нагрузки, тогда вам нужно создать небольшую утилиту для обработки Проверки работоспособности 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. Это немного сбивает с толку, я думал, что это одно и то же, но это не так. У вас есть возможность включить одно или другое. Выбирайте ELB.

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

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

Та-Да!

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

Мне нравится слышать любые предложения или идеи от любого, кто это читает.

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

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

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