Distributing WebAssembly components using OCI registries
As the cloud-native space keeps evolving at a rapid pace, WebAssembly is…
Maintaining a competitive advantage often depends on how quickly you can deliver new services. SAP applications are designed to help companies analyze data to anticipate new requirements and rapidly deliver new products and services. This gives you the ability to keep existing customers happy while attracting new business.
In line with SUSE’s vision is to simplify, modernize, and accelerate with technology, the first release of SUSE Linux Enterprise Server for SAP Applications already included automated installation features for the SAP software stack. Over the last 10 years, our SAP LinuxLab and development engineers have introduced several additional features to automate routine system administration.
Starting from the idea of simplifying and modernizing SAP HANA and SAP Interweave deployments, SUSE worked on rewriting the deployment wizards we had built.
Building the infrastructure to running SAP applications can get quite complex and demands a big effort if they get deployed manually. In addition, reproducing the process can be tedious and error-prone. An additional challenge is to make the infrastructure highly available, as this will add more complexity and tasks.
SUSE’s major motivation was to improve, simplify and unify the installation of SAP Landscape on SUSE Linux Enterprise Server for SAP Applications and clearly standardize deployments and allow customers to use one level of tooling in various ways—from a Command Line interface, through some GUI-driven process and SUSE Manager, or other automation frameworks. So it was clear for us to move to a more modern approach, like infrastructure-as-code, in order to reduce the effort and errors.
As SUSE Linux Enterprise Server and many other SUSE products ship with a universal configuration management solution for the last few years, we used this as the base for the new automation. This configuration infrastructure management system is called Salt from SaltStack and provides a highly scalable, powerful, and fast infrastructure automation and management, built on a dynamic communication bus. Salt can be used for data-driven orchestration, remote execution for any infrastructure, configuration management for any app stack, and much more.
Combining this management system with an infrastructure deployment solution like Terraform makes it possible to do a hands-free setup of an SAP Landscape, ready to login to start customizing your SAP System.
Such a number of systems have an additional challenge: getting an overview of what’s going on after the install is done. So we added the possibility to allow insights into your SAP Landscape with comprehensive dashboards, real-time and historic views, and active alerts and reporting based on flexible and powerful open-source projects Prometheus and Grafana. The deployment automation can be configured to also set up a monitoring environment for the clusters, HANA, and Netweaver.
SAP HANA and Netweaver applications can be deployed in many different scenarios and combinations. So we created building blocks, which are modular and reusable to attend from single install to full cluster deployment.
As of today, we take care of:
The solutions will get extended continuously depending on the demands of customers and partners and development is already underway for Netweaver HA with ENSA2 (Enqueue Standalone Architecture).
If you want to know more about the ENSA2 details, please have a look at this SUSE blog post.
The overall landscape that gets deployed looks like:
SaltStack’s configuration management system lets you define the applications, files, and other settings that should be in place on a specific system. The system is continuously evaluated against the defined configuration, and changes are made as needed.
The good thing is that SLES-for-SAP Applications 15 SP2 ship all these formulas now as part of the product, so you can set up as you need.
The HANA formula takes care of the following:
The Netweaver formula for bootstrapping and managing the SAP Netweaver platform takes care of:
Beyond that, the formula sets up all of the pre-requirements as:
The formula follows the best practices defined in the official SUSE documentation.
The HA bootstrap formula takes care of creating and managing a high availability cluster.
Depending on the cloud requirements it may need an iSCSI server to be able to provide a shared disk for fencing where we use the iscsi-formula from SaltStack.
To build a HA NFS Service if there is none available, we can create one with help of 3 Linux services and the following
The iSCSI-formula from SaltStack is able to deploy iSNS, iSCSI initiator, and iSCSI target packages, manage configuration files, and then start the associated iSCSI services.
A SaltStack formula to install and configure nfs server and client.
Starting from the idea of improving user experience, SUSE worked on how to monitor the several High Availability clusters that manage SAP HANA and SAP Netweaver in a modern way. For monitoring, we use the Prometheus toolkit and the Grafana project to visualize the data.
To be able to monitor the clusters on either HANA or Netweaver we have written Prometheus exporters for it.
The exporter provides metrics from more than one database or tenant. It provides
Enables monitoring of Pacemaker, Corosync, SBD, DRBD, and other components of High Availability clusters. This provides the ability to easily monitor cluster status and health.
Enables the monitoring of SAP Netweaver, SAP HANA, and other applications. The gathered metrics are the data that can be obtained by running the sapcontrol command.
Note that the dashboards aren’t currently shipped within the product, but provided by SUSE as open source.
The simplest way is to use the Terraform project in Github. As development is always a moving target. SUSE provides releases to provide a stable setup. As of writing this, v6 is current. You should have knowledge of Terraform, Linux, and SAP to use it.
First, make sure that all pre-requirements are done:
hana_public_offer = "SLES-SAP-BYOS"
hana_public_sku = "12-sp4"
hana_public_offer = "sles-sap-15-sp2"
hana_public_sku = "gen2"
storage_account_name
storage_account_key
hana_inst_master
The inst_master variable should point to the directory where you have the extracted HANA install files. There are more possibilities, but for the simplest usage have everything already extracted on you share.#hana_archive_file = "IMDB_SERVER.SAR"
#hana_sapcar_exe = "SAPCAR"
#hana_extract_dir = "/sapmedia/HDBSERVER"
mkdir -p ../salt/hana_node/files/sshkeys
ssh-keygen -t rsa -N '' -f ../salt/hana_node/files/sshkeys/cluster.id_rsa
hana_ha_enabled = true
hana_cluster_sbd_enabled = true
ha_sap_deployment_repo = "https://download.opensuse.org/repositories/network:ha-clustering:sap-deployments:v6"
monitoring_enabled = true
pre_deployment = true
Now we have all settings for Terraform done and are nearly at the step to run the deployment, so save your changes.
az login
terraform init
terraform workspace new myname
terraform plan
terraform apply
If you setup correctly, you will have an installed and running SAP HANA Systemreplication Cluster in Azure in around 40 minutes.
As there is a jumphost when a public IP address is created, you simply can login to all machines from your machine with:
ssh -J @jumphost <adminuser@targethost>
If everything is enabled, the resulting azure architecture will look like the above diagram. Hope you enjoyed this tutorial—if you have any questions or feedback, please let me know in the comments below.