Ссылка для скачивания в формате pdf – http://gallery.technet.microsoft.com/Data-Protection-Manager-e1835980

Сразу скажу, что дизайнера в команду мы так и не нашли, так что ценность постера именно в информационном наполнении J.

Приветствуются любые отзывы и комментарии, которые помогут улучшить продукт.

Ссылка на запись вэбкаста с информацией о новом подходе к управлению облаком – http://www.microsoft.com/en-us/server-cloud/new.aspx (английский язык)

В контексте данного блога самой важной новостью является выпуск DPM 2012 RC. Но, в свете изменений в позиционировании продукта, схемы лицензирования System Center и даже MVP экспертизы автора – с 01.01.2012 я являюсь MVP System Center Cloud and Datacenter Management – не удивляйтесь, что скачать DPM отдельно не предлагают.

Дистрибутив DPM 2012 RC в составе пакета System Center 2012 RC доступен по ссылке – http://technet.microsoft.com/ru-ru/evalcenter/hh505660.aspx?ocidotc-f-corp-jtc-DPR&wt.mc_idTEC_103_1_33

Дополнительную информацию о нововведениях на русском можно почерпнуть здесь – http://www.microsoft.com/ru-ru/server-cloud/readynow/default.aspx

Но русскоязычные порталы заметно отстают по актуальности содержания. Рекомендую не лениться и знакомиться с первоисточником – http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx

Рассмотрим ситуацию с защитой и восстановлением сервера Exchange. Банальные случаи, когда директор стер письмо, и его надо восстановить, оставим для красочных демонстраций. В нашем случае все серьезно – защищенный сервер Exchange 2010 на базе Windows Server 2008 R2 умер. Совсем. Даже синего экрана не покажет. Да, и предположим, что DAG не было. Выбираем оптимальный вариант защиты для одиночного сервера. Но, забегая вперед, скажу, что это не подходит для сервера – члена DAG, согласно официальной документации. Да и в отказоустойчивом варианте скорость восстановления экземпляра почтовой базы или одного из узлов уже не играет такой ключевой роли.

Да, забыл добавить – все роли Exchange были на одной машине… Еще усугубим – и виртуализацию тоже не успели внедрить. С копией виртуальной машины все проще, будь то Hyper-V или VMware. Рассмотрим универсальный вариант защиты, который работает на физической платформе так же хорошо, как и на виртуальной.

Все, условия обозначены – одиночный физический сервер со всеми ролями Exchange, кроме Edge. Чтобы, в случае необходимости, максимально просто восстановить сервер, стоит предварительно правильно настроить резервное копирование.

Защита сервера Exchange включает в себя:

1. Защита Bare Metal Recovery (BMR) сервера Exchange. Почему BMR? Причин несколько:
   • Если сервер утратил работоспособность и “все встало”, последнее, что вы захотите делать – переустанавливать Exchange в режиме восстановления. Восстановление BMR уступает по простоте и скорости только восстановлению виртуальной машины (ВМ) целиком, но последнее не вписывается в наши условия – физический сервер.
   • Осуществлять резервное копирование ВМ целиком, с учетом расположения внутри баз Exchange, которые необходимо защищать отдельно – не самый лучший вариант, т.к. потребует дополнительных затрат на хранение избыточных данных.
   • Резервная копия состояния системы сервера Exchange будет бесполезной в рассматриваемом варианте с выходом сервера из строя. Да и не только в нем.
2. Защита баз почтовых ящиков и общих папок с частотой и сроками хранения, соответствующими требованиям бизнеса и техническим возможностям.

Оба пункта целесообразно разнести по двум группам защиты. И если для BMR сервера Exchange допустимо создание точек восстановления раз в несколько дней, то для баз необходима частая синхронизация и минимум одна операция Express Full Backup (EFB) в сутки. Чем чаще делать EFB, тем быстрее пройдет восстановление базы, т.к. сокращается количество файлов журнала, которое необходимо накатывать на восстановленную полную копию. Отдельно отмечу, что для сервера Exchange, совмещающего в себе все роли, для хранения точек восстановления BMR за несколько дней достаточно всего нескольких гигабайт дискового пространства (подробности о создании резервной копии BMR и ее составе смотрите в статье Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 1)).

Итак, сервер Exchange аварийно и полностью вышел строя. Что делать?

