Bill & Greg's Most Excellent Adventure

Planning for OCS 2007 Part II

Topology!!!

Most of the time I get questions that start out with, “How many servers Greg?” “I have this many users….”, etc. It’s important to understand how functionality plays a big part in designing and OCS deployment and how the topologies are defined in OCS will help you.

The above is a picture of standard deployment. This is for customers that are looking for a small deployment of OCS. I don’t believe this meets the demands of most customers as you are looking for a scalable, highly available service for campus. This is great for pilots or Proof of Concepts. It’s very small and can scale to approx 5K users. This design requires 2 OCS Servers. One is for remote users (users outside the firewall – students/faculty/staff), public IM users or federated users, and the other server is your home server with SQL Express for the databases.

To sum up the functionality is limited to:

• IM presence and conferencing
• External user access including federation, public IM connectivity, anonymous user participation in Web conferencing external user access to audio and video sessions

I usually look at deployment of a pool (even if relatively low user base at first) only because it provides me with a scalable architecture as I look at full deployment.

Here we have an enterprise pool but no external access. So this would provide internal only communications. No edge servers are deployed. I would look at a consolidated edge topology with HTTP Reverse proxy and 1 server for internal pool for Pilot or testing. This allows me to grow my configuration to support multiple servers without a full redesign of OCS. You can have a single Front-End server in a pool without the hardware load balancer requirement. Once you have two Front-End’s then you need the load balancers.

We also have consolidated and expanded pools based on load in the environment. I’ll explain them on the next blog.