git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Designing for maximum Artemis performance


I am using AWS and paying for three EC2 instances (the 'servers'). I am
deploying a server in each AWS Availability Zone (AZ) and in the region I am
using there are 3 AZ. I am running three servers with a master (as part of a
cluster) on each, to maximum performance of the applications connecting to
Artemis.

For arguments sake, let's assume I can get performance of 200MB/s on _each_
server. So a maximum of 600MB/s across the whole 'environment'.

Consider the following setup:

- server1 in AZ1: Master-1, Slave-3, Backup-2
- server2 in AZ2: Master-2, Slave-1, Backup-3
- server3 in AZ3: Master-3, Slave-2, Backup-1

In the scenario I'm trying to design for is the lose of a server or AZ. At
the moment, if I lost server1, then: 

- server2 (initially as slave-1) would become master-1.
- server3 (initially as backup-1) would become slave-1.

When server1 comes back online, because server2 is now master-1 and server3
is slave-1, it would just remain as an idle-backup. That is: there would no
longer be ANY masters running on server1.

At the moment, the result of this is:

- I'm paying for 3 servers, but only 2 are performing the roles of master
(server2 is master-1 and master-2 and server3 is master-3).
- I can only get the performance out of 2 servers and not 3, i.e. 400MB/s
and not 600MB/s.

So my questions are:

1) Is the only way to ensure that server1 becomes the master-1 is by
manually restarting the brokers on each server, to return them to their
original master/slave/backup state? 

2) If a manual restart of the brokers is the only way to restore them to
their original state and have a master on each server per AZ, would it be
desirable to allow for fail back to work across live and multiple backups? 

3) If not, how else might I achieve ensuring that there is a always a master
on each server, across each AZ?





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html