Вопрос или проблема
У меня настроено несколько VPC в AWS, и все мои экземпляры используют выделенные IP-адреса, то есть – не используют Эластичные IP-адреса.
Когда любой экземпляр загружается, он выполняет скрипт на машине (после настройки сети), который получает ID экземпляра, ID зоны (из локальной конфигурации) и регион и т. д. – как только у него есть эта информация, он обновляет 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. Это также решит вашу проблему. Обратите внимание, что эластичные IP стоят больше, чем неэластичные публичные IP.
-
Используйте AWS RDS, возможно, Безсерверный Aurora, который почти не стоит, когда не используется. Все управление, переключение на резервный канал и т. д. будет сделано за вас.
Ответ или решение
Вопрос о том, возможно ли принудительно обновить кэш DNS-резолвера Route 53 в AWS при изменении IP-адреса, является актуальным для многих пользователей, работающих с виртуальными частными облаками (VPC) и осуществляющих мониторинг соединений на основе DNS. Давайте подробно разберем этот вопрос и рассмотрим возможные решения.
Проблема кэширования DNS
Как вы правильно отметили, когда экземпляр EC2 перезагружается и его частный IP-адрес изменяется, DNS-запись в Route 53 обновляется, однако другой экземпляр, который использует это имя, может по-прежнему кэшировать старую запись. Это связано с тем, что кэширование происходит на уровне приложений и операционной системы, а не в самом Route 53. Каждое соединение, устанавливаемое с использованием DNS-имени, может возвращать старый IP-адрес, пока не истечет время кэширования, которое определяется значением TTL (Time-To-Live).
Решения проблемы кэширования
-
Сокращение TTL: Наиболее простое и эффективное решение — уменьшить значение TTL для ваших записей DNS в Route 53. Установка TTL на значение 60 секунд позволит уменьшить период, в течение которого старый IP-адрес будет кэшироваться. После обновления записи DNS, большинство резолверов будут проверять обновленную запись через минуту.
-
Использование частных IP-адресов: Если ваши серверы находятся в одной VPC или в пирах VPC, рекомендуется использовать частные IP-адреса для внутренней связи. Частные IP-адреса не меняются при перезагрузке экземпляра, что убережет вас от необходимости в изменении DNS-записей.
-
Очистка кэша на каждом экземпляре: Как вы уже пробовали использовать
nscd, стоит помнить, что это не единственное решение. Действительно, если ваши приложения используют свои внутренние механизмы кэширования, вам может понадобиться очистить кэш в каждом из экземпляров вручную. Это может потребовать дополнительной автоматизации, чтобы обеспечить обновление кэша сразу после изменения IP-адреса. -
Использование Elastic IP: Если ваш проект позволяет использовать Elastic IP-адреса, то это также может быть хорошим решением. Elastic IP-адреса не изменяются при перезапуске экземпляра и обеспечивают постоянное разрешение DNS, независимо от состояния экземпляра.
-
Сетевой балансировщик нагрузки (NLB): Если у вас высокая нагрузка на ваши приложения, стоит рассмотреть возможность использования сетевого балансировщика нагрузки. NLB может предоставить стабильный IP-адрес для вашего сервера, обеспечивая легкость масштабирования и управляемость при изменении экземпляров.
-
Использование AWS RDS: В качестве альтернативного решения, AWS RDS предоставляет возможности для работы с базами данных с управлением кэшированием и обновлением IP-адресов. Это может значительно упростить вашу инфраструктуру и снизить дополнительные риски, связанные с изменением IP-адресов.
Заключение
Таким образом, ваш вопрос о принудительном обновлении кэша DNS Resolver в AWS вполне решаем. Варианты, которые включают сокращение TTL, использование частных IP-адресов, автоматизацию очистки кэша и использование ресурсов AWS, могут значительно снизить риски, связанные с изменением IP-адресов. Понимание механизмов кэширования DNS поможет вам оптимизировать работу вашей системы и улучшить стабильность соединений между серверами.