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 do one of two things:
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.
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:
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
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.
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.