У меня есть несколько VPC, настроенных в AWS, и все мои экземпляры используют подготовленные IP-адреса, то есть - не с помощью Elastic IP Addresses.
Когда любой данный экземпляр загружается, он выполняет сценарий на компьютере (после подключения к сети), который получает идентификатор экземпляра, идентификатор зоны (из локальной конфигурации), регион и т. Д. - как только он получает эту информацию, он обновляется. Route 53 для обновления информации DNS в частной размещенной зоне для этих экземпляров.
Причина этого в основном в том, что я могу использовать DNS для строк подключения к серверу. У меня есть свой веб-сервер и серверы БД в частной подсети, и когда веб-сервер подключается к БД, он просто использует staticdns.mydomain.private который соответствует частному IP-адресу экземпляра. Таким образом, не требуется реконфигурация при перезагрузке экземпляра или при изменении IP-адреса по другим причинам.
Это все хорошо, и это работает - с одной оговоркой. Есть задержка в разрешении новых сопоставлений DNS, я не уверен, сколько она длится - она не ОЧЕНЬ долго, но кажется несколько случайной (возможно, TTL?). На тот период, когда у резольвера есть Старый IP-адрес кэшируется, мы получим сбои подключения от веб-сервера к базе данных. Я бы предпочел, чтобы этот кеш был выпущен, когда он был обновлен, но я понятия не имею, где его даже искать.
Кто-нибудь знает, есть ли способ обновить кеш преобразователя DNS в частных зонах в Route 53? Я пробовал использовать nscd также на сервере, что, похоже, не помогло.
Пара вариантов и примечаний ...
Если серверы находятся в одном VPC или в одноранговых VPC, используйте для связи свои частные IP-адреса, а не общедоступные. Частные IP-адреса остаются неизменными при остановке / перезапуске экземпляра.
Старые записи кэшируются на хостах, а не на Route 53. Вам придется сбросить nscd кэшировать все остальные хосты после изменения одного IP-адреса, это довольно большая автоматизация. Помимо того, что некоторые приложения и фреймворки также кешируют записи вне nscd, довольно сложно очистить все, когда это необходимо.
Вы можете снизить TTL своих DNS-записей до 60 (= 1 минута), это означает, что разрешенные записи не будут кэшироваться более минуты. Это тот же подход, который AWS RDS использует для механизма аварийного переключения.
Использовать Балансировщик сетевой нагрузки (NLB) - он обеспечит стабильный IP-адрес вашего сервера, даже если фактический IP-адрес сервера изменится. Однако это уже перебор.
Использовать Эластичные IP-адреса. Это тоже решило бы вашу проблему. При подключении к работающему экземпляру они ничего не стоят.
Используйте AWS RDS, возможно Бессерверная Аврора это почти ничего не стоит, когда не используется. Все управление, аварийное переключение и т. Д. Будет сделано за вас.