Applies To:

Show Versions Show Versions

Archived Manual Chapter: 3-DNS Administrator Guide v4.1: Essential Configuration Tasks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



2

Essential Configuration Tasks



Reviewing the configuration tasks

Once you have completed the First-Time Boot utility, you set up the network and load balancing aspects of the 3-DNS Controller. The 3-DNS Controller has three essential configuration tasks that all users must complete, regardless of the chosen load balancing solution.

The 3-DNS Controller has three essential configuration tasks that must be completed, regardless of the type of configuration you are setting up:

  • Configure the physical aspects of your load balancing network, which includes the following:

    • Data centers
    • Data center servers and their virtual servers
    • Communications between the controller and other servers
    • 3-DNS Controller synchronization (if you have more than one in your network)
  • Configure the logical aspects of your load balancing network, including wide IPs and pools
  • Configure the global load balancing modes and global variables

Planning issues for the network setup

After you finish running the First-Time Boot utility, and connect each controller 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.

Tip: If you are configuring additional controllers in a network that already has 3-DNS Controllers in it, please review Chapter 5, Adding 3-DNS Controllers to the Network .

During the network setup phase, you define three basic aspects of the network layout, in the following order:

  • 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 Controllers, BIG-IP Controllers, EDGE-FX Caches, and host machines that you use for load balancing. Data center servers can also include GLOBAL-SITE Controllers, from which the 3-DNS Controller gathers network metrics.
  • Sync group
    A sync group defines the group of 3-DNS Controllers that shares configuration settings and path data.

    Note: During the network setup phase of configuration, we recommend that you connect to the 3-DNS Controller from a remote workstation where you can complete the remaining configuration tasks using the web-based Configuration utility.

Defining data centers and servers

It is important that you define all of your data centers before you begin defining the data center servers 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 Controller, EDGE-FX Cache, GLOBAL-SITE Controller, or host)
  • Server IP address (or shared IP alias for redundant systems)
  • Name of the data center where the server runs
  • big3d agent factories (BIG-IP Controllers, 3-DNS Controllers and EDGE-FX Caches, and GLOBAL-SITE Controllers only)
  • Virtual servers managed by the server (BIG-IP Controllers, EDGE-FX Caches, and hosts only)
  • SNMP host probing settings (hosts only)

    Note: 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 controllers in your network. See Chapter 3, The big3d Agent, in the 3-DNS Reference Guide, for help with determining how both of these issues affect your installation.

Planning sync groups

A sync group is a group of 3-DNS Controllers that share information. In a sync group, a principal 3-DNS Controller issues requests to the big3d agents to gather metrics data. Both the principal controller and the receiver 3-DNS Controllers in the group receive broadcasts of metrics data from the big3d agents. All controllers in the 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, select 3-DNS Controllers from the list of servers you have already defined. The sync group lists the controllers in the order in which you selected them. The first controller in the list is the principal 3-DNS Controller. The remaining controllers in the list are receiver 3-DNS Controllers. If the principal controller becomes disabled, the next controller in the list becomes the principal 3-DNS Controller until the original principal controller comes back online.

Understanding how sync groups work

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 controllers in a sync group operate as peer servers. At set intervals, the syncd daemon compares the timestamps of the configuration files earmarked for synchronization on all of the controllers. If the timestamp on a specific file differs between controllers, the controller with the latest file broadcasts the file to all of the other controllers in the group.

Understanding how the time tolerance variable affects sync groups

The time tolerance variable is a global variable that defines the number of seconds that one 3-DNS Controller's time setting can be ahead or behind another 3-DNS Controller's time setting. If the difference between the times on the controllers is greater than the time tolerance, the time setting on the controller running behind is reset to match the 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 controller running behind has its time reset to match the one running 10 seconds ahead. If the second controller 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 syncing). 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 between 3-DNS Controllers, data center servers, and big3d agents

There are three different communication issues that you need to resolve when you set up communication between the 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 for crypto controllers (that use SSH and SCP) that communicate with other crypto controllers, and you must set up rsh and rcp utilities for controllers that communicate with non-crypto controllers (that do not use SSH and SCP).
  • 3-DNS Controllers communicating with BIG-IP Controllers, EDGE-FX Caches, and GLOBAL-SITE Controllers
    To allow 3-DNS Controllers to communicate with BIG-IP Controllers, EDGE-FX Caches, and GLOBAL-SITE Controllers, you address the same ssh and rsh issues. Crypto controllers communicating with other crypto controllers can use ssh and scp utilities, but controllers communicating with non-crypto controllers require rsh and rcp utilities.
  • 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 Controllers, EDGE-FX Caches, and GLOBAL-SITE Controllers that run the big3d agent.

    Note: Enabling RSH and RCP does not prevent crypto 3-DNS Controllers from using encryption when they communicate with other crypto 3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, or GLOBAL-SITE Controllers.

