Тест файловой системы для утвержденных записей

Я использую набор инструментов тестирования файловой системы для тестирования и злоупотребления томом GlusterFS. Том является копией тома 3, распределенной по 6 хостам.

Fio, iozone и Bonnie указывают мне, что Gluster работает просто отлично и пропускная способность примерно равна пропускной способности клиентских и серверных сетевых адаптеров, поэтому производительность не может быть улучшена. Большинство моих тестов работали с 32-гигабайтными файлами, кроме iozone и Bonnie.

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

К сожалению, такое разделение мозгов, по-видимому, происходит только при использовании определенного размещенного сервиса, и у меня нет нулевого самоанализа, как работает этот сервис, какая у него версия клиента Gluster и т. Д. На серверах установлена ​​последняя версия 4.0.

Судя по описанному мной случаю сбоя ("разделение мозга происходит, когда два контейнера записывают в один и тот же файл одновременно"), мне нужен тест, который воспроизведет похожую ситуацию.

Я определенно мог бы написать свой собственный контрольный пример на C или Rust, но есть ли что-то, что будет проверять этот конкретный случай без необходимости что-либо писать?

У меня есть доступ (но не самоанализ) к этому размещенному сервису, так что я, вероятно, тоже это протестирую. Я также ломаю голову над актуальной проблемой: каков желаемый результат, когда две программы записывают разные данные в один и тот же файл одновременно?


РЕДАКТИРОВАТЬ: серверы работают под управлением последней версии CentOS 7. Мой клиентский сервер тестирования также работает так же. Основной файловой системой является XFS.

Есть ли конкретный контрольный пример, который я могу использовать, чтобы попытаться воссоздать проблему?

2 ответа

Похоже, у вас есть приложение PHP и его журнал ошибок становится поврежденным. Таким образом, наиболее реалистичным тестом будет отработка нескольких процессов PHP, которые параллельно вызывают error_log().

Вы можете отслеживать приложение, делающее журнал ошибок или читать исходный код, чтобы узнать его точную реализацию. Особенно интересно было бы, если бы он открывался в режиме добавления с O_APPEND. В приложении Append есть условия состязания в NFS, поэтому это не обязательно устраняет проблему в сетевых файловых системах.

Подумайте о том, чтобы переключить error_log на syslog и перевести ваш syslogd на центральный syslog. Это преобразует его в один файл писателя. Или вы можете перейти на платформу анализа журналов, такую ​​как Graylog, ELK или Splunk, у которой есть надлежащие базы данных.

Просто создайте две отдельные работы ФИО, которые делают direct Ввод / вывод в тот же файл, который контролируется filename параметр. Сделать size файла немного меньше, и, возможно, одно или оба задания fio выполняют случайный ввод-вывод и, возможно, устанавливают для каждого задания свой размер блока. Бонусные баллы за использование режима клиент / сервер fio, поэтому задания выполняются с разных компьютеров. использование runtime а также time_based держать петлю fio.

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