Virtualisation. When is it Right for your Business?

It always strikes me as strange that the IT industry which you would think was packed full of rational intelligent people is so susceptible to marketing and fashion. Amongst others we have had the dotcom boom, WAP, any first version of a Microsoft product, and my all time favourite, the death of the router due to the invention of the switch. How could we have been so stupid?

As a former boss of my used to say, “Nobody ever got the sack for buying IBM”. And herein lies the root of the problem. Although many IT professionals claim to be innovative and cutting edge, in reality, their main priority is job preservation and so the “safety in numbers” principle kicks in. They invest in the same technology as everyone else, usually whatever has been “bigged up” in the IT press.

The most obvious technology currently benefitting from the sheep mentality is Cloud Computing but as I’ve blogged on this before, I thought I’d highlight another area doing well from IT fashion, namely Virtualisation.

Virtualisation is useful and does have some real benefits and indeed I use it myself. However I find it annoying that it is promoted almost as a silver bullet solution as if virtualisation is guaranteed to bring lower costs, better scalability and performance as well as more uptime irrespective of the application and its uses. All of these points can be true but more and more I’m coming across cases of companies virtualising large parts of their IT infrastructure without proper analysis of whether or not they will get any real benefits. But enough of the ranting, here are a few tips for what to consider before you start a virtualisation project.

Performance: Something often overlooked is that virtualisation reduces the performance level of your hardware as there is always some overhead from the virtualisation layer. This is not necessarily a problem if you plan to run a few applications that have low load but still require isolation from each other, in fact this is where virtualisation excels. It may become a problem if your applications have some significant usage peaks as the equivalent performance on a virtualised environment will be less than on a physical system. It’s impossible to quantify exactly what this impact will be so it is necessary to analyse your own applications. A couple of examples of testing can be found at WebPerformance Inc and also Microsoft. Be aware as well that the choice of hardware for the virtualisation platform can also have a significant impact for example AMD’s Rapid Virtualization Indexing and Intel’s Extended Page Tables are specifically design to optimise virtualisation.

Cost: The main cost saving from virtualisation comes from requiring less hardware and the reduction in the associated power and data centre space. It is possible to get some reasonably powerful virtualisation software for free if certain advanced functionality is not required. What must not be overlooked is the cost of additional licensing assuming of course you are not using open source software. For example, if you run four virtual Windows Servers on a single VMWare ESXi machine you may need to pay for 4 operating system licences as could be the case for other paid software such as databases and anti-malware packages. It may be cheaper to try to get your applications to run on a single system. You may also find that free Hypervisors are not sufficient for your needs in which case there are licensing costs here as well.

If you want to use some of the more interesting virtualisation features such as dynamically moving virtual machines between physical servers it is necessary to have some kind of storage area network (SAN). If your application has significant disk I/O requirements it is better to use fibre channel rather than iSCSI. Such an option is significantly more expensive than direct attached storage. Again, this is not necessarily a problem but it is important to be sure that you are getting a decent improvement in your service for the money you invest.

Scalability: A big plus point of virtualisation is the way you can dynamically add resources to a virtual machine (VM). Firstly you can let a busy VM take unused resources from a shared pool. If this is not sufficient you can dynamically move other virtual machines to different physical hardware, assuming you have made the relevant investment in a SAN etc, freeing system power for your newly busy application. It sounds great in theory and in some cases it probably is. Once again however, the true benefits are subject to the characteristics of your applications. It would be nice if each application had its peak usage on distinct days at times that were mutually exclusive. It my experience, it is more likely that the opposite is true and so you virtual infrastructure may need to be able to cope with all of your applications experiencing peak load at the same time. Once more, this is not necessarily a problem if you decided that the convenience of being able to easily move you applications between hardware platforms is worth the investment in the infrastructure.

An unwanted side affect of offering easy hardware upgrade is the tendency for deficiencies in applications to be ignored. If more processing power is easily available it is tempting to allocate it to a poorly performing application rather than optimising the code or the configuration.

Availability: Virtualisation can help improve the availability of your applications. With the right configuration when using a SAN if a physical server fails all the virtual machines that had been running on it can be automatically moved to other hardware. The same is true if you need to take down a system for maintenance, e.g. to add new memory. It sounds great but again it is important to assess if your investment is giving you value for money. Do your applications need to be available 24x7x365? Does your SLA allow for a couple of hours down time in order for you to recover a faulty system? How often do you expect your hardware to actually fail? My own experience is that if you run a server less than 5 years old in an environment with proper temperature control and consistent power, with the exception of disk drives which should be protected by RAID, failure is rare. Also consider that SANs may fail too which could leave you with a huge single point of failure.

To conclude virtualisation can add real value to your business but before implementing it is necessary to do a proper analysis to see if what you gain adds true value for money.

HTML 5 – Security Challenges

No post recently due to the extreme lack of anything interesting to post about. Finally yesterday something turned up via the unlikely source of a Linkedin group. Linkedin Groups are usually a hotbed of inanity or self promotionists but the OWASP French Chapter bucked the trend by pointing me in the direction of this HTML 5 article on eWEEK. Much in the news recently due to discussions about the H.264 video format, new features in HTML 5 present some interesting challenges for security. Client side storage is one area highlighted in the article. HTML 5 allows for three types of client side storage which are:

Session Storage similar to cookies but with much more information.

Local Storage, similar to session storage but available to all browser windows and persistent after a window is closed.

Database Storage: Structured data saved in a real local SQL database

The most obvious security risk that springs to mind is data leakage left after an application is closed but there are also other possibilities such as cross domain request forgery and perhaps even local SQL injection!

The article also highlights that the scope for cross domain communication by JavaScript is increased with HTML 5 which allows for more powerful applications but also opens up abuse possibilities.

A little extra research seems to suggest that the above features can be implemented securely but as ever it depends on the developer’s ability to understand the technology and to be aware of how to code in a secure manner.

How to Hack Web Applications

I’ve been evaluating Google’s Web Application and Defences tutorial over the past day or so. Based around a fictitious Web application called Jarlsberg, it consists of a series of exercises that allow the student to exploit the numerous security holes on the site. The vulnerabilities include Cross Site Scripting (XSS) in its many forms, Cross Site Request Forgery (XSRF), Path Traversal, Denial of Service (DoS), Privilege Escalation, AJAX vulnerabilities and remote code execution. The main absentees are SQL injection and buffer over flows.

Although a basic understanding of HTML and Javascript is necessary to understand the content, you don’t need to be an experienced web developer to benefit from the tutorial. Its main plus point is seeing exploits in action to demonstrate the damage they can cause. In the past I’ve sometimes had problems explaining quite why something like an XSRF vulnerability is a risk to a web site.