Oracle Names Administrator's Guide

Library

Product

Contents

Index

Planning for Oracle Names

This chapter describes the issues to consider before installing and configuring Oracle Names, including:

choosing a naming model (not applicable with DDO)

defining administrative regions (not applicable with DDO)

determining the number of Names Servers required

selecting Names Server nodes

Read this chapter before installing Oracle Names. Be sure to make all planning decisions before installing Oracle Names.

Note: There may be other considerations specific to your operating system and platform. See your platform-specific manuals for details.

Before Installing Names Servers

The details of this chapter may require knowledge from elsewhere in this and other Oracle manuals.

Refer to Understanding SQL*Net for more information on SQL*Net. Refer to the Oracle7 Server Administrator's Guide, and Oracle7 Server Concepts for information on using global object names in distributed databases.

Choosing a Naming Model

Note: DDO always uses a flat naming model.

The most fundamental decision to make before installing Oracle Names is what naming model to use.

There are two types of naming models to choose from:

flat naming model

hierarchical naming model

See Chapter 3, "Oracle Names Architecture", for detailed descriptions of the flat naming and hierarchical models.

Consider Existing Standards

Many companies already have global naming standards for their PC LANs, large hosts, or mail systems. If such policies exist, you can use them as the basis for the Oracle Names naming model. Using the same structure leverages the investment in the education users already have with global names.

For example, many companies with TCP/IP networks use the Domain Name Service (DNS) model for communication on the worldwide Internet . In this model, all naming models are hierarchical from a set of base domains such as :

COM - commercial organizations

EDU - educational institutions

MIL - military

ORG - organizations

Individual companies are then assigned domains within which to build their naming model (for example, ACME.COM). To adapt any example in this book to the DNS Internet model , add a single high-level domain, such as COM (or other stem).

For organizations which are on the Internet, and therefore already have one or more DNS domains, the sensible choice is to align their Oracle naming domains with their DNS domains.

Anticipate Growth

Try to anticipate the growth of the names in the system. A flat naming model may work well until you have several hundreds or thousands of names . At these volumes, a single administrator will be very busy coordinating changes and will likely be dealing with many duplicate name requests . Subdivisions into additional domains , or decentralization of administration reduces the frequency with which this problem occurs.

Know If You Are First

If you are a division of a large corporation, be sure not to assume that you are the only Oracle Names installation in the company. Figure 4 - 1 shows PET Corp, where the Pooch and Mutt divisions each independently installed Oracle Names. Subsequently, they both chose the domain names PET and DOG.PET for some of their names.

Figure 4 - 1. Merging Name Models

At the PET company picnic, the two Oracle Names administrators met and decided to create one delegated region rather than two independent, centralized regions. The MUTT administrator would own the root data, and would rename his DOG.PET domain to PUP.PET. Knowing about each other earlier, or anticipating the possibility of such an event, could have reduced the work involved.

Defining the Administrative Regions

Note: Due to the fact that DDO only works with a single domain region this step is not applicable if you are going to use the DDO.

The Oracle Names system can be divided into multiple cooperative administrative regions . Each region can be independently operated and maintained with a small amount of cross-referenced data. Specifically, all administrative regions must have a copy of all backbone data, which consists of the following :

The communities and Interchanges in the entire network.

addresses of all Names Servers in the root administrative region must be defined in each administrative region.

For more information see Chapter 3, "Oracle Names Architecture" for a detailed description of administrative regions.

Choosing the Administrative Model

There are two basic choices when allocating administrative regions: a single, central administrative region or more than one administrative region.

A region or administrative region is an organizational entity for administering SQL*Net network components. Each region includes one Network Manager, one or more domains, one or more Oracle Names servers, network object definitions, and a network definition. Central administration and the flat naming model (that is, all names within one domain) is the default.

For delegated administration , you define each region and its child regions as region objects in the Network Manager. The highest level parent region is the root region from which all other regions are delegated. The root region always consists of the predefined root domain (the initial hierarchical reference point), and typically also includes, at least, the highest level organizational domain, for example, COM, EDU, MIL, or ORG (for commercial, educational, military, and organization domains).

Establishing Administrative Policies

An important part of running an Oracle Names installation is the planning and methods that all administrators must carry out. All installations need policies on how the following tasks are handled :

Name data requests - How data gets into the Names Server.

Inclusion requirements - What data to allow, and not allow in the Server.

Names Server maintenance - What to do when a Names Server fails.

Delegated administrative installations also require policies for handling the following:

Shared data changes--How to coordinate passing of information to delegated administrators when backbone data changes. (Network data includes communities and MultiProtocol Interchanges in the entire network, and all Names Server addresses in the root region.)

Administrative region requirements--The minimum requirements for allowing portions of the naming model to become delegated administrative regions.

See Chapter 3 "Oracle Names Architecture" for a detailed description of administrative regions.

