Home > Blogs > Virtualize Business Critical Applications > Monthly Archives: March 2012

Monthly Archives: March 2012

Virtualizing SQL Server on vSphere – Licensing

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.

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.

Your Guide to Virtualizing SQL on vSphere (Part 1)

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.

R/W%

Type

Block

Threads / Queue

Simulates

80/20

Random

8K

# cores / Files

Typical OLTP data files

0/100

Sequential

60K

1 / 32

Transaction Log

100/0

Sequential

512K

1 / 16

Table Scans

0/100

Sequential

256K

1 / 16

Bulk load

100/0

Random

32K

# cores / 1

SSAS Workload

100/0

Sequential

1MB

1 / 32

Backup

0/100

Random

64K-256K

# cores / Files

Checkpoints

-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.

 

Your Guide to Virtualizing SAP on vSphere

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.

  Image
      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