IT-блог компании "ЛанКей"

Иногда возникают ситуации, когда вынести управляющий сервер на отдельный физический невозможно в силу определенных причин. Примеров на самом деле множество. Из-за неправильного планирования инфраструктуры, когда игнорируется невозможность работы управляющего сервера на управляемом, неправильный подбор конфигурации. Наличие конфликтующих ролей на физическом сервере или испорченный Application Pool IIS (например, из-за наличия побочных служб диагностики компонентов сервера, вроде SuperDoctor Supermicro). И многое другое.

У данной схемы есть ряд преимуществ (догадаться о которых не составляет особого труда), главное из которых состоит в легкой переносимости управляющего сервера в случае острой необходимости на любой физический сервер с ролью HYPERV. Само собой подразумевается наличие отдельного массива на управляемом сервере под группы хранения или хранилищ типа DAS/SAN.

Итак, если возникла вышеописанная ситуация, то первое с чем мы столкнемся после установки DPM – это потенциальная невозможность работы (установки) агента DPM на управляемом сервере. Потенциальная именно из-за того, что ее может и не быть. А будет она в том случае, если у физического сервера имеется по меньшей мере два активных (но не обязательно подключенных) сетевых интерфейса (что является нормой в наше время). Все дело в том, что данный продукт плотно использует архитектуру DCOM, что подразумевает наличие источника данных (как на управляющем сервере, так и на управляемом) и множества клиентов, обращающихся к источнику. DCOM за все время своего существования не претерпел сколь-либо значимых изменений. Эта технология на основе разновидности RPC позволяет COM-компонентам взаимодействовать друг с другом по сети. Сеть является ключевым моментом в описываемой ситуации. Поскольку мы имеем дело с HYPERV, то реализация виртуальных сетевых интерфейсов подразумевает ряд неких программных ухищрений (довольно размыто описанных самой Microsoft), которые, возможно, кроют в себе причину в невозможности нормального взаимодействия между службами DCOM на обоих серверах. Есть подозрения, что использование собственной DCOM-технологии является одной из причин, по которой невозможно резервировать сервер, на котором стоит продукт MS SC DPM2007.

Установку агента DPM можно осуществить, перенеся виртуальную машину с управляющим сервером на любой другой сервер с ролью HYPERV, но при переносе обратно основные службы управляющего сервера DPM начнут сваливаться по таймауту. Преодолеть эту ситуацию возможно, либо оставив активным только один сетевой интерфейс, либо реализовать агрегирование сетевых подключений в командный режим (соответственно, либо с удваиванием пропускной способности, либо с балансированием нагрузки). Стоит заметить, что классический NLB здесь не поможет. Агрегирование хорошо реализуется на интеловских адаптерах собственными средствами.

Если такую схему всеже пришлось реализовать, то следует позаботиться о резервном копировании SQL-баз управляющего сервера средствами самой SQL куда-нибудь в отдельное место, а не снапшотить целиком всю виртуальную машину, т.к. это может привести к непредвиденным последствиям. Ну и естественно держать отдельно образ машины. В случае краха физического сервера мы всегда будем иметь наготове готовый управляющий сервер, к которому придется подцепить актуальные базы и предоставить доступ к хранилищу с резервными данными.