Я столкнулся с повреждением данных при записи данных на реплицированный том GlusterFS, который я настроил на двух серверах.
Я установил следующую конфигурацию:
Каждый том настроен с параметрами по умолчанию, а также с обнаружением битрота. Это следующие:
features.scrub: Active
features.bitrot: on
features.inode-quota: on
features.quota: on
nfs.disable: on
Повреждение данных проявляется, когда большие каталоги копируются из локальной файловой системы на одном из клиентских компьютеров на любой из настроенных томов GlusterFS. Когда контрольные суммы md5 вычисляются для скопированных файлов и исходных файлов и их сравнивают, количество контрольных сумм различается.
При ручном запуске самовосстановления на любом из томов GlusterFS не обнаружено, что файлы для лечения не определены. Кроме того, глядя на вывод gluster volume bitrot <volname> scrub status и выход регистрируется в /var/log/glusterfs/bitd.log и /var/log/glusterfs/scrub.log похоже, не выявляет никаких ошибок.
Эти проблемы только проявили себя недавно, примерно через неделю, когда оба тома довольно активно использовались примерно 10 клиентами.
Я попытался отключить тома и протестировал запись данных в каждый из блоков напрямую через базовую локальную файловую систему, но не смог воспроизвести проблемы.
Для дальнейшей отладки проблемы я настроил аналогичную настройку на виртуальных машинах в VirtualBox и не смог воспроизвести проблему. Поэтому я не совсем понимаю, что может быть причиной этих ошибок.
Будем признательны за любые предложения по дальнейшим действиям по отладке, которые я мог бы предпринять, или известные проблемы с GlusterFS и моей конфигурацией.
После того, как мне не удалось заставить GlusterFS вести себя должным образом, я решил переместить свою установку на NFS, при этом активный мастер и зеркало синхронизируются каждый час или около того, чтобы обеспечить некоторую степень восстановления после сбоя в случае отказа основного сервера.
Недавно мы проводили обслуживание сервера, предоставляющего зеркало, и выяснилось, что у нас были аналогичные проблемы с повреждением данных через NFS на этом сервере.
После долгой отладки возможных причин повреждения мы в конечном итоге отследили его до разгрузки оборудования в сетевой интерфейс, после того как я заметил, что мы также иногда получали Disconnecting: Packet corrupt ошибки с большими пакетами по SSH.
Изучая возможные причины ошибок SSH, я обнаружил следующий вопрос для Unix и Linux: Package_write_wait Сломан канал, даже оставив работающий верхний?
Некоторые из обсуждений в этом потоке предполагали, что драйвер сетевого интерфейса с ошибками может потенциально привести к повреждению пакета, когда сегментация и контрольная сумма rx / tx передаются интерфейсу.
После отключения разгрузки rx / tx и сегментации (следуя инструкциям в следующем сообщении блога: Как решить проблемы с повреждением пакета отключения ssh) и тестируя сервер при большой сетевой нагрузке, я обнаружил, что ошибки SSH и повреждение данных через NFS исчезли.
Поскольку у меня больше не настроена GlusterFS на серверах, я не могу проверить, что это было причиной повреждения данных, которое мы испытали. Однако, учитывая, что проблема не исчезла на одном из серверов после перехода на NFS, вполне вероятно, что это могло быть причиной наших проблем.
Кстати, драйвер сетевого интерфейса использовал e1000e Водитель. Впоследствии я нашел следующее обсуждение в системе отслеживания ошибок RHEL: Ошибка 504811 - E1000 незаметно искажает данные что предполагает, что повреждение пакета возможно в результате разгрузки оборудования на сетевой интерфейс, например, определенные карты, использующие e1000e Водитель.
Если Gluster говорит, что повреждений нет, скорее всего, на ваших томах нет обнаруживаемых повреждений. Однако из того, что вы описываете, на этих гластерных томах нет реплик данных за пределами 1. Без нескольких репик (в идеале три полных или 2n + a) мы не можем определить, повредил ли узел свои данные, поскольку у него нет другой реплики для сравните себя с.
Один из способов обойти это - включить демон обнаружения bitrot, который по умолчанию отключен. Это позволит очищать данные с помощью контрольных сумм файлов. Это можно сделать с помощью gluster volume bitrot VOLNAME enable. Обнаруженные ошибки регистрируются в /var/log/glusterfs/bitd.log и /var/log/glusterfs/scrub.log
Ничто из этого не объясняет коррупцию в полете.
Вы можете проверить самих клиентов, если ничего из вышеперечисленного не обнаруживает, и любые соответствующие журналы как от клиента, так и от сервера. Вам также может потребоваться протестировать вашу сеть, клиентское или серверное оборудование на этом пути, чтобы точно определить, где происходит это повреждение. Надеюсь, вам не придется заходить так далеко.