1. Решаем где восстанавливать – на старом оборудовании, или берем новое.
2. Восстанавливаем из консоли DPM самую свежую копию BMR сервера Exchange в папку на любом сервере (защищенный сервер с агентом DPM) или в папку на самом сервере DPM.
3. Создаем из этой папки сетевой ресурс с доступом на чтение для группы Все. Обязательное условие – папка WindowsImageBackup с копией должна находиться непосредственно в расшаренной папке.
4. Берем дистрибутив Windows Server 2008 R2 и грузимся с него на выбранном в пункте 1 сервере. На следующем после выбора языковых параметров экране жмем – Восстановление системы. Следуем далее, выбрав пункт Восстановление компьютера с помощью созданного ранее образа системы. Затем идет последовательность: Выберите образ системы -> Дополнительно -> Искать образ системы в сети -> Подключиться к этой сети. Набираем в возникшем окне полный путь к сетевой папке с архивом BMR и жмем Ок. Отмечаем найденный образ системы в списке. В следующем окне ставим отметку Форматировать и разбить на разделы диски. Жмем Далее, и, согласившись с уничтожением данных на дисках сервера, ожидаем завершения процесса восстановления. Данный пункт, как и весь процесс восстановления BMR подробно рассмотрен в статье Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 2).
5. Грузимся на восстановленном сервере и в консоли Microsoft Exchange ищем базы почтовых ящиков и общих папок (если они использовались) в разделе Локальный сервер Microsoft Exchange -> Конфигурация организации -> Почтовый ящик. Не обращаем внимание на нерабочее состояние баз и лезем в свойства каждой базы с тем, чтобы на закладке Обслуживание поставить отметку База данных может быть перезаписана при восстановлении. Попутно отмечаем для себя буквы дисков из свойства Путь к базе данных на закладке Общие.
6. При необходимости монтируем необходимые LUN к серверу Exchange и создаем тома для баз с буквами дисков, согласно отмеченным в предыдущем пункте путям. Если ваша почтовая система недостаточно задокументирована, то необходимый размер томов для баз почтовых ящиков вы можете вычислить, исходя из свойства их реплик на сервере DPM. Смотрите поле Выделение дискового пространства -> Том реплики -> использовано.
7. Восстанавливаем из консоли DPM базы почтовых ящиков, указав Время восстановления – Последний. В этом случае база восстановится в исходное место на файловом уровне, а затем на нее применятся все журналы Exchange, полученные сервером DPM посредством синхронизации с момента создания последней полной экспресс копии.
8. После восстановления последней базы новый сервер Exchange полностью готов к работе.

Данные пункты являются руководством по восстановлению одиночного сервера Exchange после аварии и, на мой взгляд, являются кратчайшим возможным путем к рабочей системе после полного выхода ее из строя. Они применимы как для физического, так и для виртуального сервера на базе различных гипервизоров. Если вы не ощущаете уверенности в процессе восстановления, то сохраните их себе отдельно. И пусть они вам не пригодятся.

Тем не менее, постоянная неопределенность статуса агента заставляет администратора DPM лишний раз нервничать и думать, что где-то что-то настроено неверно/не работает. Но тут все как в старой шутке – “It’s not a bug, It’s a feature!” В DPM 2010 разработчики отключили автоматическое обновление статусов агентов при переходе на закладку Агенты. Теперь это происходит периодически, и по моим замерам, первое обновление с момента открытия закладки проходит, примерно, через 28 минут (точно не 30, как было бы логично предположить). Сделано это для повышения производительности. Так что не мучайте свои брандмауэры J

Собственно, из всей линейки продуктов SC 2012 там доступна только лабораторная работа по SC Configuration Manager 2012.

Но у меня для вас есть отличные новости. У наших бельгийских коллег я обнаружил целую коллекцию новейших лабораторных работ. И они есть только на бельгийском портале TechNet! Уникальный бельгийский набор включает в себя лабораторные работы:

• First Look at Microsoft System Center Data Protection Manager 2012
• OM12 : Monitoring key Microsoft workloads : Microsoft Exchange Server, SQL Server and Windows Server with OpsMgr 2012 beta
• System Center Orchestrator Extensibility
• OM12: Application Monitoring in OpsMgr 2012 beta
• OM12 : Network Monitoring in OpsMgr 2012 beta
• Getting Started with System Center Orchestrator

И еще огромный список работ по новейшим продуктам. Перечисленные лабораторные работы доступны только на странице TechNet NL-BE. Вот такой удивительный эксклюзив. Все ПО внутри виртуальных стендов англоязычное, так что не пугайтесь.

В интересующей нас работе по знакомству с DPM 2012 вам предоставляются следующие виртуальные машины:

• Operations Manager 2007 R2 настроенный на мониторинг DPM 2012
• файловый сервер на базе Windows Server 2008 R2 Enterprise
• сервер DPM 2012, правда графическая консоль пока доступна только в версии DPM 2010
• сервер Exchange 2010
• контроллер домена на базе Windows Server 2008 R2 Enterprise
• сервер с различными экземплярами SQL Server 2008 и SQL Server 2008 R2

И все это можно изучать не ограничивая себя жесткими сроками. Т.е. то, что вы не закончили делать там сегодня, вы сможете доделать завтра. Сессия не разорвется и простаивающие мощности датацентра никто не спешит отнимать.

Настоятельно рекомендую к изучению. Только не сломайте мозг, отслеживая в OpsMgr ветку DPM 2011 и работая в консоли DPM 2010 на сервере DPM 2012.

PS: Всегда знал, что мои бельгийские коллеги по System Center очень продвинуты, но чтобы настолько… :)

Это я все к чему. Сейчас идет активная стадия составления планов по содержанию и разделам. Принято решение добавить больше практических советов, лучших практик и т.д. Отсеиваются все второстепенные вещи, остается, так сказать, только концентрированное тайное знание.  И именно сейчас авторы решили собрать мнения специалистов на тему – “Что бы вы хотели видеть в книге о DPM 2012?” Вы можете прямо повлиять на содержание, оставив свои пожелания в комментариях, либо отписав мне лично. Мы все их рассмотрим и учтем. Уверен, получится стоящая книжка.

Проблема

Сервер DPM и защищаемый Сервер 1 находятся на разных площадках, соединенных между собой каналом VPN, организованным между двумя серверами – TMG 1 и TMG 2:

На серверах TMG cуществуют все необходимые сетевые правила для взаимодействия двух сетей через VPN канал. При попытке установить агента DPM на Сервер 1 средствами консоли сервера DPM, либо при попытке подключения на стороне DPM установленного вручную агента, получаем ошибку 346. Ошибка сохраняется даже если разрешить все протоколы между сетями.

Решение

Лезем в сетевое правило, отвечающее за трафик между двумя сетями, переходим на закладку Протоколы. Нас интересует кнопка Фильтрация:

В выпадающем меню выбираем Настроить протокол RPC:

И, не обращая внимания на прямо противоположный англоязычному оригиналу перевод значения флажка, в окне настроек RPC снимаем галку Требовать строгого соответствия RPC:

Повторяем действия на втором сервере TMG.

После этого установка агента на Сервер 1 из консоли DPM пройдет без ошибок.

Если у вас есть вопросы или пожелания по Data Protection Manager и не только, там вы сможете озвучить их лично. Оба дня конференции, часть времени я буду проводить в качестве приглашенного эксперта у стенда System Center 2012. До встречи на мероприятии!

Итак, кто-то когда-то решил заявить в функционале DPM 2010 возможность восстанавливать исходное состояние системы серверов Windows 2008 и Windows 2008 R2 на “другое железо”. Сделано это было, вполне очевидно, для дополнительной раскрутки продукта на тесном рынке решений для резервного копирования. Это привело к тому, что спустя год после выхода продукта, часто можно встретить просьбы о помощи и вопросы, связанные с различными проблемами, проявляющимися после выполнения таких восстановлений. Вполне ожидаемым было и появление администраторов, получивших синие экраны смерти при крайне неверной трактовке заявленного функционала – использовании BMR для миграции с физических серверов в виртуальные.

В чем же подвох? Ведь даже разработчики DPM в своем блоге указывали на то, что это работает (Performing a Bare Metal Restore with DPM 2010):

Since theoretically the system in question is completely down (due to corruption of the operating system) or even new (in the case of hardware replacement), I have discovered is that the easiest way to restore these systems is by booting to the Windows media (Windows 2008 or Windows 2008 R2 DVD) and initiating the recovery.

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

