At Advent One, we are fortunate to have fantastic engagements with both our existing clients and to new clients. In many cases we are helping our enterprise SAP clients to standardise, automate and modernise their SAP implementations.
Together, with our partners, we work to provide a trusted delivery method that enables Advent One to deliver a rapid delivery and implementation cycle, reducing project costs and most importantly delivering a stable and consistent operating environment for business-critical applications across public, private and hybrid cloud.
Sometimes, things just don’t fit the accepted norm. So, when a project comes along with challenging objectives and timelines that are, at first thought of as impossible, you have to start thinking outside the square and utilising the modern technologies and resources available make it happen.
So, how do you have nine women make a baby in one month?
Our Project
One such instance is a SAP HANA migration with one of our clients, which we feel is a story worth telling.
This project had some extremely tight timelines, but with detailed design and careful pre-planning, coupled with the extensive use of automation tools, we were able to deliver the new environment in under seven days. Something that one would expect take weeks to implement and operationally harden was ready in just under a week.
Speed to go from piles of equipment stacked on pallets in the corner to a functioning set of systems was one thing, quality was the other. SAP clearly define what is required to have a certified infrastructure to run HANA and there is a significant amount of work to accurately meet the requirements in an accurate, fault tolerant and secure way.
This blog will discuss how Ansible Automation was used to deploy the entire SAP solution on IBM PowerVM running Red Hat Enterprise Linux for SAP applications from a defined state sitting in a git repository.
The environment Advent One delivered consisted of:
-
Compute & Hypervisor
-
Enterprise Storage
-
Enterprise Backup
-
OS Deployment and customisation
-
Preparing the environment for SAP (apply all the sapnotes etc)
SAP HANA TDI
SAP HANA TDI stands for SAP HANA Tailored Data Center integration program which enables customers to leverage existing hardware and infrastructure components for their HANA deployment as opposed to dedicated appliances or deployment in cloud instances.
SAP has very strict tests to determine whether hypervisor technology is good enough to not slow down HANA while isolating virtual machines well enough to avoid one instance of HANA from affecting the performance of other HANA instances in the same server.
In the early implementations of HANA dedicated appliances were prevalent for bare metal performance which removed virtualisation and the flexibility that comes with it.
The deployment being discussed here was using IBM PowerVM as the hypervisor (which is certified by SAP) on IBM Power Systems ensuring that all the SAP TDI guidelines were followed.
Ansible Automation Targets
The following diagram describes all of the configuration ‘items’ ansible touched as part of the deployment.
A combination of a lot of internal ansible roles that we could reuse, coupled with community roles sourced from Ansible Galaxy gave us the ability to point Ansible against all the below.
Ansible communicates with Linux systems via SSH and with devices and hypervisors using their REST API over secure https communication.
Ansible Galaxy and Roles
Ansible Roles provide a framework for fully independent, collections of variables, tasks, files, templates, and modules. In Ansible, the role is the primary mechanism for breaking a playbook into multiple files. This simplifies writing complex playbooks, and it makes them easier to reuse. Ansible roles can be sourced from an internal git repository, or from Ansible Galaxy which is an online collection of roles for easy consumption.
Advent One have a large internal collection of ansible roles, which were able to be used as part of the deployment. This happened first. The types of things done with the Advent One roles are:
-
OS Configuration Management Baseline
-
Security Baseline
-
Storage & Filesystems
-
Hypervisor VM creation, networking, storage etc.
-
Users & Groups
-
Performance tuning (eg multipathd)
-
Deployment of our monitoring and metrics collection software
-
Deployment and configuration of backup software
-
Allocation of Red Hat subscriptions, and enrollment into Red Hat Insights
The roles sourced from Ansible Galaxy applied a lot of the sapnotes and configuration required for the SAP pre-requisites for HANA and Netweaver. There are roles to actually deploy S/4 HANA, which is something we are yet to try, but very keen to work with the Basis team to do that which would enable end-to-end deployment.
The following example requirements.yml lists the upstream Ansible Galaxy roles that can be used, as well as Advent One’s SAP roles repository for our internal automation tasks. These are all imported at runtime.
Variables Structure
In order to define the desired state of the environment, we carefully considered the structure of our variables to ensure that things such as the following were clearly defined.
-
Where do I find software that is not installed via yum?
-
What is my timezone, DNS, mail relay, SSSD, monitoring, metrics values?
-
What filesystems, users, groups do I need to create?
-
What is my SAP SID, instance number?
These were structures as a combination of host_vars (variables for a particular host) and group_vars (variables for a group of hosts).
Bringing it all together
Once we had our playbooks, roles and variables ready, it was go-time. The hardware was powered up and connected to the network, and we were ready for the big bang deployment. Internally at Advent One we utilise Ansible Tower, so we were able to create a deployment workflow to do everything:
-
Configure the Storage
-
Configure the Hypervisor & VMs
-
Prepare the operating system & security baseline
-
Set up SAP printers, users, filesystems etc.
-
Apply all the SAP notes
-
Configure the backup software
-
Configure monitoring and metric collection
Through our customer portal, all the operational insights for monitoring and metrics were instantly available, as this is deployed along with the environment itself, so we were able to immediately have operational insights as we completed post deployment testing to ensure that everything was functioning as expected.
Lessons Learned
The planning process is what we could all agree as painful in the level of detail we had to get to quickly. We had everything to the smallest detail documented, and subsequently defined as variables in git ready for our deployment.
Aligning the team was critically important. Everyone working on the project needed to buy-in to the fact that we had to drive everything through automation.
Consistency of OS, hypervisor and network configuration is critically important. All the settings must align to get screaming fast performance, and there are significant performance penalties if they don’t. Being able to guarantee this consistency, was another benefit of using an automation tool.
Make sure you understand the SAP required software levels. You can use subscription manager to pin RHEL to a particular version of RHEL so that a yum update won’t patch past it. These software levels can be found here:
Conclusion
The timelines for design and planning cannot be collapsed without sacrificing the quality of the project, however if you have the right tools at your disposal the time taken to reach the desired outcome can be slashed dramatically.
Best of breed infrastructure and software underpinned the solution and having Ansible as an automation tool being able to tie it all together enabled us to deliver the solution at a record pace.
When we stand back and look at the work that was completed, one thing that stands out is how repeatable this is bringing together Advent One and community provided Ansible content delivering results that have delighted our customer and everyone on the project team can be proud of.