Хабрахабр

Построение и эксплуатация отказоустойчивой anycast-сети

Привет, Хабр! Ниже следует транскрипция доклада Евгения error2407 Богомазова (сетевой R&D инженер) и Дмитрия h8r Шемонаева (глава NOC) с прошедшего UPTIMEDAY. Видео в конце поста.

Зачем мы полезли в это и чем там занимаемся. Сегодня мы бы хотели рассказать о том, какие проблемы возникают при построении сети anycast.


В Qrator Labs мы строим собственную сеть anycast для решения особенных задач, отличающихся от таковых у «обычных» операторов связи. Соответственно, у нас есть точки присутствия в перечисленных регионах — мы только забыли добавить сюда Россию. А это значит, что у нас есть множество историй о том, как надо и не нужно делать. Сегодня мы поделимся с вами частью из них.

Мы поначалу хотели сделать только Q&A (вопросы и ответы), но нас все-таки попросили прочитать доклад.
Что же мы будем рассказывать, учитывая, что тема изначально объемная? Поэтому, если мы чего-то не расскажем, а что-то мы точно не успеем — ловите нас после, в кулуарах.

Как выбирать новые площадки и на что необходимо обращать внимание для того чтобы избежать последующих болей. В рамках же запланированного мы постараемся рассказать о разнице между балансировкой с помощью DNS и BGP. (в зале поднимается около трети рук)
— А кто знаком с DNS и настраивал сервера? Как это все поддерживать и насколько это непростое занятие расскажет Дмитрий.

Для начала определимся насколько вы знакомы с тематикой.
— Кто из вас знает, что такое anycast и зачем он нужен? (примерно столько же рук)
— А BGP (в кадре две руки)

Все-равно много.

У кого были проблемы с поставщиками, и кто пытался их решать? — Ну и последний вопрос — кто знаком с NOC'ом? (в кадре видна рука сисадмина Хабра)

В таком случае, надеюсь, что вам зайдет то, что мы собираемся рассказать.

До того, как перейти к anycast'у, давайте разберемся, зачем же он нужен. Отлично. Вы где-то хоститесь — пока еще вы особенно об этом не задумываетесь. У вас есть приложение, с помощью которого вы хотите обрабатывать запросы клиентов. Затем подписываете сертификат, потому что HTTPS. Покупаете имя DNS, резолвите его и так далее. Если ваше приложение одномоментно «выстреливает» — то есть становится резко популярны, к вам приходит гораздо больше пользователей. Ваше приложение растет.

Во-первых, вы должны справляться с нагрузкой. Вы должны докупать железо и баласировать нагрузку на него.

Дополнительно, могут возникнуть особо требовательные клиенты со словами: «Ребята, да за такие деньги вы должны быть доступны всегда и везде!» Что ведет к тому, что вы закладываете избыточность вычислительных ресурсов не только ради обработки пиковой нагрузки, но и просто в качестве резерва.

Поэтому если ваше приложение достаточно выросло, вы должны размещаться уже в нескольких датацентрах, иначе будет плохо.

У проблемы есть и оборотная сторона — если ваше приложение чувствительно ко времени, как в финансовой аналитике или трейдинге, вам важно отдавать запросы своим пользователям как можно быстрее. Дополнительно, сегодня это уже было упомянуто в других выступлениях, нельзя размещать железки в одном датацентре — может случиться природный катаклизм, а значит приложение уйдет в даунтайм, что вызовет финансовые и другие потери. Первый — если вы хотите отдать запрос как можно быстрее, то для этого количество запросов и ответов на них должно быть как можно меньшим. Пресловутый latency, с которым связаны два моменты. Второй момент — скорость света. Опять же дело в том, что когда пользователь подключается к вам в самый первый раз — все не работает и он вынужден пройти все круги ада. Если, допустим, ваш основной клиентский регион — Америка, то вы и будете размещать свое оборудование там же, чтобы трафик не шел через другие страны и части света. Пакет из Западной Европы до России не может идти быстрее определенного количества миллисекунд, с этим ничего не поделать.

Необходимо размещаться в нескольких датацентрах потому что мы хотим избыточность и нужно стоять ближе к потенциальным клиентам.

И это все еще не anycast.

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

Есть два стула: BGP и DNS.

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

