виртуальный ip адрес что это

Принцип работы протокола VRRP

FHRP (First Hop Redundancy Protocol) — семейство протоколов, предназначенных для создания избыточности шлюза по умолчанию. Общей идеей для данных протоколов является объединение нескольких маршрутизаторов в один виртуальный маршрутизатор с общим IP адресом. Этот IP адрес будет назначаться на хостах как адрес шлюза по умолчанию. Свободной реализацией данной идеи является протокол VRRP (Virtual Router Redundancy Protocol). В этой статье рассмотрим основы протокола VRRP.

VRRP-маршрутизаторы объединяются в один виртуальный маршрутизатор. Все маршрутизаторы в группе имеют общий виртуальный IP (VIP) адрес и общий номер группы или VRID (Virtual Router Identifier). Один маршрутизатор может состоять в нескольких группах, каждая из которых должна иметь свою уникальную пару VIP/VRID.

В случае с Cisco виртуальный маршрутизатор задается на интересующем нас интерфейсе командой:

Все маршрутизаторы делятся на два типа: VRRP Master и VRRP Backup.

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

VRRP Backup — это маршрутизатор, который ожидает пакет от Master. Если пакеты от Master перестают приходить, Backup пытается перейти в состояние Master.

Маршрутизатор становится Master, если имеет наивысший приоритет. Master постоянно рассылает сообщения на широковещательный адрес 224.0.0.18, чтобы сообщить Backup маршрутизаторам, что он работает. Master отправляет сообщения согласно таймеру Adver Timer, равный по умолчанию 1 секунде.

При этом в качестве MAC адреса отправителя используется адрес группы 00:00:5E:00:01:xx, где xx — VRID в шестнадцатеричном формате. В данном примере используется первая группа.

Если Backup маршрутизаторы не получают сообщения в течении трех Adver Timer (Master Down Timer), то новым Master становится маршрутизатор с наибольшим приоритетом, либо маршрутизатор с наибольшим IP. При этом Backup маршрутизатор с более высоким приоритетом перехватит роль Master с более низким приоритетом. Однако, когда у Backup отключен режим preempt, Backup не станет перехватывать роль у Master.

Если VRRP-маршрутизатор является владельцем VIP адреса, то он всегда перехватывает роль Master.

VRRP приоритет задается в значениях от 1 до 254. Значение 0 зарезервировано для случаев, когда Master необходимо снять с себя ответственность за маршрутизацию. Значение 255 устанавливается маршрутизатору владельцу VIP. Приоритет по умолчанию равен 100, но может задаваться административно:

Здесь мы можем увидеть приоритет маршрутизатора, когда он задан административно:

А тут представлен случай, когда маршрутизатор является владельцем VIP:

VRRP маршрутизатор может иметь три состояния: Initialize, Backup, Master. Эти состояния маршрутизатор последовательное меняет.

В состоянии Initialize маршрутизатор ожидает начала работы. Если этот маршрутизатор является владельцем VIP адреса (приоритет равен 255), то маршрутизатор отправляет сообщения о том что становится Master. Он также отправляет gratuitous ARP-запрос, в котором MAC-адрес источника равен адресу виртуального маршрутизатора. Затем он переходит в состояние Master. Если маршрутизатор не является владельцем VIP, то он переходит в состояние Backup.

В состоянии Backup маршрутизатор ожидает пакеты от Master. Маршрутизатор в этом состоянии не отвечает на ARP-запросы от VIP-адреса. Также он не принимает пакеты, у которых в качестве адреса назначения стоит MAC-адрес виртуального маршрутизатора.

Если Backup не получает сообщения от Master в течение Master Down Timer, то он отправляет VRRP сообщение о том, что собирается стать Master. Затем отправляет широковещательное VRRP сообщение, в котором MAC-адрес источника равен адресу этого виртуального маршрутизатора. В данном сообщении маршрутизатор указывает свой приоритет.

В состоянии Master маршрутизатор обрабатывает пакеты, адресованные виртуальному маршрутизатору. Он так же отвечает на ARP-запросы к VIP. Master рассылает VRRP сообщения каждые Adver Timer, чтобы подтвердить что он работает.

VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами. Для этого на одном интерфейсе создается две VRRP группы. Одной группе назначается больший приоритет, чем другой. При этом на втором маршрутизаторе приоритет задается противоположным образом. Т.е. если на одном маршрутизаторе приоритет первой группы равно 100, а второй группы — 200, то на другом маршрутизаторе приоритет первой группы будет 200, а второй 100.

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

