System Center 2012 R2 DPM — Невозможность защиты виртуальных машин на одном из узлов кластера Hyper-V — Ошибки ID 53 : Not implemented (0x80000001) и ID 104 : Access is denied (0x80070005)

imageДобавляем дополнительный хост виртуализации в действующий кластер Hyper-V на базе Windows Server 2012 R2 с использованием общих томов Cluster Shared Volume (CSV). Устанавливаем на новый узел кластера агента System Center 2012 R2 DPM CU5 и пытаемся выполнить резервное копирование виртуальных машин из кластера. При этом возникает интересная проблема – резервное копирование виртуальных машин успешно выполняется только в том случае, если они расположены на уже существующих ранее в DPM узлах кластера, а если переместить любую виртуальную машину на новый узел кластера, то в процессе создания резервной копии сначала возникает ошибка…

DPM failed to communicate with <Имя сервера DPM> because of a communication error with the protection agent. (ID 53 Details: Not implemented (0x80000001))

image

Затем следует другая ошибка…

An unexpected error occurred while the job was running. (ID 104 Details: Access is denied (0x80070005))

image

Изучение лога агента DPM на защищаемом сервере (по умолчанию расположен %ProgramFiles%\Microsoft Data Protection Manager\DPM\Temp\DPMRACurr.errlog) ясности не внесло. Решение вопроса пришлось на некоторое время отложить, так как параллельно решалась задача виртуализации серверов DPM.

В голове крутилось предположение о том, что чистая инсталляция сервера DPM без применения печально-известного CU5, возможно, избавит нас от этой проблемы. Был развёрнут свежий экземпляр System Center 2012 R2 DPM с обновлением CU4 и выполнена установка агентов DPM на все защищаемые серверы, в том числе и на все узлы кластера виртуализации Hyper-V. То есть фактически на всех серверах виртуализации агент DPM был переустановлен. Однако к моему большому удивлению, на новой инсталляции DPM проблема с появлением двух вышеописанных ошибок проявила себя снова и к тому же с ещё бОльшим масштабом, – теперь резервное копирование работало только на двух хостах из десяти…

В решении проблемы помогло банальное сравнение групп безопасности используемых агентом DPM на хосте с нормально функционирующем агентом DPM и проблемным. Выяснилось, что на всех хостах виртуализации входящих в кластер Hyper-V с CSV в локальную группу безопасности DPMRATrustedDPMRAs были включены учетные записи только двух хостов, именно тех, на которых резервное копирование как-раз таки работало. 

image

Сравнение членства данной группы с другими защищаемыми системами входящими в кластеры показало, что членами данной группы должны быть все узлы-участники кластера. Соответственным образом членство этой группы было изменено на всех хостах – участниках кластера Hyper-V.

image

Характерно также и то, что аналогичная ситуация на некоторых хостах виртуализации наблюдалась с членством локальной группы безопасности группы Distributed COM Users, которую также пришлось настроить аналогичным образом.

image

После этого резервное копирование всех виртуальных машин заработало в независимости от их размещения на разных хостах.  

image

Открытым во всей этой истории остался вопрос о том, что стало причиной такой настройки локальных групп безопасности в процессе установки агента DPM.

Добавить комментарий