Перейти к содержимому
ИТ-администрирование

Как организовать резервный интернет через двух провайдеров

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

3 минуты чтенияКоманда RKTSocial

Второй провайдер подключён, счёт оплачивается, все спокойны. Авария показывает две вещи: переключение не произошло автоматически, а когда его сделали руками — перестала работать половина сервисов.

Разберём, почему так и что нужно продумать заранее.

Два разных подхода

Переключение по отказуБалансировка
Как работаетОсновной канал, резерв включается при паденииОба канала используются одновременно
Суммарная полосаКак у основногоБольше
Поведение при аварииРазрыв соединений, потом восстановлениеЧасть соединений рвётся
Сложность настройкиНижеВыше
ПредсказуемостьВысокаяНиже: непонятно, каким каналом ушёл запрос
Когда выбиратьНужна доступностьНе хватает полосы

Для большинства офисов задача — доступность, а не полоса. Значит, переключение по отказу: оно проще, предсказуемее и его реально проверить.

Что ломается при переключении

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

Основной канал:  внешний адрес A
Резервный:       внешний адрес Б

Что сломается при переходе A → Б:

  публикация сервисов   ─ домены указывают на A
  site-to-site VPN      ─ вторая площадка ждёт A
  доступ к внешним API  ─ если там разрешён только A
  почта                 ─ записи отправителя указывают на A
  удалённый доступ      ─ сотрудники подключаются к A

Поэтому «настроить резервный канал» — это не про роутер, а про перечень того, что завязано на внешний адрес.

Что продумать заранее

  1. Шаг 1

    Составить список привязок к внешнему адресу

    Домены, VPN между площадками, разрешения на стороне партнёров и провайдеров сервисов, удалённый доступ, почта. Список почти всегда длиннее, чем помнят.

  2. Шаг 2

    Решить по каждому пункту, что с ним при переключении

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

  3. Шаг 3

    Определить критерий переключения

    «Канал недоступен» — недостаточно: канал может отвечать, но не пропускать трафик. Проверять нужно доступность внешнего узла, а не самого шлюза провайдера.

  4. Шаг 4

    Определить критерий возврата

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

  5. Шаг 5

    Проверить резерв под нагрузкой

    Не «пингуется», а реально пропускает рабочий трафик офиса.

Что делать с публикацией сервисов

Самая болезненная часть. Если наружу опубликованы сайты и корпоративные сервисы, при смене адреса они становятся недоступны, пока не обновятся записи домена.

Варианты, по возрастанию сложности:

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

Как устроена сама публикация нескольких сервисов через один адрес — в отдельном материале.

Проверка до аварии

Резерв, который не проверяли, — это предположение. Проверка занимает полчаса и делается в спокойное время.

  1. Предупредить сотрудников: соединения разорвутся.
  2. Отключить основной канал физически или программно.
  3. Засечь, за сколько произошло переключение.
  4. Проверить: интернет из офиса, доступ к рабочим сервисам, VPN, телефония, почта.
  5. Записать, что не заработало.
  6. Вернуть основной канал и засечь время возврата.
  7. Проверить, что всё восстановилось само, без ручных действий.

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

Что контролировать постоянно

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

Что запомнить

  • Для доступности выбирают переключение по отказу, а не балансировку.
  • При переходе меняется внешний адрес — начинать нужно со списка привязок к нему.
  • Критерий переключения — доступность внешних узлов, а не шлюза провайдера.
  • Нужен критерий возврата с задержкой, иначе система будет метаться.
  • Резервный канал контролируют отдельно: иначе о его падении узнают в худший момент.

Полный список того, что стоит держать под наблюдением, — в материале о мониторинге серверов.