Как 8.8.8.8 остается * всегда * живым?

Я знаю, как вы можете управлять избыточностью центра обработки данных, если есть работающий DNS-сервер, который может указывать на любой работающий сайт вашей компании - есть VRRP, мульти-WAN и т. Д. И т. Д. Но как сами DNS-серверы поддерживаются в сети? Это первый удар, когда кто-то подключается к сервису, и он не может быть подготовлен. Я имею в виду, например, 8.8.8.8или 8.8.4.4. Я не могу вспомнить, чтобы они были внизу. Когда-либо. Как интернет - провайдеры удается держать такие IP - адреса всегда в Интернете?

Я знаю, что это, вероятно, очень широкий вопрос, но я хотел бы услышать только названия протоколов / методов, которые могут быть использованы для этого. Я могу прочитать подробности о них самостоятельно.

Во-первых, VRRP никак не зависит от DNS. Для обеспечения избыточности на одном сайте вы можете просто запускать DNS-серверы на общем VRRP-адресе.

Но, как другие упоминали в комментариях, сервисы также используют произвольную маршрутизацию , что по сути означает, что один и тот же IP-адрес существует во многих местах по всему миру. Когда весь сайт выходит из строя, маршруты по всему миру пересчитываются так, что ваши пакеты попадают на другой рабочий сайт.

Лучший пример , чем общественное DNS Google, будет в корневой DNS - серверы - те , которые служат .зоны и удержания указатели com, org, euи так далее - потому что они имеют карту каждого экземпляра 13 логических адресов. «L» ICANN обслуживается 160 различными сайтами!

Обратите внимание, что anycast не имеет никакого отношения к циклическим переборам на основе DNS (где одно и то же имя имеет несколько адресов). Anycast сделан по существу, обманывая протокол маршрутизации.

Интернет использует BGP для обмена информацией о маршрутизации между организациями.

BGP по своей природе поддерживает выбор наилучшего из нескольких маршрутов в одну и ту же сеть на основе различных критериев. Например, один и тот же клиент может иметь избыточные восходящие ссылки на одного и того же интернет-провайдера (объявляя о двух маршрутах, отличающихся только весом / предпочтением). Или у клиента могут быть восходящие каналы через нескольких интернет-провайдеров, и каждый выберет свой предпочтительный маршрут (в основном кратчайший AS-путь) - в этом суть «истинного» мульти-WAN.

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

Однако BGP только направляет трафик к вашим входным дверям, но не заботится о том, что будет дальше. Таким образом, если вы внутренне настроили оба маршрута к одному и тому же серверу, вы получите множественную адресацию. Но если каждый «вход» ведет на другой сервер (настроенный на один и тот же IP), вы получаете anycast.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Важно, что это также означает, что BGP не волнует, если AS вообще не является смежным. Чтобы обеспечить всемирную избыточность, просто объявите одну и ту же сеть из нескольких физических местоположений - если вы соедините эти местоположения вместе (чтобы они направили эту сеть в одно место), вы получите множественную адресацию; если они острова, вы получите anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(В этом отношении, это даже не должно быть той же самой AS - например, реле 6to4 управляются несколькими независимыми организациями, каждая из которых объявляет свой собственный путь к 192.88.99.0/24.)

Предостережения:

• Anycast обеспечивает избыточность, но не балансировку нагрузки. Как только BGP сходится, каждый маршрутизатор выберет один предпочтительный маршрут (или иногда несколько) и будет продолжать использовать его, пока не изменится сеть.

• Тем не менее, вы не можете предсказать, как долго будут оставаться стабильными маршруты, поэтому любые службы с отслеживанием состояния могут быть сложными. DNS сходит с рук из-за отсутствия состояния и использования в основном UDP (EDNS уменьшил потребность в TCP-соединениях).

• Должна быть координация между реальной службой и маршрутизатором BGP, чтобы маршрут был отменен в случае сбоя службы.

Смотрите также "История 4.2.2.2. Что за история?" в списке рассылки NANOG: пост 1 , пост 2 .

Одним из способов достижения этого является использование серверных балансировщиков . Когда вы подключаетесь к шлюзу по IP 8.8.8.8, он распределяет запрос на один бесплатный сервер внутри системы. В результате, когда один сервер умирает, он не разрушает всю систему.

Для интернет-служб балансировщик нагрузки на стороне сервера обычно представляет собой программное обеспечение, которое прослушивает порт, к которому внешние клиенты подключаются к службам доступа. Балансировщик нагрузки перенаправляет запросы на один из «внутренних» серверов, который обычно отвечает на балансировщик нагрузки. Это позволяет балансировщику нагрузки отвечать клиенту, даже если клиент никогда не узнает о внутреннем разделении функций. Он также не позволяет клиентам напрямую связываться с внутренними серверами, что может иметь преимущества для безопасности, скрывая структуру внутренней сети и предотвращая атаки на сетевой стек ядра или несвязанные службы, работающие на других портах.

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

Также важно, чтобы сам балансировщик нагрузки не становился единой точкой отказа. Обычно балансировщики нагрузки реализуются в парах высокой доступности, которые могут также реплицировать данные о продолжительности сеанса, если этого требует конкретное приложение. [5]