You can create, configure, and administer multiserver domains that are based on native clustering. With native clustering he domain receives a native clustering implementation based on TOTEM, but you cannot take advantage of Oracle Event Processing high availability quality of service options. If you require high availability quality of service options, build your multiserver domain with Oracle Coherence.
This chapter includes the following sections:
To create a multiserver domain, start by using the Configuration Wizard to create one domain with one server. This is a standalone-server domain. To convert the standalone-server domain to a multiserver domain, you can either:
Copy and rename the server you just created and then edit the config.xml
file for each server so that they all have the same multicast name, multicast port, and domain name.
Use the Configuration Wizard to generate additional stand-alone servers and then edit the config.xml
file for each server so that they all have the same multicast name, multicast port, and domain name.
The procedures in this chapter use the first approach.
You can create a multiserver domain that uses only the two predefined deployment groups described in Singleton Server Deployment Group. The predefined deployment groups are the singleton group and the domain group. In a domain that uses default groups, all servers must be completely homogeneous.
If a domain must support servers that are not completely homogeneous, configure this by creating custom groups. See Create a Multiserver Domain with Custom Groups.
Create a multiserver domain with default groups:
Use this procedure if you plan to deploy applications that are not homogeneous and require a custom configuration. If all of the servers in your domain are completely homogeneous, you do not need to create custom server groups. Instead, use the predefined default server groups: the singleton group and the domain group. See Create a Multiserver Domain with Default Groups.
In this procedure, assume you have created three servers: myServer1
, myServer2
, and myServer3
. You want myServer1
to be a member of the selector
group and myServer2
and myServer3
to be members of the strategy
group.
Create a multiserver domain with Custom Server Groups:
You update servers in a multiserver domain the same way that you update the one server in a standalone-server domain: You either launch the Configuration Wizard or edit the XML properties file to use silent mode. The only difference between updating one server and multiple servers is that in a multiserver domain, you perform the update on each server individually. Using an XML properties file in silent mode might be your best option in a multiserver domain.
When you use the Configuration Wizard to update a server, you can update only the listen port and the JDBC data source configuration. In silent mode, you can add a server and update anything for which there is a data value.
To update the existing configuration of an existing server you provide values for the following data values in the XML properties file:
Set CONFIGURATION_OPTION
to updateDomain
.
Set the DOMAIN_NAME
and DOMAIN_LOCATION
options to the name and location of the existing domain. In the example, the values are myDomain
and C:\Oracle\Middleware\my_oep\user_projects\domains
, respectively.
Set the SERVER_NAME
option to the name of the new server you want to add to the existing domain. In the example, this would be myServer2
.
If this server is running on the same computer as the other servers in the multiserver domain, then be sure that the new server configuration options, such as NETIO_PORT
are different than the options for any existing server in the domain. The database options can be the same if you want the new server to connect to the same database as the existing servers.
If the server is on a different machine than the other servers in the multiserver domain, then the ports do not have to be different.
The following example is an XML properties file that updates an existing server in a multiserver domain.
<?xml version="1.0" encoding="UTF-8"?> <bea-installer xmlns="http://www.bea.com/plateng/wlevs/config/silent"> <input-fields> <data-value name="CONFIGURATION_OPTION" value="createDomain" /> <data-value name="USERNAME" value="wlevs" /> <data-value name="PASSWORD" value="wlevs" /> <data-value name="SERVER_NAME" value="myServer1" /> <data-value name="DOMAIN_NAME" value="myDomain" /> <data-value name="DOMAIN_LOCATION" value="C:\Oracle\Middleware\my_oep\user_projects\domains" /> <data-value name="NETIO_PORT" value="9102" /> <data-value name="KEYSTORE_PASSWORD" value="my_keystore_password" /> <data-value name="PRIVATEKEY_PASSWORD" value="my_privatekey_password" /> <data-value name="DB_URL" value="jdbc:bea:oracle://localhost:1521:XE" /> <data-value name="DB_USERNAME" value="db_user" /> <data-value name="DB_PASSWORD" value="db_password" /> </input-fields> </bea-installer>
The servers in a multiserver domain update their state by exchanging multiserver-related messages. These messages should be checked for integrity. You can use a private key to ensure integrity. The private key must be shared by all of the servers within the domain.
Secure Messages Sent Between Servers
In an active-active system, you deploy actively executing applications homogeneously across several servers. There are cases when these homogeneously-deployed applications need to elect a coordinator application to lead. In this case, events that result from the coordinator application are kept and passed to the next component in the EPN. The results of secondary servers are dropped. If the coordinator fails, then one of the secondary servers must be elected as the new coordinator.
To enable this behavior in an application, the adapter or event bean, usually in the role of an event sink, must implement the following interface:
com.bea.wlevs.ede.api.cluster.GroupMembershipListener
This interface enables the event sink to listen for multiserver domain group membership changes. At runtime, Oracle Event Processing calls the onMembershipChange
callback method whenever membership changes occur.
The callback method signature follows:
onMembershipChange(Server localIdentity, Configuration groupConfiguration);
In the implementation of the onMembershipChange
callback method, the event sink uses the Server
object (localIdentity
) to verify if it is the leader. This can be done be comparing localIdentity
with the result of Configuration.getCoordinator()
run on the second parameter, groupConfiguration
. This parameter also allows a server to know what the current members of the group are by executing Configuration.getMembers()
.
To only keep events when it is a coordinator, the event sink must get a new Server
identity every time membership in the group changes. Group membership changes occur when, for example, another server within the group fails and is no longer the coordinator.
The following interface is for listening to membership changes to the domain as a whole, rather than changes to the server group.
com.bea.wlevs.ede.api.cluster.DomainMembershipListener
In a hot-hot configuration, there is a non-zero delay in failure notification. If you use the notification APIs to implement clustering, you will lose and not process events that occur in the window of time between the server failure and the notification being delivered to the new master server.
See Oracle Fusion Middleware Java API Reference for Oracle Event Processing.
To start the servers in a multiserver domain, start each server separately by running its start script. This is the same way you start a server in a standalone server domain. See Start and Stop a Server in a Standalone-Server Domain for details.
If you have not configured custom groups for the multiserver domain, then all servers are members of just the predefined domain group, which contains all the servers in the multiserver domain, and a singleton group, one for each member server. This means, for example, if there are three servers in the multiserver domain then there are three singleton groups.
If, however, you have configured custom groups for the multiserver domain, then the servers are members of the groups for which they have been configured, as well as the pre-defined groups.