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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфигурация для группы автомасштабирования на мой взгляд немного запутана. Это действительно трехэтапный процесс:

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

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

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

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

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

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

Также хорошо, что все экземпляры имеют роль IAM, что означает, что ваши AWS-кредиты "испечены" в каждом экземпляре после рождения и доступны через ваш ENV vars. И 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, поэтому получаю очень низкую задержку между слоями приложений и уровнем данных. Я провел предварительное исследование того, как я буду откатывать свой слой данных во всем мире, и обнаружил, что он очень сложный и очень дорогой, поэтому я выпустил его в список как проблему, которая еще не нуждается в решении. Хуже всего то, что я буду использовать свой уровень данных только на US-East и усилить аппаратное обеспечение. Это не самая худшая вещь в мире, так как мой API - это строго данные JSON на проводе, поэтому средний ответ относительно крошечный. Но я вижу, что это становится узким местом в очень больших масштабах - если я когда-либо доберусь туда. Если у кого-то есть какие-либо материалы на этом слое, я бы хотел услышать, что вы скажете.

Ta-Da!

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

Любовь, чтобы услышать какие-либо материалы или идеи от любого, кто это читает.

Ответ 3

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

Ответ 4

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

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