Задать вопрос

После обновления lvm возросла запись / чтение на дисках при использовании кеширования, что это может быть?

Здравствуйте.

Есть 4 сервера с операционной системой CentOS 7, на всех серверах стоит по 2 HDD диска и по 2 SSD накопителя. Создано 2 программных RAID-1 массива (один на HDD, другой на SSD).

Из указанных дисков HDD создано хранилище на базе LVM с кешированием на SSD дисках в режиме writeback.

После обновления пакетов lvm до версии 2.02.171-8 (последняя доступная версия в официальном репозитории), чтение с SSD дисков возросло в 2-3 раза и одновременно с этим возросла запись на HDD диски (пропорционально чтению с SSD дисков).

Хранилище используется под виртуальные машины на базе QEMU-KVM, нагрузка с их стороны не менялась. Одновременно с обновлением пакетов lvm производилось обновление всей системы (то есть ядро, qemu также были обновлены).

Ради эксперимента, на одном из серверов с низкой нагрузкой я переключил режим кеширования с writeback на writethrough, чтение с SSD и запись на HDD сразу снизились.

По ссылке https://yadi.sk/d/0a7fULcv3SrmrM можете посмотреть графики записи и чтения с дисков. На сервере 1 виден скачок чтения и записи после обновления и перезагрузки системы, на сервере 2 видно резкое снижение чтения и записи после переключения кеширования в режим writethrough.

Я пробовал искать подобные проблемы в сети, но ничего найти не смог. Также изучал https://bugzilla.redhat.com/buglist.cgi?quicksearc... и https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=... , ничего похожего не нашел.

Что это может быть? Ошибка статистики или же система действительно по каким-то причинам пишет больше, чем должна? Куда копать в данном случае?

Заранее благодарен за ответы.
  • Вопрос задан
  • 287 просмотров
Подписаться 5 Сложный Комментировать
Решения вопроса 1
@Yoh Автор вопроса
Откатился с ядра 3.10.0-693.21.1.el7.x86_64 обратно на 3.10.0-514.26.2.el7.x86_64, проблема осталась. Пробовал поставить 4.4.120-1.el7.elrepo.x86_64, проблема также сохраняется.

Откатил LVM вместе с зависимостями от 2.02.171-8 к 2.02.166-1, проблема также сохранилась.

Мягко говоря, я в замешательстве.

Обновление от 13 марта: проблему для себя решил.

Я произвел чистую установку CentOS 7.4 со всеми актуальными пакетами, на ней проблему не удалось воспроизвести. Сравнил конфигурацию хранилища LVM из каталога /etc/lvm/backup, откуда выяснил, что на всех серверах metadata_format стоит в 1, а на свежей установке у хранилища стоит 2.

Что удалось выяснить - если система была обновлена с первых версий 7 ветки (точно не помню, возможно 7.1 или 7.2 изначально была установлена), то при подключении кеширования с помощью команды lvcreate без явного указания cachemetadataformat (по умолчанию стоит auto), почему-то ставилась 1 версия. А в новой установке при тех же условиях ставилась 2 версия.

Сама проблема воспроизводилась следующим образом - режим кешировния writeback, cachemetadataformat в 1. При записи на такое хранилище, процесс вел себя достаточно странно: помимо записываемых данных (которые по логике должны попадать в кеш и на диск), система производила чтение каких-то данных с HDD (в значительно больших объемах, чем велась запись), эти данные писались в кеш на SSD, а после завершения записи этот объем данных записывался обратно на HDD. Это очень хорошо видно в связке использования fio + iostat, виртуальные машины здесь не причем, проблема воспроизводится и без них.

Решение простое: отключаем кеширование и явно указываем версию мета-данных. Ниже пример команд, может кому-то пригодятся (переменные замените под себя):

lvconvert --uncache ${VG_NAME}/${LV_NAME}
lvcreate --type cache --cachemetadataformat 2 --cachemode writeback -L${SIZE}G -n ${LV_NAME}_cache ${VG_NAME}/${LV_NAME} /dev/${SSD}
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
leahch
@leahch Куратор тега Linux
3D специалист. Dолго, Dорого, Dерьмово.
Очень похоже, что поменялся алгоритм кеширования. Но у меня встречный вопрос, а почему бы не использовать ceph?! Ваша конфигурация как раз очень хорошо под это дело подходит, KVM/QEMU отлично работает с ceph напрямую. При этом вы получите практически моментальную миграцию виртуалок, очень гибкую работу с распределеенм хранилищем, снапшоты, бекапы, восстановление, клонирование, миграцию, забудете про lvm и raid, получите или быстрый кеш на ssd, или быстрый пул. В дополнение, практически неограниченно растущее хранилище данных и облачное хранилище, вылет одно любого сервера не скажется никак на доступности данных для виртуалок.

Из минусов - память на каждый терабайт дисков нужно гигабайт памяти, и нужна сеть 10гб между серверами.

Настройка не займет больше 30 минут и часа чтения документации. Диски не нужно делать в raid! На каждом из серверов достаточно отвести по 8-100 гигов для рутового раздела и загрузки, все остальное нужно просто отдать в ceph.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы