Здравствуйте товарищи!
Каждый владелец успешного интернет-ресурса, который создан с целью получения материальной или не материальной прибыли, сталкивается с ситуацией когда его сервис недоступен из-за лавинного неконролируемого трафика. Трафик этот может быть вызван как легитимными причинами, например всем известный «хабр-эффект», или зровредной деятельностью недоброжелателей. Результат один — недоступность ресурса в течении неопределенного времени и, что самое главное, отсутствие эффективных инструментов быстрого изменения ситуации в случае если инфраструктура ресурса заранее не была подготовлена. Я попробую поразмышлять, возможно ли организовать 100% доступность любого интернет ресурса. Заранее скажу что точный ответ на этот вопрос даст только реальные испытания. Я же опробовал механизмы у себя на балконе с совокупной нагрузкой на ресурс в 100 гигабит. Предприятие это вышло дюже не дешевое, но чрезвычайно интересное.
Прототип сети Internet заработал в 1972 году в США. В 1989 в стенах Европейского совета по ядерным исследованиям была разработана современная парадигма всемирной сети World Wide Web. А в 1995 году утвердили стандарт, по которому сеть управляется не единым супер компьютером, а распределенными серверами, взаимодействующими между собой по определенному протоколу. Таким образом, откуда бы пользователь, вошедший в сеть, не запрашивал нужный ему ресурс, система давала статический маршрут, дорожную карту, по которой его сигнал должен достичь запрашиваемого ресурса.
Несмотря на то, что сеть за эти годы увеличилась так же, как увеличилось бы яблоко до размеров планеты – принципиальная архитектура сети Internet нисколько не изменилась. И, естественно, самой большой проблемой стала проблема эффективного планирования трафика. Если говорить конкретнее, в настоящий момент конечный ресурс, к которому идет обращение, не способен управлять количеством и качеством трафика который на него поступает. Таким образом, не важно какая защита на стороне самого ресурса и сколько она стоит – самое слабое его место (совокупная ширина каналов доступа в Internet) находится вне его компетенции. Не важно, какая пропускная система будет стоять на проходной завода, она не сможет пропустить больше, чем могут пропустить двери. Именно по этой причине, в декабре 2012 года, значимые государственные интернет ресурсы, несмотря на самые мощные в мире системы защиты, были недоступны в течение нескольких часов. Система безопасности не справились с атакой группы злоумышленников, молодых людей из города Красноярска, организовавших огромный трафик.
Стандартными средствами задача не может быть решена – сама архитектура сети Интернет не позволяет это сделать. Поэтому я решили взглянуть на нее немного по другому. Для лучшего понимания возьмем за пример дорожное движение. Задача эффективного прохождения трафика в компьютерных сетях мало чем отличается от трафика на автодорогах: переместить от точки «А» к точке «Б» и обратно по спланированному маршруту.
Всем известна проблема пробок. Чем больше автомобилей, тем сильнее они мешают друг другу на автодорогах. Задача планирования трафика сводится к регулированию количества транспорта в единицу времени на конкретном участке автодороги. При этом пропускная способность каждого участка автодороги от пункта «А» к пункту «В» равна самому узкому месту. Конечно, сам водитель не способен эффективно спланировать свой маршрут, потому что не обладает полной информацией по маршруту следования. Но все мы знаем, что если водитель получает навигатор, который показывает маршрут с учетом пробок – ситуация начинает радикально меняться. Если бы каждое транспортное средство было оборудовано единой навигационной системой, учитывающей нагрузку на автодороги, «пробки» можно было бы уменьшить на порядок или избежать совсем. Решение о маршруте автотранспорта принималось бы не водителем, который не имеет никакой информации о следовании по маршруту, а централизованной системой которая «знает» нагрузку на любой участок автодороги в любой момент времени и направляет водителя по минимально нагруженному маршруту.
Возможно ли сделать такую центральную навигационную систему в Интернете? Технологию которая выполняет функции такой централизованной системы, с тем отличием что «водителю» указывается конечный адрес не искомой точки «Б» а промежуточного шлюза. Хорошо демонстрирует пример работы шлюза московская кольцевая автодорога(МКАД). Без нее, внешний поток машин напрямую бы направлялся внутрь Москвы. Это неминуемо бы парализовало движение внутри города и остановило входящий и исходящий поток. Кольцевая дорога балансирует этот трафик, перенаправляя его на разные въезды и выезды. Но если в случае реального мира мы ограничены пропускной способностью самой кольцевой автодороги и количеством всех примыкающих магистралей, то в виртуальном мире емкость «МКАД» и количество примыкающих магистралей можно динамически увеличивать или уменьшать почти в реальном времени. Как только на каком-то участке пропускной способности не хватает, система строит параллельную дорогу и организует все развязки, не создавая заторов.
Таким образом, шлюз строит динамическую карту маршрутов до искомого объекта «Б» и выбирает наилучший. Если новому, построенному каналу до точки «Б» грозит переполнение – система всего лишь перестает его использовать, и новый трафик направляется по свободным каналам, или создает новые.
Работая по такой технологии, любой ресурс в сети Internet, будь то сайт, платежная система или целая сеть оператора связи, напрямую не доступен публичной сети(в город нельзя въехать или выехать минуя «МКАД»). Какой бы ни был трафик, направленный на ресурс, легитимный или зловредный, он попадает сначала на «МКАД» — пусть это будет облако шлюзов. Там он «гасится», что и гарантируют 100% доступность искомого ресурса в любой ситуации в любой момент времени. Гасится трафик либо отсечением зловредного трафика, что даст возможность проходить до искомого ресурса только легитимному трафику. Либо кешированием для легитимного трафика(естественно не весь трафик можно и нужно кешировать), что также на порядки снижает нагрузку на искомый ресурс «Б» обеспечивая его доступность.
Есть решения, которые действуют по принципу подключения интернет ресурса к одному или нескольким каналам большой емкости. Но при достижении лимита в этих каналах страдают все ресурсы, которые к нему подключены. Именно это сейчас и происходит с транспортной системой Москвы – нет возможности динамически расширять дороги и их количество. Сам канал имеет предельную пропускную способность. Что не решает задачу гарантированной доступности ресурса, а только лишь усложняет для злоумышленников организацию атак.
Для специалиста, конечно это все «вода». Очевидные вещи. Вопрос как же решить задачу доступности.
Вопрос этот многослойный и решение не может быть монолитным. На каждом уровне модели OSI нужно применять свой прием. Назвать это каким-то ноухау сложно, ведь принципиально нового в каждом «слое» — ничего предложено не будет. DNS-балансинг и распараллеливание на 4 и 7 уровне модели OSI. Тем не менее, я на протяжении года повышал свой уровень медихлорианов в крови и тепловыделения на балконе, чтобы получить приемлемый результат. Может быть это потому что их уровень в крови был мал и на балконе было очень холодно? Возможно и так. Иркутск холодный город.
Давайте формализуем задачу которую решаем: Гарантировать максимально возможную доступность ресурса при любом входящем трафике.
Очевидно, что для достижение задачи необходимо получить максимальный контроль над трафиком до того момента как он «пришел» на ресурс. Это возможно? Пол Мокапетрис, изобретатель DNS дал нам ответ еще 40 лет назад – конечно возможно. Первое что происходит при обращении к ресурсу это преобразование его цифро-буквенное обозначение в IP адрес. И все современные DNS серверы имеют встроенные алгоритмы балансинга. Когда на одно имя назначено много IP адресов. DNS-сервер отдает их либо по очереди, либо по «весу» либо по комбинированным алгоритмам. «Все это — известные любому школьнику факты» — скажете вы. А давайте копнем глубже.
Итак, дано: ресурс(для упрощения пусть это будет WEB сервер на базе nginx который является проксирующим фронтэндом для апликейшн серверов) который подключен к 10 каналам по 100 мегабит каждый. Каждый канал подключен к отдельному серверу. По каким-то причинам, каналы 2,5,7 вышли из строя. Не важно сервера упали или перегруз в 100 мегабитной сети. Эти ветки стали недоступны.
Найти: метод быстрого переключения пользователей который позволит «ходить» только по рабочим каналам.
Все мы знаем, что TTL зоны по умолчанию достаточно велик. Если мы просто поменяем конфигурацию зоны и выкинем «упавшие» адреса – изменения могут дойти до пользователей только через сутки. Таким образом мы подошли к первому выводу:
Стандартный балансинг DNS сервера работает только при доступности всех адресов на которые ссылается ресурс. И не может являться инструментом доступности сервиса. Задача этого инструмента – распараллелить нагрузку. Не более.
Как решить проблему? Опытный читатель незадумываясь ответит:
— Бро, нужно сократить время жизни зоны. Чтобы поменьше времени сидел в кешах промежуточных серверах.
И будет полностью прав. Да, мы ведь можем сократить время жизни зоны(и всех доменов в нем) аж до 1 секунды. Но что мы получим взамен? Мы получим дикую нагрузку на DNS сервер который «держит» dns-зону. Нагрузка, которая вырастит в сотни и тысячи раз. И никакой канал и количество ядер тут не помогут. Строили систему гарантированной доступности а получили провал на первом же этапе. Как выйти из ситуации. Я не знаю, по этому спрошу моего более опытного друга:
-Дружище, ситуация такая, что нужно как то распараллелить днс сервера и сделать каскады проксирования/кеширования DNS запросов. Посоветуй, как быть.
-Бро, ты все правильно сделал что обратился ко мне. Смотри сюда и запоминай:
1. Выбери понадежнее под свои DNS серверы в нескольких местах. Пусть это будет 4-12 независимых площадок. Ориентируйся на то чтобы они географически находились близко к основным пользователям твоего ресурса.
1. Пропиши у своего регистратора 4-12 IP адресов в качестве твоих DNS серверов. Чем больше тем лучше. Но не все позволяют прописывать более 4. Это обеспечит первичное обращение к нескольким адресам в качестве держателя DNS зоны.
2. Cделать зонтичное каскадное проксирование / кеширование на каждом прописанном адресе. Т.е. когда на один IP адрес у тебя откликается не один а, допустим 7 или 32 сервера, которые обрабатывают запросы параллельно или по очереди. Их задача отстаивать первую линию и просто кешировать то что отдают держатели зон. Одним «концом» такой сервер смотрит на единый внешний IP адрес, а другим в кластер держателя зон. Ах да. Что такое кластер держателя зон?
5. Держатель зоны может быть сконфигурирован так что читает настройки из файла или из базы данных. А если он может читать из базы данных тогда таких читателей может быть много а база одна. База может иметь репликацию master-slave, ведь писать нам нужно в одном место а читать из многих. А значит изменения в одной базе коснуться всех серверов, которые отвечают за преобразование доменных имен в IP адреса.
-Дружище, я правильно понимаю что у нас получается DNS-кластер который можно масштабировать в реальном времени? И теоритически мы тут упираемся только в разумную стоимость совокупного владения таким кластером?
— Ты все верно понял, бро. Я нарисовал для тебя картинку. Тут ситема рассмотрела глобально, например для оператора связи или . Но ты можешь уменьшить ее в 100 раз и не изменяя сути. Посмотри
Действительно, этот механизм, реализованный в большем или меньшем масштабе, может полностью взять на себя функции первичного регулирования потоком трафика на искомый ресурс. Не в реальном времени конечно, но в приемлемый промежуток времени. Например, в 10 секунд. Вручную таких показателей не добиться, мы не сможем в течении 10 секунд понять, что у нас отвалилось и руками изменить зону. Поэтому лучше прикрутить систему мониторинга, которая по доступности хоста или группы хостов вносит небольшие правки в базу, к которой обращается DNS сервер. Эти изменения вступят в силу немедленно и конечный пользователь через 10 секунд уже будет направлен на нужный адрес.
И так мы решили вопрос правильного первичного балансинга трафика. Но что делать дальше, когда искомый ресурс получает только легитимный трафик и не справляется. Как заставить nginx отвечать на одном сервере на 500 000 легитимных запросов в секунду на гигабитном канале? Дружище, что подскажешь?
-Бро, не нужно запускать сферических коней в вакууме. Поставь два, три, десять серверов и параллельно обрабатывай запросы.
-Т.е мы реализуем технологию CARP или VRRP на наших серверах и получаем распараллеливание нагрузки на уровне 4 модели OSI?
-Конечно, если бы ты был внимательным, ты бы спросил раньше как у тебя будут работать много DNS серверов первой линии на одном адресе.
-Ок, я понял. Давай еще раз проговорим все до чего мы тут договорились:
1. Обеспечить первичны балансинг с помощью нескольких DNS серверов. Начинать можно с даже с двух. Пусть они будут держателями зон, которые смотрят в одну базу данных. Со временем прогнозируйте нагрузку и сместите роль этих сервер до обычных кеширующих серверов. Держатели зон поместите за ними. Если сервис критичный, заранее посадите на один IP адрес нужное количество DNS фроентэнд серверов по технологии CARP или VRRP.
2. Вторичный балансинг трафика который «дошел» очищенным до ресурса – «пареллелить» на уровне приложений(например nginx умеет кластеризоваться), или более универсально на уровне модели OSI(CARP VRRP)
Второй вывод: без применения распаралелливания трафика на уровне модели OSI(4-7 уровень) невозможна качественная реализация высокой доступности сервиса.
В результате мы можем получить систему, которая сможет работать на массовый сектор, или в уменьшенном масштабе для нужд супер популярной гостевой книги.
От масштабов, в данном случае, смысл работы не меняется.
Эта схема может применяться почти к любому типу ресурсов. Есть ограничение на трафик реального времени. Голос и видео организуется немного по-другому, но принципиально не отличается.
Я бы с удовольствием описал как именно этот делал я, но боюсь утомить читателя и так не малым размером статьи. Если будет интересно, и я смогу получить инвайт — буду развивать эту линию и подробно опишу в цикле статей все шаги которые я проделал достигая результата в 100 гигабит активного трафика.
Спасибо за внимание.
P.S.
-Дружище, теоретически, такая система может спасти мир от вампиров и зомби?
-Бро, я сомневаюсь что от нас что-то может спасти. Это только в кино нас убивают кольями и дробовиками. На деле нас может убить только звонкая утренняя женская истерика. А по сути вопроса — упростить людям жизнь эта схема реально может.
Автор: r1alex
