Привет, Хабр! Ниже следует транскрипция доклада Евгения error2407 Богомазова (сетевой R&D инженер) и Дмитрия h8r Шемонаева (глава NOC) с прошедшего UPTIMEDAY. Видео в конце поста.
В Qrator Labs мы строим собственную сеть anycast для решения особенных задач, отличающихся от таковых у «обычных» операторов связи. Соответственно, у нас есть точки присутствия в перечисленных регионах — мы только забыли добавить сюда Россию. А это значит, что у нас есть множество историй о том, как надо и не нужно делать. Сегодня мы поделимся с вами частью из них.
Что же мы будем рассказывать, учитывая, что тема изначально объемная? Мы поначалу хотели сделать только Q&A (вопросы и ответы), но нас все-таки попросили прочитать доклад. Поэтому, если мы чего-то не расскажем, а что-то мы точно не успеем — ловите нас после, в кулуарах.
В рамках же запланированного мы постараемся рассказать о разнице между балансировкой с помощью DNS и BGP. Как выбирать новые площадки и на что необходимо обращать внимание для того чтобы избежать последующих болей. Как это все поддерживать и насколько это непростое занятие расскажет Дмитрий.
Для начала определимся насколько вы знакомы с тематикой.
— Кто из вас знает, что такое anycast и зачем он нужен? (в зале поднимается около трети рук)
— А кто знаком с DNS и настраивал сервера? (примерно столько же рук)
— А BGP (в кадре две руки)
Все-равно много.
— Ну и последний вопрос — кто знаком с NOC'ом? У кого были проблемы с поставщиками, и кто пытался их решать? (в кадре видна рука сисадмина Хабра)
Отлично. В таком случае, надеюсь, что вам зайдет то, что мы собираемся рассказать.
До того, как перейти к anycast'у, давайте разберемся, зачем же он нужен. У вас есть приложение, с помощью которого вы хотите обрабатывать запросы клиентов. Вы где-то хоститесь — пока еще вы особенно об этом не задумываетесь. Покупаете имя DNS, резолвите его и так далее. Затем подписываете сертификат, потому что HTTPS. Ваше приложение растет.
Во-первых, вы должны справляться с нагрузкой. Если ваше приложение одномоментно «выстреливает» — то есть становится резко популярны, к вам приходит гораздо больше пользователей. Вы должны докупать железо и баласировать нагрузку на него.
Дополнительно, могут возникнуть особо требовательные клиенты со словами: «Ребята, да за такие деньги вы должны быть доступны всегда и везде!» Что ведет к тому, что вы закладываете избыточность вычислительных ресурсов не только ради обработки пиковой нагрузки, но и просто в качестве резерва.
Дополнительно, сегодня это уже было упомянуто в других выступлениях, нельзя размещать железки в одном датацентре — может случиться природный катаклизм, а значит приложение уйдет в даунтайм, что вызовет финансовые и другие потери. Поэтому если ваше приложение достаточно выросло, вы должны размещаться уже в нескольких датацентрах, иначе будет плохо.
У проблемы есть и оборотная сторона — если ваше приложение чувствительно ко времени, как в финансовой аналитике или трейдинге, вам важно отдавать запросы своим пользователям как можно быстрее. Пресловутый latency, с которым связаны два моменты. Первый — если вы хотите отдать запрос как можно быстрее, то для этого количество запросов и ответов на них должно быть как можно меньшим. Опять же дело в том, что когда пользователь подключается к вам в самый первый раз — все не работает и он вынужден пройти все круги ада. Второй момент — скорость света. Пакет из Западной Европы до России не может идти быстрее определенного количества миллисекунд, с этим ничего не поделать.
Необходимо размещаться в нескольких датацентрах потому что мы хотим избыточность и нужно стоять ближе к потенциальным клиентам. Если, допустим, ваш основной клиентский регион — Америка, то вы и будете размещать свое оборудование там же, чтобы трафик не шел через другие страны и части света.
Получается, что с какого-то момента вы должны будете присутствовать во всех частях светах на разных площадках. И это все еще не anycast.
Итак, вам нужно несколько площадок. Как-то надо их выбрать, как изначально новые, так и понимать их способности к масштабированию — при перегрузке придется докупать дополнительное железо.
Если же у вас уже есть несколько площадок, необходимо научиться распределять пользователей между ними. Есть два стула: BGP и DNS.
Из двух пунктов мы начнем с последнего. И снова два основных подхода. В первом у вас различные площадки имеют различные айпишники и, соответственно, когда пользователь приходит с запросом — он получает IP определенной площадки и на нее мапится.
Что мы тут решаем? Мы хотим, чтобы пользователь из определенного региона попадал на площадку, находящуюся в этом же регионе. Самое просто и тупое решение — использовать GeoDNS. У вас есть понимание того, в каких регионах находятся какие префиксы — вы берете эти данные, запихиваете их в DNS-сервер, соответствующе мапите пользователей, если source IP пришел из нужного префикса, на нужную площадку. Но возникает проблема — резолверы. И порядка 15-20% запросов приходят с резолверов — то есть source IP будет 8.8.8.8. Куда такого мапить?
Для этого есть EDNS, который позволяет в рамках запроса передавать изначальную клиентскую подсеть, из которой он пришел. Как вы знаете, 1 февраля 2019 года случился DNS Flag Day — как раз с этого дня все DNS-серверы должны поддерживать данный extension.
В таком примере у вас может быть как одна, так и несколько площадок, на которых находятся DNS-серверы мапящие пользователей — и сами сервера можно распределить по миру. И уже в рамках DNS появляется возможность использовать anycast — об этом мы расскажем чуть позже.
В общей же схеме, вы мапите пользователя на ближайшую к нему площадку, отдавая адрес конкретно этой площадки. Используется это уже реже.
Третий подход связан с тем, что даже если пользователь пришел из того же региона, где находится площадка — это не значит, что проблема задержек решена. Возможно, перекинуть пользователя на другую площадку будет даже выгоднее, так как регион может быть перегружен при условии наличия альтернативных путей. Неплохо было бы это использовать? К сожалению, текущих решений, позволяющих делать нечто подобное, почти нет. Facebook как-то показывал доклад о том, что делал такое — но коробки нет, все придется делать своими руками.
Что мы имеем в итоге с DNS?
Плюсы в том, что различным пользователям можно выдать разные адреса, а конкретного пользователя можно направить на строго определенную площадку — то есть можно работать с индивидуальными юзерами. Ну и DNS легко настраивать.
Каковы минусы? Если вы делаете гранулярную настройку, то конфиг разрастается довольно быстро, что невозможно поддерживать руками. Нужна автоматизация. А если неправильно сделать автоматизацию, то все поломается — если лежит DNS, то приложение недоступно.
С другой стороны, если вы делаете DNS-балансировку, то пользователь мапится на определенную площадку и ее IP становится уязвимым. Это причина, по которой мы не используем DNS-балансировку у себя, так как в этом случае весь трафик атаки может налиться ровно в одну точку, выведя ее из строя.
И как уже было сказано, DNS не поддерживает балансировку по latency из коробки. А делать ее самостоятельно очень тяжело.
Давайте наконец перейдем к вещам более прекрасным, а именно — BGP anycast.
Это именно наш случай. В чем смысл? Все площадки имеют один и тот же IP, точнее — анонсируют один и тот же префикс. Пользователь мапится на «ближайшую» к нему площадку. «Ближайшую» с точки зрения BGP — такой префикс анонсируется при помощи различных маршрутов и, если у оператора есть несколько маршрутов до анонсируемой площадки, то чаще всего он выберет наикратчайшую. Опять же с точки зрения BGP. Скоро мы расскажем, почему это плохо.
Также, BGP работает с доступностью префиксов, поэтому вы всегда оперируете подсетью и не можете манипулировать отдельными айпишниками.
В итоге, так как от всех площадок анонсируется один и тот же префикс, все пользователи из одного региона будут направлены на одну площадку. У атакующего нет способа перекинуть нагрузку из одного региона в другой, поэтому необходимо набрать в каждом из мест столько мощности, сколько захотел оператор, выбравший этот маршрут. Даже если не набрали — это все еще можно защитить.
Анонсируется один и тот же префикс — что может быть проще? Но есть и проблемы.
Первая заключается в том, что из-за необходимости анонсировать один и тот же префикс по всему миру вы вынуждены покупать provider-independent адреса, которые в несколько раз дороже.
Вторая сводится к тому, что пользователей из одного региона нельзя просто перекинуть в другой, если вдруг часть из них нелегитимна или с целью диверсифицировать трафик атаки с помощью других площадок, потому что какой-то больно. Таких ручек нет.
Третья проблема заключается в том, что в рамках BGP очень легко выбрать «не ту» площадку и «не тех» провайдеров. Вам будет казаться, что у вас избыточность и доступность, но на самом деле не будет ни того, ни другого.
У вас есть несколько площадок между которыми вы хотите раскидать пользователей. Какие есть ручки для ограничения определенного региона, стягивающего пользователей на определенную площадку?
Существуют Geo Community. Зачем они? Напомню — вы выбираете ближайший маршрут с точки зрения BGP. И у вас есть Tier-1 оператор, например Level3, у которого свои магистрали вокруг всего мира. Клиент Level3, если вы подключены к нему напрямую, находится от вас в двух хопах. А какой-нибудь местный оператор — в трех. Соответственно, оператор из Америки будет ближе к вам, нежели оператор из России или Европы, потому что с точки зрения BGP это так.
С помощью Geo Community вы можете ограничить регион, в рамках которого такой крупный и интернациональный оператор будет анонсировать ваш маршрут. Проблема также в том, что они доступны далеко не всегда (Geo Community).
У нас есть несколько кейсов, когда это приходилось самим. Дим?
(Слово берет Дмитрий Шемонаев)
«Из коробки» многие операторы этого не предоставляют и говорят, что, мол, мы за сетевой нейтралитет, свободу и так далее, ограничивать ничего не будем. Приходится долго и упорно объяснять операторам кто мы такие, почему этого хотим и зачем нам так важно, а так же просвящать о том, почему это не касается той нейтральности, которую они имеют в виду. Иногда это срабатывает — а иногда нет и мы просто отказываемся от сотрудничества с потенциально интересными операторами потому, что такое сотрудничество приведет к дальнейшей боли в эксплуатации нашего сервиса.
Также, мы довольно часто сталкиваемся с тем, что есть целый ряд операторов, которых уже упомянул Евгений — это Tier-1, которые ни у кого не покупают трафик и только обмениваются им между собой. Но, помимо них есть еще пара-тройка, как минимум, десятков операторов, которые не являются Tier-1 — они покупают трафик, но при этом у них тоже есть развернутые по всему миру сети. Далеко ходить не надо — из ближайших к нам это Ростелеком или ReTN, чуть подальше есть замечательные Taipei telecom, China Unicom, Singtel и так далее.
И в Азии мы довольно часто сталкивались с такой ситуацией, что, казалось бы, у нас есть несколько точек присутствия в Азии, мы подключены к нескольким немаленьким операторам, с точки зрения этого региона. Тем не менее, мы постоянно сталкиваемся с тем, что трафик из Азии идет к нам на площадку через Европы или делает Трансатлантическое путешествие. С точки зрения BGP это вполне себе нормально, ведь он не учитывает latency. А вот приложение в таких условиях страдает, его пользователи тоже — в общем все страдают, но с точки зрения BGP все нормально.
И приходится вносить некоторые изменения руками, делать реверс-инжиниринг того, как устроена маршрутизация у того или иного оператора, иногда договариваться, просить, умолять, стоять на коленях. В общем делать все что угодно для того чтобы решить эти проблемы. С таким наш NOC сталкивается с завидной регулярностью.
Как правило, операторы идут на встречу и в некоторых случаях готовы предоставить некоторый набор… А вообще, можете поднять руки те, кто работал с BGP на уровне community? (Улыбается) Отлично! То есть операторы готовы предоставить некоторый набор управляющих community для того чтобы, например, понизить local pref в определенном регионе, либо добавить prepend, либо не анонсировать ну или что-то еще.
Соответственно, для балансировки нагрузки в BGP сходу есть два пути. Первый — это как на слайде написано, т.н. prepend'ы. Путь в BGP мы можем представить себе как небольшую строку, в которой перечислены автономные системы, через которые проходит путь пакета от отправителя к получателю. Можно добавить в этот путь еще энное количество своих автономных систем и в результате путь удлинится и станет не очень приоритетным. Это лобовой метод и он работает не для всего — если вы добавляете prepend, он не гранулярный, то есть его увидят все в конусе того оператора, в котором вы делаете эту манипуляцию.
С другой стороны есть еще BGP community, которые бывают, как маркировочные, для того чтобы понять, откуда приходит тот или иной префикс, чьим он является по отношению к оператору — то есть пира, клиента или апстрима, а также в каком месте он забран и так далее. И есть управляющие community, которые отправляются на маршрутизатор к оператору и он предпринимает определенные действия с данным префиксом.
У большинства операторов есть ограничительные community. Возьмем для примера абстрактного российского оператора, который подключен к ряду российских операторов в вакууме. У некоторых из них есть пиринговые отношения, подразумевающие паритетный обмен трафиком, у некоторых они покупают. Соответственно, они предоставляют community, для того чтобы сделать prepend'ы в эту сторону, удлинив AS path, либо же не анонсировать или изменить local pref. Если вы оперируете с BGP — посмотрите на community и изучайте, что умеет претендент на то, чтобы стать вашим поставщиком. Иногда community скрыты и приходится общаться либо с менеджерами операторов, либо с техническими специалистами для того, чтобы нам показали определенный поддерживаемый набор.
По умолчанию же community, в случае европейского региона, описаны в RIPE DB. То есть вы делаете запрос в whois номера автономной системы и в поле Remarks обычно написано, что есть у оператора в плане маркировочных и управляющих community. Есть это не у всех, так что часто приходится искать по разным интересным местам.
Как только вы начинаете оперировать BGP, по сути, вы говорите, что сеть это часть вашего приложения, а не что-то абстрактное, так что приходится учитывать риски.
Например, у нас был случай с одной латвийской финансовой организацией, чей префикс в случае включения через нашу сеть становился недоступен примерно у половины Латвии. Хотя казалось бы, ничего не менялось — тот же префикс, который мы анонсируем в Tier-1 операторов, в Европу, казалось бы все есть, включая избыточность. Но мы не могли даже представить, что примерно у половины операторов Латвии в качестве пограничных устройств стояло то, что не может переварить полный объем fullview (вся таблица BGP маршрутизации), которая на тот момент была объемом примерно 650 тысяч префиксов. У них там стояли, ну если кто знает что такое Catalyst 3550 — то там стояло именно это, оно умело только 12000 префиксов. Ну вот они и получали какой-то объем префиксов с IX'а, на котором нас, естественно, не было и default. Вместе с этим от еще одного оператора — Латвийского телевидения, префикс в IX'е которого был не /24, а /22 в котором стоял этот /24.
В итоге он уходил туда, где не знал куда такое маршрутизировать и все вылетало в трубу. Для того чтобы это исправить нам понадобилось около двух дней и упорная переписка с латвийскими операторами до тех пор, пока они нам не показали вывод со своего пограничного устройства и мы только там заметили хостнейм. Всем привет, вот так весело иногда бывает.
Есть множество операторов со старым железом. Есть много операторов со странным пониманием того, как должна работать сеть. И теперь это тоже ваши проблемы, если вы едете играть с 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. Все это правда важно, потому что в прошлом году был прекрасный случай, когда один, довольно крупный российский оператор тестировал какую-то свою услугу и в ночи он проанонсировал очень много префиксов из города Санкт-Петербурга со вставкой своей автономной системы во второй роут-сервер DE-CIX во Франкфурте. Проанонсировал он это туда с blackhole community.
В результате очень много питерских операторов и датацентров столкнулись с недоступность из, например, сети ТТК. Нас это тоже коснулось, но мы смогли обойти это, так как между нашими точками есть своя сеть, где-то оверлейная, а где-то физическая и мы смаршрутизировали обратно трафик из проблемного оператора в того, где проблем не наблюдалось. В общем, побороли. Но я это рассказываю к тому, чтоб вы знали — 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 — то же самое. В контексте SDN'ов вы должны собирать данные с площадок и где-то их агрегировать, а те изменения, которые произошла благодаря этим данным, разливать обратно по площадкам.
Последний пункт — это DNS. Пример с Dyn был показателен — как вы помните, в 2016 году на них была совершена атака, с которой они не справились и очень большое количество популярных в США ресурсов перестали быть доступны. DNS тоже нужно защищать, иначе пользователи не найдут ваше приложение в сети. DNS-кэши спасают, частично, и есть интересные работы в IETF на эту тему, но всегда все упирается в то, будут ли это поддерживать определенные DNS-резолверы.
В любом случае, необходимо иметь защищенный DNS. Это первый этап, который должен отработать для того, чтобы пользователь ознакомился с вашим приложением. При самом первом открытии страницы помимо тех RTT, о которых мы уже говорили, будут дополнительные задержки на DNS-запросы и необходимо быть готовым, что в первый раз страница у пользователя будет открываться достаточно долго, кто-то может и не дотерпеть. Если для вас длительное первое открытие критично — придется ускорять еще и DNS.
В случае anycast вы можете кэшировать ответы DNS на ваших точках присутствия, потому что у вас уже есть эти площадки и DNS-ответы будут приходить достаточно быстро.
А в чем вообще проблема? Ну, latency, ну, балансировка.
Как мы уже упоминали, существует еще природа. Отчасти именно из-за нее нужно размещаться в разных местах. Об этом нельзя забывать, хотя риск и кажется малым.
Есть также человек и фактор случайности. Поэтому нужно по возможности все автоматизировать, тестировать разливаемые конфиги и мониторить изменения. Даже если вы что-то факапнули — будет хорошо, если вы можете внести изменения быстро и локально.
Это 90% случаев. А вот оставшиеся 10% — это если вас решили устранить конкуренты. В этом случае у вас серьезные проблемы. Почему «Резервирование» выделено отдельным большим шрифтом? Если вас решать положить, вам потребуются очень большие объемы каналов на ваших площадках, а значит нужно будет договариваться с большим количеством провайдеров. Иначе, при текущем среднем уровне атак, вы не справитесь никак.
Так что лучше делегировать, нежели покупать свое железо. Даже часть функционала, который мы сегодня описали в рамках anycast и те проблемы, которые возникают, легко решить неправильно. Так что если есть возможность эти проблемы не решать и переложить их на сторонние плечи — вероятно так и стоит поступить. Иначе необходимо точно ответить на вопрос, зачем вам нужно это все реализовывать.
Ну а в случае атаки обращайтесь к тем облакам, которые специализируются на решении таких проблем. Ну или с нами еще можно пообщаться.
Спасибо! Вопросы?
Сегодня мы бы хотели рассказать о том, какие проблемы возникают при построении сети anycast. Зачем мы полезли в это и чем там занимаемся.
В Qrator Labs мы строим собственную сеть anycast для решения особенных задач, отличающихся от таковых у «обычных» операторов связи. Соответственно, у нас есть точки присутствия в перечисленных регионах — мы только забыли добавить сюда Россию. А это значит, что у нас есть множество историй о том, как надо и не нужно делать. Сегодня мы поделимся с вами частью из них.
Что же мы будем рассказывать, учитывая, что тема изначально объемная? Мы поначалу хотели сделать только Q&A (вопросы и ответы), но нас все-таки попросили прочитать доклад. Поэтому, если мы чего-то не расскажем, а что-то мы точно не успеем — ловите нас после, в кулуарах.
В рамках же запланированного мы постараемся рассказать о разнице между балансировкой с помощью DNS и BGP. Как выбирать новые площадки и на что необходимо обращать внимание для того чтобы избежать последующих болей. Как это все поддерживать и насколько это непростое занятие расскажет Дмитрий.
Для начала определимся насколько вы знакомы с тематикой.
— Кто из вас знает, что такое anycast и зачем он нужен? (в зале поднимается около трети рук)
— А кто знаком с DNS и настраивал сервера? (примерно столько же рук)
— А BGP (в кадре две руки)
Все-равно много.
— Ну и последний вопрос — кто знаком с NOC'ом? У кого были проблемы с поставщиками, и кто пытался их решать? (в кадре видна рука сисадмина Хабра)
Отлично. В таком случае, надеюсь, что вам зайдет то, что мы собираемся рассказать.
До того, как перейти к anycast'у, давайте разберемся, зачем же он нужен. У вас есть приложение, с помощью которого вы хотите обрабатывать запросы клиентов. Вы где-то хоститесь — пока еще вы особенно об этом не задумываетесь. Покупаете имя DNS, резолвите его и так далее. Затем подписываете сертификат, потому что HTTPS. Ваше приложение растет.
Во-первых, вы должны справляться с нагрузкой. Если ваше приложение одномоментно «выстреливает» — то есть становится резко популярны, к вам приходит гораздо больше пользователей. Вы должны докупать железо и баласировать нагрузку на него.
Дополнительно, могут возникнуть особо требовательные клиенты со словами: «Ребята, да за такие деньги вы должны быть доступны всегда и везде!» Что ведет к тому, что вы закладываете избыточность вычислительных ресурсов не только ради обработки пиковой нагрузки, но и просто в качестве резерва.
Дополнительно, сегодня это уже было упомянуто в других выступлениях, нельзя размещать железки в одном датацентре — может случиться природный катаклизм, а значит приложение уйдет в даунтайм, что вызовет финансовые и другие потери. Поэтому если ваше приложение достаточно выросло, вы должны размещаться уже в нескольких датацентрах, иначе будет плохо.
У проблемы есть и оборотная сторона — если ваше приложение чувствительно ко времени, как в финансовой аналитике или трейдинге, вам важно отдавать запросы своим пользователям как можно быстрее. Пресловутый latency, с которым связаны два моменты. Первый — если вы хотите отдать запрос как можно быстрее, то для этого количество запросов и ответов на них должно быть как можно меньшим. Опять же дело в том, что когда пользователь подключается к вам в самый первый раз — все не работает и он вынужден пройти все круги ада. Второй момент — скорость света. Пакет из Западной Европы до России не может идти быстрее определенного количества миллисекунд, с этим ничего не поделать.
Необходимо размещаться в нескольких датацентрах потому что мы хотим избыточность и нужно стоять ближе к потенциальным клиентам. Если, допустим, ваш основной клиентский регион — Америка, то вы и будете размещать свое оборудование там же, чтобы трафик не шел через другие страны и части света.
Получается, что с какого-то момента вы должны будете присутствовать во всех частях светах на разных площадках. И это все еще не anycast.
Итак, вам нужно несколько площадок. Как-то надо их выбрать, как изначально новые, так и понимать их способности к масштабированию — при перегрузке придется докупать дополнительное железо.
Если же у вас уже есть несколько площадок, необходимо научиться распределять пользователей между ними. Есть два стула: BGP и DNS.
Из двух пунктов мы начнем с последнего. И снова два основных подхода. В первом у вас различные площадки имеют различные айпишники и, соответственно, когда пользователь приходит с запросом — он получает IP определенной площадки и на нее мапится.
Что мы тут решаем? Мы хотим, чтобы пользователь из определенного региона попадал на площадку, находящуюся в этом же регионе. Самое просто и тупое решение — использовать GeoDNS. У вас есть понимание того, в каких регионах находятся какие префиксы — вы берете эти данные, запихиваете их в DNS-сервер, соответствующе мапите пользователей, если source IP пришел из нужного префикса, на нужную площадку. Но возникает проблема — резолверы. И порядка 15-20% запросов приходят с резолверов — то есть source IP будет 8.8.8.8. Куда такого мапить?
Для этого есть EDNS, который позволяет в рамках запроса передавать изначальную клиентскую подсеть, из которой он пришел. Как вы знаете, 1 февраля 2019 года случился DNS Flag Day — как раз с этого дня все DNS-серверы должны поддерживать данный extension.
В таком примере у вас может быть как одна, так и несколько площадок, на которых находятся DNS-серверы мапящие пользователей — и сами сервера можно распределить по миру. И уже в рамках DNS появляется возможность использовать anycast — об этом мы расскажем чуть позже.
В общей же схеме, вы мапите пользователя на ближайшую к нему площадку, отдавая адрес конкретно этой площадки. Используется это уже реже.
Третий подход связан с тем, что даже если пользователь пришел из того же региона, где находится площадка — это не значит, что проблема задержек решена. Возможно, перекинуть пользователя на другую площадку будет даже выгоднее, так как регион может быть перегружен при условии наличия альтернативных путей. Неплохо было бы это использовать? К сожалению, текущих решений, позволяющих делать нечто подобное, почти нет. Facebook как-то показывал доклад о том, что делал такое — но коробки нет, все придется делать своими руками.
Что мы имеем в итоге с DNS?
Плюсы в том, что различным пользователям можно выдать разные адреса, а конкретного пользователя можно направить на строго определенную площадку — то есть можно работать с индивидуальными юзерами. Ну и DNS легко настраивать.
Каковы минусы? Если вы делаете гранулярную настройку, то конфиг разрастается довольно быстро, что невозможно поддерживать руками. Нужна автоматизация. А если неправильно сделать автоматизацию, то все поломается — если лежит DNS, то приложение недоступно.
С другой стороны, если вы делаете DNS-балансировку, то пользователь мапится на определенную площадку и ее IP становится уязвимым. Это причина, по которой мы не используем DNS-балансировку у себя, так как в этом случае весь трафик атаки может налиться ровно в одну точку, выведя ее из строя.
И как уже было сказано, DNS не поддерживает балансировку по latency из коробки. А делать ее самостоятельно очень тяжело.
Давайте наконец перейдем к вещам более прекрасным, а именно — BGP anycast.
Это именно наш случай. В чем смысл? Все площадки имеют один и тот же IP, точнее — анонсируют один и тот же префикс. Пользователь мапится на «ближайшую» к нему площадку. «Ближайшую» с точки зрения BGP — такой префикс анонсируется при помощи различных маршрутов и, если у оператора есть несколько маршрутов до анонсируемой площадки, то чаще всего он выберет наикратчайшую. Опять же с точки зрения BGP. Скоро мы расскажем, почему это плохо.
Также, BGP работает с доступностью префиксов, поэтому вы всегда оперируете подсетью и не можете манипулировать отдельными айпишниками.
В итоге, так как от всех площадок анонсируется один и тот же префикс, все пользователи из одного региона будут направлены на одну площадку. У атакующего нет способа перекинуть нагрузку из одного региона в другой, поэтому необходимо набрать в каждом из мест столько мощности, сколько захотел оператор, выбравший этот маршрут. Даже если не набрали — это все еще можно защитить.
Анонсируется один и тот же префикс — что может быть проще? Но есть и проблемы.
Первая заключается в том, что из-за необходимости анонсировать один и тот же префикс по всему миру вы вынуждены покупать provider-independent адреса, которые в несколько раз дороже.
Вторая сводится к тому, что пользователей из одного региона нельзя просто перекинуть в другой, если вдруг часть из них нелегитимна или с целью диверсифицировать трафик атаки с помощью других площадок, потому что какой-то больно. Таких ручек нет.
Третья проблема заключается в том, что в рамках BGP очень легко выбрать «не ту» площадку и «не тех» провайдеров. Вам будет казаться, что у вас избыточность и доступность, но на самом деле не будет ни того, ни другого.
У вас есть несколько площадок между которыми вы хотите раскидать пользователей. Какие есть ручки для ограничения определенного региона, стягивающего пользователей на определенную площадку?
Существуют Geo Community. Зачем они? Напомню — вы выбираете ближайший маршрут с точки зрения BGP. И у вас есть Tier-1 оператор, например Level3, у которого свои магистрали вокруг всего мира. Клиент Level3, если вы подключены к нему напрямую, находится от вас в двух хопах. А какой-нибудь местный оператор — в трех. Соответственно, оператор из Америки будет ближе к вам, нежели оператор из России или Европы, потому что с точки зрения BGP это так.
С помощью Geo Community вы можете ограничить регион, в рамках которого такой крупный и интернациональный оператор будет анонсировать ваш маршрут. Проблема также в том, что они доступны далеко не всегда (Geo Community).
У нас есть несколько кейсов, когда это приходилось самим. Дим?
(Слово берет Дмитрий Шемонаев)
«Из коробки» многие операторы этого не предоставляют и говорят, что, мол, мы за сетевой нейтралитет, свободу и так далее, ограничивать ничего не будем. Приходится долго и упорно объяснять операторам кто мы такие, почему этого хотим и зачем нам так важно, а так же просвящать о том, почему это не касается той нейтральности, которую они имеют в виду. Иногда это срабатывает — а иногда нет и мы просто отказываемся от сотрудничества с потенциально интересными операторами потому, что такое сотрудничество приведет к дальнейшей боли в эксплуатации нашего сервиса.
Также, мы довольно часто сталкиваемся с тем, что есть целый ряд операторов, которых уже упомянул Евгений — это Tier-1, которые ни у кого не покупают трафик и только обмениваются им между собой. Но, помимо них есть еще пара-тройка, как минимум, десятков операторов, которые не являются Tier-1 — они покупают трафик, но при этом у них тоже есть развернутые по всему миру сети. Далеко ходить не надо — из ближайших к нам это Ростелеком или ReTN, чуть подальше есть замечательные Taipei telecom, China Unicom, Singtel и так далее.
И в Азии мы довольно часто сталкивались с такой ситуацией, что, казалось бы, у нас есть несколько точек присутствия в Азии, мы подключены к нескольким немаленьким операторам, с точки зрения этого региона. Тем не менее, мы постоянно сталкиваемся с тем, что трафик из Азии идет к нам на площадку через Европы или делает Трансатлантическое путешествие. С точки зрения BGP это вполне себе нормально, ведь он не учитывает latency. А вот приложение в таких условиях страдает, его пользователи тоже — в общем все страдают, но с точки зрения BGP все нормально.
И приходится вносить некоторые изменения руками, делать реверс-инжиниринг того, как устроена маршрутизация у того или иного оператора, иногда договариваться, просить, умолять, стоять на коленях. В общем делать все что угодно для того чтобы решить эти проблемы. С таким наш NOC сталкивается с завидной регулярностью.
Как правило, операторы идут на встречу и в некоторых случаях готовы предоставить некоторый набор… А вообще, можете поднять руки те, кто работал с BGP на уровне community? (Улыбается) Отлично! То есть операторы готовы предоставить некоторый набор управляющих community для того чтобы, например, понизить local pref в определенном регионе, либо добавить prepend, либо не анонсировать ну или что-то еще.
Соответственно, для балансировки нагрузки в BGP сходу есть два пути. Первый — это как на слайде написано, т.н. prepend'ы. Путь в BGP мы можем представить себе как небольшую строку, в которой перечислены автономные системы, через которые проходит путь пакета от отправителя к получателю. Можно добавить в этот путь еще энное количество своих автономных систем и в результате путь удлинится и станет не очень приоритетным. Это лобовой метод и он работает не для всего — если вы добавляете prepend, он не гранулярный, то есть его увидят все в конусе того оператора, в котором вы делаете эту манипуляцию.
С другой стороны есть еще BGP community, которые бывают, как маркировочные, для того чтобы понять, откуда приходит тот или иной префикс, чьим он является по отношению к оператору — то есть пира, клиента или апстрима, а также в каком месте он забран и так далее. И есть управляющие community, которые отправляются на маршрутизатор к оператору и он предпринимает определенные действия с данным префиксом.
У большинства операторов есть ограничительные community. Возьмем для примера абстрактного российского оператора, который подключен к ряду российских операторов в вакууме. У некоторых из них есть пиринговые отношения, подразумевающие паритетный обмен трафиком, у некоторых они покупают. Соответственно, они предоставляют community, для того чтобы сделать prepend'ы в эту сторону, удлинив AS path, либо же не анонсировать или изменить local pref. Если вы оперируете с BGP — посмотрите на community и изучайте, что умеет претендент на то, чтобы стать вашим поставщиком. Иногда community скрыты и приходится общаться либо с менеджерами операторов, либо с техническими специалистами для того, чтобы нам показали определенный поддерживаемый набор.
По умолчанию же community, в случае европейского региона, описаны в RIPE DB. То есть вы делаете запрос в whois номера автономной системы и в поле Remarks обычно написано, что есть у оператора в плане маркировочных и управляющих community. Есть это не у всех, так что часто приходится искать по разным интересным местам.
Как только вы начинаете оперировать BGP, по сути, вы говорите, что сеть это часть вашего приложения, а не что-то абстрактное, так что приходится учитывать риски.
Например, у нас был случай с одной латвийской финансовой организацией, чей префикс в случае включения через нашу сеть становился недоступен примерно у половины Латвии. Хотя казалось бы, ничего не менялось — тот же префикс, который мы анонсируем в Tier-1 операторов, в Европу, казалось бы все есть, включая избыточность. Но мы не могли даже представить, что примерно у половины операторов Латвии в качестве пограничных устройств стояло то, что не может переварить полный объем fullview (вся таблица BGP маршрутизации), которая на тот момент была объемом примерно 650 тысяч префиксов. У них там стояли, ну если кто знает что такое Catalyst 3550 — то там стояло именно это, оно умело только 12000 префиксов. Ну вот они и получали какой-то объем префиксов с IX'а, на котором нас, естественно, не было и default. Вместе с этим от еще одного оператора — Латвийского телевидения, префикс в IX'е которого был не /24, а /22 в котором стоял этот /24.
В итоге он уходил туда, где не знал куда такое маршрутизировать и все вылетало в трубу. Для того чтобы это исправить нам понадобилось около двух дней и упорная переписка с латвийскими операторами до тех пор, пока они нам не показали вывод со своего пограничного устройства и мы только там заметили хостнейм. Всем привет, вот так весело иногда бывает.
Есть множество операторов со старым железом. Есть много операторов со странным пониманием того, как должна работать сеть. И теперь это тоже ваши проблемы, если вы едете играть с 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. Все это правда важно, потому что в прошлом году был прекрасный случай, когда один, довольно крупный российский оператор тестировал какую-то свою услугу и в ночи он проанонсировал очень много префиксов из города Санкт-Петербурга со вставкой своей автономной системы во второй роут-сервер DE-CIX во Франкфурте. Проанонсировал он это туда с blackhole community.
В результате очень много питерских операторов и датацентров столкнулись с недоступность из, например, сети ТТК. Нас это тоже коснулось, но мы смогли обойти это, так как между нашими точками есть своя сеть, где-то оверлейная, а где-то физическая и мы смаршрутизировали обратно трафик из проблемного оператора в того, где проблем не наблюдалось. В общем, побороли. Но я это рассказываю к тому, чтоб вы знали — 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 — то же самое. В контексте SDN'ов вы должны собирать данные с площадок и где-то их агрегировать, а те изменения, которые произошла благодаря этим данным, разливать обратно по площадкам.
Последний пункт — это DNS. Пример с Dyn был показателен — как вы помните, в 2016 году на них была совершена атака, с которой они не справились и очень большое количество популярных в США ресурсов перестали быть доступны. DNS тоже нужно защищать, иначе пользователи не найдут ваше приложение в сети. DNS-кэши спасают, частично, и есть интересные работы в IETF на эту тему, но всегда все упирается в то, будут ли это поддерживать определенные DNS-резолверы.
В любом случае, необходимо иметь защищенный DNS. Это первый этап, который должен отработать для того, чтобы пользователь ознакомился с вашим приложением. При самом первом открытии страницы помимо тех RTT, о которых мы уже говорили, будут дополнительные задержки на DNS-запросы и необходимо быть готовым, что в первый раз страница у пользователя будет открываться достаточно долго, кто-то может и не дотерпеть. Если для вас длительное первое открытие критично — придется ускорять еще и DNS.
В случае anycast вы можете кэшировать ответы DNS на ваших точках присутствия, потому что у вас уже есть эти площадки и DNS-ответы будут приходить достаточно быстро.
А в чем вообще проблема? Ну, latency, ну, балансировка.
Как мы уже упоминали, существует еще природа. Отчасти именно из-за нее нужно размещаться в разных местах. Об этом нельзя забывать, хотя риск и кажется малым.
Есть также человек и фактор случайности. Поэтому нужно по возможности все автоматизировать, тестировать разливаемые конфиги и мониторить изменения. Даже если вы что-то факапнули — будет хорошо, если вы можете внести изменения быстро и локально.
Это 90% случаев. А вот оставшиеся 10% — это если вас решили устранить конкуренты. В этом случае у вас серьезные проблемы. Почему «Резервирование» выделено отдельным большим шрифтом? Если вас решать положить, вам потребуются очень большие объемы каналов на ваших площадках, а значит нужно будет договариваться с большим количеством провайдеров. Иначе, при текущем среднем уровне атак, вы не справитесь никак.
Так что лучше делегировать, нежели покупать свое железо. Даже часть функционала, который мы сегодня описали в рамках anycast и те проблемы, которые возникают, легко решить неправильно. Так что если есть возможность эти проблемы не решать и переложить их на сторонние плечи — вероятно так и стоит поступить. Иначе необходимо точно ответить на вопрос, зачем вам нужно это все реализовывать.
Ну а в случае атаки обращайтесь к тем облакам, которые специализируются на решении таких проблем. Ну или с нами еще можно пообщаться.
Спасибо! Вопросы?
