Сохранение состояние системы отслеживания при сбоях#

Обзор реализации#

Система отслеживания соединений, как и вся система Netfilter, находятся в ядре ОС, в контролируемой им области оперативной памяти хранится и актуальная информация о соединениях. Само ядро не занимается резервированием, но оно предоставляет средства для загрузки и выгрузки информации о соединениях «на лету», после чего остаётся только передавать эту информацию между системами кластера. Этой деятельностью вне ядра занимается служба conntrackd. В рамках конфигурации Numa Edge эта служба доступна как conntrack-sync, а кластерное ПО работает с ней через через агент conntrack-failover, реализованный в соответствии со стандартом LSB.

Упрощённо архитектура системы отслеживания соединений представлена на рисунке:

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

Ограничения текущей реализации#

Из-за использования одних и тех же механизмов, но для разных целей, в общем случае нельзя одновременно управлять сохранением состояния соединений и использовать распараллеливание трафика по нескольким исходящим интерфейсам для «размазывания» нагрузки на каналы (WAN load balancing). В частности, очистка буферов в рамках управления или настройки системы отслеживания соединений вызовет сбой в работе системы распараллеливания трафика, которой учёт соединений нужен для выяснения фактической загруженности конкретного интерфейса (и, как следствие, канала, к которому этот интерфейс подключён).

Пример настройки#

Для сохранения информации о соединениях службу conntrack-sync необходимо настроить и запустить в каждой системе, которую предполагается использовать для поддержки сохранения состояния соединений.

Ниже приведён пример настройки conntrack-sync для самостоятельной работы:

Учитывать соединения через loopback интерфейс вряд ли необходимо, поэтому добавляем связанный с ним адрес в список игнорируемых:
1 2
[edit] admin@edge# set service conntrack-sync address-ignore ipv4 127.0.0.1
Эта сеть входит в общепринятый перечень сетей, выделенных для многоадресного вещания. Один адрес из неё используется в этом примере для общения служб conntrack-sync между собой, а следить за этими соединениями тоже необязательно:
1 2
[edit] admin@edge# set service conntrack-sync address-ignore ipv4 226.0.0.0/24
Задаём размер буфера (в байтах) для сообщений, которые conntrackd будет получать от системы отслеживания соединений ядра:
1 2
[edit] admin@edge# set service conntrack-sync event-listen-queue-size 16777216
Задаём сетевой интерфейс, через который службы conntrack-sync из разных систем будут обмениваться информацией о соединениях. Все такие интерфейсы должны быть включены в одну сеть:
1 2
[edit] admin@edge# set service conntrack-sync interface eth2
Задаём адрес назначения (идентификатор группы) для многоадресного вещания:
1 2
[edit] admin@edge# set service conntrack-sync mcast-group 226.0.0.50
Задаём размер приёмных и передающих буферов (в байтах), использующихся в обмене информацией о соединениях с другими службами conntrack-sync:
1 2
[edit] admin@edge# set service conntrack-sync sync-queue-size 2097152

Смотрим, что получилось:

[edit]
admin@edge# show service conntrack-sync
  +address-ignore {
  +    ipv4 127.0.0.1
  +    ipv4 226.0.0.0/24
  +}
  +event-listen-queue-size 16777216
  +interface eth2
  +mcast-group 226.0.0.50
  +sync-queue-size 2097152

[edit]

admin@edge01#

Применение конфигурации:

1
2
3

[edit]
admin@edge# commit
Starting conntrack-sync...

При работе служб conntrack-sync данные о соединениях не применяются автоматически ведомой службой (например, через какой-то период времени), а только хранятся в её внешнем буфере. То есть нужно предпринимать какие-то дополнительные шаги для автоматизации этого процесса в контексте изменения внешних условий.

Примечание

Служба conntrack-sync сама по себе не отслеживает состояния соединений. Для отслеживания состояния соединений и их последующей синхронизации необходимо настроить правила фильтрации, основанные на состоянии соединений, либо правила трансляции сетевых адресов.

Система отслеживания соединений#

Система отслеживания соединений является частью системы Netfilter, входящей в ядро, другими частями которой также являются системы фильтрации сетевых пакетов и преобразования сетевых адресов. Потребность в отслеживании соединений возникла из потребности принимать решения о фильтрации или преобразовании на основании не только данных из конкретного сетевого пакета, но и данных из предыдущих пакетов, как-то связанных с текущим. Олицетворением такой связи выбрана абстракция «соединение». К абстракциям с аналогичным названием в сетевых протоколах она прямого отношения не имеет, это только внутреннее представление ядром системы истории обмена пакетами между сетевыми узлами.

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

NEW: новое соединение; полученный пакет является стартовым по правилам своего сетевого протокола и пакетный фильтр ещё не обнаружил ответного трафика, связанного с этим пакетом и участниками обмена, в рамках которого получен этот пакет;
ESTABLISHED: установившееся соединение; соединение считается установившимся (установленным) когда пакетный фильтр обнаруживает ответный трафик, связанный с ранее обнаруженным исходным трафиком;
RELATED: связанное соединение; для соединений с таким состоянием нужно учитывать ещё какое-то соединение, обмен в рамках которого и инициировал рассматриваемое (RELATED) соединение; хорошим примером соединения в состоянии RELATED является соединение для обмена данными (не управляющее) в пассивном режиме FTP;
INVALID: ошибочное состояние; в рамках текущего соединения получены пакеты не того вида, который ожидался в данный момент по правилам выявленного в данном соединении протокола обмена.

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

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

В результате, в случае потери информации о соединениях на маршрутизаторе, установленном на границе сети, участникам обмена по обеим сторонам от него возможно (в зависимости от конфигурации пакетного фильтра и преобразователя адресов) придётся заново устанавливать соединения между собой.

При помощи устройств Numa Edge этой потери можно избежать благодаря использованию установленного в них инструментария conntrack-tools и организации кластера.