A Fusion Application Server (FAS) cluster is made up of one or more host machines (also referred to as nodes), each one running one or more of the component server processes (Application Server (AS), Load Balancer (LB), or Management). These server processes are grouped by a domain into server groups, each of which is associated with a set of subsystems (for example, logging, web, SIP), called a profile. For details on the relationship between domains, server groups, servers, and profiles, see the Fusion Application Server Architecture Guide.
One of the processes that make up each FAS is its Host Controller, which provides the FAS's management interfaces. Although each FAS node has a Host Controller, one is singled out as the master Host Controller, known as the Domain Host Controller. In multi-box installations, one of the hosts is installed as the master node (see the Fusion Application Server Installation Guide), and it is the master node which contains the Domain Host Controller.
Domains
All ASs and LBs in a domain share the same Domain Host Controller, which offers a single point of administration to all the other slave Host Controllers within the domain.
The Domain Host Controller can manage the cluster using the Management Console or a CLI, whereas slave host controllers only offer a limited read-only CLI interface.
When it starts, a slave Host Controller will attempt to read its configuration from the Domain Host Controller. This process ensures that all hosts in a domain have the same configuration.
The installer decides which node is the master node that runs the Domain Host Controller, and that node remains the master node; there is no automatic process for replacing a failed master node. (There is a manual process which could be followed but we do not recommend this). However, a FAS cluster can continue successfully when a master node is down, and high availability is unaffected. The only effects are a reduction in capacity, and that configuration changes cannot be made until the master node is back up.
Server Groups and Server Processes
A single FAS cluster contains several server processes, each running on one of the nodes which make up the cluster. These server processes are grouped into server groups, even if the server group only has a single server process associated with it. All server processes in a server group have a consistent configuration. They are all configured with the same profile and have the same deployment content, such as the applications deployed. Server processes on different nodes can belong to the same server group, so that you can configure all the server processes in a server group together, whatever node they run on.
On installation, a host typically has two or three server processes running on it, each belonging to a separate server group:
-
An AS process, belonging to the main-server-group.
-
An LB process, belonging to the lb-server-group.
-
The Domain Host Controller on the master FAS node runs as an additional server process that runs in its own server group, called mgmt-server-group. This server process runs the License Server and Trust Management module.
A domain can have multiple server groups. You can configure different server groups with different profiles and deployments; you can also configure different server groups with the same profile and deployments.
Profiles
A profile is a named list of subsystems, such as logging, Web, and SIP, along with the details of each subsystem's configuration. For example, a profile specifies the logging configuration such as handlers and log categories. Multiple server groups can share the same profile.
The installer creates three default profiles:
- management
Contains the default configuration suitable for hosting non-SIP, non-HA applications. It is used to configure a server process for CBA management subsystems and applications such as trust management, SNMP and licensing.
- ha
Contains the default configuration for the ASs in the main-server-group.
- lb
Contains the default configuration for the LBs in the lb-server-group. The LB profile is a lightweight profile that lacks JEE and JSR 289 subsystems; it therefore exposes less configuration options and cannot host JEE or SIP applications.
Administrators might want to alter a profile's configuration. For example, an administrator might add a datasource with details of database connection details, or an Infinispan cache that replicates data to all nodes in the server group. Applications deployed to server processes with that profile can then use these resources.
The profiles can also change the behavior of subsystems. For example, you can configure the JMX subsystem to expose the domain configuration model as MBeans.
Comments
0 comments
Please sign in to leave a comment.