Review the following sections for an understanding of Tiered Electronic Distribution (TED):
The following sections provide basic information on TED:
Tiered Electronic Distribution (TED) provides you with a way to manage your servers through the distribution of electronic data between servers. For example, application programs, collections of data files, software patches, and policy packages.
When you install Policy and Distribution Services, the installation process creates Novell eDirectoryTM objects in the tree, copies software to the various servers, and sets up basic configurations for the TED and Server Policies components according to your installation selections. The TED software can be hosted on NetWare®, Windows* NT*, Windows 2000, Linux*, or Solaris* servers.
TED uses a tiered distribution model that enables one server to indirectly service hundreds or even thousands of other servers. TED makes it easy to distribute files and policy packages by building them into compressed data packages and hosting them in distribution channels for dissemination to the appropriate servers.
TED lets you schedule distributions to take advantage of off-peak hours. It also sends notification of distribution status by sending e-mail messages, logging events, displaying real-time messages, database reporting, and sending SNMP traps.
The TED distribution concept is as follows:
The key components of TED include:
To understand how TED can distribute electronic data between servers, you must understand its eDirectory objects, its agents, and the types of distributions it uses:
TED uses eDirectory objects and the related software for performing its distribution functions. The Distinguished Name (DN) of all TED objects includes the server name and component function of the host server.
The eDirectory schema extensions included in TED define the classes of eDirectory objects that can be created in your eDirectory tree, including information that is required or optional at the time the object is created. Every object associated with TED in an eDirectory tree has a class defined for it in the tree's schema.
The following eDirectory objects will be extended in the schema of your tree when you install ZfS 3:
The Distributor object (TED Distributor) is an eDirectory object that defines the properties for the Distributor. You can have multiple Distributor objects in the tree; however, you can only have one Distributor per server.
The Distributor Agent builds a Distribution on the Distributor server from the information you provide when you create and configure a Distribution object. A Distributor can own multiple Distributions.
When a Distributor builds a Distribution, it can also create a digest that provides a checksum for the Subscriber to compare against. Digests are used by Subscribers to verify that the Distributions have not been tampered with while in transit. Creating a digest is optional for each Distributor, so the digests might not always be available to the Subscribers for a checksum comparison.
A Distributor lists its Distributions in Channels. The Distributor can list any one of its Distributions in several Channels, and several of its Distributions in one Channel. Distributors do not own Channels. However, a Distributor is the sole owner of its Distributions.
The following illustrates a Distributor's relationship with its Distributions and the Channels:
This illustration shows one Distribution being listed in two different Channels.
A Distributor's Refresh schedule determines when it will read eDirectory for changes to its Distributions and other TED objects. A Distributor builds new Distributions it finds and rebuilds any of its Distributions that have changed. The new or rebuilt Distributions are then available to be sent through a Channel according to the Channel's send schedule.
IMPORTANT: We recommend the Distributor's Refresh schedule be daily, unless changes to Distributions warrant a more frequent refresh. However, do not refresh the Distributor more often than every three minutes.
A Distributor can build its Distributions any time its Refresh schedule starts, or when it is forced to do so from a server's command line. For more information on scheduling, see Scheduling .
The Distributor sends its Distributions to Subscribers (generally parent Subscribers. If a Subscriber does not respond to a Distributor (or a parent Subscriber) that is trying to send a Distribution, the Distributor will retry sending a Distribution every two minutes for 30 minutes, then stop. It will not attempt to re-send the Distribution until the Channel schedule starts again.
If you delete a Distribution, you should also refresh the Distributor immediately so that it will not try to build a Distribution that no longer exists.
The Distributor contains a distribution route, which is a hierarchical list of Subscribers that indicate the routes the Distributor can take to send a Distribution to a Subscriber.
All Distributors can log information to one common database file, or each Distributor can write to its own database file. For more information on databases, see ZENworks Database .
The Distribution (TED Distribution) object contains a list of data packages or data grouping information. A Distribution is a compilation of software and/or files, or a policy package, that the various servers in your network might need.
A Distribution is owned by only one Distributor. A Distribution keeps a list of its Channel associations, and can be placed into multiple Channels.
The following illustrates a Distribution's relationship with its Distributor and the Channels:
When a Distribution is built, it is built according to its type. There are seven types of Distributions:
The Desktop Application type is only available when ZENworks for Desktops (ZfD) is also installed.
A Distribution has a Build schedule that notifies its Distributor how often the Distribution needs to be built. If a Distribution has changed since the last time it was built, a new one will be created. Distributions can also be made active or inactive to control whether they should be built. For more information on scheduling, see Scheduling .
When a Distribution is built, any deletions in the Distribution object or on the Distributor server's file system, such as deleting files or directories, will cause those files or directories to also be deleted from the Distribution when it is rebuilt. However, unless synchronization is enabled, the files and folders will not be removed from the Subscriber server's file system.
The Channel object (TED Channel) contains a list of Distributions associated with it and Subscribers subscribed to it. The following illustrates a Channel's relationship with Distributions and Subscribers:
Distributors can list one Distribution in multiple Channels, and multiple Distributors can list their Distributions in the same Channel.
You can have as many Channels as you want. Channels do not hold the actual Distributions---only a reference to them. There is no limit to the number of Distribution references a Channel can send. The practical limit is how many Distributions you want to track per Channel.
Channels can be subscribed to by multiple Subscribers. To receive a Distribution, a Subscriber must subscribe to the Channel where that Distribution is listed. However, Subscribers will receive all of the Distributions listed in that Channel.
A Channel's Send schedule determines when a Distribution can be sent from the Distributor to its Subscribers. A Channel can be active or inactive to control when its Distributions can be sent. For information on how time zones can affect scheduling between a Channel and its associated Distributors and Subscribers, see TED Object Scheduling Issues .
The Subscriber object (TED Subscriber) is an eDirectory object that defines the properties for the Subscriber. The Subscriber is a service that receives and extracts Distributions to obtain the software, files, or policies it needs. Any server where you want to distribute applications, files, or policy packages must be a Subscriber.
Distributions are copied to the Subscriber server's hard drive. The Subscriber Agent receives the Distributions and extracts them to install the software, files, or policies.
Subscribers can subscribe to a Channel to receive all of the Distributions listed in that Channel. A Subscriber object's properties lists the Channels it is subscribed to. Subscribers can receive Distributions from multiple Distributors because:
The following illustrates a Subscriber's relationship with the Channels:
A Subscriber's Extract schedule determines when it is available for extracting Distributions. For more information on scheduling, see Scheduling .
Subscribers can be parent Subscribers, which act as proxies for the Distributor to pass Distributions on to other Subscribers. This helps the Distributor by providing load-balancing in sending the Distributions to other Subscribers.
The Subscriber object's properties lists the parent Subscriber through which it receives all of its Distributions. A Subscriber can receive its Distributions directly from the Distributor if it does not have a parent Subscriber and is not listed in the Distributor's routing hierarchy.
Parent Subscribers can also be used to bridge WAN links to ensure that Distribution packages are sent across WAN links a minimum number of times.
The External Subscriber object (TED External Subscriber) is an eDirectory object that represents a Subscriber object in another tree. This allows TED to send Distributions between trees.
The following illustrates an External Subscriber's relationship with its parent Subscriber and the Channel:
External Subscribers are identified by the TCP/IP address or DNS name of the TED Subscriber server in the other tree that it is associated with.
The External Subscriber object's properties lists the Channels it can receive Distributions from. An External Subscriber cannot be a parent Subscriber itself, though it must have a parent Subscriber in the tree where its object resides.
For an External Subscriber that does not have a TED Subscriber object in the eDirectory tree, a TEDNODE.PROPERTIES file can be used. A sample of the TEDNODE.PROPERTIES file is located at the root of the ZENworks for Servers Companion CD. You can use this sample file to create a copy to place in the ZENWORKS\PDS\TED directory on the External Subscriber's server. For more information, see Editing the TEDNODE.PROPERTIES File .
For more information, see Sending Tree-to-Tree Distributions .
The following TED agents are used to perform the distribution functions:
The Distributor Agent does the following:
This agent is installed on each server where you select to install the Distributor option.
The Subscriber does the following:
The Desktop Application type must have ZENworks for Desktops (ZfD) to process it.
This agent is installed on each server where you select to install the Policy Engine/Subscriber option.
The following illustrates the relationships of the main TED objects:
Note the following from this illustration:
The schedules that need to be coordinated for sending Distributions are the Distributor's Refresh schedule, the Distribution's Build schedule, and the Channel's Send schedule.
The schedules that need to be coordinated for receiving and extracting Distributions are the Channel's Send schedule and the Subscriber's Extract schedule.
For more information on scheduling, see TED Object Scheduling Issues .
The following is an example of the physical network connections between Distributor and Subscriber servers in a WAN environment.
Note the following from the illustration:
Now that you have determined your network's topology, your Distributions (how many, their sizes, and how often you might expect them to be rebuilt), and how many Subscribers will be receiving these Distributions, you can determine how many Distributors you will need.
Review the following sections to determine your Distributors:
A Distributor can use parent Subscribers in a routing hierarchy to explicitly determine routes for its Distributions. This eases its workload in distributing to Subscribers.
A parent Subscriber can also help a Distributor with its workload by acting as a proxy for the Distributor to pass on Distributions to other Subscribers. You can have multiple parent Subscribers on a given LAN to share the distribution workload on the LAN.
We estimate that the number of Subscribers and/or parent Subscribers that any one Distributor or parent Subscriber should service to be about 40. This figure is dependent on such factors as network speed, sizes of Distributions, and so on.
You should place parent Subscribers where they will help in load-balancing for Distributors and other parent Subscribers.
The following illustrates a WAN environment with parent Subscribers:
Note the following from this illustration:
The Distributor has the workload of reading eDirectory for Distribution changes, building the Distributions, sending the Distributions, and writing to the ZENworks database. By minimizing the number of Subscribers that a Distributor itself must directly send Distributions to, you can give the Distributor more resources for its various functions.
When you include parent Subscribers in the routing hierarchy, this can minimize network traffic by limiting the number of times a Distributor needs to pass a Distribution across a WAN link.
Because Distributors can send Distributions to parent Subscribers, which in turn can send them on to other Subscribers, a way is provided to send Distributions over a WAN link just once, instead of many times to reach every Subscriber on the other side of the WAN link.
Generally, you should have at least one parent Subscriber on every LAN to minimize the number of times a Distribution has to cross a WAN link. Even if there are only two Subscribers on a LAN, network traffic can be reduced by using one of them as the parent Subscriber.
Parent Subscribers are especially helpful with slow WAN links.
Consider the following when you determine how to distribute across your WAN links:
Parent Subscribers on the Distributor's LAN Segment: You should assign at least one Subscriber to be a parent Subscriber for all of the other Subscribers on a Distributor's LAN segment. That way the Distributor can have more resources for sending Distributions across WAN links.
Parent Subscribers for Bridging WAN Links: You can minimize the number of Subscribers that a Distributor must directly service across WAN links by assigning at least one parent Subscriber on all other LAN segments and including those parent Subscribers in the Distributor's routing hierarchy.
For example, your WAN has four LANs. With the Distributor in one LAN segment, it must send Distributions across three WAN links to get to Subscribers on the other three LAN segments. Let's assume each of the other LANs has 160 Subscribers who all need a Distribution from the Distributor. Without using parent Subscribers in the Distributor's routing hierarchy, the Distributor would have to send the Distribution 480 times across WAN links. In using parent Subscribers (four per LAN segment to share the Distribution workload on the LAN), the Distributor would only have to send the Distribution nine times.
Primary Parent Subscribers on a LAN: You can further minimize WAN traffic by tiering parent Subscribers on the other side of a WAN link from the Distributor. In other words, you can have just one parent Subscriber in the routing hierarchy that would also be a parent to several other parent Subscribers on its LAN segment.
Using the previous example, Subscriber 1 on each LAN segment could be the parent Subscriber for Subscribers 2, 3 and 4. In turn, parent Subscribers 1, 2, 3, and 4 would each service their own 39 or so Subscribers. That would allow the Distributor to only have to pass a Distribution across a WAN link once to Subscriber 1, which would take care of passing that Distribution on to the other three parent Subscribers, saving the Distributor three extra WAN link transmissions. Therefore, in contrast to the previous example, the 9 transmissions would be paired down to only three.
To use Policy and Distribution Services in multiple trees, you must install the software separately in each tree. However, you only need to install the ZfS objects to one of the trees.
For example, if your network topology is:
You could have the following TED configuration for the Distributor's routing hierarchy:
In this example, the Subscriber and server objects all exist in Tree_A. This allows you to have centralized management of the TED objects, regardless of your network topology.
Although you can create the Distributor and Subscriber objects in only one tree, the Policy and Distribution Services software can be installed to any server in your network, whether the server's eDirectory object resides in the same tree where the TED objects are created, or whether the server even has an eDirectory server object in any tree (such as a Windows server in a domain). This allows you to have centralized management of TED in environments where you have multiple trees and mixed server operating systems (such as NetWare and Windows servers).
Review the following sections to understand using External Subscribers for tree-to-tree distributions:
If you installed all of your TED objects on one tree, an External Subscriber is not necessary, because you can send your Distributions using the objects in the one tree. However, if you installed ZfS objects in several different trees, then you can use External Subscribers for sending Distributions between these trees.
TED uses IP addresses as a pointer to a NetWare or Windows server. Therefore, Subscriber objects do not need to be in the same tree as their NetWare servers' eDirectory objects.
The properties of an External Subscriber object contains the following:
The parent Subscriber will do the physical work in sending the Distribution file to the server in the other tree.
This allows you to use the External Subscriber for sending a Distribution to a Subscriber in another tree.
Once you have installed Policy and Distribution Services software to servers in multiple trees, you can send Distributions to those servers using the Subscriber and External Subscriber objects.
If you network topology were:
You could have the following TED configuration for the Distributor's routing hierarchy:
In this example, the Server_3 does not have a Subscriber object in either tree. Therefore, an External Subscriber object is created in Tree_A so that Server_3 can receive Distributions from Tree_A. However, Server_3 must have the Subscriber software installed on it in order to receive and extract the Distribution.
Because there is no Subscriber object for Server_3 in Tree_A, Server_3 will not receive any configuration information from the Distributor in Tree_A. Therefore, it must have the TEDNODES.PROPERTIES file installed on the server where configuration information is kept.
From an eDirectory perspective, the Distribution is sent from the Distributor object to Subscriber_1, which sends it to External Subscriber, which in turn sends it to Server_3. From a topology perspective, the Distribution file is sent from Server_1 to Server_2, which in turn sends it to Server_3.
If you have two trees where Distributors have been installed, your network topology might be:
You could have the following TED configuration for Distributor_A's routing hierarchy:
In this example, each tree has a Distributor. Server_4 receives its configuration information from Distributor_B (Server_3) in its trusted tree. Therefore, a TEDNODES.PROPERTIES file is not needed for Server_4.
To send a Distribution from Distributor_A to Subscriber_2, you would create an External Subscriber object in Tree_A, select Subscriber_1 as the parent for the External Subscriber, and list Server_4's IP address in the External Subscriber object's properties.
From an eDirectory perspective, the Distribution is sent from Distributor_A to Subscriber_1, which sends it to External Subscriber. From a topology perspective, the Distribution file is sent from Server_1 to Server_2, which in turn sends it to Server_4.
In summary, the External Subscriber object is useful for sending tree-to-tree Distributions when one of the following conditions exists:
The following are some points concerning External Subscribers:
Review the following to understand how Distributions are sent:
The following illustrates the flow of TED Distributions:
Note the following from the illustration:
IMPORTANT: When there are multiple versions of a File or Desktop Application type of Distribution, the Subscriber maintains copies of the versions according to what you set in the Distribution object's properties. The default is 10.
TED provides a way to automate getting Distributions from the Distributors to your servers. The following sections provide information on sending Distributions:
The power of a tiered distribution model enables you to spread the workload for sending Distributions. This is particularly important to the Distributor servers. By sharing distribution duties with parent Subscribers, a Distributor server can have more resources available for reading eDirectory, building each of its Distributions, and logging information to the database.
Tiered distribution levels can be very deep, providing a very large number of Subscribers that any one Distributor can service---without doing so directly.
A Distributor must actually send each of its Distributions because they reside on its own server.
Sending Distributions can create an enormous workload for a Distributor if it has to individually send each of its Distributions to every Subscriber server on the network. Therefore, parent Subscribers are used to help send Distributions.
A parent Subscriber is a Subscriber that acts as a proxy for the Distributor to store and pass Distributions so that the Distributor does not have to send its Distributions directly to every Subscriber.
A detailed understanding of your network's topology is important for properly configuring distribution routes and selecting parent Subscribers. Therefore, refer to a diagram of your network that shows all WAN links.
A Subscriber does not have to subscribe to a Channel containing a Distributor's Distributions to be in the Distributor's routing hierarchy. A parent Subscriber itself does not need to be the recipient of the Distribution it is passing on.
Further, a parent Subscriber does not have to subscribe to the same Channels as its subordinate Subscribers to be able to pass on those Channel's Distributions.
To ease a Distributor's workload in sending Distributions, each Distributor has its own routing hierarchy, which is a hierarchical list of Subscribers that indicate the routes Distributions can take to send a Distribution to a Subscriber. The Subscribers in the routing hierarchy are the parent Subscribers. Parent Subscribers can be nested many levels deep.
A parent Subscriber can receive a Distribution and extract it, as well as pass that same Distribution on to other Subscribers.
You can modify distribution routes at any time by editing the properties of the Distributor objects.
The following illustrates a Distributor's routing hierarchy:
Note that the only Subscribers you need to include in the Distributor's routing hierarchy are those that will be used to pass on Distributions to other Subscribers. Subscribers that are not used to pass on Distributions can be referred to as end-node Subscribers.
In the illustration under Routing Hierarchy , each Subscriber listed could be a parent to other Subscribers on its LAN. For example, if every Subscriber listed in the illustration was a parent to 20 end-node Subscribers, the Distributor could service 210 total Subscribers while only physically sending its Distributions to three of the Subscribers (the first-tier parent Subscribers, numbers 01, 04, and 09).
To further illustrate, parent Subscriber 04 would be servicing 104 Subscribers while only directly sending to two parent Subscribers (05 and 06) and its own 20 end-node Subscribers.
If you have multiple Distributors, they can share portions of each other's distribution routes, meaning Subscribers can be listed in the distribution routes of more than one Distributor. This is because the route to a Subscriber is dependent on the Distributor, and can be different for any given Distributor to Subscriber path.
Assume that Subscriber 07 is a parent to Subscriber 11 (which is not in the routing hierarchy). The distribution route from the Distributor to Subscriber 11 would be the following:
The Distributor used four parent Subscribers (04, 05, 06, and 07) to send the Distribution to Subscriber 11.
If Subscriber 11 did not have a parent Subscriber (such as Subscriber 07), the Distribution would come directly from the Distributor:
Note that the only Subscribers you need to include in a routing hierarchy are those that will be used to pass Distributions on to other Subscribers. The end-node Subscribers (Subscribers that are only receiving and not passing on Distributions) do not need to be listed in the hierarchy. They have links in eDirectory to their parents.
Subscribers that exist in a routing hierarchy are generally parent Subscribers, although this is not required.
IMPORTANT: Subscribers that do not utilize parent Subscribers can increase the workload on the Distributor and increase network traffic across WAN links. All Subscribers should have a parent Subscriber, except for the first tier Subscribers that receive Distributions directly from the Distributor.
If a parent Subscriber is changed, or the routing list (on the Routing Hierarchy tab of the Distributor object's properties) is changed, the change will be reflected in the routing slip because it is calculated each time the Channel schedule starts. A refresh is required for the Distributor to re-read eDirectory.
Parent Subscribers should be placed in the routing hierarchy using the following guidelines:
Note that parent Subscribers are not always required for a WAN link. For example, if you have only two Subscribers on a LAN connected by a fast WAN link, the traffic difference between sending the Distribution once versus twice could be negligible. However, for a slow WAN link this might not be the case.
The factors in determining whether a Subscriber can receive Distributions directly from the Distributor instead of through a parent Subscriber are:
The following illustrates the use of multiple Distributors and parent Subscribers in sending Distributions:
The arrows and lines indicate the subscription and Distribution connections to the Channels (dotted lines) and the distribution paths from the Distributors to the Subscribers (solid lines).
Note that this illustration does not show distribution route hierarchies. For the purpose of this illustration, assume the following:
Note the following from the illustration concerning the use of multiple Distributors and parent Subscribers in sending Distributions:
Distribution Ownership: Distributors have ownership of their own Distributions and will build and send each of its Distributions.
Multiple Distributors: Multiple Distributors can list their Distributions in the same Channel. This means a Subscriber can receive Distributions from multiple Distributors.
Channel Usage by Distributors: Distributors can list their Distributions in any Channel, and they can list one Distribution in multiple Channels.
Multiple Distributions per Channel: A Channel can have multiple Distributions from one or more Distributors.
Channel Subscriptions: Each Subscriber subscribes to any of the Channels that have the Distributions it needs. A Subscriber can subscribe to multiple Channels, and a Channel can have multiple Subscribers subscribed to it.
Parent Subscribers: A parent Subscriber is used as a proxy for the Distributor to pass on Distributions to other Subscribers.
Orphaned Subscribers: If a Subscriber is not in a Distributor's distribution route, or the child of a parent Subscriber in that hierarchy, the Distributor will send the Distribution directly to the Subscriber. This can be an issue for WAN links and other topology issues.
The following illustrates a Distribution hierarchy containing a Distributor, several parent Subscribers, and many end-node Subscribers:
Consider the following in designing your Distributor's routing hierarchy:
Distribution Route: This represents the most efficient path to any given segment of your WAN. A Distribution route is a list of parent Subscribers that relay Distributions on to other parent or end-node Subscribers. Parent Subscribers can be used to minimize the workload for a Distributor by being able to pass on Distributions.
End-Node Subscribers: The only Subscribers you need to add to the left box are those you want to be used to pass on Distributions (see the Parent Subscriber nodes in the illustration). End-node Subscribers that will only receive Distributions do not need to be added to the routing hierarchy.
Configuring Distribution Routes: To create the Distribution routes, consider your network design and the number of Subscribers on each LAN. Then build the routing hierarchy to mimic your network topology.
Selecting Multiple Subscribers: If you select multiple Subscribers, they will all be placed at an equal level under the Distributor or Subscriber you have selected in the left box.
Using Multiple Distributors: You can also select multiple Distributors so that you can place the same Subscribers under each of them. This can be used to create the same Distribution route for each Distributor.
Reusing Subscribers: Any Subscriber can be used more than once if you have multiple Distributors, although you should consider whether you might overload the Subscriber if it should service multiple Distributors.
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.
Distributions can be prioritized in two ways:
Send Queue: You can prioritize the order in which Distributions are sent: High, Medium, or Low. For example, in a given Channel, all High priority Distributions are sent first, then the Medium priority Distributions are sent, and then the Low priority Distributions are sent.
Because Distributions with mixed priorities cannot be sent concurrently, you can control the order in which Distributions are sent by the priorities that you assign them.
Output Rate: You can configure different output rate settings for a Distribution, based on a priority: High, Medium, or Low. This allows you to control the bandwidth a Distribution will use. For example, if you want your High priority Distributions to utilize the most bandwidth, you would configure their output rates with the High priority.
The Maximum Number of Concurrent Distributions value is affected by prioritizing. This value is subordinate to the priorities set for the Distributions. For example:
Distributor objects can be deleted from eDirectory. However, you will lose the following important information that you may want to reuse for the Distributor's replacement:
Because Distributions belong exclusively to their Distributors, you will no longer be able to build and send those Distributions if you delete a Distributor object from eDirectory. The Distributions associated with the deleted Distributor will become orphaned and no longer usable.
Any orphaned Distributions that have already been sent and extracted before you delete the Distributor object will be usable by the Subscriber servers where they were extracted. However, these servers will no longer receive updated versions of the orphaned Distributions.
You will still be able to see the orphaned Distribution objects in eDirectory, but no current or future Distributor object can be associated with these orphaned Distribution objects.
For all Distribution types, you can delete the Distribution directories on the Subscriber servers' file systems for all orphaned Distributions. We recommend that you delete the Distribution directories for any Distributions that you intend to re-create.
For most Distribution types, deleting the orphaned Distributions' directories is all you need to do in order to clean up for management and disk space conservation purposes. These Distribution types are:
However, for the Policy Package and Software Package Distribution types, you might need to undo the processes that the Distributions initiated when they were extracted and installed.
For example, a Policy Package Distribution might require that you use iManager to remove the policies that the Distribution set for the server. For more information, see Step 5 under Managing the Policy/Package Agent from the Remote Web Console .
You need to re-create each orphaned Distribution that you want to continue to use. You can do this using an existing Distributor object, or after you install a new Distributor.
After you have re-created a Distribution, all Channels previously associated with the orphaned Distribution need to be associated with the newly-created Distribution.
In re-creating the Distributions, you can use the configuration information from the orphaned Distribution objects. When you no longer need the orphaned Distribution objects, you can delete them and they will no longer be displayed on the Distributions tab of the Channel object.
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.
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.
Policy and Distribution Services provides several means for securing Distributions:
A certificate is a security mechanism used by Policy and Distribution Services to ensure that the Distribution received by a Subscriber was actually sent by the Distributor owning that Distribution. Without a matching certificate, a Subscriber cannot receive Distributions from the Distributor.
For more information, see Distribution Security Using Signed Certificates and Digests .
Distributions can be encrypted for when you send them outside your secure network.
For more information, see Distribution Security Using Encryption .
Communications between TED components residing inside and outside your secure network can be secured by installing inter-server communications security where needed.
For more information, see Security for Inter-Server Communication Across Non -Secured Connections .
Distributors and Subscribers use working directories on the servers for Distributions, patches, status files, and temporary working files. The size of a working directory is determined by the size and number of Distributions.
The working directories default to the SYS: volume on NetWare® servers or the C: Drive on Windows* servers. Because of disk space considerations on NetWare servers, we recommend that you select a different location on the server, such as a DATA: volume.
The default working directory names for NetWare and Windows servers are Path\ZENWORKS\PDS\TED\DIST for the Distributor and Path\ZENWORKS\PDS\TED\SUB for the Subscriber. For Linux* and Solaris* servers, the paths are usr/ZENworks/PDS/TED/Working/Dist and usr/ZENworks/PDS/TED/Working/Sub. You can change working directory names in the properties of the TED object.
The following sections describe the TED directory structures:
The following directories are used by NetWare Distributors:
Contains the TED software for the Distributor.
Contains the Distributor's private key.
Contains one subdirectory for each Distribution that belongs to the Distributor. The working directory name is user-defined in the Distributor object.
Each Distribution has its own subdirectory that is created under the working directory. The Distribution directory's name is derived from the following syntax: Tree_DN_of_Distribution. For example, TestTree_Files.TED.Novell.
Each Distribution directory contains multiple time stamp directories, which are named according to the date and time the Distribution was built.
Each time a Distribution is built, the Distributor checks to see if anything has changed since the last time the Distribution was built. If so, a new time stamp directory is created.
The number of time stamp directories kept is determined by the Maximum Number of Revisions to Keep field in the Distribution object's properties. There are occasions when the number of time stamp directories will exceed the maximum number specified because the Distributor will not delete a time stamp directory that is in use. The Distributor removes the oldest time stamp directories first.
Sometimes a time stamp directory name will have _TEMP appended to it. When a Distributor builds a Distribution, it creates a *_TEMP directory before it determines if anything has changed. If changes are discovered, the _TEMP is removed and the directory is used for the new build.
A Distributor's time stamp directories contain the following files:
The following directories are used by NetWare Subscribers:
Contains the TED software for the Subscriber and/or Distributor.
Contains certificates received from Distributors.
Contains one subdirectory for each Distribution that it receives from a Distributor. The working directory name is user-defined in the Subscriber object.
Each Distribution has its own subdirectory that is created under the working directory. The Distribution directory's name is derived from the following syntax: Tree_DN_of_Distribution. For example, TestTree_Files.TED.Novell.
Each Distribution directory contains multiple time stamp directories, which are named according to the date and time the Distribution was built.
The number of time stamp directories kept is determined by the Maximum Number of Revisions to Keep field in the Distribution object's properties.
Once a threshold is met, the Subscriber receives the maximum revision information and deletes the oldest time stamp directories first.
A Subscriber's time stamp directories contain the following files:
The following directories are used by Windows NT* Distributors:
Contains the TED software for the Distributor.
Contains the Distributor's private key.
The following directories are used by Windows NT Subscribers:
Contains the TED software for the Subscriber.
Contains certificates received from Distributors.
Each Distribution directory contains multiple time stamp directories, which are named according to the date and time the Distribution was built.
The following directories are used by UNIX Distributors:
Contains the TED software for the Distributor.
Contains the Distributor's private key.
Each Distribution directory contains multiple time stamp directories, which are named according to the date and time the Distribution was built.
The following directories are used by UNIX Subscribers:
Contains the TED software for the Subscriber.
Contains certificates received from Distributors.
Each Distribution directory contains multiple time stamp directories, which are named according to the date and time the Distribution was built.