- What Are Business Critical Applications?
- Why Virtualize Business Critical Applications?
- Risks, Challenges, and Common Objections of Virtualizing Business Critical Applications
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Risks, Challenges, and Common Objections of Virtualizing Business Critical Applications
Now that we’ve reviewed the many benefits that organizations can realize by virtualizing their business critical applications, let’s review some of the risks, challenges, and common objections that organizations will face along the way. By understanding both the benefits and the risks, you will be able to understand the full scope of virtualizing these applications and be able to build a better business case. You’ll also be more likely to succeed if you go into this with your eyes wide open.
The preceding section might have made it seem as though virtualizing your organization’s business critical applications was all rainbows and unicorns and nothing could go wrong, right? The truth is that almost any application can be virtualized on the vSphere platform, but without the proper planning up front and understanding of the risks, it is easy to fail. This section outlines the risks and common objections to virtualizing business critical applications and provides ways to combat these objections with facts, benefits, and counterpoints.
Performance
The biggest concerns that application owners and businesses are likely to express about virtualizing their critical applications are around performance. These are the most common objections you are likely to hear, in one form or another:
- My application will perform more slowly if it is virtualized on vSphere.
- If my application has to share resources with other virtual machines running on the same host, it will perform poorly.
- My application requires too many resources (such as CPU and memory) to virtualize.
It is true that if an application is not properly sized, or a virtual infrastructure is not properly designed, applications can experience decreased performance when they are virtualized. Similarly, if an organization carries over poor practices from the physical world (such as oversizing systems with more CPU and memory resources than they actually need) into the virtual world, performance of the organization’s applications can suffer. Without careful planning you could easily fall into the pitfalls of the three listed items.
The best way to avoid performance problems is to treat a business critical application differently from all other applications you might have virtualized thus far. Just because you were successful in virtualizing a front-end web server does not mean you’ll have the same success virtualizing the back-end SQL database using the same process. Business critical applications have different requirements than lower-tier applications, so they typically require more planning before virtualizing them. A proper capacity-planning exercise should be performed before the application is virtualized so that you understand exactly what the resource demands will be and you can size the virtual machines, and the environment, properly.
For example, the host on which the business critical applications are running should not have high resource overcommitment or, ideally, any at all. It might be a common practice to overcommit resources on ESXi hosts in your organization to increase consolidation ratios, but that practice can hurt the performance of business critical applications (and might not even be supported by some applications). High consolidation ratios are not typically a goal of virtualizing business critical applications (though it can be an ancillary benefit), so don’t try to cram in too many virtual machines per ESXi host.
To address the most common objections, let’s go through them one at a time. First, application owners might think that their application will perform more slowly if it is virtualized on vSphere. In fact, VMware has performed numerous performance tests that show that major business critical applications like Microsoft Exchange Server, SQL Server, and others perform as well when virtualized as they do when they are on physical servers. In some cases, the applications actually perform better when virtualized than if they are physical, due to the limits of scalability within the application itself. By deploying multiple copies of the same application on the same host, it can often scale better than if a single copy was installed directly onto the physical server. On VMware’s Virtualize Business Critical Applications blog (http://blogs.vmware.com/apps), you can find these performance studies and other details that can be great resources for organizations looking to be successful with virtualization initiatives.
Next, a common concern is that performance will suffer if a business critical application needs to share resources with other less important virtual machines on the same ESXi host. This can happen without the proper planning up front or if the goals of the virtualization effort are misaligned, but with a proper design this should be an unlikely scenario. The vSphere platform provides numerous technologies that can be implemented to help control access to resources so that this does not occur. For example, vSphere offers the capability to provide resource reservations for particular VMs, where they reserve a specific amount of resources ahead of other virtual machines. This guarantees access to those resources and can be especially useful if other workloads run on the same host, or if a host experiences a failure and more workloads are running on an ESXi host than originally intended. In addition, features such as Storage I/O Control and Network I/O Control can help control the “noisy neighbor” scenario in which another virtual machine is consuming too many disk or network resources. These tools are especially important as organizations move their most critical applications into their own private clouds.
While there have been major improvements to the vSphere platform over the years, there have also been significant advances in the world of storage and networking. These advances make virtualizing business critical applications easier than it was in the past. Storage performance has vastly improved in recent years, with storage arrays that offer automatic tiering systems to move highly accessed data to the fastest disks available. The introduction of solid-state drives into enterprise-class arrays has also greatly improved storage performance, making it possible to meet the performance needs of even the most demanding applications. On the networking side, 10Gb Ethernet has become more prevalent in today’s data centers, which greatly increases the bandwidth that applications have available to them.
Finally, some application owners think that their applications simply have system requirements that are too high to be satisfied by the vSphere platform. As the vSphere platform has improved over the years, so too has the scalability of the platform itself. As of vSphere 5.1, a virtual machine can now be configured with 64 vCPUs and 1TB of RAM, and can achieve up to one million I/O operations per second. This should satisfy the needs of even the largest business critical applications. Often the maximum recommended system configuration for a business critical application is far below the capabilities of modern server hardware, so without virtualization there would be large amounts of wasted resources.
In Table 1.1, you can see what approximately 95% of applications actually require in terms of resources, and what the vSphere platform is capable of supporting. VMware gathered these 95% statistics from the thousands of customers who have uploaded data to their Capacity Planner tool (which we’ll discuss in more detail in the next chapter). It is clear that nearly any application can be virtualized on the vSphere platform.
Table 1.1. Resource Scalability of the vSphere Platform
|
|
95% of Apps Require |
ESX 1 |
ESX 2 |
VMware Inf. 3.0/3.5 |
VMware vSphere 4 |
VMware vSphere 5.1 |
|
CPU |
1 to 2 CPUs |
1 VCPUs |
2 VCPUs |
4 VCPUs |
8 VCPUs |
64 VCPUs |
|
Memory |
<4GB at peak |
2GB per VM |
3.6GB per VM |
16/64GB per VM |
256GB per VM |
1,000GB per VM |
|
Network |
<2.4Mbps |
<.5Gbps |
.9Gbps |
9Gbps |
30Gbps |
>36Gbps |
|
IOPS |
<10,000 |
<5,000 |
7,000 |
100,000 |
300,000 |
1,000,000 per VM |
Supportability
Another common objection that organizations might raise about virtualizing business critical applications is the supportability of these applications on a virtual platform. Once again, this is actually a valid risk in that if it is not implemented properly, the software vendor might very well not support the application. Now that virtualization has become much more prevalent, many software vendors have clarified their support statements for applications running in a virtual environment.
It can be easy to ignore vendor-specific support statements and simply deploy the application on vSphere as if it were being deployed on a physical server. By not paying close attention to the vendor’s support requirements, you run the risk of virtualizing the business critical application in a fashion that is not supported by the vendor.
Microsoft, for instance, has specific support statements for applications like Exchange Server and SQL Server that dictate the requirements for running them in a virtual environment. For example, only specific versions of SQL Server are supported in a virtual environment, and if you plan on clustering your SQL servers, only specific versions of Windows are supported as well. Similarly, Microsoft supports only a two-to-one overallocation of physical CPUs to virtual CPUs (that is, assigning only a maximum of double the number of virtual CPUs than there are physical CPUs in the server) for Exchange Server. Many organizations are used to much higher consolidation ratios and might inadvertently run Exchange in an unsupported fashion.
There are other virtualization-specific support requirements that might be overlooked that can lead to an unsupported configuration. Software vendors might not support the use of virtual machine snapshots for their applications, yet snapshots are a common practice in many organizations. Snapshots are typically not supported on applications where databases are in use (such as Exchange Server or SQL Server), because there can be issues when reverting those virtual machines to previous versions of the snapshot. In that scenario not only could your organization be in an unsupported configuration, but you could actually cause problems for the applications you are trying to protect.
By paying careful attention to vendor support statements for running their application in a virtual machine, you can avoid many of these risks. Most businesses cannot survive extended outages without their critical applications running, so maintaining proper support is incredibly important. Always follow the individual vendor’s specific guidance around how to run their application properly in a virtual machine.
Management
Application teams and administrators of business critical applications are used to having a physical server that they own and can operate as they see fit. If they need to access the console of the server, they can use remote tools like HP Integrated Lights Out (iLO) (or similar) or network-based keyboard, video, and mouse (KVM) systems. There is typically nothing sitting in between the administrators who manage the server/application and the application itself.
When an application is virtualized, however, the vSphere platform now sits in between the administrator and the server or application. Although the administrator can use common remote desktop tools to access the server, he loses the ability to do things like access the console, walk up to the server and insert a CD/DVD, or press the power button to reset the server if it is hung. For these reasons application owners might resist the move to a virtual infrastructure for fear of losing “control” of the application.
The loss of the ability to manage the application is a valid concern for application owners, and one that vSphere and business critical application architects need to take into consideration. Luckily, VMware vCenter includes a granular role-based access control system that is fully integrated with Microsoft Active Directory. Administrators can grant granular access rights for specific virtual machines to the application owners, restoring their ability to manage the application the way they did in the past.
Not providing this access is a great way to alienate the application owner and make other application owners more hesitant to move their applications into the virtual infrastructure. A thorough understanding of the application owner’s requirements should uncover this need and it should be included in your design.
Reliability
Right behind performance, questioning the reliability of the vSphere platform is typically one of the most common objections from application owners when virtualizing their applications. After all, the business depends on these applications, so reliability is important to make sure that they remain online and operational.
Just as with performance, if your environment is not properly designed or implemented, there is a very real risk of reduced reliability when virtualizing these applications. For example, if your environment relies heavily on overcommitting memory on your ESXi hosts, the reliability of your application can suffer during peak utilization periods. The same can be said if the vSphere environment as a whole is not properly maintained, secured, or monitored. After all, the virtualized application is only as good as the platform on which it runs.
The vSphere platform has proven year after year that it can provide the reliability that business critical applications require. The ESXi hypervisor was introduced without a general-purpose operating system like the previous version, ESX, reducing the attack surface of the platform and also reducing the frequency with which it needs to be patched. The ESXi hypervisor also utilizes hardware drivers that are optimized for virtualization rather than generic vendor-supplied drivers that other hypervisors rely on. By limiting the hardware drivers to only those that are tested and optimized, the likelihood of a system failure is reduced.
Despite the smaller ESXi hypervisor, patches are still required. VMware has a tool called vCenter Update Manager that can be used to streamline the installation of patches on ESXi hosts. vCenter Update Manager can scan hosts and determine whether they are compliant with the latest patches and, if not, indicate which are missing and facilitate the installation of these patches. Maintaining a regular patching schedule for ESXi hosts is important to make sure your organization remains compliant with the latest security and functionality updates.
When patches are required or hardware maintenance must be performed, features like VMware vMotion enable the live migration of workloads between ESXi hosts without any downtime to the application. This can increase the uptime of these applications while still enabling administrators to maintain the servers and keep them up to date. Should there be an issue with an ESXi host patch, the system supports the ability to roll back to the previous state to quickly and easily restore functionality.
Finally, the maturity of the ESX/ESXi platform shows that it is trusted and reliable. VMware has won numerous awards over the years from many in the technology industry, including prestigious titles such as Best Virtualization Solution (Cloud Computing World Forum, 2012) and Best Virtualization Platform (InfoWorld, 2012). These awards show that the industry trusts the vSphere platform with the most critical virtualized workloads.
Customers have trusted the ESX/ESXi platform for over 10 years, and VMware has continued to improve the features, functionality, and reliability of the platform. In fact, VMware states that 100% of the Fortune 100 and 98% of the Fortune 500 use VMware products. That is a testament to the reliability of VMware’s products and the trust that even the largest organizations place in them.
Security Risks
Another very common objection against virtualizing business critical applications involves concerns about security. If an application is critical to the business, security of that application is crucial, so it is easy to see why it can be a common objection to virtualization.
Back in the early days of the ESX platform, virtualization was new and many folks did not understand how the basic concepts actually worked. VMware worked hard to educate their customers by discussing concepts like “encapsulation” and “isolation” of virtual machines. Though VMware does not need to describe these somewhat basic concepts anymore, it can be helpful to revisit them to reinforce why vSphere is a secure platform for business critical applications. Virtual machines are completely encapsulated into a small set of files rather than the thousands of individual files that typically make up an operating system and application installation. These files are not typically shared between virtual machines, so the data within the files remains secure without risk of another virtual machine accessing them (with the one exception being certain virtualized Windows clustering configurations in which a disk is shared between cluster nodes). Similarly, a virtual machine is isolated from all other virtual machines so that the operation of one does not affect the other. An application or operating system crash in one virtual machine has no impact on another due to this isolation.
Because virtual machines are made up of a small set of files, controlling access to these files becomes very important. By default, ESXi does not allow remote connections using tools like secure shell (SSH), and that configuration should not be changed unless you are troubleshooting a problem. ESXi can also be integrated with Active Directory for authentication, enabling you to closely audit who is connecting to hosts for auditing and compliance. By adhering to these good security practices, you can help mitigate the risk of the console of an ESXi host becoming compromised.
If a single virtual machine is compromised via a security vulnerability (in the operating system, for example), other virtual machines are not automatically exposed. That means that if a hacker gains access to a single virtual machine on an ESXi host, the individual does not automatically have access to all virtual machines running on the host. The isolation of virtual machines inherently provides security benefits similar to if the servers were physical.
VMware continuously improves the ESXi platform and releases security patches to address any vulnerabilities that are discovered. Due to the smaller size of the ESXi code base, there are far fewer security updates than with other platforms like Microsoft Windows or even previous versions of VMware ESX. If administrators remain vigilant about patching ESXi hosts with security updates when they are released, they can greatly reduce the risk of an entire host becoming compromised.
Taking a step beyond the basic concepts, VMware also offers a full suite of security products to help augment or improve the security of virtualized environments. The vCloud Networking and Security suite of products (formally released as individual products under the vShield suite) can provide a robust set of security features, including (but not limited to) these:
- Perimeter security services including firewall, Network Address Translation (NAT) services, and Virtual Private Networking (VPN) connectivity
- Application-level firewall that maintains security as virtual machines migrate between hosts
- Virtual appliance that allows for the offloading of antivirus operations from the virtual machine to the hypervisor
- VXLAN, a technology that, very simply stated, creates a logical layer-2 network that can span physical boundaries for a very scalable virtualized networking solution
VMware also provides vCenter Configuration Manager, an application that monitors and reports on configuration changes and compliance. By constantly monitoring and reporting on any change that happens both in the virtual infrastructure and within the virtual machines, administrators can maintain compliance as well as be able to pinpoint when changes (authorized or otherwise) were made in their environments. Change control and compliance with regulatory mandates are crucial for many business critical applications, and vCenter Configuration Manager can help put application owners at ease with the knowledge that their applications are protected and compliant.
In addition to the features found in vSphere and other VMware tools, standard security practices that are used in physical servers can be carried forward to virtual machines as well. This includes things like role-based access control for access to virtual machines, security software run inside the virtual machine, or other common requirements that application owners might have to secure their servers.
By combining the native security features of vSphere with the security, compliance, and auditing features of vCloud Networking and Security, application owners should feel confident that their applications will be protected and secure when virtualized.
Complacency
It’s the classic “if it ain’t broke, don’t fix it” argument: Why should an application owner who currently has his applications on physical servers make the decision to move that application to the vSphere platform? This is a common objection and one that can derail a project if not properly addressed.
Application owners are used to running their applications on physical servers and might not understand the benefits of moving to a virtual infrastructure. They also might not be experiencing problems with their application, especially if it is running on modern hardware and is well managed. Additionally, application owners can have concerns about the effort involved in moving their application to a virtual platform and might not feel that the benefits are worth the risk or time investment.
These and other reasons are commonly why application owners become complacent and unmotivated to move their applications to the virtual infrastructure. Typically, the best way to combat complacency is to understand the issues and pain points that the application owners are currently dealing with. Are they using complicated clustering solutions to maintain high availability? Can they provide high availability at all for their application? Do they have a disaster recovery strategy for their application?
By understanding the issues application owners face on a daily basis, you can better frame the conversation and showcase the benefits of virtualizing their application. If an application has no native capability to provide high availability, for example, showing that vSphere provides this capability to all virtual machines might make them rethink their decision to remain physical.
Even if application owners are happy with the current application performance and availability features, highlighting the features of vSphere that are not easily possible on physical servers can help tip the scales in favor of virtualization. For example, showing that vSphere has the capability to add resources on the fly without downtime or deploy new servers quickly to meet demand can help application owners see the benefits. Including the application in a disaster recovery solution that already protects many other applications and can easily be tested without incurring downtime is likely to be another key selling point. Also, the capability to easily test patches and updates and then roll back quickly if there is a problem is another major benefit that is not easily possible with physical servers.
Finally, private clouds can be disruptive forces in organizations, so it is important to explain all the benefits they provide. If an organization is moving toward a private cloud model, complacent application owners might find themselves on the outside looking in if they do not adapt to this new paradigm.