Тестирование гибридного программного массива (HDD+SSD) (оптимизация фермы виртуализации)

Сегодня я немного поэкспериментирую с гибридным программным массивом состоящим из обычного жесткого диска и кэширующего твердотельного накопителя. Эксперимент должен оказаться довольно интересным, хотя средства измерения показывают погоду на Марсе и у меня все никак не доходят руки переписать скрипт собирающий сведения по IOPS-ам при дисковой активности.

 
 
Логотип GITA-DEV

Автор: Черноусов Антон aka Gita-Dev
Опубликовано: 06 Сен 2018 (последние правки 5 месяцев, 1 неделя)

dev ubuntu

Запуск шести (Windows Server) виртуальных машин одновременно начало эксперимента 14:41. Как вы видите скорость чтение/записи на диск небольшая, но утилизация диска 100%, что характерно для реальных условий работы систем виртуализации с большим количеством конкурирующих запросов. Будем считать, что эксперимент завершился когда дисковая активность спала до минимума в 14:54.

Скорость чтения-записи на диск при этом эксперименте:

Утилизация диска и дисковая очередь:

Я использовал планировщик ввода-вывода cfq (он используется по умолчанию в Ubuntu Linux).

# cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]

В следующем эксперименте (до тестирования гибриных массивов) я сменю планировщик на deadline и проведу абсолютно идентичный тест с теми же образами шести виртуальных машин.

# echo deadline > /sys/block/sdb/queue/scheduler
# cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq

Начало эксперимента в 15:25 в режиме deadline окружение пользователя полность остновилось и если с cfq-планировщиком я вполне себе работал в браузере (писал эту статью), то в режиме deadline я просто ушел пить кофе, так как курсор мыши более ни на что не реагировал. Это кстати видно по графикам, где даже заббикс не смог отправить данные по дисковой активности. Тест занял как и в предыдущем случае те же 15 минут, поэтому я не уверен что режим deadline принесет какие-то ощутимые дивиденды для фермы виртуализации.

Скорость чтения-записи:

Дисковая очередь:

Собираем гибридный дисковый массив bcache из нашего тестового HDD и SSD на 128 гб. Во первых, инициализируем HDD для использования его в гибридном массиве bcache:

# make-bcache -B /dev/sdc1 
UUID:                  221e020c-f257-4b90-a665-7c8db35e5b34
Set UUID:              e3b49d5d-2ca7-4fff-bb5c-ccd2b6ae512f
version:               1
block_size:            1
data_offset:           16

Далее, мы инициализируем кэширующий диск SSD:

# make-bcache -C /dev/sdb1
UUID:                  5b4d2510-3517-4aea-aa99-08e4edc1a310
Set UUID:              45b7a4ff-f7e0-4768-aac1-c6581e24e290
version:               0
nbuckets:              244140
block_size:            1
bucket_size:           1024
nr_in_set:             1
nr_this_dev:           0
first_bucket:          1

Добавляем кэширующий диск к нашему HDD для чего нам понадобится идентификатор кэширующего диска:

# bcache-super-show /dev/sdb1 | grep cset.uuid
cset.uuid              45b7a4ff-f7e0-4768-aac1-c6581e24e290

И выполняем команду:

# echo 45b7a4ff-f7e0-4768-aac1-c6581e24e290 > /sys/block/bcache0/bcache/attach

Запрашиваем сведения о массиве bcache0:

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

dev.label              (empty)
dev.uuid               221e020c-f257-4b90-a665-7c8db35e5b34
dev.sectors_per_block  1
dev.sectors_per_bucket 1024
dev.data.first_sector  16
dev.data.cache_mode    0 [writethrough]
dev.data.cache_state   1 [clean]

cset.uuid              45b7a4ff-f7e0-4768-aac1-c6581e24e290

Убедившись, что к HDD теперь добавлено кэширующее устройство мы можем создать на устройстве /dev/bcache0 раздел и смонтировать его для теста. Естественно, что в тесте принимают участие все те же образы дисков и одновременный запуск шести виртуальных машин, режим кэширования writethrough (безопасный).

Начало теста 11:33 и представляю вашему вниманию график утилизации диска и дисковой очереди:

Скорость чтения-записи:

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

Для полностью тестовой системы где не критична потеря данных, мы можем переключить режим кэширования с writethrough на writeback:

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

И это даст некоторый прирост быстродействия (но очень опасно), тест начали в 13:03.

Утилизация дисковой подсистемы в режиме writeback:

Чтение/запись гибридного массива в режиме writeback:

 

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

Отзывы и комментарии