Discussing TED Configuration in Your Network

You need to consider how you want to lay out TED into your tree and network. You need to take into account any WANs that you must use for your distributions and be careful to minimize the amount of traffic transmitted over a WAN link. TEDs from ZENworks for Servers 3 are designed to handle anything from the smallest network to large enterprises and can be configured to help minimize this traffic. However, you must set up TED and administer its functions to get these gains.

Examining a Simple Layout

To help in the explanation, let's take an example of a simple and then a complex tree and discover the best method to lay out TED components to get the best performance for your network. Look first at Figure 6.1, which shows a simple tree.

Figure 6.1. Simple example tree for TED distribution.

graphics/06fig01.gif

As you can see in Figure 6.1, the tree (SIMPLE_TREE) contains a tree that is assumed to be all in a single campus where no WANs are involved. The TED configuration for this setup can be fairly simple, because there are only eight servers in the system. To not overburden a distributor or a parent subscriber, you should not have a distributor or parent subscriber support more than 40 subscribers. Because there are not going to be more than eight subscribers in the network, this simple example needs only a single distributor and eight subscribers (one on each server, including the distribution server).

The number of channels that you want is based on the types of distributions that you would expect to perform or the time schedules within which you want the distribution sent. It is recommended that you base your channels on the types of distributions you expect to send or the schedules you want to keep, rather than the destination. For example, you should name your channels Sales Data, Base Engineering Apps, Virus Patterns, Europe Off Hours, and so forth. By naming your channels this way (rather than Building1, for example), it will be clear by the name of the channel what type of distributions can be expected to be transmitted to the subscribers attached to the channel. You can have any number of channels in the directory, and a subscriber can subscribe to any number of channels, so there is no reason to limit the channels that you create.

In the SIMPLE_TREE, we create three channels: Sales Apps, Eng Apps, and Sales Data. We place a distributor on server A because the sales data is written on this server, and a distributor on server B because it holds all the golden images of the engineering applications. We place a subscriber on each of the other servers and associate them with the appropriate channels. Figure 6.2 displays the same tree with all the channels, distributors, and subscribers in place. Subscribers G and H both subscribe to channels Sales Data and Sales Apps. Subscribers B, C, E, F, and G subscribe to the Eng Apps channel.

Figure 6.2. Channels, subscribers, and distributors for the simple example tree.

graphics/06fig02.gif

This layout is used because of the needs of each of the servers, regardless of their location in the network or the tree.

Looking at a Complex Layout

Now let's take a look at a more complex tree, one that includes some WAN traffic to cross container boundaries. Figure 6.3 is a demonstration of this type of tree.

Figure 6.3. WAN example tree for TED distribution with channels, subscribers, and distributors.

graphics/06fig03.gif

In the WAN tree you can see Provo, Paris, Honolulu, and Sydney. Provo is in the United States, Paris in France, and Sydney in Australia, so a WAN is required to interconnect these sites. There is an added complexity that is not shown: To get to Sydney from Provo you must first make a WAN hop in Honolulu and then the final WAN hop to Sydney. To throw in a twist, we'll have a sales server in the mix, server 7, that is getting information from a Sales channel from somewhere in the tree.

Because WANs are involved, you want to minimize the traffic that must go over the WAN lines. You can accomplish this by placing a parent subscriber at each of the WAN sites and then connecting each of the destination subscribers in the target WAN to that parent. In the case of Sydney, we need to have a parent subscriber send the distributions to another parent subscriber in Sydney, because it is a two-hop scenario.

We look at only two channels: one called Sales Data (collected and distributed by an unshown distributor) and one called TID Data that is used to transmit all the TID files that are collected at the main Provo site and then transmitted to each of the support sites across the world. We would want to set up the following channels, distributors, and subscribers to support the WAN tree (see Figure 6.4).

Figure 6.4. Subscribers, distributors, and channel configuration for the WAN example tree.

graphics/06fig04.gif

As you can see, there are two channels: the TID channel in Provo and the Sales channel that is somewhere in the tree. (It is really not relevant where the channel is located.) We have connected subscribers 3, 4, 5, and 6 to the TID channel in NDS. We have also made sure that subscriber 7 is connected to the Sales channel. The distributor is simply shown to exist in the Provo LAN and is not fully shown in the tree. Suffice it to say that it exists on a server in Provo in the same tree as shown.

Now we must define the parent subscribers in the network for distributor 1 (in the Provo LAN) to be the most efficient in its use of the WANs. If we do not define parent subscribers, the distributor transmits to each subscriber directly. This results in the same files being transmitted to Paris twice, to Honolulu three times, and to Sydney twice, for a total of seven WAN transmissions. See how this would work out by looking at Table 6.1. As you can see, they each take one hop except for Sydney, which requires a hop through Honolulu and then to Sydney.

Table 6.1. WAN Hops for WAN Tree Transmissions

LAN

# OF WANS

TO SUBSCRIBER

Paris LAN

1

Subscriber 3

Paris LAN

1

Subscriber 4

Honolulu LAN

1

Subscriber 5

Sydney LAN

2

Subscriber 6

Sydney LAN

2

Subscriber 7

Now we can describe in NDS the network's parent subscribers. This can be done in one of two ways: as a routing hierarchy in the distributor object, or as a parent subscriber identification in each "child" or "leaf" subscriber (see Figure 6.5).