Setting up communication between crypto and non-crypto controllers

The 3-DNS Controllers 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), or exclusively non-crypto 3-DNS Controllers (those that use the RSH protocol), the communication tools set up by the First-Time Boot utility are all you need.

If your network is a mixed environment, where some 3-DNS Controllers are crypto, and other 3-DNS Controllers are non-crypto, you need to enable the rsh and rcp utilities on the crypto 3-DNS Controllers. Though the rsh and rcp utilities come pre-installed on the crypto 3-DNS Controllers, you must explicitly enable these utilities. You can easily do this by running the rsetup script or the config_rshd script from the command line, or you can enable the utilities when you run the First-Time Boot utility. Table 2.1 shows the ports and protocols that 3-DNS Controllers use to communicate with each other.

Communications between 3-DNS Controllers

From

To

Protocol

From Port

To
Port

Purpose

Crypto 3-DNS Controller

Crypto 3-DNS Controller

TCP

<1023

22

SSH/SCP

Crypto 3-DNS Controller

Non-crypto 3-DNS Controller

TCP

>1024

514

RSH/RCP

Non-crypto 3-DNS Controller

Crypto 3-DNS Controller

TCP

>1024

514

RSH/RCP

Non-crypto 3-DNS Controller

Non-crypto 3-DNS Controller

TCP

>1024

514

RSH/RCP

Setting up data collection with the big3d agent

The big3d agent collects performance information from other 3-DNS Controllers, BIG-IP Controllers, GLOBAL-SITE Controllers, and EDGE-FX Caches, 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, please review Chapter 3, The big3d Agent, in the 3-DNS Reference Guide.

Planning issues for the load balancing configuration

The final phase of installing 3-DNS Controllers 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 BIG-IP Controllers, virtual servers managed by EDGE-FX Caches, virtual servers managed by a generic host servers, 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, such as Round Robin or Hops, that does not require significant additional configuration steps. 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.

We have included two popular 3-DNS Controller configurations in this Administrator Guide, in Chapter 3, Configuring a Globally-Distributed Network , and in Chapter 4, Configuring a Content Delivery Network . For additional details about advanced load balancing features, refer to Chapter 7, Additional Load Balancing Options .

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 3, Configuring a Globally-Distributed Network , and Chapter 11, Topology, in the 3-DNS Reference Guide.
  • 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 7, Production Rules, in the 3-DNS Reference Guide, for information about setting up production rules.

Planning DNS zone file management

An important part of installing 3-DNS Controllers in your network is planning which server should be authoritative for a given DNS zone. When you initially set up a 3-DNS Controller in your network, you have two basic options for setting up DNS zone file management:

  • You can use the 3-DNS Controller as the authoritative DNS server for your domain.
  • You can use an existing authoritative DNS server for your domain, and make the 3-DNS Controller authoritative for your sub-domains (defined as wide IPs).

    The 3-DNS Controller must always be authoritative for your wide IP sub-domains, regardless of which server is the authoritative DNS server for the network. However, we strongly recommend that you set up the 3-DNS Controller as authoritative for your domain.

    One major benefit of setting up the 3-DNS Controller to be authoritative for your domain is that you can easily manage DNS zone files using NameSurfer, a browser-based, third-party application included on the 3-DNS Controller. With NameSurfer, you can also easily transfer your existing zone files to the 3-DNS Controller after the initial installation.

    When you define wide IPs in the Configuration utility, the NameSurfer application automatically makes the appropriate additions to the zone files, and broadcasts the new zone files to the other DNS servers in your network. If you configure wide IPs from the command line, however, you need to make the corresponding zone file changes from the command line.

    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 controllers 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.

Replacing your DNS servers with 3-DNS Controllers

Figure 2.1 shows an implementation where both 3-DNS Controllers in the network are authoritative for the domain, domain.com.

Figure 2.1 Using 3-DNS Controllers as authoritative DNS servers

Converting existing BIND files during an initial installation

After you initially install the 3-DNS Controller, you need to transfer existing BIND files, and then convert them to the NameSurfer format.

The first option for importing your existing BIND files is to transfer your zone files from your current name server to NameSurfer. After configuring NameSurfer during the First-Time Boot utility and connecting to the Configuration utility, use the Copy from other name server option in NameSurfer. For more information, refer to the NameSurfer documentation available from the splash screen in the Configuration utility.

The second option for converting your existing BIND files is to skip the NameSurfer configuration when you run the First-Time Boot utility. You transfer the zone files and named.conf file after the system has rebooted, and then run the config_namesurfer script that configures, converts, and starts the NameSurfer application.

Warning: We recommend that you transfer your existing zone files using NameSurfer during the First-Time Boot utility. If you choose to transfer your existing zone files using the config_namesurfer script, please consult with your vendor first.

Running 3-DNS Controllers as authoritative for sub-domains only

At a minimum, all 3-DNS Controllers must be authoritative for the zones associated with wide IP definitions. When you set up a configuration where the 3-DNS Controllers are authoritative for only those sub-domains, you need to make a few changes to the zone files on the DNS server that is authoritative for the domain after you configure the 3-DNS Controller.

Figure 2.2 shows an example where both 3-DNS Controllers are authoritative for the wide IP sub-domain, wip.domain.com, and a generic name server in the Tokyo data center is authoritative for the domain, domain.com.

Figure 2.2 Using 3-DNS Controllers as authoritative DNS servers for sub-domains

Note that you should still set NameSurfer to be authoritative during the First-Time Boot utility for initial installations, or during the NameSurfer configuration script for upgrade installations. Remember that NameSurfer is authoritative for the zone files on the 3-DNS Controller, but in this configuration, the zone files contain only those records associated with wide IPs configured on the 3-DNS Controller. When you configure wide IPs in the Configuration utility, the NameSurfer application automatically updates the corresponding sub-domain zones and broadcasts them to the other DNS servers in the network. For configurations where synchronization is enabled, changes to any NameSurfer files are automatically updated to the other 3-DNS Controllers.

the Network Setup



Setting up a basic configuration

The second phase of installing 3-DNS Controllers is to define the network setup. Each 3-DNS Controller in the network setup must have information regarding which data center houses specific servers, and with which other 3-DNS Controllers it can share configuration and load balancing information. A basic network setup includes data centers, servers, and one sync group. Once you have the basic network components configured on your 3-DNS Controller, you can set up the wide IPs you need for managing your load balancing. We recommend that you review the load balancing solutions in the remaining chapters of this guide before you configure the wide IPs.

The following sections describe the various elements of a basic network:

  • Data centers
    Data centers are the top level of your network setup. We recommend that you configure one data center for each physical location in your global network. The data center element of your configuration defines the servers (3-DNS Controllers, BIG-IP Controllers, EDGE-FX Caches, and hosts) that reside at that location.

    A data center can contain any type of server. For example, in Figure 2.3 , the Tokyo data center contains a 3-DNS Controller and a host, while the New York and Los Angeles data centers contain 3-DNS Controllers and BIG-IP Controllers.

    For information about configuring data centers, see Setting up a data center, on page 2-12 .
  • Servers
    The data center servers that you define in the network setup include 3-DNS Controllers, BIG-IP Controllers, GLOBAL-SITE Controllers, EDGE-FX Caches, and host machines. You define the 3-DNS Controllers that manage load balancing to the BIG-IP Controllers, EDGE-FX Caches, and hosts, and you also define the virtual servers that are managed by the servers. Virtual servers are the ultimate destination for connection requests.

    For information about configuring servers, see Setting up servers, on page 2-15 .
  • Sync groups
    Sync groups contain only 3-DNS Controllers. When setting up a sync group, you define which 3-DNS Controllers have the same configuration. In most cases, you should define all 3-DNS Controllers as part of the same sync group.

    For information about configuring sync groups, see Working with sync groups, on page 2-29 .
  • Wide IPs
    After you define virtual servers for your BIG-IP Controllers, EDGE-FX Caches, and hosts, you need to define wide IPs to specify how connections are distributed among the virtual servers. A wide IP maps a domain name to a pool of virtual servers, and it specifies the load balancing modes that the 3-DNS Controller uses to choose a virtual server from the pool.

    When a local DNS server requests a connection to a specific domain name, the wide IP definition specifies which virtual servers are eligible to answer the request, and which load balancing modes to use in choosing a virtual server to resolve the request.

    For information about configuring wide IPs and choosing load balancing modes, please refer to Chapter 5, Load Balancing, in the 3-DNS Reference Guide.
  • Global variables
    You can configure global variables that apply to all servers and wide IPs in your network. However, the default values of the global variables work well for most situations, so configuring global variables is optional.

    For information about configuring global variables, see Configuring global variables, on page 2-31 .

Setting up a data center

The first step in configuring your 3-DNS Controller network is to create data centers. A data center defines the group of 3-DNS Controllers, BIG-IP Controllers, GLOBAL-SITE Controllers, EDGE-FX Caches, and hosts that reside in a single physical location. Figure 2.3 shows an example of a data center.

The advantage of grouping all machines from a single physical location into one data center in the configuration is to allow path information collected by one server to be shared with all other servers in the data center. The 3-DNS Controller uses the big3d agent to collect path and metrics information about the other servers, and their virtual servers, in the data center. The 3-DNS Controller then applies path metrics results to all the virtual servers in the data center when making load balancing decisions.

Note: You must configure at least one data center before you can add servers to the 3-DNS Controller configuration.

Figure 2.3 Example data center setup

When you add servers to the network setup, you assign the servers to the appropriate data centers.

To configure a data center using the Configuration utility

  1. In the navigation pane, click Data Centers.
  2. On the toolbar, click Add Data Center.
    The Add New Data Center screen opens.
  3. Add the new data center settings. For help on defining data centers, click Help on the toolbar.
    The data center is added to your configuration.
  4. Repeat this process for each data center in your network.

To configure a data center from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. Select Edit 3-DNS Configuration to open the wideip.conf file.
    The EDITOR environment variable determines whether this command starts vi or pico.
  3. Locate or add the datacenter statement.

    The datacenter statement should be the second statement in the file, after the globals statement and before server statements.

  4. In the first line of the datacenter statement, type a name for the data center and enclose the name in quotation marks, as shown in Figure 2.4 .
  5. Type the server type and IP address for each server that is part of the specified data center.

    Figure 2.4 shows the correct syntax for the datacenter statement.

    Figure 2.4 Syntax for the datacenter statement

     datacenter {    
    name <"data center name">
    [ location <"location info"> ]
    [ contact <"contact info"> ]
    [ 3dns <IP address> ]
    [ bigip <IP address> ]
    [ edge_fx <IP address> ]
    [ gsite <IP address> ]
    [ host <IP address> ]
    }

    Repeat the preceding procedure until you have added a separate datacenter statement for each data center in your network.

    Figure 2.5 shows a sample datacenter statement.

    Figure 2.5 Sample data center definition

     datacenter {    
    name "New York"
    location "NYC"
    contact "3DNS_Admin"
    3dns 192.168.101.2
    bigip 192.168.101.40
    host 192.168.105.40
    }

Setting up servers

There are five types of servers: 3-DNS Controllers, BIG-IP Controllers, GLOBAL-SITE Controllers, EDGE-FX Caches, and hosts. At the minimum, your network includes one 3-DNS Controller, and at least one server (BIG-IP Controller, EDGE-FX Cache, GLOBAL-SITE Controller, or host) that it manages.

This section describes how to set up each 3-DNS Controller, BIG-IP Controller, EDGE-FX Cache, GLOBAL-SITE Controller, and host machine that make up your network. The setup procedures here assume that the BIG-IP Controllers, EDGE-FX Caches, GLOBAL-SITE Controllers, and hosts are up and running, and that they already have virtual servers defined. Note that 3-DNS Controllers and GLOBAL-SITE Controllers do not manage virtual servers.

Defining 3-DNS Controller servers

The purpose of defining a 3-DNS Controller server is to establish in which data center the 3-DNS Controller resides and, if necessary, to change big3d agent settings. Before you add other 3-DNS Controllers to the configuration, you should add the 3-DNS Controller you are configuring to its own configuration. By adding any additional 3-DNS Controllers to the configuration, you make those 3-DNS Controllers available so that you can add them to a sync group.

Note: Please review Chapter 5, Adding 3-DNS Controllers to the Network , if you are configuring more than one 3-DNS Controller in your network.

To define a 3-DNS Controller server using the Configuration utility

  1. In the navigation pane, expand the Servers item, then click 3-DNS Controllers.
  2. On the toolbar, click Add 3-DNS Controller.
    The Add New 3-DNS Controller screen opens.
  3. Add the new 3-DNS Controller settings. For help on defining 3-DNS Controllers, click Help on the toolbar.

    The 3-DNS Controller is added to your configuration. Repeat this procedure for each 3-DNS Controller you need to add.

To define a 3-DNS Controller server from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.6 to define a 3-DNS Controller.

    All server statements should appear after the sync_group statement and before wideip statements.

    Figure 2.6 Syntax for defining a 3-DNS Controller server

     server {    
    type 3dns
    address <IP address>
    name <"3dns_name">
    iquery_protocol [ udp | tcp ]
    [ remote {
    secure <yes | no>
    user <"user name">
    } ]
    [ interface {
    address <NIC IP address>
    address <NIC IP address>
    } ]
    [ factories {
    prober <number>
    discovery <number>
    snmp <number>
    hops <number>
    } ]
    }

    Figure 2.7 shows a sample server statement that defines a 3-DNS Controller.

    Figure 2.7 Sample 3-DNS Controller server definition

     // New York    
    server {
    type 3dns
    address 192.168.101.2
    name "3dns-newyork"
    iquery_protocol udp
    remote {
    secure yes
    user "root"
    }
    }

Defining BIG-IP Controller servers

Before you define BIG-IP Controller servers, you should have the following information:

  • The IP address and service name or port number of each virtual server to be managed by the BIG-IP Controller
  • The IP address of the server itself

To define a BIG-IP Controller server using the Configuration utility

  1. In the navigation pane, expand the Servers item, and then click BIG-IP Controllers.
  2. On the toolbar, click Add BIG-IP Controller.
    The Add New BIG-IP Controller screen opens.
  3. Add the new BIG-IP Controller settings. (For help on defining BIG-IP Controllers, click Help on the toolbar.)
    The BIG-IP Controller and specified virtual server are added to your configuration.

To add more virtual servers using the Configuration utility

  1. In the navigation pane, expand the Servers item, and then click BIG-IP Controllers.
  2. In the table, find the BIG-IP Controller that you just added.
  3. Click the entry in its BIG-IP Virtual Servers column.
  4. On the toolbar, click Add Virtual Server.
    The Add Virtual Server to BIG-IP screen opens.
  5. Add the new virtual server settings. For help on adding virtual servers, click Help on the toolbar.

    Repeat this process for each virtual server you want to add to this BIG-IP Controller.

To define a BIG-IP Controller server from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.8 to define a BIG-IP Controller.

All server statements should appear after the sync_group statement and before wideip statements.

If you need to allow iQuery packets to pass through firewalls, include the translate keyword in the server statement that defines the BIG-IP Controller. When you include the translate keyword, the iQuery utility includes translated IP addresses in the packets sent to the specific BIG-IP Controller. For more information on configuring the big3d agent and iQuery, see Chapter 3, The big3d Agent, of the 3-DNS Reference Guide.

Figure 2.8 Syntax for defining a BIG-IP Controller server

 server {    
type bigip
address <IP address>
name <"bigip_name">
iquery_protocol [ udp | tcp ]
[ limit {
[ kbytes_per_second <number>
packets_per_second <number>
disk_avail <number>
cpu_usage <number>
memory_avail <number>
current_connections <number> ]
} ]
[ remote {
secure <yes | no>
user <"user name">
} ]
[ interface {
address <NIC IP address>
address <NIC IP address>
} ]
[ factories {
prober <number>
discovery <number>
snmp <number>
hops <number>
} ]

vs {
address <virtual server IP address>
port <port number> | service <"service name">
[ depends_on {
address <IP address>
address <IP address>
} ]
[ translate {
address <IP address>
port <port number>|service <"service name">
} ]
}
}

Figure 2.9 shows a sample server statement that defines a BIG-IP Controller.

Figure 2.9 Sample BIG-IP Controller server definition

 server {     
type bigip
address 192.168.101.40
name "bigip-newyork"
iquery_protocol udp
remote {
secure yes
user "administrator"
}
# Tell 3-DNS about the 2 interfaces on a BIG-IP HA
interface {
address 192.168.101.41
address 192.168.101.42
}
# Change the number of factories doing the work at big3d
factories {
prober 6
discovery 1
snmp 1
hops 2
}
vs {
address 192.168.101.50
service "http"
translate {
address 10.0.0.50
port 80
}
}
vs {
address 192.168.101.50:25 // smtp
translate {
address 10.0.0.50:25
}
}
}

Defining GLOBAL-SITE Controllers

Before you define GLOBAL-SITE Controller servers, you should have the following information:

  • The name of the controller
  • The IP address of the controller

To define an GLOBAL-SITE Controller server using the Configuration utility

  1. In the navigation pane, expand the Servers item, then click GLOBAL-SITE Controllers.
  2. On the toolbar, click Add GLOBAL-SITE Controller.
    The Add New GLOBAL-SITE Controller screen opens.
  3. Add the new GLOBAL-SITE Controller settings. For help on defining a GLOBAL-SITE Controller, click Help on the toolbar.
    The GLOBAL-SITE Controller is added to your configuration.

To define a GLOBAL-SITE Controller server from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.10 to define a GLOBAL-SITE Controller.

    Figure 2.10 Syntax for defining a GLOBAL-SITE Controller server

     server {    
    type gsite
    address <IP address>
    name <"gsite_name">
    iquery_protocol [ udp | tcp ]
    [ remote {
    secure <yes | no>
    user <"user name">
    }]
    [ factories {
    prober <number>
    discovery <number>
    snmp <number>
    hops <number>
    }]
    }

    In the wideip.conf file, all server statements should appear after the sync_group statement and before wideip statements.

    Figure 2.11 shows a sample server statement that defines a GLOBAL-SITE Controller.

    Figure 2.11 Sample GLOBAL-SITE Controller server definition

     server { // datacenter=East Coast    
    type gsite
    address 192.168.10.150
    name "gsite_east1
    iquery_protocol udp
    remote { secure yes
    user "root" }
    factories {
    hops 1 }
    }
    }

Defining EDGE-FX Caches

Before you define EDGE-FX Cache servers, you should have the following information:

  • The IP address and service name or port number of each virtual server to be managed by the EDGE-FX Cache
  • The IP address of the cache itself

To define an EDGE-FX Cache server using the Configuration utility

  1. In the navigation pane, expand the Servers item, then click EDGE-FX Caches.
  2. On the toolbar, click Add EDGE-FX Cache.
    The Add New EDGE-FX Cache screen opens.
  3. Add the new EDGE-FX Cache settings. For help on defining an EDGE-FX Cache, click Help on the toolbar.
    The EDGE-FX Cache and specified virtual server are added to your configuration.

To add more virtual servers using the Configuration utility

  1. In the navigation pane, click Servers, then click EDGE-FX Caches.
  2. In the table, find the EDGE-FX Cache that you just added.
  3. Click the entry in its EDGE-FX Virtual Servers column.
  4. On the toolbar, click Add Virtual Server.
    The Add Virtual Server to EDGE-FX screen opens.
  5. Add the new virtual server settings. For help on adding virtual servers, click Help on the toolbar.

    Repeat this process for each virtual server you want to add to this EDGE-FX Cache.

To define an EDGE-FX Cache server from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.12 to define an EDGE-FX Cache.

    Figure 2.12 Syntax for defining an EDGE-FX Cache server

     server {    
    type edge_fx
    address <IP address>
    name <"edge_name">
    iquery_protocol [ udp | tcp ]
    [ limit {
    [ kbytes_per_sec <number>
    pkts_per_sec <number>
    current_conns <number>
    cpu_usage <number>
    mem_avail <number>
    disk_avail <number> ]
    } ]
    [ remote {
    secure <yes | no>
    user <"user name">
    }]
    [ factories {
    prober <number>
    discovery <number>
    snmp <number> //minimum of 1 to collect metrics
    hops <number>
    }]
    vs {
    address <virtual server IP address>
    port <port number> | service <"service name">
    [ depends_on {
    address <IP address>
    address <IP address>
    } ]
    }
    }

    In the wideip.conf file, all server statements should appear after the sync_group statement and before wideip statements.

    If you need to allow iQuery packets to pass through firewalls, include the translate keyword in the server statement that defines the EDGE-FX Cache. When you include the translate keyword, the iQuery utility includes translated IP addresses in the packets sent to the specific EDGE-FX Cache. For more information on configuring the big3d agent and iQuery, see Chapter 3, The big3d Agent, of the 3-DNS Reference Guide.

    Figure 2.13 shows a sample server statement that defines an EDGE-FX Cache.

    Figure 2.13 Sample EDGE-FX Cache server definition

     server { // datacenter=East Coast, #VS=1    
    type edge_fx
    address 192.168.10.150
    name "edge_east1"
    limit { /* none */ }
    iquery_protocol udp
    remote { secure yes
    user "root"
    }
    factories {
    snmp 1
    }
    vs {
    address 10.10.10.10:80 // http
    limit { /* none */ }
    probe_protocol tcp
    }
    }

Defining host servers

A host is an individual network server or server array controller other than the BIG-IP Controller, EDGE-FX Cache, or GLOBAL-SITE Controller. Before configuring a host, you should have the following information:

  • Address information
    The IP address and service name or port number of each virtual server to be managed by the host.
  • SNMP information for host probing
    To implement host probing and to collect performance metrics, you must specify SNMP agent settings after you define the host server. The settings you specify include the type and version of SNMP agent that runs on the host, the community string, and the number of communication attempts that you want the big3d agent to make while gathering host metrics. SNMP agent settings for hosts are described in Configuring host SNMP settings, on page 2-27 .

    Note: To fully configure host probing, you must configure the SNMP agent settings in the host definition as previously described, and you must also set up the big3d agents to run SNMP factories, and configure the SNMP agents on the hosts themselves. For details, please refer to Chapter 3, The big3d Agent, and Chapter 10, SNMP, in the 3-DNS Reference Guide.

To define a host server using the Configuration utility

  1. In the navigation pane, expand the Servers item, and then click Host Servers.
  2. On the toolbar, click Add Host Server.
    The Add New Host Server screen opens
  3. Add the new host server settings. For help on adding host servers, click Help on the toolbar.
    The host and the specified virtual server are added to your configuration.

