@sasa_mi
Немного интересуюсь ИТ

Нужна помощь с gluster, проблемы с файловой системой XFS, как правильно настроить volume?

Добрый день.
Несколько дней бьюсь со странными проблемами с gluster. Прошу помощи специалистов в данном вопросе.
Имеем 3 сервера, на каждом аппаратный RAID с 8 дисками, объединенными в RAID 10. Массивы разделены на 3 раздела, загрузочный, раздел для ОС и раздел для данных (sda - sda1 (boot) sda2 (lvm) sda3). Серверы на CentOS Linux release 7.7.1908 (Core), используются как хосты виртуализации под управлением OVIRT в конфигурации HostedEngine. Версия Ovirt 4.3.7.2-1.el7.
До этого было 2 сервера, поэтому для хранения дисков данных виртуальных машин использовалась NFS (в том числе настроенная на самих серверах. После того как я обзавелся третьим сервером захотелось реализовать хранение машин на GLUSTER Volume, как в конфигурации hyperconverged. Для этого собственно была переделана сеть (выделены отдельные линки для glusterfs и т.д. согласно рекомендациям мануала
После этого, с помощью ansible из-под cockpit первого хоста был создан том (volume) из трех бриков. Единственное, что смущало в тот момент - выбор возможных вариантов RAID, там только 3 варианта - RAID5, RAID6 и JBOD. Если я правильно понимаю, эта информация используется для настройки правильного dataalignment (не знаю как по русски сказать) физического тома LVM и т.д. Я думаю это больше вопросы производительности, а может быть тут и есть ответ на мой вопрос. Выбора RAID10 нет, оставил RAID6 с размером блока 256.
После создания тому я создал новый домен данных и перенес туда диски виртуальных машин. Брики наполнились данными, все было хорошо первые 2-3 дня. Далее один из серверов пришлось перезапустить, появились некоторые расхождения в self heal, не все синхронизировалось, но казалось, что это нормально и со временем лечение пройдет. Оказалось что нет, 2 каких-то файла по какой-то странной причине на разных нодах имели разные атрибуты xattrs. Попытки разобраться ни к чему не привели, было решено перенести все данные с тома, удалить том и брики, и создать том по новой. Что и было сделано.
Я не знаю, это ли привело к интересным последствиям, или они бы начали в любом случае, но имеем ситуацию, что за 2 дня сначала на одном сервере на разделе XFS с данными брика посыпались ошибки файловой системы вида:
kernel: XFS (dm-6): Failing async write on buffer block 0x3a0673f8. Retrying async write. и
kernel: XFS (dm-6): metadata I/O error: block 0x3a0673f8 ("xfs_buf_iodone_callback_error") e
rror 28 numblks 8
После чего была предпринята попытка запуска xfs_regair -L Ошибки были исправлены, но при запуске брика и его сбросе, они резко посыпались снова. Несколько попыток восстановления ФС на разделе приводило к одинаковому результату, сначала все нормально, через несколько минут - ошибки.
После удаления тома и всех связанных с ним данных разделов и т.д. была произведена еще одна попытка создания тома. Том создался без ошибок, запустился и т.д. После перенесения на него данных,, через некоторое время (несколько часов) вновь те же проблемы, но уже на ДРУГОМ сервере! На том, на котором были ошибки до этого никаких проблем!
Что делать? Куда копать? Подскажите пожалуйста, провел три дня с этою бедой, неужели придется отказаться от Gluster? Обидно, хотелось сделать что-то наподобие hyperconverged, а еще я планировал туда перенести HE, хорошо не успел.
Версию с аппаратными проблемами массива можно отбросить, корневой раздел на том же массиве, и данные NFS до этого хранились тут же, никаких проблем не наблюдалось никогда. Сервера никаких ошибок дисков не сообщают. Заранее благодарю за любую наводку.
Версии по на хостах:
OS Version: RHEL - 7 - 7.1908.0.el7.centos
OS Description: CentOS Linux 7 (Core)
Kernel Version: 3.10.0 - 1062.9.1.el7.x86_64
KVM Version: 2.12.0 - 33.1.el7_7.4
LIBVIRT Version: libvirt-4.5.0-23.el7_7.3
VDSM Version: vdsm-4.30.24-1.el7
SPICE Version: 0.14.0 - 7.el7
GlusterFS Version: glusterfs-6.6-1.el7
CEPH Version: librbd1-10.2.5-4.el7
Open vSwitch Version: openvswitch-2.11.0-4.el7
  • Вопрос задан
  • 204 просмотра
Решения вопроса 1
@sasa_mi Автор вопроса
Немного интересуюсь ИТ
В общем, проблема с ошибками на ФС XFS, как я и писал в комментариях, связана с LVM thin provisioning. Кроме того, похоже что еще и с поведением gluster. Дело в том, что при записи на том происходит постепенное увеличение размера тома thin provisioning. По какой-то странной причине % использования на трех хостах растет не равномерно. В моем случае на одном из хостов он рос в полтора раза быстрее чем на двух других. После удаления данных с тома, этот % естественно не уменьшается, нужно вручную запускать fstrim.
Так вот, после некоторого времени работы, этот том якобы дорастает до 100% (хотя данных на нем может быть гораздо меньше), и переводит ФС в некое подобие read-only. Короче, данные на ФС потрятся, gluster совсем начинает грустить, и все становится сильно плохо. Но, судя по всему это "нормальное" поведение LVM thin.
Я именно эту проблему решил тем, что создал вручную брики без использования thin lvm томов. Теперь все с моими ФС в порядке, но остались странные проблемы с gluster (не может вылечиться после нахождения в оффлайн одного из бриков), но это уже другой вопрос, оформлю как новый, может гуру подскажут.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы