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

by Anton Chernousov aka GITA-DEV


Опубликовано: 06 Сен 2018 (последние правки 2 недели, 1 день)


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

Небольшое вступление, строчек так на пять в кратце описывающее о чем в статье пойдет речь. Без переносов строк, так как оно пойдет в Description.

Запуск шести (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:


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


Обратите внимание на статьи:


Подробный мониторинг состояния дисковой подсистемы Linux при помощи Zabbix

Подробный мониторинг состояния дисковой подсистемы Linux при помощи Zabbix

Для серверов виртуализации необходимо постоянно следить за состоянием дисковой подсистемы, и это не ограничивается банальным iowait, гораздо более важным параметром является например длина дисковой очереди. Так же не забываем мониторить состояние SMART и статус программных дисковых массивов.


Ваш собственный облачный центр виртуализации (WebVirtMgr умер! Да здравствует WebVirtCloud panel!)

Ваш собственный облачный центр виртуализации (WebVirtMgr умер! Да здравствует WebVirtCloud panel!)

Только я хотел рассказывать о одном довольно старом внедрении Web-сервиса управления парком виртуальных машин на базе полностью открытых решений, как оказалось что проект WebVirtMgr был закрыт и теперь существует в своей новой ипостаси уже с модной приставкой Cloud. Итак друзья мои, сегодня я буду устанавливать и настраивать WebVirtCloud panel.


Подготовка KVM-Libvirt инфраструктуры (удаленное подключение с поддержкой авторизации)

Подготовка KVM-Libvirt инфраструктуры (удаленное подключение с поддержкой авторизации)

Сегодня я расскажу и покажу как настроить удаленное управление гипервизором KVM/Qemu. Одним из ключевых моментов построения современных систем виртуализации ориентированных на продакшн-использование является централизованное управление и естественно, что централизация управления достигается использованием API. Одним из API для управления гипервизорами KVM/Qemu является Libvirt и стоит отметить, что эта библиотека, позволяет управлять не только KVM/Qemu, но и LXC.


Установка Zabbix-Agent версии 3.4 в Ubuntu Linux 16.04

Установка Zabbix-Agent версии 3.4 в Ubuntu Linux 16.04

Небольшая инструкция по подключению репозитария и установке zabbix-агента версии 3.4 в Ubuntu Linux 16.04


Тестирование среднего тока работы HDD-накопителей (подключение HDD для Babana PI M1)

Тестирование среднего тока работы HDD-накопителей (подключение HDD для Babana PI M1)

Как все инженеры, я предварительно прочитал спецификацию на накопитель который хотел использовать в своем проекте и там был указан максимальный потребляемый ток по шине 12 вольт равный 0.4 ампера и я кстати был совершенно не удивлен когда у меня на лабораторном блоке питания с выставленным током защиты в 1А защита таки сработала. Ну, что сказать, это маркетинг и лучше провести реальные замеры прежде чем что-то проектировать, поэтому делюсь своими наблюдениями проведенными с рядом накопителей.


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .

Блог это некоммерческий проект! Если вам понравился мой блог и то что я пишу помогло вам на практике, то можете сказать спасибо материально.