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