by Jeremy Wonson @virtualwonton
Who should read this?
If you already have orchestration and automation in place, and you’re interested in adding SAP to your already automated environment, this should get you started.
If you’re already a happy user of Puppet and/or Razor, and you want to use it in your SAP environment, this may help you start a conversation with the SAP team.
If you’re part of a SAP team, and you want better control over your server deployment and configurations, parts of this blog post will work for you as well.
Why should you read this? Because EMC and SAP go together like peas and carrots.
At least, that’s what countless customers have told me at various conferences and events, such as EMC’s SAP Week. This is an event co-sponsored by EMC and SAP, with generous involvement from VMware, Cisco, VCE, Deloitte and others. Topics of discussion range from HANA to LVM to Cloud-enabling SAP. As an experienced Cloud Architect with a limited background in SAP, I was given the task of understanding how to cloud-enable SAP using VMware.
Before I started on this project, I decided I should define what cloud-enabling means in a SAP environment. With that in mind, I arrived at the following characteristics:
Solution includes orchestration and automation outside of SAP
Automation/Orchestration addresses both physical and virtual servers
Non-SAP software works in harmony with SAP products or tools
Solution includes closely related applications outside of SAP (bolt-on)
Focus on VMware tools as much as possible
Portals are intended for IT, SAP Basis and applications staff, not true end users (Accountants, HR, etc)
Why I chose those characteristics
1. Solution includes orchestration and automation outside of SAP
If you ask SAP about private cloud, they first talk about LVM, or “SAP NetWeaver Landscape Virtualization Management”, and then they may talk about HEC or “HANA Enterprise Cloud”. HEC on the customer premise is not ready for prime time right now. When I’ve spoken with the teams within SAP that own and support HEC, on-premise private HEC is a future vision. LVM is an awesome tool for the SAP Basis team. It takes tasks that would have taken days or weeks and through the magic of automation, those same tasks take minutes or hours. Since it’s created and supported by SAP, it’s often preferable to the custom scripts the Basis team would create to do some of the same tasks.
It’s important, however, to understand what LVM does, and what it doesn’t do. In figure 1, the different layers of a SAP environment are shown. LVM works primarily with the database and central instance layers of SAP. LVM can clone, copy or refresh those layers. The only thing that LVM does with the application servers at this time is “Automated Capacity Management”, which means it can scale out/in application servers based on pre-determined thresholds. If I want to clone a production environment to make a new training environment, I would need application servers, and possibly bolt on applications to make the training environment run properly.
The only way I can accomplish this within LVM is with custom scripting, which leaves much to be desired. The cloud solution must not only incorporate SAP resources outside of LVM control, but also bolt on applications outside of SAP entirely.
2. Automation/Orchestration addresses both physical and virtual servers
A recent survey estimates that approximately 15 percent of productive SAP environments today include some server virtualization, almost exclusively using VMware. In fact, SAP is the fastest growing VMware workload. However, most SAP environments still use physical servers for the Central Instance and Database servers. Bolt-on applications may or may not be virtualization friendly. SAP LVM works with both physical and virtual machines due to this reality. The cloud solution must therefore work with both physical and virtual servers.
3. Non-SAP software works in harmony with SAP products or tools
As I mentioned earlier in this post, SAP has a private (on-premise) cloud message using their own products and services, specifically LVM. Any orchestration and automation tools or portal software needs to be compatible in some way with LVM.
4. Solution includes closely related applications outside of SAP (bolt-on)
As I explained in the description of the first characteristic, bolt-on applications must be considered. Today this is done manually or possibly using scripts. To cloud-enable SAP, the bolt-on applications must be automated and orchestrated as well as the SAP applications.
5. Focus on VMware tools as much as possible
Let’s face it, I work for EMC in close cooperation with VMware. Cisco makes a nice orchestration/automation solution with many parts and pieces called CIAC, Tidal, ITPA, etc, that works with SAP, including API integration with LVM, but it’s complicated and expensive and takes a significant amount of professional services to get running properly. I’m going to tell you how to get it done with VMware tools and Puppet, both because VMware invested significantly in Puppet Labs, and because that combination is less complicated and less expensive.
6. Portals are intended for IT, SAP Basis and applications staff, not true end users (accountants, HR, etc)
I’ve found that when I refer to creating a portal, it’s important to describe the intended user of that portal. This narrows the scope and reduces the spinning of wheels. The portals that are referenced in figure 2 are for DevOps staff, as well as SAP Basis and other applications staff.
My Cloud Apps Cocktail
At first, this felt a little like assembling a puzzle without a picture of what the end product should look like. I took the basic functions needed for a private cloud-like service and started building. Along the way, VMware decided to change the names or retire various products or pieces of the vCloud Suite…I just love it when the picture on a puzzle piece changes or the piece disappears.
I also learned that VMware invested millions in Puppet, which seems to be a direct competitor to one of their products. I’m not going to say why I wasn’t surprised, but I wasn’t. The mix of technology I eventually selected is shown in figure 3.
I chose to start with the description of the portals because I’m starting from the point of view of IT’s customer, the application owner or Basis Admin. This is the change in mindset IT shops need to undergo: View IT services from the perspective of the consumer.
In figure 4, the workflow of an order or request is shown. In figure 5, the future workflow of an order is shown, once API integration is offered. You can probably see why I’m really looking forward to API integration.
I chose SAP LVM for some of the SAP related workflows, since it’s supported by SAP and it makes some pretty complex workflows very easy. I chose VCAC (big surprise) for the overall orchestration function, and anything that was not covered by LVM. Although API integration between VCO and LVM is not available today, it is being developed at the time of this blog post.
The automation of tasks related to SAP workflows that SAP LVM manages is executed by SAP LVM. Automation of tasks in workflows outside of SAP LVM are executed by vCenter Orchestrator (vCO). Physical server and VM image management and deployment is handled by Razor, which is called by vCO. Application deployment is also handled by Puppet. All the automation tools, with the exception of LVM, will work for the environment outside of SAP as well.
When I showed the present and future figures to one of my clients, they were very happy that there is separation between the SAP Basis functions and the VMware administrative functions today. Their IT Management doesn’t want to put the ability to create systems in the hands of the SAP Basis team. IT Management likes the idea of someone on the systems team being aware that resources are being requested and deployed. Manual tasks can be added into workflows. This level of control can be offered with most orchestration tools.
Is Reporting Important?
Many enterprises today have invested in people, but not in tools. Data is gathered manually, recorded in spreadsheets and then pasted into presentations. When fulfilling requests made by the business, the admins have the opportunity to check the system. That’s when they become aware of shortages and potential problems (not failures, which are typically captured by a monitoring tool).
When those administrative duties are replaced by automation, reporting becomes paramount. No longer will the admin happen to notice that the array is down to 10TB available, and they have a request in their inbox for 20TB, and it’s the beginning of a new quarter.
When applications, and the infrastructure underneath, are deployed without human intervention, reporting is how IT stays ahead of demand and forecasts growth and budget. Without reporting, you can easily orchestrate and automate yourself out of resources, and not realize it until it’s too late. For reporting, I recommend vCenter Operations Manager (vCOPS), Watch4Net and Puppet. SAP LVM will integrate with vCOPS within the next few months. Watch4Net has integration with all major server, hypervisor, storage and network products, as well as many applications, including Oracle and SAP. Puppet does a great job of telling you which systems are out of compliance, based what you’ve already set up and may also fix those compliance issues for you automatically during the next run.
Today and Tomorrow
Since API integration between vCO and LVM doesn’t currently exist, vCO works independently of SAP LVM, as shown in figure 4. That means that there’s a person who uses vCAC, and therefore vCO, to deploy everything SAP needs, including the servers or VMs that LVM will use as target systems. Then that person or another person uses LVM to do the pieces of the workflow LVM does best. Last, someone uses vCAC, and vCO, to tie it all together and make everything work together. This is not pretty right now, but it will improve as soon as soon as VMware finishes the LVM/vCO API integration.
What does the future hold?
When vCO has API integration with SAP LVM, it will be able to call LVM workflows and ask LVM to perform tasks. At that point the orchestration layer is much simpler and more reliable. As shown in figure 5, vCAC will handle the entire workflow from beginning to end. It will use vCO to call LVM to perform the tasks it does best, and will call vCO to do the rest. vCO will call Puppet and Razor as needed for app/system deployment. This will also change how the portals are used.
While the same portals are in place, the LVM portal will be used only when the overall workflow occurs solely within the LVM context. For example, you may decide you don’t need to put Automated Capacity Management in a vCAC portal when the only person to use the portal will be Basis Admins, and the entire process occurs within LVM. In that case, you’ll probably just let the Basis Admins use the LVM portal.
Where do I start?
Start by talking with your favorite resources from VMware, EMC, VCE, Puppet or SAP. If you still have questions or can’t find the information you need, feel free to send me a tweet. I can probably point you in the right direction.
You can also see us at a future SAP Week event in coming Months to engage further on this topic: SAP Week Atlanta Feb 11th-12th & SAP Week Santa Clara March 4th-6th in 2014.
Jeremy Wonson: Cloud Architect and vSpecialist focused on Service Providers and Systems Integrators. Known to enjoy automation, orchestration, SAP and bacon.