Comments 10
После прочтения сложилось впечатление, что вы как-то не так готовите LVM-thin, что у вас такое страшное падение производительности на запись после сознания снапшота наблюдается.
Вот пример взятый с VM на тонком томе, на котором есть 1 снапшот:
Запись тут в пике должна быть хуже чтения раза в два, т.к. тонкий LVM поверх зеркала сделан.
Но, как видно, столь катастрофического падения скорости записи, как у вас, - нет.
У вас размер тесового файла 1гб, у меня 100гб, полагаю что в вашем кейсе во время теста весь гигабайт успел быстро преаллоцироваться (LVM выделил под него эктенты), вся дальнейшая запись велась в пределах него :)
Справедливо.
Попробовал померить на большего размера блоке, но, как выяснилось, при помощи CrystalDiskMark это вообще измерять нельзя, т.к. он перед тестом полностью прописывает весь диапазон, что приводит к тому, что экстенты заранее выделены.
А ты делал экспоненциальное аллоцирование как мы обсуждали для минимизации просадки или взял как у овирта монотонное?
"используя кластерный LVM" - это тот который CLVM+pacemaker? или это обычный LVM только презентованный на все ноды? не подходил ли вместо всего выше описаного в статье Cinder CSI driver?
В современных дистрибутивах cLVM был заменён на более современный lvmlockd, у которого есть два бэкенда: pacemaker и sanlock.
Sanlock позволяет относительно легко реализовать блокировки без необходимости настройки Pacemaker и Corosync.
Очень советую эту статью, чтобы понимать как работает кластерный LVM.
не подходил ли вместо всего выше описаного в статье Cinder CSI driver?
Cinder CSI driver позволяет общаться с опенстэком для заказа томов и подключения их к вирталкам запущенным внутри него, тем самым полностью перекладывая ответственность по менеджменту физических томов на плечи OpenStack.
Мы же имеем желание заменить OpenStack, а также предоставить эффективный способ утилизации SAN-хранилищ в Kubernetes в первую очередь на bare-metal серверах.
LVM+QCOW2, или Попытка создать идеальный CSI-драйвер для shared SAN в Kubernetes