Половине компьютеров назначается один адрес шлюза по умолчанию, половине другой. Таким образом половина трафика будет идти через один маршрутизатор, а половина через другой. При выходе из строя одного из маршрутизаторов, второй перехватывает на себя работу обеих VIP.

Источник

Виртуальный ip адрес что это

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

VRRP (Virtual Router Redundancy Protocol) — сетевой протокол, предназначенный для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию. Это достигается путём объединения группы маршрутизаторов в один виртуальный маршрутизатор и назначения им общего IP-адреса, который и будет использоваться как шлюз по умолчанию для компьютеров в сети.

Содержание

[править] Терминология протокола

[править] Описание протокола

Протокол VRRP предназначен для увеличения доступности маршрутизаторов, выполняющих роль шлюза по умолчанию.

Для группы маршрутизаторов настраивается их принадлежность виртуальному маршрутизатору. Фактически, виртуальный маршрутизатор — это группа интерфейсов маршрутизаторов, которые находятся в одной сети и разделяют Virtual Router Identifier (VRID) и виртуальный IP-адрес.

VRRP-маршрутизатор может находиться в нескольких виртуальных маршрутизаторах, каждый с уникальной комбинацией VRID/IP-адрес. Соответствия между VRID и IP-адресом должны быть одинаковыми на всех маршрутизаторах в одной сети.

В любой момент времени только один из физических маршрутизаторов выполняет маршрутизацию трафика, то есть, становится VRRP Master router, остальные маршрутизаторы в группе становятся VRRP Backup router. Если текущий VRRP Master router становится недоступным, то его роль берет на себя один из VRRP Backup маршрутизаторов — тот, у которого наивысший приоритет. Задание приоритета позволяет определить более приоритетные пути административно.

Backup-маршрутизатор не будет пытаться перехватить на себя роль Master-маршрутизатора, если только у него не более высокий приоритет, чем у текущего Master-маршрутизатора. VRRP позволяет административно запретить перехват роли Master-маршрутизатора. Единственное исключение из этого правила — VRRP-маршрутизатор всегда будет становиться Master, если он владелец IP-адреса, который присвоен виртуальному маршрутизатору.

В каждом виртуальном маршрутизаторе только Master отправляет периодические VRRP-объявления на зарезервированный групповой адрес 224.0.0.18. На канальном уровне в качестве MAC-адреса отправителя VRRP-объявлений используется виртуальный MAC-адрес.

[править] Примеры использования

Первый пример приведён для понимания принципов работы протокола. Как правило, такая схема не используется в реальных сетях.

Два маршрутизатора, R1 и R2, находятся в одном широковещательном сегменте, и на интерфейсах, которые смотрят в локальную сеть, назначены IP-адреса, соответственно 10.0.1.1 и 10.0.1.2. Компьютеры в сети используют в качестве шлюза по умолчанию R1 (обозначен DG на рисунке).

Должен быть определён виртуальный маршрутизатор, который поставит в соответствие уникальному идентификатору (VRID) IP-адрес, для которого один из маршрутизаторов является владельцем. R1 владелец IP-адреса 10.0.1.1, а R2 владелец IP-адреса 10.0.1.2. Для примера определён виртуальный маршрутизатор, для которого VRID = 1, а IP-адрес 10.0.1.1. После включения VRRP на маршрутизаторе R1 для VRID = 1, он берет на себя роль Master. Для него приоритет устанавливается равным 255, так как он является владельцем IP-адреса виртуального маршрутизатора. После включения VRRP на маршрутизаторе R2 для VRID = 1, он становится Backup-маршрутизатором. Для него приоритет устанавливается равным 100, так как он не является владельцем IP-адреса виртуального маршрутизатора.

При таких настройках, если маршрутизатор R1 доступен, все компьютеры передают трафик через R1 (обозначено стрелками на рисунке). Если R1 по каким-либо причинам выходит из строя, то VRRP переводит R2 в роль Master. После этого R2 отвечает за передачу трафика, который отправлен на IP-адрес виртуального маршрутизатора.

В первом примере IP-адрес не резервируется и используется только R2, как IP-адрес интерфейса. Следующий пример показывает как выполнить резервирование и IP-адреса R2.

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

