No significant architectural changes have been proposed by Open Text for Livelink / Content Server-based deployments in a number of years and most architectural changes made to Livelink over the years were suggested by / provided to Open Text by capable IT professionals who know how computers work, not by the developers of the software who know how the application functions. It was IT that first split the database and administrative server from the monolithic deployment that was the official standard. It was IT that first introduced load balancers and horizontal scaling, IT that introduced vertical scaling, and IT that introduced firewalls, multiple network deployments and other security improvements And it looks like it is IT that again needs to point Open Text towards a new architecture, one that speaks to today's reality of very fast CPUs, very large RAM values, and virtualized services.

The current approach of multiple LLservers, both vertically and horizontally scaled, is solid provided that the resources brought to the table are necessary, sufficient and dedicated. There are some well known 'tuning knobs' or configuration options that use more or less RAM and it is very easy to utilize all the resources you have at your disposal. The architectural recommendations remain valid and sound provided that you have the load that requires those resources, else they will sit idle and idle resources equal wasted money. The promise of virtualization is that those idle CPU cycles can go do some other useful work but the reality of virtualization is that it, like mainframe computers, require specialized knowledge to do well. It is easy to overburden the virtualization process and cause the biggest taboo of any interactive application ... inconsistent behaviour. This is the main reason virtualization is not supported by most critical interactive applications, it can easily lead to grumpy users.

That isn't a problem with virtualization, however, it is a problem with how virtualization is deployed. It is true that virtualization adds about a 10% penalty on CPU use (it is probably less that that in general but a good value for this analysis), it is also true that most Livelink transactions use very little CPU so this 10% barely has any effect on actual transaction times as seen/felt by users. But for virtualization to work all the memory the llserver process uses MUST remain within RAM and not be paged, swapped, or even migrated to another CPU module ... each LLserver could use as much as 1GB of RAM or more and moving that much data through any Input/Output system takes time that will be noticed/felt by users. The problem is that the virtualized servers are usually run too close to the limit for Livelink; while the CPU resources are idle the RAM resources must remain used, yet it is the very idleness of the server that suggests it is a good candidate for swapping, paging, and migrating. Unfortunately, dedicating RAM to idle processes is not always seen as conducive to ultra-high efficiency that virtualization promises.

It is true that not all IT shops are created equal in skills or budgets, if your organization doesn't already have a virtualization expert then it is likely using virtualization for OTCS will lead to user complaints of inconsistent behaviour ... virtualization experts are specialized and command greater compensation for their work....computers, however, are relatively cheap hence it makes most sense in many circumstances to purchase dedicated hardware rather than create or hire a virtualization expert. Don't forget that sharing server resources is not a new concept, in many ways virtualization only exists because of some operating systems' failings at standard general purpose computing, though to be fair these days servers can arrive with more RAM than any single instance of an OS can effectively use. Still, IT shops can still run multiple processes on a single server and make very effective and efficient use of idle resources without any need or use of virtualization.

There was a time, not so long ago, where even the existence of a firewall was unusual and few companies had firewall experts...that is no longer true of course. It was the case only a few short years ago that few companies really wanted to do virtualization and fewer still had virtualization experts ... but that is no longer true. While the case for virtualization of Livelink / OTCS is still tenuous, the servers of today are certainly very different than 3 years ago such that something has to give. Livelink processes, both llserver and lladmin-based, remain mostly geared to the movement of data and not, for the most part, big consumers of CPU (exceptions exist, of course, like for instance the DCS). It is increasingly difficult to be able to generate a load that can actually utilize the full resources of a typical entry-level duo-core server, let alone the quad-core, quad-processor server more commonly used. You need a lot of people to generate the load and the vast majority of OTCS installations do not have the user population necessary to do so.

Go ahead Use Virtualization It Will Work

Yes you can! Let's look at what we know, Open Text has somewhat reluctantly agreed to support virtualization, they had little choice as their customers demanded it. However it is Customer Support that extend that to a supported service, it is not an official platform and there are no official tests conducted ... this despite the fact that Open Text sales and services heavily use virtualized OTCS applications themselves. So we have ample proof that the platform works perfectly and yet Open Text still doesn't officially support it. The reason for this apparent dichotomy is performance; as anybody who has loaded up their laptop for a virtualized application can attest to, it is very easy to overburden the physical infrastructure and somewhat difficult to get a clear understanding of exactly which of the various virtualized servers is doing what at any particular time. Were Open Text to actually support virtualization they would have to train their support department to become virtualization experts of a sort, for that would end up being the root cause of many performance problems, and that comes at a significant cost. Not supporting it is a reasonable business decision, but so too is one that uses virtualization in spite of the lack of official support.

To put it simply, today's servers are too powerful for most applications to be able to utilize significant percentages of the CPU resources and OTCS-based applications are no different. Most Livelink transactions within a well run system using best practices for deployment involve the movement of data, often large volumes of data, and not significant computation of data, thus the faster the CPU the more idle the CPU. Virtualization offers a very real alternative to idle resources and ever shrinking IT budgets demand those idle resources get used where feasible.

But is it cost effective?

