Free ESG report : Seamless data management with Avere FXT

It is not uncommon for the IT department to find itself some way down the food chain. You know how it is: the business guys decide to implement their shiny new applications and the IT department somehow has to find the platforms to run it on.

The first step is to define the requirements for the application – both those that aren't directly related to performance such as disk space and, more importantly, those that are.

It is essential to do the latter quantitatively because that is the only way to measure performance against the service level agreement (SLA) that you will have agreed with the business.

Raised voices

If performance is unmeasurable, one of two things will happen: either you will over-specify the server, storage and network equipment for fear of under-performance; or you will be reallocating resources to the application belonging to the department that shouts loudest at the expense of all the others.

Once the requirements are defined, you can consider the implementation and configuration of the installation.

Let's start with storage: medium and large organisations are likely to use storage area networks (SANs) to present shared storage as virtual volumes to servers.

It is common to have different flavours of disk in the same SAN, for example Fibre Channel-connected high-speed disk for high priority items, and perhaps less expensive SATA for applications requiring lower performance.

Peaceful co-existence

Don't just give the new application the fastest disk you have available. Consider the requirement, as you may well find that cheaper, slower hardware is perfectly adequate.

Next comes the server platform. If you are dedicating server hardware to the new application that's fine: it will have no contention for the hardware and you don't have to consider tuning too much.

If, on the other hand, parts of the application will share hardware then give close consideration to how items co-exist on top of the operating system.

Remember, there's no law that says the threads of application A should have the same priority as those from application B. It is easy to forget that underlying performance can be tuned on a per-process basis to ensure optimum performance.

You can also restrict resource usage: by default most database packages will, for example, eat all the RAM available to them, but you can then manually configure a limit to retain sanity.

In the middle, of course, is the network – both the SAN connecting the storage to the servers and the LAN connecting the servers to each other and to the clients.

Know your infrastructure and you can ensure proper performance

It is so easy to simply plug a server into a few Gigabit ports, LACP bond them and call it a day, but this is a fast route to a performance hit. Know your infrastructure and you can ensure proper performance.

The obvious starting point is the net throughput of the network devices. Say, for instance, you have invested in a 16-port 10Gig switch blade: this doesn't necessarily mean that it will achieve full-on, sustained wire-speed throughput. Even some relatively top-end devices max out at a net 40Gbps, for instance.

Piority traffic

And bear in mind that today's infrastructure devices are increasingly application-aware. Traffic can be prioritised based on defined classes of service, with the switches and routers able to tag packets and ensure appropriate delivery.

The final component in the installation takes us back to measurability. The most essential layer that sits across the entire installation is an SLA monitoring tool.

You have agreed to provide the business with a given level of performance for all applications, and it is up to you to demonstrate that you conform with the requirements for all applications, not just the latest one that was dropped on you.

So install and configure your management application, and make sure it generates weekly management reports that chart the application's performance in the context of the SLA. ®

5 ways to prepare your advertising infrastructure for disaster