Networking Requirements

The hostname, DNS, IP address and accessibility of this information must be consistent. For the installation to operate successfully, each host must be identifiable and accessible to each other host, either by name or IP address.

Individual hosts within your deployment must be reachable and must conform to the following:

• Do not use the localhost or 127.0.0.1 addresses.

• Do not use Zeroconf (.local) addresses. These may not resolve properly or fully on some systems.

• The server hostname (as returned by the hostname) must match the names you use when configuring your service.

• The IP address that resolves on the hostname for that host must resolve to the IP address (not 127.0.0.1). The default configuration for many Linux installations is for the hostname to resolve to the same as localhost:

  127.0.0.1 localhost
  127.0.0.1 host1

• Each host must be able to resolve the address for all the other hosts in the deployment. To prevent errors within the DNS system causing timeouts or bad resolution, all hosts should be added to /etc/hosts:

  127.0.0.1     localhost
  192.168.1.60  host1
  192.168.1.61  host2
  192.168.1.62  host3
  192.168.1.63  host4

  In addition to explicitly adding hostnames to /etc/hosts, the name server switch file, /etc/nsswitch.conf should be updated to ensure that hosts are searched first before using DNS services. For example:

  hosts:          files dns

  Important

  Failure to add explicit hosts and change this resolution order can lead to transient DNS resolving errors triggering timeouts, connections failures, and in a Tungsten Cluster, failsafe switching of hosts.

• The IP address of each host must resolve to the same IP address on each node. For example, if host1 resolves to 192.168.0.69 on host1, the same IP address must be returned when looking up host1 on the host host2.

To double check this, you should perform the following tests:

1. Confirm the hostname:

   shell> uname -n

   Warning

   The hostname cannot contain underscores.

2. Confirm the IP address:

   shell> hostname --ip-address

3. Confirm that the hostnames of the other hosts resolve correctly to a valid IP address. You should confirm on each host that you can identify and connect to each other host in the planned deployment:

   shell> nslookup host1
   shell> ping host1

   If the host does not resolve, either ensure that the hosts are added to the DNS service, or explicitly add the information to the /etc/hosts file.

   Warning

   If using /etc/hosts then you must ensure that the information is correct and consistent on each host, and double check using the above method that the IP address resolves correctly for every host in the deployment.

Witness Hosts

Applies to: Tungsten Clustering for MySQL

Tungsten Cluster includes support for verifying the network status using a witness host.

Active Witness Hosts operate as standalone managers, and therefore require the same rights and requirements as a standard Tungsten Cluster host.

Network Ports

The following network ports should be open between specific hosts to allow communication between the different components:

Component	Source	Destination	Port	Purpose	Product
All Services	All Nodes	All Nodes	ICMP Ping	Checking availability (Default method)	CTTR
"	"	"	7	Checking availability	CTTR
Database Service	Database Host	Database Host	2112	THL replication	CTTR
"	"	"	7800-7805	Manager Remote Method Invocation (RMI)	CT
"	"	"	9997	Manager Remote Method Invocation (RMI)	CT
"	"	"	10000-10001	Replication connection listener port	CT
"	"	"	11999-12000	Tungsten manager	CT
Connector Service	Connector Host	Manager Hosts	11999	Tungsten manager	CT
Connector Service	"	"	13306	Database connectivity	CT
Client Application	Client	Connector	3306	Database connectivity for client	CT
Tungsten Replicator	Replicator Extractor	Database Host	3306	Database Connectivity for Replicator	CTTR
"	Replicator Applier	Database Host	[DB-PORT]	Appropriate DB port for Target Database for Hetereogeneous targets	CTTR

For composite clusters, communication between each cluster within the composite configuration can be limited to the following ports:

Component	Port	Purpose
Database service	9997	Manager Remote Method Invocation (RMI)
"	2112	THL replication
"	11999-12000	Tungsten Manager
Client Application	13306	MySQL port for Connectivity
Manager Hosts	ICMP Ping	Checking availability (default method)
"	7	Checking availability

For Composite Active/Active and Multi-Site/Active-Active clusters that communicate through replication, the communication between sites can be limited to the following ports:

Component	Port	Purpose
Replicator Service	2113-211x	THL replication (See Note Below)
"	10002-10003	Replication connection listener ports
Client Application	13306	MySQL port for Connectivity
Manager Hosts	ICMP Ping	Checking availability (default method)
"	7	Checking availability

For Tungsten Clustering

Within Composite Active/Active, the THL ports configured for the cross-site replication is automatically configured to start at port 2113 and increment by 1 for each additional cross-site service. For example in a 2 cluster configuration, port 2112 would be configured for the local replication, and 2113 for the cross-site replication. In a 3 cluster configuration, port 2112 would be configured for the local replication and ports 2113 and 2114 for each of the cross-site replicators, therefore firewall rules should be configured accordingly to factor in the additional THL ports based on the deployment topology.

Within Multi-Site/Active-Active the THL ports will be configured manually by the user within the tungsten.ini configuration and these should be accounted for when configuring the firewall rules accordingly.

If a system has a firewall enabled, in addition to enabling communication between hosts as in the table above, the localhost must allow port-to-port traffic on the loopback connection without restrictions. For example, using iptables this can be enabled using the following command rule:

shell> iptables -A INPUT -i lo -m state --state NEW -j ACCEPT