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

 


To read part 2 please click here
To read part 3 please click here


Compute Considerations

A compute unit can equal one server or blade, and a stamp is made up of multiple servers or blades in which servers are not shared but are dedicated to running one customer's deployment of SAP HANA. A variety of SKUs are available for HANA Large Instances while supporting up to 20 TB single instance of memory for S/4 HANA or other SAP HANA workloads. Two classes of servers are provided:
  • "Type I class" of SKUs consisting of S72, S72m, S96, S144, S144m, S192, S192m, and S192xm.
  • "Type II class" of SKUs consisting of S384, S394m, S384xm, S384xxm, S576m, S576xm, S768m, S768xm, and S960m.

As the data volume grows the memory requirement for HANA increases. You should be aware of your current memory consumption so you can predict its future. According to the memory requirements, you can map your demands into one of the HANA Large Instance SKUs. 

Storage Considerations

Storage layout is always implemented according to the recommendation of the TDI for SAP HANA and HANA Large Instances generally comes with a specific storage configuration for the standard TDI specifications. If you want to support the requirements of mission-critical environments including fast recovery, NFS is used not the direct attached storage. However, if you want to support high availability at the primary site, you can use different storage layouts.

The storage used in HANA Large Instances has a file size limitation of 16 GB which contradictory to the file size limitations in the EXT3 file systems, but HANA is not at all aware of the storage limitation enforced by HANA Large Instances storage which results in HANA not creating a new data file when the file size limit of 16TB is reached. 

If you want to protect HANA from growing data files beyond the file size limit of 16 TB of HANA Large Instance storage, you should set the following parameters in the global.ini configuration file of HANA

  • datavolume_striping = true  
  • datavolume_striping_size_gb = 15000

Networking Considerations

This architecture make use of both virtual as well as physical network. The virtual network is part of Azure IaaS and connects to a discreet HANA Large Instances physical network through ExpressRoute Circuits. The following components are used for the Azure network functionality:
  • Azure virtual networks connected to the ExpressRoute circuit that also connects to your on-premises network assets.

  • An ExpressRoute circuit that connects on-premises to Azure, has bandwidth of 1 Gbps or higher and this circuit is fully paid by you as a customer. 

  • All SAP systems in Azure set up in virtual networks to communicate with each other. 

  • AD and DNS hosted on-premises extended into Azure through ExpressRoute from on-premises or running entirely in Azure.

  • An ExpressRoute circuit that connects SAP HANA Large Instances into the Azure data center network fabric which is deployed and handled by Microsoft.

  • An Azure ExpressRoute gateway connects a virtual network to ExpressRoute circuits and a maximum of four different ExpressRoute circuits can be connected if those connections comes from different Microsoft enterprise edge routers.

  • Networking within the HANA Large Instance stamp is mostly transparent for you.

For HANA Large Instance Type II SKUs, only the UltraPerformance  gateway SKU is supported as an ExpressRoute gateway. Exceptions apply while using ExpressRoute Fast Path.


To read part 2 please click here
To read part 3 please click here



Comments

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

Work with String Data Using KQL Statements

Threat Hunting in Microsoft Sentinel (part 1)