Additional documents of interest
- Successful Business Continuity - Part 1 - Users and Groups
-
This article was published in the April 2005 issue of
AIX Update magazine
and discusses system administration needs and requirements oriented
around users and groups. The overall emphasis of this series of
articles is for implementation of enterprise wide unique identifiers
for a variety of parameters, such as user names, group names, UID and
GID numbers.
- Successful Business Continuity - Part 2 - Machine and Host Names
-
This article was published in the May 2005 issue of
AIX Update magazine
and discusses naming structures for machines, systems, adapters, and
aliases. The overall emphasis of this series of articles is for
implementation of enterprise wide unique identifiers for a variety of
parameters.
- Successful Business Continuity - Part 3 - Volume Names
-
This article was published in the December 2005 issue of
AIX Update magazine
and discusses naming structures for volume groups, logical volumes, log
logical volumes, directory mount points, etc. The overall emphasis of
this series of articles is for implementation of enterprise wide unique
identifiers for a variety of parameters.
- Successful Business Continuity - Part 4 - MQ Series, Startup/Shutdown Scripts, Error Processing
-
This article was published in the April 2006 issue of
AIX Update magazine
and discusses how to implement AIX in an environment dedicated to
business continuity. The topic of this article is the assignment of MQ
Series queue names and aliases, resource group startup and shutdown
script names (Application startup/shutdown script names), error logging,
and error notification.
- Successful Business Continuity - Part 5 - Miscellaneous topics
-
This article was published in the August 2006 issue of
AIX Update magazine
and discusses how to implement AIX in an environment dedicated to
business continuity. A variety of topics is discussed in this article
including automated documentation generation and management.
- Automated Microcode Management System
-
One of the most difficult administration tasks in an AIX environment is
attempting to keep the firmware and microcode up-to-date. Mt Xia has
devised an automated method of gathering the Microcode information,
determining which microcode needs to be updated, generating reports, and
uploading the required microcode updates to each individual system.
- Calculating the size of a Virtual Processor
-
This document describes the algorithms used to calculate the size of a
virtual processor when using shared processors in an LPAR. The IBM
documentation describes how to calculate CPU utilization, NOT how to
size for configuration, this document clarifies this process. A
description of the HMC input fields for the processor tab is included.
- Basics of Partition Load Manager Setup
-
This presentation was provided by Ron Barker from IBM regarding the PLM Basic
setup.
- ppt
- pdf
|
Hostname Standards
In order to achieve maximum flexibility during normal operations,
maintenance, disaster recovery, and business continuity efforts, it is
important to provide a naming standard for business functions that can
be translated easily into hostnames and/or aliases. The purpose of
using hostnames instead of IP addresses is that they are easier to
remember and use. Hostnames are not necessary, but usually
desirable.
Normal user access to an application or business function will always
be through an alias. Normal users should never access a system using a
hostname. The reason is for portability and availability. It is easy
to redirect an alias to any host, it is significantly more difficult to
change hostnames. By having the users access required services through
aliases rather than hostnames, the users can be redirected quickly to
available services in the event of a failure.
Hostnames
In Mt Xia's environment, a hostname refers to an IP address, the IP
address is associated with one or more network adapters. It is
important to recognize that an IP address is not necessarily tied to a
network adapter, but may float across adapters and machines. The same
is true with the hostnames. A hostname should be viewed as
being independent from any machine or data center. The
hostname shall be an enterprise wide unique value in order to eliminate
conflicts during manual, automated, or disaster recovery failovers.
The hostname shall consist of exactly 10 characters with the
following structure:
LocationCode + OS Type + Environment + ApplicationCode + SequenceID
3 char + 1 char + 1 char + 3 char + 2 char = 10 char
The detailed information for each component of the resource group
name is described below:
HostName
Component
|
Number of
Characters
|
Values
|
Location Code
|
3
|
dal = Dallas Data Center
bos = Boston Data Center
|
OS Type
|
1
|
a = AIX
s = Sun
|
Environment
|
1
|
a = acceptance
a = pre-production
d = test/development
p = production
t = test
x = disaster recovery
x = pre-production
|
Application Code
|
3
|
atl = Atlas
ega = EGATE
nim = NIM
ora = Oracle
tps = Maximo
vio = Virtual I/O
|
Sequence ID
|
2
|
0-9,A-Z,a-z
|
Examples of Hostnames (HN):
- dalapega01
-
EGATE Production database on AIX at Dallas Data Center, first instance
- dalapega01
-
EGATE Production database on AIX at Dallas Data Center, second instance
- bosapnim01
-
Production Network Information Manager on AIX at Boston Data Center, first instance
- dalapnim01
-
Production Network Information Manager on AIX at Dallas Data Center, first instance
- bosapvio01
-
Production Virtual I/O Server on AIX at Boston Data Center, first instance
- bosapvio02
-
Production Virtual I/O Server on AIX at Boston Data Center, second instance
- bosapvio03
-
Production Virtual I/O Server on AIX at Boston Data Center, third instance
- bosapvio04
-
Production Virtual I/O Server on AIX at Boston Data Center, fourth instance
- dalaavio01
-
Acceptance Virtual I/O Server on AIX at Dallas Data Center, first instance
- dalaavio02
-
Acceptance Virtual I/O Server on AIX at Dallas Data Center, second instance
- dalaavio03
-
Acceptance Virtual I/O Server on AIX at Dallas Data Center, third instance
- dalaavio04
-
Acceptance Virtual I/O Server on AIX at Dallas Data Center, fourth instance
Aliases
The rules for defining alias names are significantly less rigid than
for hostnames. The alias can be any name as long as it is unique within
the domain. This allows the application to be accessed though a name
that makes logical sense to the user. For example, the production EGATE
Application Server at the Dallas Data Center may have a hostname of
"bosapega03", however the alias may be "bosegate". The use of aliases
preserves the structure needed for hostnames and the ease of use desired
by users.
|
|
|