Hello,
On 02/10/2009 07:55 PM, Zahid Mehmood wrote:
Thanks for your reply.
May I trouble you and others on the list to share the deciding factors (pros & cons) for choosing the option that you did.
the benefit of a cluster is that it was designed for such cases. The drawback is that MySQL version still is pretty early stage. However, there are success stories and production environments with the cluster in place.
I am particularly going for user partitioning. It does not make full service unavailable if one db node is down. When partitioning is very important to group users by probability to talk inside the group.
As example, put all IT guys in the same node, they are very likely to talk in between a lot to solve issues. Of course, such distribution can be considered on geographic location if you deal with branch offices, a.s.o.
Each node is replicated for HA and failover - active-active or active-standby, depending on needs.
The communication between nodes is another part. Depending on number of nodes, you can have static binding of users and nodes or a proxy node that just gives back the node of one user. So you look for user on local node and if not found ask the proxy node.
I am designing and implementing the platform mainly based on customer expertise. If they feel more comfortable with a cluster, that is. Practically they are the ones that have to manage the system in a day by day manner and integrate with third party components.
I'm trying to get a better understanding circumstances in which you may choose one over the other.
What, if any, special considerations are there for the presence part?
Presence has more sip traffic, requires more memory to store and aggregate the presence documents. Therefore I recommend you have dedicated nodes as presence servers. It helps a lot in scaling and ensuring service availability for basic telephony (registration and call routing).
Cheers, Daniel