Re: Gluster deamon fails to start

"Langley, Robert" <Robert.Langley@xxxxxxxxxxx> · Mon, 12 Jun 2017 16:45:38 +0000

That did it. After detaching gsaov07 as a peer; I also had to clean out the glusterd peers folder and vols folder (/var/lib/glusterd/peers and /var/lib/glusterd/vols; for anyone else's benefit). Then, the glusterd service started successfully. I then ran
 gluster peer probe gsaov07.stor.local from gsaov08, which succeeded.
I did find that one error I made was from previously troubleshooting, where my bond for the stor.local network was set to mode 0, rather than mode 4. After that was corrected, the server activated and is now in "Up" status in oVirt.
Thank you again for your responses.

From: Atin Mukherjee <amukherj@xxxxxxxxxx>

Sent: Monday, June 12, 2017 8:25 AM

To: Langley, Robert

Cc: Sahina Bose; SATHEESARAN; Kasturi Narra; gluster-users@xxxxxxxxxxx

Subject: Re:  Gluster deamon fails to start

On Mon, Jun 12, 2017 at 7:30 PM, Langley, Robert 
<Robert.Langley@xxxxxxxxxxx> wrote:

As far as the peer status (and I now remember seeing this earlier) the issue appears to be that the host name for gsaov07 is attempting to resolve over the wrong network for gluster "ent...." and not "stor.local".

So, it may be as simple as removing gsaov07 as a peer, then probing over the correct network.

If gsaov07 doesn't have any volumes (bricks to be precise), that's quite safe and can be done.

I'll follow up with the Engine log.

Sent using OWA for iPhone

From: Sahina Bose <sabose@xxxxxxxxxx>

Sent: Monday, June 12, 2017 6:49:29 AM

To: Atin Mukherjee

Cc: Langley, Robert; SATHEESARAN; Kasturi Narra; 
gluster-users@xxxxxxxxxxx

Subject: Re:  Gluster deamon fails to start

On Mon, Jun 12, 2017 at 6:41 PM, Atin Mukherjee 
<amukherj@xxxxxxxxxx> wrote:

On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley@xxxxxxxxxxx> wrote:

Thank you for your response. There has been no change of IP addresses. And I have tried restarting the glusterd service multiple times.

I am using fully qualified names with a DNS server that has forward and reverse setup.

Something I had noticed is that, with oVirt, communication is being attempted over the VM network, rather than storage network. Which is not how the bricks are defined. Not sure how to correct that.

+Sas, Kasturi, Sahina - is this what expected in ovirt?

You can use different n/w interface for gluster management interface by peer probing the same node with multiple addresses. But you'd still need to ensure that glusterd can communicate to the IP with which brick addresses are defined.

Peer probing the multiple addresses is done via oVirt providing the logical network (with gluster role) is attached to the interface in oVirt engine.

Could you provide the "gluster peer status" output from 
GSAov08?

Also the engine.log from /var/log/ovirt-engine/engine.log of the Hosted Engine VM?

Sent using OWA for iPhone

From: Atin Mukherjee <amukherj@xxxxxxxxxx>

Sent: Monday, June 12, 2017 4:57:08 AM

To: Langley, Robert

Cc: gluster-users@xxxxxxxxxxx

Subject: Re:  Gluster deamon fails to start

glusterd failed to resolve addresses of the bricks. This could happen either because of glusterd was trying to resolve the address of the brick before the N/W interface was up or a change in the IP? If it's the latter then a point to note is that it's
 recommended that cluster should be formed using hostname otherwise if the server goes through IP change we have to change the configuration from the backend. If its the former, then this is a race condition and restarting glusterd should bring back the service
 up.

On Fri, Jun 9, 2017 at 10:01 PM, Langley, Robert <Robert.Langley@xxxxxxxxxxx> wrote:

This is in relation to bringing up a new oVirt environment.
When I was bringing up oVirt (Hosted-Engine), I had the Glusterd service stopped, since the server (I have its name as GSAoV07) was initially only going to be used to host the oVirt engine as a hypervisor (it will have Gluster volumes in the near future).
 I have three other servers I am using for storage. One of those three is also going to be a hypervisor and the other two are dedicated storage servers (Their names are GSA-Stor1 & GSA-Stor2).
When I first deployed the engine, this server (GSAoV07) I’m having an issue with was in green status.
I then added in the other server (I have it as GSAoV08), who is acting as both a Gluster server and a hypervisor. It had the red, downward arrow, for a while after I added it late at night. But, in the morning when I got into work, things switched. The
 GSAoV07 server ended up in a Non Operational state and the GSAov08 server is now green (Up). The hosted engine is still running on GSAov07 and it seems that the Non Operational status is due to the Gluster daemon failing.

Let me know if you need logs other than the glusterd.log attached.

Thank you,
Robert Langley 

_______________________________________________

Gluster-users mailing list

Gluster-users@xxxxxxxxxxx

http://lists.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users