[Gluster-users] gluster in cloud environment

[Raghavendra Talur]

On Fri, Jul 24, 2015 at 2:42 PM, Timo Schaepe <info at timoschaepe.de> wrote:

> Hi,
>
> > On 23 Jul 2015, at 18:25, Atin Mukherjee <atin.mukherjee83 at gmail.com>
> wrote:
> >
> >
> > -Atin
> > Sent from one plus one
> > On Jul 23, 2015 3:41 PM, "Timo Schaepe" <info at timoschaepe.de> wrote:
> > >
> > > Hey guys,
> > >
> > > we are trying to use gluster 3.6.4 in a cloud environment. Creating
> the gluster itself is not a problem. Mounting the created vol from a
> machine in the cloud infrastructure is not a problem. But when I am trying
> to mount the created gluster vol from an external machine it fails. In the
> log files of the client I can see that gluster is annoucing the bricks with
> the cloud infrastructure internal ips, which are not accessible from
> outside of the cloud. When I change the internal ips to the public domain
> names in /var/lib/glusterd/gv0.tcp-fuse.vol on every cluster host it works
> seamless. I definitely think that this is not the recommended way to solve
> this problem. Of course it breaks, if I add another bricks to the gluster.
> > >
> > > Is there a possibility to change the annouced ip adresses?
> > > Or is there another way to solve this problem?
> > Probably in that case its better to peer probe using public domain name
> instead of internal IP?
>
> I tried this first with negative result:
>
> azureuser at stage1-gluster2:~$ sudo gluster peer probe
> stage1-gluster1.cloudapp.net
> peer probe: failed: Error through RPC layer, retry again later
>
> And in the log of the opposite:
>
> [2015-07-24 08:51:03.223634] E [rpcsvc.c:617:rpcsvc_handle_rpc_call]
> 0-rpc-service: Request received from non-privileged port. Failing request
> [2015-07-24 08:51:23.984945] E [socket.c:2276:socket_connect_finish]
> 0-management: connection to 95.211.117.206:24007 failed (Connection timed
> out)
> [2015-07-24 08:51:23.985078] I [MSGID: 106004]
> [glusterd-handler.c:4398:__glusterd_peer_rpc_notify] 0-management: Peer
> 00000000-0000-0000-0000-000000000000, in Establishing Connection state, has
> disconnected from glusterd.
> [2015-07-24 08:51:23.985153] I [socket.c:3374:socket_submit_reply]
> 0-socket.management: not connected (priv->connected = -1)
> [2015-07-24 08:51:23.985167] E [rpcsvc.c:1247:rpcsvc_submit_generic]
> 0-rpc-service: failed to submit message (XID: 0x1, Program: GlusterD svc
> cli, ProgVers: 2, Proc: 1) to rpc-transport (socket.management)
>
> I didn’t set “server.allow-insecure”, because I think it is not a good
> idea. It is ok to use this in public and productive environment? I am also
> using ssl, do the “allow-insecure” setting has an impact on this security?
>
>
In the above logs,  ": connection to 95.211.117.206:24007 failed
(Connection timed out)" is the important part.
How is the packet routed if you use public IPs/hostnames for peer probe?
Could it be that 24007 port is blocked by your cloud provider?

You don't need to use server.allow-insecure for this particular case but
may require it is clients are not able to communicate with bricks.
server.allow-insecure removes the restriction that clients should always
connect using a port < 1023. This is a rudimentary mechanism to ensure
that the user on client is a privileged user and hence can be trusted if
the client-ip is already a trusted one.

If you have ssl enabled then it is a better way to ensure trust factor of
client than the above mechanism, hence server.allow-insecure should not
harm.


Thanks,
>
>         Timo
>
>
> > >
> > > Thanks,
> > >
> > >         Timo
> > > _______________________________________________
> > > Gluster-users mailing list
> > > Gluster-users at gluster.org
> > > http://www.gluster.org/mailman/listinfo/gluster-users
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>



-- 
*Raghavendra Talur *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150725/2b5f93c5/attachment.html>