הגדרת IP צף ו-IP וירטואלי לעמידות בפני תקלות

Floating IP настройка: где сеть теряет доступность

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

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

Floating IP настройка снимает проблему тем, что адрес перестаёт принадлежать конкретной машине. Keepalived держит виртуальный адрес на ведущем узле, следит за состоянием сервиса и при отказе узла переносит адрес на резервный — без правки DNS и без ожидания кэшей. Детали, которые определяют результат: проверка должна смотреть на сам сервис, а не на отзывчивость интерфейса; резервный узел обязан корректно объявлять адрес в сети, иначе трафик уйдёт в никуда; при разделении сети возможны два ведущих узла одновременно, поэтому нужен кворум или внешний арбитр.

Дальше разбираем, как это закрывается на практике.

Что даёт отказоустойчивая адресация сервиса

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

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

Главный эффект — уходит целый класс отказов, связанный с ручным переносом адреса. Ошибка в записи, забытая конфигурация на резервном узле, разные сроки обновления на разных серверах — всё это перестаёт быть источником аварий. Адресом управляет автоматика по одному набору правил, а не дежурный по памяти и в спешке.

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

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

Режимы отказоустойчивости адресов: сравнение схем

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

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

Этапы внедрения отказоустойчивой адресации

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

1. Аудит сети. Собираем карту сегментов, шлюзов и маршрутов, смотрим, где адреса выдаются статически, а где автоматически, ищем пересечения подсетей. На выходе — перечень свободных адресов и тех, что уже закреплены за оборудованием.
2. Схема адресации. Размечаем роли: какой адрес обслуживает приложение, какой остаётся служебным, какой держим резервным, и кто владелец каждого. Схема снимает главный риск — двойное владение адресом, когда оба узла считают себя активными.
3. Настройка переключения. Задаём проверки доступности, приоритеты узлов и время, за которое адрес переезжает. Отдельно прописываем поведение при частичном отказе — узел отвечает, а приложение на нём уже нет.
4. Проверка под нагрузкой. Прогоняем не только остановку узла, но и обрыв канала, потерю связи между узлами и плановый перезапуск. Смотрим, сколько занимает переезд адреса и рвутся ли при этом живые соединения.
5. Передача в эксплуатацию. Отдаём схему адресов, конфигурации, порядок ручного переключения и правила возврата адреса на основной узел. Дежурная смена получает не «чёрный ящик», а понятную процедуру.

Порядок одинаков для облачной площадки и собственного оборудования — меняется только то, где физически живёт адрес. Перед вводом в работу прогоняем сценарии отказа повторно, уже на боевом контуре.

Политики адресации и конфигурации в инфраструктуре

Отказоустойчивость держится не на самом факте наличия второго адреса, а на том, воспроизводима ли его конфигурация. Мы фиксируем каждый элемент так, чтобы переключение не зависело от того, кто из инженеров в этот момент на дежурстве. Комплект уходит в ваш репозиторий и остаётся рабочим при добавлении новых узлов и зон.

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

Комплект пересматривается на плановых учениях: если переключение не укладывается в согласованное время, правим конфигурацию, а не инструкцию.

Переключение адреса между узлами: результаты до и после

Сервис на двух узлах за балансировщиком: до настройки плавающего адреса отказ любой машины означал ручное вмешательство. Адрес оставался на недоступном узле, запросы клиентов завершались ошибками, дежурный менял запись DNS и ждал обновления кэшей у резолверов. О сбое чаще узнавали от пользователей, а не из мониторинга.

Как было до внедрения

Время восстановления доступа — 9–14 минут на инцидент: около минуты на само переключение и остальное на ожидание кэшей. Активные соединения при отказе терялись полностью, длительные сессии приходилось начинать заново. Проверку на отказ проводили редко, поэтому реальный сценарий переключения оставался непроверенным до первого серьёзного сбоя.

Что стало после

Плавающий адрес закрепили на паре узлов и связали с проверкой прикладного состояния через keepalived: пока узел отвечает на служебный запрос, адрес остаётся на нём, а таблица соединений синхронизируется между машинами. При отказе адрес переходит на резервный узел за 3–5 секунд, удержанные соединения переживают переключение, доля запросов с ошибкой в этот момент — ниже 0,5%.

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

Чем Floating IP отличается от Virtual IP?

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

Отсюда расходятся сценарии применения. Floating IP берут там, где нужна публичная входная точка: внешний балансировщик, обратный прокси, узел для администрирования — адрес перепривязывается к резервному экземпляру, и клиенты не замечают смены. Virtual IP ставят внутри: отказоустойчивый шлюз, пара серверов базы данных, кластер приложений, где важен один адрес для группы узлов и переключение за секунды.

Различаются и требования к сети. Floating IP опирается на возможности платформы перенаправить трафик на другой узел, поэтому критичны границы подсети, корректная работа маршрутизации и отсутствие жёстких привязок к адресу на стороне firewall. Virtual IP требует, чтобы узлы были соседями в одном широковещательном домене: нужен разрешённый обмен служебными пакетами выбора лидера, свободная передача ARP и возможность узла отвечать на чужой адрес. В облачных сетях эти условия выполняются не всегда — тогда остаётся Floating IP либо управляемый балансировщик.

На этапе проектирования мы проверяем три вещи: где физическая точка отказа — у провайдера или в кластере, кто удерживает адрес в момент аварии и сколько длится переключение, и как ведёт себя состояние сессий после смены узла. Сплошь и рядом выбирают комбинацию: Virtual IP внутри для быстрого переключения, Floating IP или балансировщик снаружи для публичного доступа. Дальше разбираем, как это собирается под конкретную схему.

Технические вопросы по настройке и эксплуатации

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

Можно ли обойтись без второго узла?

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

Как проверить переключение под нагрузкой?

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

Кто управляет адресом во время эксплуатации?

Привязку держим в описании инфраструктуры, а не в панели провайдера: тогда адрес воспроизводимо переезжает при пересоздании узла, а смена владельца не зависит от ручных действий дежурного.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы вернуться с оценкой работ, нам нужно понять топологию: где сейчас точка отказа, кто удерживает адрес и как сервисы узнают о переключении. Floating IP настройка почти всегда упирается не в сам адрес, а в поведение прикладного слоя после смены узла. На первом разговоре разбираем это — и уже на его основе отдаём план внедрения с составом работ и сроками.

Обсудим задачу — на встрече уточняем:

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

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