Хостер обещает два аплинка: как проверить, что резерв действительно существует

MAATRIX

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

Что на самом деле обещает фраза «два аплинка»

Аплинк (uplink) — канал, по которому сеть хостера подключена к остальному интернету: к магистральным операторам, точкам обмена трафиком, другим сетям. Фраза «у нас два аплинка» технически верна в любом из трёх случаев, и маркетинг обычно не уточняет, какой именно имеется в виду:

• Два физических кабеля к одному и тому же вышестоящему оператору (upstream), проложенные разными путями — защита от обрыва конкретного кабеля.
• Два кабеля к двум разным точкам присутствия (PoP) одного и того же оператора — защита от локальной аварии в узле, но не от проблемы у самого оператора целиком.
• Два канала к двум действительно независимым операторам связи — единственный вариант, который защищает и от обрыва кабеля, и от аварии или BGP-инцидента у конкретного поставщика.

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

Мнимая избыточность: два кабеля, один поставщик

Частый источник разочарования — ситуация, когда «резерв» физически есть, но не защищает от нужного сценария. Если оба канала в итоге упираются в одного и того же upstream-оператора (даже через разные кабели и оборудование), авария на его стороне — неправильный BGP-анонс, отказ его оборудования, потеря части пиринга — кладёт оба «независимых» канала одновременно. С точки зрения хостера это честно: физически было два пути, резервных друг для друга по отношению к обрыву кабеля. Но клиент, покупавший резерв ради защиты от аварии у провайдера связи, такой защиты не получил.

Реальный случай, когда кривой BGP-анонс у транзитного оператора увёл трафик клиентов через другой континент, хорошо иллюстрирует эту логику: кривой анонс BGP у аплинка увёл наш трафик в Бразилию. В таком сценарии физическая избыточность каналов вообще не помогает, если оба транзитят через сеть с проблемой на уровне маршрутизации.

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

Настоящая избыточность: разные операторы, разные точки входа

Честная защита выглядит так: у хостера есть каналы минимум к двум разным операторам (или к оператору и к точке обмена трафиком, IX), не зависящим друг от друга — авария или коммерческий конфликт у одного не задевает канал ко второму. Дополнительный, менее очевидный слой — физическое разнообразие ввода: если оба кабеля заходят в здание дата-центра через один и тот же колодец или кроссовую, авария на теплотрассе всё равно оборвёт оба канала одновременно, несмотря на разных операторов.

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

Автоматическое переключение против ручного

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

• Автоматическое на уровне BGP. Сеть анонсирует подсети через оба аплинка сразу (active-active) или через резервный с менее приоритетным анонсом (active-passive). При отказе основного канала маршрутизаторы перестают получать анонсы через него, трафик сходится на резервном без участия человека — обычно счёт идёт на секунды-минуты, хотя точное время зависит от таймеров BGP-сессии и скорости, с которой об отказе узнают соседние сети.
• Полуавтоматическое. Оборудование само определяет отказ, но переключение требует ручного подтверждения или шага дежурного персонала — время реакции зависит от того, есть ли смена 24/7.
• Полностью ручное. Резерв физически есть, но включается только после того, как инженер вручную меняет коммутацию или конфигурацию — фактически это холодный запасной канал, а не отказоустойчивость в привычном смысле: простой длится, пока кто-то заметит проблему и вручную переключит трафик.

Формулировка «есть резервный канал» не говорит, какой из трёх сценариев имеется в виду, а для практики это разница между секундами простоя и часами.

Как посмотреть на аплинки через открытые BGP-инструменты

Часть картины можно увидеть снаружи через публичные инструменты, показывающие объявленные BGP-маршруты. Общая идея (конкретные адреса и доступность сервисов на момент чтения стоит проверить отдельно — такие бесплатные инструменты периодически меняют интерфейс или закрываются):

1. Узнать ASN хостера через whois по IP-адресу сервера:

whois -h whois.ripe.net 185.xxx.xxx.xxx | grep -i origin

В ответе будет строка вида origin: AS64500 (номер условный) — это ASN сети, за которой числится адрес.

1. Посмотреть upstream-сети этого ASN через публичные BGP-справочники — исторически такую возможность бесплатно предоставляли bgp.he.net (Hurricane Electric), bgp.tools и RIPEstat (stat.ripe.net) для сетей европейского региона. По номеру ASN они обычно показывают список анонсируемых подсетей и upstream/peers — сетей, через которые ASN подключён к интернету. Один upstream ASN в списке — сигнал, что операторской избыточности может не быть, независимо от маркетинга. Два и более разных ASN разных организаций — уже похоже на настоящую независимость.

1. Проверить профиль в PeeringDB (peeringdb.com), если он есть — там дата-центры и операторы иногда публикуют точки присутствия и партнёров по пирингу. Отсутствие профиля не приговор, но повод сильнее полагаться на прямые вопросы.

1. Прогнать traceroute/mtr со своей стороны — не даёт полного списка резервных каналов, но показывает активный сейчас путь:

mtr -rw ваш-сервер.example.com

Если несколько раз за день трафик стабильно идёт через один и тот же ASN сразу после сети хостера — это не доказательство отсутствия резерва (при active-passive схеме резервный канал в обычное время попросту не виден), но дополнительный кирпичик к общей картине при отсутствии альтернативных upstream у хостера.

Честное ограничение метода: BGP-инструменты показывают объявленные маршруты и список сетей-соседей, но не показывают внутреннюю ёмкость каналов и не гарантируют, что резерв технически готов принять нагрузку в момент отказа — это видно только по факту аварии или по прямому ответу хостера. Разница между «маршрут анонсируется» и «канал выдержит нагрузку при переключении» — та же логика, что в вопросе про заявленную и фактическую полосу, разобранном в статье про общий канал против выделенного. Базовые понятия о работе BGP и о том, почему один провайдер может влиять на маршруты чужих сетей, — в статье про то, что такое BGP.

Что спрашивать у хостера напрямую

Прямой разговор не заменить BGP-разведкой полностью — но она помогает задавать более точные вопросы, на которые сложно ответить общими словами:

• Сколько именно независимых операторов связи (не кабелей, а юридически разных провайдеров) подключено к сети — двух достаточно, или их больше?
• Переключение автоматическое (на уровне BGP) или требует ручного вмешательства персонала? Если частично автоматическое — какая часть ручная?
• Сколько времени фактически занимает переключение — не по SLA, а по опыту последнего реального случая?
• Что происходит, если проблема не в кабеле, а у самого upstream-оператора целиком — есть ли защита именно от этого, или резерв рассчитан только на физический обрыв?
• Дежурная смена работает 24/7, или переключение в нерабочее время может занять больше времени?

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

Отзывы и история инцидентов

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

При чтении важнее не сам факт «была авария» (случается у всех, включая крупные облака), а то, как хостер её описал и обработал: есть ли конкретика — что произошло, сколько длилось, что делали — или только «были технические работы»; совпадает ли официальная версия с тем, что писали клиенты в момент аварии; была ли авария именно про отказ канала связи, а не про диск, питание или DDoS — не стоит судить о сетевой избыточности по инциденту другого рода.

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

Честный предел проверки со стороны клиента

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

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

Частые вопросы