Well, there's a question for you. Certainly if you ask the vendors of virtualization you'll get a mighty yes, they'll focus on the idle CPU cycles you are sure to see on your dedicated servers and suggest that is wasted money ... and they are correct of course but that is not the whole story. It remains to be seen as to whether virtualization is a cost-effective and viable alternative for production services. (I take it as given that the performance problems induced by lack of resources for virtualized servers is acceptable and reasonable for non-production, test, and development servers). Let's run some quick numbers using the following assumptions:

1. While up to a 10% CPU performance penalty is considered acceptable, it must be the case that a virtualized service reacts identically to a non-virtualized service ... that is, it is NOT acceptable to have delays induced due to the virtualized service 'waking up' or coming online. The consequence of this assumption is that there shall be no more processes than there is RAM to support the sum.

2. A production class, single purpose rack-mountable server (pizza box) using single power supply, single hard drive, single network, 4GB RAM will come in at around $1,500 -- assume 3 LLservers (1GB RAM each + 1GB for OS), assume 30% utilization is max used CPU resources

3. A production-class rack-mountable mid-range server includes redundant hot-swappable power-supplies, redundant networking, and internal hot-swappable RAID for operating system, 1 quad-core CPU and 16GB RAM will come in around $3,300 --- 15 LLservers RAM & CPU dedicated and some idle CPU

4. A production-class rack-mountable mid-range server includes redundant hot-swappable power-supplies, redundant networking, and internal hot-swappable RAID for operating system, 1 quad-core CPU and 32GB of RAM will come in at around $5,000 -- 24 LL Servers for RAM, 12 CPU virtualized

5. A production-class rack-mountable high-end server has all of the mid-range production-class except with 4 quad-core CPUs and 1TB of RAM will come in at around $115,000 -- assume 750 LL servers as above (for RAM) and 65 LLservers for CPU (3x8=24x less 10% more than single duo-core CPU

6. Operating system costs are not included though they really should be for they make the case for virtualization less clear in many cases. Though virtualization works with many Operating Systems, most often it is connected with Microsoft Windows and each virtualized server requires its own server license. This is not an insignificant cost that could be avoided with use of a dedicated server of sufficient size ... but as it is not required to use MS Windows to host Livelink, these costs have been ignored.

A dedicated pizza box costs approximately  $750/llserver but you need a load of two servers to achieve that low value.

A dedicated production-class mid-range costs approximately a $206/llserver but you need a load of about 15 LL servers, @ 6 LL servers == $550/llserver (discounting any other use of the hardware)

A virtualized production-class mid-range costs approximately a $416/llserver and you can have only 1x3 LLserver, @6 LL Servers == $416/llserver ... roughly a 50% increase for the ability to access 50% of the otherwise idle resources.

A high-end server provides for $153/llserver but only can support throughput at $1769/llserver ... roughly 75% of the dedicated cost for idle processes + the privilege of accessing the excess resources ... note well however, the cost of RUNNING LLservers here is significantly greater ... this level of virtualization is only cost effective when LLservers sit mostly unused and there are other services that can be run when Livelink is idle. @6 LL servers == $1769/llserver

6 LL servers was chosen as a base comparitor because it models a relatively busy and large Livelink installation. The choice really only affects the dedicated production-class mid-range deployment and 6 was chosen as it represents approximately 30% of the resources and might be considered a tipping point from pizza-box implementation.

CONCLUSION

There appears to be some promise of a ROI for virtualization; Livelink can work cost-effectively within a virtualized service. In an environment where Livelink is rarely used or has time-based bursty activity (like archive windows), virtualizing Livelink can make a lot of sense.

Technology changes move very quickly and it is always important to re-evaluate descisions, premises, and conclusions on a regular basis. In the last few years the relative changes between OTCS/Livelink (which has in many ways stayed static) and the servers it runs on (which have seen continual change and improvement) is striking. Open Text's official architecture for Content Server-based deployments is out of step with today's high-end computing environment. With the introduction of very large scale RAM servers, virtualization can be cost-effective for many OTCS production services provided that those services are only used infrequently.

Very large scale RAM servers can host far more applications than they can actually run concurrently but the raw CPU cost is far greater. Without great care at planning and implementation virtualization runs the risk of both poor performance and excessive expense. If virtualization is to be used at all then this fundamental equation must be understood, RAM is cheap but CPU is relatively expensive, virtualization only becomes cost-effective when the virtualized applicaitons are rarely used or use very few CPU cycles when active. Even a sustained CPU usage of as little as 10% of the time can easily swamp the costs over a smaller, dedicated server.

It seems clear that virtualization is potentiallly more cost effective than the dedicated pizza box approach, but this analysis lacks any expenses directly related to virtualization itself, like for instance IT training for hypervisor, any cost for the virtualization platform, and licensing costs for Operating Systems. For large scale departments, these cost can usually be absorbed but for smaller shops they could have a significant impact on overall costs. A detailed cost analysis should be conducted before virtualization is chosen.

There does seem to be a role for virtualization of Livelink for production services, it is clearly not a panacea and it is ripe for mistakes that could have a negative impact on both your users and your bottom line, but given the right circumstances it can be a very cost-effective method of using Open Text Content Server-based applications, particularly infrequently used ones.