Sunday, September 13, 2015

Part 1 - Virtualizing SAP - Why, When & How?

Last week I introduced this series about running SAP on VMware and this would be the first part of this series. As a technologist, I believe we should always look at both the sides of the coin while taking decisions and for me the first side is always business.

If you are not designing a technical solution keeping in mind the business benefits, then chances are that either your solution will miserably fail or it would never be adopted by the business since it does not keeps them into consideration.



WHY?

Working on the same principle, I thought I would start this series by talking about the Why and Whens before jumping into the Hows! Let us jump onto the reasons as to why we should virtualize SAP and how will it impact the Business Side and the Technology side of what we all know is one coin. 

I think it would be a marketing talk if I start talking about the features, stability and performance of vSphere as one of the driver for an organization to virtualize SAP. While these factors are a confidence builder, honestly speaking for a business it does not matter what platform they are running on, till the time the underlying infrastructure can serve the business demands without any compromise in the performance of business transactions which at the end of the are the backbone of any organization. Hence it is mostly for IT to decide on the platform while the business mostly looks at the reference case studies and the adoption rate by it's peers in the industry as a benchmark for choosing a platform.

Needless to say that vSphere has the most number of SAP workloads running on it if compared with any other hypervisor, because SAP itself runs there IT on VMware and I have not seen many, infact any customer NOT to follow the footsteps of there most critical software vendor. Now that we know that business will mostly follow references, it is important that we can get the right ones. It is easy to find references here on this link and I would encourage you to use them if required.

While the usual trend for business critical applications is to run on the most expensive hardware with no questions asked, we are seeing a rapid change in this trend in the last 5 years where customers are migrating from the expensive world of Unix platforms (Capex and Opex wise) to the commodity world of x86 platform. To top it all, Intel has done a fairly good job to ensure that there processors are becoming robust by the day to ensure higher standards of hardware availability. So while the biggest benefit to the business is saving tonnes of money, they also get the benefit of making a traditional application like SAP run on a platform which gives it the flexibility to Scale, Perform, Migrate, Upgrade, Update & Recover from disasters in a much more efficient manner than the traditional platforms.

At the end of the day SAP is just a simple 3 tier application, hence the 1st mantra is that the environment which you choose to run this application on should be simple.



WHEN?

While I can say NOW, it is only true for greenfield environments. For brownfield, the time to virtualize SAP has to the most critical decision for sure. While technology is no longer a limitation with the growing scale of physical x86 servers and VMware virtual machines, from a business point of view if you are planning to migrate from a Unix based environment, then you have to wait for certain opportunities which would make the move less painful or more rewarding. Let us quickly review all the opportunities: 

1- New SAP Deployment (Greenfield) - A scenario where you are building your first SAP module grounds up in a new SAP deployment. In this situation, virtualization has to be the first choice. Remember this includes all the tiers of your SAP application including the Oracle database which is licensed with the SAP license and hence you don't have to deal with Oracle licensing nightmares. One the other hand if you are worried about the WHY's then read above. 

2- SAP Upgrade Cycle - This is a no brainer, since this is your opportunity to explore the approved downtime from business around upgrading the SAP landscape. The SAP upgrade is where you could re-architect the SAP environment inclusive of Test, Development and Production to ensure that you can get the benefits of virtualization such as High Availability due to a distributed install.

3- Migration to 64 Bit Net-weaver - This is similar to a platform re-architecture and another great tipping point where the new 64 bit architecture can be built on the Virtual Platform of vSphere.

4- Expanding to New SAP Modules - This is similar to a new deployment, however if you have an existing SAP environment, you might NOT want to extend that for new modules, rather go for the virtual environment with the bells and whistles of VMware as this might be a lesson learnt for you to move your existing apps on top of the Virtual x86 Servers.

5- Hardware Refresh - I think this is the most obvious reason for you look at the x86 world as both the Capex and the Opex to run on the traditional hardware usually costs a bomb. 


Now that we have a good understanding of WHY and WHEN, it only makes sense to continue to the HOW part of the title!!


HOW?

Well, with this series, I will run your through a real life project which I recently completed for a customer in virtualizing their SAP Enterprise Resource Planning system, which essentially is the backbone of their organization. This includes, the TEST, Development and Production environments with the key VMware solutions for Virtualization, Operations & Disaster Recovery. Hence, the rest of the parts of these series would dive into each of the areas and numerous design decisions keeping in mind the requirements of the SAP application. While most the principles would be similar to architecting a vSphere environment for any application, with this series, I will call out the specific areas of consideration for SAP, right from sizing to implementation.

With that I will close this article and will see you with the next part of this series which would be:


Part 2 - Sizing SAP to run on VMware vSphere (coming soon...)


Till then.. Stay tuned!!

Share & Spread the Knowledge...




4 comments:

  1. Hi Sunny, thanks for sharing the knowledge esp. as pertains to the black art !
    Any idea whe the next installment(Part 2 - Sizing SAP to run on VMware vSphere ) will be up?

    ReplyDelete
  2. Hello Sunny, nice article you have there.

    May I know when will you be sharing SAP sizing on VMware vSphere? I am hoping to see that you pick a few SAP apps (e.g. HR, PI, BPC), and apply vSphere sizing methodology to it as I believe not all SAP apps behave the same way, and they should be sized differently, individually.

    Perhaps you may consider to start with a particular SAP Application functionality, the number of concurrent users at peak hour, the number of SAP Application nodes, then the SAP EWA Report, SAPS count, and how do these translate to number of vCPU and Memory.

    Once we have those, how do we configure each VM (i.e. NUMA node consideration, filesystem / mountpoint IOPS requirement, vNIC requirement etc.)?

    Looking forward to your next blog entry!

    ReplyDelete
    Replies
    1. Thanks David. This went to the back burner due to a number of things. I will definitely pick this up in the coming month and share my experiences around sizing and other topics.

      Delete