Комментарии 12
Угу. LVM под xenserver'ом — путь к большой-большой печали.
При том, что просто под XEN-ом — использую в продакшене около 5 лет как с аппаратным зеркалом (кстати — от Адаптека) и с софтварным и проблем не замечал.
У меня XenServer 6.5 вообще не хочет работать с этим контроллером. Ставил чистый XenServer — сервер ребутится, если в нижнем PCI-слоте и отваливается контроллер если в любом другом. А вот на Debian на этом же железе проблем вообще никаких. Пока решения не нашел. Скорее всего что-то в ядре.
Сколько у вас хостов в пуле? Сколько виртуалок? Если <30, <3000, там вообще не о чем говорить.
При более чем 5-6 виртуалок, работающих под нагрузкой — это вообще не тот класс адаптеров, чтобы использовать. На двух хостах с 8 виртуалками (с 10Г линком между хостами) у адаптеров Адаптека никаких проблем не замечал. Возможно, на диких задачах при интенсивном вводе-выводе они и лажают. Но тогда надо использовать что-то другое. :)
Там проблема не а адаптеке, а в совершеннейше шизофреической организации LVM, при которой используется патченная версия lvm2 с всеми шансами просрать LV из-за ошибочной записи.
Если к этому добавить молча зависающие при ребуте доменов tapdisk'ки (в старых версиях они хотя бы CPU жрали в 100% и их легко отловить было, а в новых просто висят и держат залоченными LV), вызывающие необходимость вручную снимать блокировку с тома для продолжения работы, то получаем отличный комплект кластерных граблей с разделяющимися зубьями для хождения по ним.
На 5-6 виртуалках никаких проблем не будет, ибо вероятность словить неснимающийся лок пропорциональна частоте «параллельных ребутов» от нескольких гостей.
Подробности драмы можно почитать в /etc/xensource/scripts и тот п-ц, что в /opt/xenserver/sm/*.py. (да-да, на питоне парсить вывод команды ls для получения списка файлов...)
Если к этому добавить молча зависающие при ребуте доменов tapdisk'ки (в старых версиях они хотя бы CPU жрали в 100% и их легко отловить было, а в новых просто висят и держат залоченными LV), вызывающие необходимость вручную снимать блокировку с тома для продолжения работы, то получаем отличный комплект кластерных граблей с разделяющимися зубьями для хождения по ним.
На 5-6 виртуалках никаких проблем не будет, ибо вероятность словить неснимающийся лок пропорциональна частоте «параллельных ребутов» от нескольких гостей.
Подробности драмы можно почитать в /etc/xensource/scripts и тот п-ц, что в /opt/xenserver/sm/*.py. (да-да, на питоне парсить вывод команды ls для получения списка файлов...)
Почему я это прочитал только в 2017 году?
Я как-то раз решил проверить на тестовой платформе с 3805, как работает команда arcconf modify и расширить RAID10 добавлением пары дисков. Почитал документацию, написал команду, нажал Enter… arcconf задумался секунд на 30, а потом сказал что-то вроде:
>>Controller fault, rebooting kernel
После перезагрузки контроллера RAID пропал из конфигурации контроллера совсем)
А еще была проблема — ESXi периодически ложился в розовый экран, «призывно постанывая в syslog»©. Оказалось, в ESXi тайм-аут выполнения SCSI-команды вроде бы 25 с., в 3805 — 30 c., в результате рано или поздно наступает момент, когда контроллер отваливается по тайм-ауту. Вылечилось прошивкой контроллера.
>>Controller fault, rebooting kernel
После перезагрузки контроллера RAID пропал из конфигурации контроллера совсем)
А еще была проблема — ESXi периодически ложился в розовый экран, «призывно постанывая в syslog»©. Оказалось, в ESXi тайм-аут выполнения SCSI-команды вроде бы 25 с., в 3805 — 30 c., в результате рано или поздно наступает момент, когда контроллер отваливается по тайм-ауту. Вылечилось прошивкой контроллера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Восстановление потерянного тома LVM в XenServer