On 8/5/2010 3:52 PM, Emmanuel Noobadmin wrote:
The DB will offer a more optimized alternative. A VM image won't.
I'm not quite sure what's the connection here. The database runs within the VM and is stored in the virtual disk. I'm not using VM to substitute for a database replication but to segregrate functionality. In a way, it would also allow me to pursue different redundancy arrangements if the original configuration is not ideal for one of the functions.
Just overall price/performance. If you can separate the parts that need transactional sync-to-replicated-disk from the things that don't, you can throw more resources at the difficult parts of the problem.
So how long do you wait if it is the replica that breaks? And how do you recover/sync later?
I'm not sure what "wait" are you referring to. Is that the wait before the chosen option decides to flag the node as down or the wait before replacing the replica machine or the wait until the system is fully redundant again with a sync'd replica?
Both - since these are new and likely scenarios you are introducing.
As for the actual recovery/sync, if a drive fails in the storage node, it would be straightforward case of replacing the drive and rebuilding the node's raid array wouldn't it?
Yes, but that's slow and will affect the speed that normal writes can happen.
If the storage node fails, such as a mainboard problem, I'll replace/repair the node and put it back online, leaving gluster to self heal/resync. Gluster keeps versioning data so it would only sync changed files so that should be pretty fast.
That part sounds encouraging at least.