Solving connectivity problems with Database Performance Analyzer and AWS EC2 or RDS databases You have provisioned Database Performance Analyzer (DPA) on AWS,or maybe installed Database Performance Analyzer by yourself on an EC2 instance. Your next step is to let DPA know which database instances you want to monitor. You have started the Register Instance Wizard. Then, you get the following message: “The host could not be found.” Or maybe you did not even get that far and you cannot connect to DPA itself when running on Amazon Web Services (AWS).

The purpose of this article is to guide you through several potential problem causes and help you resolve this problem.

Possible causes We will check the following possible causes one by one:

1. I cannot even connect and login to DPA! 2. Are you selecting the correct database engine? 3. Are you using the correct Amazon Elastic Compute Cloud (EC2) or Amazon Relational Database

Service (RDS) endpoint? 4. Are you using the right credentials? 5. Is your database running? 6. Are your security groups properly configured? 7. Is your Windows firewall properly configured? 8. Are your VPC ACLs properly configured?

For the purposes of this article, we will assume that your target database is Microsoft SQL Server, but the instructions are similar if you are running an Oracle database.

1. I cannot even connect and login to DPA! If you can already connect to DPA but don’t know your credentials, remember that the default user is dpa and your password is the instance_id of your EC2 instance. Only you can retrieve the instance_id from the AWS EC2 console.

You have already visited AWS and provisioned the DPA AMI there. You were given an EC2 instance with DPA deployed into it. Let’s assume your instance has a public Domain Name Server (DNS) address of ec2-54-175-249-214.compute-1.amazonaws.com. But you are unable to reach this address in your browser.

The most likely cause is an improperly configured security group. It is also possible that an Access Control List (ACL) rule is preventing you from accessing your instance.

DPA in AWS is setup by default to allow HTTP and HTTPS traffic to the EC2 instance from all locations. That is done by configuring the security group providing access to use ports 80 and 443. If those defaults are altered during the last step in provisioning the AMI, or changed after provisioning the AMI, those changes may prevent HTTP and HTTPS access to your instance from your browser.

To resolve this issue, perform the following steps:

1. Login to your EC2 console and locate your EC2 instance.

2. To verify that the security group rules allow for HTTP and HTTPS access, click on the view rules link and inspect the security group’s inbound rules. You should see inbound rules for HTTP and HTTPS from all public addresses (CIDR: 0.0.0.0/0) or, if you restricted the traffic to only your IP address, from CIDR: X.X.X.X/32 where X.X.X.X is your workstation’s public IP address. Below, you see HTTP and HTTPS inbound rules allowed for all sources. In this scenario, this security group also had opened access via RDP to allow you to easily connect to the instance from your desktop, but that rule is not enabled by default for DPA in AWS.

If your AWS Virtual Private Cloud (VPC) uses VPC ACLs, make sure that the ACLs allow for inbound AND outbound HTTP and HTTPS traffic from and to your IP address or from all public IP addresses (CIDR: 0.0.0.0/0). Because ACLs are stateless, you must create both inbound and outbound rules. If your environment does not use VPC ACLs, then both inbound and outbound rules will be open for all sources as far as ACL is concerned.

Once you reach DPA, your initial password is your instance id, which only you can get from your EC2 console. Your default user id is dpa.

To learn more about security groups and ACLs in AWS, start here:

• Security groups for EC2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

• “Network ACLs”: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

2. Are you selecting the correct database engine? DPA supports a variety of database engines, including Oracle and SQL Server, whether on EC2 or on RDS. Make sure to select the right choice in the wizard. For example, if you installed the database yourself on EC2 instances, then select the database choices of the top, Self-Managed group. If your database is running on RDS, select the ones on the bottom group.

3. Are you using the correct EC2 or RDS endpoint? For databases running on EC2 If your target database is running on an EC2 instance, DPA running on AWS can access it through the internal IP address of your instance.

Simply copy-paste that into the Server field on Step 2 of the “Register Instance Wizard.”

For databases running on RDS If your database is running on RDS, go to the RDS console and copy the instance endpoint.

Paste that value into the Server field in Step 2 of the wizard. Make sure to remove the colon and port number at the end of the string (in this example, remove:1433).

4. Are you using the right credentials? When you attempt to register a database instance in Database Performance Analyzer, the software asks for a master user login and its password. The software requires the DBA privileged user in order to create and configure a monitoring user and grant that user necessary privileges. (Note that this information is not stored and can only be used during the duration of the wizard).

Ensure you have the appropriate user id, password, and authentication mode (for example, Windows or SQL authentication in the case of SQL Server).

5. Is the database running? Yes, you still have to check that the database is running, even on AWS!

Make sure the database is not down or rebooting by doing the following:

EC2: Make sure your EC2 instance is running and SQL Server is operational If your database is running on an EC2 instance, first make sure that the instance is running. Go to the EC2 console in AWS.

Click EC2 under the Compute category. Look for your target EC2 instance running your database. It should be in a “running” state like the one below. If it is in “stopped” state, Restart your instance by right-clicking it and selecting Start.

If the instance is in “running” state, login into the server and see that your database is running.

Here, we will assume you have SQL Server Management Studio (SSMS) running on your SQL Server box. If SSMS is not running, , connect to your database using SSMS from your desktop. First, get the password

to get into your EC2 instance. You may have already changed the original password assigned by EC2. If not, right click on the instance and select Get Windows Password.

You must retrieve your key. If you lost your key file and do not remember the Windows password to your instance, you will not be able to connect to it.

Once you have given the AWS console your key, you can click Decrypt password and see it:

Copy the password to your clipboard and run a Remote Desktop Connection. Sign in as an Administrator using that password.

Once you login to your EC2 instance, run SQL Server Management Studio.

You should then be able to connect to your database instance and do something simple. Make sure to use your target database server name (not the name of your DPA EC2 instance) when connecting.

RDS: Make sure your RDS instance is available If your database is running on RDS, go to your AWS console and select RDS under Database.

Click on the desired Instances and you should then be able to see your instance. Ensure the instances are in available states.

As in the EC2 case, connect to it using your favorite database client and ensure you can see the database running.

If somebody rebooted your database,then simply wait until the database comes back up.

6. Are your security groups properly configured? To register a database to manage in DPA, make sure the product can access the database through the appropriate SQL protocol.One reason that your instance could not be accessible is that your security groups may not be properly configured.

An AWS security group acts as a firewall between your database and a Database Performance Analyzer server. You want to make sure that the security group of the EC2 instance where the database is installed, or the RDS instance that is running your database, has an inbound rule that allows SQL traffic over it. Make sure that your EC2 instance that is running DPA allows outbound SQL traffic to your database instance.

It’s a good idea to take a look at all the security groups we have. Here is the current setup:

We will use RDS for this example. Let’s go to the RDS console. Here is the RDS instance that we are trying to connect to.

The security group associated with this RDS instance is called MSSQL, with the ID sg-4864b52c. Click that link to go to the security group’s configuration. We want to make sure that that group is not simply named MSSQL, but that in fact it allows inbound SQL Server traffic.

As we can see below, the MSSQL security group sg-4864b52c actually has an inbound rule for TCP MS SQL traffic on port 1433 from the security group sg-7065b414.. If you go back to the first error screen, you will see that we were in fact trying to connect on the correct port 1433.

We have now verified that the database instance allows inbound MSSQL traffic from source sg-7065b414. Let’s now verify that the Database Performance Analyzer Server is part of this other security

group sg-7065b414 source and that it allows for outbound SQL traffic. Go back to the EC2 console and select your DPA EC2 instance. You then see the security group associated with it. Click that link.

You are now at the security group of the DPA EC2 instance. Here, you have to confirm two things. First, you want to confirm that the EC2 instance is in fact assigned to the Security group defined as source in the security group of your database instance, which we identified as sg-7065b414. Here we can see that the EC2 instance is in fact assigned to that security group (we also could have seen the description, but it’s best to check the Group Ids since descriptions can be duplicative). Second, we want to make sure that this security group sg-7065b414, which is assigned to the EC2 instance, does allow for outbound SQL traffic. We see in this case that it allows for all outbound traffic to all destinations.

Tto learn more about security groups in AWS, start here:

• Security groups for EC2: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

• Amazon RDS Security groups: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html

7. Is your database firewall properly configured? If your database is running behind a firewall, make sure that it allows the SQL traffic of your database engine. More commonly, if your database instance is running on an EC2 instance running Windows, ensure the appropriate Windows ports are active in Windows firewall. Below we see that port 1433 is open in the EC2 instance for inbound traffic to the target database. It is possible that someone might have also modified the Windows firewall settings.

Verify that the Windows firewall rules on the EC2 instance running Database Performance Analyzer have not been changed. When provisioning the software on AWS via the Amazon Machine Image (AMI), we ensure that inbound ports for HTTP and HTTPS are open for inbound traffic so that you can use the web client from your desktop. Since the default for Windows Server in EC2 is that all outbound traffic is allowed, this is an unlikely possibility, unless somebody actually added restricted outbound rules to the Windows Firewall of your EC2 instance running DPA.

8. Are your VPC ACLs properly configured? In addition to Security Groups, AWS has an extra level of security in VPC called Network ACLs. Network ACLs provide additional firewall capabilities to control traffic in and out of subnets. ACLs rules are stateless. This means that f your configuration uses ACLs, you must ensure that both inbound and outbound rules exist.

To check, and, if necessary, apply these rules, perform the following steps:

1. Click VPC under Networking in the AWS console.

In this simple setup, all traffic is allowed.

2. If your setup does not look like the figures above, click Edit on the ACL and ensure that both a MSSQL outbound rule AND an MSSQL inbound rule exist. Again, ACL rules are stateless, so you must edit both the Inbound Rules and the Outbound Rules in the ACL.

For more information on VPC ACLs, see the “Network ACLs” documentation from AWS at http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

Still having issues? We hope this article can help you solve your connectivity problems. But if you are still having issues, reach out to a systems engineer at Solarwinds. Send an email to: dpa-aws@solarwinds.com and we will be glad to help you.

Happy performance monitoring with DPA for AWS.