Split Commcell Design

Last post 05-30-2011, 8:18 PM by Brad Scott. 5 replies.
Sort Posts: Previous Next
  • Split Commcell Design
    Posted: 05-27-2011, 12:00 AM

    All,

    We manage backups across differen't networks in house.

    They are all connected but some way more 'dirty' than others.

    So much so we have had to create nats for every machine at points.

     

    I am thinking of utilizing a split commcell design or child commcells.

    Main site (10.10.10.x)

    Main Commcell (10.10.10.4), MA, Dedup.

    Child site (192.168.1.x)

    Child Commcell (192.168.1.4), MA, Dedup

    All child site clients talk to the 192 CS, MA, and dedup.

    The child Commcell has 1 nat to talk to the main Commcell.

     

     

    Am I understanding the point of split commcell design?  Any drawbacks?  I understand when I launch the Commcell GUI from my main site commcell (10.10.10.10.4) I will be able to manage all the clients in the child site as if it were just 1 Commcell?  What happens if the link between the main and child commcell goes down? 

  • Re: Split Commcell Design
    Posted: 05-27-2011, 4:56 PM

    Hi Joer,

    Thank you for your inquiry. The CommCell Split or (CommCell Clone) is mainly intended for breaking down large CommCells into smaller more manageable CommCells. When using the split CommCell process you end up with two different CommCell id's.

    Example: you have CommCell (A) Fxxx and this backups up 200 clients. You can split this CommCell into an additional CommCell (B) Bxxx and have 100 Clients backup through CommCell (A) and the other 100 clients backup through CommCell (B). Each CommCell will have its own CommCell id/ Ip address and will have its on GUI separate from each other. You will not be managing both sites with the same CommCell Console GUI.

    Please see BOL:

    Splitting CommCells

    http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/cloning/commcell_cloning.htm

    Dave W.

  • Re: Split Commcell Design
    Posted: 05-30-2011, 6:37 PM

    Dave,

     

    Thanks for the insight. I guess I misunderstood the purpose of splitting your commcell. So my original issue stands where I have many clients under different networks. Currently we just have a bunch of nats setup.  We are wanting to get away from this alltogether. 

     

    Is there any solutions I am not thinking of? I dont want to split everything and have differen't GUIs to manage.

  • Re: Split Commcell Design
    Posted: 05-30-2011, 6:44 PM

    With V9 you can get away without having NATs at all by using firewall rules within the CommCell that force the clients to connect to the CommServe/MA rather than the other way around. That way you only have to ensure that all your clients can resolve and communicate to your Commserve and MA.

    I manage an environment where we have customers connect in to our environment from the internet over HTTPs and no name resolution or NATs are in use. Works fairly well.

  • Re: Split Commcell Design
    Posted: 05-30-2011, 7:41 PM

    Squify:

    With V9 you can get away without having NATs at all by using firewall rules within the CommCell that force the clients to connect to the CommServe/MA rather than the other way around. That way you only have to ensure that all your clients can resolve and communicate to your Commserve and MA.

    I manage an environment where we have customers connect in to our environment from the internet over HTTPs and no name resolution or NATs are in use. Works fairly well.

     

    This sounds like what I need. For all purposes the 192 network is seperated from the 10.10 network in the example above. Currently the CS is 10.10.10.3 let say. Well on the 192 network in DNS we will have the CS 192.168.3.3 and have a nat on the firewall.

    I guess I need to read more about firewalls and conections but ideally I would love that no nats would be in use. I am failing to understand how that would work though.

  • Re: Split Commcell Design
    Posted: 05-30-2011, 8:18 PM

    You will still need the NATs for the CommServe and the MediaAgent just not all the clients. Essentiall what you are doing is telling all the clients that they are now responsible for making a connection to the CommServe/MA rather than the other way around. Once the connection is established the client holds it open and keeps communication open for the CommServe to send commands to it.

     

    Hope this makes sense. The firewall config can be a bit of a nightmare when you first start out but trial and error go along way and of course BOL will at least get you started if nothing else.

     

    Brad

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