Server Centralisation - Look before you leap

The case for server centralisation looks stronger than ever before, but without optimising the Wide Area Network, it can be dangerous, warns Compuware's Michael Allen.

The business case for server centralisation is more complex than some technology vendors would have us believe. No one would dispute that the potential ROI is considerable, particularly if steps are also taken to rationalise and consolidate servers. The difficulty is that server centralisation makes unprecedented demands on the Wide Area Network (WAN). Companies that undertake centralisation are therefore running a very big risk of WAN failure and potentially lost business unless they are certain that these demands can be met at a reasonable cost.

Be that as it may, the centralisation pendulum is swinging once again. Over the last 15-20 years we've seen a surge in the decentralisation of computing power, but now perhaps as many as half the European companies I talk to are either undertaking or contemplating a move back towards centralisation, and more specifically server centralisation.

Server centralisation is a scenario in which previously localised computing power is centralised into data centres; users connect to servers in these remote data centres over WAN links. There are sound arguments for centralisation: it can be a nightmare to manage hundreds of servers scattered all over the country, continent or world. Centralising them into just a few locations brings considerable economies of scale, plus tighter control, more reliable backups and more effective disaster recovery.

Server centralisation may be associated with server rationalisation and consolidation, bringing not only hardware savings but also a more robust infrastructure with fewer points of failure. While noting that the biggest ROI often accrues from consolidation, we will focus here on server centralisation, the element that has the most impact on WAN performance.

To understand why server centralisation should not be undertaken lightly, let's briefly consider the reasons for the earlier trend to site servers locally. Firstly, there is the issue of control. Enterprises typically own their Local Area Network (LAN), but the WAN is provided by a telecommunications vendor. Secondly, the LAN is usually fault-tolerant, and can be made so at relatively low cost; a WAN connection, by contrast, often consists of a single link, with, in many cases, limited resilience. Thirdly, there is a vast difference in capacity: a user community can transmit hundreds of times more data across a low-cost LAN than they can across a very expensive WAN. These three factors mean that, at least in the past, it has been much easier to guarantee acceptable performance at reasonable cost on a LAN than on a WAN.

Given the advantages of LAN deployment, why are so many companies veering towards server centralisation? A major factor is that, as modern IP VPN architectures replace frame relay solutions, WAN vendors are able to build QoS (Quality of Service) parameters into the WAN, allowing particular types of traffic to be prioritised over others so as to offer a specified level of performance for critical applications. This technology shift has enhanced the IT department's confidence in its ability to obtain the required performance, even from a network that it does not own or control.

The trouble with the QoS approach is that it cannot on its own guarantee adequate performance, particularly in applications that have been designed to run on LANs. LAN-designed applications implemented on a WAN can run into two different kinds of trouble.

Firstly, they can be sensitive to the amount of bandwidth available - that is the amount of traffic they can send or receive versus the free available WAN capacity: Graphics-rich web-based applications, in particular, often need a lot of bandwidth. If insufficient bandwidth is available, these applications are still usable but their responsiveness may be impaired.

A second type of problem, and one that is often harder to solve, is latency - that is to say the length of time information takes to travel across the network. Latency impacts applications which are very "chatty" in their communication between client and server. Applications of this type can be transformed to run successfully over a high latency WAN through the use of a thin-client enabling technology like Citrix, but if there is still a noticeable delay between the user pressing a key and the corresponding character appearing on the screen, the application can become virtually unusable. When every user communicates centrally via Citrix, organisations can accurately provision WAN bandwidth capacity; however the reality is that some applications and processes will still run natively on the WAN, periodically competing for the scarce network resource.

Sometimes organisations hope that they will be able to overcome application performance problems by simply adding more bandwidth - an option that appears more attractive under the "capacity on demand" contracts currently being offered by vendors. However, throwing extra bandwidth at the problem can be an expensive solution in the long term and may not necessarily remedy performance shortfalls, particularly if they are latency-related.

For organisations contemplating server centralisation, prudence dictates that they first apply the discipline known as WAN optimisation. This entails profiling individual applications to see how each will be affected by deployment over the WAN. The infrastructure profile - the WAN links and the way they connect users to servers - is just a part of the picture. It is also necessary to analyse the application itself together with each of its end-user transaction types, and to study how users interact with these transactions. WAN optimisation also explores how the application is to be deployed in terms of the locations and numbers of clients versus data-centre activity at various times of the day.

Only with all this information to hand does it become possible to assess the WAN's ability to support its planned use. The best way to do so is to build a model of the application working on the intended infrastructure. The organisation can then validate the way forward on the basis of a complete production model. It may be possible to go ahead with the deployment; it may be necessary to enhance the infrastructure in some way first; or the application may need a certain amount of re-engineering.

WAN optimisation may not be an obviously appealing prospect for a company that is eager to realise the savings available from server centralisation. A company in this position must, however, realise that, by deploying its key applications over the WAN, it will be enabling the effectiveness of that WAN to determine its fortunes. WAN optimisation is therefore an essential insurance policy for any company embarking on server centralisation.