Help Center/ GaussDB(DWS)/ FAQs/ Database Connections/ How Applications Communicate with GaussDB(DWS)?
Updated on 2023-04-26 GMT+08:00

How Applications Communicate with GaussDB(DWS)?

For applications to communicate with GaussDB(DWS), make sure the networks between them are connected. The following table lists common connection scenarios.

Table 1 Communication between applications and GaussDB(DWS)

Scenario

Description

Supported Connection Type

Cloud

Service Application and GaussDB(DWS) Are in the Same VPC in the Same Region

Two private IP addresses in the same VPC can directly communicate with each other.

  • gsql
  • Data Studio
  • JDBC/ODBC

For more connection modes, see Methods of Connecting to a Cluster.

Service Applications and GaussDB(DWS) are in Different VPCs in the Same Region

After a VPC peering connection is created between two VPCs, the two private IP addresses can directly communicate with each other.

Service Applications and GaussDB(DWS) Are in Different Regions

After a cloud connection (CC) is established between two regions, the two regions communicate with each other through private IP addresses.

On-premises and on-cloud

Service applications are deployed in on-premise data centers and need to communicate with GaussDB(DWS).

  • Use the public IP address or domain name of GaussDB(DWS) for communication.
  • Use Direct Connect (DC) is for communication.

Service Application and GaussDB(DWS) Are in the Same VPC in the Same Region

To ensure low service latency, you are advised to deploy service applications and GaussDB(DWS) in the same region. For example, if a service application is deployed on an ECS, you are advised to deploy the data warehouse cluster in the same VPC as the ECS. In this way, the application can directly communicate with GaussDB(DWS) through an intranet IP address. In this case, deploy the data warehouse cluster in the same region and VPC where the ECS resides.

For example, if the ECS is deployed in EU-Dublin, select EU-Dublin for the GaussDB(DWS) cluster and ensure that the GaussDB(DWS) cluster and the ECS are both in VPC1. The private IP address of the ECS is 192.168.120.1, the private IP address of GaussDB(DWS) is 192.168.120.2. Therefore, they can communicate with each other through private IP addresses.

The key points in communication check are the ECS outbound rule and GaussDB(DWS) inbound rule. The check procedure is as follows:

  1. Check the ECS outbound rules:

    Ensure that the outbound rule of the ECS security group allows access. If access is not allowed, see the Configuring Security Group Rules.

  2. Check the GaussDB(DWS) inbound rules:

    If no security group is configured when GaussDB(DWS) is created, the default inbound rule allows TCP access from all IPv4 addresses and port 8000. To ensure security, you can also allow only one IP address. For details, see How Do I Configure a Whitelist to Protect Clusters Available Through a Public IP Address?

  3. Log in to the ECS. If the internal IP address of GaussDB(DWS) can be pinged, the network connection is normal. If the IP address cannot be pinged, check the preceding configuration. If the ECS has a firewall, check the firewall configuration.

Example of using gsql for connection:

gsql -d gaussdb -h 192.168.120.2 -p 8000 -U dbadmin -W password -r

Figure 1 Access via Private IP addresses

Service Applications and GaussDB(DWS) are in Different VPCs in the Same Region

To ensure low service latency, you are advised to deploy service applications and GaussDB(DWS) in the same region. For example, if service applications are deployed on an ECS, you are advised to deploy the data warehouse cluster in the same VPC as the ECS. If a different VPC is selected for the data warehouse cluster, the ECS cannot directly connect to GaussDB(DWS).

For example, both ECS and GaussDB(DWS) are deployed in EU-Dublin, but ECS is in VPC1 and GaussDB(DWS) is in VPC2. In this case, you need to create a VPC Peering Connection between VPC1 and VPC2 so that ECS can access GaussDB(DWS) using the private IP address of GaussDB(DWS).

The key points for checking the communication are the ECS outbound rules, GaussDB(DWS) inbound rules, and VPC peering connection. The check procedure is as follows:

  1. Check the ECS outbound rules:

    Ensure that the outbound rule of the ECS security group allows access. If access is not allowed, see the Configuring Security Group Rules.

  2. Check the GaussDB(DWS) inbound rules:

    If no security group is configured when GaussDB(DWS) is created, the default inbound rule allows TCP access from all IPv4 addresses and port 8000. To ensure security, you can also allow only one IP address. For details, see How Do I Configure a Whitelist to Protect Clusters Available Through a Public IP Address?

  3. Create a VPC Peering Connection between VPC1 where the ECS is and VPC2 where GaussDB(DWS) is.
  4. Log in to the ECS. If the internal IP address of GaussDB(DWS) can be pinged, the network connection is normal. If the IP address cannot be pinged, check the preceding configuration. If the ECS has a firewall, check the firewall configuration.

Example of using gsql for connection:

gsql -d gaussdb -h 192.168.120.2 -p 8000 -U dbadmin -W password -r

Figure 2 Access via VPC peering

Service Applications and GaussDB(DWS) Are in Different Regions

If the service application and GaussDB(DWS) are in different regions, for example, ECS is in EU-Dublin and GaussDB(DWS) is in another region, you need to establish a Cloud Connect between the two regions for communication.

Figure 3 Access via cloud connect

Service applications are deployed in on-premise data centers and need to communicate with GaussDB(DWS).

If service applications are not on the cloud but in the local data center, they need to communicate with GaussDB(DWS) on the cloud.

  • Scenario 1: On-premises service applications communicate with GaussDB(DWS) through GaussDB(DWS) public IP addresses.

    Example of using gsql for connection:

    gsql -d gaussdb -h public_IP_address -p 8000 -U dbadmin -W password -r

    Figure 4 Access via public IP addresses
  • Scenario 2: On-premises services cannot access the external network. In this case, Direct Connect is required for communication.
    Figure 5 Access via direct connect