Running SAP Sybase Data Management Products In A Virtualised World

[Former Member]

Welcome everyone to my blog focused on key aspects of running SAP Sybase data management products in virtualised environments. Over the coming months I hope it will be a useful source of information for you and stimulate your interest in the “virtualised world”!

Much of what I share will be focused on my personal area of expertise – the SAP Sybase data management products brought into the SAP “database” portfolio through the acquisition of Sybase in 2010 I worked for Sybase for approximately 20 years, as a consultant in the field, prior to the SAP acquisition and have worked with these products on numerous customer projects over that time and expect to continue to do so!

I will primarily focus on these three core SAP Sybase “data management” products namely:

• SAP Sybase Adaptive Server Enterprise (ASE). 
• SAP Sybase IQ (IQ).
• SAP Sybase Replication Server (RS).

ASE is the traditional OLTP database engine that was the corner stone of the Sybase product portfolio since Sybase started in 1984.

IQ is a columnar data store (with some overlap to SAP HANA capabilities) targeted at the Data Mart / Data Warehouse / Data Mining space.

This product has gained significant traction in the in the last 5-10 years or so and is regularly positioned in the market leader space by industry respected analysts e.g. Gartner Group etc.

RS is the near real-time data movement product which “on the face of it” has a very similar role to SAP Landscape Transformation Replication Server (LTRS). Amongst some of the key differentiations of RS are:

• Transactions are read directly from the source database transaction log – not through the use of source database table triggers (as in LTRS).
• Source system performance impact is extremely low when compared to the inevitable overhead of table trigger code (LTRS).

But more about RS in later posts!

I will be addressing vitalisation of each of these products in a series of posts, beginning today with an overview of virtualising SAP Sybase ASE.

But first, for those of you who may just be beginning to explore SAP’s database technologies, I would like to recommend the following presentation from TechEd Madrid 2012 which provides an in depth view of SAPs overall database strategy. This will help set the stage for you by establishing the core value of these technologies so you can better understand how they might be further leveraged for even greater cost-savings and ease of administration in virtualised environments: http://www.sapvirtualevents.com/teched/sessiondetails.aspx?sId=3357

Oh and by the way, these links are also great starting points if you would like to access more in depth information on these three products:

• ASE: http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise
• IQ: http://www.sybase.com/products/datawarehousing/sybaseiq
• RS: http://www.sybase.com/products/businesscontinuity/replicationserver

Virtualisation – Definition, Scenarios & Benefits

OK, so let’s get started by answering the million dollar question!  What is “virtualisation” and what are the benefits?

The short “high level” answer is virtualisation is the replacement of a physical computing environment (hardware platform, operating system, software, storage device, data, network resources, etc) with a virtual one.

But that doesn’t help so much so let’s explore further to better understand the concept.

In a typical IT environment:

• Virtualisation allows for virtual machines (VMs) to be “cut from” the underlying physical hardware (CPU, disk and memory) in such a way as they appear almost) completely like a physical machine/host to any software deployed in them (including the guest O/S).
• The greatest benefit is that you can deploy many VMs from one underlying physical h/w platform such that the VM host resources (CPU, disk and memory) are shared amongst all the VMs it supports. Each of these VMs may run a different guest O/S and suite of applications.
• The “VM” management s/w shares the physical CPU, disk and memory resources amongst the VMs (working to various configuration parameters, rules and controls) allowing much better resource usage of the underlying (host) h/w and, of course, its cost – cost reduction being the primary aim.

VM platforms offer many additional features and benefits such as:

• VM “cloning” – the simple ability to copy the complete VM environment – useful for simple backup scenarios.
• VM movement/transfer between underlying VM hosts in “cloud” cluster environments – a VM (say running an ASE database) can be moved in real time to a different host environment when performance demand requires.
• VM  resource management - resources can often be dynamically modified – reconfigured “on the fly” if you will.
• Some Cloud/VM environments provide for quite sophisticated automatic failover and recovery scenarios in the event of “failure”.

Related to these last three points - particularly impressive being the ability of some cloud/VM environments to migrate a running VM (and its whole s/w environment) around the underlying “host” infrastructure without client disconnection and with only moderate performance impact. Hard to believe but it works!

When I refer to virtualisation I am talking about it in the broadest sense – that is, these SAP Sybase products running “virtualised” in the following scenarios:

• in an in-house or on-premise cloud.
• in a public cloud e.g. the recently announced collaboration between SAP and Amazon Wed Services.
• or on customer premises using “virtual machine” VM hosting platforms/technologies such as (O/S independent) VMware vSphere, Xen Hypervisor or (O/S dependent) RedHat Linux Enterprise Virtualization and many others.

