Как не потерять работу, администрируя Configuration Manager - часть 2
Продолжение первой части.
Один начальник крупного отдела, который целиком занимается Configuration Manager, любит повторять, что интенсивная работа с этим продуктом подобна сидению на вулкане или на пороховой бочке - он с напряжением ожидает момента, когда кто-то из его подчиненных ошибется, и создаст какой-нибудь массовый инцидент. Однако, надо признать, что каких-либо массовых инцидентов в том отделе не бывает. Часть принципов, которые изложены в этой статье, я впервые увидел именно там. Давайте продолжим изучать опасные сценарии использования и передовые практики по их предотвращению.
Перегрузка каналов связи
Просчеты администраторов могут привести к тому, что трафик Configuration Manager может «положить» каналы связи с удаленными офисами. В основном нагрузка на каналы появляется в момент массового распространения ПО или обновлений на множество клиентов. Чтобы беды не произошло, имейте в виду несколько вещей:
! Используйте BITS
Для доставки контента клиентам используйте BITS - протокол на основе HTTP, позволяющий ограничивать скорость передачи файлов и поддерживающий возобновление загрузки в случае разрыва связи. Кроме того, BITS загружает файлы используя только свободную полосу пропускания канала. К примеру, если приложения на компьютере используют 80% пропускной способности, BITS займет лишь оставшиеся 20%. По умолчанию, клиенты попытаются скачать к себе файлы при помощи этого протокола. Ограничивайте скорость загрузки BITS в настройках клиентов или в групповой политике, однако помните, что это ограничение и предоставление приоритета бизнес-трафику действуют лишь на этапе компьютер - маршрутизатор. Если сотня компьютеров в филиале, работающем через мегабитный канал, начнет днем скачивать с ограничением даже в 10 Кбит/сек по этому каналу очередной пакет с обновлениями, то канал перестанет обслуживать бизнес-приложения.
Можно попробовать настроить маршрутизаторы таким образом, чтобы они взаимодействовали с BITS на клиентах, и совместно управляли загрузкой внешнего канала, однако я еще этого нигде не видел. Подробней об этом написано здесь: https://msdn.microsoft.com/en-us/library/aa363133(v=vs.85).aspx
! Расставляйте Distribution Points (DP)
Если есть угроза полосе пропускания внешнего канала связи, то в локальной сети обязательно необходимо размещать тот или иной вид точек распространения. К счастью, в Configuration Manager 2012 у всех видов DP появилась возможность ограничивать сетевой трафик по времени суток, а у новых Pull Distribution Points даже есть возможность скачивать и раздавать контент через тот-же BITS. С Configuration Manager 2007 можно использовать Branch Distribution Points, которые получают контент через BITS, а отдают только через SMB.
! Ограничивайте запуски программ непосредственно с точек распространения (настройка Run from the Distribution Point)
Запуск клиентом программы с точки распространения всегда использует протокол SMB - а это может загрузить весь доступный канал. Если так сложится, что по SMB за пакетом клиент идет через WAN, то даже один компьютер может повлиять на производительность бизнес-приложений. Такое может случиться при неверно настроенных границах сайта.
! Следите за границами сайта (Boundaries)
Boundaries определяют, с каких точек распространения клиентам можно получать контент. Если Boundaries - границы сайта - не настроены должным образом, то клиенты вместо локальной DP могут выбрать находящуюся в другом городе, со всеми вытекающими последствиями. О настройках границ можно прочитать здесь: https://technet.microsoft.com/en-us/library/hh427326.aspx
! Распространяйте пакеты постепенно
Если у вашей сети древовидная топология, когда один офис соединен посредственным каналом через другой офис с таким же каналом, и точки распространения последовательно "завязаны" друг на друга (например, "Branch DP> Standard DP", или даже "Pull DP > Pull DP > Standard DP"), то лучше назначать пакеты вначале на DP верхнего уровня. После того, как пакеты распространятся, можно назначать и на нижние DP. Если назначить пакет сразу везде, то все DP в цепочке начнут скачивать контент одновременно, и на канале "верхнего уровня" возникнет затор.
Клиент установился на "не те" компьютеры, и начал выполнение различных заданий
! Осторожней с Client Push Installation и другими способами установки
Следите, чтобы клиент вашего сайта не установился на какие попало компьютеры.
Этими компьютерами могут быть те же критически важные серверы, возможно даже из другой иерархии Configuration Manager. После установки "вашего" клиента, компьютер попадет в различные коллекции, и начнет выполнять ваши задания.
Никогда не добавляйте Client Push Installation Account в администраторы домена или всех компьютеров. Вместо этого, например, делайте его администратором машин, находящихся в конкретном OU Active Directory. Также указывайте конкретный OU, если используется установка через групповые политики.
Коллеги-злоумышленники или администраторы-новички
В Интернете я иногда встречаю откровения недовольных администраторов, которые признаются, что при сильной обиде постараются насолить своему предприятию. Если у таких людей есть доступ к управлению Configuration Manager, жди беды. Также может случиться, что управление системой будет доверено неопытному сотруднику, который может натворить бед.
! Разделяйте права на разные действия
Если с ConfigMgr работают трое и более человек, стоит продумать разделение прав на различные действия в системе. Создатели пакетов ПО не должны иметь права назначать их установку на коллекции или добавлять в них новые компьютеры. Администраторы иерархии не должны иметь прав создавать пакеты и назначать установку, и т.д. В идеале, один человек не должен быть способен осуществить вредоносное действие.
! Согласовывайте с коллегами массовые установки/изменения
Если в управлении участвуют несколько человек, при массовых установках ПО введите практику как как в фильмах про запуск ядерных ракет или открытие банковского хранилища - когда двое должны повернуть ключи или нажать на кнопки одновременно. Пусть коллега администратора, назначающего массовую установку, проверит её параметры перед тем, как тот нажмет "ОК".
! Отслеживайте активность в системе
Создайте простой обновляющийся отчет со списком последних назначений ПО, и выведите на большой отдельный монитор. Сортируйте записи по дате создания назначений и количеству компьютеров. Так вы будете держать руку на пульсе. Кстати, мой коллега из Microsoft Consulting Services даже создал механизм защиты от массового выполнения новой задачи, который блокирует ее, если она нацелена на определенное количество машин, и высылает администраторам предупреждение по электронной почте.
Если беда уже произошла, и все пропало, то понять, кто её устроил, помогут статусные сообщения и готовые запросы: Advertisements (прим.- Deployments в ConfigMgr 2012) Created, Modified or Deleted, а также несколько других:
Вид отдельного статусного сообщения:
Если уже "началось" - как остановить задание?
Если вы поняли, что что-то пошло не так, не спешите удалять Advertisement/Deployment. Если вы это сделаете, то статистика его выполнений будет утрачена, и масштабы бедствия останутся неизвестными. Чтобы срочно остановить разрушительный процесс, можно предпринять один или несколько шагов:
! Выключите (Disable) плохое развертывание/объявление.
Это остановит процесс и оставит вам статистику, но клиенты, получившие задачу, продолжат её выполнение до следующего запроса политик. Этот вариант наиболее быстрый в большой многосайтовой иерархии.
! После выполнения предыдущего шага, начните обновлять пакет на всех DP...
... при этом уберите права NTFS на папку-источник пакета, или переместите его куда-нибудь. Убедитесь, что на пакете стоит отметка Disconnect users from distribution points. В этом случае клиенты останутся в состоянии "Ожидание контента", даже те, кто уже получил политику и уже качал его. В большой иерархии это не самый скорый способ прекращения инцидента, а в системе с малым количеством сайтов - пожалуй, самый быстрый.
Заключение
Нет, это не очередной опасный сценарий, а всего лишь заключительная часть статьи. Мы рассмотрели примерно дюжину потенциальных проблем и способы их решения. Если вы знаете о еще как-либо "подводных камнях", пожалуйста, поделитесь этим в комментариях ниже. И помните, что Configuration Manager, прежде всего - очень полезный инструмент для решения огромного круга задач, если он находится в умелых или осторожных руках.