Friday 13 December 2019
Saturday 30 November 2019
snapmirror snapshot with alpha-numeric characters
snapmirror snapshots on the vault destination may appear as:
snapmirrorSE.5c445bb9-45ca-b4f1-9cf4db068c07.snapshot1
This is a BUG:
https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=716347
Resolved in : 9.3RC1 onwards..
Friday 29 November 2019
Saturday 23 November 2019
Friday 20 September 2019
How does NFS access works for version nfsv3 & nfsv4 in ONTAP
When a mount command is issued to an ONTAP NFSv3 server from an NFS client, the following occurs:
1. RPC is made to port 111 (portmapper) of the NFS server to attempt a TCP connection through the portmapper.
2. When the RPC call has been acknowledged, portmapper issues a GETPORT call to port 111 of the NFS server data LIF to obtain which port NFS is allowed on.
3. The NFS server returns the port 2049 (nfs) to the client.
4. The client then closes the connection to port 111.
5. A new RPC call is made to port 2049 of the NFS server data LIF.
6. The NFS server returns the call successfully and the client sends an NFS NULL call to port 2049 of the NFS server’s data LIF. This action checks whether the parent volume allows access to the mount. In this case, the parent volume is mounted to /, or the SVM root.
7. The NFS NULL call is returned successfully and the client proceeds with the mount attempt.
8. Portmapper sends a GETPORT call to the NFS server’s data LIF asking for the mountd port and provides the credentials, NFS version number, and whether the mount will use TCP or UDP.
9. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This operation is carried out through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP/UDP is not allowed, the client reports the error.
10. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP or UDP connection. It also replies if the AUTH security provider is supported (AUTH_SYS or AUTH_GSS, for example).
11. When the GETPORT call passes, the client issues a V3 MNT call to the junction path specified in the mount command through port 635 (mountd) of the NFS server data LIF.
12. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
13. The NFS server returns the file handle to the client, as well as replies which AUTH types are supported by the export policy rule. If the AUTH type provided by the server matches what the client sent, the mount succeeds.
14. Portmapper from the client then sends another GETPORT call for NFS, this time providing the client’s host name. 15. The NFS server replies with port 2049 and the call succeeds.
16. Another NFS NULL call is made from the client over port 2049 of the NFS data LIF and is acknowledged by the NFS server.
17. A series of NFS packets with FSINFO and PATHCONF information is traded between the client and the NFS server.
When a mount command is issued to an ONTAP NFSv4 server from an NFS client, the following occurs:
1. The NFS client makes a TCP connection attempt to the NFS server data LIF through port 2049 (nfs). NFSv4 uses only TCP and only port 2049 for all calls.
2. The NFS server either allows or rejects the TCP connection, based on the NFS server settings.
3. When the TCP connection has been established, a V4 NULL call is made by the NFS client to the NFS server data LIF. This call is a check to see whether v4 is allowed on the NFS server through the AUTH type provided by the client (AUTH_SYS or AUTH_GSS, for example).
4. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This is done through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP is not allowed, the client reports the error.
5. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP connection, and also if the AUTH security provider is supported.
6. The NFS client then makes a compound v4 call for PUTROOTFH, GETFH, and GETATTR for the specified mount point’s parent volume. This call supplies the UID and GID of the user attempting access.
7. The cluster checks the UID and GID through SecD to verify that they exist in the provided NFSv4 domain and does a translation so that the user has access to mount the parent volume. In this case, the parent volume is /, or the SVM root.
8. The NFS server replies with the file handle of the SVM root volume and the attribute information of the parent volume.
9. The NFS server and client exchange a series of GETATTR calls to check access to the SVM root volume.
10. If the access is allowed to the user attempting access, then the client issues a LOOKUP DH call to the NFS server’s data LIF for the SVM root volume’s file handle/junction path; for example, 0x871aba87/vol1.
11. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
12. The NFS server returns the file handle to the client, as well as the attributes of that volume.
13. The NFS client and server exchange a series of GETATTR calls on the new file handle so that access is allowed for the user attempting mount access. 14. If access is allowed, the mount is successful.
1. RPC is made to port 111 (portmapper) of the NFS server to attempt a TCP connection through the portmapper.
2. When the RPC call has been acknowledged, portmapper issues a GETPORT call to port 111 of the NFS server data LIF to obtain which port NFS is allowed on.
3. The NFS server returns the port 2049 (nfs) to the client.
4. The client then closes the connection to port 111.
5. A new RPC call is made to port 2049 of the NFS server data LIF.
6. The NFS server returns the call successfully and the client sends an NFS NULL call to port 2049 of the NFS server’s data LIF. This action checks whether the parent volume allows access to the mount. In this case, the parent volume is mounted to /, or the SVM root.
7. The NFS NULL call is returned successfully and the client proceeds with the mount attempt.
8. Portmapper sends a GETPORT call to the NFS server’s data LIF asking for the mountd port and provides the credentials, NFS version number, and whether the mount will use TCP or UDP.
9. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This operation is carried out through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP/UDP is not allowed, the client reports the error.
10. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP or UDP connection. It also replies if the AUTH security provider is supported (AUTH_SYS or AUTH_GSS, for example).
11. When the GETPORT call passes, the client issues a V3 MNT call to the junction path specified in the mount command through port 635 (mountd) of the NFS server data LIF.
12. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
13. The NFS server returns the file handle to the client, as well as replies which AUTH types are supported by the export policy rule. If the AUTH type provided by the server matches what the client sent, the mount succeeds.
14. Portmapper from the client then sends another GETPORT call for NFS, this time providing the client’s host name. 15. The NFS server replies with port 2049 and the call succeeds.
16. Another NFS NULL call is made from the client over port 2049 of the NFS data LIF and is acknowledged by the NFS server.
17. A series of NFS packets with FSINFO and PATHCONF information is traded between the client and the NFS server.
When a mount command is issued to an ONTAP NFSv4 server from an NFS client, the following occurs:
1. The NFS client makes a TCP connection attempt to the NFS server data LIF through port 2049 (nfs). NFSv4 uses only TCP and only port 2049 for all calls.
2. The NFS server either allows or rejects the TCP connection, based on the NFS server settings.
3. When the TCP connection has been established, a V4 NULL call is made by the NFS client to the NFS server data LIF. This call is a check to see whether v4 is allowed on the NFS server through the AUTH type provided by the client (AUTH_SYS or AUTH_GSS, for example).
4. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This is done through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP is not allowed, the client reports the error.
5. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP connection, and also if the AUTH security provider is supported.
6. The NFS client then makes a compound v4 call for PUTROOTFH, GETFH, and GETATTR for the specified mount point’s parent volume. This call supplies the UID and GID of the user attempting access.
7. The cluster checks the UID and GID through SecD to verify that they exist in the provided NFSv4 domain and does a translation so that the user has access to mount the parent volume. In this case, the parent volume is /, or the SVM root.
8. The NFS server replies with the file handle of the SVM root volume and the attribute information of the parent volume.
9. The NFS server and client exchange a series of GETATTR calls to check access to the SVM root volume.
10. If the access is allowed to the user attempting access, then the client issues a LOOKUP DH call to the NFS server’s data LIF for the SVM root volume’s file handle/junction path; for example, 0x871aba87/vol1.
11. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
12. The NFS server returns the file handle to the client, as well as the attributes of that volume.
13. The NFS client and server exchange a series of GETATTR calls on the new file handle so that access is allowed for the user attempting mount access. 14. If access is allowed, the mount is successful.
Friday 22 March 2019
Sunday 17 February 2019
Global Name Space in cDOT/ONTAP is a true UNIX/Linux based 'Pseudo File Systems'
Global Name Space in cDOT is result of a 'Pseudo File Systems' in cDOT architecture: The clustered Data ONTAP architecture has made it possible to have a true pseudofile system, which complies with the RFC 7530 NFSv4 standards.
Servers that limit NFS access to "shares" or "exported" file systems should provide a pseudo-file system into which the exported file systems can be integrated, so that clients can browse the server's namespace. The clients' view of a pseudo-file system will be limited to paths that lead to exported file systems.
NFSv4 servers avoid this namespace inconsistency by presenting all the exports within the framework of a single-server namespace. An NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly from one export to another. Portions of the server namespace that are not exported are bridged via a "pseudo-file system" that provides a view of exported directories only. A pseudo-file system has a unique fsid and behaves like a normal, read-only file system.
Servers that limit NFS access to "shares" or "exported" file systems should provide a pseudo-file system into which the exported file systems can be integrated, so that clients can browse the server's namespace. The clients' view of a pseudo-file system will be limited to paths that lead to exported file systems.
NFSv4 servers avoid this namespace inconsistency by presenting all the exports within the framework of a single-server namespace. An NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly from one export to another. Portions of the server namespace that are not exported are bridged via a "pseudo-file system" that provides a view of exported directories only. A pseudo-file system has a unique fsid and behaves like a normal, read-only file system.
Friday 4 January 2019
Nostalgic : My first KB article on NDMP written between 2006/2007 still exists on the web
How to perform a backup of NDMP Filers (NAS) with the Veritas Backup Exec Network Data Management Protocol (NDMP) Option.
Article ID:100017787 Last Published:2013-09-10 Product(s):Backup Exec
https://www.veritas.com/support/en_US/article.100017787.html
You feel good when you see something that is still valid and available after 11 years nearly.
Then, I used simple Microsoft Paint to show NDMP direct & 3-way backups, and after a decade I still use paint for most of the KB articles :)
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.
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.
Subscribe to:
Posts (Atom)