locked
OCS capacity planning and best practises from Microsoft RRS feed

  • Question

  •  

    Very interesting to read the following documents.

     

    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.

    I'm not sure if I have a clear understanding about the statements above but it does bring up some questions: 

     

    Is Microsoft suggesting that in case you implement a consolidated topology you will not need to use a shared SAN environment (because all the OCS components are running on dedicated servers as well as the file servers)?

     

    The configuration of SQL Servers that uses Directly Attached Storage without clustering could indeed represent a single point of failure but this is not something specific for an enterprise expanded roll out, is it?

     

    In this case we would rather choose for the consolidated deployment because of the reasons mentioned above. 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? I believe that, with the currently available hardware (quad core processors), the amount of supported users will be higher in a consolidated scenario?

     

    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?

    Tuesday, October 21, 2008 12:16 PM

All replies

  • I think one of the main reasons for moving to an expanded topology is not neccesarily the totoal number of users in the environment, but HOW they use the product.  If audio/video communications are used lightly compared to simple IM conversations then there is a stronger argument for a consolidated approach.  But if many users are collectively running lots of video conferencing and EV or PC-to-PC audio calls then an expanded topology allows for more hardware to be dedidcated top each server component.
    Tuesday, October 21, 2008 1:05 PM
    Moderator
  •  

    Hi,

     

    the hardware used for the table showed above is described in the planning guide. The hardware specs described in that document is applicable for both the expanded as the consolidated topologies. As you said hardware has evolved since then and might support more concurrent users but I would consider that as a bonus :-) Using the figures from the planning guide will put you on the safe side, assuming ofcourse that your user profile matches that of what is described in the planning guide.

     

    Also I don't think the MSIT Showcase suggests that Consolidated Topologies is preferred because there is no SAN requirement. In fact I don't see a difference from a storage perspective for both the consolidated and expanded topology. It's typically the SQL Server that drives the SAN requirement for shared storage so you may want to think about your availability requirements.

     

    My personal preference goes towards the consolidated topology because of it's simplicity, and with simplicity think about installation guides, operational procedures, support etc... I am desiging a similar architecture at the moment that consists of 4 x consolidated enterprise pools. We will start with a single pool and will grow according to the "needs".

     

    Sincerely,

    Tonino Bruno

    Tuesday, October 21, 2008 6:41 PM