To add more virtual servers using the Configuration utility

  1. In the navigation pane, click Host Servers.
  2. In the table, find the host that you just added, and click the entry in its Host Virtual Servers column.
  3. On the toolbar, click Add Host Virtual Server.
    The Add Virtual Server to Host screen opens.
  4. Add the new virtual server settings. For help on adding virtual servers, click Help on the toolbar.

    Repeat this process for each virtual server you want to add to this host.

To define a host server from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.14 to define a host.

    All server statements should appear after the sync_group statement and before wideip statements.

Figure 2.14 Syntax for defining a host server

 server {    
type host
address <IP address>
name <"host_name">
[ prober <ip_address> ]
probe_protocol <tcp | icmp | udp | dns_rev | dns_dot>
port <port number> | service <"service name">
[ snmp {
agent <generic | ucd | solstice | ntserv | ciscoldv2 | ciscoldv3 | arrowpoint | foundry | alteon | cacheflow | win2kserv>
port <port number>
community <"community string">
timeout <seconds>
retries <number>
version <SNMP version>
} ]
vs {
address <virtual server IP address>
port <port number> | service <"service name">
[ depends_on {
address <IP address>
address <IP address>
} ]
[ probe_protocol <tcp | icmp | dns_rev | dns_dot> ]
}
}

Figure 2.15 shows a sample server statement that defines a host.

Figure 2.15 Sample host server definition

 server {     
type host
address 192.168.104.40
name "host-tokyo"
prober 192.168.101.40
probe_protocol icmp
port 53
snmp {
agent ucd
community "public"
version 1
}
vs {
address 192.168.104.50:25
}
vs {
address 192.168.104.50:80
}
}

Configuring host SNMP settings

After defining a host server, you need to configure its SNMP settings if you want to use SNMP host probing. Remember that you must first set up at least one SNMP probing factory on any 3-DNS Controller or BIG-IP Controller that runs the big3d agent.

The SNMP prober collects some or all of the following information from hosts.

  • Memory utilization
  • CPU utilization
  • Disk space utilization
  • Packet rate (packets per second
  • Throughput rate (kilobytes per second)
  • Current connections

The 3-DNS Controller uses this performance information for advanced load balancing modes such as Packet Rate, Quality of Service, and Kilobytes/Second.

The 3-DNS Controller supports the following host SNMP agents:

Supported SNMP agents

SNMP Agent

Description

Generic

A generic SNMP agent is an SNMP agent that collects metrics provided by object identifiers (OIDs) as specified in the RFC 1213 document.

UCD

This free SNMP agent is provided by the University of California at Davis. It is available on the web at http://net-snmp.sourceforge.net

Solstice

This SNMP agent is a product of Sun Microsystems.

NTServ

This SNMP matrix agent is a product of Microsoft Corporation and is distributed with Microsoft Windows NT Server 4.0.

Win2KServ

This SNMP matrix agent is a product of Microsoft Corporation and is distributed with Microsoft Windows 2000 Server.

Cisco LDV2

This SNMP agent is a product of Cisco Systems and is distributed with the Cisco LocalDirector, version 2.X.

Cisco LDV3

This SNMP agent is a product of Cisco Systems and is distributed with the Cisco LocalDirector, version 3.X.

ArrowPoint

This SNMP agent is a product of Cisco Systems and is distributed with the Cisco/ArrowPoint CSS series.

Alteon

This SNMP agent is a product of Alteon WebSystems and is distributed with the ACEdirector.

Foundry

This SNMP agent is a product of Foundry Networks and is distributed with the Foundry ServerIron.

CacheFlow

This SNMP agent is a product of CacheFlow and is distributed with the CacheFlow appliances.

Viewing host performance metrics

The Configuration utility displays the host metrics in the Host Statistics screen. The 3-DNS Controller bases the advanced load balancing decisions on packet rate, kilobytes per second, and current connections metrics, but the Host screen displays the other metrics as well, for information purposes.

Reviewing SNMP configuration issues

The SNMP probing feature requires that each host run an SNMP agent, and that the hosts and the big3d agents in the data centers have open network communication. Certain firewall configurations block SNMP communications, and you may need to verify that the firewalls in your network allow SNMP traffic to pass through. For information on configuring the big3d agent and working with firewalls, see Chapter 3, The big3d Agent, in the 3-DNS Reference Guide.

In addition to properly configuring the SNMP agents on the hosts themselves, you need to specify SNMP host probing settings in two places in the 3-DNS Controller configuration. First, when you define a BIG-IP Controller or 3-DNS Controller server, you set the big3d agent to run at least one SNMP factory. Second, when you define the host servers, you configure specific SNMP agent settings for each host. For example, you need to specify the type of agent running on the host as well as the community string that allows access to the SNMP agent. For more information on configuring SNMP agents, please review Chapter 10, SNMP, in the 3-DNS Reference Guide.

The SNMP chapter also includes some useful tips on configuring the different SNMP agents on the hosts themselves. We recommend that you use the information in conjunction with the documentation originally provided with the SNMP agent.

Working with sync groups

A sync group defines a group of 3-DNS Controllers that synchronize their configuration settings and metrics data. A sync group contains a principal controller and one or more receiver controllers. The principal controller is the 3-DNS Controller from which the receiver controllers obtain their metrics and server statistics information. You configure a sync group from the principal 3-DNS Controller. First list the IP address of the principal itself. Then list the receiver 3-DNS Controllers in the order that they should become principals if previously listed 3-DNS Controllers fail.

Each 3-DNS Controller in your network must be included in a sync group. There may be cases where you do not want a 3-DNS Controller to share its configuration with other controllers. In this case, you can create a separate sync group for each 3-DNS Controller. Each sync group contains only its own name or IP address.

Figure 2.16 Sample non-syncing sync groups statements

 sync_group {    
name "sync-ny"
3dns 192.168.101.2 // New York
}

sync_group {
name "sync-la"
3dns 192.168.102.2 // Los Angeles
}

Note: To implement such a configuration, you must modify each 3-DNS Controller's wideip.conf file; the Configuration utility does not support this function.

Configuring sync groups

The following procedures describe how to configure sync groups.

To define a sync group using the Configuration utility

  1. In the navigation pane, click 3-DNS Sync.
    The System - Add a New Sync Group screen opens.
  2. In the New Sync Group Name box, type the name of the new sync group and click Add.
    The Add a 3-DNS to a Sync Group screen opens.
  3. From the list of 3-DNS Controllers, first select the 3-DNS Controller that you want to be the principal controller. Then check the box next to each 3-DNS Controller that you want to add to the sync group.
  4. Click Add.

To define a sync group from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Use the syntax shown in Figure 2.17 to define sync groups.

    The sync_group statement should appear after the datacenter statement and before server statements.

    Figure 2.17 Syntax for setting up a sync group

     sync_group {    
    name "<name>"
    3dns <ip_address | "domain_name">
    [ 3dns <ip_address | "domain_name"> ] ...
    }

    Figure 2.18 shows a sample sync_group statement.

    Figure 2.18 Sample sync group definition

     sync_group {    
    name "default"
    3dns 192.168.101.2 // New York
    3dns 192.168.102.2 // Los Angeles
    }

Setting the time tolerance value

The time tolerance value is a global variable that defines the number of seconds that one 3-DNS Controller's time setting is allowed to be out of sync with another 3-DNS Controller's time setting. We recommend that you leave the time tolerance variable at the default setting of 10.

To check the value for the time tolerance setting using the Configuration utility

  1. In the navigation pane, click System.
    The System - General screen opens.
  2. On the toolbar, click Timers and Task Intervals.
  3. Note the value in the 3-DNS Sync Time Tolerance box, and change it if necessary.
  4. If you change this setting, click Update to save it. For more information about the settings on this screen, click Help on the toolbar.

To check the value for the time tolerance setting in the configuration file

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Search for time_tolerance. If the time_tolerance sub-statement is not in the configuration file, the default (10) is used.

Configuring global variables

The default values for global parameters are sufficient for most load balancing situations. However, we recommend that you specifically enable encryption for crypto 3-DNS Controllers.

To configure global parameters using the Configuration utility

  1. In the navigation pane, click System.
    The System - General screen opens. Note that global parameters are grouped into several categories on this screen. Each category has its own toolbar item, and online help is available for each parameter.
  2. Make general global changes at the System - General screen or, to make changes to global parameters in other categories, click the appropriate toolbar item.
  3. Add the new global settings. For help on configuring the global settings, click Help on the toolbar.

    The new global parameters are added to your configuration.

To configure global parameters from the command line

  1. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu.
  2. On the 3-DNS Maintenance menu, select Edit 3-DNS Configuration to open the wideip.conf file.
  3. Locate or add the globals statement. The globals statement should be at the top of the file.
  4. Under the globals statement, type the appropriate sub-statement and value.

    For example, to enable encryption for iQuery transactions (which is recommended), change the encryption parameter to yes (the default setting is no). If you want to use a non-default name for the encryption key file, type it on the next line.

    Figure 2.19 shows the correct syntax for enabling encryption.

    Figure 2.19 Syntax for enabling encryption

     globals {    
    encryption yes
    encryption_key_file "/etc/F5key.dat"
    }
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)