Deploying HANA Large Instances (HLI) (part 1)

By Ashwin Venugopal -

 



To read part 2 please click here


Connecting Azure VMs to HANA Large Instances

According to the networking point of view, you have to provide the following information:

  • The definition of an Azure virtual network into which you will deploy the VMs of the SAP application layer. 

  • The definition of a Default subnet in the Azure virtual network into which the VMs are deployed.

  • The created Azure virtual network should have at least one VM subnet and one Azure ExpressRoute virtual network gateway subnet.

Create the Azure virtual network for HANA Large Instances

The Azure virtual network for HANA Large Instances can be created with the help of Azure Resource Manager deployment model. Summary of the important facts of an Azure virtual network that connects to HANA Large Instances is as follows:

  • You have to submit the virtual network address space to Microsoft if you are performing an initial deployment of HANA Large Instances.

  • The virtual network address space should be of large range that can cover the entire ranges for both the subnet IP address range of the Azure VM and the virtual network gateway. 

  • On the contrary, you can also submit multiple ranges that covers the different IP address ranges of VM subnet IP address range(s) and the virtual address gateway IP address range. 

  • The defined virtual network address space is used for BGP routing propagation.

  • The name of the gateway subnet must be: "GatewaySubnet".

  • The address space should be used as a filter on the HANA Large Instance side to allow or disallow traffic to the HANA Large Instance units from Azure. Connectivity issues may occur if the BGP routing information of the Azure virtual network and the IP address ranges that are configured for filtering on the the HANA Large Instance side aren't matched. 

Different IP address ranges to be defined

The following IP address ranges should be defined before sending a request for initial deployment:

  • Virtual network address space: It is the IP address range that you assign to your address space parameter in the Azure virtual networks that can be connected to the SAP HANA Large Instance environment. It should not overlap with your on-premises or server IP pool or ER-P2P address ranges and must be submitted to Microsoft whenever you ask for an initial deployment.

  • Azure VM subnet IP address range: This range is assigned to the Azure virtual network subnet parameter which is in your Azure virtual network and connects to the SAP HANA Large Instance environment. It is used to assign IP addresses to your Azure VMs , but the IP addresses outside this range are allowed to connect to your SAP HANA Large Instance server(s). 

  • Virtual network gateway subnet IP address range: According to the features you use, the recommended size is-
  1. Ultra-performance ExpressRoute gateway: /26 address block- needed for Type II class of SKUs.
  2. Coexistence with VPN & ExpressRoute using a high-performance ExpressRoute virtual network gateway (or smaller): /27 address block.
  3. All other situations: /28 address block. 

  • Address range for ER-P2P connectivity: It is the IP range of your SAP HANA Large Instance ExpressRoute (ER) P2P connection and its IP addresses must be of /29 CIDR IP address range. This range helps in the setting up of the ER connectivity from your ExpressRoute virtual gateway to the SAP HANA Large Instance servers and should be submitted to Microsoft whenever you ask for an initial deployment.

  • Server IP pool address range: It helps in assigning the individual IP address to HANA Large Instance servers and its subnet size is of /24 CIDR block or smaller. The first 30 IP addresses are always reserved for use by Microsoft and this range should not overlap with your on-premises or other Azure IP addresses as well as should be submitted to Microsoft whenever you ask for an initial deployment.  

After defining the IP address ranges, the following things should happen:

  • You have to submit the IP address ranges for the Azure virtual network address space, the ER-P2P connectivity, as well as server IP pool address range, along with the other data that's listed at the beginning. You can also start to create the virtual network and the VM subnets.

  • Microsoft creates an ExpressRoute circuit between your Azure subscription and the HANA Large Instance stamp.

  • A tenant network is created on the Large Instance stamp by Microsoft. 

  • Microsoft can configure the SAP HANA on Azure Large Instances infrastructure to accept IP addresses from your Azure virtual network address space that communicates with HANA Large Instances.

  • In accordance with the specific SAP HANA on Azure Large Instances SKU that you bought, Microsoft offers a compute unit in a tenant network while allocating and mounting storage as well as installing the OS (SUSE or Red Hat Linux).   

In the end, Microsoft delivers the following data to you:

  1. Information that's required for connecting your Azure virtual network(s) with the ExpressRoute circuit that connects Azure virtual networks to HANA Large Instances-

  • Authorization Key(s)
  • ExpressRoute PeerID

      2. Data for accessing HANA Large Instances after you establish ExpressRoute circuit as well as                  Azure virtual network. 




To read part 2 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

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more