Celerra Capacity Limits

Thanks to Rainer for the confirmation and sorry for any confusion.

Regards,
Sandip

Correction - the Capacity limits I mentioned in my earlier post was valid earlier which has been revised (Yasushi coorectly pointed it out) as per October's NAS Support Matrix.

The new Capacity per Data Mover is

NS20 - 16 TB
NS40 - 20 TB
NS80 - 24 TB.

Please note that this is PER DM capacity. I am sure the release notes will be updated soon to reflect the changes.

Thanks,
Sandip

Hi Yasushi,

The Capacity Limits for the NS20/40/80 are as follows - NS20 - 10 TB, NS40- 16 TB, NS80 - 20 TB. This is valid for any version of 5.5 NAS code - as NS20/40/80 supports only 5.5 code (no earlier NAS Code) since they are using CX3 arrays at the back. However, if you are going for a New install - it is recommended to go with the latest code available.

Please refer to EMC Support Matrix or E-lab Navigator to get the details of DART Code and Flare Code versions.

Please let me know, if you are looking for any specific code details or if you have any more queries on this subject.

Thanks,
Sandip

Message was edited by:
Sandip
Removed the original message from Yasushi.

is that per datamover capacity limit ? I just talked to my SE and he told me that i can do 42T per datamover on NS80.

yes, that is 24TB FC storage per active data mover in the NS80

The other limit is 32TB per blade for ATA storage in a Backup2Disk environment

Hello Rainer,Sandip,dynamox

Thank you so much for your reply.
I'll check the upcoming 5.5.31 release notes.

Thanks,
Yasushi

Hmm ... i was told that i can do 42T of ATA (750G SATA drives) per data mover.

that might very well be the case

These aren't "hard" limits - the DART code wont refuse to do more and in certain circumstances you can get approval for more via RPQ

For MPFS environments for example we can even go up to 128TB behind a single data mover.

In general a data mover isn't bothered by dormant storage. However normally adding Terabytes also means adding I/O, users, checkpoints, shares,... that do consume CPU and memory - of which there is only a finite amount.

If you look at the last years of Celerra the capacity behind a data mover has been steadily increased - sometimes due to more hardware resources but also due to software efficiency.

This is mostly correct. As long as the data is not built into a filesystem, the Celerra has little interest in the fact that it's out there. Once it is built into a filesystem and mounted to a Data Mover, however, the filesystem bitmap consumes a proportional amount of memory, and when dealing with finite memory resources, limits need to be placed in order to maintain acceptable levels of performance. RPQs for larger filesystems can be approved, but we may request that certain other memory-intensive features not be used, such as checkpoints. These requests would be made to ensure acceptable levels of performance and to ensure filesystem integrity and to limit the risk of downtime due to exhaustion of physical resources.



This is exactly correct. Obviously, as we increase the amount of physical memory, we can accomodate larger filesystems. But this can also be increased with efficiencies in memory management in newer versions of DART.

I started a new thread about Celerra limits. I want to know about the maximum of iscsi connection that can be made to a DM....