Виртуальный IP-адрес (VIP, Virtual IP) — IP-адрес, который может быть назначен любому из нескольких физических или виртуальных узлов сети. Используется в двух основных сценариях: высокодоступные кластеры (HA) и балансировщики нагрузки. Клиенты обращаются на VIP и не знают, какой конкретно сервер обрабатывает запрос.
Как работает
В HA-кластере VIP управляется программным обеспечением типа Keepalived, Pacemaker или Corosync. Активный узел «держит» VIP на своём интерфейсе. При обнаружении отказа (health check не прошёл) резервный узел через VRRP (Virtual Router Redundancy Protocol, RFC 5798) или CARP объявляет себя владельцем VIP и посылает gratuitous ARP — сообщение всем устройствам сети «теперь VIP на моём MAC». Коммутаторы обновляют ARP-таблицы, и трафик переходит на новый узел за 1-3 секунды.
Протокол VRRP (RFC 5798) описывает: один Master-маршрутизатор владеет VIP, один или несколько Backup-маршрутизаторов мониторят его через VRRP-объявления (multicast 224.0.0.18). Priority 0-255 определяет порядок выборов. Keepalived — самый распространённый daemon VRRP для Linux.
В балансировщиках нагрузки (HAProxy, nginx, AWS ELB) VIP — адрес, на который приходит трафик от пользователей, а балансировщик распределяет соединения между бэкенд-серверами. Бэкенды используют реальные IP, клиенты видят только VIP.
История
Концепция floating IP / virtual IP возникла одновременно с появлением HA-решений в конце 1980-х. VRRP стандартизован в RFC 2338 (1998), актуальная версия — RFC 5798 (2010). CARP (Common Address Redundancy Protocol) разработан проектом OpenBSD в 2003 году как свободная альтернатива HSRP (Cisco) и VRRP. В облачных платформах виртуальный IP реализован через API: floating IP в OpenStack, Elastic IP в AWS.
VIP в хостинге
Ряд хостинг-провайдеров предлагает floating IP как отдельную услугу: статический IP-адрес, который клиент может перевесить с одного сервера на другой через API или панель управления. Это применяется для:
- Переезда между серверами без смены IP (и без изменения DNS).
- Blue-green deployment: переключение с одной версии сервиса на другую за секунды.
- Аварийного переключения при отказе сервера.
В Kubernetes VIP реализован через MetalLB (для bare metal) или cloud LoadBalancer-контроллеры. Ingress-контроллер получает VIP из пула и направляет трафик в нужные pod-ы.
На что обращать внимание
Переключение VIP занимает 1-5 секунд — в это время соединения прерываются. Для приложений с длинными TCP-сессиями это критично. Решение — connection draining: плавный вывод из ротации с ожиданием завершения активных сессий. Время propagation gratuitous ARP зависит от коммутационного оборудования: на некоторых устройствах ARP-кэш обновляется медленнее. Убедитесь, что VLAN и файрвол позволяют VRRP-трафик (multicast 224.0.0.18, протокол 112).
Типичные ошибки при настройке VIP
Первая ошибка — не настроить arp_announce и arp_ignore на Linux при использовании балансировщика нагрузки в режиме DR (Direct Routing): без этих параметров ARP-ответы будут некорректными. Установите net.ipv4.conf.all.arp_ignore=1 и arp_announce=2. Вторая ошибка — неправильное время failover: VRRP по умолчанию переключается за 3 секунды, что приемлемо, но при использовании keepalived можно снизить до 1 секунды через advert_int 0.1. Третья — игнорировать брандмауэр: VRRP-трафик должен быть разрешён для multicast-адреса 224.0.0.18.