by Neal Mueller

COLLABORATE is a big event for Oracle Database and Oracle Application users. You can find just what you need with help from one of our three participating users groups, those being:

• IOUG: for database users
• OAUG: for e-business suite users 
• QUEST: for JDEdwards and Peoplesoft users

VMware customers are virtualizing all of Oracle's products, so we were a popular booth at Collaborate. VMware also had eight sessions at Collaborate:

• Virtualization Boot Camp: Demystifying Oracle Database Virtualization Part I of III
• Virtualization Boot Camp: Demystifying Oracle Database Virtualization Part II of III
• Virtualization Boot Camp: Demystifying Oracle Database Virtualization Part III of III
• Oracle on VMware Expert Panel
• Oracle on VMware: Expert Panel
• Virtualizing Oracle Business Critical Applications
• Virtualization Boot Camp: Virtualizing Oracle 11gR2 RAC on VMware vSphere: Best Practices
• Demystifying MySQL for Oracle DBAs and Developers

Here is booth picture of VMware's Oracle expert Kannan Mani working with the Harvard University DBA Team. The DBA explained his architecture to Kannan on the piece of paper on the table and then took note of what Kannan said, putting it into his iPhone.

VMware had a booth and signage at the show.

Next year, Collaborate 13 will be held in Denver. Denver is home to VMware's Oracle-Master Don Sullivan and VMware's Oracle-Double-Ace George Trujillo.

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.  

Closing Remarks

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.

We have received some requests from SAP Basis colleagues on how to go about designing SAP systems on VMware. Now that vSphere 5 can support up to 32-way virtual machines it is possible to fit  larger  SAP systems into one single virtual machine (VM) so  should we go with  2-tier versus 3-tier? Here are some guidelines.

