<div dir="ltr"><div>The idea is to be able to automate it at least so long as spare nodes are available.  So if one had a cluster of 3 masters (quorum is thus 2 nodes), and 2 additional nodes operating as slaves, then if one of the masters fails the cluster would continue to be able to operate with 2 masters until the failed master is replaced.  But the cluster would also be able to promote one of the slaves (already mostly synchronized) to become a master, returning the system to the full 3 masters and making the timing of the replacement less critical.<br><br></div><div>This alone does not really replace RAIDs.  For a very large storage subsystem, each node would be made up of many disks so another layer is needed to manage those disks.  The documentation has a 'copies' mechanism that is meant to address this, where redundancy is built within each node to handle disk failures and to manage a pool of hot replacements.  If a disk fails and is taken out, the idea is for there to be sufficient copies to be able to rebuild the node without having to access other nodes.  But if for some reason there is not a sufficient number of copies then it could in fact get the data from other nodes as well.<br><br></div><div>For smaller storage systems the cluster component is probably sufficient.  But for larger storage systems both the cluster component and the copies component would be needed.<br><br></div><div>One important consideration here is how spare disks or spare nodes are handled.  I think it is relatively important for spare disks and spare nodes to be 'hot' ... that is, fully live in the system and useable to improve read fan-out performance.  So the basic idea for all spares (both at the cluster level and the copies level) is for the spares drives to be fully integrated into the filesystem as extra slaves.<br></div><div><br></div><div>Right now I am working on the clustering component.  Getting both pieces operational is going to take a long time. I'm not making any promises on the timing.  The clustering component is actually the easier piece to do.<br></div><div><br></div>-Matt<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 3:12 AM, PeerCorps Trust Fund <span dir="ltr"><<a href="mailto:ipc@peercorpstrust.org" target="_blank">ipc@peercorpstrust.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
If I understand the HAMMER2 design documents, one of the benefits that it brings is the ability to rebuild a failed disk using multiple networked mirrors? It seems that it also uses this capability to provide data healing in the event of corruption.<br>
<br>
If this is the case, are these processes transparent to the user based on some pre-defined failover configuration, or must they be manually set off in the event of a disk failure/corruption?<br>
<br>
Also, would RAID controllers still be necessary in the independent nodes if there is sufficient and reliable remote replication? Or could a HAMMER2 filesystem span the disks in a particular node and have the redundancy of the remote replication provide features that otherwise would come from a RAID controller?<br>
<br>
Thanks for any clarifying statements on the above!<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Mike<br>
</font></span></blockquote></div><br></div>