Определение причины повреждения данных GlusterFS
Я столкнулся с повреждением данных при записи данных на реплицированный том GlusterFS, который я настроил на двух серверах.
Я установил следующую конфигурацию. следующим образом:
- Серверы работают под управлением Ubuntu 16.04 и GlusterFS v3.10.6
- Клиенты работают под Ubuntu 14.04 и GlusterFS v3.10.6
- Два тома в GlusterFS сконфигурированы, каждый с двумя блоками, распределенными по одному блоку на каждом сервер.
- Каждый блок представляет собой массив MDADM RAID5 с файловой системой EXT4 / LUKS.
Каждый том настроен с параметрами по умолчанию, плюс обнаружение битов. Это следующие:
features.scrub: Активен features.bitrot: на features.inode-quota: на features.quota: на nfs.disable: включен
Повреждение данных проявляется в том, что большие каталоги копируются из локальной файловой системы на одном из клиентских компьютеров на любой из настроенных томов GlusterFS. Когда контрольные суммы md5 вычисляются для скопированных файлов и исходных файлов и сравниваются эти два, количество контрольных сумм различается.
Ручной запуск самовосстановления на одном из томов GlusterFS показывает, что файлы, идентифицированные для лечения, отсутствуют. Кроме того, глядя на вывод gluster volume bitrot и журналы вывода в /var/log/glusterfs/bitd.log и / var / log /glusterfs/scrub.log, похоже, не выявляет никаких ошибок.
Эти проблемы только проявили себя недавно, примерно после недели, когда оба тома довольно интенсивно использовались ~ 10 клиентами.
Я попытался отключить тома и протестировал запись данных в каждый из блоков напрямую через базовую локальную файловую систему, и не смог воспроизвести проблемы.
Для дальнейшей отладки проблемы я настроил аналогичная установка на виртуальных машинах в VirtualBox и не смогла воспроизвести проблему. Поэтому я не совсем понимаю, что может быть причиной этих ошибок.
Любые предложения по дальнейшим действиям по отладке, которые я мог бы предпринять, или известные проблемы с GlusterFS и моей конфигурацией были бы оценены.
Если Gluster сообщает, что повреждений нет, скорее всего, на ваших томах нет обнаруживаемых повреждений. Однако из того, что вы описываете, на этих гластерных томах нет реплик данных, кроме 1. Без нескольких репик (в идеале три полных или 2n + a) мы не можем определить, повредил ли узел свои данные, поскольку у него нет другой реплики для сравните себя с.
Один из способов обойти это - включить демон обнаружения bitrot, который по умолчанию отключен. Это позволит очищать данные с помощью контрольных сумм файлов. Это может быть сделано с помощью gluster volume bitrot VOLNAME enable . Обнаруженные ошибки регистрируются в /var/log/glusterfs/bitd.log и /var/log/glusterfs/scrub.log
Ни одна из этих ошибок не учитывает повреждение во время полета.
Вы можете проверить сами клиенты, если ничего из вышеперечисленного не приводит ни к чему, а также к любым соответствующим журналам как от клиента, так и от сервера. Вам также может потребоваться протестировать вашу сеть, клиентское или серверное оборудование на этом пути, чтобы точно определить, где происходит это повреждение. Надеюсь, вам не придется заходить так далеко.
После того, как GlusterFS не смог заставить себя вести себя должным образом, я решил переместить свою установку на NFS, с живым мастером и зеркалом, синхронизируемым каждый час или около того, чтобы обеспечить степень отказа в случае отказа основного сервера.
Недавно мы выполняли обслуживание на сервере, предоставляющем зеркало, и оказалось, что у нас были аналогичные проблемы с повреждением данных через NFS на этом сервере.
После долгой отладки возможных причин повреждения мы в конечном итоге отследили его до разгрузки оборудования на сетевой интерфейс, после того как я заметил, что мы также иногда получали ошибки Disconnecting: Packet corrected с большими пакетами через SSH.
] Изучая возможные причины ошибок SSH, я обнаружил следующий вопрос для Unix и Linux: packet_write_wait Сломан канал, даже оставив работающий верхний?
Некоторые из обсуждений в этом потоке предполагали, что драйвер сетевого интерфейса с ошибками может потенциально привести к к повреждению пакета, когда сегментация и контрольная сумма rx / tx передаются интерфейсу.
После отключения разгрузки rx / tx и сегментации (следуя инструкциям в следующем сообщении в блоге: Как решить проблемы с повреждением пакетов при отключении ssh ) и тестируя сервер при большой сетевой нагрузке, я обнаружил, что ошибки SSH и повреждение данных через NFS исчезли.
Поскольку у меня больше не настроена GlusterFS на серверах, я не могу проверить, что это было причиной повреждение данных, которое мы испытали. Однако, учитывая, что проблема сохранялась на одном из серверов после перехода на NFS, вполне вероятно, что это могло быть причиной наших проблем.
В качестве примечания, драйвер сетевого интерфейса использовал e1000e драйвер. Впоследствии я обнаружил следующее обсуждение в системе отслеживания ошибок RHEL: Ошибка 504811 - e1000 незаметно искажает данные , что предполагает, что повреждение пакета возможно в результате разгрузки оборудования на сетевой интерфейс, например, некоторые карты, использующие драйвер e1000e .