Roger Howorth
Roger Howorth is a journalist and IT contractor working for various clients operating in financial services.
Monday 22 September 2008, 6:47 PM
Automatic fault finding
All too often a problem is easy to fix once it has been correctly diagnosed. The trouble is, it can sometimes take a disproportionate amount of time to identify the problem.
A fault with a NAS device recently highlighted this for me in no uncertain terms. Users started complaining that software that used to work quickly was now taking too long. I checked cables and server logs, but initially there was no sign of any problem. A few days later, the server logs began to fill up with reports indicating a faulty disk drive.
Perhaps it should be no surprise then that several people attending the VMworld show in Las Vegas last week said the automated diagnostic features of VMware’s AppSpeed console were the star of the show.
AppSpeed was acquired by VMware when it bought B-Hive earlier this year, and the technology is soon to be integrated into VirtualCenter. The end result will be a single suite that can monitor an application to learn about how it works. In a demonstration at VMworld we saw AppSpeed map out an application simply by watching network transactions such as requests and responses from the application’s web based user interface, and queries to its backend databases. In only a few minutes AppSpeed made a map of the servers and the connections between them, and graphed the average time taken for each transaction.
As one attendee put it, this was really exciting because it would provide a quick way to find out where the problem was if users started complaining. Without this kind of technology, it could take hours to get enough insight into the application to enable further debugging. Also, the various departments responsible for the different elements in an application have a habit of denying responsibility and pointing the finger elsewhere.
The kind of diagnostic information produced by AppSpeed makes this kind of behaviour easier to challenge, because administrators would have real data to back them up. For example, they could say, “Look, queries to your database are taking five seconds, while the rest of the transactions total 200 milliseconds.”
The irony here is that AppSpeed is not being sold as a diagnostic tool. Rather, VMware thinks people will buy it to automate the management of their application services. For example, if an application is running slowly, AppSpeed could automatically allocate more resources. In some circumstances that could be the right response. In others, the best long term solution might be a bit of software redesign.
A fault with a NAS device recently highlighted this for me in no uncertain terms. Users started complaining that software that used to work quickly was now taking too long. I checked cables and server logs, but initially there was no sign of any problem. A few days later, the server logs began to fill up with reports indicating a faulty disk drive.
Perhaps it should be no surprise then that several people attending the VMworld show in Las Vegas last week said the automated diagnostic features of VMware’s AppSpeed console were the star of the show.
AppSpeed was acquired by VMware when it bought B-Hive earlier this year, and the technology is soon to be integrated into VirtualCenter. The end result will be a single suite that can monitor an application to learn about how it works. In a demonstration at VMworld we saw AppSpeed map out an application simply by watching network transactions such as requests and responses from the application’s web based user interface, and queries to its backend databases. In only a few minutes AppSpeed made a map of the servers and the connections between them, and graphed the average time taken for each transaction.
As one attendee put it, this was really exciting because it would provide a quick way to find out where the problem was if users started complaining. Without this kind of technology, it could take hours to get enough insight into the application to enable further debugging. Also, the various departments responsible for the different elements in an application have a habit of denying responsibility and pointing the finger elsewhere.
The kind of diagnostic information produced by AppSpeed makes this kind of behaviour easier to challenge, because administrators would have real data to back them up. For example, they could say, “Look, queries to your database are taking five seconds, while the rest of the transactions total 200 milliseconds.”
The irony here is that AppSpeed is not being sold as a diagnostic tool. Rather, VMware thinks people will buy it to automate the management of their application services. For example, if an application is running slowly, AppSpeed could automatically allocate more resources. In some circumstances that could be the right response. In others, the best long term solution might be a bit of software redesign.
Wednesday 17 September 2008, 9:34 PM
A better way to migrate virtual machines
VMware has been in business for 10 years, and for most of that time it based its business on the fact that Intel and AMD did not support virtualisation. Although the chip vendors both added virtualisation support to their chips a few years ago, this was only the first step. Earlier this week Intel announced new processors that include a feature called VT FlexMigration, which will help administrators move virtual machines from one host server to another without any downtime.
The ability to move a VM from one server to another without any interruption of service is one of the crown jewels of VMware’s product line. Dubbed VMotion, this is a trick that Microsoft’s Hyper-V has yet to manage. However, even VMware’s VMotion cannot move virtual machines around willy nilly. For example, VMotion can’t be used to move a VM between an Intel based server and one fitted with AMD chips. Likewise, moving VMs between different generation Intel chips is sometimes impossible.
Intel’s VT FlexMigration is all about removing some of these limitations to VMotion.
The problem with VMotion is that while all x86 compatible chips support the same basic instruction set, chips from different vendors, and even the various chip families from the same vendor, each have a different set of additional instructions. For example, Pentium 4 chips have the SSE2 instruction set. The Merom Core architecture added SSE3, and later Intel chips added SSE4 and SSE4.2. While it’s possible to VMotion a VM from an older chip to a newer one, sending it back the other way is likely to make it crash.
This is because when software starts up it is likely to check for the presence of these extra instructions. If the instructions are then taken away because the VM has been moved to a host with older CPUs, the software will crash when it next tries to use them. It’s important to note that these additional instructions could be used by a VM operating system and by its applications. Management tools like VMware VirtualCenter can mask these instructions so they can’t be used by a VM’s operating system, but without FlexMigration there is no way to hide the instructions from a VM’s applications.
Intel’s VT FlexMigration provides a way for management consoles like VMware VirtualCenter to hide these additional instructions from a VM so that it doesn’t try to use them. In turn this means that server administrators can move their VMs around between a wider range of server hardware, which gives them more flexibility in how they allocate VMs to host servers.
The ability to move a VM from one server to another without any interruption of service is one of the crown jewels of VMware’s product line. Dubbed VMotion, this is a trick that Microsoft’s Hyper-V has yet to manage. However, even VMware’s VMotion cannot move virtual machines around willy nilly. For example, VMotion can’t be used to move a VM between an Intel based server and one fitted with AMD chips. Likewise, moving VMs between different generation Intel chips is sometimes impossible.
Intel’s VT FlexMigration is all about removing some of these limitations to VMotion.
The problem with VMotion is that while all x86 compatible chips support the same basic instruction set, chips from different vendors, and even the various chip families from the same vendor, each have a different set of additional instructions. For example, Pentium 4 chips have the SSE2 instruction set. The Merom Core architecture added SSE3, and later Intel chips added SSE4 and SSE4.2. While it’s possible to VMotion a VM from an older chip to a newer one, sending it back the other way is likely to make it crash.
This is because when software starts up it is likely to check for the presence of these extra instructions. If the instructions are then taken away because the VM has been moved to a host with older CPUs, the software will crash when it next tries to use them. It’s important to note that these additional instructions could be used by a VM operating system and by its applications. Management tools like VMware VirtualCenter can mask these instructions so they can’t be used by a VM’s operating system, but without FlexMigration there is no way to hide the instructions from a VM’s applications.
Intel’s VT FlexMigration provides a way for management consoles like VMware VirtualCenter to hide these additional instructions from a VM so that it doesn’t try to use them. In turn this means that server administrators can move their VMs around between a wider range of server hardware, which gives them more flexibility in how they allocate VMs to host servers.
Wednesday 17 September 2008, 4:36 PM
A clear view of cloud computing
Ironically for a conference in sunny Las Vegas, people here are talking about clouds. Of course, they’re not thinking about typical English rain clouds. Here at the VMworld Conference, everyone is talking about cloud computing. Essentially this is all about encapsulating workloads inside VMs and running those VMs on a server somewhere. The key is that you don’t need to think too much about which server the workload runs on.
One example given was for a CRM app, and for the demo they used the Sugar CRM virtual appliance. This has been available as a free download from the VMware site for quite some time, and the appliance didn’t need to be modified in any way to work with this demo.
The demo showed how an IT department could use VMware’s forthcoming vCenter AppSpeed console to monitor the performance of the CRM app and automatically activate a second copy whenever SLA thresholds were breached. In this demo the SLA was that no transaction should take more than four seconds to complete. As more users were added to the demo environment the time taken for each transaction gradually increased until eventually some transactions took more than four seconds. At this point the second VM was started and soon began to handle enough of the workload so that the SLA was again met. Bog standard load balancing kit was used to distribute the workload between the two VMs.
Although the main VM was hosted in a VMware datacentre, the second VM was hosted by a commercial ISP, and the deal with the ISP was that it would only charge when the VM was actually running.
To use the parlance of the day, the demo was vImpressive. IT managers may even begin to use this kind of cloud configuration as part of their disaster recovery plans.
One example given was for a CRM app, and for the demo they used the Sugar CRM virtual appliance. This has been available as a free download from the VMware site for quite some time, and the appliance didn’t need to be modified in any way to work with this demo.
The demo showed how an IT department could use VMware’s forthcoming vCenter AppSpeed console to monitor the performance of the CRM app and automatically activate a second copy whenever SLA thresholds were breached. In this demo the SLA was that no transaction should take more than four seconds to complete. As more users were added to the demo environment the time taken for each transaction gradually increased until eventually some transactions took more than four seconds. At this point the second VM was started and soon began to handle enough of the workload so that the SLA was again met. Bog standard load balancing kit was used to distribute the workload between the two VMs.
Although the main VM was hosted in a VMware datacentre, the second VM was hosted by a commercial ISP, and the deal with the ISP was that it would only charge when the VM was actually running.
To use the parlance of the day, the demo was vImpressive. IT managers may even begin to use this kind of cloud configuration as part of their disaster recovery plans.
