Я использовал набор инструментов тестирования файловой системы для тестирования и злоупотребления томом GlusterFS. Том представляет собой реплику 3 тома, распределенного по 6 хостам.
Fio, iozone и Bonnie указывают мне, что Gluster работает нормально, а пропускная способность примерно равна пропускной способности клиентских и серверных сетевых адаптеров, поэтому производительность не может быть улучшена. Большинство моих тестовых примеров работали с файлами размером 32 ГБ, за исключением iozone и Bonnie.
Я получил сообщения о разделении мозга на определенные файлы, в которые одновременно записываются несколько клиентов. Вся документация, которую я прочитал, похоже, указывает на то, что разделение мозга в основном происходит при возникновении сетевых разделов, и, судя по журналам, это явно не так.
К сожалению, такое разделение мозга, похоже, происходит только при использовании определенной размещенной службы, и у меня нет никакого самоанализа в том, как эта служба работает, какая версия клиента Gluster у нее есть и т. Д. На серверах установлена последняя версия 4.0.
Судя по случаю сбоя, который мне представили («разделение мозга происходит, когда два контейнера записывают в один и тот же файл одновременно»), мне нужен тест, который воспроизведет аналогичную ситуацию.
Я определенно мог бы написать свой собственный тестовый пример на C или Rust, но есть ли что-то, что проверит этот точный случай без необходимости ничего писать?
У меня есть доступ (но не самоанализ) к этому размещенному сервису, поэтому я, вероятно, его тоже протестирую. Я также ломаю голову над реальной проблемой: каков желаемый результат, когда две программы записывают разные данные в один и тот же файл в одно и то же время?
РЕДАКТИРОВАТЬ: На серверах установлена последняя версия CentOS 7. Мой тестовый клиентский сервер также работает так же. Базовая файловая система - XFS.
Есть ли конкретный тестовый пример, который я могу использовать, чтобы попытаться воссоздать проблему?
Похоже, у вас есть приложение PHP, и его журнал ошибок поврежден. Таким образом, наиболее реалистичным тестом было бы выполнение нескольких процессов PHP, которые параллельно вызывают error_log ().
Вы можете отследить приложение, выполняющее журнал ошибок, или прочитать исходный код, чтобы узнать его точную реализацию. Особенно интересно было бы, если бы он открывался в режиме добавления с помощью O_APPEND. При добавлении есть условия гонки в NFS, поэтому это не обязательно решает проблему в сетевых файловых системах.
Рассмотрите возможность переключения error_log в syslog и вместо этого разрешите вашему syslogd перенаправить его в центральный syslog. Это преобразует его в единый файловый писатель. Или вы можете перенаправить на платформу анализа журналов, такую как Graylog, ELK или Splunk, которые имеют соответствующие базы данных.
Просто создайте два отдельных задания fio, которые выполняют direct Ввод / вывод в тот же файл, который контролируется filename параметр. Сделать size файла несколько маленький и, возможно, одна или обе задачи fio выполняют запись Ввод / вывод случайным образом и, возможно, настроить каждое задание на использование разных размер блока. Бонусные баллы за использование режим клиент / сервер fio так что рабочие места приходят с разных машин. Использовать runtime и time_based чтобы сохранить цикл fio.