Showing posts with label ontap. Show all posts
Showing posts with label ontap. Show all posts

Wednesday, December 18, 2019

Netapp: xcp tool for high file count volumes copy

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.
............................................................................................................................................................................


Troubleshooting Workflow: NetApp XCP Migration Tool errorsDocument ID BR519
Answer ID 1005557
Published Date 12/12/2019
Symptom
Symptom 1
-bash: ./xcp: Permission denied
Symptom 2
xcp: ERROR: This license has expired
Symptom 3
xcp: This copy is not licensed.
Symptom 4
xcp: ERROR: XCP not activated, run 'activate' first
Symptom 5
xcp: ERROR: License file /opt/NetApp/xFiles/xcp/license not found.
Symptom 6
xcp: ERROR: Failed to activate license: Server unreachable
Symptom 7
xcp usage error: show: requires at least one server
Symptom 8
xcp: ERROR: show '10.61.73.94:/vol/nfsvol1': invalid hostname
Symptom 9
xcp usage error: scan: missing source path
Symptom 10
xcp usage error: scan: invalid path '10.61.73.94'
Symptom 11
xcp: ERROR: Catalog inaccessible: Cannot mount nfs_server:/export[:subdirectory]
Symptom 12
xcp: compare1 'n.txt': ERROR: nfs3 LOOKUP 'n.txt' in '10.61.73.113:/target': nfs3 error 2: no such file or directory
Symptom 13
xcp: ERROR: Failed to open catalog id '3': nfs3 LOOKUP '3' in '10.61.73.94:/vol/nfsvol1/catalog/indexes': nfs3 error 2: no such file or directory
Symptom 14
xcp: ERROR: Empty or invalid index '10.61.73.94:/vol/nfsvol1/catalog/indexes/2/2.index'
Symptom 15
xcp: copying 'file3': WARNING: 10.193.67.237:/ntfs/topdir_3/subdir_52/file3: nfs3 SETATTR '10.193.67.237:/ntfs/topdir_3/subdir_52/file3' mode 00777, uid 0, gid 0, size 27, atime Thu Feb 23 10:15:00 2017, mtime Tue Feb  7 11:51:54 2017: nfs3 error 1: not owner
Symptom 16
Sync fails in different areas due to following warning:
xcp: mount 10.61.73.94:/vol/nfsvol1: WARNING: This NFS server only supports 1-second timestamp granularity. This may cause sync to fail because changes will often be undetectable.
Symptom 17
XCP fails to transfer ACLs and produces the following ERROR:
ERROR failed to obtain fallback security principal "". Please check if the principal with the name "" exists on "".
Cause
The cause and procedure to be performed to resolve these issues are described in the Solution section below.

Cause #1: Improper file permissions for XCP binary.
Solution: Modify permissions by running the  "chmod 755" command. 
Ensure XCP binary can be executed by the 
root user or sudo
command on designated XCP Linux client host.

Cause #2: This error occurs if the free 90 days XCP evaluation license is expired.
Solution: Renew or obtain the new XCP license from https://xcp.netapp.com

Cause #3: XCP is not licensed.
Solution: Download and apply XCP licenses on Linux client host system.
Cause #4: XCP license is not activated
Solution: Obtain the appropriate XCP license file. Copy the XCP license to the 
/opt/NetApp/xFiles/xcp/ directory on the XCP Linux client host. Run  "xcp activate" command to activate the license.
Cause #5: XCP license is not activated.
Solution: Download the XCP license from https://xcp.netapp.com. Copy XCP license file on to the XCP Linux client host at 
/opt/NetApp/xFiles/xcp/
After copying, run "xcp activate" command to activate the XCP license.
Cause #6: License file not found at 
/opt/NetApp/xFiles/xcp/license
Solution: Register for XCP license at https://xcp.netapp.com. Download and copy XCP license file to 
/opt/NetApp/xFiles/xcp/ directory on XCP Linux client host.
Cause #7: Incomplete parameter specified for the 
xcp show command.
Solution: Re-run the command with the server name or IP address specified. Correct syntax 
./xcp show abc.nfsserver.com
Cause #8: Valid hostname was not specified for the 
./xcp show
 command.
