HyperScale Storage Pool with Global Deduplication Policy

Last post 04-29-2019, 10:16 AM by Prasad Nara. 3 replies.
Sort Posts: Previous Next
  • HyperScale Storage Pool with Global Deduplication Policy
    Posted: 04-26-2019, 1:07 PM

    Hi Gurus,

    I would like to know what is the practice to make use of HyperScale Storage Pool once created.

    What is the recommended method between creating a Server Plan or GDP on top of it?

     

    With Command Center, I see adding a Server Plan is a part of completing setting up the storage pool.

     

    what about GDP, what is the best practice to create it on top of HyperScale Storage Pool? Do I need to treat it like creating GDP on GRIDstor? Create one DDB partition on each node? 

     

    Could someone please give me the sample instruction of the way to create a GDP over HyperScale Storage Pool in detail? I cannot find it in BOL. 

     

    Thank you very much,

  • Re: HyperScale Storage Pool with Global Deduplication Policy
    Posted: 04-26-2019, 6:12 PM

    Storage Pool is nothing but a GDP, it just another name of it. So there is no need to create GDP on top of Storage Pool. For HyperScale Storage Pool we automatically creates 2 partitions on each node for 3 node pool and 1 partition for 6 node pool. You can directly create a server plan using storage pool. 

  • Re: HyperScale Storage Pool with Global Deduplication Policy
    Posted: 04-27-2019, 10:51 PM

    Hi Prasad, thank you very much for information.

    There are 2 more questions to ask.

    1) Can I create multiple SPs and point to HyperScale Storage Pool directly, like creating SPs over normal GDP?

    2) In case that I want to do Extended Deduplication mode with HyperScale Storage Pool, is it support creating a GDP (or second Storage Pool) on HyperScale appliances which already have one Storage Pool?

     

    Thank you, 

  • Re: HyperScale Storage Pool with Global Deduplication Policy
    Posted: 04-29-2019, 10:16 AM

    #1. Yes, you can creae as many SPs as you want same as normal GDP. You can treat this as normal GDP.

     

    #2. We don't recommned creating additional GDP. I know you may say one DDB may get overloaded with all the data, it's actually 6 paritioned DDB so it can hold up to 1 PB data. Also in future service pack release we are going to auto scale DDBs by creating multiple DDBs within one StoragePool aka GDP for segregating files like data into one DDB and databases into one DDB...etc. So you never need to worry about DDBs. 

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 © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy