Deploying HANA Large Instances (HLI) (part 2)

By Ashwin Venugopal -

 



To read part 1 please click here


ExpressRoute Global Reach

After creating an Azure virtual network, you will have to create an Azure ExpressRoute gateway on the virtual network which allows you to connect with the virtual network to the ExpressRoute circuit which in turn also links you to the customer tenant on the HANA Large Instance stamp. SAP HANA on Azure Large Instances supports only HighPerformance or UltraPerformance gateway SKUs and you must use the UltrPerformance Gateway SKU for HANA Large Instances of the Type II class SKU.

Link virtual networks

You have to use the authorization information provided by Microsoft to connect the ExpressRoute gateway with the SAP HANA Large Instances ExpressRoute circuit with the help of Azure portal or PowerShell. You must use a connection-specific AUTHGUID which is specific for every virtual network and its gateway. 

You can also use the ExpressRouteGatewayBypass parameter while running the PowerShell script which readily enables ExpressRoute Fast Path (the functionality added in May, 2019) that helps in the reduction of network latency between your HANA Large Instance units and Azure VMs. 

If you want to connect the gateway to more than one ExpressRoute circuit of your subscription, then, you will have to perform this step more than once.

ExpressRoute Global Reach

To enable the Global Reach in the following scenarios:
  • HANA System Replication without any proxies or firewalls.
  • Copying backups between HANA Large Instance units in two different regions to perform system copies or system refreshes.  

You should consider the following:

  • You have to provide an address space range of a /29 address space which should - not overlap with the other address space ranges used for connecting HANA Large Instances to Azure as well as not overlap with any of your IP address ranges used somewhere else in Azure or on-premise.

  • ASNs (Autonomous System Number) which is used to advertise your on-premises routes to HANA Large Instances has a limitation that it does not advertise any routes with private ASNs in the range of 65000-65020 or 65515.

  • In the scenarios having direct access from on-premises to HANA Large Instances, it account for the cost of the circuit that connects on-premises networks to Azure. 

If you want to implement one or both the scenarios in your deployment, you will have to raise a request with Azure support.

Note- To handle both cases, you have to supply two different /29 IP address ranges that do not overlap with any other IP address used so far.

Validating SAP HANA on Azure (Large Instances)

Before HANA installation, you have to validate the following:
  1. HLI unit(s)
  2. Operating system configuration
  3. Network configuration
  4. Storage configuration

Firstly, you have to register the OS of the instance with your OS provider after receiving the HANA Large Instance and establish access as well as connectivity to the instances according to your usage of SUSE or Red Hat Subscription Manager. This step is mandatory for patching the OS, which is the responsibility of the customer.

Secondly, you have to check for new patches and fixes of the specific OS release/version while verifying the patch level of the HANA Large Instance is in the latest state as there are some cases where the latest patches aren't included. Thus, it is mandatory to check whether the patches are required to be applied or not after acquiring a HANA Large Instance unit.

Next, check out the relevant SAP notes for installing and configuring SAP HANA on the specific OS release/version. It's highly important to read the SAP notes related to SAP HANA for your exact Linux release thoroughly as a customer while also checking as well as applying the configurations of the OS release/version.

Fourthly, check the system time of your HANA Large Instance unit as the instances are deployed with a system time zone that represents the location of the Azure region in which the HANA Large Instance stamp is located. 

Lastly, as the blades get handed over, they always have different IP addresses that are assigned for different purposes hence, you have to check the etc/hosts file. As a customer, it's your responsibility to toe ensure that a newly deployed instance can easily interact and resolve the names of the units that you deployed earlier in your tenant because etc/hosts of the newly deployed systems cannot be maintained correctly automatically with the IP addresses of systems that were delivered earlier if the units are added into an existing tenant.  

Install HANA on SAP HANA on Azure (Large Instances)

After the successful completion of the validation tasks, it is your responsibility to install a new SAP HANA on Azure (Large Instances) server after establishing the connectivity between your Azure virtual networks and the HANA Large Instance unit(s).

Note- The installation of SAP HANA should be done by a Certified SAP Technology Associate exam, SAP HANA Installation certification exam pass-out, or who is a SAP certified System Integrator (SI) as per SAP policy. 

After the successful completion of the installation, the SAP HANA Instance will be up and running, and ready for usage, allowing you to connect it from SAP HANA Studio. 





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