Solution: Run the 
./xcp show
 command with valid hostname. Exact command syntax 
./xcp show 10.61.73.94
 or 
./xcp show localhost
Cause #9: Incomplete parameters specified for the 
xcp scan
 command.
Solution: To resolve this error, run the 
xcp scan
 command with the complete source NFSv3 export path. Correct syntax 
xcp scan
Cause #10: Incomplete parameter specified for the 
xcp scan command.
Solution: Run the same command again by specifying the complete NFSv3 source export path. Correct syntax 
xcp scan .
Cause #11: Catalog path is not specified in the
 xcp.ini
 configuration file.
Solution: Open a text editor on XCP Linux client host and update XCP configuration file with proper catalog location. XCP config file is located at 
/opt/NetApp/xFiles/xcp/xcp.ini
Sample entries of config file:
[root@localhost linux]# cat /opt/NetApp/xFiles/xcp/xcp.ini
# Sample xcp config:
[xcp]
catalog = 10.61.73.94:/vol/nfsvol1

Cause #12: Verify operation did not find the source file(s) on target NFS export.
Solution: Run the 
xcp sync
 command to copy the incremental updates from the source to destination.

Cause #13: XCP could not locate the specified catalog index number.
Solution: Verify the index number of the previous operation. To determine the exact catalog path, run the 
cat /opt/NetApp/xFiles/xcp/xcp.ini
 command. Catalog indexes are located in the 
:/catalog/indexes
 directory. After locating the index number, run the same command again by specifying the correct index number or name.
Cause #14: Previous copy operation was interrupted before indexing the files.
Solution: Run the 
xcp copy
 operation again by specifying the 
–newid
 option.
Interrupt the copy operation when you see the message '
indexed' 
on the console session
:
88,126 scanned, 42,058 copied, 41,469 indexed, 150 MiB in (3.60 MiB/s), 41.9 MiB out (2.88 MiB/s), 16s
Cause #15: This happens on NTFS security style volumes because XCP attempts to chown a file and cannot, as UNIX operations will fail on NTFS security style volume by default.
Solution:  Run the following command:
# chown root newfile
chown: changing ownership of ‘newfile’: Operation not permitted

In a packet trace, the following is displayed:
3380 7.642295   10.193.67.237   10.193.67.233   NFS  214  V3 SETATTR Reply (Call In 3338) Error: NFS3ERR_PERM
The error is benign, as the owner would be set from a Windows client after the fact anyway.
The following are the two ways to avoid this:
  • Change the export policy rule to ignore with the following command: export-policy rule modify -vserver DEMO -policyname default -ruleindex 1 -ntfs-unix-security-ops ignore
  • Copy to a mixed security style or UNIX security style volume. After the copy, change the security style to NTFS.
A third possible way would be for XCP not to attempt to run setattr after copying. Unable to identify a way to perform so in the current version for the copy command. Perhaps that option could go into a future release.
  • copy: Recursively copy everything from source to target
  • newid : Catalog name for a new index
  • md5: Checksum the files (also save the checksums when indexing) (default: False)
  • edupe: Include dedupe estimate in reports (see documentation for details)
  • nonames: Do not look up user and group names for file listings or reports
  • bs : read/write blocksize (default: 64k)
  • dircount : Request size for reading directories (default: 64k)
  • parallel : Maximum concurrent batch processes (default: 7)
  • noId: Disables the creation of a default index (default: False)
Cause #16: Have seen this when source volume is SLES or RHEL with ext3 file system
Solution: Issue is documented here: 1181841 XCP Sync: Timestamp granularity
  • Workaround: We recommend to have access time enabled, because xcp compares the timestamp of the files from the source and index (contains all the file metadata found on the source). And in this use-case we may have differences < 1s and xcp will not apply the changes.
  • This is only a warning, and could be ignored.
