Инженеры онлайн-сервиса Cloudflare относительно популярно объясняют, что именно технически произошло с недоступностью Facebook минувшим вечером, 4-го октября 2021 года. «Разве Facebook может упасть?», ахахахаха!

Сегодня в 16:51 UTC (в 19:51 MSK) у нас был открыт внутренний инцидент под названием «Facebook DNS lookup returning SERVFAIL» («DNS-поиск для Facebook возвращает SERVFAIL»). Мы решили, что это с нашим DNS-ресолвером 1.1.1.1 что-то не так. Однако к моменту размещения соответствующего обновления на публичной статус-странице стало ясно, что здесь что-то серьёзное.

Социальные сети уже разрывались от сообщений о том, что быстро подтвердили и наши инженеры: Facebook и связанные с ним сервисы WhatsApp и Instagram действительно упали. Их DNS-имена больше не ресолвились, а IP-адреса инфраструктуры были недоступны. Выглядело так, как будто кто-то буквально выдернул кабели разом во всех их дата-центрах, отключив от интернета.

Как такое вообще возможно?

BGP — это «протокол граничного шлюза» (Border Gateway Protocol). Это механизм для обмена информацией о маршрутизации между автономными системами (AS) в интернете. У больших роутеров, благодаря которым работает интернет, есть постоянно обновляемые списки возможных маршрутов, используемых для доставки каждого сетевого пакета до мест их назначения. Без BGP интернет-роутеры не знают, что делать, и интернет просто не будет работать.

BGP позволяет одной сети (скажем, Facebook) объявлять о своём присутствии другим сетям, которые в конечном счёте формируют весь интернет. В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов. Это означало, что по меньшей мере DNS-серверы Facebook были недоступны. По этой причине DNS-ресолвер Cloudflare (уже упомянутый 1.1.1.1) не мог отвечать на запросы, требующие выдать IP-адрес для домена facebook.com или instagram.com.

UPDATE-сообщение от BGP информирует роутер о любых изменениях, сделанных в префиксе, или о полном отзыве этого префикса. Проверяя базу данных BGP, основанную на временных рядах, мы можем точно увидеть количество обновлений, поступивших от Facebook’а. Обычно этот график довольно ровный: Facebook не будет постоянно делать большое количество изменений для своей сети. Но около 15:40 UTC был замечен резкий всплеск изменений в маршрутах Facebook’а. Именно здесь и начались проблемы. Маршруты были отозваны, DNS-серверы Facebook ушли в offline. После отзыва этих маршрутов Facebook и его сайты были отключены от интернета.

Прямым последствием этого события стала невозможность для DNS-ресолверов со всего мира получать IP для связанных с проектами доменных имён.

Это происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации. Когда кто-то набирает facebook.com в веб-браузере, DNS-ресолвер, ответственный за перевод доменного имени в реальный IP-адрес для фактического подключения, сначала проверяет, есть ли что-то в его кэше. Если кэш есть — используется IP-адрес оттуда. Если кэша нет — производится попытка получить ответ от DNS-сервера, обычно расположенного где-то поблизости.

Если DNS-серверы недоступны или не могут дать ответ по какой-то другой причине, возвращается ответ SERVFAIL, а браузер показывает пользователю ошибку.

Из-за того, что Facebook перестал анонсировать свои DNS prefix routes через BGP, наш и любой другой DNS-ресолвер не мог подключиться к DNS-серверам проекта. Поэтому, 1.1.1.1, 8.8.8.8 и другие крупные публичные DNS-ресолверы начали выдавать (и кэшировать) ответы SERVFAIL.

Но это ещё не всё. Теперь в дело включается человеческий фактор и логика работы приложения, что в совокупности приводит к экспоненциальному эффекту. От пользователей обрушивается огромная волна дополнительного DNS-трафика.

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

Всё это привело к резкому росту трафика (по количеству запросов), что мы и наблюдали. От трафика упало всё остальное, потому что 30-кратную перегрузку на DNS-ресолверы по всему миру могут выдержать не только лишь все. Фактически выдержали это только в России.

Когда Facebook упал, мы увидели растущее число DNS-запросов к Twitter, Signal и другим социальным сетям и платформам для обмена сообщениями. У них тоже появились локальные перегрузки и проблемы.

Сегодняшние события служат мягким напоминанием о том, что интернет — это очень сложная и взаимозависимая система из миллионов систем и протоколов, взаимодействующих друг с другом. Доверие, стандартизация и кооперация между задействованными в нём организациями — ключ к его работоспособности для почти пяти миллиардов активных пользователей со всего мира.

PS. В 1968 году Министерство обороны США посчитало, что на случай войны Америке нужна надёжная система передачи информации, и предложило разработать для этого компьютерную сеть. Это и был Internet. А потом что-то пошло не так.

И я даже вам расскажу, что именно пошло не так. Просто все стали переходить от децентрализованной модели изначальной сети к централизованной, где есть выделенные точки управления всей сетью. Руками ходить на каждое отдельное устройство всем надоело, решили разливать изменения всякими модными зумерскими ansible’ами, ETSI NFV MANO, использовать REST API, NET CONF и прочие централизованные вещи. И вот одно неосторожное движение — и вместо единичного отказа лежит уже вся инфраструктура сети.

В стародавние времена, когда миллениалы ещё не пребывали в эйфории от удалёнки, а зумеры только начали появляться на свет, у бородатых сисадминов уже в ходу была такая примета: «Удалённая настройка сети — это к дальней дороге».

Источник материала

• • 40
  • 1
  • 2
  • 3
  • 4
  • 5