Cloud CM-IPMP Průvodce řešením problémů stáhnout pdf (Strana 58)

• A new database name will be needed; otherwise the existing database will be overwritten by the new cluster. The existing

PostgreSQL installation can be used.

• The SLEE will need to be installed in a new directory.

• The Management Interface RMI Registry Port (default of 1199) needs to be a free port.

• The Management Interface RMI Object Port (default of 1200) needs to be a free port.

• The Management Interface JMX Remote Service Port (default of 1202) needs to be a free port.

• The Standard Web Console HTTP Port (default of 8066) needs to be a free port.

• The Secure Web Console HTTPS Port (default of 8443) needs to be a free port.

• Most importantly, a new Cluster ID will be needed.

Note that the RMI Registry Port, RMI Object Port and the JMX Remote Service Port are consecutive numbers, so a whole new

range of ports for these services will be needed to be found.

The same UDP multicast address range can be used for both clusters – the cluster ID is sent in the UDP multicast packets, and

clusters will ignore trafﬁc that is not their own.

Next, create nodes and initialise the database (as described in Chapter 4) and try to start up the nodes.

6.3.3 Deploying State

Deploying state on the new cluster is simply a case of running the

ant

utility in the exported directory. To do this, ﬁrst edit the

import.properties

ﬁle in the

export/

directory to point to the client directory of the new cluster.

Then, with the new cluster active but in the

stopped

state, run

ant

in that directory. This should deploy the old cluster’s state

on the new cluster.

6.3.4 Activating the new Cluster

To activate the new cluster, use the

start

command on the Command Console, or use the Web Console to put the cluster into

the

running

state. If all has gone to plan, the new cluster should start receiving and processing tasks.

Ensure that the new cluster is performing as expected. Make use of the statistics client and watch the output to Rhino’s logs to

ensure the new cluster is performing as expected.

6.3.5 Deactivating the old Cluster

The old cluster should now be able to be deactivated. To do this cleanly, put the old cluster into the

stopped

state using the

stop

command on the Command Console. The old cluster will take some time to drain out activities depending on the nature

of those activities.

The

waitonstate stopped

command can be used to wait until the cluster has processed all activities and returned to the

stopped

state.

If activities linger around for several hours longer than they are meant to, it could be possible that a glitch in the system has

prevented them from being cleaned up. The

findActivities

and

getActivityInfo

commands can be useful for diagnosing

hanging activities. To remove these activities, use the

removeActivity

command.

Finally, the cluster can be shut down. This can be done using the

shutdown

command, or by using the

stop-rhino.sh

with

the

--cluster

argument.

As a ﬁnal resort, the

kill

command or its alternatives can be used from the system shell to kill errand nodes or processes. Use

these commands with care; it would not be good to kill the new cluster accidentally.

Open Cloud Rhino 1.4.3 Administration Manual v1.1 49

1 2 ... 53 54 55 56 57 58 59 60 61 62 63 ... 200 201

Cloud CM-IPMP Průvodce řešením problémů Strana 58

Komentáře k této Příručce