We are currently looking at the best ways of deploying ZK ensemble to
our production pod. And I have two things I'd like to clarify (sorry if
it has been already answered but I did not find exact confirmation in
1. To provide redundancy our POD has two network switches connected to
each blade through different interfaces. So in case of failure of the
switch blades will still be connected to the network. Practically it
means that each blade will have two ips and at least one of them should
be available. So my question is how to reflect this fact in zk
configuration? Is there any way to provide multiple addresses for a
single server? Is it just multiple records in config file? Any catch
here? What is the best practice?
2. The second question regarding the best way of organizing DR policies.
Basically we want to periodically backup zk state so we will be able to
restore it remotely. In case of a single node ensemble just backing up
last data snapshot + log should be completely enough. But it is not
completely clear to me what would be the best practice in case of a
cluster? Should I maintain the backup of all nodes and try to restore it
as a cluster? But in such case how cluster will resolve possible
timedifference between taking snapshots? It feels enough to backup only
one node and than bring the whole cluster out of it, but how do I know
that the node I am planning to backup is a best one? Is it correct to
say that it is safe to backup any currently healthy node? What are the
common practices here?
Sorry if the answers are well known, but I am just starting...
This e-mail message and all attachments transmitted with it may contain privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message, all attachments and all copies and backups thereof.
Mahadev Konar 2011-01-03, 20:05
Sergei Babovich 2011-01-03, 20:58
Ted Dunning 2011-01-03, 21:43
Mahadev Konar 2011-01-03, 22:31
Sergei Babovich 2011-01-03, 22:36