Как скрестить новое со старым.

В своей статье "Прошлое нужно переосмысливать" описал проблему раннего старта сетевых демонов на примере Ceph ДО фактического создания сложной сетевой конфигурации. Вывод статьи был прост: отказ от древнего наследия в виде ifupdown скриптов и файла /etc/network/interfaces и полный переход на новую систему инициализации systemd, средствами которой создаётся сетевая конфигурация и гарантируется цель network-online.target. Так как в те времена это мне нужно было только в кластере Ceph, то проблема решилась полным переходом сетевых настроек на systemd, но, спустя годы, с коллегами решили трансформировать нашу текущую схему виртуализации в Hyper-converged Infrastructure, когда у нас не будет разделения на сервера-ноды Proxmox VE (compute) и на ноды Ceph (storage), а всем занимаются ноды Proxmox VE (compute + storage). Проект Proxmox VE сам на своих нодах развернёт актуальную версию Ceph и позволит в GUI и CLI решить все вопросы: от создания и запуска виртуальной машины до создания и управления всеми аспектами Ceph как shared storage для хранения "виртуальных жёстких дисков виртуальных машин". Но было одно НО! Сетевую конфигурацию для Proxmox VE делал через проект Open vSwitch, который официально заявляет об отсутствии интеграции с systemd (по-крайней мере пока). И встала задача усидеть на двух стульях: нужно и не отказываться от Open vSwitch и гарантировать куче сетевых сервисов Proxmox VE и Ceph их старт после реально настроенной сети.

Более подробно суть проблемы в статье Прошлое нужно переосмысливать.

Текущая и будущая схема

Схематично наша текущая схема с раздельными кластерами Proxmox VE (compute) и кластером Ceph (shared storage) выглядит так.

Shared storage позволяет виртуальной машине в режиме online, не прерывая работу, переместиться с одного физического сервера на другой.

В будущей схеме Hyper-converged Infrastructure (HCI) совмещаются роли compute (занятая виртуальными машинами CPU и RAM) и storage (HDD и SSD), что позволяет:

• получить простоту - лёгкость конфигурирования и централизованное управление множеством компонент проекта.
• улучшить масштабирование - легко и просто расширить кластер за счёт новых физических серверов-нод и сразу получать новые вычислительные, сетевые и ресурсы хранения. Кластер легко и просто расширяется горизонтально за счёт новых серверов и вертикально, получая общий прирост за счёт новых дисков, памяти, процессоров и т.д.
• уменьшить цену всего решения - Proxmox VE, как open source решение уровня предприятия, сам полностью утилизирует данные ему ресурсы CPU, RAM, storage, network, даст центр управления и механизм создания резервных копий. Он заменит дорогую и раздельную инфраструктуру compute/storage.
• защита данных и эффективность. Ceph, под капотом Proxmox VE, даст вам хранилище, которое не только shared storage, но и устойчивое к катастрофам. Благодаря надёжности через избыточность, ничто не хранится так, чтобы поломалось при выходе из строя диска, сервера и т.д. На изображении ниже схематично представлено, как виртуальный жёсткий диск конкретной VM хранится в виде объектов на различных дисках кластера для обеспечении отказоустойчивости. Воспринимайте Ceph как "сетевой RAID", как Лерне́йскую Ги́дру со множеством голов. Добавьте сюда возможность Proxmox VE под названием High Availability и вы получаете "ночного администратора", который в случае каких-либо проблем автоматически переведёт виртуальные машины на рабочие ноды, уменьшив их downtime.

Здесь на сцене появляется проект Open vSwitch, который давным-давно начали использовать вместо linux native network ради одной супервозможности: можно не делать массу мостов (bridge) под каждый поддерживаемый вами VLAN. Благодаря Open vSwitch, можно создать один единственный мост и указывать у виртуальной машины номер VLAN в её конфигурации и данная VM будет в нужной сети.

Как и было сказано выше, Open vSwitch крут, но:

• Интеграции с systemd нет и это сказано в официальной документации.
• Proxmox VE добавил свои 5 копеек и всё делает в /etc/network/interfaces, если вы орудуете в GUI. Можно, конечно, всё сделать в CLI и через systemd, но Proxmox VE может многого из вашей конструкции "не увидеть"

Описание задачи

Итак, встала задача - совместить старое с новым. Нужно создать сложную сетевую конфигурацию с помощью Open vSwitch в /etc/network/interfaces, чтобы умаслить Proxmox VE и не ссориться с ним, но гарантировать для современных сетевых служб, которые идут с готовым стартовым unit файлом и с классической просьбой запустить их после готовности сети (After=network-online.target).

Давайте приведу примеры. Вот на тестовом стенде на одной из нод Proxmox VE выводим список unit файлов, связанных с Proxmox VE.

systemctl list-units | grep pve

etc-pve.mount            loaded active   mounted   /etc/pve                                                                     
mnt-pve-SavePlace.mount  loaded active   mounted   /mnt/pve/SavePlace                                                           
pve-cluster.service      loaded active   running   The Proxmox VE cluster filesystem                                            
pve-firewall.service     loaded active   running   Proxmox VE firewall                                                          
pve-guests.service       loaded active   exited    PVE guests                                                                   
pve-ha-crm.service       loaded active   running   PVE Cluster Resource Manager Daemon                                          
pve-ha-lrm.service       loaded active   running   PVE Local HA Resource Manager Daemon                                         
pvebanner.service        loaded active   exited    Proxmox VE Login Banner                                                      
pvedaemon.service        loaded active   running   PVE API Daemon                                                               
pvefw-logger.service     loaded active   running   Proxmox VE firewall logger                                                   
pvenetcommit.service     loaded active   exited    Commit Proxmox VE network changes                                            
pveproxy.service         loaded active   running   PVE API Proxy Server                                                         
pvestatd.service         loaded active   running   PVE Status Daemon                                                            
dev-pve-swap.swap        loaded active   active    /dev/pve/swap                                                                
pve-storage.target       loaded active   active    PVE Storage Target                                                           
pve-daily-update.timer   loaded active   waiting   Daily PVE download activities                                                
pvesr.timer              loaded active   waiting   Proxmox VE replication runner           

И что мы видим? Разработчики Proxmox VE, как и большинство, приняли переход основных linux игроков на systemd и подготавливают себе стартовые unit файлы, но в дальнейшем сетевую конфигурацию через GUI формируют в старом /etc/network/interfaces или считывают ваши ручные правки там же. Это очень обескураживает и не понятно!

Смотрим на примере важнейшего стартового unit'а после чего он хотел бы стартовать?

systemctl show pve-cluster.service | grep After

After=system.slice sys-fs-fuse-connections.mount systemd-journald.socket time-sync.target network.target rrdcached.service

В выводе присутствует network.target, но не network-online.target! Судя по документации systemd, цель network.target гарантирует что сетевой стек готов, но настроен ли он? Не определено! Вот цель network-online.target гарантирует настроенный и маршрутизируемый IP адрес. Это даёт нам право сделать вывод, что ошибки недостижимой сети сервисы Proxmox VE будут решать самостоятельно, например новыми попытками через таймаут времени. На практике, кластер Proxmox VE после перезагрузки всех его серверов-нод обычно нормально "собирался обратно" без каких-либо проблем, но нужно не спешить.

Давайте глянем на стартовые unit'ы Ceph, которые создал проект Proxmox VE в рамках развёртывания Hyper-converged Infrastructure. Возьмём ноду, которая будет дополнительно нести, помимо нагрузки хранения данных object storage daemon (OSD), ещё задачи монитора (MON) и менеджера (MGR).

systemctl list-units | grep ceph

var-lib-ceph-osd-ceph\x2d0.mount   loaded active   mounted   /var/lib/ceph/osd/ceph-0                                                     
var-lib-ceph-osd-ceph\x2d1.mount   loaded active   mounted   /var/lib/ceph/osd/ceph-1                                                     
var-lib-ceph-osd-ceph\x2d2.mount   loaded active   mounted   /var/lib/ceph/osd/ceph-2                                                     
var-lib-ceph-osd-ceph\x2d3.mount   loaded active   mounted   /var/lib/ceph/osd/ceph-3                                                     
ceph-crash.service                 loaded active   running   Ceph crash dump collector                                                    
ceph-mgr@pve4.service              loaded active   running   Ceph cluster manager daemon                                                  
ceph-mon@pve4.service              loaded active   running   Ceph cluster monitor daemon                                                  
ceph-osd@0.service                 loaded active   running   Ceph object storage daemon osd.0                                             
ceph-osd@1.service                 loaded active   running   Ceph object storage daemon osd.1                                             
ceph-osd@2.service                 loaded active   running   Ceph object storage daemon osd.2                                             
ceph-osd@3.service                 loaded active   running   Ceph object storage daemon osd.3                                             
system-ceph\x2dmgr.slice           loaded active   active    system-ceph\x2dmgr.slice                                                     
system-ceph\x2dmon.slice           loaded active   active    system-ceph\x2dmon.slice                                                     
system-ceph\x2dosd.slice           loaded active   active    system-ceph\x2dosd.slice                                                     
system-ceph\x2dvolume.slice        loaded active   active    system-ceph\x2dvolume.slice                                                  
ceph-fuse.target                   loaded active   active    ceph target allowing to start/stop all ceph-fuse@.service instances at once  
ceph-mds.target                    loaded active   active    ceph target allowing to start/stop all ceph-mds@.service instances at once   
ceph-mgr.target                    loaded active   active    ceph target allowing to start/stop all ceph-mgr@.service instances at once   
ceph-mon.target                    loaded active   active    ceph target allowing to start/stop all ceph-mon@.service instances at once   
ceph-osd.target                    loaded active   active    ceph target allowing to start/stop all ceph-osd@.service instances at once   
ceph.target                        loaded active   active    ceph target allowing to start/stop all ceph*@.service instances at once      