Мы хотим, чтобы пользователь из определенного региона попадал на площадку, находящуюся в этом же регионе. Что мы тут решаем? У вас есть понимание того, в каких регионах находятся какие префиксы — вы берете эти данные, запихиваете их в DNS-сервер, соответствующе мапите пользователей, если source IP пришел из нужного префикса, на нужную площадку. Самое просто и тупое решение — использовать GeoDNS. И порядка 15-20% запросов приходят с резолверов — то есть source IP будет 8. Но возникает проблема — резолверы. 8. 8. Куда такого мапить? 8.

Как вы знаете, 1 февраля 2019 года случился DNS Flag Day — как раз с этого дня все DNS-серверы должны поддерживать данный extension. Для этого есть EDNS, который позволяет в рамках запроса передавать изначальную клиентскую подсеть, из которой он пришел.

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

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

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

Что мы имеем в итоге с DNS?

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

Если вы делаете гранулярную настройку, то конфиг разрастается довольно быстро, что невозможно поддерживать руками. Каковы минусы? А если неправильно сделать автоматизацию, то все поломается — если лежит DNS, то приложение недоступно. Нужна автоматизация.

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

А делать ее самостоятельно очень тяжело.

Давайте наконец перейдем к вещам более прекрасным, а именно — BGP anycast. И как уже было сказано, DNS не поддерживает балансировку по latency из коробки.

В чем смысл? Это именно наш случай. Пользователь мапится на «ближайшую» к нему площадку. Все площадки имеют один и тот же IP, точнее — анонсируют один и тот же префикс. Опять же с точки зрения BGP. «Ближайшую» с точки зрения BGP — такой префикс анонсируется при помощи различных маршрутов и, если у оператора есть несколько маршрутов до анонсируемой площадки, то чаще всего он выберет наикратчайшую. Скоро мы расскажем, почему это плохо.

Также, BGP работает с доступностью префиксов, поэтому вы всегда оперируете подсетью и не можете манипулировать отдельными айпишниками.

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

Но есть и проблемы.
Первая заключается в том, что из-за необходимости анонсировать один и тот же префикс по всему миру вы вынуждены покупать provider-independent адреса, которые в несколько раз дороже. Анонсируется один и тот же префикс — что может быть проще?

Таких ручек нет. Вторая сводится к тому, что пользователей из одного региона нельзя просто перекинуть в другой, если вдруг часть из них нелегитимна или с целью диверсифицировать трафик атаки с помощью других площадок, потому что какой-то больно.

Вам будет казаться, что у вас избыточность и доступность, но на самом деле не будет ни того, ни другого.

У вас есть несколько площадок между которыми вы хотите раскидать пользователей. Третья проблема заключается в том, что в рамках BGP очень легко выбрать «не ту» площадку и «не тех» провайдеров. Какие есть ручки для ограничения определенного региона, стягивающего пользователей на определенную площадку?

Зачем они? Существуют Geo Community. И у вас есть Tier-1 оператор, например Level3, у которого свои магистрали вокруг всего мира. Напомню — вы выбираете ближайший маршрут с точки зрения BGP. А какой-нибудь местный оператор — в трех. Клиент Level3, если вы подключены к нему напрямую, находится от вас в двух хопах. Соответственно, оператор из Америки будет ближе к вам, нежели оператор из России или Европы, потому что с точки зрения BGP это так.

Проблема также в том, что они доступны далеко не всегда (Geo Community). С помощью Geo Community вы можете ограничить регион, в рамках которого такой крупный и интернациональный оператор будет анонсировать ваш маршрут.

Дим? У нас есть несколько кейсов, когда это приходилось самим.

(Слово берет Дмитрий Шемонаев)

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

Но, помимо них есть еще пара-тройка, как минимум, десятков операторов, которые не являются Tier-1 — они покупают трафик, но при этом у них тоже есть развернутые по всему миру сети. Также, мы довольно часто сталкиваемся с тем, что есть целый ряд операторов, которых уже упомянул Евгений — это Tier-1, которые ни у кого не покупают трафик и только обмениваются им между собой. Далеко ходить не надо — из ближайших к нам это Ростелеком или ReTN, чуть подальше есть замечательные Taipei telecom, China Unicom, Singtel и так далее.

Тем не менее, мы постоянно сталкиваемся с тем, что трафик из Азии идет к нам на площадку через Европы или делает Трансатлантическое путешествие. И в Азии мы довольно часто сталкивались с такой ситуацией, что, казалось бы, у нас есть несколько точек присутствия в Азии, мы подключены к нескольким немаленьким операторам, с точки зрения этого региона. А вот приложение в таких условиях страдает, его пользователи тоже — в общем все страдают, но с точки зрения BGP все нормально. С точки зрения BGP это вполне себе нормально, ведь он не учитывает latency.

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

