I get asked in every engagement, “…can we virtualize OCS R2?” This is a great question. Using virtualization has clear benefits - and also clear drawbacks. On the benefit side, using virtualization offers more efficient hardware utilization; on the drawback side, applications that are time sensitive or are CPU sensitive may suffer degraded performance. OCS 2007 R2 falls into both categories. OCS has some roles that lend themselves to virtualization, but OCS also has server roles that Microsoft does not support in a VM environment (presumably because of the performance degradation). Specifically, any server role that handles media (read A/V) is not supported in a virtualized environment.
Now that we know what is supported, what is practical and not practical? We know that some organizations will weigh support issues against the advantages of an unsupported deployment and decide the benefits outweigh the risks. The documents I just pointed you to are definitive, yet the scale numbers in the second document are for large environments. What about the smaller enterprises with only a few hundred users? How about a company with less than 5000 users (the implied limit for a Standard Edition server)? What about the ancillary OCS server roles (archiving, monitoring, directors)? What follows is purely my opinion and experience. If you are concerned with being in a supported status (from the Microsoft CSS viewpoint), stop here and follow the guidance in the references to the letter.
Let’s look at the VM host environment and then see what we can do. When you plan your VM host server, make sure it has PLENTY of CPU cycles - read many fast cores. RAM is an important item on your VM host server. Do not scrimp on RAM. The guest VM must have at LEAST the minimum number of CPU cores and amount RAM as that server role is required to have on a physical server. If the recommended minimum is 2 CPU cores and 4GB RAM, then that is the minimum for the guest VM instance also. As to drive speed on the VM host, resist using SATA and go with 15k RPM SCSI. And do not try to cram too many guests VM’s onto one host. As always, leave enough RAM and CPU for the host OS to function properly.
Plan your VM host server network support carefully. Good resources for this critical task when using Microsoft's Hyper-V are here and here. I highly recommend using at least two physical Network Interface Cards - one for the host server and one for the guests. Resist the urge to get fancy and do NOT use wireless. The combination of VM, OCS, and wireless creates performance issues. Another item of note is that you can adjust the performance of both the VM host and the VM guest to maximize performance. Face it, GUI is nice, bells and whistles are cool, but do you really need that stuff on your servers? You will never miss these fancy features…they are just fluff. In a virtualized environment, where cost reduction through hardware consolidation is generally a main goal, performance is king.This is what I do for every VM host and guest I touch - the performance gain is noticeable:
Now that we have looked at the VM host and guest environment we can consider which OCS roles are candidates for virtualization, and in my experience, what is practical. The following table outlines the OCS 2007 R2 servers roles and their respective VM possibilities:
|Consolidated FE (SE)
|Consolidated FE (EE)
|Yes for IM&P only
|No for anything A/V, desktop share, or Live Meeting
|As the user numbers climb, performance will drop off. IE; You will see some screen-draw issues as the user count climbs.
|Group Chat Archiving
|For the numbers we quoted above, it works
|For the numbers we quoted above, it works
|For the number we quoted above, it works
|This will depend on your LM work load, how many remote users are expanding DL’s etc.
|SQL in VM is supported; but not SQL cluster. However, I have done SQL cluster on two separate VM hosts. Do not do VMotion or equivalent on the cluster.
While you are at this, you may want to take a look at SQL databases. Microsoft says you need a separate SQL instance for each database. This is for performance reasons. However, I know that one SQL server can host the backend OCS database, the Group Chat Archive Database, the archiving database, and the monitoring database and do just fine. Again, this is a numbers game. As the number of users climbs, the load on the SQL will climb also and eventually you will see a drop in performance. Specifically, our second reference document says that the SQL backend is the limiting factor to how many users can be attached to a virtualized enterprise pool. But, our target user numbers are only 1/8th of that limit. Therefore, I feel confident in stating that one SQL server (with the proper resources) will support your OCS needs.
Let’s take look at this table from a deployment perspective. As an example, say you have 1000 users. Your usage projections are for moderate use of Live Meeting, about 100 users maximum for CWA, and about 200 or so of your users are remote, and federation/PIC will be used by 30% of your users (just picking numbers here for this example). In this case, I would think that you could explore the possibilities of using VM for everything but your SE and your Edge. A single SQL server, deployed in VM, will be able to host all of your OCS databases. Should you deploy Enterprise Voice, you would place your mediation server on physical as well.
Before you move ahead with a project such as this, remember this is just my opinion, based on my experience, and that virtualizing OCS 2007 R2 roles that are not supported as virtualized by Microsoft places you in an unsupported configuration.