Applies To:Show Versions
3-DNS Controller versions 1.x - 4.x
- 4.6.1, 4.6.0, 4.5 PTF-08, 4.5 PTF-07, 4.5 PTF-06, 4.5 PTF-05, 4.5 PTF-04, 4.5 PTF-03, 4.5 PTF-02, 4.5 PTF-01, 4.5.9, 4.5.0
Planning the 3-DNS Configuration
- Managing traffic on a global network
- Planning issues for the network setup
- Choosing the 3-DNS mode
- Planning issues for the load balancing configuration
- Using advanced traffic control features
Managing traffic on a global network
The 3-DNS Controller is a sophisticated wide-area traffic manager. With a 3-DNS Controller, you can load balance web site traffic and distributed applications across a global network. You can also monitor the health of your network. This section provides a brief overview of how the 3-DNS Controller works within a global network, and how it interacts with any BIG-IP system, EDGE-FX system, or host in the network. The section also illustrates how the 3-DNS Controller works with the big3d agents that run in various locations in the network, and with the local DNS servers that make DNS requests on behalf of clients connecting to the Internet.
The following sample configuration shows the 3-DNS Controllers that load balance connections for a sample Internet domain, siterequest.com.
Understanding a basic 3-DNS configuration
The 3-DNS Controllers in your network sit in specific data centers, and work in conjunction with the BIG-IP systems, EDGE-FX systems, and host servers that also sit in your network data centers. All 3-DNS Controllers in the network can receive and respond to DNS resolution requests from the LDNS servers that clients use to connect to the domain.
Figure 2.1 illustrates the layout of the 3-DNS Controller, BIG-IP system, and host servers in the three data centers. The Los Angeles data center houses one 3-DNS Controller and one BIG-IP system, as does the New York data center. The Tokyo data center houses only one 3-DNS Controller, and one host server.
In the Los Angeles and New York data centers, the big3d agent runs on the 3-DNS Controllers and the BIG-IP systems, but in the Tokyo data center, the big3d agent runs only on the 3-DNS Controller. Each big3d agent collects information about the network path between the data center where it is running and the client's LDNS server in Chicago, as illustrated by the red lines. Each big3d agent also broadcasts the network path information it collects to the 3-DNS Controllers running in each data center, as illustrated by the green, blue, and purple lines.
Each 3-DNS Controller, BIG-IP system, and EDGE-FX system in a data center typically runs a big3d agent.
Synchronizing configurations and broadcasting performance metrics
3-DNS Controllers typically work in sync groups, where a group of controllers shares load balancing configuration settings. In a sync group, any system that has new configuration changes can broadcast the changes to any other system in the sync group, allowing for easy administrative maintenance. To distribute metrics data among the systems in a sync group, the principal 3-DNS Controller sends requests to the big3d agents in the network, asking them to collect specific performance and path data. Once the big3d agents collect the data, they each broadcast the collected data to all systems in the network, again allowing for simple and reliable metrics distribution.
Using a 3-DNS Controller as a standard DNS server
When a client requests a DNS resolution for a domain name, an LDNS sends the request to one of the 3-DNS Controllers that is authoritative for the zone. The 3-DNS Controller first chooses the best available virtual server out of a pool to respond to the request, and then returns a DNS resource record to the requesting local DNS server. The LDNS server uses the answer for the period of time defined within the resource record. Once the answer expires, however, the LDNS server must request name resolution all over again to get a fresh answer.
Figure 2.2 illustrates the specific steps in the name resolution process.
- The client connects to an Internet Service Provider (ISP) and queries the local DNS server to resolve the domain name www.siterequest.com.
- If the information is not already in the LDNS server's cache, the local DNS server queries a root server (such as InterNIC's root servers). The root server returns the IP address of the DNS systems associated with www.siterequest.com, which in this case runs on the 3-DNS Controller.
- The LDNS then connects to one of the 3-DNS Controllers to resolve the www.siterequest.com name. The 3-DNS Controller uses a load balancing mode to choose an appropriate virtual server to receive the connection, and then returns the virtual server's IP address to the LDNS.
- The LDNS caches the answer from the 3-DNS Controller, and passes the IP address to the client.
- The client connects to the IP address through an ISP.
Load balancing connections across the network
Each of the load balancing modes on the 3-DNS Controller can provide efficient load balancing for any network configuration. The 3-DNS Controller bases load balancing on pools of virtual servers. When a client requests a DNS resolution, the 3-DNS Controller uses the specified load balancing mode to choose a virtual server from a pool of virtual servers. The resulting answer to this resolution request is returned as a standard A record.
Although some load balancing configurations can get complex, most load balancing configurations are relatively simple, whether you use a static load balancing mode or a dynamic load balancing mode. More advanced configurations can incorporate multiple pools, as well as advanced traffic control features, such as topology or production rules.
For more information on specific load balancing modes, see Chapter 2, Load Balancing in the 3-DNS Reference Guide. For more information on load balancing configurations, review the sample configurations in Chapter 6, Configuring a Globally-Distributed Network , and Chapter 7, Configuring a Content Delivery Network . If you are unfamiliar with the 3-DNS Controller, you may also want to review Chapter 5, Essential Configuration Tasks .
Working with 3-DNS Controllers and other products
The 3-DNS Controller distributes connections across a group of virtual servers that run in different data centers throughout the network. You can manage virtual servers from the following types of products:
- BIG-IP systems
A BIG-IP virtual server maps to a series of content servers.
- EDGE-FX systems
An EDGE-FX virtual server maps to cached content that gets refreshed at frequent intervals.
- Generic host
A host virtual server can be an IP address or an IP alias that hosts the content.
- Other load balancing hosts
Other load balancing hosts map virtual servers to a series of content hosts.
Figure 2.3 illustrates the hierarchy of how the 3-DNS Controller manages virtual servers.
Planning issues for the network setup
After you finish running the Setup utility, and connect each system to the network, you can set up the network and load balancing configuration on one 3-DNS Controller, and let the sync group feature automatically broadcast the configuration to the other 3-DNS Controllers in the network. You do not have to configure the 3-DNS Controllers individually, unless you are planning an advanced configuration that requires different configurations for different data centers, or you are configuring the 3-DNS Controllers from the command line.
If you are configuring additional 3-DNS Controllers in a network that already has a 3-DNS Controller in it, please review Chapter 10, Adding a 3-DNS Controller to an Existing Network .
During the network setup phase, you define four basic aspects of the network layout, in the following order:
- Base network
The base network includes the interfaces, VLANs, and trunks for the network topology. Configuring the base network installs the 3-DNS Controller in your physical network.
- Data centers
Data centers are the physical locations that house the equipment you use for load balancing.
- Data center servers
The data center servers that you define in the network setup include the 3-DNS Controller, BIG-IP systems, EDGE-FX systems, and host systems that you use for load balancing and probing.
- Sync group
A sync group defines the group of 3-DNS Controllers that shares configuration settings.
During the setup phase of configuration, we recommend that you connect to the 3-DNS Controller from a remote workstation from which you can complete the remaining configuration tasks using the web-based Configuration utility.
Configuring the base network
The 3-DNS Controller interfaces and the related topics of self IP addresses, VLANs, and trunks are collectively referred to, in this manual, as the base network. The base network, or at least an initial version of it, is configured when you run the Setup utility for the first time. The initial base network configuration also includes such things as the default route for the 3-DNS Controller, fully qualified domain names, and certificate information that can only be configured using the Setup utility or its components. (To make changes to other base network components, such as domain names, default routes, and certificate information, refer to Chapter 3, Using the Setup Utility , which describes the Setup utility and its various components.)
A 3-DNS usually has two network interfaces. Each active interface must be configured with a VLAN membership, and each VLAN must have a self IP address. Note that most 3-DNS configurations require only one interface, VLAN, and self IP address. However, if you are configuring the 3-DNS Controller in bridge mode or router mode, you may need to configure two (or more) interfaces, depending on your network requirements. For more information on configuring the base network, refer to Chapter 4, Post-Setup Tasks .
Defining data centers and servers
In the 3-DNS configuration, it is important that you define all of your data centers before you begin defining the data center servers. This is because when you define a server, you specify the data center where the server runs. (You do this by choosing a data center from the list of data centers you have already defined.) To define a data center, you need only specify the data center name. To define a server, however, you need to specify the following items:
- Server type (3-DNS Controller, BIG-IP system, EDGE-FX system, router, or host)
- Server IP address (or shared IP alias for redundant systems)
- Name of the data center where the server runs
- The big3d agent factories (on 3-DNS Controller, BIG-IP system, and EDGE-FX systems only)
- Virtual servers managed by the server (BIG-IP system, EDGE-FX system, and host systems only)
- SNMP host probing settings (hosts only)
One important aspect of planning your network setup is to decide how to set up the big3d agent, and which ports you need to open for communications between the systems in your network. See the 3-DNS Reference Guide, Chapter 5, Probing and Metrics Collection, for help with determining how both of these issues affect your installation.
Planning a sync group
A sync group is a group of 3-DNS Controllers that share configuration information. In a sync group, a principal 3-DNS Controller issues requests to the big3d agents on all the other systems to gather metrics data. Both the principal 3-DNS Controller and the receiver 3-DNS Controllers in the sync group receive broadcasts of metrics data from the big3d agents. All members of the sync group also receive broadcasts of updated configuration settings from the 3-DNS Controller that has the latest configuration changes.
When you define the sync group, you select the sync group members from the list of 3-DNS Controllers you have already defined. The sync group lists the 3-DNS Controllers in the order in which you selected them. The first 3-DNS Controller in the list becomes the principal 3-DNS Controller. The remaining 3-DNS Controllers in the list become receivers. If the principal 3-DNS Controller becomes disabled, the next 3-DNS Controller in the list becomes the principal 3-DNS Controller until the original principal 3-DNS Controller comes back online.
Understanding how a sync group works
The sync group feature synchronizes individual configuration files, such as wideip.conf, and other files that store system settings. You have the option of adding files to the synchronization list.
The 3-DNS Controllers in a sync group operate as peer servers. At set intervals, the syncd utility compares the time stamps of the configuration files earmarked for synchronization on all of the 3-DNS Controllers. If the time stamp on a specific file differs between 3-DNS Controllers, the 3-DNS Controller with the latest file broadcasts the file to all of the other 3-DNS Controllers in the group.
Understanding how the time tolerance variable affects a sync group
The time tolerance variable is a global variable that defines the number of seconds that the time setting on one 3-DNS Controller can be ahead or behind the time setting on another 3-DNS Controller. If the difference between the times on the systems is greater than the time tolerance, the time setting on the 3-DNS Controller running behind is reset to match the 3-DNS Controller with the most recent time. For example, if the time tolerance is 5 seconds, and one 3-DNS Controller is running 10 seconds ahead of the other, the 3-DNS Controller running behind has its time reset to match the one running 10 seconds ahead. If the second system was running only 2 seconds ahead of the other, the time settings would remain unchanged. The values are 0, 5, and higher (values of 1-4 are automatically set to 5, and 0 turns off time synchronization). The default setting is 10 seconds.
The time setting on 3-DNS Controllers is important because a 3-DNS Controller compares time stamps on files when deciding whether to synchronize files with other 3-DNS Controllers in the sync group.
Setting up communications on a 3-DNS Controller
There are three different communication issues that you need to resolve when you set up communication between the 3-DNS Controllers running in your network.
- 3-DNS Controllers communicating with other 3-DNS Controllers
To allow 3-DNS Controllers to communicate with each other, you must set up ssh and scp utilities.
- 3-DNS Controllers communicating with BIG-IP systems and EDGE-FX systems
To allow the 3-DNS Controller to communicate with BIG-IP systems and EDGE-FX systems, you address the same ssh issues.
- 3-DNS Controllers communicating with big3d agents
To allow communications between big3d agents and the 3-DNS Controller, you need to configure iQuery ports on any 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems that run the big3d agent.
Setting up communication between crypto and non-crypto systems
The 3-DNS Controllers in your network need to communicate with each other in order to synchronize configuration and performance data. If you use exclusively crypto 3-DNS Controllers (those that use the SSH protocol) the communication tools set up by the Setup utility are all you need.
If your network is a mixed environment, that is, composed of both crypto and non-crypto systems, you need to enable the rsh and rcp utilities on the crypto systems. Though the rsh and rcp utilities come pre-installed on the crypto systems, you must explicitly enable these utilities. You can enable the utilities using the Setup utility. Table 2.1 shows the ports and protocols used for SSH and RSH communications between crypto and non-crypto systems.
Setting up data collection with the big3d agent
The big3d agent collects performance information from other 3-DNS Controllers, BIG-IP systems, and EDGE-FX systems on behalf of the 3-DNS Controller you are configuring. The 3-DNS Controller then uses this performance data for load balancing. The big3d agent uses factories to manage the data collection. For detailed information on configuring the big3d agent, managing the factories, opening the UDP ports, and working with firewalls, review Chapter 5, Probing and Metrics Collection , in the 3-DNS Reference Guide.
Choosing the 3-DNS mode
The 3-DNS Controller can run in one of three modes: node, bridge, or router. The base network configuration changes depending on which mode you choose. The following sections describe the three modes and provide basic configuration examples.
Running a 3-DNS Controller in node mode
Node mode is the traditional way to configure the 3-DNS Controller. The benefits of running the 3-DNS Controller in node mode are as follows:
- You can replace your name servers with 3-DNS Controllers.
- You can use the 3-DNS Controller as the authoritative DNS server for your domain.
- You can manage your DNS zone files with NameSurfer.
When you replace your DNS servers with 3-DNS Controllers, you can use the extensive wide-area traffic management capabilities of the 3-DNS Controller in conjunction with the standard DNS protocol. When the 3-DNS Controller receives a request that matches a wide IP, it routes that request to the best virtual server in your network. When a 3-DNS Controller receives a non-matching request, that request is handled by the BIND utility (named) that is running on the 3-DNS Controller.
When you configure the 3-DNS Controller to be authoritative for your domain, you can easily manage DNS zone files using NameSurfer, a browser-based, third-party application included on the 3-DNS Controller. When you define wide IPs in the Configuration utility, the NameSurfer application automatically makes the appropriate additions to the zone files. The changes are then broadcast to the other 3-DNS Controllers in your network.
If you configure wide IPs from the command line, you need to make the corresponding zone file changes from the command line.
Using the 3-DNS synchronization features
If you use the advanced synchronization features of the 3-DNS Controller, we strongly recommend that you configure each 3-DNS Controller to run as authoritative for the domain. This type of configuration offers the following advantages:
- You can change zone files on any one of the 3-DNS Controllers in the network and have those changes automatically broadcast to all of the other systems in the network.
- Each 3-DNS Controller has the most up-to-date zone files, providing you one or more layers of redundancy.
- The NameSurfer application automatically controls the addition, configuration, and deletion of zone files.
Importing BIND files to NameSurfer during an initial installation
During the initial configuration, you can specify that the 3-DNS Controller import any existing BIND files from your name server to the 3-DNS Controller. During the initial configuration, you can also designate NameSurfer as the primary name server for your domain. This forces NameSurfer to automatically format your BIND files in the NameSurfer format. For more information, refer to the NameSurfer documentation available from the home screen in the Configuration utility.
Running a 3-DNS Controller in bridge mode or router mode
Running the 3-DNS Controller in bridge mode or router mode offers the following benefits:
- You gain the wide-area traffic management capabilities of the 3-DNS Controller without disrupting your current DNS system.
- In an enterprise, you can install, configure, and test the 3-DNS Controller before you add the system to your production environment.
- You do not use NameSurfer to manage your zone files.
- You can load balance requests across two separate IP networks.
When you configure the 3-DNS Controller in bridge mode, you install the 3-DNS Controller into your network so that all DNS requests are intercepted by the 3-DNS Controller before they are sent to your name server for resolution. Based on the content of the request, the 3-DNS Controller does one of the following:
- If the request matches a wide IP managed by the 3-DNS Controller, the system responds to the request with the best available virtual server in your network.
- If the request does not match any wide IPs managed by the 3-DNS Controller, the system forwards the request to the DNS server for resolution.
Planning issues for the load balancing configuration
The final phase of installing a 3-DNS Controller is setting up the load balancing configuration. Load balancing configurations are based on pools of virtual servers in a wide IP. When the 3-DNS Controller receives a connection request, it uses a load balancing mode to determine which virtual server in a given pool should receive the connection. The virtual servers in the pool can be the virtual servers managed by a BIG-IP system, virtual servers managed by an EDGE-FX Cache, virtual servers managed by a generic host server, or they can be individual host servers themselves. Note that the 3-DNS Controller continuously verifies which virtual servers in the pool are currently available to accept load balanced connections.
Simple configurations typically use a single pool of virtual servers and a load balancing mode that does not require significant additional configuration steps, such as Round Robin or Hops. More advanced load balancing configurations can use multiple wide IPs, multiple pools, customized load balancing modes, and other advanced traffic control features, such as topology load balancing and production rules.
Using advanced traffic control features
The 3-DNS Controller offers two advanced features that you can configure to further control the distribution and flow of network traffic.
- Topology load balancing
With Topology load balancing, you can direct client requests to virtual servers in the geographically closest data center. You can set up Topology load balancing between pools, or within a pool. For details about working with topology-based features, see Chapter 6, Configuring a Globally-Distributed Network , and in the 3-DNS Reference Guide, see Chapter 3, Topology .
- Production rules
Production rules are a policy-based management feature that you can use to dynamically change the load balancing configuration and the system settings based on specific triggers, such as the time of day, or the current network traffic flow. You can set up standard production rules using the Configuration utility, or you can define custom production rules using the production rules scripting language. Refer to Chapter 4, Production Rules , in the 3-DNS Reference Guide, for information about setting up production rules.