Failover / Replication Scenario
WHChase
2 Posts
June 22, 2017, 9:14 pmQuote from WHChase on June 22, 2017, 9:14 pmI'm still in the learning phase of PetaSAN / Ceph and had a failover question for you guys.
Let's say that I have a cluster with 4 Nodes and a replication setting of 4. Nodes 1, 2 and 3 are in our server room locally and Node 4 in an off-site location connected via a WAN link. In the event of a server room fire where Nodes 1, 2 and 3 are destroyed, will Node 4 have all of the data to recreate the node after I purchase new servers and install a fresh copy of PetaSAN on Nodes 1, 2 and 3 (replacements servers)?
Now what if I want a business continuity where the off-site would be a fully functioning cluster that I could continue running the cluster? Would the WAN link possibly be too slow? Is there such a thing as a PetaSAN -> PetaSAN cluster replication?
I'm still in the learning phase of PetaSAN / Ceph and had a failover question for you guys.
Let's say that I have a cluster with 4 Nodes and a replication setting of 4. Nodes 1, 2 and 3 are in our server room locally and Node 4 in an off-site location connected via a WAN link. In the event of a server room fire where Nodes 1, 2 and 3 are destroyed, will Node 4 have all of the data to recreate the node after I purchase new servers and install a fresh copy of PetaSAN on Nodes 1, 2 and 3 (replacements servers)?
Now what if I want a business continuity where the off-site would be a fully functioning cluster that I could continue running the cluster? Would the WAN link possibly be too slow? Is there such a thing as a PetaSAN -> PetaSAN cluster replication?
admin
2,930 Posts
June 23, 2017, 4:01 amQuote from admin on June 23, 2017, 4:01 amAlthough what you describe should work in theory, it is not the way to do it. First as you stated the WAN connection to the remote site is an issue + creating as many replicas as nodes is not the answer.
The best way to do this is use Ceph's rbd mirroring feature, this mirrors disks asynchronously between remote Ceph/PetaSAN clusters typically used for off site disaster recovery:
http://docs.ceph.com/docs/master/rbd/rbd-mirroring/
It is definetly in our roadmap to support this. We also have plans to develop mirroring daemons that allow async mirroring to cloud storage such as Amazon and Azure.
Another related feature we will be supporting, not for off site disaster recovery but related, is the ability to define racks and rooms within a single large cluster. In Ceph terms this is refered to as CRUSH map editing. This will allow Ceph to distribute the data replicas more intelligently within a single cluster, so for example not to place all replicas on nodes that belong to the same rack.
Although what you describe should work in theory, it is not the way to do it. First as you stated the WAN connection to the remote site is an issue + creating as many replicas as nodes is not the answer.
The best way to do this is use Ceph's rbd mirroring feature, this mirrors disks asynchronously between remote Ceph/PetaSAN clusters typically used for off site disaster recovery:
http://docs.ceph.com/docs/master/rbd/rbd-mirroring/
It is definetly in our roadmap to support this. We also have plans to develop mirroring daemons that allow async mirroring to cloud storage such as Amazon and Azure.
Another related feature we will be supporting, not for off site disaster recovery but related, is the ability to define racks and rooms within a single large cluster. In Ceph terms this is refered to as CRUSH map editing. This will allow Ceph to distribute the data replicas more intelligently within a single cluster, so for example not to place all replicas on nodes that belong to the same rack.
Failover / Replication Scenario
WHChase
2 Posts
Quote from WHChase on June 22, 2017, 9:14 pmI'm still in the learning phase of PetaSAN / Ceph and had a failover question for you guys.
Let's say that I have a cluster with 4 Nodes and a replication setting of 4. Nodes 1, 2 and 3 are in our server room locally and Node 4 in an off-site location connected via a WAN link. In the event of a server room fire where Nodes 1, 2 and 3 are destroyed, will Node 4 have all of the data to recreate the node after I purchase new servers and install a fresh copy of PetaSAN on Nodes 1, 2 and 3 (replacements servers)?
Now what if I want a business continuity where the off-site would be a fully functioning cluster that I could continue running the cluster? Would the WAN link possibly be too slow? Is there such a thing as a PetaSAN -> PetaSAN cluster replication?
I'm still in the learning phase of PetaSAN / Ceph and had a failover question for you guys.
Let's say that I have a cluster with 4 Nodes and a replication setting of 4. Nodes 1, 2 and 3 are in our server room locally and Node 4 in an off-site location connected via a WAN link. In the event of a server room fire where Nodes 1, 2 and 3 are destroyed, will Node 4 have all of the data to recreate the node after I purchase new servers and install a fresh copy of PetaSAN on Nodes 1, 2 and 3 (replacements servers)?
Now what if I want a business continuity where the off-site would be a fully functioning cluster that I could continue running the cluster? Would the WAN link possibly be too slow? Is there such a thing as a PetaSAN -> PetaSAN cluster replication?
admin
2,930 Posts
Quote from admin on June 23, 2017, 4:01 amAlthough what you describe should work in theory, it is not the way to do it. First as you stated the WAN connection to the remote site is an issue + creating as many replicas as nodes is not the answer.
The best way to do this is use Ceph's rbd mirroring feature, this mirrors disks asynchronously between remote Ceph/PetaSAN clusters typically used for off site disaster recovery:
http://docs.ceph.com/docs/master/rbd/rbd-mirroring/
It is definetly in our roadmap to support this. We also have plans to develop mirroring daemons that allow async mirroring to cloud storage such as Amazon and Azure.
Another related feature we will be supporting, not for off site disaster recovery but related, is the ability to define racks and rooms within a single large cluster. In Ceph terms this is refered to as CRUSH map editing. This will allow Ceph to distribute the data replicas more intelligently within a single cluster, so for example not to place all replicas on nodes that belong to the same rack.
Although what you describe should work in theory, it is not the way to do it. First as you stated the WAN connection to the remote site is an issue + creating as many replicas as nodes is not the answer.
The best way to do this is use Ceph's rbd mirroring feature, this mirrors disks asynchronously between remote Ceph/PetaSAN clusters typically used for off site disaster recovery:
http://docs.ceph.com/docs/master/rbd/rbd-mirroring/
It is definetly in our roadmap to support this. We also have plans to develop mirroring daemons that allow async mirroring to cloud storage such as Amazon and Azure.
Another related feature we will be supporting, not for off site disaster recovery but related, is the ability to define racks and rooms within a single large cluster. In Ceph terms this is refered to as CRUSH map editing. This will allow Ceph to distribute the data replicas more intelligently within a single cluster, so for example not to place all replicas on nodes that belong to the same rack.