I think there are several deduplication-related subjects that require thorough documentation by Commvault.
1.) There is a long-standing recommendation to limit deduplication database disks to TWO PER MEDIA AGENT.’
I was able to track this recommendation as far back as Simpana 9.0, but I’m not sure if it pre-dates that.
This limit feels rather arbitrary, and it doesn’t take into account the performance capabilities of the host platform, or advances in computing kit since the original recommendation was made. I can’t find any references showing WHY such a limit should exist.
In my case, I have three Deduplication disks on my media agents (all NVMe SSD), and that runs with zero issues. The Media Agents are spec’d over the recommended Extra Large spec, and they don’t even sweat.
I would like to issue a call to Commvault to really explain why this limitation is in place. The Deduplication Building Block section of the documentation would be an ideal place for this information. The cost of standing up additional Media Agents to comply with this seemingly arbitrary limit can be prohibitive. We’re talking hundreds of thousands of dollars of additional cost.
2.) There are many references to limiting number of DDBs to TWO PER MEDIA AGENT.
This recommendation really bugs me, as it doesn’t take into account the size of the hosted deduplication databases. You can run twenty 50,000,000 block DDBs on a Media Agent with brilliant results. I would need to stand up a minimum of nine additional Media Agents to be in compliance with the recommendation.
This limitation requires an explanation, as the consequences of complying with it may price Commvault out of the enterprise. This should be a key part of the Deduplication Building Block portion of the documentation.