У нас есть среда VMware vSphere 5, в которой работают виртуальные машины CentOS 5.8. За последние две недели у нас было пять случаев повреждения файловой системы виртуальных машин, что потребовало восстановления с помощью fsck.
Вот что мы видим в логах:
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392098: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:39:28 hostname kernel: Aborting journal on device dm-2.
Nov 14 14:39:28 hostname kernel: __journal_remove_journal_head: freeing b_committed_data
Nov 14 14:39:28 hostname last message repeated 4 times
Nov 14 14:39:28 hostname kernel: ext3_abort called.
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Nov 14 14:39:28 hostname kernel: Remounting filesystem read-only
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392099: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:31:17 hostname ntpd[3041]: synchronized to 194.238.48.2, stratum 2
Nov 14 15:00:40 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2162743: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 15:13:17 hostname kernel: __journal_remove_journal_head: freeing b_committed_data
Эта проблема кажется происходить, пока мы синхронизируем данные приложения с другого сервера. Пока нам не удалось воспроизвести проблему или определить основную причину.
После того, как у нас возникла эта проблема на нескольких серверах, мы предположили, что возникла проблема с шаблоном, поэтому мы отказались от всех клонированных виртуальных машин из шаблона, уничтожили шаблон и создали новый шаблон с нуля, установленный из недавно загруженной CentOS. ISO.
Мы используем HP EVA SAN для хранилищ данных и перешли с 4400 на 6300 после первой проблемы. С момента перемещения и восстановления новых виртуальных машин мы сталкивались с этой проблемой дважды. На одной виртуальной машине мы выключили сервер, удалили два виртуальных процессора и снова загрузили его, проблема возникла почти сразу. На другой виртуальной машине мы ее перезагрузили, и проблема возникла через полчаса.
Любые советы или указатели в правильном направлении будут оценены.
Существует база знаний о HP EVA, особенно если вы используете Round Robin PSP. Во-первых, вы должны проверить vmkernel.log на наличие ошибок хранилища. Соответствующая запись в базе знаний (pdf)
Чтобы оптимизировать производительность массива EVA, HP рекомендует изменить значение IOPS для балансировки нагрузки циклического перебора по умолчанию на 1. Это обновление необходимо выполнить для каждого виртуального диска с помощью следующей команды на ESX4.x:
esxcli nmp roundrobin setconfig -t iops -I 1 -d naa.xxxxxxxxx
Для ESXi5:
for i in `esxcli storage nmp device list | grep naa.600` ; do esxcli storage nmp psp roundrobin deviceconfig set -t iops –I 1 -device $i; done
Если проблема может быть воспроизведена только тогда, когда вы синхронизируете данные с одного сервера на другой, это означает, что это связано с тем, как согласованность данных видна с точки зрения ядра. Если ядро считает, что файловая система будет повреждена или имеет какие-то повреждения, оно переведет файловую систему в режим только для чтения.
Я ничего не знаю о HP EVA, но есть ли у него кэш записи с автономным питанием. Если да, можете ли вы отключить кеш записи на диск и использовать кеш записи массива SAN. Для этого смонтируйте с помощью mount -o барьер = 1 и посмотрите, заметите ли вы какие-либо улучшения.
И у меня есть инстинкт, что это как-то связано с памятью, а не с ошибкой fs. Я не знаю, как это доказать, но в большинстве случаев, которые я видел о повреждении файловой системы, каким-то образом и где-то виновато, если не главное, хранилище.