blob: f6d16d751f5331e32eebd42dba38f5ae6d196d33 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
-*-org-*-
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership. The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied. See the License for the
# specific language governing permissions and limitations
# under the License.
* Active/passive cluster implementation
The active-active cluster can be used in an active-passive mode. In
this mode we would like the cluster to be as efficient as a strictly
active-passive implementation.
An active/passive implementation requires a subset of the active/active approach:
- drop Queue ownership and locking
- replicate subset of Cluster interface, don't need to know all message disposition.
Can re-use:
- cluster membership
- new member updates
- store integration
Simpler implementation of broker::Cluster:
- act like distributed MessageStore. Don't need acquisition details.
- can do immediate local enqueue and still guarantee order.
- can use smaller message IDs: just sequence number. Can be implicit.
Extra requirements:
- Exactly one broker hast to take over if primary fails.
- Passive members refuse client connections and redirect to active member.
- On failover, clients keep trying till they find the active member.
** Active/active vs. active passive
Active/active benefits:
- Total # connections: practical 60k limit per node.
- Handle client losing connectivity to one cluster node - can fail over to any.
- Some load sharing: reading from client + multicast only done on direct node.
- Clients can switch to any broker on failover
- Failure affects a subset of the clients, not all the clients.
Active/active drawbacks:
- Co-ordinating message allocation impacts performance.
Active/passive benefits:
- Don't need message allocation strategy, can feed consumers at top speed.
Active/passive drawbacks:
- All clients on one node so a failure affects every client in the system.
- After a failure there is a "reconnect storm" as every client reconnects to the new active node.
- After a failure there may be a period where no broker is active.
- Can't help clients with no connectivity to the active member.
- Clients must find the single active to fail-over.
|
