Нужна помощь с 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
Добавлю, нарыл кое-что в логах. Похоже проблема с thin provisioning. Вот такие записи перед началом повальных ошибок с ФС:
Jan 19 17:03:40 srv01 kernel: device-mapper: thin: 253:4: reached low water mark for data device: sending event.
Jan 19 17:03:40 srv01 kernel: device-mapper: thin: 253:4: switching pool to out-of-data-space (queue IO) mode
Но, так как с thin provisioning на LVM дела не имел, буду читать..
Добавлю: да, проблема 100% с thin provisioning. Пул забит на 100%. При этом с тома все данные были удалены (перенесены). Но, т.к. этот хост был в оффлайне по причине ошибок ФС, на его брике данные остались. Данных там примерно 50% от размера брика. Сейчас он в онлайне, но данные с него не удаляются! Хотя починен fxs_repair. Ошибок пока нет, почему брик не приводится в соответствие другим? Где replicated? Как заставить сделать это его вручную? reset-brick и heal data full ни к чему не приводят!
Вообще непонятно, это нормальное поведение glusterfs? Неужели он не должен удалить удаленные с тома данные с данные с брика, который был отключен в момент удаления (привести в соответствие с другими (том REPLICATED)? Уже долгое время висит и ничего не делает, что за странная штука?
Да, разобрался. Проблема с thin provisioning. Thin provisioning pool в LVM, в котором находится раздел с данными брика заполняется на 100% и начинаются проблемы. Похоже неразрешимые.
Теперь, самое интересное, как сделать так, чтобы он не заполнялсся настолько, чтобы это начинало приводить к проблемам с ФС. Это же ненормально?! Когда стоит рабочая система настроенная, объем данных не превышает размера выделенного тома, и тут на тебе.
Нужна помощь специалистов по glusterfs. Чего-то я не понимаю из основ. И не пойму в какую сторону смотреть.
Проблема найдена. Но, я не знаю откуда ноги растут. Данные записаны на volume с помощью стандартных механизмов OVIRT. Все три брика находятся в онлайне, по моему мнению, все должно быть одинаково, replicated, нет арбитров. OVIRT показывает, что брики синхронны, каждый заполнен на 32%.
А в от вывод lvs -a с трех хостов:
LV VG Attr LSize Pool Origin Data%
Хост1: data_lv RHGS_vg_data Vwi-aot--- 497,50g data_lv_pool 54,76
Хост2: data_lv RHGS_vg_data Vwi-aot--- 498,30g data_lv_pool 74,65
Хост3: data_lv RHGS_vg_data Vwi-aot--- 497.30g data_lv_pool 54.52
Хост 2 кандидат на начало проблем топика. Почему на нем места отъелось больше в полтора раза?? Объем бриков 500Гб. Если скопировать на раздел еще 150 (это позволяет объем), Хост3 вывалится в вышеуказанные проблемы. Что с ним не так??
Больше скажу, размер данных на примонтированных дисках бриков на всех трех хостах равен!
Одинаковый вывод df-h:
/dev/mapper/RHGS_vg_data-data_lv 498G 197G 301G 40% /gluster_bricks/data
rionnagel, 2 сервера подключены по 10G, третий из-за отсутствия 10G карты подключен через 2G (LACP).
Сейчас вручную переделал разделы LVM под брики, без thin provisioning, посмотрим как будет себя вести gluster.
Alexandr Mikhailov, lacp не дает скорость ровно в 2 раза больше, больше, но не в 2, скорее в 1,5. На сколько знаю, линки все должны быть 10g минимум - по этой штуке реально могут быть проблемы. Хостов желательно 5 минимум. Но это скорее теория, не факт что к вашей ситуации применимо. Вы можете где-либо увидеть батлнек? Буду трезвый - перечитаю трэд).
В общем, проблема с ошибками на ФС XFS, как я и писал в комментариях, связана с LVM thin provisioning. Кроме того, похоже что еще и с поведением gluster. Дело в том, что при записи на том происходит постепенное увеличение размера тома thin provisioning. По какой-то странной причине % использования на трех хостах растет не равномерно. В моем случае на одном из хостов он рос в полтора раза быстрее чем на двух других. После удаления данных с тома, этот % естественно не уменьшается, нужно вручную запускать fstrim.
Так вот, после некоторого времени работы, этот том якобы дорастает до 100% (хотя данных на нем может быть гораздо меньше), и переводит ФС в некое подобие read-only. Короче, данные на ФС потрятся, gluster совсем начинает грустить, и все становится сильно плохо. Но, судя по всему это "нормальное" поведение LVM thin.
Я именно эту проблему решил тем, что создал вручную брики без использования thin lvm томов. Теперь все с моими ФС в порядке, но остались странные проблемы с gluster (не может вылечиться после нахождения в оффлайн одного из бриков), но это уже другой вопрос, оформлю как новый, может гуру подскажут.
Вообще бы интересно было прочитать более подробно. Как вы траблшутили, имеет ли к этому отношение резкого изменения количества индексных дескрипторов и ролей в отношении фс для каждого хоста. Я просто выбираю xfs, но тома сразу отжирают всё. Они на 100% зарезервированы для будущих операций.
Средний
Сложный
