|
К тестированию производительности дисковой подсистемы нас подтолкнула двухчасовая установка виртуальной машины FreeBSD 8.1 под Vmware ESXi 4.1 на, современных серверах HP Proliant DL160 G6 с SATA дисками, в то время, как без VMware эта же процедура занимает порядка 15-20 минут и примерно аналогичное время тоже под VMware но на сервере с RAID контроллером, имеющим кэш. Поскольку мы не хотели полагаться на волю случая, мы решили тестировать на разных конфигурациях и с разными дисками.
В качестве подопытных кроликов фигурировала FreeBSD 8.1 версий под платформы AMD64 и i386, но поскольку различия результатов находилось в пределах погрешности, будут приведены результаты FreeBSD 8.1 AMD64. Линейная производительность дисков прекрасно известна, результаты можно без труда найти в Сети. Нас же сейчас интересует именно производительность дисковой подсистемы в условиях виртуализации. Для простоты будем просто писать в файл нули командой:
dd if=/dev/zero of=test bs=1M count=100
или
dd if=/dev/zero of=test bs=1M count=1000
ну или
dd if=/dev/zero of=test bs=1M count=10000
Командой dd мы пишем нули (/dev/zero) в файл test блоками размером 1Mb и количеством от 100 до 1000. То есть от 100 Мб до 1 Гб или 10 Гб. Чтобы меня не обвинили в подлоге вывода команды dd, признаюсь сам: я сам руками расставил апострофы в поле скорости для облегчения восприятия.
Итак, начнем тест с варианта RAID 5 из 5 SAS дисков с контроллером, оснащенным 256Mb кэша.
104857600 bytes transferred in 0.372477 secs (281’514’434 bytes/sec)
Очевидно, что данные были заброшены в кэш и целиком там поместились. Запись будет произведена «как-нибудь потом, при случае», однако пользователь продолжает работу с данными, и это уже «не его печаль».
А вот с гигабайтом этот фокус уже не пройдет. Гиг в кэш не влезает:
1048576000 bytes transferred in 6.246920 secs (167’854’882 bytes/sec)
Ну и для очистки совести (а вдруг в оперативке где...) 10 Гб:
10485760000 bytes transferred in 70.108128 secs (149’565’540 bytes/sec)
Скорость упала, но остается весьма и весьма высокой. Поднять ее, видимо, можно было бы заменой RAID5 на RAID10, но с кэшем. Это понятно. Мы же усложним задачу.
Возьмем систему с SAS дисками в RAID10, но построенную на контроллере без кеша (ZM). Пишем один гигабайт:
1048576000 bytes transferred in 46.932269 secs (22’342’325 bytes/sec)
???
Так. Пишем 10 гиг.
10485760000 bytes transferred in 445.471986 secs (23’538’540 bytes/sec)
Очевидно это и есть искомый скоростной предел. Ок, пишем 100 Мб:
104857600 bytes transferred in 2.255507 secs (46’489’592 bytes/sec)
Видимо используются системные ресурсы кэширования. Идем дальше. Проверим SATA.
Пока еще RAID10:
1048576000 bytes transferred in 92.511495 secs (11’334’548 bytes/sec)
Однако. Запускать на запись 10 гб даже желания не возникает, зато возникает желание посмотреть что же будет на обычном «зеркале», без RAID 10, просто RAID 1:
1048576000 bytes transferred in 117.557897 secs (8’919’656 bytes/sec)
Мда. Без комментариев. К вышесказанному могу добавить, что результаты не претендуют на истину в последней инстанции. Получались разные цифры, но эти цифры ярко отражают реальное положение дел в работе FreeBSD под Vmware с использованием разных дисков. Могу лишь добавить, что зачастую на RAID 1 SATA я получал реальную скорость в районе 6,5 mb/s, что, разумеется, неприемлемо для нормальной эксплуатации сервера. В качестве, например, файлового сервера. Зачем нам файловый сервер со скоростью записи как у флэшки, еще и не самой быстрой?.. Безусловно, основная вина за данный "epic fail" лежит на слабой оптимизации гипервизора VMware ESXi 4.1 и его драйверов для работы FreeBSD.
Без Vmware на тех же самых машинах имеем:
SATA RAID10(ZM)
1048576000 bytes transferred in 15.300323 secs (68’532’932 bytes/sec)
На этом же самом сервере с нативной системой FreeBSD 8.1 AMD64 на RAID1 SATA я получил порядка 60Mb/s. Порядок цифр ясен.
SAS RAID10 (ZM)
1048576000 bytes transferred in 6.838939 secs (153’324’369 bytes/sec)
Без комментариев, как говорится.
Эксперименты проводились на группе серверов параллельно, во избежание кэширования результатов первых для облегчения работы следующих.
А мораль сей басни такова.
То, что мы наблюдали – этакая «модель сферического коня в вакууме». То есть работа в идеальных условиях. Системы были свежеустановлены, без нагрузки. На практике же все будет намного хуже. Не экономьте в сервере на приличном контроллере и памяти для него – сэкономите нервы и себе и пользователям. Работа типичного сервера подразумевает постоянное оперирование файлами небольшого объема. И вот здесь как раз наличие кэша в 256 или 512 Мб у контроллера сложно переоценить. Сюда прекрасно поместятся все ваши типичные документы, таблицы, картинки итд. Ну и наконец, оставьте SATA для домашнего использования. Использование в коллективной работе дисков с малой пропускной способностью, микроскопическим кэшем и малым временем наработки на отказ на выходе обернется снижением производительности коллектива в целом. А для админа – мучительная установка самого сервера, а затем постоянные жалобы на производительность сервера со стороны пользователей. Так как разница в реальной работе будет на порядки! Минимум на один. То есть в 10 раз. А в некоторых случаях (групповая работа с многочисленными мелкими файлами) и на 2 порядка. То есть в 100 раз. Просадка производительности SATA на контроллере без кэша, по сравнению с SAS на контроллере без кэша велика. По сравнению с SAS с кэшем - чудовищна.
Оптимальный выбор – это полноценный контроллер (например P212 или P410) с памятью (хотя бы 256 Mb, а лучше 512 Mb с BBWC) и SAS диски.
При съемках этих экспериментов ни одного кролика не пострадало. Кроликами выступали: HP Proliant DL160 G6 Intel Xeon Quadro Core E5504, 4Gb RAM, P410 (ZM), HDD SATA 1Tb, HDD SAS 300Gb. В качестве недостижимого эталона выступал аналогичный сервер с кэшем 256Mb и 5-ю дисками 146Gb в RAID5.
|