Sizing

 First let’s cover sizing as this will impact the final VM architecture. SAP sizing is conducted in the SAP metric “SAPS” (http://www.sap.com/solutions/benchmark/measuring/index.epx ).   All SAP on VMware sizing is officially conducted by the server vendor SAP practice. VMware partners with the server vendors so we can help but we are not ultimately responsible for sizing. The background behind this is as follows:

• SAP has officially deferred sizing on physical and virtual to their hardware partners (since 1993 approx). SAP’s position is documented on SAP Marketplace https://service.sap.com/sizing   (logon credentials are required). As of April 2012:
  • Under “Sizing Responsibilities” it says “The hardware vendors are responsible for providing hardware that will meet the customer’s throughput and response time requirements”
  • Under “Virtualization - Some Statements about Sizing and Virtualization” it says “For the right virtualization strategy you should get in touch with your hardware vendor”.

• The SAPS rating per vCPU only depends on the processor model. The hardware vendor has the most up-to-date SAPS ratings of their servers so they can size most accurately. For example the SAPS rating of a virtual machine with 4 vCPUs will change if moved from one server model to another.

 The hardware vendor can conduct the sizing and provide the number of ESX servers required to fulfill the business requirements. Once this is available VMware can work with the hardware vendor and customer to jointly fine-tune the VM size and layout.

We recommend starting conservatively for business critical workloads. An initial sizing option could be to allocate number of vCPUs = number of cores on the ESX server – we would do this even for hyper-threaded systems.

To achieve higher utilizations, the total amount of vCPUs running on an ESX server can be higher than the total amount of physical cores. The ESX hypervisor is designed to optimally schedule the workload amongst the available CPUs. Additionally, it can be configured to give more important virtual machines a higher priority. Hardware supported features like hyper-threading will increase the CPU scheduling efficiency. No general statement can be made regarding the optimal CPU over-commitment ratio, as this always depends on individual utilization patterns of the workload.

 2-tier versus 3-tier

The architecture of a single SAP system consists of: a database instance; application server instances; Central Instance (CI - includes locking and message services and other SAP processes). In newer SAP releases the Central Instance is replaced with Central Services (CS - locking and messaging only) and the Primary Application Server instance (PAS). 2-tier refers to all these components running in the same guest-OS/ VM. 3-tier refers to the situation where, for a single SAP system these components are spread out onto at least two VMs.  Each of the components can be deployed into a separate VM. Advantage of 2-tier systems is that there are less VMs to manage and there is no network latency between the SAP components.

3-tier has the following advantages:

• For flexibility, better resource management and better overall high availability i.e. if everything is in one VM and the VM/guest OS / ESX server goes down you lose every component. If workload is dynamic e.g. month-end requires more app tier resource you can add/remove application server VMs as required so 3-tier is better for this (same principles as physical).

• You can set up a ESX cluster in a “n+1” setup i.e. if one ESX server goes down all the VMs can restart on remaining ESX servers and continue to perform as before (auto-restart scripts required for the instances or enter  “Autostart=1” in the instance startup profile). 3-tier setups allows you to spread the VMs for a single SAP system across multiple ESX servers so if one ESX server goes down then it minimizes the impact to a single system (off course if DB/CS virtual machine is offline the SAP system is down but hopefully only one component needs to be restarted).

• 3-tier setups allow you to size VMs better so they align with NUMA architecture.
  • DB VM – this needs to scale-up vertically so if sizing requires a large DB you can put it in a large VM. Ideally you want the VM to fit inside a NUMA node but if it can’t no big deal vSphere 5 can support a wide VM that crosses a NUMA node (and you can configure virtual NUMA to take advantage of any NUMA optimizations inside the guest OS).
  • Application server VMs can scale-out horizontally – size these in smaller blocks  such that they fit inside of a NUMA node.
  • For more background, see http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf, pages 39-40.

• ABAP+JAVA stack:   SAP has a policy whereby they prefer to separate ABAP + JAVA out - we can comply with this in virtual by putting the stacks in separate VMs.  Check out http://wiki.sdn.sap.com/wiki/display/SI/SAPs+Dual+Stack+Strategy – this recommends single stack except when it is a hard requirement in the SAP product e.g. Solution Manager.  Advantage of this is you can manage performance tuning separately in each VM, for example ABAP does not support large pages, but Java does (see SAP note 1681501 - Configure a SAP JVM to use large pages on Linux). However if you need to run a dual stack, you can in a single VM, just size the VM large enough to handle memory + CPU of both stacks.

In the physical world some customers run batch jobs on the CI which is on the same physical server as the DB instance. The advantage - the jobs run quicker as there is no network hop between the app and the DB.  In virtual a similar setup would require a large VM with the DB and app server/CI instance installed in the same guest-OS. The only downside is if there are long periods where the batch jobs are not run – we end up with an oversized VM with low utilization. Some datacenters may have a security requirement to separate the DB in its own guest-OS in which case your options are limited. VMware supports hot-add vCPU for the latest Linux and Windows versions but hot-remove is not supported.  One solution, if the batch job is designed to run in parallel threads (many SAP ABAP batch jobs have this ability), increase the degree of parallelism and distribute the batch workload across more app server VMs to decrease the overall runtime of the job (this assumes you have available CPU) – the latter can be provisioned and de-provisioned based on the cyclical nature of the workload.

Regards

Matthias Schlarb (SAP Technical Alliance Engineer)

Michael Hesse (SAP Technical Alliance Manager)

Vas Mitra (SAP Solutions Architect)

by Avinash Nayak

The good folks in Oracle’s marketing department deserve a raise for their efforts around promoting the latest release of the company’s virtualization solution, Oracle VM (OVM) 3. They certainly are aiming high, claiming OVM 3 is four times more scalable than VMware, four times cheaper to deploy than VMware, and is architected for efficiency while VMware is prone to inefficiencies. Not bad for a product that did not even exist until 2009 and is only on its second release (why the second release is called OVM 3, I don’t know). Unfortunately for Oracle Marketing, there’s a problem, namely – the FACTS. The facts show that VMware vSphere 5 delivers much higher scalability, greater value and unmatched performance compared to OVM.

Let’s take a closer look at Oracle’s claims and compare them with the facts:

Is OVM 3 four times more scalable than VMware? Switch the order of the products and it's perfect.

Oracle bases this claim on the fact that OVM 3 supports 128 virtual CPUs (vCPUs) per VM, where vSphere 5 VMs support 32 vCPUs.

Wait. Did someone change the definition of scalability when we weren’t looking? Since when is the scalability of a virtualization platform defined only by the number of VM vCPUs supported?

Surely, a better measure of the scalability of a platform is the number of VMs doing useful work that the platform can support (and manage) on a host or a cluster. It’s not the only measure, but one that’s far more insightful for showing scalability than just comparing vCPUs. Oracle’s documentation shows that OVM 3 is only able to run up to 128 VMs per host, compared to 512 for vSphere 5 (four times more than OVM 3, what a coincidence). So, it looks like Oracle got the “four times” part right. They just got the products mixed up. Simple mistake.

In addition, VMware’s testing has shown that a 32 vCPU guests can deliver 92-97% of native performance. Oracle has yet to provide any evidence that a 128 vCPU guest can scale linearly on OVM3.0.

Is VMware four times more expensive than OVM 3? NO. Maybe Oracle meant vSphere has four times more functionality than OVM 3.

Oracle makes this claim solely based on virtualization software costs. But virtualization software cost is only one component of the total cost of deploying an application. The other components are the hardware costs (server, storage and networking), guest OS licensing costs, power and datacenter space costs. You need to take into account all of these when calculating the total costs for deploying an application.

Thanks to the advanced features provided by vSphere, customers are able to realize significant savings from reduction in hardware necessary to deploy an application environment relative to OVM.  Through the use of multiple advanced memory management features  (transparent page sharing, ballooning, memory compression, and hypervisor swapping), vSphere is able to achieve much greater VM density per host than OVM, meaning you need fewer hosts to deploy the same number of VMs. Independent tests have shown that vSphere 5 consistently delivers higher VM density compared to competing platforms, such as Xen based OVM.

Let’s take a simple example and compare the TOTAL cost of deploying 100 Linux VMs on vSphere 5 Enterprise Plus (VMware’s highest vSphere edition) vs. OVM3. We assume a conservative 25% density advantage for vSphere over OVM. This means that if we assume we deploy 12 VMs per host for OVM, we can deploy 15 VMs per host for vSphere 5.

We see that even the highest edition of vSphere 5 is less than 6% more expensive than OVM when you take into account TOTAL cost. So it appears that Oracle’s cost claims are exaggerated by 400/6 = 66.67 times.

So what do you get for a premium of less than 6%? Here’s a subset of the features found in vSphere 5 that are absent from OVM:

But Oracle should be intimately familiar with how a “free” solution does not necessarily provide better value. After all, isn’t MYSQL a free product (like OVM) and you only pay for support. Does it deliver the same capabilities as Oracle’s Enterprise Database solutions? I wonder what Oracle has to say about that.

Is OVM 3 more efficient than vSphere? We’d like to see the evidence.

The basis for this claim is a four year old Oracle VM Benchmark Performance Report from The Tolly Group done using OVM 2 (the first version of the product). The performance tests compare OVM 2 (note – Not OVM 3) to physical servers, not to vSphere. Oracle has not provided any evidence to support the claim that OVM 3 is more efficient or has a performance advantage over vSphere.

Like other Xen-based hypervisors, Oracle VM requires guest operating systems with extensive Xen paravirtualization modifications to get acceptable performance. Instead, vSphere uses unmodified guest OSs together with optimized device drivers and full support for virtualization hardware assist features in modern processors to deliver unmatched performance. This approach allows customers to use standard operating systems that are fully supported by ISVs. And with a disk footprint of only 144MB, the vSphere hypervisor represents a far smaller attack surface. An OVM 3 server’s disk footprint is swollen to 588MB (four times larger than vSphere) by the Linux management operating system installed in the Dom0 partition.

Also, without advanced features like Network and Storage I/O Controls, OVM is unable to guarantee service levels for business critical applications (for example, large databases.) vSphere is the only platform that delivers capabilities to ensure that your most important applications have access to the resources they need to meet required SLAs.

Grading the claims made by Oracle with regards to OVM 3:

Marketing: PASS; Delivering on the Marketing Claims: FAIL

So it looks like VMware will not be shutting shop just yet. Despite what Oracle says, vSphere 5 is well ahead of OVM 3 in terms of performance, features and value.

by Barnaby Jeans

In a previous article, we talked about some best practices for virtualizing Microsoft SQL Server on vSphere and to follow it up I want to take some time to answer a common question - what is the licensing impact when virtualizing SQL server.

I have just completed a 3 week, 5 city, tour across Canada talking to companies about virtualizing Business Critical Applications (SQL Server, Exchange, SharePoint, Oracle, SAP) on vSphere.  One of the most frequent questions has to do with how to license SQL Server and understanding the Microsoft licensing cost implications as they consolidate their physical environments to virtual.  During those conversation they quickly come to appreciate that in many cases their existing licenses cover them for more virtual machines than they had planned to deploy.

As Microsoft offers a number of different licensing options for its software, you should consult with your Microsoft representative to obtain the most accurate licensing information for your situation.

Below I've provided a summary based on the available documentation to help you understand your options when it comes to running SQL Server on vSphere.

SQL Server 2008 R2

From the SQL Server 2008R2 Licensing Quick Reference Guide

Licensing for Virtualization Under the Per Processor Model
The number of operating system environments (OSEs) in which you may run instances of SQL Server 2008 R2 under the Per Processor model depends upon the edition you license and whether or not you license all of the physical processors with a Per Processor License.

Licensing All Physical Processors If you license all of the physical processors on the server (one license per physical processor), you may run unlimited instances of the SQL Server software in the following number of OSEs (either physical or virtual):

Edition	# of OSEs in Which You May Run SQL Server
SQL Server 2008 R2 Datacenter	Unlimited
SQL Server 2008 R2 Enterprise	Up to 4 per license

 

SQL Server 2012

With the release of SQL 2012 Microsoft has changed the licensing and has retired the Datacenter Edition as well as moved to Core-Based licensing.

From the SQL Server 2012 Licensing Quick Reference Guide (March 2012)

SQL Server 2012 offers expanded virtualization rights, options and benefits to provide greater flexibility for customers deploying in virtual environments. When deploying SQL Server 2012 software in virtualized environments, customers have the choice to license either individual virtual machines (VMs) as needed, or to license for maximum virtualization in highly virtualized, private cloud, or dynamic environments. Maximum virtualization can be achieved by licensing the entire physical server with Enterprise Edition core licenses and covering those licenses with Software Assurance.

In looking at the information above, you’ll note that SQL Server 2008 R2 Enterprise Edition already provides you with the ability to run 4 virtual machines with an existing license, and in most cases, customers are able to consolidate multiple physical SQL Server environments down to a much smaller number of physical hosts running SQL Server in vSphere.

Additionally, both SQL Server 2008 R2 Datacenter Edition and SQL Server 2012 Enterprise Edition with SA provide you the ability to run as many VMs on a physical host as the hardware allows.  This makes it very easy to include SQL Server in your Private Cloud initiatives.

The last documents that you’ll want to be familiar with are the Microsoft Application Server License Mobility brief and Licensing Microsoft Server Products in Virtual Environments.  Together the documents mentioned above provide a good summary of your options.  Once I walk customers through some of the information in these documents, they realize that in addition to making sense technically and operationally, it can also lead to reduced SQL Server license costs as they virtualize SQL Sever on vSphere.

As always, we suggest you consult with your Microsoft representative to obtain the most accurate licensing information for your situation.

By now, a lot of tier-2, tier-3 SQL Servers has been virtualized. Customers are seeing more availability, better agility with those SQL Servers running in a virtualization environment. That's leading customers to consider moving tier-1 mission critical SQL Servers onto the virtualization environment. A properly configured ESX is crucial to the successful deployment of a tier-1 SQL Server. In this post, I would like to talk about some storage configuration guidelines that would help maximize SQL Server performance on VMware.

Use eagerzeroedthick disk

Virtual machine disk files can be deployed in three different formats: thin, zeroedthick, and eagerzeroedthick. Thin provisioned disk enables 100% storage on-demand, disk space is allocated and zeroed out at the time disk is written. Zeroedthick disk is pre-allocated, but blocks are zeroed out by the hypervisor during the first time the disk is written. Eagerzeroedthick disk is pre-allocated and zeroed initialized during provision time. There is no additional cost for zeroing out the disk during run time.

For optimal disk access performance, use eagerzeroedthick disks for SQL Server data, transaction log, and tempdb files.

Ensure alignment of VM virtual disks

Partition alignment is a well discussed topic for SQL Server. An unaligned partition results in a track crossing and additional IOs, incurring penalty on latency and throughput. See figures below.

On VMFS, partition alignment should be configured at the VMFS level and Windows level. Beginning with ESX v3.x, VMware automatically aligns new partitions to a 64KB boundary when you create a VMFS from vCenter. In ESX v5.0, new partition is automatically align to the 1MB boundary. You may also manually align your VMFS partition. See http://www.vmware.com/pdf/esx3_partition_align.pdf for instructions on manual alignment.

For Windows 2008 and above, partition alignment is usually performed by default. The default for disks larger than 4 GB is 1 MB; the setting is configurable through Windows registry setting HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment. However the default partition alignment may be altered if system is created with OEM setups. It's a good practice to always check to confirm partition alignment. For more information, see Disk Partition Alignment Best Practices for SQL Serverhttp://msdn.microsoft.com/en-us/library/dd758814.aspx.

Optimize with device separation

SQL Server files have very different disk access patterns. Placing SQL Server binary, data, transaction log, and tempdb files on separate storage devices provides maximum flexibility, and improves performance. Consider the following best practices for deploying a tier 1 mission critical SQL Server.

• Place SQL Server binary, log, and data files into separate VMDKs. In additional to the performance advantage, separating SQL Server binary from data and log also provides better flexibility for backup. The OS/SQL Server Binary VMDK can be backed up with snapshot-based backups, such as VMware Data Recovery. The SQL Server data and log files can be backed up through traditional database backup solutions.
• Maintain 1:1 mapping between VMDKs and LUNs. When this is not possible, group VMDKs/SQL Server files with similar I/O characteristics on common LUNs.
• Use multiple vSCSI adapters. Place SQL Server binary, data, log onto separate vSCSI adapter optimizes I/O by distributing load across multiple target devices.
• Test prior to deploying SQL Server. Storage sub-system should be able to achieve IO requirements with an acceptable latency in additional to capacity requirements. IOMeter can be used to simulate SQL Server IO patterns. Below table are example SQL IO patterns that can be used to test storage sub-system performance without invoking an actual SQL Server workload.

-Wanda

Wanda He, Technical Solutions Architect

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit www.vmware.com/go/virtualizeyourapps.

In the last few years we have had some great successes of customers virtualizing their SAP landscapes in production on VMware, check out Mazda and Miami Dade at http://www.vmware.com/solutions/partners/alliances/sap-customer-success.html, both of whom presented their case studies at SAP Sapphire and SAP Tech Ed.  For technical success follow the VMware best practice papers and SAP Marketplace notes on virtualizing on vSphere (see the references at the end of this blog).  Here are some high level guidelines and considerations.

Support

SAP has supported VMware since Dec 2007 on Netweaver 6.40 and above (64 bit) in production. VMware engineers with SAP experience work with SAP support at SAP offices to provide coordinated handling of production support tickets.

Performance

Our customers are running both OLTP and batch workloads in production. Certified OLTP SAP virtual benchmarks exist.  Two 3-tier vSphere certifications 2010016 and 2011044 (http://www.sap.com/solutions/benchmark/sd3tier.epx  ) show scalability up to 16000 and 32125 benchmark users.

If you are interested in how virtualized SAP performs in comparison to native, first consider what the chief engineer of the Starship Enterprise (NCC-1701/NCC-1701A) is fond of saying “Ye canna change the laws of physics”, neither can VMware.  For an apples-to-apples comparison take a look at 2-tier benchmark certifications 2011028 (physical) and 2011027 (vSphere5)   at http://www.sap.com/solutions/benchmark/sd2tier.epx .  The virtual result is within 6% of physical.  Note that virtualizing SAP typically occurs when there is a hardware refresh/upgrade to newer servers with much faster chips. The latter (with VMware) can provide an overall performance boost compared to the customers current environment.

SAP batch processes are intensive workloads.  Examples of such jobs include: MRP runs (Material Requirements Planning) in the manufacturing module; Demand Forecasting/planning Run in the Supply Chain Management product; Allocation Run (ARUN) in the SAP Apparel and Footwear module. SAP has designed these batch jobs to run multiple parallel units of work on multiple processes in the app servers. These app servers can be configured in multiple virtual machines that scale out horizontally to manage the overall runtime of the batch schedule (similar to horizontally scaling out OLTP workloads).  The advantage with VMware is that these app servers can be quickly deployed for month-end processing and then decommissioned once batch has completed.

Virtualize in Phases

Virtualization of SAP landscapes is not an all or nothing approach.  The SAP landscape consists of multiple SAP products (ERP, CRM, portal etc.) with separate production and non-production environments and separate application and database tiers.  Virtualize the less critical systems first, gain experience with VMware, and develop your own internal best practices and then move on to the next set of systems.  One option is to virtualize the application tier first all the way from non-production to production.

Design the Virtual Landscape Conservatively

SAP systems drive business critical processes and, as such, SAP users require and demand performance and stability.  For instance, if shipping documents cannot get processed by SAP, goods can’t leave the warehouse and the supply chain suffers. Hence SAP application owners are more likely to take a cautious approach to infrastructure changes especially if they have agreed upon performance SLAs between the IT organization and business users.  First adopt the phased virtualization approach discussed above to gain gradual confidence and experience in VMware. Next follow some conservative design practices.

You can get a sizing of your virtual environment from a VMware capacity planner assessment or from a sizing exercise by the SAP practice of the server/OEM vendor - similar to physical. VMware partners with all the server vendors. As it can be very difficult to predict actual workload before go-live, sizing will be conservative and factors in month-end peak processing requirements.  We recommend setting a memory reservation to the configured size of the virtual machine to guarantee no memory over commit. Yes this will reduce consolidation, potentially impede vMotion and requires high-density DIMMs to efficiently load an ESX server, but the goal is to minimize risk of any performance issue in production and avoid ESX swapping.  The latter can be viewed by SAP end-users as an outage and could have serious revenue impact to the business (monetary value of which far exceeds the hardware cost of the extra memory required for SAP).

Other conservative guidelines during initial architecture design may include: laying out virtual machines such that total number of vCPUs equals the number of cores of the ESX server; putting DRS in manual mode  (initially SAP admins may prefer to have manual control, also with conservative sizing DRS would not have any impact).  After go-live once the workload is known, rebalancing of virtual machines via vMotion can help increase utilizations to the point where vCPU over-commit is possible at which point automatic DRS can be activated.

 If memory of virtual machines appear to be over-sized we ask that VMware admins work with SAP Basis administrators to use SAP tools to monitor actual SAP memory usage inside the virtual machine to determine if any down-sizing is required.

Coordinated Performance Monitoring

SAP has provided a rich set of performance monitoring tools that allow Basis admins to monitor the database, OS and SAP application. All of this can be done within the SAP presentation GUI. One such SAP monitoring transaction is “OS07N” which allows monitoring of OS/guest OS level performance counters. This transaction has been updated by SAP to include some virtual level performance metrics. However certain key performance metrics in the virtualized environment such as realistic CPU usage, disk I/O and network dropped packets can only be viewed using VMware tools like vCenter performance charts. SAP admins need to be aware of these counters and should work with the VMware teams to jointly address performance monitoring and management.  The following table summarizes some useful performance metrics/tools at the different levels.

 
      Figure: Some Useful Performance Tools/Counters (WIP)

You can find the SAP on VMware best practices guide at http://www.vmware.com/files/pdf/techpaper/SAP-Solutions-on-VMware-Best-Practice-Guide-2011.pdf .  Chapter 10 has a summary of the technical best practices – yeah I know we should have separated this summary with titled sub-sections for memory, CPU, storage, network….easier to digest…..we’ll get to this on the next rev.

A complete list of VMware related SAP marketplace notes is available at http://forums.sdn.sap.com/thread.jspa?threadID=1524523&tstart=0  . As is the case with all SAP installations please read the notes.

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware.  To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit www.vmware.com/go/virtualizeyourapps

For a few years now we've been providing guidance on virtualizing Exchange on vSphere. Although not fully supported at the time, customers were looking for guidance to virtualizing Exchange 2003 and 2007 and so we created best practices guides and performance studies. Today we continue to provide best practices, design and sizing, and availability guides for Exchange 2010 on vSphere. With all of those resources out there one could ask, "What else is there to cover?" In this first posting of two I wanted to take a step back and look at some of the pre-requisites for designing an Exchange environment on vSphere. In Part 2 of this series I'll jump forward to some design considerations to keep in mind when virtualizing Exchange on vSphere. What about the technical details in between pre-reqs and design considerations? We've got those well covered and I'll provide links at the end of this article.

Microsoft Exchange Server, for most organizations, is the central communications stream and as such becomes critical to the daily operations of the business, or a business critical application. Unlike the typically virtualized workloads of days past, these business critical applications typically require a dedicated project staff and budgets, and are highly visible throughout the organization. Because of the importance of such a project to the organization proper planning is vital to ensure a successful outcome.

To aide in successful planning consider the following pre-requisites when beginning an Exchange design for deployment on vSphere.

Understand the business and technical requirements

Among the many technical requirements that must be followed when deploying Exchange and vSphere it is important to understand any technical and non-technical requirements placed by the organization. A few of the most common business requirements we encounter when designing a virtualized Exchange environment are listed below.

• High availability – What level of availability needs to be designed into the environment? Is there an SLA in place that requires services to be restored within a certain time period? With Exchange 2010 this is one of the most important decisions to be made at the beginning of the design process. The use of Database Availability Groups will dictate the amount of storage needed to house active and passive databases, as well as how many mailboxes can be supported per mailbox server. Is disaster recovery in scope?
• Supportability of the design – Those of us that have worked for large organizations know the importance of designing a supported solution, and more importantly the frustration of having support calls closed due to an unsupported configuration. When building the design keep support in mind and be sure to consult with your hardware and any other software vendors to make sure they will take your calls when problems arise.
• Scalability – Is the goal of the company to continue to grow or does the nature of the business keep the organization size stable? If this is a large environment do we need to consider deploying fewer larger virtual machines, or is it preferable to scale-out with smaller virtual machines. If this is a volatile environment do we need to have the capability to scale-out or up on demand using templates or hot-add technologies?
• Mailbox Size – Are there currently quotas in place or will they be introduced as part of this new design? Is there a limit to the amount of data that the proposed solution can handle? Does archiving need to be factored into the solution?
• Performance – What bolt-on accessories are in use in the current messaging environment and does their functionality need to be carried over? Many of these solutions will add overhead to the environment and their use needs to be accounted for when it comes time to size.

Analyze the current messaging environment

An Exchange 2010 sizing exercise is mostly based on the assumption that there is an understanding of the current usage of the messaging environment. If this is a greenfield environment it will be necessary to estimate what the usage will be and this can be very difficult. Typically I would recommend beginning with a medium to heavy workload, around 150 messages per day, per mailbox. The beauty of building on vSphere is that if it turns out that the environment was over-provisioned you can easily scale back and regain some compute resources for other projects.

If there is an existing Exchange environment you can download the Exchange Server Profile Analyzer to help understand the current messaging requirements. This tool can look at a single Exchange mailbox database or across an entire organization and report on user activity. Other ways to analyze the messaging activity within an organization include:

• Exchange message tracking logs
• Sendmail or Postfix logs
• Statistics from email anti-virus tools
• Logs from SPAM gateways
• Third-party email statistics tools

Regardless of which method is chosen, the desired outcome is to determine the average number of messages sent and received per mailbox per day. This is the primary method used by Microsoft to determine the amount of processor and storage resources each mailbox uses and the recommended amount of physical RAM that should be allocated for mailbox database cache. The table below from TechNet can be used to determine the amount of database cache, IOPS, and CPU estimates based on user activity.

Table 1. IO Profile Resource Utilization Estimate

Source: TechNet - Mailbox Server Processor Capacity Planning

Analyze the health of the current messaging and vSphere Environment

Before beginning an Exchange migration project, a full health check of the current Exchange environment, the vSphere environment, and any infrastructure dependencies should performed. Often times a new environment can help bring an underlying issue to the surface. Being able to identify these issues and resolve them before going into production can make a migration much smoother for the implementation team as well as the end users.

A number of tools are available to help make sure there are no glaring issues in the current environment.

• VMware HealthAnalyzer – captures data from the vSphere environment including configuration and utilization information to provide a health report card. Ask your VMware representative for more details on obtaining a health check using HealthAnalyzer.
• Exchange Best Practices Analyzer – The ExBPA is installed with the Exchange Management Console and can be used to quickly scan a particular server or the entire organization's configuration against best practices. The report lists details about the configuration and offers explanations and guidance on how to fix common issues. Running the ExBPA is a must before placing any Exchange server into production and is recommended to run as part of routine maintenance.

Identify support and licensing options

With a business critical application like Exchange it is key to understand support and licensing considerations. Support for virtualizing Exchange has come a long way over the past few years. The Server Virtualization Validation Program provides mainstream support for running Exchange 2007 and 2010 on vSphere. Prior to going down the road of building a design it is a good idea to walk through the Support Policy Wizard on the Windows Server catalog web site to validate that the solution you are putting together is supported.

Figure 1. SVVP Support Policy Wizard

No matter the hypervisor used to virtualize Exchange 2010, the support requirements remain the same. The Exchange team at Microsoft outlines the requirements for virtualizing Exchange very well on the Exchange System Requirements TechNet page. These requirements must be reviewed and understood to be sure that the design meets Microsoft's support guidance and to help avoid any confusion during a support request.

Exchange 2010 is licensed per server and client-access license, just as it is on physical. This is important to note as it may help determine whether you design using a scale-up or scale-out approach. Another licensing consideration is that of license mobility. Previously application licenses tied to a physical server could only migrate between physical servers once every 90 days. This was updated to allow application licenses to migrate between physical hosts within a server farm as needed. More information can be found in the Application Server License Mobility document. As always, we suggest you consult with your Microsoft representative to obtain the most accurate licensing information for your situation.

Thanks for making it this far. I hope you found the often overlooked pre-requisites for virtualizing Exchange 2010 on vSphere helpful. In Part 2 I will dive into some additional design considerations to keep in mind when virtualizing Exchange 2010 on vSphere. If you've missed any of the great resources we have on virtualizing Exchange 2010 on vSphere check out our resources page at the link below.

http://www.vmware.com/solutions/business-critical-apps/exchange/resources.html

-alex

Oracle DBAs considering to virtualize Oracle 11gr2 RAC should check out VMware vSphere 5 platform - VMware® vSphere® is the industry-leading virtualization platform for building cloud infrastructures. It enables users to run business-critical applications like Oracle with confidence and respond to business needs faster by taking advantage on the application and Infrastructure services that vSphere 5 provides.

As you all know, Oracle now provides support (Oracle MySupport ID: 249212.1 – RAC support added as of Nov 8, 2010) for Oracle 11gr2 RAC on VMware. VMware vSphere® 5.0 can handle the intensive workloads of business-critical applications - Let us discuss on a workload characterization study that was conducted on a four node Oracle 11g R2 RAC using VMware vSphere 5 with Cisco UCS servers and EMC VNX5500 Unified storage. See below the architecture that describes and demonstrates how the Oracle RAC deployment can sustain a heavy OLTP load without any degradation to transaction performance.

Below table describes the various components involved in this workload study.

Let us see below the few test result highlights described in this workload characterization study:

• 24 hour workload Test: The following table summarizes results for 24 hour workload test. The above architecture was tested by subjecting it to a sustained heavy OLTP workload over a 24-hour period and results showed substantial transaction throughput without any degradation in performance.

  

• Oracle RAC Node VM vMotion Test: The following SwingBench load generator screenshot shows the results during first and second vMotion. This also shows there is a minimal TPM impact during vMotion and ramps back to where it was before the vMotion, each vMotion took approx 64 seconds.

For more detailed read, check out the Oracle Databases on VMware vSphere® 5 - RAC Workload Characterization Study click on the image below

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware.  To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit www.vmware.com/go/virtualizeyourapps

Whether you’re a large enterprise or small to midsized business, VMware solutions enable you to reduce costs and simplify your plans for business continuity and disaster recovery (BC/DR). 

For customer sites with up to 75 virtual machines: Save 40 percent off a 75-VM pack of VMware Site Recovery Manager™ Standard and vCenter Operations™ Enterprise.

For customer sites with more than 75 virtual machines: Introducing the Business Production Bundle, a 75-VM pack of Site Recovery Manager Enterprise, vCenter Operations Enterprise, and VMware vShield App. Purchase it now and receive 75 free Training Credits (value $7,500 USD). Training can be instructor-led or webbased and expires after one year.

For more information regarding this promotion, visit: http://www.vmware.com/go/bcdr-promo

The VMware Business Continuity/Disaster Recovery promotion is effective from February 1, 2012 to June 15, 2012.

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit vmware.com/go/virtualizeyourapps