This section focuses on setting up your system to be highly available, including configuring the high availability infrastructure provided by this product, and having your applications take advantage of it.
Follow these shortcuts to get started quickly with popular tasks.
The high availability framework that is provided with the product eliminates single points of failure and provides peer to peer failover for applications and processes running within the product environment. This infrastructure is managed by a high availability manager and includes cells, clusters, core groups, and high availability groups. Every high availability group has a policy associated with it that the high availability manager uses to determine which members of a high availability group are active at a given time.
The product includes a high availability manager component. The services that the high availability manager provides are only available to product components.
A unique HAManagerService configuration object exists for every core group member. The enable attribute in this configuration object determines if the high availability manager is enabled or disabled for the corresponding process. When the enable attribute is set to true, the high availability manager is enabled. When the enable attribute is set to false, the high availability manager is disabled. By default, the high availability manager is enabled. If the setting for the enable attribute is changed, the corresponding process must be restarted before the change goes into effect. You must use the wsadmin tool to disable or enable a high availability manager.
High availability groups are dynamically created components of a core group. They cannot be configured directly, but they are directly affected by static data, such as policy configurations, which is specified at the core group level. You can use the administrative console to view information about the high availability groups that are part of a core group.
Every high availability group has to have an associated policy. This policy determines which members of a high availability group to put in the active state.
Every high availability group has an associated policy. The high availability manager uses this policy to determine which members of a high availability group to put in the active state.
A default core group, called DefaultCoreGroup, is created for each cell. This default core group or high availability domain as it is sometimes referred to, is sufficient in most configurations. However there are some circumstances under which you need to create additional core groups for a cell.
A core group is a component of the high availability manager. A default core group, called DefaultCoreGroup, is created for each cell. A core group can contain application servers, proxy servers, node agents, and the deployment manager. A core group must contain at least one node agent or the deployment manager.
A core group member is an application server, proxy server, the deployment manager, or a node agent that is a member of a high availability core group.
When moving members to a different core group, remember that: each process can only be a member of one core group, and that all members of a given cluster must belong to the same core group.
The core group bridge service can be configured to establish communication between core groups. A core group is a statically defined component of the high availability manager. To configure communication between core groups, use an access point group. An access point group is a collection of core groups that communicate with each other.
This page provides a starting point for finding information about service integration.
This page provides a starting point for finding information about data access. Various enterprise information systems (EIS) use different methods for storing data. These backend data stores might be relational databases, procedural transaction programs, or object-oriented databases.
This page provides a starting point for finding information about Java Transaction API (JTA) support. Applications running on the server can use transactions to coordinate multiple updates to resources as one unit of work, such that all or none of the updates are made permanent.