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:
- 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
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:
Delegated administrative installations also require policies for handling the following:
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.
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:
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.
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
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.