(Улыбается) Отлично! Как правило, операторы идут на встречу и в некоторых случаях готовы предоставить некоторый набор… А вообще, можете поднять руки те, кто работал с BGP на уровне community? То есть операторы готовы предоставить некоторый набор управляющих community для того чтобы, например, понизить local pref в определенном регионе, либо добавить prepend, либо не анонсировать ну или что-то еще.

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

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

Возьмем для примера абстрактного российского оператора, который подключен к ряду российских операторов в вакууме. У большинства операторов есть ограничительные community. Соответственно, они предоставляют community, для того чтобы сделать prepend'ы в эту сторону, удлинив AS path, либо же не анонсировать или изменить local pref. У некоторых из них есть пиринговые отношения, подразумевающие паритетный обмен трафиком, у некоторых они покупают. Иногда community скрыты и приходится общаться либо с менеджерами операторов, либо с техническими специалистами для того, чтобы нам показали определенный поддерживаемый набор. Если вы оперируете с BGP — посмотрите на community и изучайте, что умеет претендент на то, чтобы стать вашим поставщиком.

То есть вы делаете запрос в whois номера автономной системы и в поле Remarks обычно написано, что есть у оператора в плане маркировочных и управляющих community. По умолчанию же community, в случае европейского региона, описаны в RIPE DB. Есть это не у всех, так что часто приходится искать по разным интересным местам.

Как только вы начинаете оперировать BGP, по сути, вы говорите, что сеть это часть вашего приложения, а не что-то абстрактное, так что приходится учитывать риски.

Хотя казалось бы, ничего не менялось — тот же префикс, который мы анонсируем в Tier-1 операторов, в Европу, казалось бы все есть, включая избыточность. Например, у нас был случай с одной латвийской финансовой организацией, чей префикс в случае включения через нашу сеть становился недоступен примерно у половины Латвии. У них там стояли, ну если кто знает что такое Catalyst 3550 — то там стояло именно это, оно умело только 12000 префиксов. Но мы не могли даже представить, что примерно у половины операторов Латвии в качестве пограничных устройств стояло то, что не может переварить полный объем fullview (вся таблица BGP маршрутизации), которая на тот момент была объемом примерно 650 тысяч префиксов. Вместе с этим от еще одного оператора — Латвийского телевидения, префикс в IX'е которого был не /24, а /22 в котором стоял этот /24. Ну вот они и получали какой-то объем префиксов с IX'а, на котором нас, естественно, не было и default.

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

Есть много операторов со странным пониманием того, как должна работать сеть. Есть множество операторов со старым железом. Ну и в итоге многие операторы одноногие (один вышестоящий поставщик связности), поэтому у них свои собственные наборы костылей.
И теперь это тоже ваши проблемы, если вы едете играть с BGP.

(Евгений Богомазов продолжает)

Как видите, даже эту тему можно развивать долго и в 40 минут уложиться сложно.

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

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

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

В принципе этих двух моментов достаточно, для того чтобы понять, какой регион будет стянут и куда вставать. Два основных момента — это длина пути, на которую влияют prepend'ы и local preference, который говорит, что маршруты от клиентов предпочтительнее маршрутов откуда бы то ни было еще.

Помимо прочего, необходимо учитывать еще пару вещей, а именно — какая связность у вашего поставщика, дополнительно и то, что некоторые поставщики между собой не общаются («пиринговые войны») и даже если вы подключились к региональному Tier-1 это не значит, что все локальные пользователи будут вас видеть.

Отвечая на вопрос: «Куда вставать?» выбор вроде как очевиден. Еще одна вещь про которую часто забывают заключается в том, что связность в IPv4 и IPv6 совершенно разная, друг на друга не переносящаяся.

И тут мы подходим к основному моменту. Там есть связность, большинство пользователей, по идее, должны быть к нему подключены, а большинство контентщиков, таких компаний как Яндекс и прочие, сначала подключаются к IX'ам и только потом уже к поставщикам. Если у вас есть пользователи в регионе — вы встаете на IX в этом регионе и думать тут больше не о чем. Но у поставщиков могут быть уникальные клиенты, некоторые поставщики сами не присутствуют на IX'е и, в итоге, вы не можете перенаправить этих пользователей на себя — они пойдут к вам странными путями.

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

