Thursday, 3 January 2019

Handy info on SNMP & ZAPI wrt NetApp

OnCommand System Manager (OCSM) uses SNMP for the dashboard and discovery.

Can OCUM (Oncommand Unified Manager) discover NetApp controllers using https only, without SNMP?

Yes, with OCUM 6.x, SNMP is not required to discover cDOT clusters. You must enable https to discover the cDOT.

OCUM 5.x = snmp & https
OCUM 6.x and later = https

OCUM: The default interval for the discovery process is every 15 minutes.


Possible causes for failure of cDOT discovery in OCUM 6.x and later?
Http/Https web service is not enabled on the Cluster
Cluster node is busy
Cluster is not reachable
Cluster certificate is expired
Cluster node name has changed


Does SnapManager Suite of Products use SNMP to talk to controller?
SnapManager products do not communicate directly with controllers, all communication is through SnapDrive.  SnapDrive communicates to controllers using ZAPI calls.


Note: You might know this already but if not then it is a kind of common knowledge that - Slowly all the SnapManager suite of Products will be phased out by 2020 in favour of SnapCenter. SMSQL, SME, SMO all have different EOSL, so more info go to NetApp support site.  Going forward, you can either switch to 3rd Party Backup Vendor (s) such as CommVault  to replace your existing SM backups, or switch to SnapCenter to continue using NetApp based protection.


What is ZAPI?
Zephyr + API = ZAPI
How it works: API (Python library) requests and responses are wrapped in XML format and transmitted over HTTP(S)

Cluster ZAPI: Connects to cluster management IP, used for administrating entire Cluster, can administer Vserver by using Vserver tunneling and optionally can delegate the administration of the Vserver to a Vserver administrator

VSERVER ZAPI: Connects to Vserver Management IP but can only use APIs listed in Vserver context.


If the SNMP community string on the controller does not match the SNMP string configured in OnCommand Unified Manager (DFM):

On the controller: 7-mode

Check the current SNMP string:
filer> snmp community

Set a new/additional SNMP community string:
filer> snmp community add ro <community>

To delete an existing SNMP community string:
filer> snmp community delete ro <community>


On the controller: cDOT

cluster1::> system snmp community add -type ro -community-name <community>
cluster1::> system snmp community delete -community-name <community> -type ro

Note: Do not use the default SNMP community, there must be a private community string used in your organization, if unsure ask the Infrastructure Guys (Network Discovery).

PS: If there is any information that you find incorrect or would like to add to it, please feel free to post your comments.

No comments:

Post a Comment