Proxmox 4. День второй. Thin-LVM

    Добрый день, друзья. После ранее опубликованной статьи много воды утекло, было поднято несколько серверов, несколько уже на новой 5-ой версии. Были и кластеры и CEPH и даже репликация с двумя нодами (появилась функция в 5-ке). Для себя принял решение (как и советовали в прошлых комментариях), что проще и удобнее ставить debian, правильно размечать диски и поверх рабочего soft-raid поднимать proxmox.

    О разметке, о VLM и о тонких дисках далее и пойдет речь.

    На одном сервере столкнулся с очень большой и неприятной вещью. Сервер отдельный, на debian 8. При разметке, в которой отдельное большое место выделяется под thin-lvm диск для хранения дисков виртуальных машин, есть одна тонкость, которую я не учитывал ранее.

    Пример реальной конфигурации: создан soft raid-10 из 4 дисков по 3 Тб.

    Из общих 5,7 Тб выделен отдельный диск в 5,37 типа LVM-Thin для дисков виртуалок. Размещены виртуальные машины, общий выделенный объем дисков которых составил 4,03 ТБ. Машины работали себе и понемногу заполняли диски. Заполнение за полгода составило в среднем на 20-30% в каждой из виртуалок.

    В очередной день (естественно понедельник, который совпал еще и с первым днем долгожданного отпуска) наш сервер zabbix начал лихорадочно отправлять через телеграмм уведомления от витруалок. Сначала про отказы отдельных сервисов типа http или ssh, а потом и вовсе про потерю пингов. Полез подключаться через ssh на почтовую виртуалку, тормозит, с первых пары секунд ничего не понятно, тут прилетают еще с десяток сообщений от zabbix о проблемах других виртуалок. Боковым взглядом понимаю, что плохо у всех виртуалок, кроме самого гиперзивора. Залезаю на него и открываю консоль первой же проблемной машины.

    И вижу

    Заголовок спойлера
    device-mapper: message ioctl on failed: Operation not supported

    Первым, что подумал, рассыпался soft-raid. Но почему не было уведомления на эту тема от самого гипера – раз, почему гиппер работает внешне корректно – два.

    Лезу на lvm –a И вижу общие данные по pve\data

    Data% — 23,51%
    Meta% — 99,95%

    Шах и мат.

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

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

    Учитывая, что попасть в наш местный форд нокс, где находится этот сервер сложновато, теряем кучу времени, отправляем атишника с флешкой на 8Гб. Через 1,5 часа он на месте, вставляет флешку, я добавляю ее в группу lvm, расширяю meta диск еще на 3 Гб командой:

    Заголовок спойлера
    lvresize --poolmetadatasize +3G pve/data

    И получаю в итоге Meta% — 1,58%

    Перезапускаю по очереди машины, проверяя их диски и исправляя проблемы руками, т.к. некоторые (например, почтовый сервер) не захотели без проблем и исправлений по sfck запускаться по-человечески. И наконец-то решаю проблему.

    Что это было, Карл? — спрашиваю я себя.

    Создавая раздел Thin-LVM и добавляя его в proxmox я и не думал, что надо вручную учитывать емкость метаданных, вычислять их на калькуляторе и задавать вручную при создании диска. Почему такие важные, критичные показатели никак не мониторятся к примеру через тот же GUI Proxmox?

    Ребята, если не сложно, в комментариях, очень прошу высказаться по этому поводу, что сделано не так, почему очень мало написано про создание Thin и именно про meta данные. И какие есть варианты решения проблемы помимо моего. Далеко не всегда рядом может оказаться авторизованный человек с флешкой, которого пустили в ДЦ, дали доступ в стойку, а я, находясь в отпуске за 1 тыс км, сумел-таки простоем в 2 часа решить проблему.

    P.S.: Ну и результат конечно же меня не устраивает. Флешка таки торчит в сервере. Добавлена в группу LVM и может сдохнуть в любой момент (с потерей метаданных в этом случае – а это хуже, чем, когда система их просто не может записать). При возвращении буду думать, как избавиться от флешки другими путями (менять и\или добавить диск в сервер уже нельзя). По этому поводу, товарищи, так же хотел бы услышать объективные комментарии.
    Share post

    Comments 35

      0
      Ну, в DL120 G6 нельзя просто взять и установить еще один диск к четырем имеющимся LFF.
      Хотя внешний-то можно — например, подключить USB HDD/SSD, или хранилище какое по iSCSI или NFS.
      Второй момент — я и в первой статье не увидел, в чем была причина и необходимость перехода с ESXi на Proxmox/Debian?
        0
        Верно — мы и добавили флешку на 8 гигов.
        Не представляю как диск с метаданными расширить на сетевом хранилище… во-первых, lvm нужны физические диски, а во-вторых, при потере связи метаданные повредили бы и сами диски с виртуалками.

        Переход был вызван тем, что Esxi не видит программный raid. А на дебиан был поднят и soft-raid и lvm
          0

          Зато esxi прекрасно работает и с nfs и с iscsi, что могло решить проблему.

            0

            Так и проксмокс тоже!

        0
        Родной аппаратный RAID для этого сервера (SA P411) б/у — 10-12К рублей на развалах (avito, ebay и иже с ними). Это точно стоило последующего геморроя?
        lvm, насколько я знаю, прекрасно прожует и подключенные по iscsi диски (сам пробовал только ради экспериментов, не в продакшне под нагрузкой, разумеется).
          0
          iscsi диски — возможно. попробую на досуге. но в любом случае, не вариант расширять на них раздел с метаданными. разве что емкость (но с ней то проблем не было).
          по аппаратному — да, можно купить. но 12-14к — это треть стоимости этого сервера. уже не рентабельно.
            +1

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

              0
              смигрирую. а как потом быть с самим разделом LVM?
              как я это вижу — развалить пустую группу и пересобрать снова.
              только при сборке сначала создать раздел с метаданными и руками задать ему размер в 5 гигов например, а потом все оставшееся место 100%FREE?
              ну и переехать виртуалками обратно.
            0

            Прекрасно на прод кластера у меня 5 лет работало. Один из рекомендованных проксмоксом вариантов. LVM in iSCSI

              +1
              Тут немного другая ситуация — когда блочным устройством по iSCSI предполагается нарастить lvm, уже собранный на локальных дисках. Немного бредовато получается, оттого и опасения — но в рамках сервера без полной замены хардов расти некуда.
              Да и харды особо не наменять — сервер весьма не новый, и если с >2TB дисками еще проблема как-то решается, то вот гарантированно совместимые харды (Seagate Constellation ES всех серий, HGST A7K2000 серии и пр. подобные) найти будет уже не просто, а современные очень не всегда в старье заводятся (разумеется, речь даже не о дисках с 4К блоком, а о 512e/512n).
            0

            Ваши сервисы стоят дешевле 12к рублей?

              0

              Может попробовать по этой доке — https://www.systutorials.com/docs/linux/man/7-lvmthin/ — увеличить место под metadata-pool?
              Если в volume group место еще есть, конечно.
              Конкретные инструкции в разделе "Metadata space exhaustion".

                0

                И посмотрите, не осталось ли snapshot-ов виртуалок в LV.
                Promox мог оставить после бекапов. Или может вы сами делали.

                  0
                  Снапы я перестал делать довольно давно.
                  0
                  Места нет. Одной командой в этой статье можно увеличить размер меты. Причем ирония в том, что хватило бы и 500мб
                    0

                    Тогда разве что забекапить ВМ по одной. Удалить вместе с LV. И разбекапить обратно.

                      0
                      все верно. только есть несколько НО.

                      1) удалить диски виртуалок не получится. потому как, даже процедура удаления требует изменения меты, у которой нет места.
                      2) забекапить надо куда то. выше ребята в комментах подсказали отличную идею с цеплянием по сети репозитория и переноса дисков туда. идея отличная (в моем случае репы не было и пришлось бы все равно нести в ДЦ USB-диск большой).
                  0
                  Нафиг этот LVM нужен, когда Proxmox из коробки умеет отлично работать с ZFS?
                    0

                    Возможно потому, что ZoL из коробки всё ещё не умеет отлично работать.

                      0
                      Zol отлично работает из коробки. Не хватает только поддержки trim для SSD, но это скорее из-за из параноидально безопасного подхода разработчиков к сохранности данных. Многие производители SSD реализуют trim настолько плохо, что были неоднократные случаи потери данных на EXT4 и других фс. Погуглите.
                        0

                        К сожалению не всё так радужно.
                        При высокой I/O нагрузке на zfs, даже только на чтение, система начинает залипаться и тупить.
                        Конкретно Proxmox 5.0 + последний ZoL 0.6.5.11 при работе бекапов.
                        И это не рабочий сервер под нагрузкой, а тестовый.
                        Диски правда не SSD.


                        Если использовать хранилище на LVM / Dir + (ext|x)FS — таких диких лагов не наблюдается.

                          +1
                          Если у вас не контейнеры, а виртуальные машины, то диски хранятся на zfs volume (zvol), а для них Proxmox делает по умолчанию размер блока 8кб. Попробуйте использовать больший размер блока (128кб, как в датасетах). Так же могут наблюдаться проблемы с IO из за swap раздела на zfs volume. Попробуйте отмонтировать swap, если проблемы с IO исчезнут, используйте другую FS для SWAP или настройте оптимальный размер блока.

                          Вообще имея zfs можно вместо бэкапов делать реплики на уровне файловой системы. Это вообще не нагружает систему, т.к. Zfs не нужно сравнивать файлы и совершать какую либо работу, что бы получить разницу между 2 снимками.
                            0
                            Если интересно, поделюсь скриптом.
                              0
                              интересно. поделитесь.
                              попробую все это собрать на тестовой машине и погонять под нагрузкой.
                              0
                              Так же для swap нужно выставить logbias=throughput, это серьезно уменьшит накладные расходы.
                                0
                                • используем контейнеры, данные — в датасетах
                                • recordsize = 32k
                                • без дедупликации
                                • включено сжатие lz4
                                • arc_max_size = 4G
                                • logbias оставлен на latency, на throughput еще хуже лагает
                                • swap на отдельном разделе, не на zfs. да и почти не используется.
                          0
                          Ну хотя бы потому, что на сервере всего 10мб ОЗУ
                            0
                            Память не проблема. ARC кэш можно ограничить или отключить через файл
                            /etc/modprobe.d/zfs.conf

                            options zfs zfs_arc_max=8299967296 # (по умолчанию 50% от общего объема памяти)

                            # arc_sys_free — количество памяти которое нужно оставлять свободным. По умолчанию 1\64 от общего объема :)
                            options zfs zfs_arc_sys_free=6442450944 # (оставлять 6 гб свободной памяти)
                              0
                              #To apply this change immediately without a reboot, issue the command:

                              echo 8299967296 >> /sys/module/zfs/parameters/zfs_arc_max
                              echo 6442450943 >> /sys/module/zfs/parameters/zfs_arc_sys_free
                            0
                            По-моему скромному опыту, ZFS не всегда хорошее решение. Имел проблемы с зависаниями виртуалок крутящих MSSQL. В основном это касается слабых дисковых подсистем, там ext4+LVM вполне стабильное и рабочее решение. Плюс ZFS надо памятью кормить
                            0
                            У меня используется PVE+LXC+LVM thin и есть пара моментов
                            1. Нужно использовать trim
                              man lvmthin
                              описано в разделе Using fstrim to increase free space in a thin pool LV При этом уменьшается использование не только Data, но Меtadata
                            2. Обязательно использовать мониторинг lvm thin томов, например, через zabbix
                              0
                              а про второй пункт можно подробнее?
                                0
                                Обычный zabbix discovery, который ищет lvm thin pool, lvm thin volume на PVE ноде через zabbix agent За основу я брал share.zabbix.com/operating-systems/linux/lvm-thin-pool-and-lvm-thin-volume-monitoring-template — пришлось поправить сам шаблон (он не импортируется в zabbix 3.2) и userparameter_lvm.conf (выхлоп lvs немного отличается)
                                  0
                                  у меня в3.5 zabbix отлично импортировался. удобно, спасибо!
                                0
                                По второму пункту есть иные способы загонять данные в zabbix помимо парсинга вывода
                                lvs -a
                                и UserParameter в конфиге zabbix?
                                Я мониторинг lvm пока только так себе вижу

                              Only users with full accounts can post comments. Log in, please.