Introduction
This document provides Customers a brief description of networking solution for connecting customers from any location to Azure, leveraging our customers with the leading national and international network providers.
A single hardware failure is mitigated by a Fabric Controller which manages resource allocation, automatically failing-over to a different machine or cluster. Hardware management is transparent to the customer. Without additional configuration, data is protected by locally redundant storage, which maintains multiple replicas of data within a single region. If geo-replication for the virtual machine is configured, that geo-replication provides redundancy of data across regions to help ensure access to data in the event of a local disaster.
Network infrastructure and components are similarly redundant, with N+1 links to regional TelCos, load balancers, and routing switch fabric.
SAP on Azure is a very popular workload. As customers look to deploy their production SAP systems on Azure it is important to consider proper network design to ensure performance. This document will walk you through how to optimally connect to the Microsoft network for SAP and SAP HANA Large Instance.
Latency Optimization
The solution facilitates a seamless, fast migration to SAP on Azure, based on a secure, highly available, performant, and resilient connectivity solution covered by an end-to-end SLA.
When deploying enterprise applications such as SAP in Azure it is important to know the different connectivity methods used with the Microsoft network.
The most common way to interface with applications hosted in Azure is to connect via the Internet. Microsoft today interconnects with Internet Service Providers in over 150 locations around the world. Microsoft provides more than 80 percent of global GDP (Gross Domestic Product) with an experience of sub-30 milliseconds latency.
The most common way to interface with applications hosted in Azure is to connect via the Internet. Microsoft today interconnects with Internet Service Providers in over 150 locations around the world. Microsoft provides more than 80 percent of global GDP (Gross Domestic Product) with an experience of sub-30 milliseconds latency. We are adding new edges every week, and our ambition is to provide this level of performance to all of global audience.
When using Internet connectivity to access SAP applications customers can either leverage Microsoft VPN Gateway or Azure Virtual WAN. VPN Gateway allows customers to establish an IPSEC tunnel from an on-premise device to Azure directly over the internet.
Prerequisite
- Azure Subscription
- Basic Azure knowledge
- SAP knowledge
- Administrator Access
- PowerShell (Good to have)
- Understanding of SAP HANA administration
Definition
Throughout the document, these terms are used:
- IaaS - Infrastructure as a service.
- PaaS - Platform as a service.
- SaaS - Software as a service.
Contents
- Introduction
- Prerequisite
- Definition
- Document Approval
- Revised History
- Abstract
- Complexity
- Comparison
- Azure approach on SAP Connectivity Requirement
- Azure ExpressRoute Challenge
- Architecture
- Highlights Networking architecture for HANA Large Instance
- The differences to SAP deployments in Azure
- HANA Large Instance units in multiple regions
- Conclusion
Abstract
This response document helps address standard Requests for Information (RFI) with which IoTCoast2Coast empower customers to evaluate different offerings in the market place today. Through the mappings available in the CCM, we can illustrate how Azure has implemented security and privacy controls aligned to other international standards such as ISO/IEC 27001, US Government frameworks including FedRAMP, and industry certifications such as PCI DSS.
Complexity
A cloud-specific controls framework such as the Cloud Control Matrix (CCM) reduces the risk of an organization failing to consider important factors when selecting a cloud provider. The risk is further mitigated by relying on the cumulative knowledge of industry experts who created the framework, and taking advantage of the efforts of many offerings.
Comparison
For organizations that do not have detailed knowledge about the different ways that cloud providers can develop or configure their offerings, reviewing a fully developed framework can provide insight into how to compare similar offerings and distinguish between providers. A framework can also help determine whether a specific service offering meets or exceeds compliance requirements and/or relevant standards.
Azure approach on SAP Connectivity Requirement
Both Azure and the underlying Microsoft Cloud and Infrastructure Operations (MCIO) physical environments employ Network frameworks that span multiple best standards.
Let’s enable a wide range of enterprise and consumer services with a highly available, secure, and agile network
Azure ExpressRoute Challenge
Azure ExpressRoute is the recommended Azure networking service to create a private connection between an on-premises network and Azure virtual networks, bypassing the public Internet (see reference architecture). This is applicable to both SAP S/4HANA as well as SAP HANA on Azure Large Instances deployments.
ExpressRoute enables the initial migration of the data estate, as well as the ongoing secure data transfer between your SAP on Azure solution and applications remaining in your enterprise data center. Most organisations in Northern Europe deploy their SAP on Azure solutions on the Azure West Europe multi-zone region located in The Netherlands.
There are couple of ExpressRoute nodes available in North America, offers <0.5 millisecond latency to SAP Hana on Azure and Large Instances. To safeguard performance of SAP HANA in-memory databases, latency and jitter should be considered when designing connectivity solution.
As physical distance directly impacts latency and jitter, it’s recommended for customers planning to transfer large data volumes and customers running hybrid cloud architectures to consider it seriously.
![Build Azure Network Foundation]()
Reference architecture
Architecture
Let's This reference architecture describes an enterprise-grade, production-level system. To suit your business needs, this configuration can be reduced to a single virtual machine. However, the following components are required,
Virtual network
The Azure Virtual Network service securely connects Azure resources to each other. In this architecture, the virtual network connects to an on-premises environment through a gateway deployed in the hub of a hub-spoke topology. The spoke is the virtual network used for the SAP applications.
Subnets
The virtual network is subdivided into separate subnets for each tier: gateway, application, database, and shared services.
Virtual machines
This architecture uses virtual machines running Linux for the application tier and database tier, grouped as follows:
Application tier
Includes the Front-end Server pool, SAP Web Dispatcher pool, application server pool, and SAP Central Services cluster. For high availability of Central Services on Azure Linux virtual machines, a highly available Network File System (NFS) service is required.
NFS cluster
This architecture uses an NFS server running on a Linux cluster to store data shared between SAP systems. This centralized cluster can be shared across multiple SAP systems. For high availability of the NFS service, the appropriate High Availability Extension for the selected Linux distribution is used.
SAP HANA
The database tier uses two or more Linux virtual machines in a cluster to achieve high availability. HANA System Replication (HSR) is used to replicate contents between primary and secondary HANA systems. Linux clustering is used to detect system failures and facilitate automatic failover. A storage-based or cloud-based fencing mechanism can be used to ensure the failed system is isolated or shut down to avoid the cluster split-brain condition.
Jumpbox
Also called a bastion host. This is a secure virtual machine on the network that administrators use to connect to the other virtual machines. It can run Windows or Linux. Use a Windows jumpbox for web browsing convenience when using HANA Cockpit or HANA Studio management tools.
Load balancers
Both built-in SAP load balancers and Azure Load Balancer are used to achieve HA. Azure Load Balancer instances are used to distribute traffic to virtual machines in the application tier subnet.
Availability sets
Virtual machines for all pools and clusters (Web Dispatcher, SAP application servers, Central Services, NFS, and HANA) are grouped into separate availability sets, and at least two virtual machines are provisioned per role. This makes the virtual machines eligible for a higher service level agreement (SLA).
NICs
Network interface cards (NICs) enable all communication of virtual machines on a virtual network.
Network security groups
To restrict incoming, outgoing, and intra-subnet traffic in the virtual network, network security groups (NSGs) are used.
Gateway
A gateway extends your on-premises network to the Azure virtual network. ExpressRoute is the recommended Azure service for creating private connections that do not go over the public Internet, but a Site-to-Site connection can also be used.
Azure Storage
To provide persistent storage of a virtual machine's virtual hard disk (VHD), Azure Storage is required.
Highlights Networking architecture for HANA Large Instance
The networking architecture for HANA Large Instance can be separated into four different parts,
On-premises networking and ExpressRoute connection to Azure. This part is the customer's domain and is connected to Azure through ExpressRoute. This Expressroute circuit is fully paid by you as a customer. The bandwidth should be large enough to handle the network traffic between your on-premise assets and the Azure region you are connecting against. See the lower right in the following figure.
Azure network services, as previously discussed, with virtual networks, which again need ExpressRoute gateways added. This part is an area where you need to find the appropriate designs for your application requirements, security, and compliance requirements. Whether you use HANA Large Instance is another point to consider in terms of the number of virtual networks and Azure gateway SKUs to choose from. See the upper right in the figure.
Connectivity of HANA Large Instance through ExpressRoute technology into Azure. This part is deployed and handled by Microsoft. All you need to do is provide some IP address ranges after the deployment of your assets in HANA Large Instance connect the ExpressRoute circuit to the virtual networks. For more information, see SAP HANA (Large Instances) infrastructure and connectivity on Azure. There is no additional fee for you as a customer for the connectivity between the Azure data center network fabric and HANA Large Instance units.
Networking within the HANA Large Instance stamp, which is mostly transparent for you.
The differences to SAP deployments in Azure
- The HANA Large Instance units of your customer tenant are connected through another ExpressRoute circuit into your virtual networks. To separate load conditions, the on-premises to Azure virtual network ExpressRoute circuits and the circuits between Azure virtual networks and HANA Large Instances don't share the same routers.
- The workload profile between the SAP application layer and the HANA Large Instance is of a different nature, with many small requests and bursts like data transfers (result sets) from SAP HANA into the application layer.
- The SAP application architecture is more sensitive to network latency than typical scenarios where data is exchanged between on-premises and Azure.
- The Azure ExpressRoute gateway has at least two ExpressRoute connections. One circuit that is connected from on-premise and one that is connected from HANA Large Instances. This leaves only room for another two additional circuits from different MSEEs to connect to on ExpressRoute Gateway. This restriction is independent of the usage of ExpressRoute Fast Path. All the connected circuits share the maximum bandwidth for incoming data of the ExpressRoute gateway.
HANA Large Instance units in multiple regions
To realize disaster recovery set ups, you need to have SHANA Large Instance units in multiple Azure regions. Even with using Azure [Global Vnet Peering], the transitive routing by default is not working between HANA Large Instance tenants in two different regions. However, Global Reach opens up the communication path between the HANA Large Instance units you have provisioned in two different regions. This usage scenario of ExpressRoute Global Reach enables,
- HANA System Replication without any additional proxies or firewalls
- Copying backups between HANA Large Instance units in two different regions to perform system copies or system refreshes.
The figure shows how the different virtual networks in both regions are connected to two different ExpressRoute circuits that are used to connect to SAP HANA on Azure (Large Instances) in both Azure regions.
Conclusion
The Whether you choose to reach the Microsoft cloud / Azure through the Internet or through a private network, IoTCoast2Coast is committed to provides it’s customers to build the fastest and most reliable global network of any public cloud. Microsoft continue innovating and investing in a globally distributed networking platform to enable high performance, low latency, and the world’s most reliable cloud.
IoTCoast2Coast will continue to provide you with the best possible network experience, wherever in the world you happen to be.