Назад | Перейти на главную страницу

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

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

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

Что еще более важно, наши пользователи в других регионах (то есть на континентах) видят медленное обслуживание. Мы в значительной степени знаем, как улучшить это с помощью локальных серверов: добавив к существующему fra-service.example.com (Франкфурт) и ioa-service.example.com (Айова). Два экземпляра haproxy (один в FRA, один в IOA) и ключевые дополнительные сервисы, каждый из которых требует малой задержки.

Что мне менее понятно, так это то, как обслуживать пользователей.

Пользователь A отправляет HTTPS-запрос на сайт www.example.com. DNS предлагает посмотреть на 1.2.3.4 (все IP-адреса в этом вопросе явно поддельные). Это уже первая проблема. У нас есть 1.2.3.4 (в FRA) и 1.2.3.5 (IOA). Как DNS узнает, на какой из них указать пользователя? Обратите внимание, что RR-DNS, часто предлагаемый в этом контексте, неуместен: он не принимает во внимание нагрузку, доступность или близость и может дополнительно страдать от слепоты кэширования. Виртуальный IP адреса мощь работают, но если они это сделают, кажется, требуется, чтобы мы использовали протоколы внутреннего шлюза, такие как OSPF. Я не думаю, что это что-то разумное для нас, и я не уверен, что наш провайдер все равно позволит это, но я могу быть совершенно неправ. Я не совсем понимаю VIP-персон. Плавающие IP-адреса может использоваться для аварийного переключения, но также может дать сбой, поскольку не учитывает близость или нагрузку.

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

Я немного читал о GeoDNS, что звучит многообещающе. (Anycast, с другой стороны, требует, чтобы DNS-сервер был совмещен с нашим haproxy. И может потребоваться поддержка интернет-провайдера.)

Казалось бы, любое решение чрезвычайно сложной проблемы выдачи сертификатов SSL.

Может ли кто-нибудь указать мне в правильном направлении, как к этому подойти?