Мы постоянно сталкиваемся с типовой задачей о развёртывании офисного сервера для различных компаний. Чаще всего клиент хочет купить сервер, на котором будут работать офисная почта, например, postfix+*SQL, ejabberd с тем же *SQL, samba, а также *SQL под 1С. В этом случае возникает необходимость изучения производительности дисковых массивов применительно к серверам «рабочей группы» одной и той же модели, но различных поколений. Поскольку наша компания в большей степени специализируется на продукции Hewlett-Packard, анализу подверглись 1U серверы HP ProLiant 360 5-го, 6-го, 7-го и 8-го поколений:
Во всех конфигурациях контроллера используем кэш размером 256Mb. Стоит отметить отличие в пропускной способности PCI Express шины, посредством которой подключены контроллеры: P400i и P410i — 2GBps (гигабайта в секунду), P420 — 8 GBps (гигабайт в секунду).
Первый вопрос, который логично возникает в этом случае: в каких попугаях измерять производительность? Изучив статью уважаемого amarao, мы установили, что подобные измерения стоит проводить как минимум по двум параметрам: IOPS — количество дисковых Input/Output операций в секунду: чем их больше, тем лучше и Latency — время обработки операции: чем меньше, тем лучше.
Было решено произвести сравнение производительности различных конфигураций применительно к разным типовым задачам, поскольку эти задачи подразумевают различные варианты нагрузки на дисковую подсистему. Характер нагрузки определяется следующими параметрами: размер блока, соотношение операций чтение-запись, случайный/последовательный доступ.
Последовательный доступ к данным характерен для записи всевозможных логов, при трансляции и записи аудио/видео и тому подобного. Суть в том, что доступ характеризуется локализованной областью диска, без необходимости прыгать по всей поверхности.
Случайный доступ наиболее характерен для баз данных, веб и файловых серверов: большое количество запросов к разбросанным по диску секторам.
Комбинированный сочетает в себе оба выше описанных сценария, например функционирование БД с записью логов на тот же массив.
Тестируем непосредственно raw-device (прямой доступ, без оглядки на файловую систему), чтобы избежать влияния особенностей реализации файловых систем и всего, что с этим связано на разных платформах.
Под эту задачу были написаны правила для fio и IOMetter.
Конфигурационный файл IOmetter
Очевидно, что для тестирования под Windows необходима установка данной ОС, а это, как минимум, еще один занятый порт и время, посвящённое установке на каждый сервер. Именно поэтому для работы мы выбрали Linux. Дело тут даже не в индивидуальных пристрастиях, а в наличии развитых средств автоматизации процесса «из коробки», позволяющих, к примеру, запустить тестирование сразу после загрузки ОС, а по окончанию тестов, отправить результаты по ssh, ftp или по email.
Было решено собрать небольшой Live-USB образ на базе Debian со всеми необходимыми утилитами. Желающие пересобрать его под свои потребности могут скачать архив. Для сборки потребуется Debian (скорее всего, подойдет и Ubuntu), multistrap, isolinux, squashfs-tools и xorriso. Внеся изменения и доустановив из chroot'a нужные пакеты, выполните скрипт build.sh.
Единственный пользователь в системе — root, пароль не задан. При загрузке генерируется, основанный на uuid, hostname, а при логине выдаётся краткая сводка о системе. Для запуска тестирования необходимо выполнить скрипт run.sh в каталоге fio, передав в качестве аргумента полное имя файла устройства, которое нужно протестировать, например, ./run.sh /dev/cciss/c0d0.
ВНИМАНИЕ! Делать это следует исключительно на пустом массиве, иначе вы потеряете данные!
Тем не менее, в одном из случаев мы провели тестирование и под Windows с использованием IOMetter для сравнения полученных результатов с fio.
Таким образом удалось изучить производительность различных массивов на наших серверах по 12 типовым профилям нагрузки, выраженным в 3-х группах, сформированных по типу доступа.
Как известно, кэш представляет собой промежуточный буфер быстрого доступа к информации, запрашиваемый с наибольшей вероятностью. В итоге доступ к данным осуществляется оперативнее, минуя выборку данных из удаленного источника.
Рассмотрим влияние наличия платы аппаратного кэша на примере конфигурации raid10, построенной на четырех 6Gbps дисках.
Как видно, при установленной плате кэша, производительность возрастает примерно до 40% на операциях как последовательного, так и случайного доступа. Также на гистограммах наглядно демонстрируется, что при включении кэша, колоссально (до нескольких порядков) сокращается время реакции (latency).
Стоит отметить, что использование кэша контроллером (P400i) сервера пятого поколения, мягко говоря, нерационально.
Контроллер сервера восьмого поколения наоборот, принудительно использует кэш, проигнорировав команду на отключение.
Напомним, что параметр «Gbps» (гигабит в секунду) являет собой максимальную скорость передачи данных между диском и контроллером, то есть 3000Mbps и 6000Mbps. При надобности пересчитать в байты делим на 10: 300MBps и 600MBps соответственно. Теоретически, при количестве более шести 3G и более трех 6G дисков, бутылочным горлышком окажется скорость шины. Собственно, попробуем оценить ширину этого самого горлышка. Следует помнить, что жесткий диск является механической системой и указанная скорость передачи данных является предельной, то есть, по факту, в полной мере недостижимой. Напомним также, что контроллер P420i сервера восьмого поколения подключен через PCIe 3.0 (8GBps).
Сравнение проводим на raid10 с включенным кэшем.
При использовании на данной конфигурации 3Gbps и 6Gbps дисков с 10K оборотов, какой-либо принципиальной разницы нет как по параметру IOPS, так и по Latency. А вот рост производительности при использовании 6Gbps 15K весьма значителен и лучше всего заметен на операциях случайного доступа. Вывод: количество оборотов имеет значение.
К вопросу о PCIe 2.0 и 3.0: на примере конфигурации серверов Gen6, Gen7 и Gen8 с 6Gbps дисками, разница в IOPS составляет максимум 10%, по Latency и вовсе не больше 2%. Вывод: «бутылочное горлышко» PCIe 2.0 достаточно широко для конфигурации из четырех 6Gbps (600MBps) дисков.
Любопытно, что сервер седьмого поколения на конфигурации 3G 10Krpm дал худшую производительность, чем Gen 6 на этих же дисках. С чем это связано, в данном случае, сказать трудно и, возможно, будет выявлено при комплексном тестировании серверов.
Использование в сервере пятого поколения 6Gbps 15K дисков дало некоторый прирост в быстродействии, в основном за счет большего количества оборотов в секунду. Разницы между 6G и 3G десятитысячниками, ожидаемо, практически нет.
В принципе, все видно выше, но все-таки проиллюстрируем на примере raid10, построенном на четырех 6Gbps дисках.
Как видно на графиках разница не существенная, особенно между серверами DL360Gen6, DL360Gen7 и DL360Gen8. В типовой нагрузке (профиль workstation) есть небольшая разница и с DL360Gen5. Старенький контроллер P400i в сервере DL360G5 сильно подкачал лишь на операциях последовательного доступа как по количеству IOPS, так и по времени реакции (latency), что не удивительно.
Желающие ознакомиться с детальными результатами тестирования (конфигурации raid5 и raid10 на трех, четырех и восьми дисках), могут скачать csv файл
Разница между G8 (P420i) и G6/G7 (с одинаковым контроллером P410i) составляет не более 10% на всех типах задач. Напрашивается вывод, что если исходить исключительно из соотношения «производительность дисковой системы/стоимость», G6 или G7 будут более выгодным приобретением. Комплексное сравнение производительности этих серверов мы проведем в одной из следующих статей.
Gen5 же несколько отстает: напомним, что его контроллер P400i обменивается данными с дисками на скорости 3Gbps. Видно, что на операциях случайного доступа отставание не так велико. С ростом количества операций последовательного доступа, разница растет. В принципе, компенсировать ее можно наращиванием числа дисков в массиве. Таким образом, этот сервер можно рекомендовать, как бюджетное решение для небольшой компании из 10-15 человек.
А теперь попробуем ответить на вопрос: а сколько же мне потребуется IOPS под такую-то задачу? Простой ответ: чем больше, тем лучше. С latency, соответственно, наоборот.
В первую очередь, стоит разобраться, какая именно нагрузка предвидится (что именно будет работать на сервере) и попробовать соотнести с приведенными выше результатами, имитирующими «потолок» для той или иной конфигурации.
Лучше всего — посмотреть какую нагрузку дают ваши приложения. В Linux это можно сделать с помощью программы iostat, входящей в состав пакета sysstat, которая показывает текущее состояние дисковой подсистемы.
r/s и w/s — IOPS на чтение и запись
r/await и w/await — соответственно latency.
util — уровень загруженности сервера. В наших тестах значение колеблется от 80% до 100%.
В случае Windows, замеры можно произвести утилитой perfmon.
Если пиков нагрузки, принимающих значения близкие к нашим результатам будет много и параметр util длительное время колеблется в районе 80-100% — это хороший повод задуматься над оптимизацией дисковой системы.
Возвращаясь к вопросу о выборе конфигурации под потребности небольшой компании: файловый сервер, *SQL и завязанные на нем сервисы, мы бы рекомендовали рассматривать сервер не ниже Gen 6 с контроллером P410i с массивом уровня 10 (минимум 4 диска) из соображений сочетания быстродействия и надежности (raid10 имеет гораздо меньшее время перестроения массива в случае сбоя диска) на 6Gbps 15Krpm носителях. Отметим, что экономить на плате кэша крайне не рекомендуется.
Вообще, для нас результаты тестирования оказались неожиданными. Разница в производительности дисковых подсистем ожидалась гораздо большая, особенно в случае Gen8 с его PCIe 3.0 контроллером, в сравнении с серверами шестого и седьмого поколения. Маркетинг есть, а разницы почти нет — забавно.
Тестируемые сервера
HP Proliant DL360 Gen5 с контроллером P400i
HP Proliant DL360 Gen6 с контроллером P410i
HP Proliant DL360 Gen7 с контроллером P410i
HP Proliant DL360p Gen8 с контроллером P420i
HP Proliant DL360 Gen6 с контроллером P410i
HP Proliant DL360 Gen7 с контроллером P410i
HP Proliant DL360p Gen8 с контроллером P420i
Во всех конфигурациях контроллера используем кэш размером 256Mb. Стоит отметить отличие в пропускной способности PCI Express шины, посредством которой подключены контроллеры: P400i и P410i — 2GBps (гигабайта в секунду), P420 — 8 GBps (гигабайт в секунду).
Для тестирования мы используем следующие жесткие диски:
Первый вопрос, который логично возникает в этом случае: в каких попугаях измерять производительность? Изучив статью уважаемого amarao, мы установили, что подобные измерения стоит проводить как минимум по двум параметрам: IOPS — количество дисковых Input/Output операций в секунду: чем их больше, тем лучше и Latency — время обработки операции: чем меньше, тем лучше.
Было решено произвести сравнение производительности различных конфигураций применительно к разным типовым задачам, поскольку эти задачи подразумевают различные варианты нагрузки на дисковую подсистему. Характер нагрузки определяется следующими параметрами: размер блока, соотношение операций чтение-запись, случайный/последовательный доступ.
Последовательный доступ к данным характерен для записи всевозможных логов, при трансляции и записи аудио/видео и тому подобного. Суть в том, что доступ характеризуется локализованной областью диска, без необходимости прыгать по всей поверхности.
Случайный доступ наиболее характерен для баз данных, веб и файловых серверов: большое количество запросов к разбросанным по диску секторам.
Комбинированный сочетает в себе оба выше описанных сценария, например функционирование БД с записью логов на тот же массив.
Тестируем непосредственно raw-device (прямой доступ, без оглядки на файловую систему), чтобы избежать влияния особенностей реализации файловых систем и всего, что с этим связано на разных платформах.
Под эту задачу были написаны правила для fio и IOMetter.
Конфигурационный файл IOmetter
fio/profiles.cfg
[web-file-server4k]
blocksize=4k
rwmixread=95
rwmixwrite=5
rw=randrw
percentage_random=75
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[web-file-server8k]
blocksize=8k
rwmixread=95
rwmixwrite=5
rw=randrw
percentage_random=75
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[web-file-server64k]
blocksize=64k
rwmixread=95
rwmixwrite=5
rw=randrw
percentage_random=75
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[decision-support-system-db]
blocksize=1024k
rwmixread=100
rwmixwrite=0
rw=randrw
percentage_random=100
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[media-streaming]
blocksize=64k
rwmixread=98
rwmixwrite=2
rw=randrw
percentage_random=0
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[sql-server-log]
blocksize=64k
rwmixread=0
rwmixwrite=100
rw=randrw
percentage_random=0
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[os-paging]
blocksize=64k
rwmixread=90
rwmixwrite=10
rw=randrw
percentage_random=0
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[web-server-log]
blocksize=8k
rwmixread=0
rwmixwrite=100
rw=randrw
percentage_random=0
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[oltp-db]
blocksize=8k
rwmixread=70
rwmixwrite=30
rw=randrw
percentage_random=100
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[exchange-server]
blocksize=8k
rwmixread=67
rwmixwrite=33
rw=randrw
percentage_random=100
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[workstation]
blocksize=8k
rwmixread=80
rwmixwrite=20
rw=randrw
percentage_random=80
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
[video-on-demand]
blocksize=512k
rwmixread=80
rwmixwrite=20
rw=randrw
percentage_random=100
ioengine=libaio
direct=1
buffered=0
time_based
runtime=300
Очевидно, что для тестирования под Windows необходима установка данной ОС, а это, как минимум, еще один занятый порт и время, посвящённое установке на каждый сервер. Именно поэтому для работы мы выбрали Linux. Дело тут даже не в индивидуальных пристрастиях, а в наличии развитых средств автоматизации процесса «из коробки», позволяющих, к примеру, запустить тестирование сразу после загрузки ОС, а по окончанию тестов, отправить результаты по ssh, ftp или по email.
Было решено собрать небольшой Live-USB образ на базе Debian со всеми необходимыми утилитами. Желающие пересобрать его под свои потребности могут скачать архив. Для сборки потребуется Debian (скорее всего, подойдет и Ubuntu), multistrap, isolinux, squashfs-tools и xorriso. Внеся изменения и доустановив из chroot'a нужные пакеты, выполните скрипт build.sh.
Единственный пользователь в системе — root, пароль не задан. При загрузке генерируется, основанный на uuid, hostname, а при логине выдаётся краткая сводка о системе. Для запуска тестирования необходимо выполнить скрипт run.sh в каталоге fio, передав в качестве аргумента полное имя файла устройства, которое нужно протестировать, например, ./run.sh /dev/cciss/c0d0.
ВНИМАНИЕ! Делать это следует исключительно на пустом массиве, иначе вы потеряете данные!
Тем не менее, в одном из случаев мы провели тестирование и под Windows с использованием IOMetter для сравнения полученных результатов с fio.
Таким образом удалось изучить производительность различных массивов на наших серверах по 12 типовым профилям нагрузки, выраженным в 3-х группах, сформированных по типу доступа.
Влияние аппаратного кэша
Как известно, кэш представляет собой промежуточный буфер быстрого доступа к информации, запрашиваемый с наибольшей вероятностью. В итоге доступ к данным осуществляется оперативнее, минуя выборку данных из удаленного источника.
Рассмотрим влияние наличия платы аппаратного кэша на примере конфигурации raid10, построенной на четырех 6Gbps дисках.
Операции последовательного доступа
Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ
Операции случайного доступа
OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ
Операции комбинированного доступа
Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ
Как видно, при установленной плате кэша, производительность возрастает примерно до 40% на операциях как последовательного, так и случайного доступа. Также на гистограммах наглядно демонстрируется, что при включении кэша, колоссально (до нескольких порядков) сокращается время реакции (latency).
Стоит отметить, что использование кэша контроллером (P400i) сервера пятого поколения, мягко говоря, нерационально.
Контроллер сервера восьмого поколения наоборот, принудительно использует кэш, проигнорировав команду на отключение.
Разница между 3Gbps и 6Gbps дисками
Напомним, что параметр «Gbps» (гигабит в секунду) являет собой максимальную скорость передачи данных между диском и контроллером, то есть 3000Mbps и 6000Mbps. При надобности пересчитать в байты делим на 10: 300MBps и 600MBps соответственно. Теоретически, при количестве более шести 3G и более трех 6G дисков, бутылочным горлышком окажется скорость шины. Собственно, попробуем оценить ширину этого самого горлышка. Следует помнить, что жесткий диск является механической системой и указанная скорость передачи данных является предельной, то есть, по факту, в полной мере недостижимой. Напомним также, что контроллер P420i сервера восьмого поколения подключен через PCIe 3.0 (8GBps).
Сравнение проводим на raid10 с включенным кэшем.
Операции последовательного доступа
Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ
Операции случайного доступа
OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ
Операции комбинированного доступа
Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ
При использовании на данной конфигурации 3Gbps и 6Gbps дисков с 10K оборотов, какой-либо принципиальной разницы нет как по параметру IOPS, так и по Latency. А вот рост производительности при использовании 6Gbps 15K весьма значителен и лучше всего заметен на операциях случайного доступа. Вывод: количество оборотов имеет значение.
К вопросу о PCIe 2.0 и 3.0: на примере конфигурации серверов Gen6, Gen7 и Gen8 с 6Gbps дисками, разница в IOPS составляет максимум 10%, по Latency и вовсе не больше 2%. Вывод: «бутылочное горлышко» PCIe 2.0 достаточно широко для конфигурации из четырех 6Gbps (600MBps) дисков.
Любопытно, что сервер седьмого поколения на конфигурации 3G 10Krpm дал худшую производительность, чем Gen 6 на этих же дисках. С чем это связано, в данном случае, сказать трудно и, возможно, будет выявлено при комплексном тестировании серверов.
Использование в сервере пятого поколения 6Gbps 15K дисков дало некоторый прирост в быстродействии, в основном за счет большего количества оборотов в секунду. Разницы между 6G и 3G десятитысячниками, ожидаемо, практически нет.
Разница между поколениями серверов
В принципе, все видно выше, но все-таки проиллюстрируем на примере raid10, построенном на четырех 6Gbps дисках.
Операции последовательного доступа
Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ
Операции случайного доступа
OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ
Операции комбинированного доступа
Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ
Как видно на графиках разница не существенная, особенно между серверами DL360Gen6, DL360Gen7 и DL360Gen8. В типовой нагрузке (профиль workstation) есть небольшая разница и с DL360Gen5. Старенький контроллер P400i в сервере DL360G5 сильно подкачал лишь на операциях последовательного доступа как по количеству IOPS, так и по времени реакции (latency), что не удивительно.
Желающие ознакомиться с детальными результатами тестирования (конфигурации raid5 и raid10 на трех, четырех и восьми дисках), могут скачать csv файл
а также, посмотреть детальные гистограммы по всем протестированным конфигурациям.
Последовательный доступ.
SQL Server Log: размер блока 64KB, 0%/100% чтение/запись, 100% последовательный доступ
Web Server Log: размер блока 8KB, 0%/100% чтение/запись, 100% последовательный доступ
Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ
Случайный доступ. Базы данных OLTP и Exchange.
OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ
Decision Support System DB: размер блока 1MB, 100% Read, 100% случайный доступ
Exchange Server: размер блока 4KB, 67%/33% чтение/запись, 100% случайный доступ
Video On Demand: размер блока 512KB, 100%/0% чтение/запись, 100% случайный доступ
Комбинированный доступ.
Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ
Web File Server64k: размер блока 64KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
Web File Server8k: размер блока 8KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
Web File Server4k: размер блока 4KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
Подведение итогов
Разница между G8 (P420i) и G6/G7 (с одинаковым контроллером P410i) составляет не более 10% на всех типах задач. Напрашивается вывод, что если исходить исключительно из соотношения «производительность дисковой системы/стоимость», G6 или G7 будут более выгодным приобретением. Комплексное сравнение производительности этих серверов мы проведем в одной из следующих статей.
Gen5 же несколько отстает: напомним, что его контроллер P400i обменивается данными с дисками на скорости 3Gbps. Видно, что на операциях случайного доступа отставание не так велико. С ростом количества операций последовательного доступа, разница растет. В принципе, компенсировать ее можно наращиванием числа дисков в массиве. Таким образом, этот сервер можно рекомендовать, как бюджетное решение для небольшой компании из 10-15 человек.
А теперь попробуем ответить на вопрос: а сколько же мне потребуется IOPS под такую-то задачу? Простой ответ: чем больше, тем лучше. С latency, соответственно, наоборот.
В первую очередь, стоит разобраться, какая именно нагрузка предвидится (что именно будет работать на сервере) и попробовать соотнести с приведенными выше результатами, имитирующими «потолок» для той или иной конфигурации.
Лучше всего — посмотреть какую нагрузку дают ваши приложения. В Linux это можно сделать с помощью программы iostat, входящей в состав пакета sysstat, которая показывает текущее состояние дисковой подсистемы.
r/s и w/s — IOPS на чтение и запись
r/await и w/await — соответственно latency.
util — уровень загруженности сервера. В наших тестах значение колеблется от 80% до 100%.
В случае Windows, замеры можно произвести утилитой perfmon.
Если пиков нагрузки, принимающих значения близкие к нашим результатам будет много и параметр util длительное время колеблется в районе 80-100% — это хороший повод задуматься над оптимизацией дисковой системы.
Возвращаясь к вопросу о выборе конфигурации под потребности небольшой компании: файловый сервер, *SQL и завязанные на нем сервисы, мы бы рекомендовали рассматривать сервер не ниже Gen 6 с контроллером P410i с массивом уровня 10 (минимум 4 диска) из соображений сочетания быстродействия и надежности (raid10 имеет гораздо меньшее время перестроения массива в случае сбоя диска) на 6Gbps 15Krpm носителях. Отметим, что экономить на плате кэша крайне не рекомендуется.
Вообще, для нас результаты тестирования оказались неожиданными. Разница в производительности дисковых подсистем ожидалась гораздо большая, особенно в случае Gen8 с его PCIe 3.0 контроллером, в сравнении с серверами шестого и седьмого поколения. Маркетинг есть, а разницы почти нет — забавно.