Половина компьютеров использует в качестве шлюза по умолчанию R1, вторая половина — R2. Настройки виртуального маршрутизатора с VRID = 1 остаются точно такими же как в первом примере. Добавляется второй виртуальный маршрутизатор с VRID = 2 и IP-адресом 10.0.1.2. Для этого виртуального маршрутизатора R2 будет выполнять роль Master, а R1 — Backup.

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

Хотя в обоих примерах использовались только два маршрутизатора, маршрутизаторов может быть и больше. Тогда будет один Master и несколько Backup и, при выходе из строя Master-маршрутизатора, приоритет, присвоенный Backup-маршрутизаторам, будет определять, кто из них будет новым Master (если приоритет больше, то маршрутизатор становится Master). Если у маршрутизаторов одинаковые значения приоритетов, то сравниваются их IP-адреса — тот у кого больше IP-адрес, будет Master.

Как правило, IP-адреса компьютерам назначаются с помощью протокола DHCP. Во втором примере DHCP-сервер должен выдавать половине компьютеров в подсети IP-адрес маршрутизатора по умолчанию 10.0.1.1, а другой половине компьютеров — 10.0.1.2. Это можно реализовать с помощью опции 82 DHCP. Идея заключается в том, чтобы выдавать компьютерам, которые подключены к разным коммутаторам, разные значения IP-адреса шлюза по умолчанию.

[править] Формат пакета VRRP

VRRP-пакеты передаются для того, чтобы передать всем VRRP-маршрутизаторам информацию о состоянии и приоритете Master-маршрутизатора, который ассоциирован с VRID.

VRRP-пакеты инкапсулируются в IP-пакеты и отправляются на адрес групповой рассылки, который зарезервирован для VRRP.

[править] Поля IP-пакета

Так как VRRP-пакеты инкапсулируются в IP-пакеты, ниже описаны значения некоторых полей IP-пакета:

[править] Параметры виртуального маршрутизатора

Параметры виртуального маршрутизатора:

[править] Таймеры VRRP

[править] Описание состояний маршрутизаторов

Диаграмма перехода между состояниями:

[править] Initialize

Цель состояния Initialize — ожидание начала работы (Startup event).

Если VRRP включен на маршрутизаторе, то:

[править] Backup

Цель состояния Backup — мониторинг доступности и состояния Master-маршрутизатора.

Когда VRRP-маршрутизатор находится в этом состоянии он должен делать следующее:

[править] Master

В состоянии Master маршрутизатор отвечает за отправку пакетов, отправленных на IP-адрес, ассоциированный с виртуальным маршрутизатором.

Когда VRRP-маршрутизатор находится в этом состоянии, он должен делать следующее:

Источник

?Обсуждения

Виртуальные IP-адреса

Оба, IKE-v1 и IKE-v2, понимают концепцию виртуальных IP-адресов. Это означает, что инициатор соединения на подключение выполняет запрос на получение дополнительного IP-адреса от пира для того, чтобы воспользоваться им как внутренним IP-адресом, внутри туннеля IPsec.

В IKE-v1 обмен назначением виртуальных IP-адресов происходит при помощи дополнительного режима настройки, а IKE-v2 уже имеет полноценную поддержку виртуальных IP-адресов в основе IKE-v2-стандарта при помощи полезной нагрузки (payload), содержащей информацию о настройках.

strongSwan в настоящее время поддерживает только один сценарий с полезной нагрузкой (payload), которая в себе содержит информацию о настройках, где IP-адрес назначается инициатору соединения на подключение, то есть roadwarrior’у (начиная с версии stongSWAN 5.0.1, уже можно назначать несколько IP-адресов из нескольких пулов). Обратное поддерживается протоколом, но такая ситуация случается крайне редко и, следовательно, не поддерживается.

Настройка инициатора (клиента)

Клиенту потребуется внести в свой клиентский «ipsec.conf» дополнительный параметр, называемый «leftsourceip»

Под «%config» подразумевается выполнение запроса на получение IP-адреса от ответчика (VPN-сервера), «%config» представляет собой алиас для «%modecfg», доступного только для IKE-v1. Но можно также и указать IP-адрес явно ручками:

Этот параметр настройки включит IP-адрес «10.3.0.5» в payload-запрос, который содержит информацию о настройках. Однако, пир с обратной стороны (VPN-сервер) может вернуть другой IP-адрес, или может вернуть ни одного IP-адреса.

