Re: [Gluster-users] Stupid question re multiple networks

2014-11-16 Thread Kaushal M 
The 'Better peer identification' part is completed. GlusterD can now
correctly identify the mentioned peer, regardless of the type of name
used (IP, FQDN, short name). It also laid down a framework on which we
can build a nice multi-interface support in the future, as we can now
associate multiple names with a peer.

~kaushal

On Sat, Nov 15, 2014 at 1:42 AM, Justin Clift  wrote:
> On Thu, 13 Nov 2014 14:15:24 -0500 (EST)
> Jeff Darcy  wrote:
>
>> > AFAIK multiple network scenario only works if you are not using
>> > Gluster via FUSE mounts or gfapi from remote hosts. It will work
>> > for NFS access or when you set up something like Samba with CTDB.
>> > Just not with native Gluster as the server always tells the clients
>> > which addresses to connect to: ie your storage hosts will always
>> > supply the connection details of the hosts that are configured in
>> > gluster to your storage clients.
>> >
>> > I wonder if this could be gaffer-taped with some bridging/vlan/arp
>> > spoofing trickery but I'm not sure I'd trust such a hack.
>> >
>> > It would be *really* nice if there was a way to set up gluster so
>> > you could specify different IPs for backend and frontend operations.
>>
>> As you suggest, there are various kinds of "trickery" that can be used
>> to fake multi-network support even for native mounts.  I've seen it
>> done via split-horizon DNS, explicit host routes, and iptables.
>> *Proper* support for multiple networks is part of the proposed 4.0
>> feature set.
>>
>> http://www.gluster.org/community/documentation/index.php/Planning40
>>
>> In fact, I would greatly appreciate your help defining what "proper"
>> means in this context.
>
> As an extra data point, this is a gluster-devel thread from a while ago
> about one potential approach:
>
>   https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00069.html
>
> It turned out the code (at the time) in GlusterFS for identifying
> peers wasn't great, and needed to be updated first before really
> addressing the problem at all. ;)
>
>   https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00067.html
>
> Those two threads should be read together, as the concept in the first
> one evolved during discussion with Kaushal M (CC'd) and via the mailing
> list and IRC over a few days.
>
> This pre-requisite required code became the "Better Peer Identification"
> feature for 3.6.x series:
>
>   
> http://www.gluster.org/community/documentation/index.php/Features/Better_peer_identification
>
> I haven't kept an eye on that though, so unsure if it's completed yet
> or not (just now emailed Kaushal to find out).
>
> + Justin
>
> --
> GlusterFS - http://www.gluster.org
>
> An open source, distributed file system scaling to several
> petabytes, and handling thousands of clients.
>
> My personal twitter: twitter.com/realjustinclift
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-14 Thread Justin Clift 
On Thu, 13 Nov 2014 14:15:24 -0500 (EST)
Jeff Darcy  wrote:

> > AFAIK multiple network scenario only works if you are not using
> > Gluster via FUSE mounts or gfapi from remote hosts. It will work
> > for NFS access or when you set up something like Samba with CTDB.
> > Just not with native Gluster as the server always tells the clients
> > which addresses to connect to: ie your storage hosts will always
> > supply the connection details of the hosts that are configured in
> > gluster to your storage clients.
> >
> > I wonder if this could be gaffer-taped with some bridging/vlan/arp
> > spoofing trickery but I'm not sure I'd trust such a hack.
> >
> > It would be *really* nice if there was a way to set up gluster so
> > you could specify different IPs for backend and frontend operations.
> 
> As you suggest, there are various kinds of "trickery" that can be used
> to fake multi-network support even for native mounts.  I've seen it
> done via split-horizon DNS, explicit host routes, and iptables.
> *Proper* support for multiple networks is part of the proposed 4.0
> feature set.
> 
> http://www.gluster.org/community/documentation/index.php/Planning40
> 
> In fact, I would greatly appreciate your help defining what "proper"
> means in this context.

As an extra data point, this is a gluster-devel thread from a while ago
about one potential approach:

  https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00069.html

It turned out the code (at the time) in GlusterFS for identifying
peers wasn't great, and needed to be updated first before really
addressing the problem at all. ;)

  https://lists.gnu.org/archive/html/gluster-devel/2013-06/msg00067.html

Those two threads should be read together, as the concept in the first
one evolved during discussion with Kaushal M (CC'd) and via the mailing
list and IRC over a few days.

This pre-requisite required code became the "Better Peer Identification"
feature for 3.6.x series:

  
http://www.gluster.org/community/documentation/index.php/Features/Better_peer_identification

I haven't kept an eye on that though, so unsure if it's completed yet
or not (just now emailed Kaushal to find out).

+ Justin

-- 
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-14 Thread Anders Blomdell 
On 2014-11-14 16:03, Jeff Darcy wrote:
>> What if the gluster servers are also clients? I locally plan to use
>> a number of servers acting as gluster and VM servers, so that gluster serves
>> both the VM's and other clients.
> 
> I think that fits fairly well into this paradigm.  Note that the routing of
> traffic is by *type* (e.g. user I/O, rebalance) rather than by destination.
> By default, everything's on the same network, so things would work just as
> now.  If you want, you can redirect user I/O over one network and internal
> traffic over another, even if the machines are both clients and servers.
Exactly, and I want the user I/O for the VM's to go over the same network
as the internal traffic (higher capacity), this can of course be solved with
separate gluster volumes (which might be necessary since I might need different
translators and access rights for different clients). Might well be that this 
is better handled with specific routing entries on the servers (not very many, 
so 
its manageable).

/Anders


-- 
Anders Blomdell  Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University  Phone:+46 46 222 4625
P.O. Box 118 Fax:  +46 46 138118
SE-221 00 Lund, Sweden

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-14 Thread Jeff Darcy 
> What if the gluster servers are also clients? I locally plan to use
> a number of servers acting as gluster and VM servers, so that gluster serves
> both the VM's and other clients.

I think that fits fairly well into this paradigm.  Note that the routing of
traffic is by *type* (e.g. user I/O, rebalance) rather than by destination.
By default, everything's on the same network, so things would work just as
now.  If you want, you can redirect user I/O over one network and internal
traffic over another, even if the machines are both clients and servers.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-14 Thread John Hearns 
>  Heartbeats, quorums, etc.
> should also be aware of multi-homed hosts.  

Definitely for that feature.

I have spent the last six years managing an SGI Clustered XFS setup.
The heartbeat for CXFS tends to run on a completely private network - a set of 
dumb switches, and interfaces which carry no other traffic. You can define a 
second  network to fail over to should the primary heartbeat network go down, 
which in my case was the normal user access LAN.





***Viglen***
Viglen Ltd, Registered in England No 1208441. Registered Office: 7, Handley 
Page Way, Colney Street, St. Albans, Hertfordshire AL2 2DQ.

Information in this electronic mail message is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this message by 
anyone else is unauthorised. If you are not the intended recipient any use, 
disclosure, copying or distribution of this message is prohibited and may be 
unlawful. When addressed to our customers, any information contained in this 
message is subject to Viglen Terms & Conditions. Please rely on your own virus 
checker and procedures with regard to any attachment to this message.
***Viglen***

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-14 Thread Anders Blomdell 
On 2014-11-13 20:15, Jeff Darcy wrote:
>> AFAIK multiple network scenario only works if you are not using Gluster via
>> FUSE mounts or gfapi from remote hosts. It will work for NFS access or when
>> you set up something like Samba with CTDB. Just not with native Gluster as
>> the server always tells the clients which addresses to connect to: ie your
>> storage hosts will always supply the connection details of the hosts that
>> are configured in gluster to your storage clients.
>>
>> I wonder if this could be gaffer-taped with some bridging/vlan/arp spoofing
>> trickery but I'm not sure I'd trust such a hack.
>>
>> It would be *really* nice if there was a way to set up gluster so you could
>> specify different IPs for backend and frontend operations.
> 
> As you suggest, there are various kinds of "trickery" that can be used
> to fake multi-network support even for native mounts.  I've seen it done
> via split-horizon DNS, explicit host routes, and iptables.  *Proper*
> support for multiple networks is part of the proposed 4.0 feature set.
> 
> http://www.gluster.org/community/documentation/index.php/Planning40
> 
> In fact, I would greatly appreciate your help defining what "proper"
> means in this context.  Clearly, we need to add the concept of a network
> to our (informal) object model, and sort out the host/address/network
> relationships.  Then we need a way to direct certain traffic flows to
> certain networks.  The question is: how do we present this to the user?
> Let's take a whack at how to define networks etc. using the CLI's
> current object-verb syntax (even though it's a bit clunky).
> 
>gluster> network add user-net 1.2.3.0/24
>gluster> network add back-end 5.6.0.0/16
>gluster> peer probe 1.2.3.4
>gluster> peer probe 5.6.7.8
> 
> So far, so good.  Note that on the second probe we should be able to
> recognize that this is just a new address (on another network) for the
> host we already added with the first probe.  Heartbeats, quorums, etc.
> should also be aware of multi-homed hosts.  Maybe there's a better
> syntax, but this will do for now.  Let's add a volume.
> 
>gluster> volume create silly-vol 1.2.3.4:/brick
> 
> So, which network address should the daemon for 1.2.3.4:/brick expose
> for clients?  Which address should it use for internal traffic such as
> rebalance or self-heal?  This is where it gets tricky.  Let's start by
> saying that *by default* all traffic is on the interface specified on
> the "volume create" line.  If we want to do something different...
> 
># ONLY redirect rebalance traffic.
>gluster> volume route silly-vol rebalance back-end
> 
> Now rebalance traffic goes through 5.6.7.8 instead.  Is that intuitive?
> What about these?
> 
># Export a volume on multiple networks.
>gluster> volume route silly-vol client user-net some-other-net
> 
># Redirect rebalance, self-heal, anything else we think of.
>gluster> volume route silly-vol all-mgmt back-end
> 
># Redirect GLOBALLY instead of per volume.
>gluster> cluster route rebalance back-end
> 
> Does this seem like it's heading in the right direction?  It doesn't
> look too bad to me, but my perspective is hardly typical.  Is there
> something *users* would like to be able to do with multiple networks
> that can't be expressed this way, or is there some better way to define
> how these multiple networks should be used?  Please let us know.
What if the gluster servers are also clients? I locally plan to use
a number of servers acting as gluster and VM servers, so that gluster serves
both the VM's and other clients.

/Anders


-- 
Anders Blomdell  Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University  Phone:+46 46 222 4625
P.O. Box 118 Fax:  +46 46 138118
SE-221 00 Lund, Sweden

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-13 Thread Lindsay Mathieson 
On Thu, 13 Nov 2014 06:06:28 PM Alex Crow wrote:
> AFAIK multiple network scenario only works if you are not using Gluster via
> FUSE mounts or gfapi from remote hosts. It will work for NFS access or when
> you set up something like Samba with CTDB. Just not with native Gluster as
> the server always tells the clients which addresses to connect to: ie your
> storage hosts will always supply the connection details of the hosts that
> are configured in gluster to your storage clients.
> 
> I wonder if this could be gaffer-taped with some bridging/vlan/arp spoofing
> trickery but I'm not sure I'd trust such a hack.
> 
> It would be *really* nice if there was a way to set up gluster so you could
> specify different IPs for backend and frontend operations.


Yes, but I don't think that was what the OP was asking. I believe what he 
wanted to know was how to ensure the gluster servers talked to each other over 
his 10G interfaces.

In that regard I thought he was correct - just setup the servers via the IP 
for the interfaces. I have a multiple interface setup:

eth0:192.168.5.0/24 : 1G
bond0:   10.10.10.0/24 : 1x1G (Bonded)

To route everything through bond0:

from 10.10.10.240
  gluster peer probe 10.10.10.241
  gluster peer probe 10.10.10.242


gluster volume create datastore1 replica 2 transport tcp \
 10.10.10.240:/mnt/gluster-brick1/datastore \
 10.10.10.241:/mnt/gluster-brick1/datastore \
 10.10.10.242:/mnt/gluster-brick1/datastore 

Net monitoring shows all gluster traffic going through bond0 as desired.

I realise this is old hat for most on the list, but I just wanted to confirm 
it for the op.
-- 
Lindsay

signature.asc
Description: This is a digitally signed message part.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-13 Thread Mario Benincasa 
Hi all
may I just add a question to the topic?
In a scenario with (say) two or three servers, one distributed volume,
native (fuse) clients, and stable filesystems with more read than write
operations, what is the typical amount of traffic between the servers,
compared to the client-server traffic?
In case of replicated volume instead of distributed?
What is the server-server traffic made up of, in case of native clients? If
it is just hearbeat-like traffic?
In other words, could be there a performance gain in separating
client-server traffic on one network and server-server traffic on a
different network? Or not?

Thanks a lot in advance for any answer!

Mario



On Thu, Nov 13, 2014 at 8:15 PM, Jeff Darcy  wrote:

> > AFAIK multiple network scenario only works if you are not using Gluster
> via
> > FUSE mounts or gfapi from remote hosts. It will work for NFS access or
> when
> > you set up something like Samba with CTDB. Just not with native Gluster
> as
> > the server always tells the clients which addresses to connect to: ie
> your
> > storage hosts will always supply the connection details of the hosts that
> > are configured in gluster to your storage clients.
> >
> > I wonder if this could be gaffer-taped with some bridging/vlan/arp
> spoofing
> > trickery but I'm not sure I'd trust such a hack.
> >
> > It would be *really* nice if there was a way to set up gluster so you
> could
> > specify different IPs for backend and frontend operations.
>
> As you suggest, there are various kinds of "trickery" that can be used
> to fake multi-network support even for native mounts.  I've seen it done
> via split-horizon DNS, explicit host routes, and iptables.  *Proper*
> support for multiple networks is part of the proposed 4.0 feature set.
>
> http://www.gluster.org/community/documentation/index.php/Planning40
>
> In fact, I would greatly appreciate your help defining what "proper"
> means in this context.  Clearly, we need to add the concept of a network
> to our (informal) object model, and sort out the host/address/network
> relationships.  Then we need a way to direct certain traffic flows to
> certain networks.  The question is: how do we present this to the user?
> Let's take a whack at how to define networks etc. using the CLI's
> current object-verb syntax (even though it's a bit clunky).
>
>gluster> network add user-net 1.2.3.0/24
>gluster> network add back-end 5.6.0.0/16
>gluster> peer probe 1.2.3.4
>gluster> peer probe 5.6.7.8
>
> So far, so good.  Note that on the second probe we should be able to
> recognize that this is just a new address (on another network) for the
> host we already added with the first probe.  Heartbeats, quorums, etc.
> should also be aware of multi-homed hosts.  Maybe there's a better
> syntax, but this will do for now.  Let's add a volume.
>
>gluster> volume create silly-vol 1.2.3.4:/brick
>
> So, which network address should the daemon for 1.2.3.4:/brick expose
> for clients?  Which address should it use for internal traffic such as
> rebalance or self-heal?  This is where it gets tricky.  Let's start by
> saying that *by default* all traffic is on the interface specified on
> the "volume create" line.  If we want to do something different...
>
># ONLY redirect rebalance traffic.
>gluster> volume route silly-vol rebalance back-end
>
> Now rebalance traffic goes through 5.6.7.8 instead.  Is that intuitive?
> What about these?
>
># Export a volume on multiple networks.
>gluster> volume route silly-vol client user-net some-other-net
>
># Redirect rebalance, self-heal, anything else we think of.
>gluster> volume route silly-vol all-mgmt back-end
>
># Redirect GLOBALLY instead of per volume.
>gluster> cluster route rebalance back-end
>
> Does this seem like it's heading in the right direction?  It doesn't
> look too bad to me, but my perspective is hardly typical.  Is there
> something *users* would like to be able to do with multiple networks
> that can't be expressed this way, or is there some better way to define
> how these multiple networks should be used?  Please let us know.
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>



-- 
Mario Benincasa
Via del Conservatorio 55
00186 Roma - Italy
tel.   +39 066872917
mob.   +39 3346210331
fax:   +39 0697656510
email: mbeni...@gmail.com
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-13 Thread Jeff Darcy 
> AFAIK multiple network scenario only works if you are not using Gluster via
> FUSE mounts or gfapi from remote hosts. It will work for NFS access or when
> you set up something like Samba with CTDB. Just not with native Gluster as
> the server always tells the clients which addresses to connect to: ie your
> storage hosts will always supply the connection details of the hosts that
> are configured in gluster to your storage clients.
>
> I wonder if this could be gaffer-taped with some bridging/vlan/arp spoofing
> trickery but I'm not sure I'd trust such a hack.
>
> It would be *really* nice if there was a way to set up gluster so you could
> specify different IPs for backend and frontend operations.

As you suggest, there are various kinds of "trickery" that can be used
to fake multi-network support even for native mounts.  I've seen it done
via split-horizon DNS, explicit host routes, and iptables.  *Proper*
support for multiple networks is part of the proposed 4.0 feature set.

http://www.gluster.org/community/documentation/index.php/Planning40

In fact, I would greatly appreciate your help defining what "proper"
means in this context.  Clearly, we need to add the concept of a network
to our (informal) object model, and sort out the host/address/network
relationships.  Then we need a way to direct certain traffic flows to
certain networks.  The question is: how do we present this to the user?
Let's take a whack at how to define networks etc. using the CLI's
current object-verb syntax (even though it's a bit clunky).

   gluster> network add user-net 1.2.3.0/24
   gluster> network add back-end 5.6.0.0/16
   gluster> peer probe 1.2.3.4
   gluster> peer probe 5.6.7.8

So far, so good.  Note that on the second probe we should be able to
recognize that this is just a new address (on another network) for the
host we already added with the first probe.  Heartbeats, quorums, etc.
should also be aware of multi-homed hosts.  Maybe there's a better
syntax, but this will do for now.  Let's add a volume.

   gluster> volume create silly-vol 1.2.3.4:/brick

So, which network address should the daemon for 1.2.3.4:/brick expose
for clients?  Which address should it use for internal traffic such as
rebalance or self-heal?  This is where it gets tricky.  Let's start by
saying that *by default* all traffic is on the interface specified on
the "volume create" line.  If we want to do something different...

   # ONLY redirect rebalance traffic.
   gluster> volume route silly-vol rebalance back-end

Now rebalance traffic goes through 5.6.7.8 instead.  Is that intuitive?
What about these?

   # Export a volume on multiple networks.
   gluster> volume route silly-vol client user-net some-other-net

   # Redirect rebalance, self-heal, anything else we think of.
   gluster> volume route silly-vol all-mgmt back-end

   # Redirect GLOBALLY instead of per volume.
   gluster> cluster route rebalance back-end

Does this seem like it's heading in the right direction?  It doesn't
look too bad to me, but my perspective is hardly typical.  Is there
something *users* would like to be able to do with multiple networks
that can't be expressed this way, or is there some better way to define
how these multiple networks should be used?  Please let us know.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Stupid question re multiple networks

2014-11-13 Thread Alex Crow 
AFAIK multiple network scenario only works if you are not using Gluster 
via FUSE mounts or gfapi from remote hosts. It will work for NFS access 
or when you set up something like Samba with CTDB. Just not with native 
Gluster as the server always tells the clients which addresses to 
connect to: ie your storage hosts will always supply the connection 
details of the hosts that are configured in gluster to your storage clients.


I wonder if this could be gaffer-taped with some bridging/vlan/arp 
spoofing trickery but I'm not sure I'd trust such a hack.


It would be *really* nice if there was a way to set up gluster so you 
could specify different IPs for backend and frontend operations.


Alex


On 13/11/14 17:47, John Hearns wrote:


Forgive me for a stupid question, I hav looked at the Wiki page on 
multiple networks.


If I have a set of Gluster storage servers which have both a gigabit 
network connection and a 10Gig network connection


(or an Infiniband network connection) how do I make sure the Gluster 
traffic goes over the 10Gig interfaces?


Do I simply have to form a cluster with the hostnames associated with 
the 10Gig interfaces,


Or is there perhaps a more sophisticated way to do this?

Dr John Hearns

Principal  HPC Engineer

Viglen, 7 Handley Page Way, Old Parkbury Lane,
Colney Street, St. Albans, Hertfordshire, AL2 2DQ

***Viglen***
Viglen Ltd, Registered in England No 1208441. Registered Office: 7, 
Handley Page Way, Colney Street, St. Albans, Hertfordshire AL2 2DQ.
Information in this electronic mail message is confidential and may be 
legally privileged. It is intended solely for the addressee. Access to 
this message by anyone else is unauthorised. If you are not the 
intended recipient any use, disclosure, copying or distribution of 
this message is prohibited and may be unlawful. When addressed to our 
customers, any information contained in this message is subject to 
Viglen Terms & Conditions. Please rely on your own virus checker and 
procedures with regard to any attachment to this message.

***Viglen***

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean.


___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] Stupid question re multiple networks

2014-11-13 Thread John Hearns 
Forgive me for a stupid question, I hav looked at the Wiki page on multiple 
networks.

If I have a set of Gluster storage servers which have both a gigabit network 
connection and a 10Gig network connection
(or an Infiniband network connection) how do I make sure the Gluster traffic 
goes over the 10Gig interfaces?

Do I simply have to form a cluster with the hostnames associated with the 10Gig 
interfaces,
Or is there perhaps a more sophisticated way to do this?


Dr John Hearns
Principal  HPC Engineer
Viglen, 7 Handley Page Way, Old Parkbury Lane,
Colney Street, St. Albans, Hertfordshire, AL2 2DQ

***Viglen***
Viglen Ltd, Registered in England No 1208441. Registered Office: 7, Handley 
Page Way, Colney Street, St. Albans, Hertfordshire AL2 2DQ.

Information in this electronic mail message is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this message by 
anyone else is unauthorised. If you are not the intended recipient any use, 
disclosure, copying or distribution of this message is prohibited and may be 
unlawful. When addressed to our customers, any information contained in this 
message is subject to Viglen Terms & Conditions. Please rely on your own virus 
checker and procedures with regard to any attachment to this message.
***Viglen***

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
_
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users