Analyzing the Application for Suitability

This section describes the guidelines you must follow in creating applications to be managed by Geographic Edition software.

Before you create an application to be managed by Geographic Edition software, determine whether the application satisfies the following requirements for being made highly available or scalable.

• Both network-aware (client-server model) and network-unaware (client-less) applications are potential candidates for being made highly available or scalable in the Geographic Edition environment. However, Geographic Edition cannot provide enhanced availability in timesharing environments in which applications are run on a server that is accessed through telnet or rlogin.

• The application must be crash tolerant. That is, it must recover disk data (if necessary) when it is started after an unexpected node death. Furthermore, the recovery time after a crash must be bounded. Crash tolerance is a prerequisite for making an application highly available because the ability to recover the disk and restart the application is a data integrity issue. The data service is not required to be able to recover connections.

• The application must not depend on the physical host name of the node on which it is running.

• The application must operate correctly in environments in which multiple IP addresses are configured to go up. Examples include environments with multihomed hosts, in which the node is located on more than one public network, and environments with nodes on which multiple, logical interfaces are configured to go up on one hardware interface.

• Application binaries and libraries can be located locally on each node or in the cluster file system. The advantage of being located in the cluster file system is that a single installation is sufficient. The disadvantage is that when you use rolling upgrade for Oracle Solaris Cluster software, the binaries are in use while the application is running under the control of the Resource Group Manager (RGM).

• The client must have capacity to retry a query automatically if the first attempt times out. If the application and the protocol already handle the case of a single server crashing and rebooting, they also can handle the containing resource group failing over or switching over.

• The application must not have UNIX domain sockets or named pipes in the cluster file system.

A scalable service must meet all the preceding conditions for high availability as well as the following additional requirements.

• The application must have the ability to run multiple instances, all operating on the same application data in the cluster file system.

• The application must provide data consistency for simultaneous access from multiple nodes.

• The application must implement sufficient locking with a globally visible mechanism, such as the cluster file system.

For a scalable service, application characteristics also determine the load-balancing policy. For example, the load-balancing policy Lb_weighted, which allows any instance to respond to client requests, does not work for an application that makes use of an in-memory cache on the server for client connections. In this case, you should specify a load-balancing policy that restricts a given client's traffic to one instance of the application. The load-balancing policies Lb_sticky and Lb_sticky_wild repeatedly send all requests by a client to the same application instance, where they can make use of an in-memory cache. If multiple client requests come in from different clients, the RGM distributes the requests among the instances of the service.

See Chapter 2, Developing a Data Service, in Oracle Solaris Cluster Data Services Developer’s Guide for more information about setting the load-balancing policy for scalable data services.

The application must be able to meet the following data replication requirements:

• Information replicated must not be host– or cluster-specific.

  When the application fails over to the remote site, the application might run on a host with a different IP address. To allow client nodes to find the remote site, use a Geographic Edition action script to update the DNS/NIS mapping.

• If you don't want your application to tolerate any data loss, the application should use synchronous replication.