Начиная с версии strongSWAN 5.0.1, VPN-клиент может запросить несколько IP-адресов, перечисляя в «leftsourceip» через запятую сочетание «%config4», «%config6» или фиксированные IP-адреса. Если указывается «%config» (или один из его алиасов), то будет запрашиваться IP-адрес, входящий в семейство IP-протокола для туннеля, то есть будет запрашиваться IP-v4 или IP-v6. Обычный случай использования запроса виртуального IP-адреса из каждого семейства IP-протокола для dualstack-хостов:

Параметр настройки «leftsubnet» не должен указываться при запросе виртуального IP-адреса, так как подсеть может не совпадать с полученный IP-адресом от VPN-сервера. Без параметра настройки «leftsubnet» подсеть сужается до назначенного VPN-сервером виртуального IP-адреса автоматически.

Настройка DNS-серверов

Настройка ответчика (сервера)

Настройка ответчика использует параметр настройки «rightsourceip»

Это будет выдавать клиенту IP-адрес 10.3.0.6, даже если инициатор запрашивал другой IP-адрес. Кроме того, ответчик может указать:

для того, чтобы позволить клиенту выбирать IP-адреса по желанию. Это не рекомендуется в том случае, если вы не доверяете полностью VPN-клиенту.

Вы можете указать пул IP-адресов в нотации CIDR, т.н.

для выдачи IP-адресов из этого пула.

Вы также можете использовать внешний пул IP-адресов, при помощи реализации в виде плагина, где вы можете назначать имена пулам IP-адресов для того, чтобы их выбирать. Указание

делает запрос при помощи зарегистрированных (то есть подключенных и рабочих) плагинов на получение IP-адреса из пула под именем «poolname». Также можно подставить имя другого подключения (раздела conn) в «ipsec.conf», в котором ранее уже определён пул в нотации CIDR для параметра «rightsourceip», и первый пул под именем этого подключения создастся неявно. Начиная с версии strongSWAN 5.0.1, несколько подключений (разделов conn) могут неявно создавать один и тот же пул в том случае, если эти подключения используют одни и те же значения параметра «rightsourceip» (ранее каждое подключение использовало свою собственную копию и везде, в каждом разделе conn, был указан один и тот же виртуальный IP-адрес, который раздавался разным VPN-клиентам).

Множество пулов можно указывать списком в значении параметра «rightsourceip» начиная с версии strongSWAN 5.0.1, т.н.

Настройка DNS-серверов

DNS-серверы и различные остальные атрибуты могут назначаться при помощи плагинов (т.н. плагином «attr») или, начиная с версии strongSWAN 5.0.1, напрямую в «ipsec.conf» при помощи добавления параметра настройки «rightdns»

База данных на backend

The ipsec pool utility allows to easily manage IP address pools and other attributes, like DNS servers, stored in an SQL database using the attr-sql plugin.

DHCP на backend

При помощи плагина «dhcp», ответчик (VPN-сервер) может запрашивать виртуальные IP-адреса для инициаторов (VPN-клиентов) прямо от DHCP-сервера при помощи широковещательных пакетов (broadcast), или от конкретно указанного DHCP-сервера.

Информация про сервера DNS/WINS дополнительно выдаётся VPN-клиентам в том случае, если DHCP-сервер предоставляет такую информацию.

Плагин используется в настройке «ipsec.conf» при помощи указания значения

При использовании плагина «dhcp» можно также использовать плагин «farp». Использование плагина «farp» позволит ответчику (VPN-серверу) подделать ответные ARP-пакеты от виртуальных IP-адресов, выданных VPN-клиентам. Это позволяет roadwarrior’у взаимодействовать с локальной сетью VPN-сервера как полноценный клиент локальной сети (LAN), в которой находится VPN-сервер.

RADIUS на backend

Since 5.0.3 the RADIUS plugin can provide virtual IP addresses assigned to RADIUS clients via the Framed-IP-Address attribute.

Версии strongSWAN до 5.0.0

The description above covers the features of the charon daemon, which handled only IKEv2 connections in earlier releases. The pluto daemon that handled IKEv1 connections provided a similar feature set but not everything was supported (for instance, the dhcp and farp plugins).

The pluto daemon did not request virtual IP addresses from the responder if they were explicitly configured with leftsourceip. In that case, that is, if the virtual IP was not assigned by the responder with rightsourceip one may had to use the rightsubnetwithin directive (refer to this example).

