Тест файловой системы для состязательной записи
Я использовал набор инструментов тестирования файловой системы для тестирования и злоупотребления томом GlusterFS. Том представляет собой реплику 3 тома, распределенного по 6 хостам.
Фио, iozone, и Бонни показали мне, что 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, которые выполняют прямые ввод-вывод в один и тот же файл, который управляется параметром filename . Сделайте размер файла несколько маленьким и, возможно, пусть одно или оба задания fio будут выполнять запись ввода-вывода случайным образом и, возможно, настроить каждое задание на использование другого размер блока . Бонусные баллы за использование режима клиент / сервер fio , чтобы задания приходили с разных машин. Используйте runtime и time_based , чтобы сохранить цикл fio.