Determining The Number of Names Servers

Note: There can be no more than five well-known Names Servers when you use the DDO.

Using a system like Oracle Names makes users dependent on access to the names it stores. If a system had a single Names Server, and that server were unavailable, no client-server applications in the network could communicate. It is therefore very important to ensure high availability of data in the network's Names Servers.

Two Names Servers Per Region

Oracle recommends that each administrative region should have at least two Names Servers. If one Names Server is unavailable , clients will automatically forward requests to the other. The degree of availability this allows depends on the regularity of service each node provides. For example, imagine that the amount of time a Name Servers node is down for unscheduled reasons is 1%. (It is usually much less.) The likelihood that both would be down at the same time is then roughly .01%, or 1% of 1%.

There is also an issue of network loading, or load balancing. Although any given Names Server is only engaged for a short period of time when a client initiates a connection, the goal is to keep name resolutions lightning fast. With a very large volume of clients, or applications requiring many connections, load balancing across multiple Names Servers can increase system performance.

One Names Server Per Community

It is strongly recommended that regions with multiple communities offer at least one Oracle Names Server per community. (Refer to the glossary for a definition of communities.)This can be either a single Names Server between multiple communities , or separate Names Servers in each community. This is not a technical restriction--using a MultiProtocol Interchange, the client could connect to a Names Server in another community. However, this is presented as a strong recommendation to avoid name requests travelling through an Interchange to resolve a name. Connection time through an Interchange is commonly on the order of a few seconds rather than the milliseconds in which a name should be resolved.

In multi-community installations, it is recommended that Names Servers be installed on nodes with MultiProtocol Interchanges between the communities. The benefit is that all clients in all communities the Names Server node is on can access it. The Interchange node is an obvious candidate because it always runs multiple protocols.

Names Server Proximity to Clients

In general, the closer data is to a client, the faster it is retrieved, and the less likely it will be made unavailable by network failures. Clients should be able to reliably get to at least one Names Server in less than a second . If they cannot, consider adding another Names Server to serve those clients.

For example, an installation with a single administrative region administered out of Hong Kong with three Names Servers, two in Hong Kong and one in Japan may provide fast, high availability to some Eastern countries but could leave offices elsewhere in the world subject to poor performance and network outages. Remember if the Names Server is unavailable, client connections are disabled. Installing additional Names Servers in the USA, Europe, and elsewhere would provide clients in those areas with more reliable name resolution. All Names Servers could still be maintained (with respect to names data and management) from the single administrative region in Hong Kong, but would be physically close to the clients.

Selecting Names Servers Nodes

Note: If you have successfully installed the Oracle Names software you have already made this choice.

An Oracle Names Server is portable software that runs on a variety of computer platforms . You can obtain specific platform and operating system availability information from your Oracle representative. In general, Oracle Names runs on:

A variety of UNIX and VAX/VMS minicomputers and workstations.

Intel-based computers (PCs) running operating systems such as OS/2, NetWare, Windows NT, and UNIX.

The computer does not have to be dedicated as an Oracle Names Server. In fact, Oracle Names typically requires relatively little CPU and memory to function.

Your choice of computer to use as a Names Server should be based on:

Software availability--While Oracle Names runs on many operating systems , it does not run on all. As a shared resource, Oracle Names only needs to be on one type of operating system to serve all clients and servers. It does not have to be available on all of the operating systems you use.

Node availability and maintenance --A server that is monitored and maintained by a group assigned the task of maintaining the system is best. A failure on a corporate data center computer is more likely to be recognized and fixed quickly than if the computer is on an someone's desk. Data center computers are also more commonly backed up and diagnosed regularly. These criteria tend to favor UNIX, VMS, or PC LAN file server nodes, all of which are commonly maintained in a data center.

Community coverage --As stated above, in a multi-community SQL*Net network, choosing a MultiProtocol node as a Names Server minimizes the number of nodes that need to be installed for redundancy. There is no requirement that the Names Server run on a MultiProtocol node; it is a matter of minimizing administrative overhead for complete name service coverage.

Note: Currently, you are required to have a Names Server in every community. In general, Oracle recommends that Names Servers in a multi-community network be placed on Interchange nodes, thereby minimizing the number of Names Servers required.

CPU availability --The node chosen must have adequate CPU, memory, and disk space available for an Oracle Names installation. Beyond the operating system and any other activity on the machine, Names must have the resources it needs to run. Installation on an old 386 PC, or a loaded-down UNIX server will not allow the system to perform optimally.

If the node you have chosen already has SQL*Net or an Interchange on it from a previous installation, the node should already be defined. You enter information such as the following on the Name Server property sheet in the Network Manager:

protocol-specific address information

Names Server password

log and trace file names

You must enter the address information; however, all other values have defaults. If you have security concerns, it is always good practice to change the default password.

Prev Next

Library

Product

Contents

Index