О том, как правильно выбирать поставщиков, Дима, расскажешь?

(и опять Дмитрий Шемонаев)

Давайте представим, что у нас есть одна точка и регион нашего интереса это Россия. Окей. У нас есть точка в условно-хорошем датацентре в Москве, мы оперируем своей автономной системой, собственным набором префиксов и решили скейлится, используя BGP anycast — стильно и модно.

Давайте, говорят, мы останемся в Москве и точку поставим в Новосибирске, все будет лучше, RTT упадет, понятное дело. Бизнес, совместно с техническими коллегами решили, что от Владивостока до Москвы сильно большой RTT и это плохо, то есть не хорошо. Сказано — сделано.

Да, в принципе мы можем положится на внутреннюю маршрутизацию поставщика, но это не всегда правильно — в данном случае мы кладем все яйца в одну корзину и надо понимать, что маршрутизация согласно IGP оператора может быть не оптимальной, мягко говоря, потому что не всегда понятно что же ею движет. Тут встает вопрос о площадке для размещения оборудования, но это немного за рамками нашего сегодняшнего разговора, а вот вопрос о выборе оператора — вполне.
Казалось бы, выбор очеввиден — в Москве мы подключены к условному «Москвателекому», давайте и в Новосибирске к нему же воткнемся. Иногда понятно, иногда не очень — сейчас не об этом, к тому же мне руководство запретило ругаться, поэтому я просто не могу детально разобрать некоторые примеры.

И в один прекрасный момент такой контроллер может эту сеть просто уничтожить. Современные веяния таковы, что даже «Москвателеком» может сказать, что настало время SDN и сейчас мы поставим замечательный контроллер, который будет рулить сетью. Из-за одной сетевой карты. Навскидку не припомню такого случая, конкретно с SDN-контроллером, но вот совсем недавно в Америке у крупного оператора (CenturyLink) одна сетевка отошла к сетевому богу и вся сеть нестабильно работала по всем США. Из-за одной сетевки. NOC этого оператора трое или четверо суток разруливал эту проблему.

Если вы подключены к одному оператору — я вас искренне поздравляю.

Тут — с «Москвателекомом», а там — с «Новосибирсктелекомом» (все совпадения случайны). Ну ладно, значит, решили — мы не будем сотрудничать с условным одним оператором в Москве и Новосибирске. Всегда желательно, чтобы операторы были паритетные и имели пиринги между собой на территории того региона, в котором находится ваш интерес. Размеры клиентских конусов этих двух телекомов различаются как черепаха от слона и весь свой трафик вы получите туда, куда приходится основной клиентский конус, то есть в московский «Москвателеком». Поэтому трафик ходил между этими операторами плюс-минус оптимально. В России несколько раз лет назад у крупнейших операторов, таких как Ростелеком и ТТК, были пиринги в Москве, в Санкт-Петербурге, в Нижнем Новгороде, в Новосибирске и вроде бы во Владивостоке.

Чтобы у него были community, чтобы у него был NOC. Но оператора все-таки нужно подбирать правильно. Проанонсировал он это туда с blackhole community. Все это правда важно, потому что в прошлом году был прекрасный случай, когда один, довольно крупный российский оператор тестировал какую-то свою услугу и в ночи он проанонсировал очень много префиксов из города Санкт-Петербурга со вставкой своей автономной системы во второй роут-сервер DE-CIX во Франкфурте.

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

Вернемся к NOC'у. Трехдневная частичная недоступность у ряда операторов. Ответами на ряд тикетов, поступающих относительно сети. Network Operations Center — центр управления сетью, это то подразделение компании, которое занимается эксплуатацией сети, работами на сети и так далее. Взращенные Айти-суммой специалисты в этом зале наверняка знают все хорошие вещи о мониторинге. Что же хочется добавить? В некоторых случаях мониторить придется очень специфичные вещи.

Некоторые пользователи могут жаловаться на то, что «все как-то плохо» и не имеют возможности предоставить диагностику, требуемую для начала работ по исправлению ситуации. Это действительно важно. В таком случае мы стараемся взаимодействовать с NOC'ом того оператора, в клиентском конусе которого находится этот пользователь. Есть сигнал о том, что плохо — а что и где, непонятно. В общем, собираем как можем. Если не получается, то мы смотрим на то, какие есть корреляции — возможность ноды проекта RIPE Atlas внутри этого конуса. Мы готовы к тому, что нам не всегда могут дать.

