OpenVZ, Quagga и LiveMigration

Добрый всем день!
Хочу поделиться удобным способом использования OpenVZ контейнеров. Объект этот очень лёгкий, можно поднимать экземпляр на каждый чих.
По умолчанию для контейнера используется «venet» сетевой интерфейс. Для администратора это выглядит, как просто присвоить контейнеру адрес, и это удобно. Но для того, чтоб контейнер был доступен из сети, следует использовать адреса из той же IP сети, к которой подключён физический сервер (HN). Сервер знает список запущенных на нём контейнеров и отвечает своим MAC-ом на ARP запросы с адресами контейнеров. Но всегда хочется больше удобства в работе, и поможет нам в этом динамическая маршрутизация.
Как именно рассмотрим на примерах, используя Quagga и OSPF.

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

во-первых, необходимо установить на сервер Quagga:

тут всё просто, Quagga входит в стандартную поставку почти всех дистрибутивов,
здесь и далее команды для debian based:

#sudo apt-get install quagga

во-вторых, произвести минимальную настройку и запустить:

в файле /etc/quagga/daemons исправить строчки (с «no» на «yes»):

zebra=yes
ospfd=yes

создать файл /etc/quagga/zebra.conf

ip forwarding
line vty

создать файл /etc/quagga/ospfd.conf

router ospf
 redistribute kernel
 network 0.0.0.0/0 area 0.0.0.0
line vty

перезапустить:

#sudo service quagga restart

с такими настройками HN будет искать маршрутизаторы на всех интерфейсах и рассказывать им о всех своих запущеных контейнерах.

проверим, Quagga подключилась к сети и информация о контейнерах распространяется:

# vtysh -e "show ip ospf nei" 

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
198.51.100.11    128 Full/DR            2.548s 192.0.2.25   vmbr0:192.0.2.26      0     0     0
192.0.2.27         1 2-Way/DROther      2.761s 192.0.2.27   vmbr0:192.0.2.26      0     0     0
192.0.2.28         1 Full/Backup        2.761s 192.0.2.28   vmbr0:192.0.2.26      0     0     0

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

# vzlist
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
       100         38 running   -               radius.local
       101         26 running   198.51.100.2    dns.local
       104         47 running   203.0.113.4     cacti.local
       105         56 running   203.0.113.5     host3.local
       152         22 running   203.0.113.52    host4.local
       249         96 running   203.0.113.149   zabbix.local

# vtysh -e "show ip ospf database external self-originate" | fgrep Link\ State\ ID
  Link State ID: 198.51.100.2 (External Network Number)
  Link State ID: 192.168.98.4 (External Network Number)
  Link State ID: 192.168.98.5 (External Network Number)
  Link State ID: 192.168.98.52 (External Network Number)
  Link State ID: 192.168.98.149 (External Network Number)

получаем два списка с IP адрессами, которые должны совпадать.

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

Теперь немного дополним конфигурацию Quagga:

благодаря этим строчкам, информация будет обновляться быстрее, но нужно соответствующим образом настроить также интерфейсы на маршрутизиторе.
файл /etc/quagga/ospfd.conf:

...
interface vmbr0
  ip ospf hello-interval 1
  ip ospf dead-interval 3
...

Информация о контейнерах с адресами из сети в которой находится сервер — не будет распространяться. Действительно, про эту сеть и так всем известно, зачем забивать таблицу маршрутизации лишними записями.
файл /etc/quagga/ospfd.conf:

...
ip prefix-list ifvmbr0 seq 100 permit 192.0.2.0/24 le 32
router ospf
  redistribute kernel route-map openvz
route-map openvz deny 100
  match ip address prefix-list ifvmbr0
route-map openvz permit 200
...

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

1. Live Migration, можно без простоя и разрыва соединений переносить контейнеры между серверами в разных сетях и на разных площадках.
2. Можно реализовать горячий резерв, когда «запасной» контейнер с таким же адресом находится на другом сервере и анонсируется с большей метрикой.
3. Anycast, аналогично предыдущему пункту, контейнеры на разных серверах в разных точках присутствия, у контейнеров одинаковые адреса которые анонсируются с metric-type 1. Тогда трафик пойдёт на «ближайший» адрес (DHCP/RADIUS/IPTV/Proxy и т.д.)

P.S.

• С Proxmox — тоже работает замечательно, только если собираете кластер на туннелях, то интерфейсы туннелей надо вывести из OSPF или поднять метрики, а то есть риск что по тунелям побежит пользовательский трафик.
  
• Может возникнуть вопрос, что тут вообще нового, уже давно ставят Quagga на сервера, но преимущество в том, что демон не нужно устанавливать внутрь каждого контейнера, а только на хостовую машину, на которой могут работать многие десятки контейнеров.
• Не рекомендую использовать для этих целей OSPF NSSA area, есть тонкости в том, как квага генерирует LSA7 для таких маршрутов, так что, скорее всего не заработает.

P.P.S./upd Недопустимо использовать эту схему, если сетью и серверами занимаются разные команды. Это скорее некий очень удобный «хак» для администраторов которые занимаются и первым и вторым.