Благодаря урагану Сэнди и ее маленькой злобной сестрице зимней буре Афине (мы уже начали давать имена зимним бурям) было много разговоров об аварийном восстановлении. К сожалению, мне кажется, что большинство компаний не подготовились к аварийному восстановлению как следует. Мне кажется, это объясняется человеческой психологией: мы все склонны думать, что неприятности случаются только у других, где-то, не с нами. Подобная привычка проявляется и на уровне компаний при планировании аварийного восстановления. Принимая во внимание сказанное, сейчас самое время быстро пересмотреть ваш план аварийного восстановления Active Directory (AD) и оценить, насколько он готов к реальной катастрофе.

.

Нельзя сломать то, чего нет

Конечно, у каталога AD есть свои уязвимые места, и при недостаточной проработке леса определенные действия могут привести к разрушению исходной отказоустойчивости каталога. Первое и наиболее очевидное правило – в лесу должно быть более одного контроллера домена. Для крупных компаний это и так ясно, но не все прозрачно для небольших фирм (например, если используются различные версии сервера Small Business Server). Если вы используете более одного контроллера домена, честь вам и хвала, но теперь мы подходим ко второму правилу: где размещены контроллеры домена? Географическое распределение контроллеров домена считается удобным решением для средних и крупных компаний, однако небольшие предприятия, возможно, не имеют второй площадки, подключенной через соединение по глобальной сети. В таком случае необходимо, по возможности, распределить контроллеры внутри офиса. Что вы будете делать в случае катастрофы масштаба урагана Сэнди, когда будет очень мало времени на подготовку? Отключите контроллер домена, который не является хозяином роли Primary Domain Controller (PDC)/роли Relative ID (RID)/схемы/инфраструктуры, и заберите его с домой! Конечно, это не лучший подход с точки зрения безопасности, но разве в такой ситуации не важнее сохранить компанию «на плаву»?

Предположим, вы убедились в выполнении первых двух правил. Ваш лес состоит из нескольких доменов? Если так, не находятся ли все контроллеры корневого домена в одном месте? Имейте в виду, что потеря всех контроллеров корневого домена в лесу с несколькими доменами в результате обрушения здания приведет к потере леса. Качественная разработка архитектуры AD и толковая стратегия финансового планирования имеют один общий принцип: разделение – ключ к большинству нестандартных ситуаций.

Если не делать резервных копий, восстанавливать будет нечего

Однако разделение ресурсов не заменяет резервное копирование леса. Хорошая стратегия резервного копирования и восстановления гарантирует, что если вы потеряете лес или его часть, то сможете построить его заново. План резервного копирования и восстановления не должен ограничиваться уровнем восстановления контроллеров домена – он должен предполагать ситуацию полной потери леса. Прежде всего, убедитесь, что выполняются резервные копии двух контроллеров в каждом домене. В небольших компаниях это не проблема; скорее всего, у вас только один домен. Имеет ли значение, какие контроллеры копировать? В большинстве случаев это несущественно. Однако поскольку мы рассматриваем настоящее стихийное бедствие, выбор определенных контроллеров позволит сократить время восстановления леса.

Процесс восстановления леса, согласно статье TechNet «Planning for Active Directory Forest Recovery» (http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery%28v=ws.10%29.aspx), создает «вновь посаженный» лес, состоящий из одного контроллера для каждого домена. Так как в каждом восстановленном домене только один контроллер, каждый сервер должен владеть всеми ролями хозяина операции. Процесс восстановления будет чуть проще и быстрее, если на восстанавливаемом сервере уже установлены все роли, поэтому выполняйте резервное копирования того контроллера, который является хозяином этих обычно сгруппированных вместе ролей.

Если ваш лес имеет несколько доменов, вы можете не копировать контроллер домена, который является сервером Global Catalog (GC). Почему нет? Потому что различия в версиях резервных копий между полномочным контроллером в каждом домене и его репликами глобального каталога в других доменах могут привести к появлению в восстановленном лесу устаревших объектов (подробнее об этом  —  в разделе «Removing the Global Catalog» статьи «Appendix A: Forest Recovery Procedures» по адресу http://technet.microsoft.com/en-us/library/cc781218%28v=ws.10%29.aspx#DisableGC). Рекомендуется все контроллеры домена делать серверами GC, так как же нам разрешить это противоречие? Принимайте решение, основываясь на размере вашего домена или леса и количестве контроллеров в домене. Если у вас лес с несколькими доменами, содержащий более 10000 пользователей, удаление роли GC займет время, которое вы не захотите тратить в процессе аварийного восстановления. Кроме того, возможно, в домене у вас будет достаточно контроллеров и отсутствие на одном из них роли GC не будет проблемой. Если у вас небольшое количество пользователей в лесу с несколькими доменами, вы более зависимы от роли GC, а удаление небольшого глобального каталога с создаваемого контроллера домена занимает не так много времени, так что этот совет не подходит.

Еще одна возможность ускорить восстановление леса – обновить контроллеры домена до системы Windows Server 2012. Как новая операционная система упростит процесс? Высокоуровневый процесс заключается в построении восстановленного леса, состоящего из одного контроллера на домен, и последующем расширении восстановленного леса с помощью дополнительных контроллеров. Как я упоминал в статье «Аварийное восстановление Active Directory в Windows Server 2012», опубликованной в Windows IT Pro/RE № 8 за 2012 год, система Server 2012 может существенно ускорить процесс расширения, позволяя просто клонировать созданные контроллеры домена. Если у вас нет системы Server 2012, вы все равно можете ускорить процесс расширения леса путем быстрого создания виртуальных машин с обычными серверами – но вы должны повышать их уровень, как и в случае с любым физическим сервером, а не просто клонировать.

Вопрос о том, как «облако» влияет на резервное копирование и восстановление каталога AD, достоин отдельной дискуссии. Например, стоит ли использовать виртуальные контроллеры домена как услугу Infrastructure as a Service (IaaS)? Может ли вам помочь новая служба AD Windows Azure от компании Microsoft? Я оставлю эти вопросы для будущих статей.