locked
Role Collocation Restrictions in an Expanded Enterprise Pool? RRS feed

  • Question

  • I realize the intention of the Expanded pool (versus the consolidated) is to break out the roles onto separate physical servers, but I am wonder if it's possible to collocate one or more primary OCS roles on one physical server in an Expanded Pool.  Can you deploy the roles in any combination or is it limited to one role per one physical server?

     

    It appears the only drawback to a Consolidated Pool is that you cannot just add (grow) a specific role to a separate host if future demand dictates, so I am wondering why we wouldn't just install an expanded pool with all the primary OCS roles on the Front End server(s) to begin with, and then grow out the specific roles as needed (instead of Consolidated which has the limitation that all servers in the pool must have all primary roles installed).

     

    Thanks,

    Friday, September 26, 2008 9:08 PM

Answers

  • While I still have some unanswered questions, I summarized my findings on the issue for the benefit of others on my blog:
     
        > http://insideocs.com/2008/10/02/differences-between-ocs-consolidated-and-enterprise-pools






    Thursday, October 2, 2008 8:21 PM

All replies

  • OCS 2007 Ent Edition in EXPANDED topology is RARELY ever necessary.  Can you provide use #'s and why you are going this route?

     

    A consolidated pool is much easier to manage and extend as needed.... just add another server to the pool.

     

    Saturday, September 27, 2008 12:36 AM
  • Choosing between Consolidated and Expanded topologies in the Enterprise version is as simple as installing just the components you want on a server, so yes you can pick and choose what roles go where.  For example you could install the Front End and Web Conferencing services on one box and out the A/V Conferencing role on another physical box.  The same can be done with the Edge server; you are not forced to pick one or the other.

    Saturday, September 27, 2008 12:45 AM
    Moderator
  • Are you sure about that Jeff?  I seem to remember being explicitly prompted during the Pool creation whether it was going to be Consolidate or Expanded.  I found a reference to that selection on Page 48 of the OCS Planning Guide.

     

    "Enterprise Edition. The Deployment Tool prompts you for configuration type (Consolidated or Expanded). The Create Enterprise Pool Wizard prompts you for pool name, the domain in which it resides, and the names of various servers and services that it will require. The wizard then copies the appropriate files".

     

    On the next page it goes on to say:  "If you are deploying Enterprise Edition, Expanded Configuration, you must install the Web Conferencing Server and A/V Conferencing Server on separate computers from those hosting the Front End Servers".  I am fairly certain I have seen an Expanded configuration with Web Conferencing on the Front End though...weird.

     

    Also, if it as simple as whatever roles you choose to install on the server(s), why would there be the concept of Consolidated vs Enterprise in the first-place?  Maybe so that the scalability numbers are more easily understood?

     

    Thanks,
    Curtis

    Saturday, September 27, 2008 1:32 AM
  • I think the 'must' statement is supportability-based.  I'd have to go back through the install wizard again to see if it actually limits any of those configurations, but I have also seen Front-End and Web Conf on a box with A/V Conf on a separate box.  But the more I think about that might have been an Edge deployment I am thinking of.  I was planning on running another install this weekend to test a few things, I'll try a couple expanded scenarios to see what works and what doesn't.

    Saturday, September 27, 2008 1:43 AM
    Moderator
  •  Curtis Johnstone wrote:

    Are you sure about that Jeff?  I seem to remember being explicitly prompted during the Pool creation whether it was going to be Consolidate or Expanded.  I found a reference to that selection on Page 48 of the OCS Planning Guide.

     

    "Enterprise Edition. The Deployment Tool prompts you for configuration type (Consolidated or Expanded). The Create Enterprise Pool Wizard prompts you for pool name, the domain in which it resides, and the names of various servers and services that it will require. The wizard then copies the appropriate files".

     

    On the next page it goes on to say:  "If you are deploying Enterprise Edition, Expanded Configuration, you must install the Web Conferencing Server and A/V Conferencing Server on separate computers from those hosting the Front End Servers".  I am fairly certain I have seen an Expanded configuration with Web Conferencing on the Front End though...weird.

     

    Also, if it as simple as whatever roles you choose to install on the server(s), why would there be the concept of Consolidated vs Enterprise in the first-place?  Maybe so that the scalability numbers are more easily understood?

     

    Thanks,
    Curtis

     

    Curtis, you are correct, and bless you for reading the planning guide Smile

     

    The typical EE Expanded pool consists of roughly 7 servers right off the bat.  You can move certain roles around, but it is a pain and more importantly it is a risk.

     

    You should run the OCS Planning Tool and see a few different supported options.  If you are looking at less than 20k users, then keep it simple, stick with consolidated.  If later for some reason you want to deal with expanded pools, then reduce the consolidated equipment, build out the expanded, move the users over.

     

    -My 2 cents.

    Saturday, September 27, 2008 2:01 AM
  • I found something interesting on Page 3 of the Microsoft Office Communications Server 2007 Technical Reference:

     

    "In an Enterprise Edition expanded configuration, the A/V Conferencing Server and Web Conferencing Server server roles are distributed and run on separate servers".  Maybe it is as simple as you can mix-and-match all your role combinations EXCEPT that the A/V and Web Conferencing roles must be on different physical servers in an Expanded deployment.

     

    This is the thing - I am dealing with a relatively small deployment (~3500 users). The common wisdom is "keep it simple, use a consolidated pool", which is my recommended approach.  My only vague hestitation is that I could see a higher demand for Web Conferencing in the future.  With a consolidated pool we can add an additional server WITH ALL PRIMARY roles, but the question remains: why not just choose an expanded pool right off the bat and collocate all pimary roles for 'ease of deployment and management' and then when we have the need, deploy a Web Conferencing server in the future??

     

    Why limit myself with a consolidated pool?  What advantages does it gives me if I can just collocate all primary roles on physical servers in an expanded pool?

    Saturday, September 27, 2008 1:22 PM
  • OK, I validated the steps in my lab to refresh my memory and I stand by my original statement that the deployment guide instructions are from a supportibility and recommendation standpoint.  The installation wizard does not prevent the collocation of any OCS components when choosing the Expanded configuration. In fact you can even install SQL 2005 on the local server and use that for the OCS database, which is clearly not supported, but is possible.  One of the main reasons MS recommends to split the Front End services away from Web Components is the usage of Hardware Load Balancers.  Hosting the Web Components on those servers isn't protected under the same load-balancing features that the client communications are.  Some custom configuration could be used to replicate the flat Address Book files as well as configuring the internal pool and Web Farm FQDNs to get the expected result.

     

    To answer your last question I believe the two installation paths are just for convience and simplicity when running the Enterprise Edition installation.  If you know how to customize all the setting (like using LCSCMD) then you could use different approaches.

     

    Saturday, September 27, 2008 6:02 PM
    Moderator
  • Interesting. Thanks for validating that Jeff; I'll be doing similar work in my lab this week and I can confirm certain configurations.  I agree, those Enterprise definition are probably to simplify deploying the most supported configurations; although I wish there was a clear matrix with recommended role allocation in the Expanded model.  All the documentation seems to skirt around the issue.

    Saturday, September 27, 2008 9:58 PM
  • While I still have some unanswered questions, I summarized my findings on the issue for the benefit of others on my blog:
     
        > http://insideocs.com/2008/10/02/differences-between-ocs-consolidated-and-enterprise-pools






    Thursday, October 2, 2008 8:21 PM
  • Interesting discussion. To add some more information on sizing I would like to share the following:

     

    In the planning guide and the web cast called OCS Capacity Planning Microsoft Webcast, 18 March 2008-05-07 I found the following table:

     

    Standard Edition Server

    1 SE Server

    5.000 users

    Enterprise Pool Consolidated Config

    4 FE Servers (alle rollen op 1 server)

    1 SQL Server

    30.000 users

    Enterprise Pool Expanded Config

    Mid Range SQL Server

    4 FE Servers

    2 Web Conferencing Servers

    2 A/V Conferencing Servers

    2 Web Components (IIS )Servers

    1 SQL Server

    50.000 users

    Enterprise Pool Expanded Config

    High Performance SQL Server

    6 FE Servers

    4 Web Conferencing Servers

    4 A/V Conferencing Servers

    2 Web Components (IIS) Servers

    1 SQL Server

    125.000 users

     

     

     

     

     

     

     

     

     

     

     

     



    We are implementing an OCS environment that potentially could grow up to more then 130.000 users. Based on the information from the webcast and the planning guide we would have to choose for an Expanded configuration. Reading the whitepaper "How Microsoft IT Deployed Office Communications Server 2007 and Office Communicator 2007" I found some interesting conclusions:

     

    After deploying Office Communications Server 2007, Microsoft IT continues to evaluate the infrastructure and processes for improvement opportunities. For example, the initial deployment used an expanded topology in the Redmond location and consolidated topologies in the other data centers. Microsoft IT later transitioned to a consolidated topology in the Redmond location as well for better supportability and manageability. Microsoft IT designed the server capacity to accommodate an increase of up to 20 percent in users each year with no performance degradation. For added capacity, it is straightforward to add additional servers as needed to the base consolidated topologies.

     

    There were several reasons for transitioning the Redmond data center to use a consolidated topology. As already mentioned, Microsoft IT determined that the shared SAN environment did not provide the necessary I/O throughput, which resulted in a configuration of SQL servers that used DAS without clustering. This represents a single point of failure for each server pool and an unacceptable risk for Microsoft IT. To provide full system redundancy, Microsoft IT decided to use multiple server pools at each site, in addition to spreading out the user load across multiple geographically dispersed data centers.

    Another reason reasons for transitioning the Redmond data center to use a consolidated topology is simplification. For Microsoft IT, it is more straightforward to implement, administer, and operate a server topology that is homogenous across all data centers. In analyzing the most common reasons for unavailability, Microsoft IT noticed that external dependencies such as the underlying network, hardware load balancers, Active Directory, and so on were responsible. By reducing the complexity of the environment, Microsoft IT reduces the potential for unavailability caused by external dependencies.

    In this case we would rather choose for the consolidated deployment because of the reasons mentioned about. Considering the amount of supported users in a consolidated topology (in the table above) you will have to implement at least 4 OCS pools to support 120.000 users.  

    • Are the numbers in the table above correct?
    • On what hardware has Microsoft tested this? Will it have any influence on the maximum amount of users supported?

    There is another reason for implementing a consolidated version: that is easy migration to future realeases of OCS. 

     

    In our case we only need to support 10.000 users in the first phase of the project. The customer would like to standardize on 64 bit servers. Keeping in mind that OCSR2 is only supported on 64 bit and that we going to migrate the users in the next stage we were are already working on a migration scenario. Our OCS 32bit infrastructure will not grow above 30.000 users before the migration. One of the OCS Solution specialists from Microsoft was advising me to go for a consolidated configuration in this case.

     

    I'm wondering why you would choose for an expanded toplogy after knowing the facts above? Or am I forgetting/ missing some points?

     

    /Thomas

    Friday, October 10, 2008 12:07 PM