4.7. Global Settings
There are several settings that are global to all clusters running on the ATM. These parameters can be set in the `Global Settings' section of the configuration program. The following are the global settings that you can configure, as listed in the `Global Settings' menu:
Security Settings
Network Settings
NAT Settings
4.7.1. Security Settings
The security settings determine which machines can access the remote administration capabilities of the cluster. They work much like the TCP wrappers configured in /etc/hosts.allow and /etc/hosts.deny. Normally, you will want to restrict this ability to the local network, particularly the system from which you plan to do administration.
To restrict access to administration of the cluster, follow these steps:
From the tlclbconfig main menu, choose `Global Settings'.
Choose `Security Settings' from the `Global Settings' menu. This will show a list of the security rules in force. If you do not have security rules configured initially, you will not see a list in the window.
Click `Add' to create a new rule.
Enter the IP address of the host or the network that you want to allow or restrict.
Enter the network mask. For a single host, enter 255.255.255.255. If you want to allow or deny a whole network, enter the subnet mask for that network.
Check `allow' if you want this host or network to be allowed to administer the ATM. Check `deny' if you want to prohibit it from accessing the administrative functions.
Click `OK' when you have entered the settings you desire.
You can select each rule and use the `Up' and `Down' buttons to rearrange the rules.
Click `Done' after you have configured all the security rules you want.
You should always set an Allow rule for the address 127.0.0.1 (localhost) and a Deny rule for every other address. This allows the CMC daemon to change parameters, but nobody else. Thus, your security rules list should look like this:
127.0.0.1,255.255.255.255,allowed 0.0.0.0,0.0.0.0,denied |
4.7.2. Network Settings
The global `Network Settings' menu has only one parameter that you can modify. This is the subnet mask. This pertains to the physical subnet that contains all the ATMs. In most cases this will be 255.255.255.0, but some networks may vary. Check with your network administrator, or simply look at the subnet mask of one of the ATM systems.
4.7.3. NAT Settings
One of the forwarding methods you can use to forward traffic to the cluster nodes is Network Address Translation (NAT). One of the advantages of NAT is that you do not have to modify any settings on the node itself. However, you do need to set some things up on the ATM. This is primarily done in the `NAT Settings' section of the `Global Settings' menu.
When using NAT forwarding, your ATM machines should have two network cards installed. One network card will be (indirectly) connected to the Internet. The other will be attached to an internal subnet. This internal subnet can only be accessed from the outside through the Network Address Translation of the primary ATM.
There are only three NAT settings, but understanding how they work can be a little tricky.
The `NAT Subnet' should be set to a network address range that does not exist on your network. This range of addresses will be used to perform the address translation. Incoming client connections will appear to come from this address range after they have been translated by NAT and sent to NAT-forwarded cluster nodes.
It is suggested that you use 10.0.0.0 as the subnet address, unless you have systems that already exist within that address range. This is one of the address ranges that has been reserved for private use. The other reserved network addresses are 172.16.0.0 and 192.168.0.0. Just make sure that there are no actual systems configured with those addresses.
Whatever address range you choose for the `NAT Subnet', do not use addresses from that range anywhere on your network. The addresses are used internally by NAT. If you use the addresses for actual network resources, you will not be able to access those resources.
The `NAT Subnet Mask' corresponds with the `NAT Subnet' setting. However, because the NAT subnet is used to map client connections and is not used for any physical systems, the subnet mask is really telling the ATM how many client connections to be prepared for.
For an average cluster, you should use 255.255.0.0, which will allow for over 65,000 connections. If you have higher traffic demands, you can increase the number of connections by decreasing the number of bits in the NAT subnet mask. The maximum value you can use is 255.0.0.0, which will provide 16 million connections. (This is for 10.0.0.0; for 172.16.0.0, the maximum is 255.240.0.0, and for 192.168.0.0 it is 255.255.0.0.) However, each potential connection will require several bytes of memory in the kernel, so you may not be able to reserve 16 million entries unless you have a lot of system memory. A more realistic value would be 255.240.0.0, which will give you more than 1 million virtual connections.
When using NAT, packets returning to the client must return through the ATM. This is done by setting the default gateway on the NAT-forwarded nodes. They should be set to an address on the ATM. We could use the IP address of one of the network cards on the primary ATM, but that wouldn't work if the ATM went down and a backup ATM had to take over. Therefore, we need to assign a virtual IP address for this gateway, in addition to the virtual IP address for the cluster itself.
While the cluster's virtual address is used for client access, the NAT gateway virtual address is used to send packets back from the cluster nodes. Because the nodes are on a different physical subnet than the cluster's virtual IP address, they cannot use that address as the default gateway. Hence, we must assign another virtual IP address for the NAT gateway.
When implementing NAT, the ATM should have two network cards: one attached to the "internal" network of NAT nodes, and one interface that is accessible to clients on the outside. To choose the NAT gateway address, select an IP address from the "internal" subnet that is not in use. If you are replacing an existing router, use the internal IP address that the router had. That way, you will not have to reconfigure the NAT-forwarded nodes at all.
Once you have determined an address that you can use, enter it into the `Gateway to NAT Subnet' field in the form.
If you have no nodes that use the NAT forwarding method, you can accept the default values. The NAT subnet and subnet mask will be 255.255.255.255 and the gateway will be set to 0.0.0.0.
Below is a diagram showing an example of a cluster using NAT. The virtual IP address of the cluster is 1.2.3.100, and the NAT Gateway has been set to 192.168.0.100. Note that eth0 and eth1 could be on opposite sides; the daemon will assign the NAT Gateway to whichever interface is already on the "internal" NAT subnet.
| If you configure NAT incorrectly, it can cause a large amount of spurious network traffic. It can also cause the ATM to be unable to reach some network resources. |
While configuring NAT on the ATM can be somewhat complicated, it eliminates the need to do any special configuration of the cluster nodes. You can simply replace the default gateway (router) that the nodes were using with the ATM. Just configure the ATM to use the default gateway's old IP address as the ATM's NAT gateway address. If you are building a cluster from scratch, just enter the NAT gateway address when the systems ask you to configure their default gateway.
If you want to get really fancy, you can even have the IP addresses and default gateway settings of the NAT nodes assigned via DHCP. Just set up a DHCP server on the NAT subnet, handing out IP addresses to the nodes. If the nodes have different roles, you will have to make sure that the systems always get the same IP address. If all the cluster nodes handle the same services, and all the addresses that are handed out are configured in the cluster configuration file, it doesn't even matter which IP address each system has.