Глянем важный unit менеджера

systemctl show ceph-mgr@pve4.service | grep After

After=network-online.target systemd-tmpfiles-setup.service basic.target sysinit.target time-sync.target system-ceph\x2dmgr.slice pve-cluster.service systemd-journald.socket -.mount local-fs.target

и одного из четырёх демонов хранения (по одному на каждый диск, а их четыре в сервере).

systemctl show ceph-osd@0.service | grep After

After=local-fs.target pve-cluster.service time-sync.target sysinit.target system-ceph\x2dosd.slice -.mount network-online.target ceph-mon.target systemd-journald.socket systemd-tmpfiles-setup.service basic.target

В выводе обоих присутствует network-online.target, а значит Ceph хотел бы стартовать ПОСЛЕ гарантированной настройки сети.

Получается, что мне необходимо в старом /etc/network/interfaces создать сложную сетевую конфигурацию с помощью Open vSwitch и увязать это с современными тенденциями старта программ через систему инициализации systemd, которую я люблю и принимаю.

Мне необходимо с помощью Open vSwitch создать из 4 сетевых интерфейсов (eth0, eth1, eth2, eth3) два бонда по 2 сетевые карты в каждом: один сетевой интерфейс clusternetwork (по природе своей это bond = eth2 + eth3) будет использоваться для связи в рамках Cluster Network (изолированная сеть для нужд Ceph), а другой бонд (eth0 + eth1) publicnetwork в рамках Public Network (для скромных нужд кластера Proxmox VE и доступа пользователей к виртуальным серверам).

Каждый сервер настроен одинаково и различается лишь IP адресами. Очень упрощённый пример, где publicnetwork - это бонд, поверх которого реализован мост с возможностью указания различных VLAN. clusternetwork - это сеть для нужд Ceph.

Решение вопроса

После долгих раздумий и тестов, родилась мысль как более элегантно увязать старое наследие /etc/network/interfaces и создание сложной сетевой конфигурации через Open vSwitch с уведомлением systemd о готовности сети и гарантиях достижимости network-online.

Для этого нам необходимо включить службу systemd-networkd, хоть мы и не настраивали ни единого сетевого интерфейса через systemd- sudo systemctl enable systemd-networkd

Затем нам необходимо переопределить параметр ExecStart и указать свои хотелки. В терминах SystemD это называется Drop-in.
systemctl edit systemd-networkd-wait-online

Вам откроют редактор, в котором вы должны переопределить ExecStart

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i publicnetwork -i clusternetwork

Ваши изменения попадут в отдельный файл /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf

Обратите внимание на опцию -i (--interface). Судя по документации, именно она отвечает за факт что система обладает настроенным сетевым интерфейсом, обладающим маршрутизируемым IP адресом, а следовательно network-online.target достигнута и службы, просившие их старт после готовности сети, можно запускать. Разрешается множественное использование опции -i.

Выдержка из документации на английском:
-i INTERFACE[:OPERSTATE], --interface=INTERFACE[:OPERSTATE]

Network interface to wait for before deciding if the system is online. This option may be used more than once to wait for multiple network interfaces.

Итог

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

Собственными глазами видел ранний старт сетевых демонов Ceph, чей старт разбавлял только начинающий создаваться bond0, и больше такого видеть не хочу, тем более в будущем сложном кластере.

Jun  5 08:59:29 cn5 ceph[1703]: === osd.18 ===
Jun  5 08:59:31 cn5 kernel: [    8.680641] bond0: link status up for interface enp5s0, enabling it in 0 ms
Jun  5 08:59:32 cn5 kernel: [    9.080607] bond0: link status definitely up for interface enp6s0, 1000 Mbps full duplex
Jun  5 08:59:56 cn5 ceph[1703]: 2017-06-05 08:59:56.613942 7f114c179700  0 -- :/3498339517 >> 172.16.3.41:6789/0 pipe(0x7f113c0052c0 sd=4 :0 s=1 pgs=0 cs=0 l=1 c=0x7f113c0065a0).fault
Jun  5 08:59:59 cn5 ceph[1703]: failed: 'timeout 30 /usr/bin/ceph -c /etc/ceph/ceph.conf --name=osd.18 --keyring=/mnt/d1//keyring osd crush create-or-move -- 18 3.6369 host=cn5 root=default'
Jun  5 08:59:59 cn5 ceph[1703]: === osd.19 ===

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

Дата последней правки: 2020-01-24 11:39:41