отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Алерты RTMT: Consistency Check inconsistency logging disabled на серверах MCS 78XX серии I

При работе CUCM на аппаратных серверах MCS 78XX серии I возможно появления таких алертов в RTMT:

At Sat Oct 08 03:02:21 MSK 2016 on node , the following HardwareFailure events generated: 
hwStringMatch : Oct  8 03:01:52 cucm-mcs78XX-I daemon 4 Director Agent: LSIESG_AlertIndication 500405C002448BC0 Consistency Check inconsistency logging disabled on VD 00/0 (too many inconsistencies) Sev: 3.
AppID : Cisco Syslog Agent
ClusterID :
NodeID : cucm-mcs78XX-I
TimeStamp : Sat Oct 08 03:01:52 MSK 2016

hwStringMatch : Oct  8 03:01:52 cucm-mcs78XX-I daemon 4 Director Agent: LSIESG_StorageVolume_Modified 500405C002448BC0 Consistency Check inconsistency logging disabled on VD 00/0 (too many inconsistencies) Sev: 3.
AppID : Cisco Syslog Agent
ClusterID :
NodeID : cucm-mcs78XX-I
TimeStamp : Sat Oct 08 03:01:53 MSK 2016

Согласно техническому документу IBM появление данных ошибок для RAID массивов уровня 1 - mirror (а именно они сконфигурированы на MCS серверах) не является проблемой. Ошибка означает различие в не в самих данных, а в контрольных суммах посчитанных для блоков данных на основном и резервном дисках.
По всей видимости во время записи данных на диски контроллер не успевает считать контрольную сумму для резервного диска и делает это отложенной операцией.

Вот некоторые причины, которые могут приводить к возникновению данной ситуации:

- отсутсвие кэш памяти на контроллере (это не наш случай, т.к. в MCS серверах всегда установлены RAID контроллеры с кэг памятью)
- на RAID контроллере установлен режим Write Through
- высокая утилизация swap-а операционной системой
- очень большое кол-во операций ввода-вывода

Подробнее см. в оригинале:
https://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5092480

После появления таких ошибок нужно собрать сделающую диагностику с CLI CUCM:

show hardware
utils create report hardware (нужно будет забрать созданные файлы по SFTP)

В выводе команды show hardware нас интересуют:

- состояние логического диска (RAID-1 – mirror):

Logical Drives Information:
==========================
Virtual Disk: 0 (Target Id: 0)
RAID Level: Primary-1, Secondary-0, RAID Level Qualifier-0
Size:135.972 GB
State: Optimal
Stripe Size: 128 KB
Number Of Drives:2
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

Нас интересует: State: Optimal

- состояние батарейки кэш памяти RAID контроллера (BBU):

BBU status for Adapter: 0

BatteryType: iBBU
Voltage: 3976 mV
Current: 0 mA
Temperature: 20 C

BBU Firmware Status:

  Charging Status              : None
>>  Voltage                      : OK
>>  Temperature                  : OK
  Learn Cycle Requested           : Yes
  Learn Cycle Active           : No
>>  Learn Cycle Status           : OK
>>  Learn Cycle Timeout          : No
>>  I2c Errors Detected          : No
  Battery Pack Missing         : No
>>  Battery Replacement required : No
>>  Remaining Capacity Low       : No
  Periodic Learn Required      : No

вышеуказанные параметры должны быть как в примере.

В xml файле hardware report вы найдете подобные сообщения:

<VALUE>seqNum: 0x00006b1e</VALUE>
<VALUE>Time: Sat Aug  10 04:06:29 2016</VALUE>
<VALUE></VALUE>
<VALUE>Code: 0x0000003f</VALUE>
<VALUE>Class: 0</VALUE>
<VALUE>Locale: 0x01</VALUE>
<VALUE>Event Description: Consistency Check found inconsistent parity on VD 00/0 at strip 44d5d</VALUE>

<VALUE>Time: Sat Sep 16 04:06:30 2016</VALUE>
<VALUE></VALUE>
<VALUE>Code: 0x0000003f</VALUE>
<VALUE>Class: 0</VALUE>
<VALUE>Locale: 0x01</VALUE>
<VALUE>Event Description: Consistency Check found inconsistent parity on VD 00/0 at strip 44d5d</VALUE>

По динамике их появления можно сделать какие-то выводы.

Обратите внимание на конфигурацию режима работы кэш памяти RAID контроллера:
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

В нашем случае текущая политика - Write Through, что является неоптимальным режимом с точки зрения производительности,
хотя значение по умолчанию - WriteBack.

Возвращяясь к hardware report-у можно увидеть следующие сообщения:

<VALUE>Event Description: BBU disabled; changing WB virtual disks to WT</VALUE>
<VALUE>Event Description: BBU enabled; changing WT virtual disks to WB</VALUE>
<VALUE>Event Description: BBU FRU is </VALUE>
<VALUE>Event Description: BBU disabled; changing WB virtual disks to WT</VALUE>
<VALUE>Event Description: BBU enabled; changing WT virtual disks to WB</VALUE>
<VALUE>Event Description: BBU FRU is </VALUE>
<VALUE>Event Description: BBU disabled; changing WB virtual disks to WT</VALUE>
<VALUE>Event Description: BBU enabled; changing WT virtual disks to WB</VALUE>
<VALUE>Event Description: BBU FRU is </VALUE>
<VALUE>Event Description: BBU disabled; changing WB virtual disks to WT</VALUE>
<VALUE>Event Description: BBU enabled; changing WT virtual disks to WB</VALUE>

Дело в том, что периодически (раз в месяц) RAID контроллер проверяет целостность и емкость батарейки
кэш памяти, для того чтобы в случае отключения питания сервера не было неприятных сюрпризов.
Процедура проверки выполняется по следующему алгоритму:
- режим кэша меняется на WT
- отключается BBU
- BBU подключается к батарейке и питается от неё какой-то время (на практике значения составляют несколько часов)
- контроллер определяет операционные параметры состояния батарейки
- BBU подключается к общему питанию
- BBU вводится в работу
- кэш переключается в режим WB


Данная процедура может быть незавершена, например по причине отключения питания сервера в момент проверки или ошибки
в алгоритме работы контроллера и кэш остается в режиме WT.
Это существенно снижает производительность дисковой системы сервера и может приводить к появлению указанных ошибок:
Сonsistency Check inconsistency logging disabled on VD 00/0 (too many inconsistencies)
В таком случае нужно изменить режим работы контроллера с WT на WB (при условии хорошего состояние батарейки)

Выводы:
- периодически анализируйте вывод команды show hardware на присутствие следующих строк
State: Optimal
Voltage                      : OK
Temperature                  : OK
Learn Cycle Status           : OK
Learn Cycle Timeout          : No
I2c Errors Detected          : No
Battery Replacement required : No
Remaining Capacity Low       : No
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU

История версий
Редакция №
1 из 1
Последнее обновление:
‎10-09-2016 09:15 AM
Автор обновления: