> CommCell Console > CommCell Management > CommCell Migration > Performing CommCell Migration

Splitting a CommCell Environment

If you need separate CommCell environments for organizational needs such as providing each team with an environment or balancing capacity usage, you can split a CommCell environment into multiple CommCell environments. And you can move clients between CommCell environments.

Unlike in a CommCell migration, you can take incremental backups, rather than full backups, after splitting a CommCell environment. On average, incremental backups consume less media and place less burden on resources than full backups.

Note

  • You must never perform Commcell migration between the two CommCell environments after the CommCell split. Migration between these CommCell environments causes metadata conflicts.

  • Air gap libraries cannot be migrated or split to a different CommCell environment. These libraries are permanently associated with the CommCell in which they were originally created.

Before You Begin

  • Disable all activities on all the clients that you plan to move to the new CommServe server. You can enable them later after the CommCell split procedure is complete.

  • On the original CommServe server, mark the libraries that are part of the new CommServe server as read only.

  • You can use a library for backup operations on any one of the CommCell environments after the split procedure is complete. You cannot use it on both the CommCell environments.

  • If the original CommServe server has the client group Clients For Commserv LiveSync, disable the sCSINTERFACELIST additional setting in the client group’s properties. Perform the CommServe database dump only after this setting is disabled.

Procedure

  1. Install a new CommServe server.

  2. Move the CommServe database dump file from the original CommServe server computer to the new CommServe server computer.

  3. Restore database dump of the original CommServe server to the new CommServe server using CSRecoveryAssistant in production mode.

  4. On the new CommServe server, stop all CommServe services.

  5. Open the Registry Editor on the CommServe computer, navigate to the following registry path HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\CommServe, add a new DWORD (32-bit) value with the name nEnableCSClientNameUpdate, and set its value to 1.

  6. On the new CommServe server, provide a name to the new CommServe server by running the following command:

    SetPreImagednames.exe CSNAME -displayname newcomputername oldcomputername

    Verify that the new CommServe client name is updated in the database. If the update is not reflected, please contact Support for assistance.

  7. Obtain the latest version of the CommCellSplit.sqle script from Commvault Support, and then copy the script to the <software installation directory>/ Base folder.

    UpdateBundle_Build1100080UpdateBundle_SP36_Form198332

  8. Contact your Commvault Support and obtain the authorization code.

  9. Execute the following command on the new CommServe server:

    Qscript -f BaseFolderLocation\CommCellSplit.sqle -i AUTH_CODE

  10. On the new CommServe server, start the CommServe services.

  11. On both the original and new CommServe servers, run the following command:

    qoperation execscript -sn setConfigParam -si CCM_CONFIG_DO_NOT_FAIL_MIGRATION_FOR_DUPLICATE_GUID -si 2 -si authentication_code

  12. Contact your Commvault Support and obtain the authorization code.

  13. On the new CommServe server, perform the CommCell registration.

    Use an administrator account that does not have two-factor authentication (TFA) enabled.

  14. Using XML script, change the CommServe name for backup clients for which we want to perform the name change to point them from the original CommServe server to the new CommServe server. Perform the following for those backup clients in batches.

    For example:

    <EVGui_ClientNameControlReq commCellId="0" destinationConfiguration="2" isPostMigration="1"
newName="xyz-abc.xyzabc.loc" oldName="gxw.company2.com" operation="139"
setWithoutConditionFlag="0" sourceConfiguration="2">
<header/>
<clientList val="171"/>
<clientList val="170"/>
</EVGui_ClientNameControlReq>

    where

    • newName is the new CommServe server host name

    • oldName is the original CommServe server host name

    • clientList val is the client ID on which we perform the name change

  15. While executing the XML file, make sure that the clients added in the XML file pass check readiness from the original CommServe server, and the new CommServe server is able to ping 8400 port of those clients.

  16. To execute the XML file, run the following command.

    qoperation execute -af XML_FILE_LOCATION\filename.xml

  17. On the new CommServe server, change the library of the disaster recovery storage policy to a new library that is accessible from the new CommServe server.

  18. On the original CommServe server, change the library of the disaster recovery storage policy to a new library that is accessible from the original CommServe server.

  19. Obtain the latest version of the CommcellSplit_UpdateNameAndHostName.sqle script from Commvault Support, and then copy the script to the <software installation directory>/ Base folder.

  20. Execute the following command on both the CommServe computers. The clients.txt must contain the list of clients and MediaAgents that you plan to delete on each CommServe computer respectively. The command invalidates the hostnames of the clients and the MediaAgents which you want to delete on both the CommServe computers.

    Qscript -f CommcellSplit_UpdateNameAndHostName.sqle -i clients.txt 30000

    Where, 30000 is the number of clients in the client list file.

  21. On the original CommServe server, delete the following entities (in the same order) that are now part of the new CommServe server.

    Caution

    Do not use the Retire option.

    • clients

    • storage policies

    • libraries

  22. On the new CommServe server, delete the following entities (in the same order) that are now part of the original CommServe server.

    Caution

    Do not use the Retire option.

    • clients

    • storage policies

    • libraries

  23. Perform test restores for existing jobs in both the original and new CommServe servers.

  24. Verify that the backups run for the same storage policy, deduplication database, and library.

    The CommCell environment is split successfully.

  25. Perform the following steps to apply the license to the new CommCell environment:

    1. Contact your Commvault Support and obtain the following information for each of the new CommServe server:

      • authorization code to update the new GUID of the new CommServe server in the Licensing tables

      • New GUID that has been set by the CommCellSplit.sqle script on the new CommServe server

      • XML license file to apply

      • Latest version of the LicChangeGUID.sqle script

    2. Perform the following steps on each of the new CommServe server:

      1. Stop all running jobs.

      2. To update the GUID in the licensing tables, run the following command :

        qscript -f LicChangeGUID.sqle -i AUTHCODE for that CS ChangeGUID NEW GUID for that CS

      3. Before applying the license, run the following command:

        qscript -f LicChangeGUID.sqle -i Same authcode PreLicApply NEW GUID for that CS

      4. Apply license manually on the CommServe server (through CommCell Console or Command Center) using the obtained XML license file.

      5. To activate the license, run the following command:

        qscript -f LicChangeGUID.sqle -i Same authcode PostLicApply NEW GUID for that CS

        Caution

        Synthetic full backups may fail on some subclients. To overcome the issue, we recommend that you perform full backups.

What to Do Next

  • Enable activities that you disabled earlier on the clients that you moved to the new CommServe server.

  • On the new CommServe server created after the split, on the libraries that you want to use for backup operations, add a new mount path and provide write access only for that new mount path. The mount paths that already exist must remain in read only mode.

  • If you disabled the sCSINTERFACELIST setting in the client group’s properties on the original CommServe server, then re-enable it. On the new CommServe server, delete the Clients For Commserv LiveSync client group.

×

Loading...