Как мы знаем из первой части статьи, для осуществления защиты исходного состояния системы DPM использует компонент операционной системы – систему архивации данных Windows Server (Windows Server Backup, WSB). Если быть точным, получение актуальной резервной копии BMR защищаемого сервера происходит следующим образом: агент экземпляра SQL сервера, на котором находится база данных DPM по заданному в свойствах группы защиты расписанию инициирует выполнение задачи, которая через службу агента на защищаемом сервере стартует файл сценария BmrBackup.cmd, находящийся в папке C:\Program Files\Microsoft Data Protection Manager\DPM\bin. Структура файла очень проста:

@echo off

if not exist %SystemRoot%\system32\wbadmin.exe goto returnError

rem Start a wbadmin.exe to create a BMR backup
start  /WAIT %SystemRoot%\system32\wbadmin.exe start backup -allcritical -quiet -backuptarget:%1

rem If return error code, Pass this error code to caller else check whether it actually succeeded or not
if %ERRORLEVEL% == 0 goto returnSuccess
exit /B %ERRORLEVEL%

:returnSuccess
exit /B 0

:returnError
exit /B 1

Жирным шрифтом я выделил интересующую нас команду. Через переменную %1 агент защиты передает в сценарий путь к репликам на сервере DPM.

Как мы видим, все банально. И если вы готовы отказаться от централизованного мониторинга, отчетов, единой консоли и прочих прелестей “правильного” администрирования, все это можно сделать и вручную. Особенно принимая во внимание требование лицензии Enterprise ML для защиты BMR и необходимость кучи манипуляций для его восстановления. При восстановлении BMR, DPM просто вывалит копию данных в указанную администратором папку и дальше все придется делать вручную. Восстановление BMR на исходные тома сервера целиком отдано тому же компоненту архивации, присутствующему в среде восстановления Windows (Windows Recovery Environment, WinRE) загружаемой с установочного диска.

Если все действия по резервному копированию и восстановлению выполняет система архивации данных, то можно посмотреть – а что говорит документация к этому компоненту ОС о восстановлении BMR на отличном от изначального аппаратном обеспечении. На эту тему есть очень подробный, постоянно обновляемый документ – How to move a Windows installation to different hardware (и не вздумайте читать унылую поделку, датированную 2007-ым годом, которой является русскоязычный перевод этой статьи.) Указанная публикация проливает свет на условия успешности восстановления резервной копии BMR:

1. HAL (слой аппаратных абстракций) исходного и конечного серверов должен совпадать (здесь и далее исходный сервер – источник резервной копии, конечный – сервер, на котором планируется восстановление). Единственное исключение здесь – многопроцессорный ACPI (усовершенствованный интерфейс конфигурации и управления питанием) может быть восстановлен на однопроцессорный ACPI и наоборот. Тоже самое касается однопроцессорной и многопроцессорной MPS (мультипроцессорной спецификации).
2. Версии операционных систем исходного и конечного серверов должны совпадать. В контексте BMR это можно изложить так – необходим загрузочный диск с дистрибутивом ОС, совпадающей с той, которую необходимо восстанавливать (обязательно соответствие платформ х86 или х64 дистрибутива и ОС, с которой был создан архив).
3. Удалите сторонние драйверы-фильтры на исходном компьютере перед выполнением резервного копирования. Этот тип драйверов может являться источником проблем при восстановлении на другое аппаратное обеспечение.
4. Удаление на конечном компьютере любого аппаратного компонента, присутствие которого не требуется для завершения процесса восстановления, повышает вероятность успешного восстановления.
5. Жесткие диски конечного сервера должны быть большего или одинакового с исходным сервером размера.
6. ОС архитектуры х86 может быть восстановлена только на конечный сервер с процессором архитектуры х86 или х64, ОС х64 – только на сервер х64 и IA-64 (Itanium) только на IA-64.

Неслабый список, особенно оговорки про удаление драйверов. И, на мой взгляд, от некоторых пунктов явно отдает неуверенностью в благоприятном исходе восстановления. Но, таки, работает же. И при выполнении условий, описанных в статье базы знаний, даже официально поддерживается. Только вот, применительно к DPM, почти все эти оговорки куда-то пропали. Заявляется поддержка восстановления на другое аппаратное обеспечение без условий, “прямо из коробки”, ставь и пользуйся. Как-то не совсем корректно. Тут отлично подходит старая поговорка – “Доверяй, но проверяй”.

В следующей части мы рассмотрим методику эффективной защиты и восстановления BMR для серверов с “сюрпризами” на системном разделе, вроде папки C:\ClusterStorage на несколько терабайт.

Предыдущие части доступны по ссылкам:

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 1)

Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 2)