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


Администрирование операционных систем на базе Linux (Debian/Ubuntu и Centos/RedHat) Виртуализация серверов и рабочих станций в Windows и Linux - Hiperv, KVM, VMWare Мониторинг серверов и сетевой инфраструктуры при помощи Zabbix
hdd linux server нагрузка
 
 

* В этом блоге я описываю свою повседневную рабочую практику, поэтому все статьи в блоге написаны лично мной и при копировании их на свой сайт пожалуйста указывайте ссылку на страницу откуда вы скопировали.
* Если какая-то статья вам помогла, то вы можете дать мне немного денег вместо простого спасибо (ссылка на форму поддержки проекта внизу страницы), если вы что-то не поняли или у вас что-то не получается, то вы можете нанять меня и я вам все подробно расскажу (расценки и ссылки в конце статьи).


(последние правки 3 недели, 3 дня)

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

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

 

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

Моя официальная страница на FaceBook
Мой микроблог в твиттер

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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


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

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