Добрый день, друзья. После ранее опубликованной статьи много воды утекло, было поднято несколько серверов, несколько уже на новой 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 И вижу общие данные по pvedata
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 и может сдохнуть в любой момент (с потерей метаданных в этом случае – а это хуже, чем, когда система их просто не может записать). При возвращении буду думать, как избавиться от флешки другими путями (менять иили добавить диск в сервер уже нельзя). По этому поводу, товарищи, так же хотел бы услышать объективные комментарии.
Автор: vasyakrg