Cause #17: This may happen when:
  • The target netbios name/machine account cannot be resolved to an IP
  • The target machine cannot resolve the fallback-user or fallback-group to a SID
Solution:
  • For cause 1, add a mapping in the hosts file (c:\windows\system32\drivers\etc\hosts) for the netbios name/machine account name of the target.
  • For cause 2, select a fallback-user/group that can be resolved by the target system. This can either be a local user to the target machine, or a domain user resolvable by the target machine.
Related Links:
  • 1098120: NetApp XCP Frequently Asked Questions and Resources
  • 1015592: Triage Template - How to troubleshoot NetApp XCP Migration Tool issues
  • 1015613: How to transition 7-Mode NFSv3 exports to clustered Data ONTAP using NetApp XCP Migration Tool 1.0
XCP 1.5
XCP Best Practices TR-4808
You are Welcome :)

Monday, December 9, 2019

Netapp: How to do perform Disk Erasure, Disk Clearing and Wipe Configuration on CDOT Netapp disks.

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.
............................................................................................................................................................................

Depending on what scenario is applicable to you in your environment, there are two ways to run data erasure and disk configuration wipe out activity. By simply pushing the data disk to spare pool after removing it from aggregate may not suffice some of the data erasure function requirement. Disk degaussing by feeding the drive into traditional degauss machine that uses magnetic function to certify degauss might leave some data owners in a questionable position about their comfort before disk disposal. Here are two scenarios that are standard practices which Netapp supports without intervention from third party software or application that runs disks data erasure and wiping configuration.

Scenario 1 Usage: Disk Initialize
If there is flexibility to reboot the node and entire disks data needs to be wiped or configuration reset, then “disk Initialize” is the right option.

Prerequisites.
1. If the disks are part of an aggregate and/or holds volumes, volumes must be taken offline, destroyed followed by taking aggregate offline and aggregate deletion.
2. Disks must be in a spare pool, but can be owned by nodes.
3. Only root aggregate disks should be present.

Actual Action:
Step 1. Boot each node by while accessing from console or SP (if configured) and take it to the loader prompt.
Boot each node to the LOADER/CFE prompt and ensure that the below variables are set. These variables remove the cluster RDBs, CDBs and the varfs from mroot, boot device and nvram.
setenv bootarg.init.boot_clustered true
setenv bootarg.factory_init_completed true
setenv bootarg.init.clearvarfsnvram true

Step 2. Then run boot_ontap from loader prompt and while node reboots, Press CTRL + C to go to special boot menu.

Step 3. Out of 8 special boot menu option, dont select any option yet. Rather Type “wipeconfig” on each node.

Step 4. Then select Option no. 4. that says “Clean configuration and initialize all disks”
(This will prompt if you want to zero disks, reset config and install a new file system. Type “yes”)

Step 5. This will run disk initialize operation in the background which is indicated by dots (…….) fillling the screen till its done. Each and every drives gets initialized and upon completion, it will take you to a prompt where it asks if you want to create or join cluster or new filesystem.

At this time, it is safe to power down Controller head and Disk Shelves. Disk have been reset and data have been completely erased.


Scenario 2 Usage: Disk Sanitization
Data ONTAP 8.0 and earlier, the disk sanitization feature needed a disk sanitization license.
Data ONTAP 8.1 and later, Just need to enable the feature per step 1, under Actual Action below.
If you only few drives in a stack, or just one shelf from a set of stack of shelves, you cannot use scenario 1 based solution for complete data erasure as we are not going to erase data from entire array, but only from selective disks.
Disk sanitization is the process of physically obliterating data by overwriting disks with specified byte patterns or random data so that recovery of the original data becomes impossible. You use the sanitization process to ensure that no one can recover the data on the disks. This functionality is available through the nodeshell.

Pre-Requisites.
1. Disks in question must be in spare pool, but can be owned by nodes.

How Disk sanitization works?
Disk sanitization process uses three successive default or user-specified byte overwrite patterns for up to seven cycles per operation. The random overwrite pattern is repeated for each cycle.

**Sanitization contains two phase:
a. Formatting phase
b. Pattern overwrite phase

**Disk Sanitization Feature is applied at Storage system level, and once it is enabled, it cannot be disabled.

Actual Action:
Step 1. Go to nodeshell from cluster.
node::>options nodescope.reenabledoptions licensed_feature.disk_sanitization.enable
node::>options licensed_feature.disk_sanitization.enable on

Step 2.Start disk sanitize on disk or disklist.
node::> disk sanitize start disk_list

Step 3. Check disk sanitize status
node::> disk sanitize status disk_list

Step 4. After disk sanitization is complete, return the sanitized disk to spare pool, it wont automatically send disk to spare pool.
node::> disk sanitize release disk_name

Step 5. Exit from node shell and go to cluster shell.
node::> CTRL + D
Cluster::>>

Step 6. Verify disk have been properly placed on spare pool.
cluster::> storage disk show -container-type spare

By now, disk is sanitized with no data and is in hot spare pool for it be ready to be used.

**At this time, you can use the degauss machine to crush the drive**

**Some of the Industry Standards on how to run disk sanitization or data erasure procedure**

https://kb.netapp.com/app/answers/answer_view/a_id/1034565/~/how-to-use-disk-sanitize-to-meet-department-of-defense-5220.22m-
https://kb.netapp.com/app/answers/answer_view/a_id/1072424/~/how-to-perform-disk-erasure%2C-disk-clearing-and-disk-sanitization-

You are Welcome :)

Tuesday, November 26, 2019

Netapp: How to remove Nodes from multi-node cluster running CDOT with Examples


I am a seasonal IT professional with a background on VMware, Storage, Backup, Unix, and Project liaison experience. I have held positions working on technologies like Netapp, EMC, IBM, Cohesity storage and Backup supporting SAN and NAS Environment. I have held roles of IT administrator, engineer, team lead and project liaison. This blog is for Storage and Backup Professionals, and content are derived from vendor as well as my own experience.
............................................................................................................................................................................
I recently did cluster unjoin and removed nodes from multi-node cluster running CDOT 9.3Px without any service disruption and with seamless activities. 

##Visibility to system is the KEY. Log into SP or Console of nodes all the time during this activity. Helps if you run into some unforeseen or unpredicted situations.


Prerequisites:
  1. Disable Storage failover (cf status) between HA nodes.
  2. Migrate data lifs home and home port from nodes in question over to other healthy nodes/ports by net interface modify.
  3. Remove ports of nodes from broadcast domain / failover-groups leaving only ones that would be present after nodes removal.
  4. Delete intercluster lifs, and remove Intercluster ports from corresponding broadcast domain.


Actual Steps:

Step 1. 
Log into adv mode in cluster by:
cluster: set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: (Press y)

Step 2. 
Confirm that the nodes in questions is serving as master node. If it is working as master node, make it ineligible. (Caution, Once you have it made it ineligible, you would need to reboot the node to make it eligible again, if you need to.) This can be done by checking cluster ring status from adv mode.
cluster*::>cluster ring show

Verify that there is still no lif or data on nodes in question:
net int show -home-node node1

net int show -home-node node2

cluster*::> cluster modify -node node2 -eligibility false
Double confirm by running below to ensure there is no lif dependency except cluster port and/or node management port/lif. It would complain if there is still something left on nodes being worked.

cluster*::>cluster ring show
(This would list node2 being offline as it has been deemed ineligible. Other node will display as master)
(You run the same for both nodes in HA.)


Node      UnitName Epoch    DB Epoch   DB Trnxs      Master    Online
---------     --------      -------       --------       --------           ---------      ---------
node2     mgmt         0               25       736267                           offline
node2     vldb           0               23       1913                               offline
node2     vifmgr        0               25       11031                             offline
node2     bcomd       0               26       4                                     offline
node2     crs             0               23       1                                     offline

Step 3.  Verify:
cluster::*>storage failover show
cluster::*>cluster ring show

Step 4. 
Now run actual unjoin action.
cluster::*> cluster unjoin -node node2

(This will provide some warnings, but as long as checklist of pre-req and other is completed, proceed)

(At this time, you can wipe disk data by pressing step 4 by doing “Ctrl + C” during reboot. You will have visibility to console, if you have been accessing the node via console or service processor. It is strongly advised, that nodes in question be accessed using sp in a different session than actual session where cluster unjoin session is being executed.)

Step 5. 
Halt the nodes in question by logging into individual nodes, if applicable. You can uninstall the Hardware after completion of disk initialization (if chosen). Otherwise, its safe to remove cables, uninstall hardware.



You are welcome :)


  

Wednesday, November 20, 2019

Netapp: How to partition SSD disk/tray to an aggregate that already has partitioned disks

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.
............................................................................................................................................................................
Problem Synopsis: I have encountered into a situation, where I saw discrepancy on logical partition size of newly added disks into a pool of partitioned disks aggregate while you check partition size of spare drive.

Potential Result: In an event drive would fail in a current aggregate, the spare partition drive wont kick in, or even if it kicks in, it may not be in healthy state.

Solution: Validate the current partition size first, and then when add a new tray of SSD or just drives, perform partition copying the partition size.

**This applies only when you are adding additional disk/tray to an already existent aggregate**
Step 1: All new drives or entire tray of disks should be assigned to one node. If it partitions by default, you would need to unpartition the disks first. After disks are unpartitioned, thats when you partition the disks from nodeshell.

Step 2: Get the actual raw size of P3 partition from root aggregate. Remember Higher Partition number is for ROOT. E.G. P3 is partition only usable for root, No data aggregate can be created even when you have many spare P3 partition available. (This is what I found little off i.e. not being able to use entire space).

** Judgement to use Unparitioned drive to leave two drives for Parity and DP, Or, do Partition the drives and still leave P3 partition in the float pool, is something what you want. I found out that partitioning still is better in terms of total SSD usable capacity rather than using non-partition based disk add, after adding into pool.**

  1. Go to diag mode from a node where you already have root aggregate (partitioned) and gather info on P3 partition raw size.
  • node>priv set diag
  • node*>raid_Config info listdisk XX.XX.XXP3 (locate raw size)
xxxxxxxxxxxxxxxxdfdsdafdsjlfkj, jlkjfldkjlsj ,ljkjflsjkdljsljd,jlfjlksjfljdlsdjssjlfjldsfjldfs,lsjldsjdlfjsd
rawsize=28246976,used=28239680,rightsize=28244928,slfjldsjfs,klsjfkdsljfs,jlkfjlsjlskjlk,lkdjldksjlkf

Step 3: Now From list of all the unpartitioned disk that were just added, Pick the one you want to partition. And perform Partition.
  • node*> disk partition -n 3 -i 3 -b 28246976 0d.11.0 (n= number of parition, b=raw size from current one) 
  disk partition: 0d.11.0 partitioned successfully 


Step 4: Validate the partitioned disk.
node*> disk show -n

DISK       OWNER                    POOL   SERIAL NUMBER         HOME                    DR HOME

------------ -------------            -----  -------------   -------------           -------------
0d.11.0P1    Not Owned                  NONE   
0d.11.0P2    Not Owned                  NONE   
0d.11.0P3    Not Owned                  NONE   

Step 4: Now Assign the partition to respective node.
node*> disk assign 0d.11.0P3 -o

This will leave remainder of Partition match what were were previously on existing partitioned disks.


You are Welcome :)
Source: www.netapp.com








Wednesday, November 13, 2019

Netapp: Example of CN1610 Netapp Cluster switch FASTPATH and RCF upgrade

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.
............................................................................................................................................................................Upgrade FASTPATH and RCF on CN1610


Important things to consider:

  • Before a Netapp Cluster switch is upgraded, ensure that current running Ontap supports the FASTPATH version to be upgraded on switch side by looking into interoperability matrix.

  • Ensure FASTPATH version and RCF version are compatible with ONTAP version running.




***Once verified that the RCF and FASTPATH are compatible, proceed with below**


Steps:

1. Verify Cluster ports are home, healthy and operational.




2. Verify Cluster interface are healthy, and are home

 

3. We are doing Cluster Switch 2 Upgrade first. So migrate cluster Lif xx_clus2 over to partner port on same local node.




4.  Verify cluster lif clus2 has migrated to NODE 1, port e0a.



5. Now Modify Cluster Port by turning its admin status which was connected to ClusterSwitch#2. By Step no. 3, we now have no dependency of cluster lif on port e0b on either nodes.




6.  Confirm Cluster port admin/link status is down as a result of Step #5.




7. Now Shutdown the ISL port on ClustwerSwitch#1 to remove any ISL traffic to ClusterSwitch#2.


8. Since we are doing the upgrade on ClusterSwitch#2 First, Log into ClusterSwitch#2 and verify what version is running in active state, what is the backup version, and what version is giong to be next active.

(ClusterSwitch#2) #show bootvar
Image Descriptions
 active :
 backup :
 Images currently available on Flash
 ----  ----------  ----------  -----------------  -----------------
 unit      active      backup     current-active        next-active
 ----  ----------  ----------  -----------------  -----------------

    1     1.1.0.8     1.1.0.8            1.1.0.8            1.1.0.8


9. Copy active FASTPATH image to backup before making changes

 



10. Verify Current running Version on Switch#2.


11. Copy the Updated FASTPATH Image and stage it on SWitch#2.
(ClusterSwitch#2) #copy scp://username@servername //var/www/ftp/CN1610_1.2.0.7.stk active
Management access will be blocked for the duration of the transfer
Are you sure you want to start? (y/n) y

12.  Confirm the next active shows up the version you have just copied from step#11.



If RCF from Compatibility Matrix is not present, Follow 14-17, Else Move to Step 18

14. Find the Correct RCF file from Support site. For this exercise we are going with RCF_v1.2 that is compatible with Next-Active FASTPATH 1.2.0.7.
(ClusterSwitch2)#copy scp://username@servername //var/www/ftp/CN1610_CS_RCF_v1.2.txt nvram:script CN1610_CSRCF_v1.2.scr

15. Confirm Script is downloaded:




16. Apply the script to the Switch.


17. Verify the script has been applied to the switch, and then save the configuration.




Step 14- Step17 is required only if RCF version need to be updated

18. Reboot the ClusterSwitch#2 now. (1.2.0.7 as new FASTPATH has been uploaded, Newer RCF is uploaded by now. Reboot will make it active).



19. Verify the switch is running new version of FASTPATH Software on ClusterSwitch#2.



20. Now Log into ClusterSwitch#1 and Enable ISL Ports for Port-Channel



21. Verify ISL Ports are operational and Port channel is active from ClusterSwitch#2.



22. Log into Cluster and bring up the admin port of e0b which would now be connected to already upgraded ClusterSwitch#2. This can be done from node locally only i.e. logging into cluster lif prevents you from bringing up or down ports.


23. Verify that the cluster ports are healthy and UP by now.




24. Verify Cluster Interface are home and healthy.






25. Verify Cluster HA is healthy, cluster health is healthy.
Cluster1::*> Storage failover show




REPEAT STEP 3 THRU STEP 25 for ClusterSwitch#1 This time. Instead of Cluster lif clus2, this time it will be Clus1 and port migrate would be port e0b from step no. 3.



I have followed above instruction in doing multiple CN1610 upgrades.

I am sure you found it helpful.



You are welcome :)
Source: www.netapp.com


Netapp: What is an inode ?

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.
......................................................................................................................................................................
Netapp Documentation Says-- An inode is a data structure containing information about files.
An inode is a data structure that defines a file, except for the filename which is stored in the directory entry. Note that a directory is just another file. The inode number is an integer unique to the volume upon which it is stored. Inodes point to blocks that make up a file, and inodes also contain the metadata of the file.
When a program refers to a file by name, the system looks up the filename in the directory entry file of the directory in which the file exists to get the proper inode. This gives the system the information it needs about the file to perform further operations.
Each inode contains the following information:
  • Volume where the inode resides
  • Locking information
  • Mode and type of file
  • Number of links to the file
  • Owner's user and group ids
  • Number of bytes in the file
  • Access and modification times
  • Time the inode itself was last modified
  • Addresses of the file's blocks on disk
  • Permission: UNIX bits or Windows Access Control List (ACLs)
  • Qtree ID
Data ONTAP allocates one inode per 32KB of data in a volume by default. This value can be increased to as high as 1 inode per 4KB of data via the maxfiles command.


You are Welcome :)
Source: www.netapp.com

