Designing an Application Server

To provide a complete implementation of these techniques throughout an environment, the tasks on the server include the following:

•  Identifying servers to specialize in providing application access

•  Implementing the fewest possible slices (partitions) to contain the software packages

•  Performing software installations on these servers in a consistent file system layout

•  Sharing the application server file system read-only to users

•  Naming package directories in a way that reflects both the application name and the version

•  Installing packages initially per vendor instructions and then (if necessary) adjusting them to simplify and encapsulate their structure

•  Creating a value-added subhierarchy within each application

•  Creating wrappers for applications, to eliminate or minimize any requirement for hard-coded setup on the part of individual users

•  Installing wrappers into their respective application value-added subhierarchy

•  Creating all application command names as symbolic links in a common directory, and creating symbolic links to point to the application wrapper

•  As applications are added to a server, updating other servers appropriately, using rdist

•  Separating servers for network services (NIS/NIS+, DNS, NTP, mail, and so on) from application servers in all but the smallest environments

The tasks in the user environment include:

•  Setting up users with the appropriate mount point and mount to access the application server

•  Setting up users with a path that includes the common command directory

The following sections describe in greater detail the basic tasks involved in a general implementation. However, coverage of many topics necessarily is superficial, and the overall model is simplified.

Server Configuration

Consider the following points when designating servers to act as application servers:

•  Choose server configurations that you believe to be robust. Consolidating applications into one location simplifies life only to the extent that the system provides ongoing, reliable service. Typically, when application service is down, users are down.

•  Choose servers that can retain their identities for reasonable lengths of time. Hostname changes require mount maintenance, and hostid changes can make licensed passwords obsolete.

User Capacity

It is impossible to offer specific guidelines concerning the number of servers you will require. Your goal is to provide reasonable NFS response time to all clients served. The user ratio you can support depends on many factors, such as the server characteristics, network characteristics, the types of applications being served, and the number of clients.

Try to locate application servers on the same network segments as the bulk of their clients. As a rule, you obtain the best response if you minimize NFS traffic through routers and other store-and-forward network devices.

Automounter maps for application directories are especially useful when applications are moved from one server to another.

Compatible Services

It is probably simplest to dedicate a server exclusively as an application server. If, however, it is impossible or impractical to do so in your environment, you may need to implement a multipurpose server.

Certain services present little conflict with NFS service because of their light weight or typical scheduling. Examples include license service and backup service. Additional, nonapplication NFS roles, such as sharing client root or home directory file systems, may have some impact on application response time.

---

NOTE:  For its role as an NFS server, a platform need not be typical of the user base platforms. However, if an application server is also to act as a license server, it must be capable of running the license support binaries provided by the application vendors.

---

Other functions are incompatible with optimum NFS performance because they make heavy CPU and I/O demands. Examples of incompatible functions include back-end database engine, development activity, and routing.

Disk Allocation

You need to allocate adequate space for applications on the server, allowing ample space to accommodate future additions. Also remember that you may need space for multiple versions of some applications as you transition users to newer versions.

As noted earlier, you want to serve applications from a single file system to minimize user mounts. If your overall application space requirements exceed the size of your largest disk, you may want to use the Solstice DiskSuite product. This product lets you concatenate (group together) multiple physical disk slices into one logical metaslice. DiskSuite offers other performance and high-availability enhancements, such as striping, mirroring and “hot spare” capability. For more information about the Solstice DiskSuite product, refer to “DiskSuite” on page 510 of Appendix B.

Contrary to system defaults, put /, /usr, and /opt into a single partition large enough to hold dozens or hundreds of patches as well as providing enough room for an OS upgrade.

File System Configuration

The following sections suggest a basic file system configuration for application servers. When you create one or more application servers, you generally provide a single file system with a consistent directory hierarchy. In that way, you create an environment that is consistent throughout your organization.

Base Directories

When you have a server with a disk slice (partition) that you consider adequate for long-term use as an application server, you can begin to implement the file system itself. As a foundation, SunSoft recommends that you create a minimum of two standard directories, which, in this model, we name /usr/apps/exe and /usr/apps/pkgs, respectively.

You install symbolic links or wrappers that represent all the available commands used to execute applications in the /usr/apps/exe, the common command directory. You install all of the applications in the /usr/apps/pkgs directory.