v11 OpenStack Ports and The proxy is not an OpenStack instance

Last post 04-21-2020, 12:51 PM by shlee@synergyds. 4 replies.
Sort Posts: Previous Next
  • v11 OpenStack Ports and The proxy is not an OpenStack instance
    Posted: 04-02-2020, 12:32 PM

    Hi Guys,

    I have a deployment for backing up OpenStack VM. There is a hiccup where 1 of the box sitting in DMZ zone. I have requested customer to open ports for 8400, 8401, 8403, 35357, 5000. Connection from proxy to the keystone was successful but could not browse any VMs until logs showing connection failed to connect to Nova through ports 8774 & 9292.

    Ports 35357, 5000, 8774 & 9292 were not mentioned under https://documentation.commvault.com/commvault/v11/article?p=3349.htm

    Port Requirements

    • The security group associated with the proxy instance should permit all incoming and outgoing TCP traffic.
    • If unrestricted access cannot be set up, configure a one-way Commvault firewall between the CommServe host or MediaAgent and the VSA proxy instance. With this firewall configuration, you can restrict communication to a single TCP port (typically port 8400).
    • When using the RHEL-OP distribution or in any OpenStack environment that includes a firewall, ensure that CVD port 8400 is configured to accept incoming traffic from Commvault.

     

    Question:

    1) What are the essential ports required? 

    2) Proxy was deployed and running in the same region in OpenStack. But backup failed with "The proxy is not an OpenStack instance; please select a proxy running as instance in OpenStack to backup." Any idea to explain this situation? (There are no issue on the other 2 OpenStack box)

    Can someone share some ideas on above situation? attached job logs for reference.

    Thanks,

    shlee

  • Re: v11 OpenStack Ports and The proxy is not an OpenStack instance
    Posted: 04-20-2020, 12:35 AM

    Hi Shlee

    8400 is the default communication port that is required for Proxy, MA and CommServe to communicate on. If there are port restrictions within the environment you will need to configure Commvault Network Routes to indicate to the Proxy, MA and CommServe to confirm which component will start the application tunnel (whether it is bi-directional or one-way)

    How is the Network Routes configured between the Proxy and the Openstack VM?

    Regards

    Winston 

  • Re: v11 OpenStack Ports and The proxy is not an OpenStack instance
    Posted: 04-21-2020, 12:16 PM

    Wwong:

    Hi Shlee

    8400 is the default communication port that is required for Proxy, MA and CommServe to communicate on. If there are port restrictions within the environment you will need to configure Commvault Network Routes to indicate to the Proxy, MA and CommServe to confirm which component will start the application tunnel (whether it is bi-directional or one-way)

    How is the Network Routes configured between the Proxy and the Openstack VM?

    Regards

    Winston 

     

    Hi Winston, 

    Thanks for dropping msg here.

    After opening support ticket, only I found out there are more ports required for backing up OpenStack environment. Those ports are not listed in BOL.

    https://docs.openstack.org/kilo/config-reference/content/firewalls-default-ports.html

    After webex session, I have requested end user to open up ports as listed, however still encountered below ports are required.

    ERROR: Connect to CS:49956 failed: Connection refused

    ERROR: Connect to CS:49937 failed: Connection refused

    ERROR: Connect to CS:49992 failed: Connection refused

    The final solution was reqesting user to open up all ports listed in logs and backup/restore are going through.

    It is abit confusing when BOL does not state those ports out until a support ticket required. Just my personal opinion.

     

    Thanks and regards,

    Lee

  • Re: v11 OpenStack Ports and The proxy is not an OpenStack instance
    Posted: 04-21-2020, 12:22 PM
    • Aplynx is not online. Last active: 06-04-2020, 4:59 PM Liam
    • Top 10 Contributor
    • Joined on 05-04-2010
    • New Jersey
    • Master
    • Points 1,838

     

    The GxCVD service dynamically uses free ports between 49152 and 65535 to communicate during data protection and data recovery jobs. The system dynamically assigns a number of free ports to be used by each job to allow parallel data movement. After the job is finished, if no other job is pending, the dynamic ports are released.

    http://documentation.commvault.com/commvault/v11/article?p=8572.htm

    You customize the port usage with the network configuration. 

     

  • Re: v11 OpenStack Ports and The proxy is not an OpenStack instance
    Posted: 04-21-2020, 12:51 PM

    Aplynx:

     

    The GxCVD service dynamically uses free ports between 49152 and 65535 to communicate during data protection and data recovery jobs. The system dynamically assigns a number of free ports to be used by each job to allow parallel data movement. After the job is finished, if no other job is pending, the dynamic ports are released.

    http://documentation.commvault.com/commvault/v11/article?p=8572.htm

    You customize the port usage with the network configuration. 

     

     

    Hi Liam,

    Thanks for the info. Before I could run the backup. Those ports are required for me to perform discovery of the OpenStack VMs which are not stated in BOL. (Perhaps I missed out reading it somewhere)

    35357
    8776
    8774
    8773
    8775
    9292
    9696
    According to supports, Virtual Server proxy has to be allowed those ports in order to communicate with OpenStack before we could proceed with the backup/restore.
    End user raised question about why those required ports are not listed in BOL system requirement. That is the question that I could not justify as I could not find the ports requirement in BOL.
    I am very new to backing up Openstack, CommVault Support did good job pointed that out and share me the Openstack ports requirement. 
    Thanks and regards,
    Lee 
     
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