AzureStack HCI

Application Version Details

Introduction

Azure Stack HCI is a virtualized workload solution from Microsoft that allows businesses to run Windows and Linux apps and services in a hybrid on-premise/cloud environment. Built on top of Windows Server, Azure Stack HCI is an example of hyper-converged infrastructure (HCI). This technology virtualizes conventionally hardware-defined systems like storage and networking to create flexible, efficient infrastructure solutions.

Key Use cases

Discovery Use cases

• It discovers the AzureStack HCI components.
• Publishes relationships between resources to have a topological view and ease of maintenance.

Monitoring Use cases

• Provides metrics related to job scheduling time and status etc..
• Concern alerts will be generated for each metric to notify the administrator regarding the issue with the resource.

Prerequisites

• OpsRamp Classic Gateway 14.2.0 and above.

• OpsRamp NextGen Gateway 14.2.0 and above

  Note: We recommend using the latest Gateway version for full coverage of (Recent bug fixes, enhancements.. etc)

• For powershell cmdlets the following are prerequisites:

  • Windows domain User should be able to do powershell remoting:
    Enable-PSRemoting -Force
  • Windows domain user should be added to Remote Management users group:
    net localgroup "Remote Management Users" /add <user>
  • Windows domain user should be added to Performance monitor users group:
    net localgroup "Performance monitor users" /add <user>
  • Add OpsRampGatewayIP to the TrustedHosts list on the target machine to allow the powershell connection from the gateway to the target machine.
  • To add TrustedHosts use the following command:
    • To allow any host:
      Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Value *
    • To allow a specific host:
      Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Concatenate -Value <OpsRampGatewayIp>
  • Setup and restart the WinRM service for the changes to reflect
    • To set up: Set-Service WinRM -StartMode Automatic
    • Restart using: Restart-Service -Force WinRM

• Granting remote DCOM Rights

  • To grant the user DCOM rights, log on to each system to be monitored and complete the following procedure:
    1. Go to Command Prompt and enter dcomcnfg.
    2. Navigate to Component Services > Computers > My Computer, right click and click Properties.
    3. Go to COM Security tab.
    4. Under Access Permissions, go to Edit Limits and click Add to enter the domain non-admin user and enable both Local and Remote access.
    5. Click OK.
    6. Under Launch and Activation Permissions, go to Edit Limits, click Add to enter the domain non-admin user and check all boxes.
    7. Click OK.

• Granting Remote WMI Rights

  • To give the user remote WMI rights, log on to each system to be monitored and complete the following procedure:
    1. Go to Computer Management > Services and Applications > WMI Control.
    2. Right-click on WMI control and go to Properties > Security tab.
    3. Select Root and click the Security button.
    4. Click Add to enter the domain non-admin user, and check the boxes for Execute Methods, Enable Account, Remote Enable, and Read Security.
    5. Click Advanced and select the added non-admin domain user.
    6. Click Edit > Applies to and select This namespace and subnamespaces from the dropdown listbox.
    7. Click OK thrice.

• For monitoring services like the Windows Cluster Service and other MSSQL services (SQL Server, SQL Agent, SQL Browser, etc.), you would require the Windows domain user to be a part of the ‘Local Administrators group’ as we are using the ‘Win32_Service’ class for fetching the details.

  Refer Microsoft Igniteto

• If you do not want to add the user to the local administrator group, you can also use “Security descriptors” for monitoring the services. To do this, you need to configure as follows:
  Refer Enable Windows Service Monitoring section of the documentation.

• Windows domain user should be granted read-only access to Cluster:
  Grant-ClusterAccess -User <domain\user> -Readonly

Hierarchy of Azure Stack HCI Resources

• Azure stack HCI Cluster
  • Azure stack HCI Server
    • Azure stack HCI Virtual Switch
    • Azure stack HCI Node Disk
    • Azure stack HCI Guest Virtual Machine
  • Azure stack HCI Cluster Role
  • Azure stack HCI Cluster Disk
  • Azure stack HCI Cluster Shared Volume

Supported Metrics

Default Monitoring Configurations

AzureStack HCI has default Global Device Management Policies, Global Templates, Global Monitors and Global metrics in OpsRamp. You can customize these default monitoring configurations as per your business use cases by cloning respective Global Templates and Global Device Management Policies. OpsRamp recommends performing the below activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   OpsRamp has a Global Device Management Policy for each Native Type of AirWave Management Platform. You can find those Device Management Policies at Setup > Resources > Device Management Policies, search with suggested names in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: azure-stack-hci Azure stack HCI Cluster - 1 (i.e, appName = azure-stack-hci, nativeType = Azure stack HCI Cluster, version = 1)

