none
выбор архитектуры sccm 2012 RRS feed

  • Вопрос

  • Посоветуйте оптимальную архитектуру для sccm 2012.

    Есть главный офис и 30 филиалов. В каждом филиале, в том числе и главном офисе, от 200 до 2000 клиентов. В целом не превышают 20 000. Возможен незначительный прирост клиентов. Ширина канала ~10 мб/сек.

    В большей части филиалов сидят свои админы, которые будут рулить sccm-ом для своего филиала.

    Что хочется:

    1.Централизованно управляемую систему из главного офис, при этом делегировать управление системой местным админам каждому из филиалов.

    2. Минимизировать передаваемый трафик между главным офисом и филиалами.

    3. Оптимально распределить нагрузку на системы сайтов (БД есть возможность вынести на отдельные серверы).

    2 октября 2013 г. 6:23

Ответы

  • Самое простое и самое правильное для вас, похоже - Primary в главном офисе (с выделенным сервером БД) и 30 Secondary.

    1. Делегирование управления осуществлять с помощью ролей, областей безопасности и коллекций.

    2. Трафик минимизирован.

    3. Нагрузка определяется в зависимости от задач. В случае необходимости добавляются сервера с системами сайта.

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



    3 октября 2013 г. 10:28
  • Согласен, что Secondary на каждый филиал - не оптимальный вариант с идеалистической точки зрения, но, в реалиях, когда сетевики очень подозрительно относятся ко всяким "лишним" трафикам - вполне оправдан ))

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

    Более логичным было бы оставить некоторые небольшие филиалы без вторичника и отслеживать сетевую активность, жалобы пользователей на сеть и т.п. - но вот это, как раз, не очень желательно ))


    Начиная с ConfigMgr 2012 достаточно установить локальные точки управления и точки распространения. Сайт сервер, к сожалению, нельзя защитить от отказов, в любом случае сайт ConfigMgr без сайт сервера будет функционировать, за тем исключением, что вы не сможете его администрировать. Все остальные роли можно разворачивать в нескольких экземплярах, что даст полную отказоустойчивость. Вы можете разнести SMS Provider на разные серверы, что позволит вам подключаться консолью к другим серверам (при этом Сайт сервер и SMS Provider должны быть установлены в одном домене).

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

    8 октября 2013 г. 5:21
    Отвечающий

Все ответы

  • Здравтсвуйте Валерий,

    Вы являетесь партнером Microsoft? Мой совет Вам воспользоваться "advisory hours", которые помогут Вам в выборе самой оптимальной конфигурации для Вашей сети


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий. Не забывайте помечать сообщения как ответы и полезные, если они Вам помогли.

    3 октября 2013 г. 6:04
    Модератор
  • Самое простое и самое правильное для вас, похоже - Primary в главном офисе (с выделенным сервером БД) и 30 Secondary.

    1. Делегирование управления осуществлять с помощью ролей, областей безопасности и коллекций.

    2. Трафик минимизирован.

    3. Нагрузка определяется в зависимости от задач. В случае необходимости добавляются сервера с системами сайта.

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



    3 октября 2013 г. 10:28
  • Спасибо за ответ.

    1. Плохо, только то что, если основной сайт будет не доступен, администрировать вторичные сайты администраторы филиалов не смогут.

    2. Доступ должен быть именно от клиентов к основному сайту или клиенты общаются с вторичным, а вторичный с основным?

    4 октября 2013 г. 5:26
  • 1. Это так. Но ConfigMgr не является системой реального времени и, как правило, для отказоустойчивости вполне хватает бэкапов системы и виртуалок - они восстанавливаются в несколько кликов, после чего система вновь работоспособна.

    2. Пардон, исправил. От клиентов вторичного сайта к серверу вторичного сайта.

    4 октября 2013 г. 6:00
  • Начните с http://technet.microsoft.com/en-us/library/gg712681.aspx

     Что касается Primary +30Secondary  не думаю, что самое оптимальное решение  для Вас

    Как вам уже сказали, логично будет установить Primary в HQ , что касается удаленных филиалов

    Secondary рекомендуется ставить в нескольких случаях

    Необходимы локальные MP SUP SMP, наличие определенного кол-ва клиентов  - некоторые рекомендуют более 500.

    Что касается трафика можете посмотреть как пример

    http://blogs.technet.com/b/manageabilityguys/archive/2013/04/22/system-center-2012-configuration-manager-client-network-traffic-estimates-series-part-1-of-3.aspx

    Старайтесь упростить иерархию


    Примечание:Сообщения предоставляются "КАК ЕСТЬ" без каких-либо гарантий,выраженных или подразумеваемых | Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied

    4 октября 2013 г. 14:00
    Отвечающий
  • Согласен, что Secondary на каждый филиал - не оптимальный вариант с идеалистической точки зрения, но, в реалиях, когда сетевики очень подозрительно относятся ко всяким "лишним" трафикам - вполне оправдан ))

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

    Более логичным было бы оставить некоторые небольшие филиалы без вторичника и отслеживать сетевую активность, жалобы пользователей на сеть и т.п. - но вот это, как раз, не очень желательно ))

    4 октября 2013 г. 14:29
  • Согласен, что Secondary на каждый филиал - не оптимальный вариант с идеалистической точки зрения, но, в реалиях, когда сетевики очень подозрительно относятся ко всяким "лишним" трафикам - вполне оправдан ))

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

    Более логичным было бы оставить некоторые небольшие филиалы без вторичника и отслеживать сетевую активность, жалобы пользователей на сеть и т.п. - но вот это, как раз, не очень желательно ))


    Начиная с ConfigMgr 2012 достаточно установить локальные точки управления и точки распространения. Сайт сервер, к сожалению, нельзя защитить от отказов, в любом случае сайт ConfigMgr без сайт сервера будет функционировать, за тем исключением, что вы не сможете его администрировать. Все остальные роли можно разворачивать в нескольких экземплярах, что даст полную отказоустойчивость. Вы можете разнести SMS Provider на разные серверы, что позволит вам подключаться консолью к другим серверам (при этом Сайт сервер и SMS Provider должны быть установлены в одном домене).

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

    8 октября 2013 г. 5:21
    Отвечающий
  • ОМГ, если сайтов больше 1, то вариантов без CAS не бывает в принципе, это ж 2012 :)

    Как правильно сообщили, можно открыть Advisory в MS и получить официальный ответ.

    Неофициально в вашем случае я б посоветовал CAS+PRI в центре, PRI по большим регионам и там, где свои админы, SEC или просто DP - там, где админов нет и мало клиентов.

    Если есть PRI, то админы смогут создавать свои пакеты в регионах и от себя их распространять. На SEC, как уже писали, можно поставить Software Update Point и собирать данные Inventory, но экономия в целом будет не слишком большая. Клиенты вторичных сайтов все равно будут генерировать трафик на primary каждый раз, как только у вас меняется тело политики, а сканирование обновлений - копейки, контент обновлений все равно будет распространяться с ближайшей DP.

    А 10 мегабит - это не так уж и мало, главное - стабильный чтоб канал был, с некоторой заторможенностью прокачки контента можно жить.

    9 октября 2013 г. 20:59