You cannot afford for business critical applications in your datacenter to go down just to upgrade them. With that in mind, let’s look at which events might provide a good opportunity to virtualize applications in your datacenter. Below are some questions to ask when considering virtualization. If you answer “yes” to any of the questions, it might be time to virtualize that app.
Category Archives: Exchange
The following best practices for virtualizing Exchange can provide useful guidance for virtual CPU, virtual memory, networking and storage setup.
Email has become one of the most critical applications in an organization’s IT infrastructure. Organizations increasingly rely on messaging tools for individual and organizational effectiveness. As a result, messaging administrators face a constant challenge as they continually seek to manage the conflicting demands of availability, agility, and cost.
Microsoft Exchange is the most widely used email system in the world. It’s operational and performance characteristics are well understood, and best practices for design, deployment, and operations are readily accessible. Exchange continues to evolve through enhanced features and functionality, and previous limitations have been addressed with each successive new version.
With its release of Exchange Server 2010, Microsoft has added many features that improve messaging performance, reliability, and scalability. These provide a major step forward. However, Exchange Server 2010 is still subject to many of the shortcomings inherent in most applications running directly on physical hardware, such as hardware platform dependence, under-utilization of server computing resources, lack of flexibility to respond to changing workloads, and heavy costs associated with maintaining disaster recovery, test, and development environments. The architectural improvements in Exchange Server 2010 do not fully address these limitations.
The ideal platform for Exchange would adapt easily to changing workloads, provide flexibility to accommodate changing demands on an organization’s IT infrastructure, remain reliable and resilient despite system outages, and improve both staff and infrastructure hardware effectiveness. A new operational platform based on vSphere can accomplish these goals.
Here is an updated support statement for running Exchange on vSphere.
Customer Case in Point
Like many companies that choose VMware virtualization technology, Raymond James Financial began with a server consolidation project that achieved impressive results. By the completion of the initiative, the Florida-based diversified holding company had reduced its web server capital costs by 90 percent. Raymond James started by virtualizing Microsoft Exchange, one of the company’s most critical and high profile applications. Through virtualization, Raymond James has been able to better meet its business needs. “Right now, around 60 percent of our servers are virtualized,” says Sue Werner, Systems Engineer at Raymond James. “But our goal is to achieve 87 to 90 percent virtualization.” This will include not only the company’s Microsoft Exchange environment, but also other business-critical systems such as its SQL databases. “Implementing our new Microsoft Exchange environment has further validated the benefits of VMware,” Werner concludes. “It has enabled us to make significant progress toward our virtualization goal.
This post is part of the 7-part series Seven Top Benefits of Virtualizing Business Critical Applications.
VMware supports running Monster VMs. Application performance is based on four infrastructure measures. Today, virtual machines on vSphere 5 can scale to 32 vCPUs, 1TB of memory, 36GB/s network, and 1 million storage IOPS.
These advances in performance are charted in Figure 13. And what they mean for you is that resource-intensive applications perform very well on vSphere. In fact, we have measured the resource requirements of more than 700,000 production applications running on x86 servers. vSphere is able to support more than 99 percent of those applications (Source: VMware Capacity Planner™ assessments).
In the below figure you can see that vSphere 5 Is ready for the most demanding applications.
vSphere is also improving its performance per operation in core areas, such as vMotion. For example, vSphere 5 decreased vMotion duration by 44 percent from vSphere 4.1. This benefits application owners by providing vMotion without downtime or delay.
See below Duration of vMotion on vSphere 4.1 and vSphere 5, for Single and Multiple Exhange Server Deployments (Source: VMware vSphere vMotion Architecture, Performance and Best Practices in VMware vSphere 5.)
This post is part of the 7-part series Seven Top Benefits of Virtualizing Business Critical Applications.
Ensuring availability of your applications is difficult. Each application component must be made highly available, and operations teams often struggle with a proliferation of different clustering and availability options. The Web tier is fairly simple to protect using network load balancing, and the application tier can be clustered, but databases are typically the most difficult tier to protect. Databases can be protected using Microsoft Clustering, database mirroring, or high-end options such as Oracle RAC.
VMware provides a range of capabilities that can extend availability to 100 percent of applications including databases, without the complexity or cost of clustering. These capabilities are:
- vMotion – Move running virtual machines from one physical server to another with no impact to end users. vMotion keeps your IT environment up and running, giving you unprecedented flexibility and availability to meet the increasing demands of your business and end users.
- High Availability – Provides automated application restart in the event of host failure or OS failure within the virtual machine. It is automatically available for any application running on vSphere. VMware HA is simple and does not require OS- or app-level clustering. It is also very cost effective because it doesn’t rely on dedicated standby servers, and in many cases allows the use of lower-cost OS and application licenses.
- App-Aware High Availability – Monitors the application and if it goes down, it can be restarted. App-Aware HA will run the failover only when the application doesn’t come back up again. The underlying technology depends on the VMware HA to automatically initiate the failover. App-Aware HA is an API that allows users to plug in one of two currently available third-party App-Aware products from Symantec or Neverfail.
- Fault Tolerance – Protects any application against host failure with continuous availability, without data loss or downtime. VMware FT creates virtual machine “pairs” that run in lock step—essentially mirroring the execution state of a virtual machine. To the external world they appear as one instance (one IP address, one application)—but they are fully redundant instances.
The siloed example of availability methods shown in Figure 11 requires expensive licenses, dedicated standby infrastructure, and highly skilled staff to configure and manage. The alternative to this expensive approach is a standardized approach using vSphere technology, though some companies choose to implement both appspecific and VMware solutions running in tandem.
To prepare for availability issues affecting an entire datacenter, VMware vCenter™ Site Recovery Manager (SRM) enables datacenter teams to build, manage, and execute reliable disaster recovery plans for all applications, including business-critical apps. By taking full advantage of the encapsulation and isolation of virtual machines, SRM enables simplified automation of disaster recovery. SRM helps meet recovery time objectives, reduces costs traditionally associated with business continuance plans, and achieves low-risk and predictable results for recovery of a virtual environment.
The figure below lists some of the top business and technical reasons to virtualize business-critical applications.
Note: Consolidation rates are averages based on “VMware Customer Readiness Reviews.” Licensing savings are cited in the Licensing section of the below whitepaper.
vSphere delivers the performance required to run business-critical applications in large-scale environments. vSphere 5 provides 16 times (source Figure 14 in BCA Whitepaper) the performance of VMware Infrastructure 3 while keeping virtualization overhead at a limited 2 to 5 percent. The fact is that the virtualization overhead or “tax” is often greatly exaggerated and many application owners are managing applications that have already been virtualized by the server and virtualization teams, and the applications owners don’t even know it.
Performance is a major factor in business-critical applications. Virtual machines perform the same as their physical equivalents, as witnessed in production by the app owners. The following set of graphs illustrates this performance across several applications.
Virtualized Oracle databases perform the same as native databases from the application owner’s perspective (source: Virtualizing Performance-Critical Database Applications in VMware vSphere).
In the figure below, Confio, a third-party company unaffiliated with VMware, compared virtual and physical servers in a side-by-side test, finding the performance would be the same to the DBA (Source: A Comparison of Oracle Performance on Physical and VMware Servers, 2012. Written by Confio, www.confio.com.)
In the figure below, Virtualized SQL databases perform the same as native databases from the application owner’s perspective (Source: Performance and Scalability of Microsoft SQL on vSphere.).
In the figure below, Virtualized SAP performs the same as native equivalents from the application owner’s perspective (Source: Virtualized SAP Performance with VMware vSphere 4.).
In the figure below, Virtualized Java performs the same as native equivalents from the application owner’s perspective (Source: Performance of Enterprise Java Applications on VMware vSphere 4.1 and SpringSource tc Server.).
In the figure below, Virtualized Hadoop performs the same as native equivalents from the application owner’s perspective (Source: Source: “A Benchmarking Case Study of Virtualized Hadoop Performance on VMware vSphere® 5”, 2012.)
Thousands of VMware customers have virtualized their Exchange, Oracle Databases, Oracle eBusiness Suite, SQL, SAP, and Java applications. These applications are often considered the six business-critical applications (BCAs). There are also business-critical apps that are industry specific (such as for retail, telecom, and healthcare industries) as well as newly emerging business-critical apps (such as Hadoop). According to a recent VMware survey (Source: VMware customer survey, June 2011), 75 percent of VMware customers report they virtualize at least one business-critical application in their production environment.
The figure below identifies many large companies that are currently virtualizing their business-critical applications with VMware. You will find additional virtualization success stories at www.vmware.com/customers.
Audience: This whitepaper provides solution and technical product information is intended for Architects, Engineers, Administrators, DBAs, App-owners and Business staff
Purpose of this whitepaper: This whitepaper documents the challenges with virtualizing business critical apps and provides evidence for overcoming these challenges and to virtualize these apps.
Executive Summary: Starting with vSphere 4, and more recently using vSphere 5, customers are virtualizing business-critical applications at an accelerated pace. 75-percent of VMware customers report they virtualize at least one business-critical application in their production environment. Application infrastructure administrators and CIOs see that the value of virtualization extends far beyond basic consolidation. Applications run better virtualized, with faster time to market and improved Quality of Service (QoS).
by Jeff Szastak
Enhancing Exchange 2010’s Security Profile
In this post we will discuss using vShield to bolster the protection profile of Exchange 2010. We will start off with a brief discussion on vShield, and then move on to discussing the Exchange 2010 architecture, and then finally how we implemented vShield around Exchange 2010.
vShield 5.0 Overview
The VMware vShield product family is the foundation for trusted cloud infrastructures. vShield enables adaptive and cost-effective security services within a single management framework. vShield is a suite of products comprised of vShield Edge, vShield App, vShield Data Security, and vShield Endpoint. For purposes of this post, we will focus on two of the four products, vShield Edge and vShield App.
vShield Edge provides network edge security and gateway services to isolate VMs in a port group, vDS port group, or Cisco Nexus 1000v. vShield Edge is a stateful inspection firewall that can provide NAT, DHCP, IPsec Site to Site VPN VPN, and Web load balancing services for the virtual data center.
vShield App is a layer 2 / layer 3 virtualization aware, hypervisor based firewall that protects applications in the virtual datacenter from network based attacks. A major benefit to vShield App is configuring access control polices are based on logical and physical constructs versus purely physical constructs that a traditional firewall leverages. An example of this would be the ability to create rules based on a vApp (logical) versus IP Address (physical).
Exchange 2010 Architecture Overview
We built Exchange 2010 within the construct of a vApp. A vApp allows you to group VMs together and perform management functions against those VMs, such as power on, power off operations. vApp provide the ability to create ‘nested’ vApps. We leveraged this ability to create a multi-tier vApp for Exchange.
We created a root vApp labeled Exchange and then nested three different containers, based on Exchange 2010 roles (CAS, HUB, Mailbox). We then explicitly configured boot order within the CAS, HUB, and Mailbox vApps and at the Exchange Level.
We separated out the individual Exchange 2010 roles into individual VMs for the CAS, HUB, and mailbox roles. We used Exchange 2010 SP1 installed on Windows Server 2008 R2 Standard / Enterprise. We also configured the SAMESUBNETDELAY setting to 2000ms since we are using HA, DRS, and vMotion with DAG. More information on running DAG on the vSphere platform, see the whitepaper Using VMware HA, DRS, and vMotion with Exchange 2010 DAGs. The VMware software used in this configuration was vSphere 5.0 and vShield 5.0.
For networking we used the vSphere Distributed Switch with one Port Group for production traffic and a second Port Group dedicated to DAG replication traffic. In addition, we limited the number of ports in the DAG replication network to 2 so we would not have to worry about addition VMs being plugged into this Port Group. In the screen shot below, you can see the HUB01 and MBX01 VMs both using the Production dvPortGroup and the second vNIC on MBX01 using the ExchangeDAG dvPortgroup.
Once we got Exchange up and running we installed vShield. vShield installs default open so we were able to leverage the traffic flow reports inside vShield to assist us in creating the rules around Exchange 2010.
Building the Rules
As stated earlier, vShield installs default open which allows us to leverage the traffic flows within vApp to better understand communication activity amongst systems. We decided to gradually lock down Exchange 2010 by first configuring VM to VM rules, and then implementing port based rules based on the TechNet post detailing ports used by Exchange 2010: http://technet.microsoft.com/en-us/library/bb331973.aspx.
We built our rule sets using logical constructs within vCenter Server. For example, we built a rule stating the Mailbox vApp is allowed to communicate with the HUB vApp. By creating the rule against these logical constructs, any VMs placed into these containers will inherit the rules of that container.
As we built the rules we monitored traffic flows between Exchange 2010 systems, which was key in validating we correctly configured the rule sets and also identified other key traffic activities that were not documented in the aforementioned Ports Used by Exchange 2010 article. An example of this was UDP 139 from the Exchange vApp to our Domain Controller vApp.
Configure an external syslog server for vShield. As you build your rules, enable logging of the rule in order to validate enforcement of the rule. Start with general rules, like VM to VM rules and if necessary move down to port specific rules. Both of these will provide better protection, be sure to implement the appropiate level for your enviornment. Be aware that as the rules become more granular you must be more diligent to ensure all ports required by the application and OS are available. When you have validated your configuration is correct, change the default allow rule to deny.