Re: who uses Lustre in production with virtual machines?

[Les Mikesell <lesmikesell@xxxxxxxxx>]

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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos