что такое "anycast" и как это полезно?

<p>я никогда не слышал о anycast, пока несколько секунд назад не прочитал " <a href="https://serverfault.com/questions/13356/what-are-some-cool-or-useful-server-networking-tricks/14960#14960">какие крутые или полезные трюки с сервером/сетью?</a> ".</p><p>статья в википедии " <a href="http://en.wikipedia.org/wiki/anycast">anycast</a> " довольно формальна и на самом деле не дает мысленного представления о том, как она будет использоваться.</p><p>может ли кто-нибудь объяснить в нескольких неформальных предложениях, что такое "anycast", как вы его настраиваете (в общем смысле) и каковы его преимущества (что делает его проще)?</p>

<p>anycast - это сетевой метод, в котором один и тот же ip-префикс объявляется из разных мест. затем сеть решает, куда направить пользовательский запрос, основываясь на стоимости протокола маршрутизации и, возможно, "работоспособности" рекламных серверов.</p><p>у anycast есть несколько преимуществ. во-первых, в устойчивом состоянии пользователи службы anycast (отличный пример dns) всегда будут подключаться к "ближайшему" (с точки зрения протокола маршрутизации) dns-серверу. это уменьшает задержку, а также обеспечивает уровень балансировки нагрузки (при условии, что ваши потребители равномерно распределены по вашей сети).</p><p>еще одним преимуществом является простота управления конфигурацией. вместо того чтобы настраивать разные dns-серверы в зависимости от того, где развернут сервер/рабочая станция (азия, америка, европа), у вас есть один ip-адрес, который настраивается в каждом местоположении.</p><p>в зависимости от того, как реализован anycast, он также может обеспечить высокий уровень доступности. если объявление маршрута anycast обусловлено некоторой проверкой работоспособности (например, запросом dns для хорошо известного домена в этом примере), то, как только сервер потерпит неудачу, его маршрут может быть удален. как только сеть повторно соединится, пользовательские запросы будут беспрепятственно перенаправлены на следующий ближайший экземпляр dns без необходимости какого-либо ручного вмешательства или перенастройки.</p><p>конечным преимуществом является горизонтальное масштабирование; если вы обнаружите, что один сервер перегружен, просто разверните другой в месте, которое позволит ему принимать некоторую долю запросов перегруженного сервера. опять же, поскольку не требуется настройка клиента, это можно сделать очень быстро.</p>

<p>одна из вещей, которая часто смущала меня в понимании "anycast", заключается в том, что, хотя это термин высокого уровня, в практической реализации он обычно сводится к двум примерам:</p><ol> <li> <p>маршрутизаторы, использующие <a href="http://en.wikipedia.org/wiki/border\_gateway\_protocol"> bgp </a> для объявления одного и того же блока ip через несколько <a href="http://en.wikipedia.org/wiki/autonomous\_system\_%28internet%29"> как </a> путей как грубые способ направления пользователей на "более близкий" сайт. в то же время он обеспечивает почти прозрачное переключение на другие сайты, просто убирая маршруты из проблемного сайта. это может быть полезно практически для любого протокола, хотя, очевидно, он вызывает много проблем с синхронизацией данных на сервере.</p> </li> <li> <p>объявление одного и того же ip-адреса службы из нескольких точек вашей собственной сети (через <a href="http://en.wikipedia.org/wiki/static\_routing">статическая маршрутизация</a> , <a href="http://en.wikipedia.org/wiki/ospf"> ospf </a> , <a href="http://en.wikipedia.org/wiki/eigrp"> eigrp </a> или что угодно). если маршруты взвешены <em> по-разному </em>, это действует как механизм аварийного переключения. если маршруты взвешены <em> равномерно </em>, он может воспользоваться возможностями балансировки нагрузки для каждого пакета или потока для большинства маршрутизаторов известных производителей. вы должны быть осторожны, что протокол <a href="http://en.wikipedia.org/wiki/application\_layer">уровень приложения</a> удобен для этого, поэтому вы почти всегда слышите о том, что он используется с <a href="http://en.wikipedia.org/wiki/dns"> dns </a> где запрос всегда один пакет и все без сохранения состояния. лично я рассматриваю это как хакерское вторжение проблем прикладного уровня в сетевой уровень, когда сочетание dns и надлежащих балансировщиков нагрузки почти всегда будет лучшим решением.</p> </li> </ol>

<p>в основном используется для служб на основе udp, таких как dns. по сути, вы объявляете один и тот же маршрут из нескольких центров обработки данных по всему миру. таким образом, ваши клиенты будут отправлены в "лучший" и "ближайший" центры обработки данных на основе маршрутов bgp. я поместил "лучшие" и "самые близкие" в кавычки, потому что сетевые провайдеры могут по-разному играть в игры и маршрутизировать трафик из определенных сетей. как правило, с anycast все получается лучше, но это не гарантия.</p><p>примером этого может быть перечисление ваших dns-серверов как 1.2.3.4 и 1.2.3.5. ваши маршрутизаторы объявят маршрут для 1.2.3/24 из нескольких центров обработки данных. если вы находитесь в японии и там есть центр обработки данных, скорее всего, вы окажетесь там. если вы находитесь в сша, вас отправят в центр обработки данных в сша. опять же, это основано на маршрутизации bgp, а не на фактической географической маршрутизации, но обычно это происходит так.</p>

<p>в соответствии с моим первоначальным ответом я только что опубликовал еще две статьи в своем блоге под названием: anycast dns - часть 3, использование rip и anycast dns - часть 3, использование rip (продолжение). последнее более подробно описано, но на сайте www.netlinxinc.com/netlinx-blog.html вы найдете реальные рецепты по настройке маршрутизаторов cisco и программного обеспечения с открытым исходным кодом quagga для маршрутизации на основе хоста для anycast dns с использованием rip.</p><p>в настоящее время я работаю над написанием четвертой статьи в серии. это даст информацию о том, как развернуть anycast dns с использованием ospf. последним в этой серии я покажу рецепты развертывания anycast dns с использованием bgp.</p><p> <a href="http://www.netlinxinc.com/netlinx-blog/45/118.html">anycast dns - часть 1, обзор</a> </p><p> <a href="http://www.netlinxinc.com/netlinx-blog/45/119.html">anycast dns - часть 2, использование статических маршрутов</a> </p><p> <a href="http://www.netlinxinc.com/netlinx-blog/45/120.html">anycast dns - часть 3, использование rip</a> </p><p> <a href="http://www.netlinxinc.com/netlinx-blog/45/121.html">anycast dns - часть 3, использование rip (продолжение)</a> </p>

<p>учитывая, что это в основном dns на данный момент ...</p><p>неформально это делает вашу службу более устойчивой и обеспечивает лучший доступ к сети/задержку/скорость, позволяя вам настроить одну и ту же службу в нескольких местах по всему миру, используя один и тот же адрес. когда кто-то запрашивает этот адрес, ему предоставляется ближайший/лучший маршрут.</p><p>с точки зрения сервера:</p><p>если одноадресная передача - это то, что вы делаете с одним человеком, а многоадресная передача - с несколькими, а трансляция - это то, что вы делаете для всех людей, тогда анкаст является шизофреником и имеет несколько личностей, где личность, наиболее подходящая для каждого человека, связана с ними. хм. не самая лучшая аналогия.</p>

<p>действительно интересное использование anycast - dns. вы можете разместить 5 разных dns-серверов в разных физических и сетевых расположениях, но использовать один (а иногда и первичный, и вторичный dns) адреса. в зависимости от того, где находится источник, они направляются к ближайшему узлу. это обеспечивает некоторую балансировку трафика и обеспечивает избыточность в случае смерти dns-сервера.</p>

<p>также полезно отметить, что anycast не годится или не надежен для некоторых tcp соединений, которые не могут пережить перезагрузки или длительный разговор).</p><p>anycast ips, используя bgp, сообщают интернету, что есть <strong>2, 3 или более путей к определенному хосту</strong>, однако на самом деле это <strong>не тот же хост</strong>, они точны реплики хостов, рекламируемых в нескольких центрах обработки данных, для достижения меньших задержек соединений.</p><p>например, у меня есть 3 сервера, которые выполняют перенаправление 301 без www для 198.251.86.133, если вы пропингуете этот хост, вы можете время от времени получать ответы duplicate или даже пропадать в зависимости от того, где вы находитесь, так как мои серверы находятся в сша-востоке, сша. -запад и евро. для соединений с коротким временем (например, 301, которые кешируются в браузере) это дает быстрый ответ локального сервера в ближайшем центре обработки данных.</p><p>с точки зрения избыточности в anycast нет встроенных, вам все равно потребуется независимая избыточность на каждом сайте, так как этот ip (в типичных сценариях) всегда будет указывать на эти центры данных.</p>

<p>по словам одного из моих коллег, это также полезно в качестве метода смягчения атаки dos, так как люди могут атаковать только "ближайший" anycast ip-адрес, поэтому, если в сша, например, в сша много зомби, ваш евро-сайт будет в основном незатронутый, поскольку они фактически не могут посылать ему пакеты.</p><p>также может быть возможно использовать его как способ (несколько наивно) фильтровать поддельные пакеты, если они явно поступают откуда-то и вряд ли будут объявлены в bgp как правильный маршрут (например, пакеты, поступающие в европу, когда asn указывает на n american) блок).</p>