Why no differentiation?
From the SAP Sybase products viewpoint there is little (if any) difference which of these virtualisation scenarios is being used.
However, there may be differences in approach to SAP Sybase product configuration depending upon the exact virtualisation target.
For example, with a product running in a public cloud, an organisation is probably going to require greater control and management in the “security space” both for data on disk (encryption) and network traffic (encryption) in/out of the cloud. Whereas in a private cloud or VM deployment, the focus is likely to be more on meeting/maintaining performance service levels.  More on this later!

Hopefully you now get the “high level” picture of why virtualisation has become such a hot topic – much better use of h/w resources with associated – and likely significant - cost reduction. It’s that simple really!

More to the point, the overall benefit of running these SAP Sybase technologies in a virtualized environment is that organisations can better leverage their software architecture at a significantly reduced operating cost whilst eliminating costs/concerns such as “idling” h/w resources, inefficient usage of disk storage and so on.

However, with that said, “you don’t get something for nothing” in the IT world we live in – there has to be, and is, some overhead in running most applications virtualised. Database engines such as SAP Sybase ASE are no exception and we will begin to explore the reality in a moment.

Running SAP Sybase ASE Virtualised
I my experience, the main topics of interest (possibly concerns even) raised by our customers when considering running SAP Sybase ASE systems virtualised are:

• Performance impact. I’ve heard some many different opinions, just what is the real picture?
• Systems Supportability. Just how do I monitor for and manage issues when (say) the ASE is in the cloud? Does running ASE under a VM increase risk of outages etc?
• Systems Consolidation. How does this work out in practice when many ASE/VM systems are sharing a host h/w environment?
• Security – public cloud deployment related largely. What can ASE provide here to help address my security concerns?
• Disaster Recovery and Resilience e.g. backup and recovery approaches. Do I have to rethink/re-invent my DR/resilience strategies running ASE virtualised now?
• Migration Effort. Cost/Effort in migrating ASE systems to VM/cloud. In practice is migrating a productive system to VM any harder than any other migration? What does ASE and the supporting product/tool set provide to help me?
• Operational Cost Savings – In practice do I see the hoped for reduction in my total cost of ownership (TCO)?
• Oh and did I list performance impact!

I will address the “performance impact” question in a moment and plan to address the other topics in due course and provide further (technical) detail on why SAP believe ASE in particular is a “natural fit” to run in a cloud/virtual environment.

ASE Virtualised - A Real World Example
But before that a brief example from my own experience running ASE (and RS) virtualised.

A small UK financials market application vendor I worked with hosts (facility manages) their clients SAP Sybase ASE database(s) in an on-premise ASE VM/cloud hosted in a Xen Hypervisor host/platform. A second off-site Xen host/platform is used for (site) disaster recovery (DR) and the ASE databases within the suite of DR VMs are maintained using the near real time replication capabilities of SRS.
Quick aside on why my client chose RS for DR:

• For my client RS was a more cost effective and resilient approach than traditional metro/fibre disk block/level replication.
• Also my client recognised the risks of replicating disk corruptions when using disk level replication which RS technology completely avoids/eliminates - I will explain why when we get into RS proper in later posts.

They had traditionally deployed ASE on physical Windows Server PCs  and are now using virtualised Windows Servers instead.
Hopefully it is fairly easy to see why cutting new/cloned Windows VMs (in minutes) from the Xen environment was more attractive than commissioning new PC h/w (hours, days?) when a new client was signed up.

When I was on-site my role was largely to support the built out of their improved DR offering based on RS but also to support ASE migrations from v12.5.4 to v15.7 (which were already running in VMs). The Xen VM cloning ability became invaluable as a very simple mechanism to maintain “backups” of ASE (and RS) environments prior to Sybase product “patch” deployments or sometimes significant product re-configuration changes during the proof-of-concept (PoC) exercises sometimes required.

As expected the monitoring of the virtualised ASE systems didn’t really change at all – their 3rd party ASE (and RS) monitoring product worked just fine.
Although the performance requirements for their clients ASE systems were very modest and never really a concern, the overall Xen VM performance monitoring “dashboard” was found to be really useful as a first indicator of possible issues. The dashboard providing high level overview of resources (CPU, memory, disk & network) being absorbed by each VM etc.

In summary, my client found that pretty much all the generic operational management benefits of VM deployments (VM cloning, VM migration, very rapid “host” build out etc) as previously described came to be.
They also felt that the operational “cost savings” side held true but this was a subjective judgement rather than quantitative – being quite a small organisation that “had to do”.
Aside: As many ASE customers have found the level of DBA support required by ASE is very modest compared to competitor products. My client took that to a new level leaving one employee responsible for Xen (VM) environment management and DBA support for the ASE and RS estate!

Overall, my clients feedback on running SAP Sybase ASE and RS virtualised was very positive – great news then!

