Maintaining Azure for SAP Workloads (part 2)

By Ashwin Venugopal -

 



To read part 1 please click here


Remote Management of SAP HANA on Azure (Large Instances)

Connecting to Azure HANA on Azure (Large Instances) from Azure VMs & from on-premises locations

As we all know that, by default, the transitive routing between HANA Large Instance units and on-premises doesn't work, hence you can connect to HANA Large Instances from the same virtual network that hosts the application Azure VMs or you can also allow transitive routing with the help of following methods:

  • A reverse proxy to route data, to and from SAP HANA on Azure (Large Instances) which can be for example, F5 BIG-IP or NGINX with Traffic Manager deployed in the Azure virtual network.

  • IPTables rules in a Linux VM can be used to enable routing between on-premises locations and HANA Large Instance units, or between HANA Large Instance units in different regions. But, the VM size should be accordingly, so that the network throughput of the VM is appropriate for the expected network traffic.

  • Azure Firewall must be used to guide traffic between on-premises and HANA Large instance units.

If you are using reverse proxy, IPTables, or Azure Firewall, traffic routed through an Azure virtual network could also be filtered by Azure Network Security Groups, so that certain IP addresses or IP address may vary from on-premises could be blocked or especially enabled to access HANA Large Instances. 

Managing Azure HANA on Azure (Large Instances) via the Azure portal

You can click on any of the blade listing HANA Large Instance units entries in the Azure portal to get to the blade displaying details of the corresponding single HANA Large Instance unit. There are a number of information pieces available like the name of the unit, its operating system, its IP address, the ExpressRoute Circuit ID, the unit type with the number of CPU threads and memory as well as the IP address of the NFS endpoint providing storage for the unit.

The information about the power state is also available which indicates if the hardware unit is powered on or off instead of the state of operating system. You can also review the recorded restart activities which may include the status of the activity, the times-tamp of its trigger, the subscription ID of the trigger, and the Azure AD identity initiating the trigger.

The other types of recorded activities may include changes to metadata associated with the individual units which is recorded as Write HANAInstances and has no impact on the operational state of the HANA Large Instance unit, but by default, they have no tag assigned.

Restart a HANA Large Instance unit through Azure portal

The restarting of the Linux operating system of a HANA Large Instance unit may sometimes not be completely successful, but the power restart function of HANA Large Instance unit is available directly from the Azure portal whose button can be readily seen in the overview section of the HANA Large Instance unit in the Azure portal.

In accordance with the the amount of memory of the HANA Large Instance unit, a restart and reboot of the hardware as well as the operating system can take up to one hour.

Register HANA Large Instance Resource Provider

Generally, the Azure subscription being used for Azure Large Instance deployments includes registration of the HANA Large Instance Resource Provider, but, if the deployed HANA Large Instance units can't be seen, then you must register the Resource Provider in your Azure subscription which can be easily done with the help of Azure CLI and the Azure portal.

Register through CLI interface

If you want to register, you should start by signing in to your Azure subscription consisting the HANA Large Instance deployment through the Azure CLI. After that, you can invoke the registration by running the following:

az provider register --namespace Microsoft.HanaOnAzure 

Register through Azure portal

If you want to register the hANA Large Instance Resource Provider through the Azure portal, then you have to display the blade representing the Azure subscription, which was used to deploy the HANA Large Instance unit(s). On that blade, you have to select the "Resource Providers" and type "HANA" in the search text box. After that, you have to click the "re-register" or "register" in the list of results.





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