The IKEv2 daemon charon supports address pools since version 4.2.1, the IKEv1 daemon pluto gained support for this in 4.4.0.

Источник

Использование виртуальных IP-адресов: где предел?

Виртуальная IP-адресация — функция исключительно удобная, как для сетевых, так и для серверных администраторов. Однако где лежит предел ее возможностей? В своей статье ИТ-специалист Рик Вановер (Rick Vanover) обращает внимание на некоторые недостатки этой технологии.

Виртуальная IP-адресация (VIP) позволяет обеспечить соответствие требованиям доступности, рабочей нагрузки и аварийного восстановления во многих ситуациях, однако не может считаться универсальным решением. В прошлом году я уже писал о проблемах, связанных с делегированием разрешений на включение или отключение VIP-узла. В этом году я столкнулся с другой трудностью: использование VIP-адресов в приложениях. И речь идет не только о простых программах типа веб-сервисов на нескольких серверах, пользующихся одной базой данных.

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

Другое ограничение на использование VIP-адресов налагает схема применения DNS. Очень часто я использую VIP-адресацию для записей хоста (A) и псевдонима (CNAME). Этот подход проиллюстрирован на рис. A.

При этом клиенты видят и используют только CNAME — webservice.rwvdev.tld, — не подозревая о существовании VIP-адреса. Это создает условия для быстрого перенаправления рабочей нагрузки в том случае, если с VIP-адресацией возникают какие-то проблемы: CNAME заменяется непосредственно на полное допустимое доменное имя хоста. Однако такая конфигурация тоже затрудняет обслуживание и ограничивает функциональность некоторых приложений.

В общем, мы любим VIP-адресацию, но использовать ее во всех ситуациях без исключения, к сожалению, невозможно. Все зависит от приложения. Мне очень интересно было бы узнать, как вы подходите к этой проблеме и как разрешаете всевозможные трудности, связанные с использованием VIP. Высказывайте свое мнение в комментариях!

Автор: Rick Vanover
Перевод: SVET

Оцените статью: Голосов

Источник

Keepalived: настройка высокой доступности и плавающих IP адресов в CentOS 7

В этой статье мы рассмотрим настройку отказоустойчивой конфигурации из двух прокси серверов squid для доступа пользователей в Интернет из корпоративной сети с простой балансировкой нагрузки через Round Robin DNS. Для построения отказоустойчивой конфигурации мы создадим HA-кластер с помощью keepalived.

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

