- SAP Managed Tags:
I discussed in part 1 of the series – ‘SAP HEC as a multi-cloud offering’ about the methods to derive a viable cloud strategy. I also explored the challenges/viability of multi-cloud deployments for SAP and non-SAP workloads and mentioned that SAP is working with multiple Hyperscaler vendors (namely Microsoft Azure, Amazon Web Services, Google Cloud Platform to enable the standard SAP HEC offering. To cope with increasing customer demand, it was necessary to adopt multi-cloud platforms and provide the customer with a choice in Hyperscaler.
The high-level validation steps to enable SAP's applications and databases on AWS, Azure, and GCP are summarized in Figure 1.
1. Data Center Strategy
Apart from legal data regulation in different industries and optimizing costs, it is important to validate bandwidth requirements and network latency for choosing a data center. Selecting nearby data centers can provide better performance and lower latency, but geographically dispersed data centers are equally important to offer truly global HEC service to SAP’s customer base. It also lowers risk in the case of a natural or human-induced data center disaster. The technical evaluation of each of the multi-cloud regions was based on the type of machine/ VM instances available in each of the regional data centers, specific storage technologies, network traffic costs in each region, and zone-region combinations for Azure, AWS and GCP.
Figure 1. Technical Validation steps: Multi-Cloud SAP HANA Enterprise Cloud
2. Infrastructure Certification
The SLA’s offered by Hyperscaler provider may be 99.99 percent, but they are only for network availability and the durability of the infrastructure. These SLAs do not apply for customer data and data availability. Data falls under what is often termed as ‘the shared responsibility’ model. Each provider would have a different shared responsibility model, so it is important that SAP validates the infrastructure components for its software and databases so that we can deliver HEC specific SLAs on application levels in production mode.
Luckily, we at SAP HEC were able to piggyback on our previous efforts of validating IaaS providers and machines for SAP HANA, SAP ASE, and SAP Netweaver. For example, a detailed list of certified IaaS vendor offerings based on different CPU architectures, RAM, cluster configurations, software versions, OLAP / OLTP application deployments, RHEL / SLES versions is available in our SAP IaaS Hardware Directory.
Similarly, network time protocol certifications of different deployment modes, SAP Netweaver – SAP HANA VM / Large Instances network lag testing, scale-out deployments, SAP standard application benchmarks (SD-Benchmark, BWH & BWAML benchmark) will be done prior to making any service generally available for a given Hyperscaler vendor.
3. Business Continuity Techniques – High Availability and Disaster Recovery mechanisms
Unplanned system downtime has become unacceptable in today’s business climate. Cloud-based business continuity solutions may offer many advantages if they can be effectively applied to the respective solutions. From the SAP perspective, overall technical validation of business continuity procedures should ensure that High Availability & Disaster recovery should appear consistent irrespective of the underlying provider.
To understand a high-availability solution for SAP systems it is important to know the classic single points of failure in an SAP system i.e. Message Server – (A) SCS instance, Enqueue Server – (A) SCS instance, SAP Web dispatcher and database. The SAP application does have built-in redundancy for many of the other key components i.e. ABAP dialog and batch work processes, Update Work process, Gateway work process, Spool work process, J2EE cluster nodes. For high availability, auto-host recovery techniques should be tested for different software types (Netweaver ABAP/JAVA, HANA, ASE, etc.) installed on top. AWS Auto-recovery, Azure Self-Healing, GCP Compute Engine automatic restart are some of the techniques which needed careful validation in this case. For HANA, we have the option of dedicated standby nodes where HANA auto-host failover can be performed, and this option needed explicit test and validation procedure for each vendor.
SAP HEC Disaster recovery services with required RPO/RTO values for short distance and long distance DR are described here. To offer this level of disaster recovery service on AWS, Azure and GCP, we validated DR setup mechanisms such as HANA system replication (synchronous or asynchronous) and auto-failover techniques for ABAP, JAVA, ASE, HANA, BOBJ, cloud connectors, and web dispatcher systems. In case of a disaster, the network-based redirection should be able to automatically redirect client applications using the SAP system to the IP address of the replacement system.
4. Network connectivity
SAP HEC is a private managed cloud and we must ensure that equivalent service can be offered on public cloud providers. To do that, the virtual private cloud management, web application firewall rule management, load balancer configurations, virtual private cloud (VPC) setup, private-public cloud connection management mechanisms were validated. Here are some of the connectivity options that were validated:
Apart from these customer-specific connection mechanisms, we also performed tests to validate requirements of SAP HEC’s - Centralized management environment (for instance provisioning, operating system setup, software installation automation, centralized monitoring, reporting, etc.) in individual cloud vendor’s infrastructure. These tools allow SAP HEC delivery teams to install and operate our customers’ individual landscapes in a consistent manner.
5. Reference Architecture and security configuration validations
The solutions deployable in HEC environment should follow consistent design principles which ensure that we can provide the required quality and scale to our customer landscapes. These design principles are packaged based on services, and type of solutions and leads to artifacts that are reusable across different customer landscapes. In the blog titled Managing large SAP BW on HANA systems: SAP HANA Enterprise Cloud (HEC) perspective, I discussed how we address the data growth puzzle for SAP BW on HANA systems and gave a flavor of our design methodology. The public cloud vendors and corresponding infrastructure technologies were validated using SAP HEC reference designs so that we can successfully operate complete lifecycle of a customer landscape.
When it comes to the security configurations i.e. access control & network security, it must be ensured by the IaaS Provider (be it SAP or public cloud provider) that the Administration Platform & API management layer is monitored against misuse and scanned for security vulnerabilities. Additionally, SAP HEC should be able to configure and combine the IaaS Provider services in a secure and reliable way (e.g. strong authentication & access control mechanisms). Similarly, all other operational security measures (such as system hardening, change management, security patch management, malware management, administrative user access management, data retention & requested data & user deletion) should be in place. All these elements are being validated systematically.
6. Hyperscaler specific services
Each IaaS vendor has different capabilities when it comes to compute, hybrid architecture, concurrent provisioning, migration automation, function as a service and storage related topics. The cloud computing landscape is maturing rapidly, and innovation in the areas such as containers, network, integration, machine learning, conversational AI, internet of things, edge-computing is mind-boggling.
In the case of a service like SAP HEC, it is important to introduce the underlying Hyperscaler provider- specific innovations to our customers in a timely and tested manner. SAP as a business process solution provider and a technology company can offer valuable innovation management services to our end customers and manage the complexity of managing multiple, rapidly moving parts. A very detailed comparison of hyperscaler provider services is available at http://comparecloud.in/.
7. Value Added Services
Apart from standard managed cloud services (described in HEC Roles and Responsibilities), SAP also offers several value-added services on top such as SAP Application basis support, functional application support, application evolution, and change management, etc. Other than AMS (application management), SAP also covers migration, consulting, cloud launch advisory, preferred success in the cloud. Each of these services can be adapted to the underlying infrastructure and management tools.
The result of this exercise is a consistent private managed multi-cloud offering for our customers. We hope that customers will be able to adapt their existing IT landscapes into the public Hyperscaler cloud of their choice with guidance by SAP through HANA Enterprise Cloud.
Figure 2. SAP HANA Enterprise Cloud enabled for Hyperscale providers
SAP HEC on Multi-Cloud - Technical Validation Steps
The high-level validation steps to enable SAP's applications and databases on AWS, Azure, and GCP are summarized in Figure 1.
1. Data Center Strategy
Apart from legal data regulation in different industries and optimizing costs, it is important to validate bandwidth requirements and network latency for choosing a data center. Selecting nearby data centers can provide better performance and lower latency, but geographically dispersed data centers are equally important to offer truly global HEC service to SAP’s customer base. It also lowers risk in the case of a natural or human-induced data center disaster. The technical evaluation of each of the multi-cloud regions was based on the type of machine/ VM instances available in each of the regional data centers, specific storage technologies, network traffic costs in each region, and zone-region combinations for Azure, AWS and GCP.
Figure 1. Technical Validation steps: Multi-Cloud SAP HANA Enterprise Cloud
2. Infrastructure Certification
The SLA’s offered by Hyperscaler provider may be 99.99 percent, but they are only for network availability and the durability of the infrastructure. These SLAs do not apply for customer data and data availability. Data falls under what is often termed as ‘the shared responsibility’ model. Each provider would have a different shared responsibility model, so it is important that SAP validates the infrastructure components for its software and databases so that we can deliver HEC specific SLAs on application levels in production mode.
Luckily, we at SAP HEC were able to piggyback on our previous efforts of validating IaaS providers and machines for SAP HANA, SAP ASE, and SAP Netweaver. For example, a detailed list of certified IaaS vendor offerings based on different CPU architectures, RAM, cluster configurations, software versions, OLAP / OLTP application deployments, RHEL / SLES versions is available in our SAP IaaS Hardware Directory.
Similarly, network time protocol certifications of different deployment modes, SAP Netweaver – SAP HANA VM / Large Instances network lag testing, scale-out deployments, SAP standard application benchmarks (SD-Benchmark, BWH & BWAML benchmark) will be done prior to making any service generally available for a given Hyperscaler vendor.
3. Business Continuity Techniques – High Availability and Disaster Recovery mechanisms
Unplanned system downtime has become unacceptable in today’s business climate. Cloud-based business continuity solutions may offer many advantages if they can be effectively applied to the respective solutions. From the SAP perspective, overall technical validation of business continuity procedures should ensure that High Availability & Disaster recovery should appear consistent irrespective of the underlying provider.
To understand a high-availability solution for SAP systems it is important to know the classic single points of failure in an SAP system i.e. Message Server – (A) SCS instance, Enqueue Server – (A) SCS instance, SAP Web dispatcher and database. The SAP application does have built-in redundancy for many of the other key components i.e. ABAP dialog and batch work processes, Update Work process, Gateway work process, Spool work process, J2EE cluster nodes. For high availability, auto-host recovery techniques should be tested for different software types (Netweaver ABAP/JAVA, HANA, ASE, etc.) installed on top. AWS Auto-recovery, Azure Self-Healing, GCP Compute Engine automatic restart are some of the techniques which needed careful validation in this case. For HANA, we have the option of dedicated standby nodes where HANA auto-host failover can be performed, and this option needed explicit test and validation procedure for each vendor.
SAP HEC Disaster recovery services with required RPO/RTO values for short distance and long distance DR are described here. To offer this level of disaster recovery service on AWS, Azure and GCP, we validated DR setup mechanisms such as HANA system replication (synchronous or asynchronous) and auto-failover techniques for ABAP, JAVA, ASE, HANA, BOBJ, cloud connectors, and web dispatcher systems. In case of a disaster, the network-based redirection should be able to automatically redirect client applications using the SAP system to the IP address of the replacement system.
4. Network connectivity
SAP HEC is a private managed cloud and we must ensure that equivalent service can be offered on public cloud providers. To do that, the virtual private cloud management, web application firewall rule management, load balancer configurations, virtual private cloud (VPC) setup, private-public cloud connection management mechanisms were validated. Here are some of the connectivity options that were validated:
- Hyperscaler native VPN connectivity
- Hyperscaler native direct connectivity (AWS Direct Connect, Azure ExpressRoute, GCP Google Cloud Interconnect / Partner Interconnect)
- Hyperscaler native internal connectivity (VPC Peering / VNet Peering)
- Hyperscaler native Load balancer management including Web application firewall rule management
Apart from these customer-specific connection mechanisms, we also performed tests to validate requirements of SAP HEC’s - Centralized management environment (for instance provisioning, operating system setup, software installation automation, centralized monitoring, reporting, etc.) in individual cloud vendor’s infrastructure. These tools allow SAP HEC delivery teams to install and operate our customers’ individual landscapes in a consistent manner.
5. Reference Architecture and security configuration validations
The solutions deployable in HEC environment should follow consistent design principles which ensure that we can provide the required quality and scale to our customer landscapes. These design principles are packaged based on services, and type of solutions and leads to artifacts that are reusable across different customer landscapes. In the blog titled Managing large SAP BW on HANA systems: SAP HANA Enterprise Cloud (HEC) perspective, I discussed how we address the data growth puzzle for SAP BW on HANA systems and gave a flavor of our design methodology. The public cloud vendors and corresponding infrastructure technologies were validated using SAP HEC reference designs so that we can successfully operate complete lifecycle of a customer landscape.
When it comes to the security configurations i.e. access control & network security, it must be ensured by the IaaS Provider (be it SAP or public cloud provider) that the Administration Platform & API management layer is monitored against misuse and scanned for security vulnerabilities. Additionally, SAP HEC should be able to configure and combine the IaaS Provider services in a secure and reliable way (e.g. strong authentication & access control mechanisms). Similarly, all other operational security measures (such as system hardening, change management, security patch management, malware management, administrative user access management, data retention & requested data & user deletion) should be in place. All these elements are being validated systematically.
6. Hyperscaler specific services
Each IaaS vendor has different capabilities when it comes to compute, hybrid architecture, concurrent provisioning, migration automation, function as a service and storage related topics. The cloud computing landscape is maturing rapidly, and innovation in the areas such as containers, network, integration, machine learning, conversational AI, internet of things, edge-computing is mind-boggling.
In the case of a service like SAP HEC, it is important to introduce the underlying Hyperscaler provider- specific innovations to our customers in a timely and tested manner. SAP as a business process solution provider and a technology company can offer valuable innovation management services to our end customers and manage the complexity of managing multiple, rapidly moving parts. A very detailed comparison of hyperscaler provider services is available at http://comparecloud.in/.
7. Value Added Services
Apart from standard managed cloud services (described in HEC Roles and Responsibilities), SAP also offers several value-added services on top such as SAP Application basis support, functional application support, application evolution, and change management, etc. Other than AMS (application management), SAP also covers migration, consulting, cloud launch advisory, preferred success in the cloud. Each of these services can be adapted to the underlying infrastructure and management tools.
Result
The result of this exercise is a consistent private managed multi-cloud offering for our customers. We hope that customers will be able to adapt their existing IT landscapes into the public Hyperscaler cloud of their choice with guidance by SAP through HANA Enterprise Cloud.
Figure 2. SAP HANA Enterprise Cloud enabled for Hyperscale providers
1 Comment