2. Default Global Templates

   OpsRamp has a Global template for each Native Type of AirWave Management Platform. You can find those templates at Setup > Monitoring > Templates, search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: aruba-airwave Azure stack HCI Cluster Template - 1 (i.e, appName = aruba-airwave , nativeType = Azure stack HCI Cluster, version = 1)

3. Default Global Monitors

   OpsRamp has a Global Monitors for each Native Type which has monitoring support. You can find those monitors at Setup > Monitoring > Monitors, search with suggested names in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: Azure stack HCI Cluster Monitor azure-stack-hci Azure stack HCI Cluster 1 (i.e, monitorKey = Azure stack HCI Cluster Monitor, appName = azure-stack-hci , nativeType = Azure stack HCI Cluster, version= 1)

Configure and Install the AzureStack HCI Integration

1. From All Clients, select a client.
2. Navigate to Setup > Account.
3. Select the Integrations and Apps tab.
4. The Installed Integrations page, where all the installed applications are displayed. If there are no installed applications, it will navigate to the Available Integrations and Apps page.
5. Click + ADD on the Installed Integrations page. The Available Integrations and Apps page displays all the available applications along with the newly created application with the version.
   Note: Search for the application using the search option available. Also you can use the All Categories option to search.

6. Click ADD in the Azure Stack HCI Cluster application.
7. In the Configurations page, click + ADD. The Add Configuration page appears.
8. Enter the below mentioned BASIC INFORMATION:

Notes:

• By default the Is Secure checkbox is selected.
• IP Address/Host Name and Port Should be accessible from Gateway.
• App Failure Notifications: if turned on, you will be notified in case of an application failure that is, Connectivity Exception, Authentication Exception.

9. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

10. In the RESOURCE TYPE section, select:

    • ALL: All the existing and future resources will be discovered.
    • SELECT: You can select one or multiple resources to be discovered.

11. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:

    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly

12. Click ADD.

Now the configuration is saved and displayed on the configurations page after you save it.
Note: From the same page, you may Edit and Remove the created configuration.

13. Click NEXT
14. Below are the optional steps you can perform on the Installation page.

• Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

  Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

• Click +ADD to create a new collector by providing a name or use the pre-populated name.

15. Select an existing registered profile.

16. Click FINISH.

The integration is installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed integration.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the Azure Stack HCI Cluster application.

View the Azure Stack HCI Cluster Details

The Azure Stack HCI Cluster integration is displayed in the Infrastructure > Resources > Cluster. You can navigate to the Attributes tab to view the discovery details and Metrics tab to view the metric details for Azure Stack HCI.

View resource metrics

To confirm Azure Stack HCI Cluster monitoring, review the following:

• Metric graphs: A graph is plotted for each metric that is enabled in the configuration.
• Alerts: Alerts are generated for metrics that are configured as defined for integration.

Resource Filter Input keys

Azure Stack HCI app Resources are filtered and discovered based on below keys.

Supported Alert Custom Macros

Customise the alert subject and description with below macros then it will generate alert based on customisation.

Risks, Limitations & Assumptions

• For Cluster object discovery and monitoring implementation, we are considering the object which has Name equals to Cluster Name in Get-ClusterResource response
• For ClusterGroup monitoring implementation, We are considering the object which has name as Cluster Group in Get-ClusterGroup response
• Application can handle Critical/Recovery failure notifications for below two cases when user enables App Failure Notifications in configuration:
  • Connectivity Exception
  • Authentication Exception
• Application will not send any duplicate/repeat failure alert notification until the already existing critical alert is recovered.
• If user enables agent monitoring templates on the Cluster/Node resource, the user might see the duplicate metrics with different naming conventions.
• While trying to fetch the node ip address we receive multiple node ips, which will include many local ips and actual ips (example: let’s consider actual node ip is 10.1.1.1 when trying to fetch the details we will receive two ips one associated with cluster (192.168.0.0) and other is the actual ip). To identify the actual node ip address from the list of ip addresses received we assume that node ip address is part of the same subnet of cluster ip address. meaning if cluster ip is 10.1.1.1 then node ips will be 10.1.X.X.
• We have provided the provision to give Cluster Ip Address OR HostName in configuration, but hostName provision will work only if the host name resolution works.
• Classic gateway requires additional libraries to be packaged which are needed to execute the powershell script to achieve this integration approach.
• This application supports only Classic Gateway and NextGen Gateway. Not supported with Cluster Gateway.
• No support of showing activity log and applied time.
• Component level thresholds can be configured on each resource level.
• Optional configuration parameters can be defined
• Application upgrade is an automated process with version change.