Обратился ко мне коллега с интересным вопросом о том, как найти в System Center DPM проблемную группу защиты, у которой переполнен раздел Replica Volume при условии, что в консоли DPM нет никаких упоминаний о проблемном разделе и вообще все группы защиты имеют включённый признак авто-расширения и выглядят как штатно работающие. Определение ассоциированной группы защиты DPM оказалось нетривиальным, и поэтому было решено зафиксировать это дело в данной заметке.
Началось всё с того, что коллега получил от системы мониторинга SCOM уведомление о переполнении дискового раздела, относящегося к точкам монтирования DPM:
Alert: Logical Disk Free Space is low Source: C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\Microsoft Hyper-V VSS Writer\vol_f40fda89-b997-4c03-89e1-73d88a4ede12 Path: KOM-FS03.holding.com Description: The disk C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\Microsoft Hyper-V VSS Writer\vol_f40fda89-b997-4c03-89e1-73d88a4ede12 on computer KOM-FS03.holding.com is running out of disk space. The values that exceeded the threshold are 0% free space and 0 free Mbytes. ...
Для того, чтобы выяснить к какой именно группе защиты в DPM относится данный проблемный раздел, мы воспользовались блоком скрипта Powershell, который уже помогал нам ранее. Однако, к моему удивлению, скрипт не выдал никаких результатов. Более того, манипуляции с выгрузкой данных разными командлетами в консоли DPM Management Shell с последующим анализом вывода (на предмет нахождения в нём идентификаторов точки монтирования "vol_f40fda89…" и GUID связанного с ней раздела "\?\Volume{0e061830-…\") также не дали никаких зацепок.
Стало ещё интересней, так как получилось, что информации о точке монтирования и разделе нет ни в графической консоли DPM, ни в Management Shell.
Появилось предположение о том, что DPM по какой-то причине (по ошибке) не удалил какой-то уже неиспользуемый раздел и мелькнула мысль о ручном удалении точки монтирования и самого раздела из оснастки Disk Management. Но эта идея показалась не очень хорошей, так как, пробежавшись глазами по некоторым таблицам в базе данных DPM, например tbl_SPM_Volume, мы обнаружили там упоминания данного дискового раздела.
После некоторых изысканий был обнаружен полезный SQL-запрос, опубликованный в форуме TechNet. Запрос позволяет объединить в одном выводе данные из разных таблиц БД DPM:
select ag.NetbiosName, ds.DataSourceName, vol.MountPointPath, ds.DataSourceId, vol.GuidName from tbl_IM_DataSource as ds join tbl_PRM_LogicalReplica as lr on ds.DataSourceId=lr.DataSourceId join tbl_AM_Server as ag on ds.ServerId=ag.ServerId join tbl_SPM_Volume as vol on lr.PhysicalReplicaId=vol.VolumeSetID and vol.Usage=1 order by NetbiosName
Из вывода этого запроса мы обнаружили, что интересующая нас точка монтирования и её раздел относятся к одной из виртуальных машин Hyper-V в одной из действующих групп защиты DPM.
Причём интересно в этой ситуации то, что для данного источника защиты мы видим две записи о разделах, но при этом в графической консоли DPM, равно как и в командлетах DPM Management Shell, фигурирует только один раздел "vol_38f907a3…", а упоминаний о разделе "vol_f40fda89…" нет.
Как бы там ни было, мы всё же получили ответ на поставленный вопрос о принадлежности "мутной" символической ссылки (раздела) к конкретной группе защиты DPM. Однако другой возникший вопрос о том, как мог образоваться данный скрытый раздел остался в области "чёрной магии" DPM. На мой вопрос с предположением о том, что изначально ВМ была добавлена в одну группу защиты DPM, а затем в какой-то момент времени была перенесена в другую группу защиты, пройдя через стадию Inactive Protection, коллега ответил утвердительно, но подробностей вспомнить не смог. А для окончательного закрытия вопроса по проблеме переполнения этого самого скрытого дискового раздела, мы попросту удалили данную ВМ из группы защиты (с удалением ассоциированных разделов DPM) и затем добавили ВМ в группу защиты по новой.
RSS - Записи
Добавить комментарий