Як 8.8.8.8 утримується * завжди * в живих?

Я знаю, як можна керувати надмірністю центрів обробки даних, якщо там працює DNS-сервер, який може вказувати на будь-який робочий сайт вашої компанії - є VRRP, мульти WAN і т.д. тощо. Але як DNS-сервери підтримуються в Інтернеті? Це перший удар, коли хтось підключається до сервісу, і його реально не можна передбачити. Я маю на увазі, наприклад, 8.8.8.8або 8.8.4.4. Я не можу пригадати, щоб вони були вниз. Колись. Як провайдерам вдається підтримувати такі IP-адреси завжди в Інтернеті?

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

Перш за все, VRRP жодним чином не залежить від DNS. Для надмірності на одному веб-сайті ви можете запустити DNS-сервери за спільною VRRP-адресою.

Але, як згадували інші у коментарях, сервіси також використовують маршрутизацію anycast , що по суті означає, що однакова 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 │
                  └──────────────────────────┘

(З цього приводу навіть не потрібно бути однаковим АС - наприклад, реле 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]