Technical difference between Horizontal Scaling and manually-created DDBs

Last post 02-20-2020, 12:09 PM by Sheree. 4 replies.
Sort Posts: Previous Next
  • Technical difference between Horizontal Scaling and manually-created DDBs
    Posted: 02-15-2020, 1:43 PM

    Hi,

    1. Can someone explain the technical difference between Horizontal Scaling, and manually creating separate DDBs?

    2. The Horizontal Scaling documentation says it creates separate DDBs for "virtual machines, databases, and file system agents" ... Are NDMP or NetApp IntelliSnap backups included in one of the types mentioned?

    3. We have 500+ front-end terabytes of Oracle flatfiles being backed up by the Linux FileSystem Agent, with its own dedicated DDB. Dedupe savings is 87%.  Dedupe savings on the 68 front-end TB of general 'Unix' filesystem agent stuff is 75%.  We're looking to consolidate our 14 DDBs to as few as possible, and it sounds like Horizontal Scaling would lump this in with the File System Agent stuff.  Is that for the best, or does this type of data merit its own DDB?

    Thanks!

    Sheree

  • Re: Technical difference between Horizontal Scaling and manually-created DDBs
    Posted: 02-16-2020, 3:34 AM

    Hi Sheree

    Answers are inline

    1. Can someone explain the technical difference between Horizontal Scaling, and manually creating separate DDBs?

      • The purpose of the Horizontal Scaling is Commvault's way of managing different IDA in a single Global Deduped Policy. The system will automatically detect the IDA and create associated DDB partition for the specific IDA. There are various parameters that can be tuned to manage when new DDB partition are created (i.e. 200 million Blocks before a new DDB partition is created, but existing subclients will still write to the original partition, only new clients will write to the new DDB partition)

    2. The Horizontal Scaling documentation says it creates separate DDBs for "virtual machines, databases, and file system agents" ... Are NDMP or NetApp IntelliSnap backups included in one of the types mentioned?

      • NDMP and NetApp Intellisnap will be classified under the FileSystem agent

    3. We have 500+ front-end terabytes of Oracle flatfiles being backed up by the Linux FileSystem Agent, with its own dedicated DDB. Dedupe savings is 87%.  Dedupe savings on the 68 front-end TB of general 'Unix' filesystem agent stuff is 75%.  We're looking to consolidate our 14 DDBs to as few as possible, and it sounds like Horizontal Scaling would lump this in with the File System Agent stuff.  Is that for the best, or does this type of data merit its own DDB?

      • I believe with your current configuration leveraging the Horizontal Scaled DDB would be the best way forward. With a consolidated single Global Deduped, the system will automatically manage the specific IDA type.
     
    Feel free to reach out if you have any other specific question
     
    Regards
     
    Winston 
  • Re: Technical difference between Horizontal Scaling and manually-created DDBs
    Posted: 02-16-2020, 4:45 PM
    Hi Winston,

    1. I didn't ask what the purpose of Horizontal Scaling is.  The question I actually asked is what is the technical difference between creating my own DDBs for these agent types, versus having Horizontal Scaling do it?

    2. Thanks!

    3. I feel like I'm not being heard, here.  Can you address why it would be better to let Horizontal Scaling lump this data in with FileSystem Agent stuff, after it's already been proven to dedupe better by itself, since Horizontal Scaling won't recognize it as being a separate type of data?


    I'm looking for technical answers here.  Thanks!

  • Re: Technical difference between Horizontal Scaling and manually-created DDBs
    Posted: 02-17-2020, 1:25 AM

    Hi Sheree

    Apologies for miss-interpreting your original questions:

    1.The question I actually asked is what is the technical difference between creating my own DDBs for these agent types, versus having Horizontal Scaling do it

    • Technically there is no difference, Commvault is just providing an ease of scalability by automatically managing the segragation of the IDA types, if multiple IDA are associated to a single Global DDB Policy. If you already have an existing Global DDB Policy where the IDA is separated then there is no need to re-configure the entire environment to leverage Horizontally Scaled DDB
    3. Can you address why it would be better to let Horizontal Scaling lump this data in with FileSystem Agent stuff, after it's already been proven to dedupe better by itself, since Horizontal Scaling won't recognize it as being a separate type of data?
    • Sorry I missed the part about Flat File and Linux FS, I was to focus on the 14 separate DDB's
    • Your original assumption is correct, as the FlatFile is backed up under a Linux FS iDA this will be lumped into the FS IDA if you are to use Horizontal Scaled DDB
    • This will definitely be better to have a separate Global DDB (and not be lumped with a Horizontally Scaled DDB). 
    Regards
     
    Winston 
  • Re: Technical difference between Horizontal Scaling and manually-created DDBs
    Posted: 02-20-2020, 12:09 PM

    Thanks, Winston--that helped a lot!

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy