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

By Ashwin Venugopal -

 


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

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more