Для примера возьмем трех операторов: Мегафон, Ростелеком и Транстелеком. В некоторых случаях имеет смысл мониторить с какими community приходит тот или иной префикс на ваш пограничный маршрутизатор и собирать историческую ретроспективу, простите за тафтологию. Вы видите префиксы, в которых находятся ваши пользователи, с каким-то набором маркировочных community, в данном случае. Предположим, что у всех них есть пиринг на территории РФ, а вы подключены к условному Ростелекому или неважно. Например вам приходит префикс с community, что это пир на территории России. Их можно собирать, записывать и когда что-то случится — community поменяются. И тут это community поменялось на то, что это пир во Франкфурте. Ага, отлично, записали. Что эти оператора разорвали между собой пиринговые отношения и у вас с latency все уже не очень хорошо — вы идете через европейскую петлю. Что это значит? В таком случае можно делать что-то проактивно, но это трудоемко и требует решимости, а также прочих качеств.

Почему важно автоматизировать? И по возможности все автоматизируйте — это лет 10 назад было тяжело, а сейчас есть куча утилит, типа Ansible, Chef, Puppet, которые умеют взаимодействовать с сетевыми элементами. С точки зрения того человека это правило на вас тоже распространяется. Я очень долго настраивал BGP и первое правило звучит примерно так: «С кем бы ты ни настраивал BGP-соседство, с той стороны с тобой его настраивает не очень приятный человек».

У меня был стык с одним крупным контентщиком — онлайн-кинотеатром и у меня был стык с местной дочкой Ростелекома. У меня лично был случай, когда я в некотором самарском операторе, чье имя мы не будем называть, переносил все пиринги с одного бордера на другой. И я, как человек приятный, перенес все это ночью — смотрю на графики, на стомегабитный стык и думаю: «О как попер-то!» А потом смотрю — этот в полку, тот в полку и думаю (бьет себя по лбу) — я забыл сделать фильтры. Только с контентщиком у меня был гиговый стык, а с дочкой стомегабитный. Автоматизация — враг нехороших людей и друг хороших. Вот чтобы огородиться от таких своих действий, ведь все остальные приняли, от тройного страйка как раз нужно защищаться автоматизацией.

Дальше ты, Женя.

(Евгений Богомазов продолжает)

Но на anycast'е все не заканчивается, помимо него нужно следить за другими, дополнительными, вещами.

Давайте посмотрим, что еще есть. Вот мы и обсудили все изначальные тезисы. Если такой возможности нет, то насколько бы ваша система ни была распределена, все пользователи пойдут на ту площадку, где приложение находится фактически. Нужно посмотреть, насколько хорошо приложение интегрируется в распределенность — если есть несколько плозадок, нужно иметь возможность раскидывать контент по этим площадкам. И именно RTT вы не сэкономите.

Если приложение будет все поддерживать, то используйте anycast облака, если не хотите развивать собственную инфраструктуру — это принесет много профита. С другой стороны, если пользовательских данных как таковых у вас нет, то вы можете разместить пользовательское приложение на той площадке — так и сделайте.

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

Бизнес-метрики обычно падают потому, что где-то что-то случилось, но это, конечно, утопия — даже мы к такому пока не приблизились.

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

Вам приходит новый префикс — вы должны его везде проанонсировать, обновили DNS — то же самое. Если у вас довольно много площадок, то вы должны уметь одновременно обновлять конфиги в разных местах. Пример с Dyn был показателен — как вы помните, в 2016 году на них была совершена атака, с которой они не справились и очень большое количество популярных в США ресурсов перестали быть доступны. В контексте SDN'ов вы должны собирать данные с площадок и где-то их агрегировать, а те изменения, которые произошла благодаря этим данным, разливать обратно по площадкам.

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

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

Ну, latency, ну, балансировка.
Как мы уже упоминали, существует еще природа. В случае anycast вы можете кэшировать ответы DNS на ваших точках присутствия, потому что у вас уже есть эти площадки и DNS-ответы будут приходить достаточно быстро.

А в чем вообще проблема? Об этом нельзя забывать, хотя риск и кажется малым. Отчасти именно из-за нее нужно размещаться в разных местах.

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

А вот оставшиеся 10% — это если вас решили устранить конкуренты. Это 90% случаев. Почему «Резервирование» выделено отдельным большим шрифтом? В этом случае у вас серьезные проблемы. Иначе, при текущем среднем уровне атак, вы не справитесь никак.

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

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

Вопросы? Спасибо!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть