12:35 p.m.
In oVirt 3.1 GlusterFS support was added. It was an easy way to replicate your virtual
machine storage without too much hassle.
There are two main howtos:
*
http://www.middleswarth.net/content/installing-ovirt-31-and-glusterfs-usi...
(Robert Middleswarth)
* http://blog.jebpages.com/archives/ovirt-3-1-glusterized/ (Jason Brooks).
1) What about performance?
I've done some tests with rsync backups (even using the suggested --inplace rsync
switch) that implies small files. These backups were done into local mounted glusterfs
volumes. Backups instead of lasting about 2 hours they lasted like 15 hours long.
Is there maybe something that only happens with small files and with big files performance
is ok?
2) How to know the current status?
In DRBD you know it checking a proc file if I remember it well. I remember too that
GlusterFS doesn't have an equivalent thing and there's no evident way to know if
all the files are synced.
If you have tried it how do you know if both sets of virtual disks images are synced?
3) Mount dns resolution
If you check Jason Brooks howto you will see that it uses a hostname for refering to nfs
mount. If you want to perform HA you need your storage to be mounted and if the server1
host is down it doesn't help that the nfs mount point associated to the storage is
server1:/vms/ and not server2:/vms/. Checking Middleswarth howto I think that he does the
same thing.
Let's explain a bit more so that understand. My example setup is the one where you
have two host machines where you run a set of virtual machines on one and the other one
doesn't have any virtual machine running. Where is the virtual machines storage
located? It's located at the glusterfs volume.
So the first one of the machines mounts the glusterfs volume as nfs (It's an
example).
If it uses its own hostname for the nfs mount then if itself goes down the second host
isn't going to mount it when it's restarted in the HA mode.
So the first one of the machines mounts the glusterfs volume as nfs (It's an
example).
If it uses the second host hostname for the nfs mount then if the second host goes down
the virtual machine cannot access its virtual disks.
A workaround for this situation which I have thought is to use /etc/hosts on both machines
so that:
whatever.domain.com
resolves in both hosts to the host self's ip.
I think that glusterfs has a way of mounting their share through "-t glusterfs"
that somehow can ignore these hostnames problems but I haven't read it too much about
it so I'm not too sure.
4) So my doubts basically are:
* Has anyone setup a two host glusterfs HA oVirt cluster where storage is shared by a
replicated Glusterfs volume that is shared and stored by both of them?
* Does HA work when one of the host goes down?
* Or does it complain about hostname as I suspect?
* Any tips to ensure the best performance?
Thank you.
--
--
Adrián Gibanel
I.T. Manager
+34 675 683 301
www.btactic.com
Ens podeu seguir a/Nos podeis seguir en:
i
Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de
tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es
cosa de todos.
AVIS:
El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el
destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense
tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem
que ho feu saber immediatament al remitent i que procediu a destruir el missatge .
AVISO:
El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario,
les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la
autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos
que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .
8:45 a.m.
Hey Adrian,
I'm jumping in now because you haven't had any nibbles yet, not because I know for
sure I'm right. I only have something to say about the 3rd part of your email:
3) Mount dns resolution
If you check Jason Brooks howto you will see that it uses a hostname
for refering to nfs mount. If you want to perform HA you need your
storage to be mounted and if the server1 host is down it doesn't
help that the nfs mount point associated to the storage is
server1:/vms/ and not server2:/vms/. Checking Middleswarth howto I
think that he does the same thing.
Let's explain a bit more so that understand. My example setup is the
one where you have two host machines where you run a set of virtual
machines on one and the other one doesn't have any virtual machine
running. Where is the virtual machines storage located? It's located
at the glusterfs volume.
So the first one of the machines mounts the glusterfs volume as nfs
(It's an example).
If it uses its own hostname for the nfs mount then if itself goes
down the second host isn't going to mount it when it's restarted in
the HA mode.
So the first one of the machines mounts the glusterfs volume as nfs
(It's an example).
If it uses the second host hostname for the nfs mount then if the
second host goes down the virtual machine cannot access its virtual
disks.
From what I can tell, you are asking about using storage local to
hypervisors, combined into a gluster volume, and used as a POSIX data center.
I don't think anyone would disagree about that being a bad idea. In the RHEV
documentation, we try and make it clear that one of the weaknesses of using storage that
is local to they hypervisors is that when something happens, you lose two pieces of
infrastructure in one shot, rather than one. I think that for the availability you are
talking about, you'll want at least three nodes.
I've cc'd John Walker, the Gluster Community Guy (whom I met recently at LCA,
g'day John!), he can probably say something specific.
Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thildred(a)redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred
----- Original Message -----
> From: "Adrian Gibanel" <adrian.gibanel(a)btactic.com>
> To: "users" <users(a)ovirt.org>
> Sent: Friday, January 25, 2013 9:35:42 PM
> Subject: [Users] Glusterfs HA doubts
>
> In oVirt 3.1 GlusterFS support was added. It was an easy way to
> replicate your virtual machine storage without too much hassle.
> There are two main howtos:
> *
>
http://www.middleswarth.net/content/installing-ovirt-31-and-glusterfs-usi...
> (Robert Middleswarth)
> * http://blog.jebpages.com/archives/ovirt-3-1-glusterized/ (Jason
> Brooks).
>
> 1) What about performance?
> I've done some tests with rsync backups (even using the suggested
> --inplace rsync switch) that implies small files. These backups were
> done into local mounted glusterfs volumes. Backups instead of
> lasting about 2 hours they lasted like 15 hours long.
>
> Is there maybe something that only happens with small files and with
> big files performance is ok?
>
> 2) How to know the current status?
> In DRBD you know it checking a proc file if I remember it well. I
> remember too that GlusterFS doesn't have an equivalent thing and
> there's no evident way to know if all the files are synced.
>
> If you have tried it how do you know if both sets of virtual disks
> images are synced?
>
3) Mount dns resolution
If you check Jason Brooks howto you will see that it uses a hostname
for refering to nfs mount. If you want to perform HA you need your
storage to be mounted and if the server1 host is down it doesn't
help that the nfs mount point associated to the storage is
server1:/vms/ and not server2:/vms/. Checking Middleswarth howto I
think that he does the same thing.
Let's explain a bit more so that understand. My example setup is the
one where you have two host machines where you run a set of virtual
machines on one and the other one doesn't have any virtual machine
running. Where is the virtual machines storage located? It's located
at the glusterfs volume.
So the first one of the machines mounts the glusterfs volume as nfs
(It's an example).
If it uses its own hostname for the nfs mount then if itself goes
down the second host isn't going to mount it when it's restarted in
the HA mode.
So the first one of the machines mounts the glusterfs volume as nfs
(It's an example).
If it uses the second host hostname for the nfs mount then if the
second host goes down the virtual machine cannot access its virtual
disks.
>
> A workaround for this situation which I have thought is to use
> /etc/hosts on both machines so that:
> whatever.domain.com
> resolves in both hosts to the host self's ip.
>
> I think that glusterfs has a way of mounting their share through "-t
> glusterfs" that somehow can ignore these hostnames problems but I
> haven't read it too much about it so I'm not too sure.
>
> 4) So my doubts basically are:
>
> * Has anyone setup a two host glusterfs HA oVirt cluster where
> storage is shared by a replicated Glusterfs volume that is shared
> and stored by both of them?
> * Does HA work when one of the host goes down?
> * Or does it complain about hostname as I suspect?
> * Any tips to ensure the best performance?
>
> Thank you.
>
> --
>
> --
> Adrián Gibanel
> I.T. Manager
>
> +34 675 683 301
> www.btactic.com
>
>
>
> Ens podeu seguir a/Nos podeis seguir en:
>
> i
>
>
> Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi
> ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en
> el medio ambiente. El medio ambiente es cosa de todos.
>
> AVIS:
> El contingut d'aquest missatge i els seus annexos és confidencial. Si
> no en sou el destinatari, us fem saber que està prohibit
> utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització
> corresponent. Si heu rebut aquest missatge per error, us agrairem
> que ho feu saber immediatament al remitent i que procediu a destruir
> el missatge .
>
> AVISO:
> El contenido de este mensaje y de sus anexos es confidencial. Si no
> es el destinatario, les hacemos saber que está prohibido utilizarlo,
> divulgarlo y/o copiarlo sin tener la autorización correspondiente.
> Si han recibido este mensaje por error, les agradeceríamos que lo
> hagan saber inmediatamente al remitente y que procedan a destruir el
> mensaje .
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
4119
days inactive
4129
days old
1 comments
2 participants
participants (2)
-
Adrian Gibanel -
Tim Hildred