Я настроил Raid 50 на хосте Xenserver с картой Perc H700 и несколько недель назад заменил диск, который вышел из строя. Рейд был восстановлен, и теперь я проверяю состояние массива через omreport:
# omreport storage vdisk
Controller PERC H700 Integrated (Slot 4)
ID : 0
Status : Critical
Name : Virtual Disk 0
State : Resynching
Hot Spare Policy violated : Not Assigned
Virtual Disk Bad Blocks : Yes
Encrypted : Not Applicable
Layout : RAID-50
Size : 14,900.00 GB (15998753177600 bytes)
Associated Fluid Cache State : Not Applicable
Device Name : /dev/sda
Bus Protocol : SATA
Media : HDD
Read Policy : Adaptive Read Ahead
Write Policy : Write Through
Cache Policy : Not Applicable
Stripe Element Size : 64 KB
Disk Cache Policy : Enabled
У меня вопрос, почему штат так долго застрял на ресинхронизации? Операции ввода-вывода не так много, так как на данный момент на хосте нет виртуальных машин. А также что включает в себя ресинхронизация?
Другой момент, о котором стоит упомянуть, - это критический уровень заряда батареи:
# omreport storage battery
Controller PERC H700 Integrated (Slot 4)
ID : 0
Status : Critical
Name : Battery 0
State : Failed
Recharge Count : Not Applicable
Max Recharge Count : Not Applicable
Learn State : Idle
Next Learn Time : 15 days 22 hours
Maximum Learn Delay : 7 days 0 hours
Learn Mode : Auto
Однако, используя Megacli, он показывает батарею как Оптимальную:
BBU status for Adapter: 0
BatteryType: BBU
Voltage: 4035 mV
Current: 0 mA
Temperature: 27 C
Battery State: Optimal
В чем причина конфликта в двух отчетах?
Заранее спасибо, пожалуйста, спросите, нужна ли вам дополнительная информация.
Возможно, что диски, с которых выполняется чтение для расчета данных «повторной синхронизации», во время процесса сталкиваются с некоторыми поврежденными блоками. Поскольку вы используете RAID50, если вы обнаружите ЛЮБЫЕ сбойные блоки с любого диска в «половине» (RAID5), который восстанавливается, это автоматически приведет к URE (называемому Dell как «прокол").
Я говорю, что подозреваю это, потому что ты видишь Virtual Disk Bad Blocks : Yes - сбойные блоки не возникают на уровне виртуального диска, если базовый RAID не «теряет» блок из-за того, что несколько частей повреждены или отсутствуют. Это одна из причин, почему производственные данные обычно намного безопаснее на RAID10 или RAID6. Почти в каждом случае, с которым я сталкивался с плохими блоками виртуального уровня, единственное исправление - это повторная инициализация RAID и восстановление из резервной копии. Единственный способ избежать этого - если этот блок просто содержит данные, которые не нужно читать (или пустое пространство на уровне файловой системы), и в конечном итоге перезаписывается ... в противном случае у вас, вероятно, есть некоторая степень повреждения данных, которая следует исследовать и решать.
Что касается несоответствия статуса батареи, я бы доверял MegaCLI, а не omreport. MegaCLI от OEM (LSI) и разработан специально для этой задачи, тогда как omreport занимается мониторингом. все компонентов оборудования Dell. Скорее всего, перезапуск служб OMSA или обновление установленной версии устранит несоответствие.
Если у вас есть действующая гарантия на систему, вы также можете рассмотреть возможность обращения в Dell за советом по обоим вопросам.