DX NetOps Portal web server MySql database connection details
search cancel

DX NetOps Portal web server MySql database connection details

book

Article ID: 385841

calendar_today

Updated On:

Products

Network Observability CA Performance Management

Issue/Introduction

The DX NetOps Performance Management Portal web server uses a MySql database to store information.

The database can be co-located with the Portal web server or it can be installed on a separate remote host.

We are seeing connectivity issues for a remote MySql server install. The firewall rules are impacting the connections being made between the Portal web server and the remote MySql server host. It is closing them when it should not be, breaking Portal functionality. Only service restarts resolve the issue, at least temporarily until the issue returns. What are the MySql connection details that can be used to ensure the firewall rules are properly configured?

Environment

All supported DX NetOps Performance Management releases

Cause

Firewall rules are impacting the connections being made between the Portal web server and the remote MySql server host. It is closing them when it should not be, breaking Portal functionality. Only service restarts resolve the issue, at least temporarily until the issue returns.

Resolution

  • Is there an "unlimited" setting that can be used on the firewall?
    • This is the ideal configuration where the firewall doesn't touch the connections.
    • Is it possible through an approved exception or exemption process?
  • What Ports are used?
    • We use a random port on the Portal host to generate the connection to the MySql host.
    • The MySql host uses port 3306.
  • We use a pool of threads for each of the four Portal server services.
    • We use a pool of 80 threads in the console service.
    • We use a pool of 8 threads in the Device Manager service
    • We use a pool of 40 threads in the Event Manager service
    • We use a pool of 8 in threads in the sso service.
  • Each has a test while idle. We check for idle threads every 5 minutes.
    • This means if a connection is not valid when checked for idleness, it should be dropped/closed.
    • Our validation should run a command with a 3 second timeout. After 3 seconds the command is given up on.
    • The connection pooling will only close connections if during the idle check or borrow check the connection check times out. If we find the validation works, we leave the connection alone to be used by pool.