none
Распределенная система SCOM 2012 RRS feed

  • Вопрос

  • Открывал уже тему здесь: http://social.technet.microsoft.com/Forums/ru-RU/momru/thread/b94cc714-fbf6-447c-abba-074e2f167d41?prof=required. 

    1) подулючение двух менедмент групп произошла удачно, только если накатываю обновления  ( http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/2f0c9862-dcd9-44fc-a345-8e7517d5be9c/ )  

    2) всё это работает только на уровне представлений.., и если канал связи падает, то мы не увидем алерты с другого SCOM из другого менеджмент группы. Мы не можем видеть всего остального, строить графики, счетчики  и т.д.

    3) единая база данных (допустим в центр. офисе), тоже не вариант, если падает канал, то в на удаленных площадках система мониторинга отваливается 

    Может есть какое нибудь решение...?

    Надеюсь, а то как то  странно получается.... (чем интресно мониторит Майкрософт свои сервера, или он мониторит только внутри каждого отдельного филиала и не нужна консолидация..? )

    Заранее благодарен!  


    С уважением к Вам Вашей работе

    5 октября 2012 г. 6:13

Ответы

  • В общем я понимаю вы хотели бы видеть возможность синхронизации не только алертов между управляющими группами но и всей остальной информации, для анализа всех логов, построения отчетов и тд... Но такой возможности действительно нет. Возможно если бы базы SCOM были не настолько велики то можно было бы что то придумать ... Вот только на практике в организациях базы SCOM (операционная, отчетная, acs) занимают 100-600 ГБ для одной управляющей группы и если представить что необходимо копию удаленной площадки держать в центральном офисе (а если таких офисов более 10 или 100?) то вы сами можете представить какой объем информации необходим...а ведь это еще надо как то бэкапить...в общем нагрузка на SQL сервер будет нереальная..

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

    Также есть возможность настройки агентов для отправки информации на обе управляющие группы что позволит синхронизировать данные. Архитектура multihomed. Увеличив при этом размер кэша для агента если нет доступа к управляющему серверу (как тут уже упоминали стандартно это 15 мегабайт (для SCOM 2012 ничего не поменялось).

    • Помечено в качестве ответа taramm 8 октября 2012 г. 11:29
    8 октября 2012 г. 7:16
  • Не хочется разводить войны, но мне кажется, что вы не правы на счет "другие системы могут". У Tivoli Hub-сервер является "точкой отказа", и должен быть всегда он-лайн. Да, у них есть возможность "переждать", когда он появится снова. Но это время лимитировано, так же, как и у OpsMgr.

    Соответственно,в сравнении с Tivoli, у OpsMgr каждый агент это своеобразный "remote server", который будет собирать данные и ждет, когда появится сервер управления, пока у него кэш не кончится. Кроме этого, у OPsMgr есть Gateway, который умеет собирать данные с других агентов, сжимать эти данные и передавать на сервер управления. Он конечно в основном предназначен для мониторинга не доверенных лесов\доменов, но никто не мешает использовать его и только для сжатия. И на нем точно также поддерживается кэширование.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    • Помечено в качестве ответа taramm 11 октября 2012 г. 10:39
    10 октября 2012 г. 20:34
    Отвечающий

Все ответы

  • Обычно, если отваливается канал - это АХТУНГ неимоверный.

    Но OpsMgr умеет кэшировать данные мониторинга на агенте, если сервер управления не доступен некоторое время (я не знаю значение по умолчанию для 2012 версии, для 2007 R2 это 15Мб).

    Соответственно, чудес не бывает - если вы хотите всё мониторить, вы должны иметь нормальный канал, который доступен более-менее постоянно.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    5 октября 2012 г. 8:48
    Отвечающий
  • Кешировниве данных не поможет.. ну потом покажет, что произошло... 

    А если упал канал не спорю, что ахтунг, но всё же это вполне, нормально для РФ... (к большому большому сожалению!)

    Если не ошибаюсь, сервера SCCM и подключенные к нему другие сервера SCCM (подчиненные), в 2012 версии реплицируют между собой БД...

    И ещё возник вопрос.. может существует какой нибудь коннектор для SCOM? (оркестратор посмотрел, у него примерно такие же возможности как и у подулючение двух менедмент групп)..


    С уважением к Вам Вашей работе


    • Изменено taramm 5 октября 2012 г. 9:32 дополнение
    5 октября 2012 г. 9:10
  • Это не нормально для РФ.

    Собственно, тогда не понятно чего вы хотите. Как вы собираетесь без канала получать данные о мониторинге???


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    5 октября 2012 г. 9:30
    Отвечающий
  • 1) Хм.. не будет вдаваться в дисскусию..

    2) допустим: два сервера SCOM (главный и доп) - две базы данных - два филиала в разных местах. Допустим существует какой-либо коннектор, который позволяет скачивать определенную инфу с доп. SCOM-a и передает инфу главному. При исполнении данного сценария админ главного SCOM видит, что происходит на доп. SCOM (соответвенно видит инфу о его ИТ инфраструтуре в целом), так же видит и админ доп. SCOM что творится у него в филиале. Так если канал падает админ доп SCOM продолжает видить что происходит, админ главного SCOM видит, то что происходило в филиале до того как канал упал.

    - Так вот, если же SCOM использует едниую БД расположенную в главном офисе, то при условии канал падает, админ филиала перестает видить что у него происходит, т.к. канал упал...

    - И если одулючение двух менедмент групп, то админ ГО аидит только алерты, и если падает канал, то перестает видить вообще что было в филиале.. 

     

    С уважением к Вам Вашей работе

    5 октября 2012 г. 9:40
  • Опять не очень понятно, возможно, из-за синтаксических и граматических ошибок. Вы хотите держать копии баз данных каждого сервера на каждой площадке? Скорее всего это невозможно. Здесь что-то похожее обсуждается - http://www.systemcentercentral.com/Forums/tabid/60/categoryid/4/indexid/60500/Default.aspx, но опять же не уверен, что вам нужно именно это.

    Vladimir Zelenov | http://systemcenter4all.wordpress.com


    5 октября 2012 г. 11:32
    Отвечающий
  • Привет, в целом вроде понятно, т.е когда мы к основному офису (одна управляющая группа) подключаем дополнительный офис (вторая управляющая группа) то из единой консоли мы видим алерты двух управляющих групп. Но когда канал падает то с основного офиса нет возможности подключиться к sdk удаленного офиса и нет возможности посмотреть последние алерты? так? почему бы тогда не настроить оповещения с двух управляющих групп ...допустим на почту или использовать command channel для передачи критических алертов в резервные источники... которые бы не зависели от качества каналов между офисами. Допустим открыли почту и смотрите что у вас происходило (или происходит) в удаленном офисе.

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

    5 октября 2012 г. 20:08
  • Да. Правильно поняли.

    Если настроить оповещения, всё же мы будем видеть алерты, но не сможем посторить разнгообразные схемы. Я хотел что то типо такого:


    С уважением к Вам Вашей работе

    8 октября 2012 г. 5:15
  • В общем я понимаю вы хотели бы видеть возможность синхронизации не только алертов между управляющими группами но и всей остальной информации, для анализа всех логов, построения отчетов и тд... Но такой возможности действительно нет. Возможно если бы базы SCOM были не настолько велики то можно было бы что то придумать ... Вот только на практике в организациях базы SCOM (операционная, отчетная, acs) занимают 100-600 ГБ для одной управляющей группы и если представить что необходимо копию удаленной площадки держать в центральном офисе (а если таких офисов более 10 или 100?) то вы сами можете представить какой объем информации необходим...а ведь это еще надо как то бэкапить...в общем нагрузка на SQL сервер будет нереальная..

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

    Также есть возможность настройки агентов для отправки информации на обе управляющие группы что позволит синхронизировать данные. Архитектура multihomed. Увеличив при этом размер кэша для агента если нет доступа к управляющему серверу (как тут уже упоминали стандартно это 15 мегабайт (для SCOM 2012 ничего не поменялось).

    • Помечено в качестве ответа taramm 8 октября 2012 г. 11:29
    8 октября 2012 г. 7:16
  • Ожидал, чего то такого.. К сожалению, продукты конкурентов могут выполнять данные хотелки..

    Не обязательно же через Orchestrator алерты переправлять, можно и с помощью connect managment groups...

    А 'Также есть возможность настройки агентов для отправки информации на обе управляющие группы что позволит синхронизировать данные. Архитектура multihomed' - не подскажете как это выполнить?


    С уважением к Вам Вашей работе


    • Изменено taramm 8 октября 2012 г. 7:39
    8 октября 2012 г. 7:20
  • Как я понимаю у вас к каждой управляющей группе подключены определенные агенты...но если вы из удаленной управляющей группы также произведете установку агента на уже управляемый агентом сервер главного офиса то агент будет отсылать одну и туже информацию на обе управляющие группы. Также можно произвести данные настройки непосредственно c сервера (для scom 2012 есть настройки из панели управления - Operations Manager Agent) или через скрипты.

    "Не обязательно же через Orchestrator алерты переправлять, можно и с помощью connect managment groups..."

    через connected management groups алерты не передаются в базу данных scom главного офиса. Она просто считывается и нигде как в памяти больше не хранится. Если же вы передали алерты при помощи Orchestrator то они будут уже в вашей системе и будут независимы от подключенной управляющей группы удаленного офиса. 

    8 октября 2012 г. 8:03
  • В 2012 это можно сделать непосредственно через панель управления. Вроде как в 2005 ограничение было 4 группы. В 2012 - не знаю, скорее всего так и осталось.

    http://www.bictt.com/blogs/bictt.php/2012/05/06/manipulating-scom-2012-agent-multihoming

    http://thoughtsonopsmgr.blogspot.com/2011/08/dude-where-is-multi-home-option-for.html


    Vladimir Zelenov | http://systemcenter4all.wordpress.com


    8 октября 2012 г. 8:15
    Отвечающий
  • 2007 R2 также по документам поддерживает до 4 подключенных групп - http://technet.microsoft.com/en-us/library/bb381302.aspx

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

    8 октября 2012 г. 9:21
  • А после того, как добавил в "Operation Manger Agent" на сервере SCOM выполнять, что то нужно?


    С уважением к Вам Вашей работе

    8 октября 2012 г. 10:26
  • В этом случае со стороны сервера ничего делать не надо ...если агенты подтверждаются автоматом...если же нет то проверьте настройки Global Management Servers Settings - Security (если стоит Reject то смените на Review new manual agent либо на автомат либо чтоб новые агенты появлялись в Device Management -> Pending Management для их подтверждения) . 
    8 октября 2012 г. 11:06
  • Спасибо всем!

    С уважением к Вам Вашей работе

    8 октября 2012 г. 11:29
  • Не хочется разводить войны, но мне кажется, что вы не правы на счет "другие системы могут". У Tivoli Hub-сервер является "точкой отказа", и должен быть всегда он-лайн. Да, у них есть возможность "переждать", когда он появится снова. Но это время лимитировано, так же, как и у OpsMgr.

    Соответственно,в сравнении с Tivoli, у OpsMgr каждый агент это своеобразный "remote server", который будет собирать данные и ждет, когда появится сервер управления, пока у него кэш не кончится. Кроме этого, у OPsMgr есть Gateway, который умеет собирать данные с других агентов, сжимать эти данные и передавать на сервер управления. Он конечно в основном предназначен для мониторинга не доверенных лесов\доменов, но никто не мешает использовать его и только для сжатия. И на нем точно также поддерживается кэширование.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    • Помечено в качестве ответа taramm 11 октября 2012 г. 10:39
    10 октября 2012 г. 20:34
    Отвечающий
  • "Войны" не будет, по крайне мере с моей стороны..  :)

    Мне просто интересно.

     "OPsMgr есть Gateway, который умеет собирать данные с других агентов, сжимать эти данные и передавать на сервер управления" - передает данные

    - только одному серверу управления в одной группе,

    -передает нескольким серверам управления одной менеджмент группы,

    - передает данные нескольким серверам в нескольких менеджмент групп?

    И на сколько он сжимает данные? 


    С уважением к Вам Вашей работе

    11 октября 2012 г. 5:31
  • Gateway может быть подключен к нескольким серверам управления одной группы, но работает в один момент времени с одним сервером, на другие переключается в случае отказа основного.

    Про сжатие: http://blogs.technet.com/b/momteam/archive/2007/08/31/low-bandwidth-scenarios.aspx


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    11 октября 2012 г. 9:01
    Отвечающий
  • Я правильно понимаю, для корректного сжатия данных, Gateway нужно размещать в каждом филиале. Далее инфа передается в ЦО на сервер OpsMgr?

    С уважением к Вам Вашей работе

    11 октября 2012 г. 10:24
  • Несколько дополнений по Gateway

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

    2. Агенты также сжимают трафик перед отправкой поэтому назвать этот трафик уж совсем неэффективным нельзя...Шлюз в этом случае получается эффективнее если на него повешено много агентов что дает такой же эффект как архиватор Rar с опцией Solid из за повторяющихся данных.

    3. Есть еще не очень хороший эффект от шлюза..так как его мы подключаем к управляющему серверу (напрямую шлюз в БД не пишет) тот же управляющий сервер рассматривает наш шлюз как всего лишь одного агента (не задумываясь что на шлюзе может висеть допустим 50 агентов) поэтому приоритет данных 50 серверов на запись данных будет ниже чем у тех агентов которые подключены непосредственно к управляющему серверу.

    11 октября 2012 г. 10:24
  • Я правильно понимаю, для корректного сжатия данных, Gateway нужно размещать в каждом филиале. Далее инфа передается в ЦО на сервер OpsMgr?

    С уважением к Вам Вашей работе

    Да


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    11 октября 2012 г. 10:26
    Отвечающий
  • @Alexis

    1. А по какой-такой причине агент будет переключаться на сервер управления? А если у меня шлюз стоит в DMZ, куда по вашей теории будет переключаться агент?
    2. А пруфлинк про агенты и сжатие можно? На сколько я знаю, агент вообще не сжимыет данные, а только их шифрует.
    3. И что? Какой здесь минус?


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    11 октября 2012 г. 10:30
    Отвечающий
  • А можно выполнить следующее:

    1) сделать Менеджмент группу в ЦО

    2) сделать Менеджмент группы в филиалах

    3) В филиалах поставить Gateway

    4) Подключить к   gateway серверу сервера управления SCOM в филиалах

    5) передавать уже с этих (в филиалах) Gateway информацию на сервер SCOM в ЦО?

    понимаю что извращенно..  


    С уважением к Вам Вашей работе

    11 октября 2012 г. 10:31
  • Нельзя.

    Но можно так:

    1. Группа в ЦО
    2. Группа в филиале
    3. Шлюз в филиале, подключенный к ЦО
    4. Агенты в филиале работают в режиме мультихомед, одновременно подключаясь к своей группе и к шлюзу

    Но это надо тестить. А зачем, собственно, такое решения? Если у вас связь пропадает на время большее, чем хранит данные у себя в кэше агент\шлюз, то вы эти данные в ЦО всё равно не увидети.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    11 октября 2012 г. 10:36
    Отвечающий
  • Сам додумал (про Ваш метод), спасибо!

    Но мы же увидем всё то, что происходило до того как упал канал. Схема странная.. Ещё раз спасибо! 

     

    С уважением к Вам Вашей работе

    11 октября 2012 г. 10:39
  • В этом случае либо шлюз, либо группа в филиале - лишнее звено.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    11 октября 2012 г. 10:40
    Отвечающий
  • Привет Антон,

    1. Если стоит в DMZ и нет резервного шлюза то естественно никуда не переключится (и на управляющие серверы тем более). Я не этот случай хотел упомянуть а только лишь тот когда шлюзы используются в качестве более эффективного сжатия трафика.

    2. System Center Operations Manager 2007 Unleashed by  Cameron Fuller

    Четвертая глава - Design
    Agent communication to the RMS, management servers, and gateway servers— The amount of data sent by the agent depends on the management packs installed on each agent, the type of activity generated, how those management packs are tuned, and conditions in your environment. The good news is the data between the agents and the management server/gateway server is compressed. 

    3. Помоему тут и так очевидно.. у одного агента подключенного напрямую приоритет 1 а у агента подключенного через шлюз (1/50 - если 50 агентов на шлюз). Можно словить большие проблемы особенно если агентов на шлюз вешать в большом количестве.

    вот и небольшой пруф и best practice

     Here’s why: In terms of priority, a management server does not distinguish between a

    traditional agent and a gateway server it is hosting. This means data from a gateway is
    assigned the same level of priority as that from a standard agent. That may seem reasonable
    on the surface, but if 100 agents report to the gateway, each agent is afforded
    only 1/100 of the standard priority otherwise afforded to an agent. If the management
    server hosting the gateway also has 100 agents of its own, each receiving 1/100 of the
    total priority, the agents reporting to the gateway will ultimately only receive 1/100 of
    that 1/100 slice of priority, or in more understandable terms, 1/10,000 of the priority.

    The authors and Microsoft recommend assigning a dedicated management server with
    no traditional agents reporting to it (even in a failover scenario), for the sole purpose of
    collecting data from your gateway server(s).

    11 октября 2012 г. 10:48
  • To Taramm 

    "И на сколько он сжимает данные? "

    Я честно досконально не проверял но в книгах указывают 20-30 процентов. Что не так плохо если много агентов.

    11 октября 2012 г. 10:50
  • А Gateway сервер может получать данные от безагентного мониторинга..?

    С уважением к Вам Вашей работе

    11 октября 2012 г. 11:23
  • Управляющие серверы и управляемые агенты могут выступать в качестве прокси для безагентного мониторинга. Так как шлюз это одна из разновидностей управляющего сервера то думаю может. Но вы наверное знаете что у безагентного мониторинга куча ограничений...не все MP могут работать с ним..я бы сказал большинство))))  
    11 октября 2012 г. 11:45
  • Да, знаю... 

    Спасибо.


    С уважением к Вам Вашей работе

    12 октября 2012 г. 5:59