Рейтинг:1

Политика DNS для конечной точки VPC

флаг za

У меня есть VPC с тремя подсетями в разных зонах доступности, и конечная точка интерфейса VPC в каждой. Конечная точка VPC по умолчанию имеет 4 DNS-имени хоста:

  • Региональное DNS-имя хоста, например. vpce-x.ec2.us-восток-1.vpce.amazonaws.com.
  • Три зональных DNS-имени хоста для конкретных конечных точек, например. vpce-x-us-east-1a.ec2.us-east-1.vpce.amazonaws.com.

Насколько я понимаю, региональное DNS-имя хоста будет произвольной конечной точкой. Есть ли способ настроить одно DNS-имя хоста, которое всегда будет разрешаться в конечную точку в одной и той же подсети, чтобы уменьшить трафик между зонами доступности? Я не уверен, применима ли политика маршрутизации с задержкой для этого варианта использования или нет, или есть ли другое решение. Или региональное DNS-имя хоста уже будет делать что-то подобное?

Примером использования здесь является приложение, которое отправляет большой трафик во внешнюю службу через конечные точки экземпляра VPC — до такой степени, что передача данных требует значительных затрат. Избегание трафика между зонами доступности для конечной точки VPC уменьшит часть затрат на передачу данных.

Tim avatar
флаг gp
Tim
Чего вы пытаетесь достичь? Какая у вас проблема?
флаг za
Попытка снизить затраты на передачу данных между зонами доступности.
Tim avatar
флаг gp
Tim
Ваш вопрос чрезвычайно конкретен, без указания общей картины, он спрашивает о решении, которое, по вашему мнению, будет работать. Я предлагаю вам задать новый вопрос, в котором описывается ваша рабочая нагрузка, ваша архитектура, описывается ваша проблема (которая может включать в себя объем трафика между зонами доступности, который вы получаете) и запрашиваются предложения. Предлагаемое вами решение может быть тем, что придумали люди, но у людей могут быть и другие идеи. Например, в некоторых случаях решением может быть ALB с отключенной межзональной балансировкой нагрузки.
флаг za
Добавлены некоторые подробности о сценарии использования. Но я подозреваю, что текущий ответ - это путь сюда, поэтому не буду публиковать еще один вопрос. Использование ALB (или NLB) — интересная идея для этого, но затраты будут близки к затратам на передачу данных между зонами доступности.
Рейтинг:1
флаг cn

Если вы используете зональное DNS-имя, вы обращаетесь к этой зоне. От документы:

Выберите подсеть в вашем VPC для использования конечной точки интерфейса. Мы создаем сетевой интерфейс конечной точки в подсети. Сетевому интерфейсу конечной точки назначается частный IP-адрес из диапазона IP-адресов вашей подсети, и он сохраняет этот IP-адрес до тех пор, пока конечная точка интерфейса не будет удалена. Вы можете указать более одной подсети в разных зонах доступности (как поддерживается службой), чтобы убедиться, что конечная точка вашего интерфейса устойчива к сбоям в зоне доступности. В этом случае мы создаем сетевой интерфейс конечной точки в каждой указанной вами подсети.

Итак, если у вас есть экземпляр, работающий, например. us-east-1a, скажите ему использовать конечную точку east-1a, и все коммуникации будут в пределах зоны доступности. У вас должна быть возможность изменять DNS-имя, используя переменные среды в коде, сопоставления в CloudFormation или поиск в хранилище параметров. Имейте в виду, что это не будет устойчивым к неудаче.

Если вы не занимаетесь высокопроизводительными вычислениями, требующими чрезвычайно низкой задержки, или переносом огромных объемов данных между зонами, я бы просто использовал региональное имя (например, us-east-1).Я ожидаю, что он будет использовать что-то разумное.

Вы можете проверить, выполнив некоторые хост REGIONALDNS и проверяя, какой IP он вам возвращает, и сравнивая с зональным результатом.

флаг za
Через конечную точку проходит достаточно данных, поэтому затраты на трафик между зонами доступности становятся значительными. Использование зональных DNS-имен напрямую решило бы проблему, но усложнило бы службу (в настоящее время это одна и та же служба с одной и той же конфигурацией, развернутой в нескольких зонах доступности). Я надеялся, что есть простой способ сделать это с помощью Route53.
флаг cn
Вы можете попробовать настроить что-то в R53, чтобы использовать маршрутизацию с геоблизостью или задержкой, но это не гарантируется — я не уверен, что геоблизость будет работать так близко, а задержка потенциально варьируется в зависимости от нагрузки.
флаг za
Использование разных имен хостов для разных AZ, вероятно, является правильным путем. Это можно сделать устойчивым к сбоям, предпочитая конечную точку из той же зоны доступности и возвращаясь к другим (например, отдельные записи с политикой маршрутизации при отказе).
флаг za
Я вижу, что политики геоблизости и маршрутизации с задержкой недоступны для частных размещенных зон, поэтому похоже, что они не предназначены для этого варианта использования.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.