ASE Virtualised – Performance Impact
So to kick off this topic I thought you would find this TechEd 2012 presentation, put together by a colleague Chris Brown, a useful overview:
Virtualizing SAP Sybase ASE:  http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/104880ad-0521-3010-a9b3-993159450acb

It is particularly interesting to see that the high ASE performance impact expected was not actually seen by Chris in his “like for like” testing and that the impact (measured in transaction throughput) was only in the 5-10% range. Pretty positive.

His testing used a single ASE environment compared between a physical and a VM deployment (a simple “like for like” test) and I know Chris is keen to address more “real world” scenarios such as the following:

• Taking several ASE physical environments and consolidating them in VMs on a reduced physical environment – and assessing the performance impact.  Something many customers are planning to do or have done. After all, this “real world” scenario is the whole point right? As per my client story earlier -cost reduction through consolidation with minimal operational impact.

So what SAP Sybase ASE performance impact (aka “penalty”) should you expect?
Well a key factor is the level of “over deployment” of host resources you have configured or to put it another way how many VMs (running SAP Sybase ASE) you have cut from the underlying host (VMware, Xen) environment. Another key factor being how well have you matched each ASE configuration to the VM (resources) it is running in?

So, the short answer is “it depends”.

However, what we can say is that the technical architecture of ASE provides a number of features (my “natural fit” comment earlier) that lend themselves to providing predicable/stable performance under VM by maintaining better control over the VM (h/w) resources and being less impacted by the VM operational overhead etc.
BTW, if you are interested in deep technical detail on these ASE features I recommend the Sybase ASE manuals (http://infocenter.sybase.com/help/index.jsp) which have excellent overview sections covering ASE’s internal architecture.

1. The ASE (“OS like”) Kernel
ASE has always incorporated general OS kernel functionality e.g. internal resource (connection/task, other) scheduling, disk and network i/o management.

The ASE multi-process/internal “thread” scheduling architecture uses multiple cooperative processes (ASE “engines”) to leverage parallel hardware when running in process kernel mode. The number of ASE engines (processes) can be configured to mirror the cores/CPUs available in the VM.
In addition, ASE also has a threaded kernel mode (the default mode starting in ASE release 15.7) which is what Chris used in his tests.
Notes:

• Even in ASE threaded kernel mode there is the concept of an ASE engine - although somewhat reduced compared to process kernel mode. For this reason it is somewhat of a “hybrid” threaded architecture.
• ASE threaded kernel mode was introduced to better utilise “CPU resource” when running in environments using hyper-threaded cores – becoming particularly common from chip manufacturers such as Intel.

It is interesting to note that Chris’s testing was all done using ASE in “threaded” kernel mode rather than the traditional “process” kernel mode.
I understand he plans to carry out testing using ASE process kernel mode in due course and it will be interesting to see what those tests show.

Although possibly VMware specific perhaps, he notes that keeping the number of virtual cores (“vCores”) to a minimum and busy is better than being over generous on vCores for best performance. As Chris was using ASE threaded kernel mode, it implicitly mapped to the vCore count in the VM. When an ASE is in process kernel mode it is important to match ASE engine count to vCore count for the VM.

2. ASE Memory Management
ASE memory can be pre-allocated from the O/S at start up.  Generally this pre-allocated memory is requested from the “host” as “pinned shared memory”. 
This fixed memory map ability is important when configuring VMs to support ASE deployments as it allows better memory management and control for ASE VMs “cut from” the underlying physical host.

This raises an associated initial “best practice” – generally of the four main resource types (CPU, memory, disk i/o & network bandwidth i/o), it is the over allocation of VM memory (compared to underlying physical host memory) that should be kept to a minimum when deploying ASEs within VMs.

3. ASE Lower Resource Consumption – Other Resources
Since ASE can be setup to ask for most resources (as per memory) that it needs at start up, it becomes possible to run multiple instances of ASE even within a single VM or physical h/w environment. In effect ASE internally provides, and has always provided, several of the key properties of a VM including partitioning, isolation, encapsulation, and hardware independence.

Also, ASE has a proven track record as a lower footprint product in terms of "host" resources required to meet the performance goals for any given systems workload compared with the competition - further supporting the "natural fit" positioning of ASE for cloud/VM.

As a result of these features, ASE performance under a VM can be better managed and is more predicable than the competition.

Next Time
In my next post I will look at systems supportability, consolidation opportunities and security with respect to SAP Sybase ASE running in the cloud/VM.
Hope you will be back to see what I have to say then?

Finally, let me leave you with a reference to the recently published SAP “Statement of Direction” for customers using SAP Sybase ASE (http://www.saphana.com/docs/DOC-2851). It contains a key bullet (on page 4) clearly indicating SAPs commitment to making SAP Sybase ASE the best database engine available for cloud/virtualised environments. This is great news for the product and I look forward to updating you on the further ASE innovations/optimisations targeting cloud/VM as they are rolled out.