NetApp ONTAP

Introduction

NetApp ONTAP

ONTAP has evolved from NetApp’s original operating system. It is most popular and widely-deployed operating system.

The different platforms that it can run on now are FAS, AFF, ONTAP Select, Cloud Volumes ONTAP, and NetApp Private Storage.

The different platforms run on hardware or virtual machine, and on premises or in the cloud.

NetApp ONTAP Architecture:

Cluster, Cluster Nodes and Disks

An ONTAP cluster can be as small as a single node cluster. Running a single node cluster means actually losing the access to data if the node fails. Simply it is not redundant.

To be redundant we can add another node to the existing cluster to form a HA-Pair. The two nodes which are connected in HA-Pair share a single disk. If we run a HA-Pair then we will have HA-Interconnect. This HA-Interconnect mirrors the NVRAM between these two nodes. So if one of the node fails then the other node can take over the aggregates of the failed node. Thus, there will be no loss of data even if one of the node fails. We have a network called Cluster Interconnect. The Cluster Interconnect is used for heartbeat configuration management and volume data between the cluster nodes.

A cluster node can be scaled out by connecting one or more HA-Pairs to the same cluster. Each HA-pair should be connected to Cluster Interconnect and each HA-pair contains individual HA_Interconnect.

Based on the protocols we use the maximum number of HA-Pairs and can be configured as follows:

• NAS : 12 HA-Pairs (24 Nodes)
• SAN : 6 HA-Pairs (12 Nodes)

Aggregates, Volumes and SVMs

Client data and configuration data in ONTAP is stored in volumes, and volumes are always a part of an aggregate. Aggregate is a collection of disks. Each node contains only one root aggregate, but we can have multiple data aggregates per node. In the case of node failure the surviving node will take over the aggregates of the failed node by default. In case of single HA-Pair the aggregates will be given back automatically after the failed node is up and running again.

There is a very important volume called root volume typically named as vol0, which is located in root aggregate. This volume is a node volume which contains cluster configurations and log files. So every node contains a volume named vol0.

A cluster always runs virtual machines. SVMs are logical representation of one of four types. They are:

1. System Type (Cluster SVM) : We have only one such type of SVM in the cluster. This SVM is used to manage the cluster Inter-Connect interfaces.

2. Node Type (Node SVM) : Each node in the cluster is represented as a node SVM.

3. Admin Type (Cluster Management SVM) : Usually connect to this type of SVM when we want to manage the cluster. Basically it represents the cluster.

4. Data Type : Depending on the number of nodes and protocols we use we can have upto a maximum of 1000 SVMs of this type. These type of SVMs are used to represent data towards our NAS and SAN clients. The data of the SVMs is stored in volumes. All the volumes belonging to a particular data SVM are a part of namespace of that particular SVM. Therefore, the namespace of a data SVM contains all of its data volumes. A data SVM contains exactly one root volume. This is a very small volume of 1GB commonly used to manage data volumes. This root volume should never contain data and the only information available from the root volume is junction paths of the connected data volumes. In a NAS environment the volumes have to be managed, otherwise they are not accessible by the clients.

LUNs and QTrees

A LUN is the logical representation of storage in a storage area network (SAN). In ONTAP, a LUN is located within a volume. Optionally, it can be located within a Qtree in a volume.

A Qtree is a logically defined file system that can exist as a special subdirectory of the root directory within a FlexVol volume or a FlexGroup volume.

Resource Hierarchy:

NetApp Cluster
— Cluster Nodes
    — Aggregates
    — Storage Ports
    — Ethernet Ports
      — Logical Interfaces(LIF’s)
    — FCP Adapters
      — FC Interfaces
— Storage Virtual Machine/SVM
    — Storage Volumes
        — Storage Luns
        — QTrees
— Disks
    — Shelves
Metro Cluster
    — Metro Cluster Nodes

Prerequisites

Transport Layer Security (TLS) must be enabled on the NetApp Cluster.

To check the TLS status:

SSH username@hostname
system services web show

If TLS is not enabled: tls.enable on

Example output:

External Web Services: true
               Status: online
   HTTP Protocol Port: 80
  HTTPS Protocol Port: 443
        TLSv1 Enabled: true
        SSLv3 Enabled: true
        SSLv2 Enabled: true

Install the integration

1. From All Clients, select a client.

2. Go to Setup > Integrations > Integrations.

3. From Available Integrations, select Adapter > NetApp ONTAP. The Install NetApp ONTAP Integration popup appears.
   Note: Ensure that Adapter addon is enabled at client and partner levels.

4. Enter the following information:
   a. Name: Name of the integration
   b. Upload Logo: Optional logo for the integration.
   c. GateWay Profiles: Select a gateway management profile to associate with the client.
   

5. Click Install. The Integration page displays the installed integration.

Configure the integration

1. In CONFIGURATION section, click + Add.

2. On Create Adapter Configuration, enter:

   • Name: Configuration name.
   • IP Address/Host Name: IP address or host name of the target.
   • Protocol: Protocol
   • Notification Alerts: Select TRUE or FALSE.
     
     

3. In the Credential section, select Custom and enter the Username and Password.

4. In the Resource Types & Metrics section, select the metrics you want and configure for availability and alert conditions.

5. In the Discovery Schedule section, select Recurrence Pattern to add one of the following patterns:

   • Minutes
   • Hourly
   • Daily
   • Weekly
   • Monthly
     
     

6. In the Monitoring Schedule section, configure how frequently the monitoring action should trigger.

7. Click Save.

After saving the integration, NetApp ONTAP resources are discovered and monitoring is enabled as specified by the configuration profile.

The configuration is saved and displayed on the page.

You can perform the actions manually, like Discovery, Monitoring or even Disable the configuration.

The discovered resource(s) are displayed in the Infrastructure page under
Storage > NetApp Cluster, with Native Resource Type as NetApp Cluster.

The NetApp Cluster Node, NetApp Storage Disk, and NetApp Storage SVM are displayed under Components:

Metro cluster (NetApp Remote Cluster) is discoverd only when it is configured on the cluster.

View resource metrics

To confirm NetApp 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.

Supported Metrics

Risks, Limitations & Assumptions

• App can handle below 3 different types of alerts:
  • Connectivity Exception
  • Authentication Exception
• Using metric for monitoring the resources and generate alerts when the threshold values are breached.
• App cannot control monitoring pause/resume actions based on the above alerts
• Platform has support to enable/disable configuration. So when a particular notification is generated then customer can take action using UI/API.
• Discovery and Monitoring frequencies depend on the number of resources. If the number of resources increase, then discovery and monitoring frequencies need to be adjusted:
  • Recommended discovery frequency for around 2500 resources is 2 hours
  • Recommended monitoring frequency for around 2500 resources is 30 minutes
  • The API rate limit is 20 (At a point of time we can make 20 concurrent API calls only with the cluster).

References

ONTAP API Response: https://library.netapp.com/ecmdocs/ECMLP2874708/html/index.html