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.
--
Les Mikesell
lesmikesell at gmail.com