locked
SCCM 2012 design question RRS feed

  • Question

  • Hi

    I am trying to plan a design for SCCM 2012.

    We have 2 sites with about 500 users each (total 1000 users). Both sites are well connected.

    I have 2 designs in my mind.

    1. One primary site at site1 connecting to a sql instance on the cluster box

    And a Secondary site at site2.

                    OR

    1. One Centera site at site1 connecting to sql instance on the cluster box and 2 primary sites (one each at both the sites).

    Any advice on which one should I go for?

    Thnx

    Thursday, June 7, 2012 10:14 AM

Answers

  • Hi,

    I would go the one Primary site and a Secondary site, based on the fact that you have a well connected site and probabaly a reliable connection as well. And it is a much less complicated deisng and environment to manage with less SQL instances, less servers and resources used.

    I would go for 1 primary+ 1 secondary site

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    • Marked as answer by VinodR Monday, June 11, 2012 2:19 PM
    Thursday, June 7, 2012 12:52 PM
  • "With a CAS and two primary's we could redirect the clients to the other primary and keep the infrastructure intact."

    "What I understand is CAS+2Primary makes more sense if there was no SQL cluster?"

    No, to both of these. There is no auto-failover process for clients between primaries thus having two primaries for failover is, although technically feasible, not practical in reality.

    The main question here is exactly what is the requirement that you are trying to address? Generally, ConfigMgr functionality is not business critical and thus some down-time is accepatble per some sort of SLA. Within that SLA, normal backup and restore procedures is usually enough. But, once again, this all depends upon the exact functional requirements that exist in your enviornment. Saying that all of ConfigMgr should be HA is overly broad because there are many different roles and client centric functions -- planning to have all of these HA could be costly and completely unecessary.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by Zak Humphries Friday, June 8, 2012 11:13 AM
    • Marked as answer by VinodR Monday, June 11, 2012 2:19 PM
    Friday, June 8, 2012 1:49 AM
  • ConfigMgr 2012 has added all the stuff that needs to be recovered into the database now, so the recovry is extremely fast. In fact, the reinitializations required in a a hierarchy would add a lengthy delay as data is synchronized from CAS to primary. With a standalone primary - depending on the size of the data and how many site roles you have - you could be looking at a simple restore in 30 minutes or so - especially if you have an existing database sitting on a cluster.
    • Marked as answer by VinodR Monday, June 11, 2012 2:08 PM
    Friday, June 8, 2012 4:01 PM

All replies

  • Hi,

    I would go the one Primary site and a Secondary site, based on the fact that you have a well connected site and probabaly a reliable connection as well. And it is a much less complicated deisng and environment to manage with less SQL instances, less servers and resources used.

    I would go for 1 primary+ 1 secondary site

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    • Marked as answer by VinodR Monday, June 11, 2012 2:19 PM
    Thursday, June 7, 2012 12:52 PM
  • I too am trying to plan our SCCM 2012 design. We have an almost identical setup 2 sites, 600 + 400 users and are trying to decide between the two designs.

    I lean towards the Primary / Secondary option for the exact reasons you mentioned Jorgen (it is a much less complicated deisng and environment to manage with less SQL instances, less servers and resources used). The argument that keeps coming back at me is redundancy. eg if you lose one of the primary sites the other primary will function for all the clients in the lost site. 

    Do you have any thoughts on that?

    Thursday, June 7, 2012 1:42 PM
  • Always use the KISS principal (in like and ConfigMgr): Keep It Simple Stupid. Using a CAS violates this. Only add one if you find an explicit reason to do so.

    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by Zak Humphries Friday, June 8, 2012 11:13 AM
    Thursday, June 7, 2012 2:26 PM
  • Thanks Jason, 

    This happens to be a principal I live by and band around the office all the time, it was rather funny to see the post directly after mine mention it! The explicit reason that is being raised is the level of redundancy when using the primary / secondary model. If the primary goes down so does the whole infrastructure. With a CAS and two primary's we could redirect the clients to the other primary and keep the infrastructure intact.

    Thursday, June 7, 2012 3:44 PM
  • Thanks all of you for your inputs.

    What I understand is CAS+2Primary makes more sense if there was no SQL cluster?

    In the current scenario 1Primary + 1 Secondary is a good option as the database is on cluster. But my concern is the downtime. It would be useful to know the recovery time/process if the primary goes down?

    Thursday, June 7, 2012 9:22 PM
  • "With a CAS and two primary's we could redirect the clients to the other primary and keep the infrastructure intact."

    "What I understand is CAS+2Primary makes more sense if there was no SQL cluster?"

    No, to both of these. There is no auto-failover process for clients between primaries thus having two primaries for failover is, although technically feasible, not practical in reality.

    The main question here is exactly what is the requirement that you are trying to address? Generally, ConfigMgr functionality is not business critical and thus some down-time is accepatble per some sort of SLA. Within that SLA, normal backup and restore procedures is usually enough. But, once again, this all depends upon the exact functional requirements that exist in your enviornment. Saying that all of ConfigMgr should be HA is overly broad because there are many different roles and client centric functions -- planning to have all of these HA could be costly and completely unecessary.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    • Proposed as answer by Zak Humphries Friday, June 8, 2012 11:13 AM
    • Marked as answer by VinodR Monday, June 11, 2012 2:19 PM
    Friday, June 8, 2012 1:49 AM
  • My initial taught was having a Fallback status point on both the primary sites, pointing to each other… but this is a security risk?

    About HA, at the moment I am thinking…
    Managing clients – more specifically remote control would need to be HA (for helpdesk to have support continuity)
    This can be addressed by having multiple instances of the SMS Provider?

    We were thinking about… what if one of the sites blows off…. As long as we have proper backup it should not take long to recover (considering CM2012 recovery process… couple of hours)?

    Friday, June 8, 2012 11:29 AM
  • ConfigMgr 2012 has added all the stuff that needs to be recovered into the database now, so the recovry is extremely fast. In fact, the reinitializations required in a a hierarchy would add a lengthy delay as data is synchronized from CAS to primary. With a standalone primary - depending on the size of the data and how many site roles you have - you could be looking at a simple restore in 30 minutes or so - especially if you have an existing database sitting on a cluster.
    • Marked as answer by VinodR Monday, June 11, 2012 2:08 PM
    Friday, June 8, 2012 4:01 PM
  • FSPs are a simple messaging mechanism allowing clients to report communciation issues back to their site. You don't point them at any other site and they in no way provide any type of fallback mechanism.


    Jason | http://blog.configmgrftw.com | Twitter @JasonSandys

    Saturday, June 9, 2012 2:44 AM