SAP HANA on Azure (Large Instances) compute, network, & storage (part 2)

 


To read part 1 please click here
To read part 3 please click here


ExpressRoute Fast Path

Microsoft is offering ExpressRoute Fast Path since May 2019 to optimize connectivity of HANA Large Instances to Azure virtual networks that host the SAP application VMs which helps in not routing the data to flow between VMs and HANA Large Instances through the ExpressRoute Gateway anymore. 

The ExpressRoute Fast Path functionality needs that the subnets running the SAP application VMs are in the same Azure virtual network that connects to the HANA Large Instances while the VMs located in Azure virtual networks connected directly to the HANA Large Instance units are not profitable through ExpressRoute Fast Path. Additionally, ExpressRoute Fast Path does not support User Defined Routing (UDR) rules and requires an UltraPerformance ExpressRoute gateway. 

Single & Multiple SAP Systems

Single SAP system

The ExpressRoute gateway for the VMs hosting the SAP application instances is connected to one ExpressRoute circuit which in turn connects to an on-premises network and then connects to a separate enterprise edge router dedicated to connecting to Large Instance stamps.

This system is simple an example of a single SAP system where the SAP application layer is hosted in Azure and it is assumed that the ExpressRoute gateway bandwidth of 2-Gbps or 10-Gbps throughput doesn't represent a bottleneck.

Multiple SAP system

If you deploy multiple SAP systems or large SAP systems to connect with SAP HANA on Azure (Large Instances), then the throughput of the ExpressRoute gateway may become a bottleneck. You may also want to create a special virtual network that can connect to HANA Large Instance for following cases:

  • Performing backups directly from the HANA Instances in HANA Large Instance to a VM in Azure that can host NFS shares.

  • Copying large backups or other files from HANA Large Instance units to disk space managed in Azure.  

For more scalable network architecture:

  • Leverage multiple virtual networks for a single, larger SAP application layer.

  • Deploy one separate virtual network for each SAP system deployed, as compared to combining these SAP systems in separate subnets under the same virtual network.

Depending on the rules and restrictions, you can easily apply between the different virtual networks hosting VMs of different SAP systems, and peer from those virtual networks. 

Routing in Azure

The following dictates the routing behavior of SAP HANA on Azure (Large Instances):

  • By default, SAP HANA on Azure (Large Instances) can be accessed only through Azure VMs and the dedicated ExpressRoute connection, not directly through on-premises.

  • If you deploy HANA Large Instance units in two different Azure regions for disaster recovery, the same transient routing restrictions are applied in the past i.e. IP addresses of a HANA Large Instance unit in one region were not routed to HANA large Instance unit deployed in another region.

  • SAP HANA on Azure (Large Instances) units always have an assigned IP address from the server IP pool address range that you submitted while requesting the HANA Large Instance deployment.

You should be also aware that the implementation and support for custom solutions involving third-party network appliances and IPTables isn't offered by Microsoft and the support must be provided by the vendor of the component used or the integrator. 



To read part 1 please click here
To read part 3 please click here




Comments

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

Work with String Data Using KQL Statements