Skip to Content

Hello again everyone! Hope your 2013 has got off to a productive start?

To quickly recap I listed the following areas of interest raised by our customers when considering running SAP Sybase ASE systems virtualized:

  • 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 virtualized 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)?

In my first (introductory) and follow up posts I discussed Performance Impact, Systems Supportability, Systems Consolidation and Security with respect to running SAP Sybase ASE in a cloud/virtual environment.

In this final “wrap up” post on SAP Sybase ASE I will briefly discuss these final topics – Disaster Recovery and Resilience, Migration Effort & Operation Cost Savings.

Disaster Recovery and Resilience

In the last post I posed these three questions:

– Would you expect your resilience/DR architecture thinking to be radically different for ASE cloud/virtualized deployments?

– Does cloud/virtualized deployment increase or decrease resilience/DR architecture complexity?

– What features of cloud/virtualization technologies/products can typically help in the systems residence space?

With respect to the first two questions, in my opinion the answers are basically no and it depends! Pretty much the same rules of engagement apply as if the SAP Sybase ASE system was running physically. We need to establish the business continuity requirements for the system or suite of systems in scope e.g.

– acceptable loss of committed data (if any);

– time to recover from component loss (disk, ASE instance) – site internal resilience;

– time to recover from complete site loss – full DR/failover scenario;

– etc. 

With these clearly stated requirements an appropriate resilience architecture can be designed which could possibly include the deployment of other SAP Sybase data management products such as SAP Sybase Replication Server (RS) – described in my first post. RS could be deployed for data replication between off-premise cloud/VM ASEs or a mix of on-premise/off-premise ASE running physically or virtually. Such a resilience architecture (where all database held data is replicated on a per transaction basis in near real-time) provides for recovery from a variety of failures including complete loss of an ASE environment (of any deployment flavor be it VM/cloud, physical, on/off-premise etc).

ASIDE:

– The use of RS for systems resilience is covered (amongst other SAP Sybase product based architectures) in this blog series by my colleague Christian Schmitt (first post here) – Business Continuity with SAP SYBASE solutions.

– An overview of RS capabilities, typical “use cases”, and customer references can be found here – Real-Time Data Replication Software | Database | Technology | Solutions | SAP

The scenario where one or more of the ASEs in systems scope may be running virtually leads us to discuss the third question posed. In such a scenario we are able to consider features and capabilities of the supporting VM/cloud environment in our resilience architecture design such as VM cloning, VM backup and/or VM migration. As per my first blog post, these capabilities can be very impressive – the ability to failover/migrate a specific VM (running an ASE) within the overall VM platform due to certain VM platform component failures etc. Clearly certain business continuity requirements could be addressed through such features.

In summary, I would assert that deploying SAP Sybase ASE virtually (on/off-premise & cloud) has only moderate impact to your resilience architecture thinking and, if anything, may allow you some simplification compared to traditional physical SAP Sybase ASE deployments (on/off-premise).

Migration Effort

In the introduction I posed the question – In practice is migrating a productive system to VM any harder than any other migration?

In my opinion the short answer is no, the migration of an existing ASE database environment to cloud/virtual deployment involves the same steps/procedures/processes as it would if it was being migrated to a different physical (non-VM/cloud) environment.

From a database (“data”) centric viewpoint, the primary issue would be is the VM guest O/S the same or different for the ASE installation supporting the application to be migrated?  If the current and (VM guest) O/S are different it is possible that the O/S uses different endian (Endianness – Wikipedia, the free encyclopedia) encoding which will impact the way the ASE database “data” content is interpreted.  Fortunately the SAP Sybase ASE database backup capabilities (commonly referred to as database dump/load) provide a cross O/S platform database backup feature that allows for this issue. During the load of a database backup into an ASE environment (with a different endian encoding from the source ASE environment) every byte in the database backup is transparently swapped to meet the target O/S ASE environment byte order requirement. Upon completion of the target (VM) O/S ASE database load – and after the possible rebuild of some index structures – the database is “ready to go”.

In the scenario where you are migrating an application from a non-SAP Sybase ASE environment (e.g. Oracle) to SAP Sybase ASE, again the same steps/procedures/processes would apply irrespective of whether the target SAP Sybase ASE environment was real/physical or VM/cloud. It is interesting to note that good traction is being seen within our customer base for the migration of physical non-SAP Sybase ASE systems to virtual/cloud based SAP Sybase ASE systems for various reasons including TCO of course!

Finally many of the features available in VM environments (as discussed earlier) – e.g. VM cloning, VM snapshot and rollback etc – can be very useful in supporting migration efforts to VM/cloud deployments particularly during the development/regression testing/UAT stages in the migration project lifecycle.

If you are interested in the general topic of system migrations to SAP Sybase ASE, particularly from non-SAP Sybase ASE based systems, I would recommend you review the following series of SAP Community blogs created by my colleague Jonathan Wesley-James which contain considerable levels of detail on this topic:

Best Practices for Migrating To SAP Sybase ASE – an introduction

Best Practices For Migrating ToSAP Sybase ASE – Designing architecture migration

Best Practices for Migrating to SAP Sybase ASE – Implementing schema migration

Best Practices for Migrating to SAP Sybase ASE – Implementing data migration

Best Practices for Migrating to SAP Sybase ASE –Implementing application migration

Best Practices for Migrating to SAP Sybase ASE – Implementing operation migration

Best Practices for Migrating to SAP Sybase ASE – Validating the migration

Best Practises Migrating to SAP Sybase ASE – Enterprise Migration Planning using a Factory Concept

Best Practices Migrating to SAP Sybase ASE – Migration Implementation using Minimum  Down Time

Operational Cost Savings

Of course as with any significant IT infrastructure change, “your mileage will vary” in terms of the level of cost savings seen when SAP Sybase ASE is deployed virtually. However, what we can say is that when the best of breed TCO model for SAP Sybase ASE is combined with typical systems consolidation opportunities presented by VM/cloud implementations, the results are generally very positive for our customers. In summary cloud/VM deployments typically enhance/magnify the effect of lowering the overall TCO through the use of SAP Sybase ASE.

As per my first blog, from my personal experience I have seen customers who have undertaken this move and been very satisfied particularly when the additional operational benefits/features of running in VM/cloud are taken into account.

If you are interested in further detail on the comment “best of breed TCO model for SAP Sybase ASE” I recommend reviewing the publicly available material from these leading industry analysts:

– IDC Whitepaper: http://www.sap.com/mena/asset/index.epx?id=40095f6e-0c34-4dfb-8865-746ea2996923

– Bloor Whitepaper: Sybase ASE Total Cost of Ownership | Bloor

Next Time

This wraps up my mini series of SAP Sybase ASE targeted blog posts.

I hope you have found them of interest and please do contact me directly if you have an comments or questions?

In my next post I will address a number of topics with respect to the deployment of SAP Sybase IQ in virtualized environments.

In the meantime please take a minute to look at the recent exciting announcement of SAP Sybase IQ 16 availability

SAP Drives  Business Transformation Through Innovative “Big Data” Insights

And Finally!

Please check out our “Database Services Content Library” to find all the SAP Database and Technology Services blogs available.

To learn more about SAP Database and Technology Services I recommend you start here – http://www.sap.com/services-and-support/data-and-technology/database-services/index.epx

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply