Policy and Distribution Services agents (Policy/Package Agent, Distributor Agent, and Subscriber Agent) are dependent on one another and upon eDirectory. It is important to understand the following dependencies when using Policy and Distribution Services to manage your network:
ZfS uses eDirectory as the repository for information needed by the TED and Server Policies components. Since eDirectory is a distributed database and can have partitions and replicas throughout the network, it takes time to synchronize all of the replicas each time ZfS objects are created or modified.
The Distributor Agent and Policy/Package Agent are the only ones that read eDirectory. The Subscriber Agent does not.
You must change the parent Subscriber attribute in the Subscriber object to change the parent Subscriber. Then, the next time a Distribution is sent, the distribution route to the Subscriber will reflect the new parent Subscriber.
If a parent Subscriber Java process is unloaded (exited), the subordinates of the parent Subscriber will not renegotiate to another parent Subscriber. The subordinates will wait until that parent Subscriber is loaded again and continue to use it. The reason for this is that if the parent Subscriber was the only server between twenty Subscribers and the Distributor (which is located across the WAN), you would not want all of the Subscribers to go across the WAN to get their Distributions if the parent Subscriber is unavailable.
Using Policy and Distribution Services can affect the behavior of your system:
Installing and using TED can affect any of the following:
To optimize your installation of TED, you should consider the following issues when selecting Distributor and Subscriber servers:
Consider CPU speed for building and sending Distributions, and sufficient disk space for storing all of the Distributor's Distributions.
The server can perform other non-ZfS network functions, be running other ZfS or non-ZfS software, or it can be solely dedicated to the ZfS Distributor function.
Consider installing the Subscriber software to each server that you want to manage with policies, or where you want to distribute software packages. The policy engine is installed with the Subscriber software; also, the Subscriber software is used to extract and install software packages.
Consider CPU speed for sending the Distributions, and free disk space for storing the Distributions that the parent Subscriber will pass on.
Consider WAN traffic when deciding where to locate parent Subscribers.
Consider Distribution priorities and setting sending and receiving rates to minimize the affect Distributions can have on bandwidth for WAN links.
If you need to control bandwidth usage for Distribution traffic, you can set the I/O rates and the maximum number of concurrent Distributions for Distributors and/or Subscribers.
Attributes of both the Distributor and Subscriber objects provide the following controls:
Input Rate: For sending and receiving Distributions, you can set the maximum bytes per second. The Distributor Agent and Subscriber Agent send and receive the Distributions. This allows you to have some control over the bandwidth used by these agents.The default is the maximum that the connection can handle. However, this does not control the rate at which FTP, HTTP, and RPM Distributions are built by the Distributor.
Output Rates Based Upon Distribution's Priority: Sets the default output rate to minimize network traffic for TED objects. This determines the send rate for Subscribers. The default value is the maximum that the connection can handle. There are three output priorities where you can specify a rate:
High Priority: These Distributions will be sent before any Medium or Low priority Distributions.
Medium Priority: These Distributions will be sent after all High priority and before any Low priority Distributions.
Low Priority: These Distributions will be sent after all High and Medium priority Distributions.
For more information, see Prioritizing Distributions.
Maximum Number of Concurrent Distributions: This determines how many simultaneous Distributions the Distributor Agent or Subscriber Agent will send. The default is unlimited (blank field). The Subscriber will always receive as many Distributions as it is sent; however, it will only concurrently pass on the number that you choose here.
If there is only one Subscriber, the Distributor will send Distributions at the selected rate. If there are two Subscribers, the Distributions will be sent at one half the rate. In other words, to determine the slowest distribution rate, divide the Distributor's output rate by the maximum number of concurrent Distributions.
Because Subscribers will always receive another concurrent Distribution, the rate will still apply even though you cannot limit the number of incoming connections.
TED provides message notifications so that administrators and selected end users can be kept informed. Notifications can be sent in several ways:
The following sections explain notification usage:
There are seven levels of messaging available, from no messages to be broadcast to a developer trace option. Regardless of the destination for a message, resources are directly affected by the level you choose. For information on setting message levels, see:
The level you choose for a log file will affect the rate at which the log file grows. Because log files have no maximum size, you can control the size of a log file by choosing to delete entries after x number of days. For information on setting message levels, see:
The greatest impact on network traffic can come from the levels you choose for SNMP traps and for the remote console.
For information on setting message levels for SNMP traps, e-mail messages, and the server's console, see:
SNMP messages are sent only if there is an SNMP policy in effect for the receiving server, regardless of the level you choose for the messages. SNMP traffic is affected by both the level you choose and by the SNMP configuration in the policy on the server. There is one SNMP packet per message per destination in the SNMP Trap Target policy. IPXTM addresses are not supported for trap targets.
Whenever there is a change to the identity of either a Distributor or Subscriber server, you must perform certain tasks so that the distribution processes for these servers can continue as before.
In the distribution process, TED servers identify themselves to each other by their DNS names or IP addresses. The following sections explain situations that can arise from changing these server identifiers.
If you change the IP address of a Distributor or Subscriber server when you are using its DNS name to identify it to ZfS, this change will not affect the distribution processes.
Because reinstating valid certificates is involved in resolving server identity changes, see Handling Invalid Certificates for instructions.
It is possible, for many common computer-related reasons, that a TED process could fail. The following are a few possibilities:
A Distribution could be interrupted. If so, when it restarts it will pick up where it left off.
Before distribution, the Distribution package resides at the Distributor. After distribution, the Distribution package still resides at the Distributor with a copy now at the Subscriber. It is during the distribution process that an interruption could halt copying. When the Distributor tries to re-send the Distribution (the next time the Channel schedule starts), it will pick up where it left off and not re-send the entire Distribution.
If the re-sending of a Distribution is interrupted, the sender will retry every two minutes for 30 minutes. If it is not successful in reestablishing connection to the target server, it will stop retrying. The next time the Channel's schedule starts it will pick up where it left off in sending the Distribution when it was originally interrupted.
An extraction could be interrupted. If so, the extraction will not pick up where it left off.
Distributions are made across the wire from server to server, while extractions are performed on the server from Distributions already sent. Therefore, when an extraction is interrupted, it simply fails. The Subscriber will not roll back (or undo) the failed extraction, unless the Distribution was a software package (.CPK file). It will try the extraction again the next time the Subscriber's extraction schedule starts.
Files are extracted to the volume and directory specified when the Distribution package was created. File groupings and software packages both allow you to specify which volume and directory the package should be extracted to. Therefore, when an interruption occurs during extraction, it fails in the same way as if you were copying a file in the operating system.
The File type offers the following:
All options deal with extraction and how to handle it.