У нас есть несколько систем Server 2012, каждая из которых работает виртуализировано на сервере Hyper-V 2012. У нас возникли проблемы с двумя такими виртуальными экземплярами, оба из которых используются в качестве файловых серверов, из-за чего они иногда перестают отвечать на запросы на обслуживание файлов для клиентов. После входа на сервер попытки корректно завершить его завершаются неудачно (без ошибок, просто не удается подтвердить запрос на выключение).
Восстановление - это случай отключения и включения сервера (ов) из консоли Hyper-V.
Эти два сервера не обслуживают большое количество пользователей (один обслуживает не более 6 пользователей, а другой - около 20 пользователей), они находятся в одном домене, но на разном физическом оборудовании (и на разных сайтах). Они не запираются одновременно. Оба они используют DFSR для репликации довольно большого объема данных между собой (200 ГБ) по ADSL-соединениям, это работает нормально, и мы использовали DFSR для этого в предыдущих двух поколениях серверной ОС, которую мы использовали (Server 2008 R2 и Server 2003 - однако оба из них были физическими).
Сегодня, когда один из серверов вышел из строя, я заметил запись в журнале событий, которая выглядела примерно так:
Log Name: Application
Source: ESENT
Date: 27/11/2012 10:25:55
Event ID: 533
Task Category: General
Level: Warning
Keywords: Classic
User: N/A
Computer: HAL-FS-01.example.com
Description:
DFSRs (1500) \\.\E:\System Volume Information\DFSR\database_C8CC_101_CC00_EC0E\
dfsr.db: A request to write to the file "\\.\E:\System Volume Information\
DFSR\database_C8CC_101_CC00_EC0E\fsr.log" at offset 4423680 (0x0000000000438000)
for 4096 (0x00001000) bytes has not completed for 36 second(s). This problem is
likely due to faulty hardware. Please contact your hardware vendor for further
assistance diagnosing the problem.
Когда сервер снова запустился, я пошел искать запись в журнале событий для дальнейшего исследования и обнаружил, что записи в журнале событий больше нет (я предполагаю, что она была в памяти, но не смогла записать на диск до того, как сервер был выключен, для причина указана в сообщении). Я нашел это сообщение, выполнив поиск в журнале событий.
На обоих этих виртуальных серверах тома E: полностью выделены, а не динамически расширяются, и нет никаких других проблем ни на одном из других виртуальных серверов (включая server 2012, server 2008 R2 и Ubuntu 12.04 x64). На хост-системах нет никаких признаков нехватки ввода-вывода, памяти или ЦП.
Я использовал счетчики производительности на затронутых виртуальных серверах для мониторинга использования памяти (включая использование невыгружаемого пула), а также загрузки ЦП и сети, и ни один из них не выдает никаких признаков проблемы при возникновении проблемы.
Я бы подумал, что наша конфигурация не такая уж редкость, поэтому мне интересно, видел ли кто-нибудь это и сумел решить проблему?
Технические характеристики хоста следующие:
hal-vm-01
работает всего 5 виртуальных серверов (затронутый файловый сервер, DC + другие гости): Dell Poweredge R710, 16 ГБ, 6 x 300 ГБ SAS 15K RAID 10, Perc H700
hey-vm-01
В системе работают 2 виртуальных сервера (затронутые файловый сервер и контроллер домена) Dell Poweredge T620, 16 ГБ, 2 x 3 ТБ SATA RAID 1, Perc H310
У нас есть еще один виртуальный сервер hal-vm-02
работает 5 гостей, что не влияет на эту проблему и имеет более низкие характеристики, чем hal-vm-01
, но загружается примерно так же (exchange, DC, SQL + другие гости). На подходе больше памяти, чтобы мы могли настроить отказоустойчивое переключение между этим хостом и hal-vm-01.
На двух затронутых виртуальных серверах работает антивирусное программное обеспечение (MS SCEP), они настроены на сканирование только при создании и не сканирование файлов, созданных процессом dfsrs.exe. На самих хостах виртуальных машин нет программного обеспечения AV.
Мы используем резервную копию Windows Server 2012 на хосте hal-vm-01
для резервного копирования всех виртуальных машин на это не хватает часов. Другой затронутый сервер hey-vm-01
резервное копирование не выполняется, так как это просто копия данных DFSR за пределами нашего главного офиса. На затронутой виртуальной гостевой системе выполняется другое задание резервного копирования. hal-fs-01
, при этом также используется резервное копирование Windows Server для создания моментальных снимков данных, хранящихся в реплицированных общих папках DFS. Оба задания резервного копирования работают в нерабочее время.
Спустя три месяца...
У нас есть запрос в службу поддержки Microsoft уже более трех месяцев, в Microsoft было отправлено множество журналов счетчиков производительности, дампов памяти и журналов событий. Проведенный ими анализ выявил проблему с одним из виртуальных дисков hal-fs-01 (виртуальный сервер с проблемой). Виртуальный диск, о котором идет речь, был серверным E:\
drive, на котором случайно оказались все наши группы и акции DFSR. Недавно я переместил все данные с E:\
диск на множество виртуальных дисков меньшего размера, которые я добавил на сервер, и, конечно, переместил все общие ресурсы и группы DFSR, оставив только файлы служб развертывания Windows на сервере. E:\
водить машину. Несмотря на это, мы все еще видели проблему с записью в E:\
диск выходит из строя.
На прошлой неделе я переместил файлы WDS на новый виртуальный диск, а также отключил службу WDS. Я также удалил E:\
виртуальный диск на случай, если с диском возникла какая-то аномалия. С тех пор у нас еще не было другого сбоя, однако еще слишком рано знать, устранило ли это проблему, так как наше самое долгое время безотказной работы ранее составляло около 2 недель на момент этого редактирования (20.03.2013). , у нас всего одна неделя в текущей конфигурации, и если проблема не появится снова к следующей неделе, я повторно включу WDS, так как у меня есть подозрение, что WDS может быть виновником.
Я буду обновлять этот вопрос (или дам ответ, если мне удастся решить проблему).
Перенесено обратно на Server 2008 R2 ...
Не обновлял вопрос с прогрессом, но в итоге мы откатились к Server 2008 R2, все работает нормально. Мне все равно было бы интересно услышать о тех, у кого есть эта проблема, и которым удалось найти решение.
Хорошо, я не уверен, что это поможет, но общий фактор, который у меня с вами, заключается в том, что мои диски были подключены к контроллеру PERC H310, и я запускал файловый сервер в виртуальной среде, сопоставляя свой диск данных с Сырой диск подключил к тому же H310. В случайное время, как правило, в периоды интенсивного ввода-вывода виртуальная машина будет жаловаться, что не может получить доступ к диску, и выйдет из строя. В итоге я подключил диски к встроенному контроллеру Intel, и с тех пор проблем не было. Я лично считаю, что у низкокачественных карт Perc есть причуды, которые могут вызвать проблемы с операциями ввода-вывода.
Думаю, вы смотрите не в том месте. Посмотрите на хост - он пахнет проблемой хоста с дисковой подсистемой: либо дерьмо, либо ЗНАЧИТЕЛЬНО перегружено.