Netapp: Maximum number of volumes snapshots, and flexclones

I am a seasonal IT professional with a background on VMware, Storage, Backup, Unix, and Project liaison experience. I have held positions working on technologies like Netapp, EMC, IBM, Cohesity storage and Backup supporting SAN and NAS Environment. I have held roles of IT administrator, engineer, team lead and project liaison. This blog is for Storage and Backup Professionals, and content are derived from vendor as well as my own experience.
............................................................................................................................................................................
I personally find it very helpful when I know the data if I have to compare some other storage products in terms of relative assessment.

Here are the maximum limits per volume as documented by Netapp.

Volume limits


1. Maximum file size: 16TB

2. Maximum flexclone volumes clone depth: 499 Characters.

3. Maximum volumes per cluster: 12000 **

4. Maximum volumes count: Model dependent. Refer: hwu.netapp.com

5. Maximum Qtrees per volume: 4995

6. Maximum Snapshot: 9.3 and earlier-: 255 &   9.4 and after-:1024

7. Maximum Clones per file or lun: 32767

8. Maximum total shared data per flexvol volume: 640TB (Array and Native), & and; 100TB (For Edge).



You are Welcome :)
Source: www.netapp.com

Netapp: Flexgroup volume vs. flex volume and inodes limit

Learn Storage, Backup, Virtualization,  and Cloud. AWS, GCP & AZURE.

............................................................................................................................................................................

Netapp: Flexgroup, Inodes limit, Volumes count- NFS


Flexgroup and Files Count:
NFSv3 in ONTAP uses 32-bit file IDs by default. 32-bit file IDs are limited to 2,147,483,647 maximum unsigned integers. With the two-billion inode limit in FlexVol, this value fits nicely into the architecture. 

However, because NetApp FlexGroup volumes can officially support up to 400 billion files in a single container (and theoretically, many more), the implementation of 64-bit file IDs was needed. 64-bit file IDs support up to 9,223,372,036,854,775,807 unsigned integers. The 64-bit file identifier option is off by default. 

This was by design, to make certain that legacy applications and operating systems that require 32-bit file identifiers were not unexpectedly affected by 34 NetApp ONTAP FlexGroup Volumes .

 ONTAP changes before administrators could properly evaluate their environments. Check with your application and OS vendor for their support for 64-bit file IDs before enabling them. Alternatively, create a test SVM and enable it to see how applications and clients react with 64-bit file IDs. Most modern applications and OSes can handle 64-bit file IDs without issue.

If a FlexGroup volume does not exceed two billion files, you can leave this value unchanged. However, to prevent any file ID conflicts, the inode maximum on the FlexGroup volume should also be increased to no more than 2,147,483,647.



You are Welcome :)
Source: www..netapp.com