Вопрос или проблема
Запуск сервера Ubuntu 20.04 с исправлениями на AWS для размещения NFS-томов, шифрованных с помощью Cryptsetup и форматированных в XFS.
Мы сталкивались с этой ситуацией на нескольких разных серверах с такой же конфигурацией. Эти серверы работали много лет без проблем и без изменений.
Похоже, что происходит следующее…
- Сервисы NFS, похоже, зависают/падают
- На самом NFS-сервере том по-прежнему полностью смонтирован и доступен, но другие клиенты не могут его достичь
- любая попытка перезапустить службы NFS также зависает, и в syslog или где-либо еще нет журнала проблемы
- выполнение команды cryptsetup luksOpen работает без проблем, но команда монтирования просто зависает без ответа или логирования. cryptsetup repair не показывает никаких проблем.
- перезагрузка или остановка/запуск сервера приводит к его возврату, НО NFS-том не монтируется. Предыдущий шаг имеет такие же результаты.
- отключение и повторное подключение тома тоже ничего не меняет
- xfs_repair не выявляет никаких проблем
Тем не менее, если я отсоединяю том, подключаю его к новой, свежей установке Ubuntu и выполняю “cryptsetup luksOpen” на устройстве… он там монтируется без проблем. И… если я затем отключаю том, снова подключаю его к исходному серверу, том монтируется без проблем.
Что здесь происходит? Кто-нибудь еще сталкивался с этим? Я не верю, что новый сервер выполняет какую-либо починку, но это точно похоже на то, что он делает.
Ответ или решение
Теория
При работе с зашифрованными файловыми системами и сетевыми файловыми системами (NFS) могут возникать различные сложности, особенно в сценариях, где они объединяются, как в вашем случае на сервере Ubuntu 20.04 в AWS. Основная задача, с которой вы столкнулись — это зависание NFS-сервиса и невозможность монтирования зашифрованного XFS-диска после сбоя NFS. Проблема является многослойной и может касаться как непосредственно аппаратных, так и программных компонентов.
Системы, работающие стабильно в течение долгих периодов времени, иногда могут демонстрировать сбои вследствие неожиданных изменений в собственной конфигурации или в конфигурации сетевого окружения. Наиболее очевидные подходы к решению таких проблем включают в себя проверку целостности всех вовлечённых элементов, мониторинг системных журналов, а также тестирование на других серверах для исключения специфических аппаратных или конфигурационных сбоев.
Пример
Из вашего описания следует, что при сбое NFS на сервере, данные не теряются, и объём остаётся доступным локально, однако все подключения к нему извне становятся невозможными. После перезагрузки или повторного запуска также невозможно примонтировать NFS-том, что указывает на зацикленную проблему в конфигурации или в работе одного из служб.
Одним из ключевых наблюдений является возможность успешного монтирования диска на свежей установке Ubuntu на другом сервере и последующая возможность его монтирования на исходном сервере после этой промежуточной операции. Это говорит о том, что проблема не связана с данными или повреждением файловой системы. Вероятнее всего, проблема кроется в закэшированных данных, остатках сессий или состоянии, которые сбрасываются при подключении к другой системе.
Применение
С учётом вышеизложенного, расследование проблемы стоит начать с анализа проблем с NFS-сервером. Периодически обновляемые кэш-файлы или застарелые состояния демонов могут провоцировать такие проблемы. Рассмотрите выполнение следующих шагов:
-
Анализ журналов: Возможно, в стандартных журналах системных служб (например,
syslog,dmesg,journalctl) изначально нет очевидных подсказок. Попробуйте увеличить уровень логирования для служб NFS и cryptsetup, чтобы получить более детализированную информацию о процессе. -
Проверка состояния демонов: Используйте команды такие как
systemctl status nfs-server,systemctl restart,sfcdи другие для анализа состояния демонов. Зависания могут быть связаны с некорректными зависимостями или неопределёнными статусами сессий. -
Обновление и тестирование кэша: Очистка и сброс кэша NFS может помочь. Например, команда
exportfs -raобновляет NFS-экспорты. Также может быть разумным на некоторое время отключить или изменить настройки кэширования для устранения проблемы. -
Сравнительный анализ на новых системах: Если перенос диска на другой сервер временно решает проблему, стоит провести сравнение рабочего окружения старого и нового сервера, включая версии установленных пакетов, конфигурационные файлы, активные модули ядра и загруженные библиотеки.
-
Диагностика с cryptsetup и XFS: Даже в случае успешного открывания LUKS и выполнения
xfs_repair, попробуйте использовать команды наподобиеcryptsetup luksDumpиblkidдля дополнительной информации, которая может пролить свет на состояния и изменения заголовков или UUID. -
Эксперименты с перезагрузками: Вы можете также протестировать результаты принудительной перезагрузки демонов без полного перезапуска системы, что потенциально может требовать команды
kill -9для тех процессов, которые виснут и не выключаются корректно стандартными методами.
Совокупность указанных методик должна помочь обнаружить источник проблемы и позволит вам устранить его для стабильной работы вашего конфигурационного решения. Реализовав указанные шаги, вы обеспечите более надёжную работу системы и уменьшите риск повторного возникновения данной проблемы.