DRBD8 с Systemd-Networkd (Netplan)

Это - первый раз, когда я настраиваю DRBD (drbd-utils 8.9.10-2) на Ubuntu 18.04 с systemd-networkd (использующий netplan).

Обычно установка кажется успешной. У меня есть один ресурс, который синхронизируется более чем два хоста через специализированный интерфейс. NIC node1 и node2 непосредственно соединен (никакой Переключатель). Другой NIC используется для hearbeat ресурса и ресурсов как веб-сервер.

Теперь к части, которая не работает:
Когда я отключаю кабель специализированного drdb сетевого соединения, узлы попадают в Автономный режим вместо WFConnection. Шоу журналов, что это пытается войти в WFConnection, но сбои и после этого отступает в StandAlone:

Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: ens192: Flags change: -UP -LOWER_UP -RUNNING
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_33 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=21 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: LLDP: Stopping LLDP client
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: ens192: Stopped LLDP.
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: ens192: Lost carrier
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: ens192: State is configured, dropping config
Apr 17 09:08:01 gts-test-node2 systemd-networkd[284]: ens192: Removing address: 192.168.0.2/24 (valid forever)
Apr 17 09:08:01 gts-test-node2 systemd-timesyncd[388]: Network configuration changed, trying to establish connection.
Apr 17 09:08:01 gts-test-node2 systemd-timesyncd[388]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com).
Apr 17 09:08:02 gts-test-node2 corosync[480]: Apr 17 09:08:02 warning [TOTEM ] Incrementing problem counter for seqid 7082 iface 192.168.0.2 to [1 of 10]
Apr 17 09:08:02 gts-test-node2 corosync[480]:   [TOTEM ] Incrementing problem counter for seqid 7082 iface 192.168.0.2 to [1 of 10]
Apr 17 09:08:02 gts-test-node2 corosync[480]: Apr 17 09:08:02 warning [TOTEM ] Incrementing problem counter for seqid 7084 iface 192.168.0.2 to [2 of 10]
Apr 17 09:08:02 gts-test-node2 corosync[480]:   [TOTEM ] Incrementing problem counter for seqid 7084 iface 192.168.0.2 to [2 of 10]
Apr 17 09:08:02 gts-test-node2 kernel: drbd storage1: PingAck did not arrive in time.
Apr 17 09:08:02 gts-test-node2 kernel: drbd storage1: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Apr 17 09:08:02 gts-test-node2 kernel: drbd storage1: ack_receiver terminated
Apr 17 09:08:02 gts-test-node2 kernel: drbd storage1: Terminating drbd_a_storage1
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: Connection closed
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: conn( NetworkFailure -> Unconnected )
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: receiver terminated
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: Restarting receiver thread
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: receiver (re)started
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: conn( Unconnected -> WFConnection )
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: bind before listen failed, err = -99
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: conn( WFConnection -> Disconnecting )
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: Connection closed
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: conn( Disconnecting -> StandAlone )
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: State change failed: Need a connection to start verify or resync
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1:  mask = 0x1f0 val = 0x80
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1:  old_conn:StandAlone wanted_conn:WFConnection
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: receiver terminated
Apr 17 09:08:03 gts-test-node2 kernel: drbd storage1: Terminating drbd_r_storage1

Эта ошибка плохо мне знакома и никогда не происходила с Ubuntu 16.04, где ifupdown использовался, а не systemd-networkd:

свяжите прежде слушают отказавшие, допускают ошибку =-99

Если я systemctl stop systemd-networkd прежде, чем отключить кабель, поведение корректно-> это остается в WFConnection, но я хочу смочь использовать systemd-networkd и не реконфигурировать все для возвращения к "старому пути".

Разъединение кабеля было моделировано двумя различными способами с тем же результатом:

ip link set ens190 down

или просто разъединяя интерфейс физически.

Делает у любого есть идея что процесс systemd-networkd (или возможно networkd-dispatcher или другой?) вызывает этот проступок? Я не смог найти что-либо в Интернете связанным с этой темой.

Любая справка высоко ценится.

1
задан 17 April 2019 в 12:08

1 ответ

Я испытывал эту проблему также. Используя networkd-отправку для входа интерфейсного состояния я видел, что, когда там без поставщиков услуг, интерфейс лишен своей конфигурации IP, вызывающей drbd для создания всех ресурсов автономными. Это systemd поведение, кажется, бесполезно инвертирует все виды установленных идей о том, что должно произойти в этом случае.

https://github.com/systemd/systemd/commit/a9cc0189aa69a5fa1bcbacbdc69740fa3e5353db был добавлен, но это не включено в бионический systemd пакет. Опция должна была бы, вероятно, также быть выставлена через netplan, таким образом, сгенерированные единицы устанавливают желаемое поведение.

Возможные обходные решения:

  • Присвойте drbd IP сетевому мосту и добавьте свой интерфейс репликации к мосту
  • Используйте networkd-диспетчера для drbdadm connect all на подходящем этапе

(Я думаю, что systemd поведение просто неправильный. Когда возможно подать заявки, связывают с определенными адресами, я не хочу, чтобы тот адрес исчез, потому что устройство одноранговой сети перезапущено, кабель, отключенный и т.д.),

0
ответ дан 7 December 2019 в 20:41

Другие вопросы по тегам:

Похожие вопросы: