Использование Amazon Load Balancers для маршрутизации трафика на частные серверы за пределами Amazon
Я планирую использовать Amazon Elastic Load Balancing (ELB), чтобы сократить время простоя при сбое сервера. По сути, я не хочу менять соответствующие записи DNS и ждать распространения DNS по всему миру, я просто хочу перенаправить трафик на другую машину, обслуживающую мое приложение.
Однако почти все мои серверы не являются экземплярами EC2, это VPS или выделенные серверы с компанией, которая не имеет ничего общего с Amazon.
Можно ли использовать некоторую комбинацию сервисов Amazon (в частности, ELB), которая позволила бы мне указывать доменное имя на эластичном балансировщике нагрузки и переадресовывать его запросы на 1-2 сервера вне сети Amazon?
Если IP-адрес балансировщика изменится, это, очевидно, не сработает (тогда на него нельзя будет указать имя корневого домена). Однако не могли бы вы назначить балансировщику эластичный IP-адрес, а затем указать ему свое доменное имя + настроить его для пересылки запросов не-Amazon-PrivateServer1 и Non-Amazon-PrivateServer2?
3 ответа
ELB будет отправлять трафик только на экземпляры EC2.
У вас может быть пара экземпляров nginx EC2 за проксированием трафика ELB на ваши реальные серверы, или вы можете просто пойти по простому маршруту и отбросить свой TTL DNS примерно до 10 минут, чтобы изменения отражались быстрее.
По состоянию на 31 августа 2017 г. балансировщики нагрузки приложений поддерживают IP-адреса в качестве целей в дополнение к идентификаторам экземпляров:
Мы рады сообщить, что теперь балансировщики нагрузки приложений могут распределять трафик по ресурсам AWS, используя свои IP-адреса в качестве целей в дополнение к идентификаторам экземпляров. Вы также можете балансировать нагрузку на ресурсы вне VPC, на котором размещен балансировщик нагрузки, используя их IP-адреса в качестве целей. Это включает ресурсы в одноранговых VPC, EC2-Classic и локальных расположениях, доступных через AWS Direct Connect или VPN-соединение. Балансировка нагрузки между AWS и локальными ресурсами с использованием одного и того же балансировщика нагрузки упрощает миграцию в облако, пакетную передачу в облако или аварийное переключение в облачное хранилище.
Почему бы не использовать Route53 с проверками работоспособности для этого?
Сначала вы создаете проверку работоспособности на основе IP для каждого из ваших серверов. Эти проверки могут быть простыми и просто отслеживать состояние HTTP 200 для определенного запроса; или вы можете создать более сложные проверки, которые ищут конкретную строку в результате запроса.
Затем, если это еще не сделано, вы создаете размещенную зону для домена, который вы используете в Route53; и предоставить регистратору вашего домена назначенные Route53 DNS-серверы.
Как только это будет сделано, для каждого сервера, для которого вы хотите сбалансировать запросы, создайте набор записей (в только что созданной размещенной зоне), используя, например, тип "Взвешенный", короткий TTL (60 или ниже) и выберите "Связать с проверкой работоспособности".: ДА 'и выберите созданную выше проверку работоспособности, соответствующую конкретному серверу /IP-адресу, для которого вы создаете запись. Снова, повторите это для каждого сервера /IP.
В итоге у вас будет несколько наборов записей, каждый с 1 IP, и все они связаны с одним и тем же доменом в Route53. После DNS-запросов Route53 теперь будет возвращать один из них в зависимости от назначенного им веса И в зависимости от текущего состояния каждой проверки работоспособности. Если какая-либо проверка работоспособности не проходит, этот конкретный IP-адрес не указывается
Вы также можете сделать это, используя другие типы наборов записей Route53; например, при "отказоустойчивости" у вас есть 1 или несколько первичных IP-адресов и 1 или несколько вторичных IP-адресов. Route53 всегда будет возвращать один из первичных IP-адресов, если проверки работоспособности для них не пройдены, затем он переключается на один из вторичных.
И в Route53 есть более сложные типы записей, которые также можно комбинировать с проверками работоспособности: задержка, геолокация, многозначность. Все очень хорошо объяснено в документах AWS.