Главная System Center, Без рубрики ConfigMgt, ConfigMgt 2012, vNext
  • ConfigMgr 2012 Beta 2 – галопом по европам… (Part 01)

    betaТо, что ждали революционные массы – свершилось. Для публичного тестирования стала доступна Beta 2 новой версии System Center Configuration Manager 2012 (vNext).

    Загрузить дистрибутив ConfigMgr 2012 Beta 2 можно по ссылке: http://technet.microsoft.com/en-us/evalcenter/ff657840.aspx. Поскольку это всего-лишь бета-версия продукта, то на нее наложены довольно существенные ограничения по настройкам и поддерживаемому окружению. В частности установка поддерживается только для Windows Server 2008 SP2 x64 и на SQL 2008 SP1 + CU10\11. Стоит особо отметить, что SQL 2008 SP2 или SQL 2008 R2 не поддерживаются. Естественно, что выход RTM снимет эти ограничения. ConfigMgr 2012 будет первой версией SMS\SCCM которая работает в 64х битном режиме. И если предыдущую версию ConfigMgr 2007 можно было установить на 64х битную ОС, но работала она в все равно 32х битном режиме. Сейчас же ConfigMgr 2012 поддерживается 32х битные серверные ОС только как серверы точек распространяя (Distribution Point). Кроме этого поддерживается установка ConfigMgr 2012 Beta 2 только на системы с английским региональным окружением. Пока не поддерживается NAP (хотя к слову сказать мне еще не приходилось сталкиваться с работой NAP через ConfigMgr в реальной, продуктовой среде).

    В цикле этих статей я постараюсь осветить часть нововведений в ConfigMgr 2012 Beta 2 и поговорить об особо интересных вопросах. Эта и все последующие статьи из цикла, выражают только мое субъективное мнение, более того я впервые не особо сверялся с документацией (в большинстве случаев ее пока просто нет J ). Часть нововведение ConfigMgr 2012 мне очень интересна, но по разным причинам я не смогу их описать. Например, из-за ограничений своей тестовой среды, я не буду касаться вопросов управления мобильными устройствами. Помните – это пока всего лишь Beta, пусть и под номером 2 и все еще может поменяться. 😉

    Установка

    Как я уже говорил, установка ConfigMgr 2012 Beta 2 поддерживается только на Windows Server 2008 SP2. Из ролей (role) и возможностей (features) нам понадобятся:

    • .net Framework 3.5 и .net Framework 4
    • BITS
    • Remote Differential Compression
    • WSUS (если мы будем использовать Software Update)

    Устанавливаем данные роли и так же все зависимости от них. Устанавливаем SQL 2008 (Database, а так же в будущем сам ConfigMgr, я по старой привычке устанавливаю на отдельный от системы раздел). При установке SQL необходимо все службы (engine, agent, etc) запускать от имени Local System. Кроме того, необходимо будет явным образом указать в настройках фаервола разрешение для портов TCP: 1433 и 4022. Коллейшен (collation) сервера и баз по прежнему должен быть регистронезависимым , поддерживается только: SQL_Latin1_General_CP1_CI_AS.

    После установки SQL 2008 его необходимо последовательно обновить, вначале до SP1, а затем до CU 10 (или старше).

    Перед установкой ConfigMgr 2012 расширяем схему Active Directory. Не берусь утверждать, что ее нужно обновлять, если она уже была расширена для ConfigMgr 2007. Сравнение файлов CONFIGMGR_AD_SCHEMA.LDF для версии SCCM 2012 B2 и SCCM 2007 показали, что они одинаковы. Я устанавливал ConfigMgr 2012 в новом, чистом окружении и поэтому расширил схему с помощью утилиты extadsch, а так же создал служебный контейнер System\System Management и выдал полные права на него и все дочерние объекты для учетной записи Local System.

    <03-25-2011 05:50:05> Modifying Active Directory Schema – with SMS extensions.

    <03-25-2011 05:50:05> DS Root:CN=Schema,CN=Configuration,DC=itband,DC=local

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Site-Code.

    <03-25-2011 05:50:06> Defined attribute cn=mS-SMS-Assignment-Site-Code.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Site-Boundaries.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Roaming-Boundaries.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Default-MP.

    <03-25-2011 05:50:06> Defined attribute cn=mS-SMS-Device-Management-Point.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-MP-Name.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-MP-Address.

    <03-25-2011 05:50:06> Defined attribute cn=mS-SMS-Health-State.

    <03-25-2011 05:50:06> Defined attribute cn=mS-SMS-Source-Forest.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Ranged-IP-Low.

    <03-25-2011 05:50:06> Defined attribute cn=MS-SMS-Ranged-IP-High.

    <03-25-2011 05:50:07> Defined attribute cn=mS-SMS-Version.

    <03-25-2011 05:50:07> Defined attribute cn=mS-SMS-Capabilities.

    <03-25-2011 05:50:08> Defined class cn=MS-SMS-Management-Point.

    <03-25-2011 05:50:08> Defined class cn=MS-SMS-Server-Locator-Point.

    <03-25-2011 05:50:08> Defined class cn=MS-SMS-Site.

    <03-25-2011 05:50:08> Defined class cn=MS-SMS-Roaming-Boundary-Range.

    <03-25-2011 05:50:08> Successfully extended the Active Directory schema.

    <03-25-2011 05:50:08> Please refer to the ConfigMgr documentation for instructions on the manual

    <03-25-2011 05:50:08> configuration of access rights in active directory which may still

    <03-25-2011 05:50:08> need to be performed. (Although the AD schema has now be extended,

    <03-25-2011 05:50:08> AD must be configured to allow each ConfigMgr Site security rights to

    <03-25-2011 05:50:08> publish in each of their domains.)

    Переходим непосредственно к самой установке. Запускаем мастер splash.hta

    Большая часть пунктов меню в нем еще не работоспособна и отображает такое сообщение:

    Выбираем вариант: Install. Мастер отображает нам список того, что мы должны сделать.

    Я выбрал установку отдельного Primary сайта с базовым функционалом.

    По старой доброй традиции, нам необходимо скачать набор обновлений. Если раньше для их загрузки с отдельного компьютера мы использовали утилиту setup.exe с ключом download. Теперь существует отдельная утилита, которая загружает обновления: setupdl.exe

    Обновления занимают порядка 192Мб и включают в себя:

    • Microsoft Remote Differential Compression Library
    • Windows Update Agent 3.0
    • WMI Redistributable Components version 1.0
    • Silverlight
    • .NET Framework Client Profile 4.0 RTM
    • SQL Server 2008 Express
    • MSXML 6.0 Service Pack 1
    • SQL Server 2008 Native Client
    • SQL Server 2008 System CLR Types
    • SQL Server 2008 Management Objects
    • SQL Server 2008 Replication Management Objects

    Код сайта и его имя, а так же каталог установки. Из нового – возможность не ставить консоль администрирования при установке сайт сервера.

    Вот так выглядело бы окно проверки, если бы я не выполнил все требования перед установкой.

    Первый запуск

    Во-первых, новый вид, хотя если вы работали с OpsMgr 2007 – то он вас не сильно удивит. Во-вторых, ленты (ribbon) как например в Office 2007\2010, по итогам тестовой эксплуатации показались очень удобными, но пришлось отключить для экономии места на экране. В-третьих, скорость работы и отображения изменений. Первые 10 минут я по привычке жал F5 после каждого своего действия. Но теперь это больше не нужно. Все изменения происходят и отображаются мгновенно.

    Рабочие задачи в консоли разбиты на 4 группы:

    • Administration
    • Software library
    • Monitoring
    • Asset and Compliance

    Administration

    Раздел Administration содержит несколько узлов, содержимое которых понятно я думаю без слов.

    Раздел Site Hierarchy

    Новый Discovery Method – Active Directory Forest Discovery. Будет позволять автоматически отслеживать изменения на уровне леса AD, при этом создавая границы AD Site\IP subnet на основании результатов обнаружения. Я думаю, что это позволит снять часть рутинной и часто забываемой работы по созданию границ.

    Можно заметить, что из раздела Schedule исчезла галочка Run as soon as possible. Теперь мы можем запустить полное обнаружение через контекстное меню в консоли. Естественно, что я запустил обнаружение.

    Из интересного в других Discovery – возможность задавать учетную запись для каждого отдельного метода обнаружения. Атрибуты AD в том же методе AD System стало задавать гораздо удобнее.

    Как раньше задавались дополнительные атрибуты AD.

    Тем временем успешно автоматически создалась новая граница:

    Появились группы границ (boundary groups). Именно для групп теперь задаются все привычные действия – задание сайта, который входит в эти границы и тип его подключения (fast\slow). Вполне логичный шаг, поскольку раньше в больших окружениях один сайт мог иметь несколько границ. Теперь настраивать и администрировать стало намного проще.

    Два последующих подраздела: Exchange Server Connectors и Addresses, я пока пропускаю, поскольку моя тестовая среда их не поддерживает.

    Последний подраздел: AD Forest содержит сводную информацию по лесу AD: домены, сайты, подсети, статусы обнаружения.

    Раздел Site Operations

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

    Раздел Client Settings

    Теперь политики клиента можно создавать. Естественно тема отдельной статьи, но этот момент я не мог не показать. Кто знает, тот поймет J

    Разделы Security, Migration Distribution Point и DP Groups – даже не буду показывать скриншоты, слишком много там всего – ждите отдельных статей J

    На этом на сегодня все. На десерт еще несколько снимков консоли.

    Alexey

  • Главная System Center, Без рубрики, Новое ConfigMgt, Remote Assistance, Remote Desktop, Remote Tools, SCCM
    • Remote Tools и Windows 7

      pc-remote-supportПервоначально я хотел в этой статье рассказать только о Remote Tools, но по мере написания статьи я понял, что нужно осветить и остальные способы удаленного управления клиентом в ConfigMgr 2007.

      В рамках статьи я буду придерживаться следующей терминологии:

      · Администратор – сотрудник, который подключается удаленно для выполнения каких-либо действий на компьютере пользователя, например сотрудник техподдержки. Не обязательно, чтобы этот человек обладал административными полномочиями на удаленной станции.

      · Пользователь – любой человек, который работает в локальном сеансе за компьютером и которому требуется оказать помощь.

      И так, в SCCM 2007 существует три варианта предоставления удаленного доступа к клиентской системе:

      · Remote Desktop

      · Remote Assistance

      · Remote Tools

      Первые два – штатные способы предоставления удаленного доступа в Windows. Механизм Remote Assistance рекомендуется использовать для оказания помощи пользователю. Например, необходимо понаблюдать за действиями пользователя, которые приводят к ошибке или наоборот показать пользователю что-то. Remote Desktop целесообразно использовать когда необходимо выполнить какие-либо административные задачи, не требующие участия пользователя. Например: установить приложение, обновление безопасности, изменить системные настройки Windows. Поскольку клиентские системы Windows могут быть использованы одновременно только одним пользователем, то подключение с помощью Remote Desktop вызовет отключение текущего пользователя. Рассмотрим, что же происходит при попытке подключения по RDP к машине, на которую выполнен локальный вход.

      В тот момент, когда администратор инициирует подключение к рабочей станции с помощью Remote Desktop, ему отображается уведомление о том, что обнаружен активный пользователь.

      clip_image001

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

      clip_image002

      Скажу сразу, пользователь может отклонить подключение, выбрав вариант «Отмена» и тогда администратор увидит следующее сообщение:

      clip_image003

      Обойти данный механизм нельзя, и в таком случае правильнее всего будет прибегнуть к административно-организационным мерам.

      Если пользователь выбрал вариант «Да» или в течение 30 секунд не выбрал ни один из вариантов, происходит подключение удаленного сеанса, при этом сеанс текущего пользователя отходит в фон и пользователь видит экран приветствия Ctrl-Alt-Delete.

      clip_image004

      Пользователь может попробовать войти в свой сеанс, при этом он будет уведомлен о том, что с компьютером работает удаленный пользователь

      clip_image005

      Администратору в сеансе RDP отобразится запрос о подключении

      clip_image006

      Администратор, точно так же как и пользователь, может отклонить запрос.

      Еще раз хочу акцентировать внимание на том, что сеанс пользователя не завершается, а отходит в фон. Таким образом, все запущенные пользователем приложения будут продолжать работать.

      Remote Tools это механизм предоставления удаленного доступа в ConfigMgr 2007. Для работы Remote Tools могут использовать свой собственный видеодрайвер ConfigMgr. При использовании Windows 7 больше не требуется, чтобы служба Remote Desktop на клиентском компьютере была запущена. Кроме того, Remote Tools накладывает некоторые ограничения при своей работе. Во-первых, вы можете использовать Remote Tools только для подключения к активной сессии. Если вам нужно подключиться к рабочему столу, в тот момент, когда пользователь вышел из системы – используйте механизм Remote Desktop. Во-вторых, на клиентском компьютере сеанс работы Remote Tools запускается в контексте и с правами текущего пользователя, таким образом, пользователь может по своему желанию прервать сеанс Remote Tools. Сделать он это может двумя способами: штатным, если вы в настройках Remote Agent указали отображение клиента Remote Tools, либо завершив процесс RT.exe с помощью диспетчера задач. Рекомендую оставить значения по умолчанию и на клиенте отображать значок уведомления об использовании Remote Tools.

      clip_image007

      clip_image008

      По консоли в каждый дом!

      Подключение к клиентскому компьютеру с помощью всех трех методов (Remote Tools, Remote Assistance, Remote Desktop) возможно при использовании консоли администрирования ConfigMgr Management Console. Помимо доступа к удаленному управлению, при использовании консоли специалисты службы поддержки могут получать так же информацию инвентаризации через Resource Explorer. Конечно, если служба поддержки насчитывает большое количество сотрудников, которым необходим только функционал удаленного доступа, установка консоли администрирования SCCM в таком сценарии может показаться не совсем удобным решением. Есть несколько способ решения этой проблемы.

      Remote Desktop
      Я думаю, не секрет, что доступ к Remote Desktop вы можете получить, запустив штатное средство: Remote Desktop Connection или выполнив команду: mstsc. Подробнее о параметрах RDC можно узнать из статьи: Use command line parameters with Remote Desktop Connection.

      clip_image009

      Remote Assistance

      Доступ к Remote Assistance возможен при запуске мастера: Windows Remote Assistance (%windir%\system32\msra.exe)

      clip_image010

      Если перейти в режим расширенных настроек (Advance connection option for help desk), то будет запущен мастер выбора компьютера по IP адресу или имени компьютера.

      clip_image011

      Этот же мастер можно запустить, выполнив команду: %windir%\system32\msra.exe /offerra

      clip_image012

      Remote Tools

      Использование консоли администрирования ConfigMgr Management Console является единственным рекомендованным и поддерживаемым способом получения доступа через Remote Tools. Однако, если вы не хотите устанавливать консоль SCCM только для того, чтобы позволить сотрудникам поддержки подключаться к клиентам, вы можете вручную перенести файлы, необходимые для работы. Для запуска Remote Tools необходимы файлы: rdpencom.dll и rc.exe расположенные в папке %Console_Path%\AdminUI\bin\i386.

      clip_image013

      Права

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

      Средство

      Порт

      Remote Desktop

      TCP port 135

      TCP port 3389

      Remote Assistance

      TCP port 135

      TCP port 3389

      Remote Tools

      TCP port 135

      TCP port 2701

      TCP port 2702

      Для того чтобы сотрудник поддержки мог подключиться к клиентскому компьютеру, его учетная запись должна быть членом одной из локальных групп на этом компьютере.

      Средство

      Локальная группа

      Remote Desktop

      «Remote Desktop Users»

      Remote Assistance

      «Offer Remote Assistance Helpers»

      Remote Tools

      «Remote Desktop Users»

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

      User Account Control (UAC)

      UAC впервые появился в Windows Vista, а затем был доработан в Windows 7. В идеале, UAC должен быть настроен таким образом, чтобы не позволять пользователю повышать свои права. К сожалению, реальность далека от идеала. Меньшим злом (по сравнению с отключением UAC) будет настройка UAC на запрос учетных данных. При этом желательно использовать Secure Desktop – это как раз то затенение, которое появляется при всплытии окна UAC с запросом учетных данных. Использование Security Desktop позволяет успешно защищаться от некоторого набора спуфинг-атак, поскольку сам вывод окна UAC при использовании Secure Desktop происходит с правами системы и в отдельном пространстве от программ пользователя.

      В групповой политике существует несколько параметров, которые задают поведение UAC (подробнее):

      · User Account Control: Admin Approval Mode for the built-in Administrator account

      · User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

      · User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

      · User Account Control: Behavior of the elevation prompt for standard users

      · User Account Control: Detect application installations and prompt for elevation

      · User Account Control: Only elevate executables that are signed and validated

      · User Account Control: Only elevate UIAccess applications that are installed in secure locations

      · User Account Control: Run all administrators in Admin Approval Mode

      · User Account Control: Switch to the secure desktop when prompting for elevation

      · User Account Control: Virtualize file and registry write failures to per-user locations

      Выделены параметры, которые вам, возможно, придется изменить. Дело в том, что Remote Assistance и Remote Tools, в силу своих особенностей, не могут отобразить окно запроса UAC, если используется Secure Desktop.

      Если сотрудник поддержки попытается выполнить действия, которые требуют повышения прав и отображения UAC (в режиме Secure Desktop), то он увидит черный экран в случае с Remote Assistance и предложение, воспользоваться Remote Desktop, в случае использования Remote Tools.

      Правильным и безопасным способом решения этой проблемы будет использование Remote Desktop, для всех случаев, когда необходимы повышенные привилегии. Remote Desktop полностью поддерживает работу UAC во всех режимах. Кроме того, использование Remote Desktop является безопасным способом работы с повышением права на клиенте, с той точки зрения, что конечный пользователь не может отключить удаленный сеанс и таким образом, не сможет даже временно получить повышенные привилегии на компьютере. В случае использования Remote Assistance или Remote Tools пользователь в любой момент времени может отключить администратора от системы, и остаться один на один, например с запущенной с административными правами командной строкой. Поэтому старайтесь использовать Remote Desktop всегда, когда это возможно.

      Если вам все же необходимо использовать Remote Assistance\Remote Tools для работы с UAC существует два способа сделать это.

      Для Remote Tools

      Необходимо настроить следующие параметры

      Параметр

      Значение

      Описание

      Behavior of the elevation prompt for standard users

      Prompt for credentials

      Настраивает UAC на запрос учетных данных, при попытке повышения прав

      Switch to the secure desktop when prompting for elevation

      Enabled

      Указывает UAC, что необходимо переходить в режим Secure Desktop, перед запросом о повышении прав

      ConfigMgr Agent, при подключении по Remote Tools, самостоятельно временно отключает Secure Desktop. Таким образом, во время сеанса работы сотрудник технической поддержки может повышать права. После того, как сеанс Remote Tools завершен, ConfigMgr Agent снова включает Secure Desktop. Минус данного подхода состоит в том, что при нештатном завершении (пользователь завершил процесс через диспетчер задач) Secure Desktop останется выключенным до следующего применения политики.

      Для Remote Assistance

      В групповой политике есть параметр «Allow UIAccess applications to prompt for elevation without using the secure desktop», который в случае включения позволяет Remote Assistance временно отключать Secure Desktop. Плюс данного подхода в том, что даже если пользователь завершит процесс remote assistance на своем компьютере, система автоматически включит Secure Desktop.

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

      Alexey

      • Жизненный цикл Office 2010 под присмотром SCCM 2007

        Microsoft Office 2010 LogoРуководство описывает ручной, полуавтоматический и автоматический сценарии развертывания/свертывания MS Office 2010 (32-битная редакция) в инфраструктуре «один лес, один домен» под управлением MS System Center Configuration Manager 2007 R2.

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

      • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
        • System Center Operations Manager 2007 – Пакеты управления

          В прошлых статьях я не раз упоминал пакеты управления (management pack, МП). Пришло время поговорить о них поподробнее, т.к. пакеты управления – один из ключевых элементов OpsMgr. МП – кирпичики, из которых складывается система. Без пакетов управления OpsMgr – голая программная оболочка. Именно из пакетов управления OpsMgr узнает, что и как ему надо выполнять, что и где отображать в интерфейсе и т.д. Фактически пакет управления – это модуль описания, содержащий правила построения системы и ссылки на библиотеки сборок.

        • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
          • System Center Operations Manager 2007 – Health Model

            Данная статья продолжает цикл статей о OpsMgr 2007 R2, и в этот раз речь пойдет о модели здоровья. Кроме описанного ранее моделирования служб, OpsMgr использует еще одну модель – модель «здоровья» (Health Model). Каждый объект в системе OpsMgr имеет показатель «здоровья». Здоровье объекта определяется шестью состояниями: здоров (healthy ), предупреждение (warning ), критический (critical ), не проверяется (unmonitored ), в режиме обслуживания (Maintenance mode ) и «недоступен» ().

            Мониторы (monitors)

            Для воздействия на состояние объекта в рамках OpsMgr существуют мониторы (monitors), которые делятся на несколько видов: юнит-мониторы, Aggregate rollup-мониторы и Dependency rollup-мониторы.

            Модель здоровья строится по принципу «дерева», при этом нижележащие мониторы передают своё состояние по определенным правилам вышележащим.

            При инициализации любого объекта в системе ему присваивается статус Health, если данный объект имеет хотя бы один активный монитор, или Unmonitored, если для объекта не настроено ни одного монитора (их нет вообще или они отключены). После этого, по результатам проверки состояния объекта, выставляется состояние предупреждение (warning) или критический (critical). В случае если агент, который занимается обслуживание данного объекта, не доступен, объект помечается как «недоступный», при этом отображается последнее известное состояние объекта.

            В случае если на объекте или его хозяине (см. host-отношения в прошлой статье) включен режим обслуживания, состояние объекта также переходит в режим обслуживания. В этом режиме не запускаются мониторы и, соответственно, не производится определение состояния объекта (кроме этого режим обслуживания влияет еще на ряд аспектов мониторинга, но они не относятся к модели здоровья).

            Монитор может иметь как все три состояния (Health-Warning-Critical), так и какую-то пару состояний (Health-Warning или Health-Critical). Это определяется на этапе создания монитора.

            Unit-monitor

            Unit-монитор – это процесс, производящий некие действия, результаты которых оцениваются, и по этой оценке выставляется уровень здоровья данного монитора – Health, Warning или Critical. Unit-монитор обычно состоит из трех частей:

            1. Планировщик, который запускает монитор по определенному расписанию. Этого шага может не быть, если наблюдаемый объект поддерживает подписку на события (н-р журнал Windows или WMI Events)
            2. Процесс, получающий данные о проверяемом объекте
            3. Условие, которое по данным определяет состояние объекта

            Примером Unit-монитора могут служить:

            – выполнение WMI-запроса, и проверка состояния службы Windows

            – появление события с определенным ID и источником в журнале Windows

            – результат выполнения скрипта (vbs или powershell)

            – наличие строки в текстовом файле

            Т.к. unit-монитор обычно запускается по расписанию, перерасчет состояния происходит через промежутки времени, заданные в расписании. Если монитор настроен на запуск раз в 15 минут, и срабатывает условие, которое переводит его в состояние Critical, то обратно он вернутся только через 15 минут, даже если в реальности условие перехода наступило через 2 минуты. Исключением может служить, например, монитор, работающий с событиями в журнале Windows – он реагирует сразу, как только событие имело место.

            Пакеты управления содержат массу готовых и настроенных unit-мониторов, но администратор может добавлять их из шаблонов, идущих в комплекте с OpsMgr, тем самым влияя на модель здоровья. В OpsMgr существует огромное количество шаблонов unit-мониторов, они будут рассмотрены позже. Чаще всего используются мониторы, реагирующие на события в журнале Windows, и мониторы на базе скриптов. Кроме этого администраторы могут создавать свои unit-мониторы любой сложности с помощью Authoring Console.

            Aggregate rollup monitor

            В отличие от unit-мониторов, aggregate-мониторы не выполняют никаких действий, а лишь собирают состояния других мониторов, расположенных ниже в дереве здоровья, для выставления общей оценки объекта по какому-либо критерию. У любого объекта есть как минимум 4 aggregate-монитора: Availability, Configuration, Performance и Security. Например, для класса Windows Server 2003 Operating System определен еще один дополнительный aggregate-монитор Core Windows Services Rollup, определяющий общее состояние служб:

            Dependency rollup monitor

            Dependency-монитор также не выполняет никаких действий, а лишь передает сведения о здоровье другого объекта, от которого зависит проверяемый объект. Dependency-мониторы крайне тесно связаны с понятием «отношения», рассмотренным ранее. Думаю лучше пояснить работу Dependency-монитора на примере. Когда я описывал отношения, одним из примеров было отношение между лесом AD и сайтом. С точки зрения «здоровья» логично, что если что-то не так с сайтом, то это также должно отобразиться и на всем лесе. Dependency-монитор как раз и передает состояние здоровья сайта в схему здоровья леса:

            Для dependency-монитора мы можем выбрать в качестве ссылки те мониторы, которые нацелены на объект класса, с которым у исходного объекта есть отношения. На рисунке представлены возможные варианты настройки dependency-монитора для леса AD:

            Политики сбора здоровья (Health Rollup Policy)

            Для Dependency rollup и Aggregate rollup можно определить «политики сбора здоровья» – правила, по которым будет передаваться состояние ниже лежащих объектов в дереве.

            Для Aggregate rollup monitor можно лишь задать одно из двух значений: по худшему состоянию (worst state) или по лучшему (best state). Рисунок, который поясняет работу этой политики, размещен прямо в консоли:

            В качестве примера использования правила сбора по лучшему состоянию можно привести кластер – кластер считается «живым», пока хотя бы одна нода находится в рабочем состоянии.

            Для Dependency rollup monitor настроек гораздо больше. Кроме сбора по худшему или лучшему состоянию, доступен также сбор худшего значение от определенного процента объектов:

            Тут может возникнуть вопрос – откуда в Dependency-мониторе может взяться несколько объектов, если мы делаем ссылку на один монитор? Ответ достаточно прост: как уже говорилось выше, Dependency-мониторы строятся на базе отношений. И каждый объект может иметь отношения как с одним, так и с несколькими объектам. Например, возвращаясь к примеру с лесом и сайтом, мы имеем следующую ситуацию: у нас определены Containment-отношения между классами AD Forest и AD Site. Исходя из этого, мы можем для класса AD Forest создать Dependency-монитор, который ссылается на монитор Availability класса AD Site. Но в системе в одном лесе может быть несколько сайтов, поэтому при оценке здоровья будет использоваться состояние всех сайтов в данном лесе.

            Кроме правила определения состояния «лучший-худший», Dependency-монитор позволяет настроить реакцию на случаи, когда монитор, на который идеи ссылка, не доступен (unmonitored), и когда зависимый объект находится в состоянии обслуживания (Maintenance mode). Для каждого из состояний можно игнорировать этот монитор (Ignore), переводить монитор в состояние Warning или переводить монитор в состояние Critical.

            Health Explorer

            Главным инструментом для работы с моделью здоровья служит Health Explorer. В этой консоли сведены все мониторы для объекта. Health Explorer можно вызвать для любого объекта в системе. На рисунке представлен скриншот Health Explorer, вызванный для объекта класса AD Forest:

            Корневой элемент в дереве – Entity Health, это и есть общее состояние объекта. Все остальные элементы строятся по шаблону «Имя_правила – имя_объекта (класс_объекта)». Например, элемент «Logical Disk Availability – C: (Windows Server 2003 Logical Disk)» следует понимать как монитор «Logical Disk Availability», который проверяет здоровье объекта с именем «C:», принадлежащий к классу Windows Server 2003 Logical Disk.

            Кроме этого, из Health Explorer можно посмотреть свойства любого монитора. Пример свойств Dependency-монитора AD Forest Availability Health Rollup Monitor:

            Как видно, данный монитор устанавливает зависимость от монитора Availability класса AD Site, а также имеет политику сбора, согласно которой монитор переходит в худшее состояние из 40% лучших сайтов J.

            В отличие от основной консоли, обновление информации не происходит автоматически: Health Explorer отображает состояние объектов на момент его открытия. Для обновления информации можно воспользоваться соответствующей кнопкой на панели.

            Сброс состояния (Reset Health)

            В идеальных условиях, переход между состояниями монитора (здесь и далее речь идет о unit-мониторах) должен происходить после выполнения неких проверочных действий. Но мир ИТ далек от идеалов, и всегда находится момент, когда необходимо отойти от идеалов, и сделать всё через «запасный выход». Такая же ситуация может сложиться и с монитором, ведь легко можно представить, когда у нас есть критерий перехода монитора в состояние Critical, но нет правила, по которому мы могли бы вычислить, что с объектом уже всё в порядке. Часто такое поведение встречает, когда «здоровье» вычисляет по событиям в журнале операционной системы: мы имеет событие, которое говорит о том, что с сервером что-то случилось, а вот события, говорящее о том, что работоспособность восстановлена – нет.

            Для выхода из таких ситуаций монитор может быть создан с ручным сбросом (Manual Reset) и со сбросом по времени (Time Reset). Монитор с ручным сбросом может переходить в состояние Critical или Warning, но никогда автоматически не вернется в состояние Health. Для сброса состояния таких мониторов необходимо открыть Health Explorer, выбрать нужный монитор и нажать кнопку Reset Health. После некоторого времени, состояние монитора будет сброшено в Health. Также состояние можно сбрасывать с помощью скриптов на Powershell (готовых командлетов для этого нет) или с помощью сторонних программ (например GreenMachine).

            Мониторы со сбросом по времени работают следующим образом. В свойствах монитора указывается, через какое время состояние объекта будет сброшено в Health. Когда монитор переходит в состояние Critical (или Warning), запускается отчет. По достижении указанного промежутка времени, монитор сбрасывается в Health. Например, вот так будет меняться состояние монитора, настроенного на событие в журнале безопасности и сброс в Healh через 2 минуты:

            Обратите внимание, что в последнем случае сброс произошел через 4 минуты. Это связано с тем, что при появлении события, отчет зачинается заново.

            Быстро определить, каким образом происходит возврат монитора в Health можно в свойствах монитора: на вкладке Health в столбце «Monitor Condition» обычно описан тип возврата.

            Кроме сброса состояния, существует также возможность вычислить состояние на данный момент (recalculate state). При этом предпринимается попытка запустить монитор, и получить текущие данные о состоянии объекта. Но в реальной жизни это используется редко, т.к. далеко не все мониторы поддерживают пересчет состояния, и определить, поддерживает ли монитор пересчет состояния или нет, стандартными средствами нельзя.

            «Залипание» состояния

            Как было описано выше, rollup-мониторы целиком и полностью зависят от состояния unit-мониторов. Поэтому они меняют своё состояние в зависимости от нижележащих unit-мониторов. Но иногда можно наблюдать вот такую картину:

            Как видно, все unit-мониторы находятся в состоянии Health, а вот rollup-монитор в Critical. Reset Health здесь не поможет, и одно из средств – установить объект-хозяин в Maintenance Mode на минимальное время (5 минут). При выходе из Maintenance Mode происходит сброс всех мониторов объекта в Health.

            Заключение

            В данной статье мы кратко рассмотрели модель здоровья в OpsMgr. На поведение мониторов влияет несколько других компонентов OpsMgr, такие как упомянутый Maintenance Mode, а также overrides. Также при создании собственных мониторов важным является понимание нацеливания мониторов (targeting). Обо всем этом вы можете прочитать в сопроводительной документации к продукту, или позже в моих статьях.

            В следующей статье речь пойдет о пакетах управления (management packs) и компонентах, входящих в них.

            Антон Гриценко ака FreemanRU

            OpsMgr.ru

          • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
            • System Center Operations Manager 2007 R2 — Service Modeling

              В предыдущей части мы рассмотрели компоненты, из которых состоит система, построенная на OpsMgr 2007 R2. Теперь речь пойдет о том, как же работает OpsMgr «изнутри».

              OpsMgr реализует концепцию управления на основе моделей (model-based management). Любую систему можно разложить на службы (services), в свою очередь, любую службу можно представить в виде некой модели. Использование моделирования позволяет легко описать любую службу или процесс, при этом абстрагировавшись от реального аппаратного и программного обеспечения. Для примера моделирования и его крайней полезности в деле мониторинга, можно привести массу примеров. Например, возьмем терминальные службы: их разворачивают в компаниях с числом серверов от одного до нескольких тысяч. В рамках классического объектного мониторинга в каждом случае пришлось бы строить систему «по месту» – вносить в систему мониторинга каждый сервер, каждый сервис на этом сервере, строить некие правила проверки и так далее. При использовании моделирования мы можем создать некую абстракцию, создать для неё правила проверки и признаки, по которым мы можем отличить терминальные службы от прочих – и тогда всё равно, сколько серверов и компонентов в нашей системе, все они будут проверяться по единой модели и единым правилам.

            • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
              • System Center Operations Manager – Компоненты OpsMgr R2

                В предыдущей статье я вкратце описал класс систем мониторинга, к которым относится System Center Operations Manager. Данная статья будет первой технической статьей, и в ней я опишу компоненты, составляющие систему, построенную на OpsMgr.

                SCOM vs OpsMgr

                И то, с чего я хотел бы начать свой рассказ о самом продукте, покажется немного странным, однако прояснить этот момент я считаю необходимым. Речь идет о названии продукта, а точнее о его сокращении. Все продукты линейки System Center сокращаются одинаково – по первым буквам слов в названии. Например, System Center Configuration Manger – это SCCM, ну и т.д. Но так было не всегда. Когда выходила очередная версия Microsoft Operations Manager, она была включена в состав линейки продуктов System Center и получила название System Center Operations Manager 2007. И тут оказалось, что сокращение SCOM крайне напоминает слово scam. Разработчикам и маркетологам не очень понравилось такое совпадение, и решено было сделать официальным сокращением аббревиатуру «OpsMgr». Впоследствии оказалось, что ИТ-сообщество не усмотрело в SCOM ничего такого обидного, и активно пользовалась именно этим сокращением. После не большого промежутка времени маркетинг Microsoft сдался, и официальным сокращением стало SCOM. Однако среди специалистов и разработчиков продукта до сих пор «идеологически верным» является сокращение OpsMgr, поэтому и я, дабы не нарушать идеологии, пользуюсь именно этим сокращением в своих статьях. Данных факт до сих пор вносит некоторую неразбериху при поиске информации о продукте, поэтому в тегах к статье вы можете увидеть оба сокращения.

                Еще одно отступление, которое хотелось бы сделать – это локализация. В русском ИТ-сообществе использование локализованных версий продуктов фактически является «дурным тоном». В основном это связанно с тем, что качество перевода оставляет желать лучшего. Кроме этого, поиск решения возникающих проблем проще производить на английском языке. Но есть продукты, которые зависят от языковой среды, в которой они работают. И при локализации этих продуктов могут возникнуть ошибки не только в переводе, но и собственно в функционировании продукта. К таким вот продуктам относится и OpsMgr. Справедливости ради надо отметить, что на данный момент, с выходом OpsMgr 2007 R2 и CU2 к нему, эта проблема во многом «сошла на нет», но если вы не хотите в какой-то определенный момент выступать в роли тестировщика, мой совет – никогда не устанавливайте в качестве каких-либо компонентов в системе мониторинга локализованные продукты. Это касается всех компонентов – ОС, SQL Server и самого OpsMgr. Этим вы обезопасите себя хотя бы от ошибок при локализации. В связи с этим в статье я буду давать собственный перевод терминов и названий, приводя оригинальное название на английском языке.

                System Center Operations Manager 2007 R2

                На данный момент крайней версией продукта является System Center Operations Manager 2007 R2, которая имеет следующие возможности:

                • Поддержка большого числа устройств в качестве точек мониторинга: Windows-компьютеры с агентом, Windows-компьютеры без агента, *NIX-компьютеры с агентом, SNMP-устройства (это не только сетевые устройства, но и вообще любые системы, способные выступать в роли SNMP-агента: серверное оборудование, операционные системы и т.д.).
                • Обнаружение установленных систем и компонентов на точках мониторинга
                • Выполнение действий по проверке состояния обнаруженных систем и компонентов: Monitors (мониторы) и Rules (Правила)
                • Выполнение диагностических и корректирующих воздействий
                • Сбор данных с точек мониторинга – Collection Rules. Обычно это данные о производительности.
                • Раздельное хранение краткосрочных и долгосрочных (отчетных) данных. Срок хранения программно не ограничен ничем, и зависит только от возможностей вашего аппаратного обеспечения.
                • Ролевая система доступа
                • Возможность отправлять уведомления по нескольким каналам: SMTP, SMS, IM и с использованием внешних приложений
                • Масштабируемость системы: от 30 до десятков тысяч точек мониторинга
                • Мониторинг соблюдения показателей SLA
                • Возможность передачи событий во внешние системы, в том числе с синхронизацией состояния
                • Сбор событий из журнала безопасности (Audit Collection Service – ACS)
                • Разработки дополнительных модулей
                • Поддержка базы знаний

                Компоненты OpsMgr

                Административной единицей в системе мониторинга на основе System Center Operations Manager 2007 R2 является группа управления, состоящая из следующих компонентов:

                • Операционная база данных (Operation DB);
                • Корневой сервер управления (Root Management Server – RMS);
                • Отчетная база данных (DataWarehouse DB) и интерфейса отчетности;
                • Один или несколько дополнительных серверов управления (Management Server – MS);
                • Один или несколько серверов-шлюзов (Gateway Server);
                • Консоли мониторинга;
                • Веб-консоли мониторинга (Web-Console);
                • Базы данных (ACS DB) и коллекторов событий (ACS Collector) из журналов безопасности (Security Event Log) Windows;
                • Агенты, устанавливаемых на серверах и рабочих станциях (Windows или *NIX);

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

                Группа управления

                Группа управления – это исключительно административное деление, чем-то напоминающее домен в Active Directory. Сравнение может и грубое, но для понимания назначения группы я считаю его оптимальным. При проектировании системы мониторинга необходимо стремиться всегда иметь одну группу управления. Добавление группы мониторинга может понадобиться в случаях, когда:

                • Количество компьютеров, которые необходимо мониторить, превышает 5000. Жестких ограничений нет, но крайне рекомендуется не превышать это число по соображениям производительности.
                • Необходимо использовать тестовое окружение.
                • Есть четкое административное разделение компьютеров на группы, и эти группы требуют абсолютно разных настроек мониторинга. В принципе, это можно реализовать и в одной группе, но иногда удобнее сделать разные группы. Например, у вас есть 150 серверов, которые необходимо мониторить полностью по всем аспектам, и есть еще 100, на которых необходимо лишь снимать базовые показатели производительности. Чтобы не делать множество переопределений в одной группе мониторинга, проще разделить эти сервера на разные группы управления.
                • Необходимо выделить ACS в отдельную группу. Это может понадобиться с точки зрения безопасности, т.к. администраторы группы мониторинга имеет доступ ко всем данным в группе, в том числе и к данным ACS.
                • Необходимо разделить компьютеры по географическому принципу или из-за особенностей сетевой топологии. Данный момент будет подробно рассмотрен при описании сетевого взаимодействия различных компонентов OpsMgr.

                В случае если в организации развернуто несколько групп, их можно подключить друг к другу. В этом случае одна из группы будет ведущей (Top-Tier), остальные группы будут подключенными (Mid-Tier). Это делается для того, чтобы можно было просматривать данные из нескольких групп в одной консоли. Консоль должна быть подключена к ведущей группе. При этом из ведомой группы передаются только события и состояние объектов, и ничего больше. Веб-консоль также не поддерживается – она будет отображать только данные своей группы.

                Точки мониторинга

                Как уже было сказано выше, в качестве точки мониторинга могут выступать Windows-компьютеры с агентами и без агентов, *NIX-компьютера с агентами и агенты SNMP.

                Windows-агенты

                Максимальную информацию, естественно, предоставляет точка мониторинга с агентом (agent-management state). Агент мониторинга может предоставлять как всю информацию о компонентах и системах расположенных на самом компьютере, где он установлен, так и о других системам. Классическим примером является кластер – агенты расположены на нодах кластера, но кроме самих нод, агенты передают информацию обо всех виртуальных серверах, участвующих в кластере. Agent-management компьютер всегда подключен к какому-либо серверу управления (RMS или MS). Переключение между серверами управления может производиться как в автоматическом режиме (при потере связи с текущим MS), так и в ручном – из консоли управление OpsMgr. При количестве агентов более 100 рекомендуется строить систему таким образом, чтобы агенты не были подключены к RMS. Агент может работать в двух режимах – управляемом (Manageable) и не управляемом (unmanageable). Отличаются эти два режима способом установки агента. В случаях, когда агент был установлен из консоли OpsMgr, агент считает управляемым. Во всех остальных случаях (установка «руками», с помощью SCCM или иным способом) агент считается не управляемым. Функционально отличие состоит в том, что управляемый агент можно переключить с одного управляемого сервера на другой, удалить и обновить из консоли OpsMgr. Обновление – это один из самых важных аспектов, т.к. при установке обновлений на OpsMgr управляемые агенты обновляться автоматически, а вот на все не управляемые необходимо будет устанавливать обновления вручную.

                Безагентный мониторинг Windows

                Безагентный мониторинг (Agentless) используется тогда, когда нет возможности установить агент на компьютер. Agentless-монторинг накладывает существенные ограничения: большинство правил и мониторов не будут работать при таком методе. Но тут есть нюанс – как уже говорилось выше, агенты могут передавать данные не только о себе, но и о других объектах, в том числе о безагентных компьютерах. Например, все виртуальные сервера в кластере подключаются в систему как безагентные.

                Мониторинг Unix и Linux

                В версии OpsMgr R2 была добавлена возможность устанавливать агенты на компьютеры под управлением Unix и Linux, ранее известная под именем SCXplat – Cross Platform Extension. На данный момент поддерживают следующие версии ОС:

                • AIX 5.3 (Power), 6.1 (Power)
                • HP-UX 11iv2 (PA-RISC и IA64), and 11iv3 (PA-RISC и IA64)
                • Red Hat Enterprise Server 4 (x64 и x86) и 5 (x64 и x86)
                • Solaris 8 (SPARC), 9 (SPARC) и 10 (SPARC и x86 версии старше 120012-14)
                • SUSE Linux Enterprise Server 9 (x86) , 10 SP1 (x86 and x64) и 11 (x86 и x64)\

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

                Кроме этого, OpsMgr может выступать в роли syslog-сервера, и обрабатывать поступающие сообщения.

                Мониторинг устройств SNMP

                OpsMgr позволяет взаимодействовать с агентами SNMP по средствам Get-запросов. Кроме этого, OpsMgr может выступать в роли получателя trap-ов для агентов, зарегистрированных в системе. Такие устройства в терминах OpsMgr называются Network Devices. К сожалению, «из коробки» OpsMgr имеет лишь базовую функциональность: единственное, что проверяется по умолчанию, это доступность устройства путем отправки Get-запроса на устройство. До недавнего времени было всего два решения: писать все нужные дополнения самому, либо приобретать коммерческие решения. Цена последних была заоблачной, и зачастую в несколько раз превосходило стоимость внедрения самого OpsMgr. Не так давно ситуация изменилась, и был выпущен пакет xSNMP, который позволяет мониторить основные характеристики SNMP-устройств, при этом распространяется бесплатно. Список поддерживаемых производителей и устройств впечатляет:

                • APC
                • APC/NetBotz
                • Brocade
                • Check Point SPlat
                • Cisco
                • Data Domain
                • Dell PowerEdge
                • HP ProCurve
                • HP Proliant
                • IBM AIX
                • Juniper Networks
                • NetApp
                • NetScreen Firewalls
                • NetSNMP (Unix/Linux)
                • NetScreen Firewalls
                • SonicWALL Firewalls
                • Sun Server Hardware

                Что нельзя мониторить?

                Список того, что можно мониторить, может показаться не большим. Но на самом деле ответ на вопрос «Что можно мониторить с помощью OpsMgr» прост – всё. Абсолютно всё, что доступно по сети, можно так или иначе мониторить с помощью OpsMgr. Всё зависит только от вашей фантазии и желания. Например, можно проверять наличие кофе в кофеварке.

                Сервера управления

                В системе OpsMgr есть два вида серверов управления – корневой сервер управления (RMS) и рядовой сервер управления (MS). RMS – это первый сервер, устанавливаемый в системе. В системе может быть только один RMS. RMS отличается от рядового сервера следующим:

                • На RMS располагается служба SDK и Config, которая отвечает за подключение консолей управления, любых коннекторов и внешних систем
                • На RMS располагается служба Config, которая отвечает за распространение настроек группы на другие компоненты системы
                • RMS выполняет ряд workflow, отвечающих за функционирование некоторых аспектов системы, таких как оповещения, назначение компьютеров в рамках AD Integration (будет рассмотрено отдельно), grooming базы данных и других.

                Набор служб на RMS и MS одинаковый: System Center Data Access (OMSDK), System Center Management (HealthService) и System Center Management Configuration (OMCFG). Но на рядовом MS службы OMSDK и OMCFG отключены (Disabled), и включаются только если роль сервера повышается до RMS. Как видно из списка – RMS является ключевым компонентом системы, и требует обеспечения отказоустойчивости. Достигнуть отказоустойчивости можно двумя способами:

                • расположить RMS на кластере
                • использовать дополнительный рядовой сервер, и при выходе из строя RMS поднять рядовой сервер до RMS.

                Выбор зависит от требований к отказоустойчивости и бюджета организации. В случае кластера, вам необходимо будет иметь два сервера с установленной ОС Windows Server Enterprise Edition, при этом один сервер будет простаивать. Время восстановления составит несколько секунд. В случае же использования второго сервера MS, достаточно установить Windows Server Standard Edition, при этом второй сервер может обслуживать агентов, что позволяет распределить нагрузку на сервера. При этом время восстановления может занять до получаса. Восстановление представляет собой повышение второго сервера до RMS.

                Сервер-шлюз (gateway server)

                Вся коммуникация между агентами и серверами управления происходит только после взаимной аутентификации. Для аутентификации в обычных условиях используется Kerberos. Причем Kerberos используется не только для аутентификации, но и для шифрования трафика между агентом и серверами управления. Такой подход вводит некоторые ограничения, а именно: сервера и агенты должны располагаться в пределах доменов AD, отношения между которыми поддерживают Kerberos. Таких отношений всего два: parent-child trusts и full forest trusts. Т.е. если агенты и сервера находятся в разных лесах AD, то между этими лесами должны быть настроены full forest trusts. Доверие между доменами в разных лесах не подходит. Но что же делать, если агенты и сервера управления расположены в разных лесах, и доверие между ними установить нельзя? Или агенты вовсе расположены в рабочей группе, и ни о каком Kerberos речи идти не может? В этом случае поддерживается аутентификация при помощи сертификатов. Для этого необходимо установить сертификат на каждый компьютер с агентом и на сервера управления. Отличная возможность! Пока дело не доходит до реального внедрения. Установить сертификаты на 30-50 серверов (а это не редкость, например в случае использования DMZ) в ручном режиме, а потом еще и сопровождать всё это – не самое приятное занятие. Ведь надо следить за отозванными сертификатами, за истечением срока действия и т.д. И далеко не всегда есть доступ от таких компьютеров до сервера сертификатов. Для упрощения системы в таких ситуациях служит роль «шлюз» – Gateway Server. Как и следует из названия, шлюз становится посредником между агентами в одном домене и серверами управления в другом. При этом шлюз располагается в том же домене, что и агенты, поэтому аутентификация происходит с помощью Kerberos. В свою очередь, аутентификация между шлюзом и серверами управления происходит при помощи сертификатов:


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

                Базы данных OpsMgr и система отчетности

                Для работы OpsMgr необходим MSSQL Server. Он выполняет роль хранилища всех данных – от конфигурационных до отчетных. Кроме этого, одна из ролей MSSQL – Reporting Services, используется для системы отчетности OpsMgr. Для работы OpsMgr необходим MSSQL Server 2005 или старше, либо MSSQL Server 2008 SP1 и старше. Заметьте, что MSSQL Server 2008 без SP1, а также MSSQL Server 2008 R2 не поддерживаются. MSSQL Express также не поддерживается.

                Добавлено 28.09.2010. С этого момента добавлена поддержка MSSQL 2008 R2 Standard и Enterprise, но с некоторыми ограничениями. Подробно решение описано в Базе Знаний.

                Для каждой группы OpsMgr необходимо от одной до нескольких баз данных:

                • Одна база данных OperationDB. Это основная база данных, в которой содержатся все данные о конфигурации группы и текущие данные мониторинга. Данная БД обязательна для каждой группы, и в системе с высокой доступностью – основной кандидат на кластеризацию;
                • Одна отчетная база данных. Содержит в себе данные долгосрочного хранения. Используется для построения отчетов. Замечу, что несколько групп могут использовать одну базу данных отчетности (и, соответственно, один сервер отчетности)
                • Одна или несколько баз данных ACS. Несколько баз данных может потребоваться в том случае, когда у вас используется несколько коллекторов ACS, т.к. один коллектор может использовать только одну, выделенную ему, базу данных.

                Отчетность и ACS будут рассмотрены отдельно, т.к. это достаточно объемные темы.

                Консоль OpsMgr

                Основным инструментом администратора является консоль OpsMgr. Она может быть установлена на любой компьютер, работающих под управление ОС Windows XP SP2 и старше. Консоль позволяет просматривать данные мониторинга, состояние объектов, выполнять задачи, просматривать отчеты, производить настройки системы, производить базовую разработку (Authoring). Общий вид консоли представлен ниже:

                Веб-консоль (Web-console)

                Веб-консоль является альтернативой основной консоли OpsMgr, и может применяться в случаях, когда достаточно просмотра сообщений и состояния объектов. Веб-консоль построена на базе IIS и AJAX, и требует наличие на клиенте только браузера. На сегодняшний день поддерживает только Internet Explorer 6 и выше. FireFox, Chrome и прочие альтернативные браузеры просто не работают с веб-консолью. При проектировании рекомендуется располагать веб-консоль вместе с ролью RMS. От основной консоли веб-консоль отличается отсутствием возможности производить настройки группы, производить разработку и просматривать отчеты (система отчетности имеет собственный веб-интерфейс). Вид веб-консоли представлен ниже:

                Audit Collection Service (ACS)

                ACS – это отдельный компонент в OpsMgr, который служит для сбора событий безопасности из одноименного журнала ОС Windows. ACS позволяет производить анализ событий безопасности, и интересна в первую очередь представителям службы безопасности. В частности, она позволяет ответить на такие вопросы, как кто и когда выполнял вход на рабочие станции, какие учетные записи были заблокированы, какие пользователи добавлялись в группы и т.д. ACS состоит из 3 компонентов:

                1. Collector ACS – служба на одном из серверов OpsMgr, отвечающая за прием событий и передачи их в базу данных.
                2. Forwarder ACS – служба на любом компьютере под управлением ОС Windows, на котором есть агент OpsMgr. Форвардер передает все события безопасности из локального журнала на коллектор.
                3. База данных ACS – отдельная база данных, в которую попадают все события от коллектора.

                Каждому коллектору соответствует только одна база данных ACS. Одна база данных не может обслуживать несколько коллекторов. ACS работает следующим образом:

                1. В момент запуска на удаленном компьютере с агентом, служба ACS Fowarder собирает все события безопасности с момента последнего запуска. Если это первый запуск – собираются все записи из журнала безопасности. Записи отправляются на Collector, который указывается при настройки ACS Fowarder.
                2. Collector ACS принимает данные о событиях безопасности, производит фильтрацию (фильтр позволяет настроить какие записи попадут в базу данных, а какие будут исключены), затем согласно схеме обрабатывает данные событий безопасности и записывает обработанные данные в базу данных.

                ACS это также довольно обширная тема, поэтому ей будет посвящена отдельная статья.

                В этой статье мы рассмотрели основные компоненты, из которых состоит система, построенная на OpsMgr. В следующих статьях пойдет речь о том, как устроен OpsMgr изнутри.

                Антон Гриценко ака FreemanRU

                opsmgr.ru

                • Тестируем внешние HDD через различные подключения. Часть -2

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

                  Поговорили о многом, вот только не было возможности протестировать eSATA подключение к ноутбуку из-за отсутствия такового порта в моем ноуте Lenovo ThibkPad R61. OS : Windows 7 Ultimate Edition [6.1 Build 7600] (x64)

                  Сегодня удалось заполучить преходник на eSATA.
                  Модель с одним eSATA портом Orient EX-1SATA.

                  P1050938P1050936
                  Делая тесты, мелькнула мысль, а будет ли разница в скорости между USB-портами находящимися “на борту” ноута и портами, подключенными как PCMCI-карта?
                  В моем арсенале как раз был такой девайс. Rovermate <Adaptmate-054> Adapter Cardbus-> USB2.0 4-port (RTL)

                  P1050937P1050935

                  Коллективное фото переходников.
                  P1050933

                  Измерение скорости производил с помощью накопителя i-Stor iS302 с установленным в нем Seagate Barracuda 7200.12 500 GB ST3500418AS.
                  При тестировании, кроме iS302, никакие другие USB устройства подключены к компьютеру не были.

                  Произвел три измерения.
                  iS302 USB – скорость работы через бортовые USB.
                  iS302 USB PCMCI – скорость работы через добавочные USB.
                  iS302 eSATA – скорость работы через бортовые USB.

                  Тест/Диск – Способ подключения iS302
                  USB
                  iS302 USB PCMCI iS302
                  eSATA
                  Sequential Read 34.989 MB/s 17.302 MB/s 126.578 MB/s
                  Sequential Write 19.733 MB/s 12.101 MB/s 104.942 MB/s
                  Random Read 512KB 21.118 MB/s 10.570 MB/s 39.183 MB/s
                  Random Write 512KB 14.654 MB/s 11.277 MB/s 60.263 MB/s
                  Random Read 4KB (QD=1) 0.438 MB/s [   106.9 IOPS] 0.440 MB/s [   107.3 IOPS] 0.458 MB/s [   111.7 IOPS]
                  Random Write 4KB (QD=1) 1.305 MB/s [   318.7 IOPS] 1.338 MB/s [   326.6 IOPS] 1.316 MB/s [   321.3 IOPS]
                  Random Read 4KB (QD=32) 0.628 MB/s [   153.4 IOPS] 0.616 MB/s [   150.3 IOPS] 1.306 MB/s [   318.8 IOPS]
                  Random Write 4KB (QD=32) 1.339 MB/s [   326.9 IOPS] 1.310 MB/s [   319.7 IOPS] 1.348 MB/s [   329.2 IOPS]

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

                  PS Подключить eSATA диск на “горячую” не удалось. Для того, чтобы система увидела связку eSATA-переходник+iS302 eSATA пришлось выключиь ноут, подключить карту и диск. После загрузки ОС попросила рестарта. После перезагрузки ОС, диск стал нормально виден в системе.
                  Отключение на “горячую” прошло без проблем. Сначала отключил диск, затем карточку. ОС успешно продолжила работу.

                • Главная System Center, Без рубрики, Новое OpsMgr, SCOM, мониторинг
                  • Мониторинг в корпоративной среде

                    Предисловие

                    Эта статья является первой в цикле статей об Microsoft Operations Manager 2007 R2. Сколько в итоге получится таких статей, я не знаю. Всё будет зависеть от наличия свободного времени, интереса читателей и еще кучи факторов. В первой статье я вкратце опишу, что понимается под словом «мониторинг» когда речь заходит о средних и крупных ИТ-системах. Если же у вас уже есть понимаю, что вам необходима система мониторинга уровня OpsMgr – можете смело пропустить эту статью, не думаю что вы найдете здесь для себя что-то новое.

                    Понятие мониторинга

                    Мониторинг. Очень часто доводится слышать этот термин в сфере ИТ. Но самое интересное, что каждый понимает под этим словом что-то своё. Для кого-то это – проверить, жив ли сервер пингами, а для кого-то – понять, почему вдруг пользователи начали жаловаться на «тормоза» в корпоративном приложении. И все по-своему правы. И на каждом уровне развития ИТ-инфраструктуры используется свои методы и средства для наблюдения и оценки работы ИТ-инфраструктуры.

                    Когда у вас 1-2 сервера вы вряд ли задумывается о мониторинге. Обычно сервера находятся «под боком», вы можете хоть каждый час проверять сами их состояние, и при возникновении проблем вы узнаете сразу. При этом каждый аспект работы этих серверов изучен, и вы знаете как реагировать на ту или иную проблему. При росте инфраструктуры, когда у вас уже 5-10 серверов, следить за всеми серверами «руками» не так удобно. Обычно на этом этапе начинается внедрение скриптов, различных автоматических «пинговалок» и «проверялок» вроде GoldenEye. Но вот когда число серверов переваливает за 20-30, и бизнес-приложения начинаются «размазываться» по нескольким серверам, такие средства оказываются не совсем к месту. Часто приходилось видеть ситуации, когда по данным скриптовых проверок и проверок состояний различных служб всё отлично (всё пингуется, все службы запущены), а пользователи всё равно жалуются – почта «не ходит», 1С тормозит, сайт не открывается. И тогда администратор начинает «разбор полетов». И вот тогда обычно возникает вопрос – «а что происходит там, внутри приложения? Какие ресурсы и компоненты задействованы?». Именно в этот момент происходит понимание, что необходимо в первую очередь мониторить бизнес-приложения в целом, а уже потом сервера и службы, которые их обслуживают. Все крупные вендоры, такие как Microsoft, IBM, CA, HP, предлагают свои продукты исходя именно из этого подхода. И именно поэтому вместо monitoring употребляется слово operations management, т.е. управление операциями (а продукты от HP и Microsoft используют это обозначение в своих продуктах).

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

                    • Осуществлять проверку максимального числа компонентов бизнес-приложения на самом глубоком уровне.
                    • Иметь средства аналитики для быстрого обнаружения проблемных мест в работе бизнес-приложения, в том числе агрегации и корреляции событий.
                    • Уметь выполнять проактивный мониторинг, т.е. обнаруживать потенциальную проблему до начала её влияния на бизнес. Замечу, что для администратора эта возможность является одной из ключевых, т.к. не только позволяет избежать простой бизнеса, но и повышает его оценку в глазах руководителя.
                    • Иметь возможность долгосрочного хранения информации об ИТ-инфраструктуре
                    • Иметь возможность реагировать на процессы, вплоть до действий по восстановлению компонентов системы. Согласитесь, полезно, когда кто-то делает за тебя всю работу J
                    • Должна реализовывать в базовом функционале основные принципы ITIL, т.к. эти рекомендации давно стали де-факто стандартном в ИТ индустрии
                    • Иметь возможность ведения базы знаний

                    Этот список явно дает понять, что разного рода «проверялки» уровня GoldenEye не могут выполнять ни одной из этих задач, а если могут, то с очень большими оговорками. Некоторые коллеги могут возразить, что все эти задачи можно реализовать и самому, при помощи скриптов и различных утилит. Да, можно. Но такой подход можно охарактеризовать как «а после нас – хоть потоп». Он имеет право на жизнь в статичной инфраструктуре, где ничего не меняется годами (да, есть и такое, один знакомый недавно хвастался, что у него uptime сервера составляет что-то около 500 дней), или где применяются крайне специфичные системы. Но таких предприятий крайне мало. Что же касается «обычных» компаний, то в них ИТ-инфраструктура, а в особенности бизнес-приложения, редко переживают год. Представьте ситуацию – вы, как администратор, разработали отличную систему мониторинга, написали два десятка скриптов по косточкам разбирающие все ваши бизнес-приложения, даже «прикрутили» ко всему этому интерфейс. Получили за это премию и уважение руководства. А через год уволились. Приходит новый админ, и что? Документации нет, как это работает, знает только один человек, и тот уехал в Израиль\Австралию\Бирюлево и его координат нет. Да, но она работает, вроде бы всё отлично? Но через 3 месяца происходит внедрение новой версии корпоративного приложения, и построенная система мониторинга просто перестает работать. Обычно в этом случае про старую систему забывают, и начинают строить новую J Коммерческие системы мониторинга позволяют стандартизовать подход к проверке систем, что дает массу преимуществ, таких как наличия документации к системе, поддержки вендора, наличия специалистов по данной системе на рынке труда.

                    Итак, вы пришли к пониманию, что вам необходима коммерческая система мониторинга. Какую выбрать? Для меня ответ на этот вопрос на самом деле крайне прост – выбирайте систему того вендора, который максимально представлен в вашей инфраструктуре. Если у вас в сети большинство бизнес-приложений базируются на HPUX – выбирайте продукт от HP. Если у вас ядром системы являются решения от Oracle – выбирайте и мониторинг от Oracle. Если у вас бизнес-приложения завязаны на продукты Microsoft – выбирайте систему мониторинга от Microsoft. Ибо на сегодняшний день никто лучше не знает о продукте, чем вендор его создавший (с некоторыми оговорками и исключениями, конечно).

                    Хуже дело обстоит, когда сеть гетерогенная, и в ней перемещались не только несколько вендоров, но и несколько платформ – часть бизнес-приложений построено на платформе Windows, часть на Unix. В этом случае выбор системы не очевиден, и ответа на вопрос «что выбрать» однозначно дать не возможно. Очень может быть, что систем мониторинга будет не одна, а несколько. В этом случае необходимо обратить внимание на то, сколько ваших компонентов в данных момент, и насколько глубоко, поддерживает та или иная система мониторинга, как она развивается и поддерживается другими вендорами, насколько просто её интегрировать с другими системами, в том числе системами ServiceDesk.

                    Почему именно OpsMgr?

                    Сразу оговорюсь – я не ставил себе задачу сравнить системы мониторинга. Моя задача – рассказать про OpsMgr. Но всё же эту вводную статью я хотел бы закончить некими тезисами, почему я выбрал OpsMgr в качестве своей специализации, и в чем, на мой взгляд, основные его преимущества на данный момент перед другими подобными продуктами:

                    • Рынок Windows-based приложений на сегодняшний день огромен. И, как я уже говорил выше, никто не знает о своих системах лучше, чем создавший их вендор. Поэтому вполне логично, что система мониторинга от Microsoft является одним из основных кандидатом при выборе.
                    • OpsMgr способен получать данные от практически всех распространенных систем и приложений, существующих на рынке. Существуют решения для мониторинга VMware, Oracle Database, SAP, сетевых устройств Cisco, Linux-систем, Unix-систем, аппаратных платформ HP, Dell, Intel ,EMC и т.д. Список этот огромен, и многие из этих решений созданы для OpsMgr самими вендорами, что означает глубину управлением системы и поддержку со стороны вендора. За достаточно короткое время, OpsMgr стал де-факто основной системой мониторинга на рынке бизнес-приложений.
                    • Легкая интеграция с любыми внешними системами, в том числе двухсторонняя. Частое требование к системе мониторинга – передача событий в систему ServiceDesk\HelpDesk. OpsMgr «из коробки» имеет поддержку такой коммуникации, причем он способен не просто передать событие во внешнюю систему, но и поддерживать эту связь на протяжении всей жизни события и синхронизировать состояния события между системами.
                    • Относительная простота разработки компонентов системы. С одной стороны, создать достаточно мощную систему мониторинга собственного приложения или бизнес-сервиса можно прямо из консоли OpsMgr, не прибегая ни к каким сторонним средствам разработки. С другой, вы можете использовать любые средства разработки в случаях, когда вам потребуется мониторинг какого-либо крайне специфичного бизнес-приложения.
                    • OpsMgr позволяет выполнять мониторинг с точки зрения бизнес-пользователя. Он способен отслеживать соблюдение уровней SLA, строить карты распределенных бизнес-приложений и производить оценку влияния того или иного сбоя на это приложения согласно карте.

                    Этот список далеко не полный, и я очень надеюсь, что вы сами сможете его дополнить после изучения System Center Operations Manager.

                    Антон Гриценко ака FreemanRU

                    opsmgr.ru