Figure 6.5. Subscribers, distributors, and channel configuration for the WAN example tree.

graphics/06fig05.gif

The quickest way to define this would be to go to distributor 1's object in the tree and define the following routing hierarchy:

  1. Subscriber 3

    1. Subscriber 4

  2. Subscriber 5

    1. Subscriber 6

      Subscriber 7

This would state to the distributor that when it is distributing its collections, subscriber 3 will service subscriber 4, and subscriber 5 will service subscriber 6, who then services subscriber 7. If you look at the behavior of TED when this is done, the following transmissions occur over the WAN (see Table 6.2).

Table 6.2. Optimized WAN Hops for WAN Tree Transmissions

LAN

# OF WANS

TO SUBSCRIBER

Paris LAN

1

Subscriber 3

Local, from subscriber 3

0

Subscriber 4

Honolulu LAN

1

Subscriber 5

Sydney LAN, passed from subscriber 5

1

Subscriber 6

Local, from subscriber 6

0

Subscriber 7

You can see now that we transmit the files only three times over a WAN and have saved almost 233% of the traffic that we would have consumed had we not done parent subscribers.

One annoyance is that when you define the routing hierarchy in the distributor, only that distributor knows of this configuration. You have to go to all the distributors in that LAN and put this same routing hierarchy into their objects. This can also be a great benefit, because it enables you to set up different distribution routes depending on the distributor that is sending the information. For example, you might have a financial information distributor, but you may not want that financial information passing through a certain subscriber. By defining a separate distribution hierarchy on the financial distributor, you can eliminate certain servers from ever getting the financial information. To save you some aggravation with having to describe your whole network, you can leave the leaf node subscribers out of the routing hierarchy definitions and identify their parents in their own objects. The distributor automatically discovers this and includes it in the routing list. (See the "Construction of a Routing Hierarchy" section of this chapter for more information.)

Looking at a Tree Spanning Layout

Now let's take a look at some example of spanning distributions across tree boundaries. ZENworks for Servers 3 also enables you to distribute software independent of trees by using external subscriber objects (discussed later in this chapter). You can get benefits from spanning distributions across trees in various ways.

You might want to span trees if you need to maintain similar distributions in each of your trees. Imagine that you have one tree for your corporate office in Houston and another tree for your manufacturing plant in Detroit. The distance and dissimilar functions of the two sites makes having a single tree unreasonable, but both sites use the same accounting and payroll system, which needs to be updated occasionally. The value of an external subscriber is for the occasional use of sending the accounting and payroll distribution from the corporate tree to the manufacturing tree, instead of duplicating the distribution creation work for the same distribution in both trees.

You might also want to span trees if you need to send a distribution outside your firewall, perhaps to another business. Let's say your business manufactures a product that is distributed by one company and then sold by a third company. You could create an external subscriber for both the distributor and the reseller. Then you could create a distribution for product schedules and the like. That way a single distribution could update not only the appropriate offices in your own business, but your distributor and reseller as well, and all three companies can stay current.

Examining Capacities and Restrictions

It's a good idea to review some of the issues that you should watch in your network to make sure that you don't attempt to overburden your servers with distribution work. This concern is relative to the number of dependents a distributor must support and where distributors must be in the network.

Looking at Dependents

As was mentioned earlier, you should attempt to not overburden any distributor or parent subscriber with more than 40 direct dependents. This can be difficult to manage, and you need to keep a careful eye on how you configure your subscribers and distributors to keep this from becoming a problem. The issue is that you really don't know at the beginning which distributors will be sending to which subscribers, because that determination is based purely on which channel you chose to place the distribution. The easiest way to keep this all working well is to think about your TED distribution network from the bottom up as you are constructing the system. As you place subscribers into the network, choose a hierarchy of well-known parent subscribers, making sure that no branch of your TED network is overburdened.

For example, imagine that you start with the TED distribution network shown in Figure 6.6.

Figure 6.6. Phase1 hierarchy of subscribers in TED distribution network.

graphics/06fig06.gif

As shown in Figure 6.6, subscribers 3 through 63 are set up so that they each use either subscriber 1 or 2 as the parent subscriber. Subscribers 66 through 84 use subscriber 64 as their parent subscriber. In the figure, the levels of the hierarchy (levels 1 4) are labeled to help you understand where in the structure each of the subscribers reside. Now, when you want to add more subscribers, you can either place them hierarchically, under some other subscribers at level 2, or you can create a new level 1 and go from there. Just keep in mind that you want to keep the TED distribution hierarchical tree balanced somewhat so as to not overburden any one subscriber or distributor.

This leveling approach works well for a single LAN. When you move into multiple LANs and introduce a WAN link, you need to have this leveling in each of the LANs in your network and then describe in the distributors how you may efficiently move from one WAN to the next, based on their locations. For example, distributor X may only have one hop to LAN Y, but distributor M may have two. So, the routing hierarchy defined in distributors X and M will be different with regard to how to most efficiently get to LAN Y.



Novell's ZENworks for Servers 3. Administrator's Handbook
Novell's ZENworks for Servers 3. Administrator's Handbook
ISBN: 789729865
EAN: N/A
Year: 2003
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net