Тестирование гибридных дисковых массивов HDD+SSD в Ubuntu Linux


Как вы наверное знаете, я много работаю с системами виртуализации на базе KVM/QEMU как для продакшн-ферм, так и для организации тестирования и разработки. За время работы с OpenSource-технологиями аппаратной виртуализации я накопил достаточно большой практический опыт по оптимизации производительности различных подсистем хостов виртуализации и сегодня я хотел бы поделиться своими наработками по оптимизации производительности дисковой подсистемы на тестовых фермах.

Тестирование гибридного дискового массива в Linux

Речь сегодня пойдет о программных гибридных массивах SSD+HDD про которые я как-то уже рассказывал и сегодня мы больше сосредоточимся на тестировании этой технологии, хотя я конечно расскажу как такой массив создать и управлять им. Основная идея в использовании гибридных массивов, это получить скорости чтения-записи и количество операций в секунду соизмеримые с показателями SSD-накопителей для обычных HDD (магнитных) накопителей большого объема.

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

Тесты накопителей отдельно

Прежде чем переходить к тестированию гибридных массивов, я проведу тесты накопителей по отдельности.

Тест пропускной способности SSD диска на запись (пиковое число операций записи в секунду в секторах):

Анализ дисковой активности при линейной записи.

Анализ дисковой активности при линейной записи на SSD-диск

Тест пропускной способности SSD диска на чтение (пиковое число операций чтения в секунду в секторах):

Анализ дисковой активности при линейном чтении.

Анализ дисковой активности при линейном чтении с SSD

Тест пропускной способности HDD диска на запись (пиковое число операций записи в секунду в секторах):

Анализ дисковой активности при линейной записи.

Анализ дисковой активности при линейной записи на HDD-диск

Тест пропускной способности HDD диска на чтение (пиковое число операций чтения в секунду в секторах):

Анализ дисковой активности при линейном чтении.

Анализ дисковой активности при линейном чтении с HDD

Сумасшедший SQL-тест

Мой SQL-тест на SSD-диске

Дисковая активность.

Дисковая активность на тестовых SQL-запросах

Результаты тестирования:

TEST STARTED
=====================================
RECOVERY FROM DUMP
START
49:16-59sec
END
51:16-09sec
=====================================
BUILD INDEXES
START
51:16-09sec
END
51:16-17sec
=====================================
MAGIC UPDATE
START
51:16-17sec
END
52:16-36sec
=====================================
STRING UPDATES
START
52:16-36sec
END
53:16-28sec
=====================================
MAGIC SELECT
START
53:16-28sec
END
53:16-50sec

Все операции заняли: 3 минуты 51 секунду

Мой SQL-тест на HDD-диске

Дисковая активность.

Дисковая активность на тестовых SQL-запросах HDD

Результаты тестирования:

TEST STARTED
=====================================
RECOVERY FROM DUMP
START
09:17-24sec
END
11:17-18sec
=====================================
BUILD INDEXES
START
11:17-18sec
END
11:17-28sec
=====================================
MAGIC UPDATE
START
11:17-28sec
END
13:17-19sec
=====================================
STRING UPDATES
START
13:17-19sec
END
14:17-33sec
=====================================
MAGIC SELECT
START
14:17-33sec
END
14:17-47sec

Все операции заняли: 5 минут 23 секунду

Собираем гибридный дисковый массив с кэшированием операций записи

Устанавливаем пакет bcache-tools:

# apt install bcache-tools

Инициализируем HDD:

# make-bcache -B /dev/sdc1

Инициализируем SSD под кэш:

# make-bcache -C /dev/sdb3

Получаем UID кэширующего диска:

# bcache-super-show /dev/sdb3 | grep cset.uuid
cset.uuid               7e72f33c-7b97-4ae7-8c80-161262eb78a0

Назначаем кэш массиву:

# echo 7e72f33c-7b97-4ae7-8c80-161262eb78a0 > /sys/block/bcache0/bcache/attach
# echo 1 > /sys/block/bcache0/bcache/running

Проверяем, что у массива есть кэш:

# bcache-super-show -f /dev/sdc1 
sb.magic                ok
sb.first_sector         8 [match]
sb.csum                 D699C9241309C76D [match]
sb.version              1 [backing device]

dev.label               (empty)
dev.uuid                d4d85a5f-859f-4e8d-9127-8c65f001a633
dev.sectors_per_block   1
dev.sectors_per_bucket  1024
dev.data.first_sector   16
dev.data.cache_mode     1 [writeback]
dev.data.cache_state    1 [clean]

cset.uuid               7e72f33c-7b97-4ae7-8c80-161262eb78a0

Проверяем режим в котором работает кэш:

# cat /sys/block/bcache0/bcache/cache_mode

Включаем кэширование записи:

# echo writeback > /sys/block/bcache0/bcache/cache_mode

Сумасшедший SQL-тест

Мой SQL-тест на гибридном дисковом массиве

Дисковая активность на устройстве Bcache0.

Дисковая активность на устройстве Bcache0

Дисковая активность на SSD-кэше.

Дисковая активность на SSD-кэше

Дисковая активность на HDD накопителе.

Дисковая активность на HDD-накопителе

Результаты тестирования:

TEST STARTED
=====================================
RECOVERY FROM DUMP
START
15:09-43sec
END
16:09-56sec
=====================================
BUILD INDEXES
START
16:09-56sec
END
17:09-02sec
=====================================
MAGIC UPDATE
START
17:09-02sec
END
18:09-18sec
=====================================
STRING UPDATES
START
18:09-18sec
END
19:09-38sec
=====================================
MAGIC SELECT
START
19:09-38sec
END
19:09-54sec

Все операции заняли: 4 минуты 11 секунд

Как и предполагалось мы получили нечто среднее по производительности между HDD и SSD.