С подключением к сети все в порядке, тесты подтверждают, что LACP полностью функционален и приближается к теоретическому максимуму 20 Гбит / с.
systemd не обнаруживает, что сетевой стек остановлен во время завершения работы, и ждет, пока не станет слишком поздно, чтобы отключить общие ресурсы NFS, и, таким образом, не может их отключить, что приводит к тому, что сервер NFS зависает на неопределенное время, чтобы ответить.
После запуска "systemctl stop network.service" и network.target, и network-online.target по-прежнему считаются активный.
Монтирование NFS, добавленное через /etc/fstab
файл переведен на *.mount
юниты systemd. Эти единицы автоматически зависят от remote-fs.target
который зависит от `network-online.target.
Из документациякажется, что network * .target зависит от инструмента управления сетью, чтобы определить, работает ли сеть и тому подобное. Это может быть NetworkManager
, systemd-nerworkd
, или что-нибудь еще (но что?). Я думаю, что моя проблема может быть здесь, поскольку кажется, что наш шаблон jumpstart полагается на старые сценарии инициализации для управления интерфейсами. И я сомневаюсь, что systemd может взаимодействовать с ним, чтобы получать информацию о том, работает ли сеть или нет (несмотря на то, что он используется для остановки сетевого стека с помощью systemctl stop network
)
Моя вторая гипотеза заключается в том, что объединение сети с использованием libteam / teamd даже через файлы ifcfg- * выходит за пределы области действия systemd network.target. Кажется, что нет зависимости между модулями teamd systemd (включая teamd@lacp0.service) и сетевыми модулями. Это объясняет, почему единственные системы, отображающие эту проблему, - это системы с поддержкой LACP, и у нас не было проблем раньше при использовании типичного связывания.
Итак, мой вопрос: какое решение у меня есть, чтобы убедиться, что мои общие ресурсы NFS отключены до того, как мой сетевой стек будет отключен, обычно при перезагрузке системы?
PS: было бы лучше, если бы указанное решение не исходило из способа создания монтирования NFS, чтобы тот, кто должен добавить общий ресурс на этот сервер, не должен был быть проинформирован о специальных шагах, которые необходимо предпринять. Это кажется почти невозможным, учитывая наш производственный процесс.
К сожалению, единственным «правильным» ответом на этот вопрос, похоже, является использование инструмента управления сетью, который на данный момент либо NetworkManager
(Передовой опыт Red Hat) или systemd-networkd
.
Чтобы избежать использования NetworkManager, мы использовали обходной путь:
редактировать /etc/systemd/system/teamd@.service.d/override.conf
[Unit]
Before=remote-fs.target
[Install]
WantedBy=network-online.target
[Service]
ExecStop=/bin/bash -c "while grep ' nfs ' /proc/mounts; do sleep 5; done"
TimeoutStopSec=30
Этот файл будет связан с системным шаблоном любого teamd@<teamname>.service
так как /etc/systemd/system/*
файлы имеют приоритет над /usr/lib/systemd/system/
При остановке systemd сначала инициирует размонтирование NFS, но по умолчанию не ждет их завершения. Затем мы заставляем teamd @ .service, который отвечает за подключение к сети, ждать не более 30 секунд, пока общие ресурсы NFS не будут отключены, прежде чем убивать демонов teamd и продолжать процесс завершения работы.
Ссылки :