Особенности управления крупной инфраструктурой. Начало

При разработке контрольной панели управляющей крупной сетевой инфраструктурой и автоматизирующей такие рутинные сценарии, как: создание организационных единиц в Active Directory или подготовка почтовых ящиков пользователям, приходится сталкиваться с множеством оптимизационных задач. В новом цикле, открываемом этой заметкой, я расскажу об одном решении, применяемом нами в Parallels Automation, позволяющем справиться сразу с несколькими проблемами подобного рода.

Проблемы
В отличие от Microsoft System Center, ориентированного в первую очередь на управление сетью одного предприятия, Parallels Automation управляет инфраструктурой поставщика услуг, обычно включающей сотни серверов, объединённых в несколько несвязанных доменов Active Directory, в которых располагаются тысячи организационных единиц, содержащих сотни тысяч пользователей. Этим пользователям предоставляется доступ ко множеству сервисов: Exchange, IIS, SharePoint, MS DNS, MS SQL, Lync и так далее. Помимо решения задач автоматизации, контрольная панель отвечает и за такие вещи, как: управление подписками и учётными записями клиентов, сбор и публикация статистики, учёт ресурсов, и даже реализует функции пользовательского интерфейса для провайдера и его клиентов.

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

• сгенерировать логин;
• проверить уникальность логина и повторить генерацию, если он не уникальный;
• создать пользователя в Active Directory;
• создать почтовый ящик в Exchange для только что созданного пользователя;
• скорректировать протоколы доступа (POP3, IMAP, MAPI и так далее);
• ...

А теперь помножим всё это множество операций на тысячи пользователей и попытаемся представить, что получится, если для выполнения каждой из них контрольной панели придётся делать удалённый вызов на тот или иной сервер внутри инфраструктуры.

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

Решение
Все вышеописанные проблемы решаются в Parallels Automation с помощью внешней по отношению к контрольной панели системы управления. Она строиться на базе автономных процедур-сценариев, каждая из которых реализует одну достаточно крупную задачу управления, например: создание организационной единицы клиента в Active Directory со всеми необходимыми служебными объектами (пользователями, группами и так далее) или создание Web-сайта со всеми настройками, виртуальными директориями и параметрами безопасности. Каждая такая процедура полностью реализует отдельный сценарий управления, включая обработку ошибок и, если необходимо, откат изменений в случае фатальных проблем.

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

Если управляющие процедуры будут написаны на некотором скриптовом языке, то мы решим ещё 2 проблемы: упрощение поддержки и удешевление разработки. Действительно: в случае возникновения серьёзной проблемы, клиент, не дожидаясь официального исправления и руководствуясь нашими рекомендациями, может самостоятельно вносить исправления в скрипты, поставляющиеся в открытом виде. Кроме того, по личному опыту могу сказать: писать такие процедуры на скриптовом языке проще, чем использовать для этих целей "тяжёлую артиллерию" вроде C++ или C#.

Windows Provisioning Engine
В течении длительного времени в качестве такой внешней системы управления мы использовали решение компании Microsoft под названием Microsoft Provisioning System. Оно поставлялось с множеством готовых управляющих процедур и удовлетворяло всем требованиям: внешний движок по исполнению сценариев, специальный скриптовый язык на базе XML`я, возможность расширения. Но полтора года назад разработка и поддержка данной системы была прекращена.

Как только стало понятно, что у MPS нет будущего, мы задумались над решением, которое могло бы его заменить. Сторонних аналогов MPS, которые бы могли удовлетворить наши требования, не нашлось. Разрабатывать свой язык сценариев с нуля – дорого и долго. К тому моменту мы уже давно занимались автоматизацией Exchange 2007 и OCS и начинали работать с Exchange 2010 и Lync. Мы заметили, что большинство новых корпоративных продуктов от компании Microsoft управляются с помощью командлетов PowerShell`а. Идея витала в воздухе – взять за основу язык сценариев PowerShell, реализовав на .NET серверную системы, которая бы отвечала за приём запросов и запуск скриптов на исполнение. Так на свет появилось то, что мы называем Windows Provisioning Engine.

Продолжение следует...