Повреждение базы данных Exchange 2013 с событием 476 в ESE
У меня случайные повреждения базы данных на нашем Exchange Server 2013 с событием 476 на ESE. Это уже пятый раз, и ситуация уже неприемлема. Вот скриншот окна просмотра событий с инцидентом.
Процедура восстановления должна выполняться из резервных копий или выполняться eseutil /p что является процедурой с потерями, поскольку журналы тоже были повреждены.
На этом этапе я действительно хочу изолировать проблему и найти, какое устройство я должен винить. Этот сервер Exchange работает внутри виртуальной машины в vSphere 6.0. VMDK экспортируется через iSCSI из Dell Powervault MD3820i.
Из-за природы ошибки, похоже, проблема связана с подсистемой хранения, но как мы можем это исследовать? По предыдущим вопросам специалисты DELL сказали, что с хранилищем все в порядке, но я не знаю, достаточно ли надежна проводимая ими диагностика.
Заранее спасибо,
РЕДАКТИРОВАТЬ: На сервере не установлено антивирусное программное обеспечение. В качестве хост-оборудования под управлением VMware vSphere 6.0 используется DELL PowerEdge R730, омологированный DELL для работы с vSphere. В журналах VMware нет ошибок или чего-либо подобного, или, по крайней мере, я не смог найти никаких проблем в журналах.
Обмен данными с хранилищем осуществляется через iSCSI с использованием двух кабелей Cat6 в многопутевом режиме с двумя контроллерами на PowerVault MD3820i, так что это довольно стандартная конфигурация, которая работает, и, опять же, она была омологирована DELL.
Я знаю, что наличие омологации DELL не означает, что это хорошо. Но они продавали оборудование и рекомендовали свои лучшие практики, и мы следовали всем им.
РЕДАКТИРОВАТЬ II: На устройстве хранения PowerVault установлена последняя версия микропрограммы от DELL, версия 08_20_09_60, которая на один старше последней, решает одну конкретную проблему, которая приводит к повреждению данных: Устранена редкая проблема, которая может вызвать сбой процессора, что может привести к проблеме целостности данных.
Что касается сетевых карт, мы используем двойной Broadcom NetXtreme II BCM57810 10GbE. Карта не поддерживает разгрузку ядра TCP и / или разгрузку iSCSI, так что это не должно быть проблемой.
VMware также работает с рекомендованными драйверами для локальных контроллеров SAS: megaraid_sas водитель вместо глухого tg3 в комплекте с VMware. Я не думаю, что это может быть проблемой, поскольку виртуальные машины находятся в хранилище iSCSI, а не в локальном хранилище.
Как говорится в описании ошибки журнала событий, это почти наверняка будет неисправностью системного оборудования, что может быть довольно расплывчатым понятием, когда речь идет о виртуальных гостях.
Я бы очень внимательно посмотрел на подсистему хранения - учитывая мой недавний опыт работы с виртуальными кластерами, построенными на серверах Dell, я подозреваю, что проблема связана либо с микропрограммой сетевой карты, либо с микропрограммой системы хранения в таком порядке.
Выпив чашку чая и подумав, я снова посмотрел на вашу ошибку, вы получаете ошибку 1019. Это, в частности, означает, что сервер обмена пошел читать некоторые данные в базе данных, которые, как он «знал», были записаны, но не смог их найти (читали ли вы https://support.microsoft.com/en-gb/kb/314917 - там ошибки подробно обсуждаются).
Это может быть только какое-то повреждение диска, и основной причиной этого, скорее всего, будет проблема с системой хранения, особенно с учетом того, что вы упомянули, что это уже случалось раньше.
Еще меня беспокоит то, что ошибка 1019 может быть довольно коварной; это может быть конечным результатом неправильной записи, которая некоторое время назад не была обнаружена, потому что данные не были нужны в течение некоторого времени. Восстановление вчерашней резервной копии не поможет, например, если повреждение произошло на прошлой неделе.
На этом этапе я бы обязательно связался с Dell, а также, возможно, с Microsoft.
В VMware 6 есть проблемы, которые могут привести к повреждению обменных пунктов (или чего-либо активного, например, базы данных). Есть (связанные?) Проблемы с функцией отслеживания измененных блоков (CBT), используемой программным обеспечением виртуального резервного копирования, таким как Veeam. Поищите по этим темам, и вы найдете другие с поврежденными магазинами Exchange. Это особенно неприятная проблема, поскольку после того, как ваш магазин будет поврежден, ошибки CBT могли сделать ВСЕ ваши резервные точки восстановления (включая внешние) непригодными для использования. Насколько я понимаю, у VMware есть патч для предотвращения повреждения работающего сервера, но на момент публикации этой публикации нет исправления для проблем CBT, а резервные копии ESXi 6.0 на основе CBT не являются надежными. FWIW - У меня был хороший опыт работы с сетями хранения данных Dell MD. Они не причудливые, но у меня есть несколько клиентов, работающих с ними, и у меня никогда не было проблем. Точно так же у меня есть довольно много надежных полок Equallogic. Конечно, я использую только базовые функции LUN, ничего особенного, вроде снимков или репликации; полагаясь в этом на Veeam.
Учитывая ограниченную информацию о среде, в которой он работает, я бы начал с проверки следующего.
Убедитесь, что в AV установлены соответствующие исключения для обмена.
Убедитесь, что драйверы для хранилища и сети являются правильными стабильными версиями для устройств на другом конце.
ищите другие события, предшествующие неудаче.
Попытайтесь включить дополнительную информацию об оборудовании, типе сервера, памяти, процессоре, типах сетевых карт и конфигурации (порт-канал и т. Д.)
внимательно изучите журналы vsphere на предмет ошибок, связанных с хранением.