Я попытался провести сравнительный анализ GlusterFS и NFS на Amazon Web Services (AWS), используя экземпляр EC2 размером m1.medium. Мы используем AWS EBS в качестве хранилища блоков с файловой системой XFS. Запуск Ubuntu 12.04 с использованием стандартных пакетов.
Я использовал iozone и dd для тестирования. Я понимаю, что их нельзя сравнивать с инструментами тестирования, но получаю некоторые странные результаты.
Мой результаты в МБ / с ниже (все тесты запускаются на клиенте):
using: iozone -c -e -i 0 -+n -r 64k -s 1000M -t 2
Direct to EBS GlusterFS NFS GlusterFS + NFS
37.5 26.8 99.8 21.1
.
using: dd if=/srv/test of=/dev/null bs=64k count=16k
Direct to EBS GlusterFS NFS GlusterFS + NFS
97.0 40.8 58.3 23.8
Direct to EBS хорошо работает с dd, но с iozone он на самом деле медленнее, чем NFS. Зачем?
В общем, я видел, что GlusterFS обычно в 1,5–2 раза медленнее, чем NFS. Реалистичны ли эти цифры для GlusterFS?
Как и все тесты, сложно сравнивать яблоки с яблоками. Кажется, что iozone перегружает систему и не моделирует конкретную нагрузку. dd просто измеряет пропускную способность.
Я наткнулся верстак. С участием filebench вы можете моделировать определенные типы нагрузки, эти различные тесты называются «личностями». Это дало мне гораздо более реалистичные цифры. Я смоделировал веб-сервер, который обычно доступен только для чтения. Хотя filebench добавляет журнал к моделированию, я удалил это в данном случае. Получил следующие результаты:
Результаты в МБ / с
using: sudo filebench (webserver personality without simulation of log append)
Direct to EBS GlusterFS NFS GlusterFS + NFS
24.2 6.0 17.0 20.4
Примечание: filebench было ограничением в тесте EBS, так как во время теста он загружал 100% ЦП. Полагаю, результат EBS был бы выше.
Примечание 2: GlusterFS сама по себе имела очень высокую задержку, когда я включил тест для добавления журнала. Это можно объяснить в эта почта. Я не исследовал эту проблему с высокой задержкой, поскольку мы ожидаем в основном чтения.