Обе эти задачи позволяет выполнить keepalived. Keepalived – системный демон на Linux системах, позволяющего организовать отказоустойчивость сервиса и балансировку нагрузки. Отказоустойчивость достигается за счет “плавающего» IP адреса, который переключается на резервный сервер в случае отказа основного. Для автоматического переключения IP адреса между серверами keepalived используется протокол VRRP (Virtual Router Redundancy Protocol), он стандартизирован, описан в RFC (https://www.ietf.org/rfc/rfc2338.txt).

Принципы работы протокола VRRP

В первую очередь нужно рассмотреть теорию и основные определения протокола VRRP.

Общий алгоритм работы:

Установка и настройка keepalived на CentOS

Установку и настройку будем проводить на примере серверов proxy-serv01 и proxy-serv02 на Centos 7 с установленным Squid. В нашей схеме мы будем использовать простейший способ распределения (балансировки) нагрузки — Round Robin DNS. Этот способ предполагает, что для одного имени в DNS регистрируется несколько IP адресов, и клиенты, при запросе получают поочередно сначала один адрес, потом другой. Поэтому нам понадобится два виртуальных IP адреса, которые будут зарегистрированы в DNS на одно имя и на которые в итоге будут обращаться клиенты. Схема сети:

У каждого Linux сервера есть два физических сетевых интерфейса: eth1 с белым IP адресом и доступом в Интернет, и eth0 в локальной сети.

В качестве реальных IP адресов серверов используются:
192.168.2.251 — для proxy-server01
192.168.2.252 — для proxy-server02

В качестве виртуальных IP адресов, которые будут автоматически переключаться между серверами в случае сбоев используются:
192.168.2.101
192.168.2.102

Установить пакет keepalived нужно на обоих серверах, командой:

yum install keepalived

После завершения установки на обоих серверах правим конфигурационный файл

Цветом выделены строки с отличающимися параметрами:

на сервере proxy-serv01	на сервере proxy-serv02

Разберем опции более подробно:

Если текущая сетевая конфигурация не позволяет использовать multicast, в keepalived есть возможность использовать unicast, т.е. передавать VRRP пакеты напрямую серверам, которые задаются списком. Чтобы использовать unicast, понадобятся опции:

Таким образом, наша конфигурация определяет два VRRP экземпляра, proxy_ip1 и proxy_ip2. При штатной работе, сервер proxy-serv01 будет MASTER для виртуального IP 192.168.2.101 и BACKUP для 192.168.2.102, а сервер proxy-serv02 наоборот, будет MASTER для виртуального IP 192.168.2.102, и BACKUP для 192.168.2.101.

Если на сервере активирован файрвол, то нужно добавить разрешающие правила для multicast траффика и vrrp протокола с помощью iptables:

Активируем автозагрузки и запустим службу keepalived на обоих серверах:

systemctl enable keepalived
systemctl start keepalived

После запуска службы keepalived, виртуальные IP будут присвоены интерфейсам из конфигурационного файла. Посмотрим текущие IP адреса на интерфейсе eth0 серверов:

На сервере proxy-serv01:

На сервере proxy-serv02:

Keepalived: отслеживание состояния приложений и интерфейсов

Благодаря протоколу VRRP штатно обеспечивается мониторинг состояния сервера, например, при полном физическом отказе сервера, или сетевого порта на сервере или коммутаторе. Однако, возможны и другие проблемные ситуации:

Для обработки перечисленных выше ситуаций, воспользуемся следующими опциями:

Обновим конфигурацию, добавим мониторинг интерфейса eth1 (по умолчанию, VRRP экземпляр будет проверять интерфейс, к которому он привязан, т.е. в текущей конфигурации eth0):

Директива track_script запускает скрипт с параметрами, определенными в блоке vrrp_script, который имеет следующий формат:

Настроим мониторинг работы Squid. Проверить, что процесс активен, можно командой:

Создадим vrrp_script, с параметрами периодичности выполнения каждые 3 секунды. Этот блок определяется за пределами блоков vrrp_instance.

Добавим наш скрипт в мониторинг, внутри обоих блоков vrrp_instance:

Теперь при ошибке в работе службы прокси Squid, виртуальный IP адрес переключится на другой сервер.

Вы можете добавить дополнительные действия при изменении состояния сервера.

Если Squid настроен на прием подключений с любого интерфейса, т.е. http_port 0.0.0.0:3128, то при переключении виртуального IP адреса, никаких проблем не возникнет, Squid будет принимать подключения на новом адресе. Но, если настроены конкретные IP адреса, например:

то Squid не узнает о том, что в системе появился новый адрес, на котором нужно слушать запросы от клиентов. Для обработки подобных ситуаций, когда нужно выполнить дополнительные действия при переключении виртуального IP адреса, в keepalived заложена возможность выполнения скрипта при наступлении события изменения состояния сервера, например, с MASTER на BACKUP, или наоборот. Реализуется опцией:

Keepalived: тестирование переключения при отказе

После настройки виртуальных IP, проверим, насколько корректно происходит обработка сбоев. Первая проверка — имитация сбоя одного из серверов. Отключим от сети внутренний сетевой интерфейс eth0 сервера proxy-serv01, при этом он перестанет отправлять VRRP пакеты и сервер proxy-serv02 должен активировать у себя виртуальный IP адрес 192.168.2.101. Результат проверим командой:

На сервере proxy-serv01:

На сервере proxy-serv02:

Как и ожидалось, сервер proxy-serv02 активировал у себя виртуальный IP адрес 192.168.2.101. Посмотрим, что при этом происходило в логах, командой:

И проверим, что после включения в сеть интерфейса eth0 на сервере proxy-serv01, виртуальный IP 192.168.2.101 переключится обратно.

Вторая проверка – имитация сбоя интерфейса внешний сети, для этого отключим от сети внешний сетевой интерфейс eth1 сервера proxy-serv01. Результат проверки проконтролируем по логам.

Третья проверка — имитация сбоя работы службы прокси Squid, для этого вручную оставим службу командой: systemctl stop squid Результат проверки проконтролируем по логам.

Все три проверки пройдены успешно, keepalived настроен корректно. В продолжении этой статьи будет произведена настройка HA-кластера с помощью Pacemaker, и рассмотрена специфика каждого из этих инструментов.

Источник