- SAP Managed Tags:
This is part 2 of the blog series covering various options available in SAP Landscape Management (LaMa) to perform Database Refresh when using HANA as the database.
Part 1: Refresh Scenarios Across Azure Regions and Subscriptions
Part 3: Using Backint Agents for AWS and GCP
In this blog, the refresh will occur across Azure and AWS, using the HANA replication approach. The scenario can also apply across on-premise datacenter and an IaaS as well as other IaaS (e.g. Azure/AWS to GCP) as the concept is similar.
LaMa SP21 or later is needed for performing replication based refresh when using HANA single tenant database. HANA MDC (multitenant database containers) was used in part 1 of the blog series and has been supported for some time in LaMa. However, HANA single tenant database (abbreviated here as HANA stdb) refresh using HANA replication was not supported with LaMa until SP21.
Minimum HANA version is 2.0 SPS 05 Rev 52 (2.00.052). If you do not meet this requirement then the option to allow replication based refresh of single tenant database will not appear in the configuration.
Since we demonstrated HANA MDC refresh in part 1, we will focus on HANA stdb refresh in part 2 of the blog series. Below is a screenshot from the LaMa user guide for SP21 showing the high-level steps involved.
Note: Some diagrams may appear too small or blurry to view. In this case please click on the diagram to enlarge it.
As shown in the diagram above, I have a distributed setup of ABAP with HANA stdb system residing in Azure (US West). I have a similar system residing in AWS (US East).
At this point there is no network connectivity between the 2 environments.
All of the IP addresses used for intersystem communication are in the private address space - 10.1.xx.xx/24 in Azure and 172.xx.xx.xx/24 in AWS.
Note that there is a 13 character limit for hostname in LaMa.
We will create a VPN tunnel between the Azure Vnet and AWS VPC. Steps involved in setting this up are covered in the appendix section at the end of the blog.
After the successful setup of the VPN tunnel, our lab environment now looks like:
Now that VPN is established, perform a simple test from LaMa OS prompt to the ssh port of the three systems in AWS.
Assuming that ssh connections are not blocked, you should see a successful connected output.
As LaMa is in Azure, we also need to ensure that communication ports are open in the AWS VPC for connections coming from the Azure side.
Open following ports on AWS VPC to allow traffic from Azure Vnet:
LaMa configuration steps were already covered in detail in part 1. Only the additional configuration will be covered here.
As in part1 of blog series.
Follow procedure in part 1, to create an additional pool for AWS
Create a new network configuration for AWS
Create a repository for the AWS systems. In part 1 we created it for Azure so now we will have two.
Discover and configure systems in both Azure and AWS following procedure in part 1. There is a slight variation in the topology as we have single tenant database. Ensure that your topology looks like the below.
As in part 1 except for the new option added in SP21.
Edit the system A4H, navigate to the Network Isolation page. Here we add the 3 target hosts’ primary host names or IP addresses. This is to avoid any potential communication loss between the 3 AWS hosts when fencing is enabled.
As in part 1.
We are not doing restore based refresh so we are not configuring HANA backup share like we did in part 1.
Follow part 1 to configure secure communication for replication. Alternatively you may want to disable secure communication since the VPN tunnel is already secure but for lab tests only.
In this exercise we will refresh A4H (AWS) from DEQ (Azure). Since the mapping in LaMa is already done with DEQ as source for A4H, we do not need to specify the source when refreshing A4H.
Due to the configuration we made in LaMa (Configure Target System Provisioning & RFC), the database refresh operation will use HANA replication.
CAUTION: Before starting the Database Refresh operation, make sure that the tenant database is backed up for the target system. As part of the process, the target tenant database is dropped and recreated before replication. Therefore if the operation fails before replication is completed, you can recover via a restore from backup.
We successfully performed a HANA single tenant database refresh using HANA replication. In addition we demonstrated how it can be done across different cloud providers. The same principle can be applied in a hybrid cloud environment to perform database refresh between on-premise datacenter and a public cloud environment.
Part 3: Using Backint Agents for AWS and GCP
This section is an optional read and covers steps to create a VPN tunnel between Azure and AWS:
Part 1: Refresh Scenarios Across Azure Regions and Subscriptions
Part 3: Using Backint Agents for AWS and GCP
In this blog, the refresh will occur across Azure and AWS, using the HANA replication approach. The scenario can also apply across on-premise datacenter and an IaaS as well as other IaaS (e.g. Azure/AWS to GCP) as the concept is similar.
LaMa SP21 or later is needed for performing replication based refresh when using HANA single tenant database. HANA MDC (multitenant database containers) was used in part 1 of the blog series and has been supported for some time in LaMa. However, HANA single tenant database (abbreviated here as HANA stdb) refresh using HANA replication was not supported with LaMa until SP21.
Minimum HANA version is 2.0 SPS 05 Rev 52 (2.00.052). If you do not meet this requirement then the option to allow replication based refresh of single tenant database will not appear in the configuration.
Since we demonstrated HANA MDC refresh in part 1, we will focus on HANA stdb refresh in part 2 of the blog series. Below is a screenshot from the LaMa user guide for SP21 showing the high-level steps involved.
Note: Some diagrams may appear too small or blurry to view. In this case please click on the diagram to enlarge it.
Lab Environment
As shown in the diagram above, I have a distributed setup of ABAP with HANA stdb system residing in Azure (US West). I have a similar system residing in AWS (US East).
At this point there is no network connectivity between the 2 environments.
All of the IP addresses used for intersystem communication are in the private address space - 10.1.xx.xx/24 in Azure and 172.xx.xx.xx/24 in AWS.
- HANA version: 2.00.057
- Netweaver SAP_BASIS Release: 7.53
- SUSE Linux Enterprise 12
- LaMa 3.0 Enterprise edition SP21
- SAP Host Agent Patch 52
- SAP Adaptive Extensions 1.0 Patch 62
| TYPE | SID/HANASID | VM Hostname | Virtual Hostname |
| ASCS (Azure) | DEQ | deq-xscs-0 | deq-ascs |
| PAS (Azure) | DEQ | deq-app-0 | deq-app-1 |
| HANA (Azure) | AH1 | deq-db-0 | ah1-db |
| LaMa (Azure) | J2E | lama-azure | n/a |
| ASCS (AWS) | A4H | z-vm1 | a4h-ascs |
| PAS (AWS) | A4H | z-vm2 | a4h-app-0 |
| HANA (AWS) | AH1 | z-vm3 | hdb-db |
Note that there is a 13 character limit for hostname in LaMa.
Connectivity
We will create a VPN tunnel between the Azure Vnet and AWS VPC. Steps involved in setting this up are covered in the appendix section at the end of the blog.
After the successful setup of the VPN tunnel, our lab environment now looks like:
Test Connectivity
Now that VPN is established, perform a simple test from LaMa OS prompt to the ssh port of the three systems in AWS.
LaMa# telnet <ip address of A4H system> 22Assuming that ssh connections are not blocked, you should see a successful connected output.
As LaMa is in Azure, we also need to ensure that communication ports are open in the AWS VPC for connections coming from the Azure side.
Open following ports on AWS VPC to allow traffic from Azure Vnet:
- Instance agent: 50013 to 50014
- Host agent: 1128 to 1129
- ABAP: 32<xx> and 33<xx> (xx is instance number)
- HANA: 30013 and 30015
LaMa Configuration
LaMa configuration steps were already covered in detail in part 1. Only the additional configuration will be covered here.
Discover/Configure Systems in LaMa
Engine Setting
As in part1 of blog series.
Pool Configuration
Follow procedure in part 1, to create an additional pool for AWS
Network Configuration
Create a new network configuration for AWS
Repository Creation
Create a repository for the AWS systems. In part 1 we created it for Azure so now we will have two.
Discovery
Discover and configure systems in both Azure and AWS following procedure in part 1. There is a slight variation in the topology as we have single tenant database. Ensure that your topology looks like the below.
Configure Source System Provisioning & RFC
As in part 1 except for the new option added in SP21.
Configure Target System Provisioning & RFC
- Repeat the above for the target system as copy of the source. This is important to enable the refresh option.
- We have one extra option compared to part 1. This is a new feature in SP21 to allow replication based refresh of single tenant database.
Configure Target Network Isolation
Edit the system A4H, navigate to the Network Isolation page. Here we add the 3 target hosts’ primary host names or IP addresses. This is to avoid any potential communication loss between the 3 AWS hosts when fencing is enabled.
PCA Activation
As in part 1.
HANA Configuration
We are not doing restore based refresh so we are not configuring HANA backup share like we did in part 1.
Follow part 1 to configure secure communication for replication. Alternatively you may want to disable secure communication since the VPN tunnel is already secure but for lab tests only.
Refresh Database with HANA Replication
In this exercise we will refresh A4H (AWS) from DEQ (Azure). Since the mapping in LaMa is already done with DEQ as source for A4H, we do not need to specify the source when refreshing A4H.
Due to the configuration we made in LaMa (Configure Target System Provisioning & RFC), the database refresh operation will use HANA replication.
CAUTION: Before starting the Database Refresh operation, make sure that the tenant database is backed up for the target system. As part of the process, the target tenant database is dropped and recreated before replication. Therefore if the operation fails before replication is completed, you can recover via a restore from backup.
- Enter Master Password for OS and DB Users
- If passwords differ then they can be changed in one of the subsequent steps
- In Tenant Details, accept defaults for DB credentials or change if needed
- There is nothing to select for the Hosts as we unchecked “Backup Application Servers During Database Refresh” in the LaMa engine settings.
- In the Host Names screen, verify that the entries displayed are correct and if not change them
- In the Users screen, accept default as the users already exist.
- In the Rename screen, either accept defaults or if passwords differ from the Master then change them accordingly.
- In the isolation screen, select the default network access control list. During the initial configuration in LaMa these default rules are defined. Note that we made an adjustment to the fencing during configuration of the system in LaMa. If you need to make changes then you may do so here.
- Select “Unfence target system without confirmation”. You may also select the other two options based on your scenario. For unfencing without prompt users take full responsibility for unfencing the target.
- For PCA, you can add any task list variant that you may have created as well as any other task list you would like to execute, for example the BDLS task list with its improvements. In this example we kept the default.
- The activity should now run and progress bar will eventually reach 100%
We successfully performed a HANA single tenant database refresh using HANA replication. In addition we demonstrated how it can be done across different cloud providers. The same principle can be applied in a hybrid cloud environment to perform database refresh between on-premise datacenter and a public cloud environment.
Part 3: Using Backint Agents for AWS and GCP
Appendix
This section is an optional read and covers steps to create a VPN tunnel between Azure and AWS:
- In Azure, create a Virtual Network Gateway of type "VPN"
- You must have sufficient available address space to allow creation of a gateway subnet. This subnet will be created automatically as part of creating the virtual network gateway.
- If you don't have enough address space then modify your Vnet to allow for this
- Note down the public IP address after the gateway is created as we will need it on the AWS side
- Refer to https://azure.microsoft.com/en-us/pricing/details/vpn-gateway/ in choosing the SKU of the gateway to meet your bandwidth requirements
- I selected the lowest bandwidth as a starting point. The bandwidth can be changed at anytime afterwards from the virtual network gateway view.
- Note that the bandwidth of the VPN connection is dependent on the lowest bandwidth. For example if you choose 100Mbps on the Azure side and 1.25Gbps on the AWS side, your real bandwidth will be the lower value which is 100Mbps.
- Refer to https://azure.microsoft.com/en-us/pricing/details/vpn-gateway/ in choosing the SKU of the gateway to meet your bandwidth requirements
- In AWS, create a Virtual Private Gateway (VPG or VGW). Two tunnels are created by default and each has a bandwidth of 1.25 Gbps. There are options to increase the bandwidth further. Refer to https://aws.amazon.com/vpn/pricing/ for details.
- Attach the above to the VPC in AWS.
- In AWS, create a Customer Gateway (CGW). Choose static routing and enter the public IP address of virtual network gateway from the Azure side.
- As we are using pre-shared keys so we did not fill in the field for Certificate ARN or Device
- In AWS, create Site-to-Site VPN Connection. In the drop down select the VPG/VGW created previously.
- Choose static routing
- Add private IP address space for Azure Vnet -- e.g. 10.1.xx.xx/24 in my case
- Local IPv4 CIDR = 10.1.xx.xx/24 (Azure Vnet as above)
- Remote IPv4 CIDR = 172.xx.xx.xx/24 (AWS VPC private address space)
- Accept defaults for the tunnel options section
- After above is created, click on the "Download Configuration" button and keep the file in a safe place
- Choose Vendor = Generic
- Platform = Generic
- Software = Vendor Agnostic
- IKE version = 2
- The configuration template file has a section for each tunnel. Choose one of the sections for the information in the next steps. We will only bring up one tunnel for this lab exercise.
- Note down the Virtual Private Gateway address in the file under the heading of "Outside IP Addresses" (from the tunnel section you have decided to use)
- After above is created, click on the "Download Configuration" button and keep the file in a safe place
- From the same tunnel section, note down the pre-shared key
- In Azure, create a Local Network Gateway
- Virtual Private Gateway IP address from above is needed here
- In Azure, navigate back to the Virtual Network Gateway we created in step 1
- Select "Connections" from the gateway page
- Select "+Add"
- Name: Any name you choose
- Connection Type: Site-to-Site (IPsec)
- Virtual Network Gateway: Filled in already and should be the one you created and are currently navigated to
- Local network gateway: What you created in the previous step (in Azure)
- Share Key (PSK): From the config file
- IKE Protocol: IKEv2
- Do not check the boxes "Use Azure Private IP Address" and "Enable BGP"
- In a few minutes you should see the connected status as below.
- In AWS, modify the main route table for the VPC
- Traffic to VPC subnet is via local --> should already be in place
- Traffic to Azure Vnet is via the VGW (also call VPG) --> will need to be added (I used the address space of the Vnet that covers the gateway subnet and the subnet of the hosts)
- Traffic to everywhere else via the Internet GW --> should already be in place
