[Gluster-users] gluster processes won't start when a single node is booted
Mauro M.
gluster at ezplanet.net
Mon Sep 21 07:41:23 UTC 2015
Atin,
I can assure you that with 3.5 too I had the second server turned off most
of the time and when I rebooted the primary server without having the
secondary turned on, gluster always started and I was able to mount the
filesystem automatically.
If what you describe is the behaviour by design I propose that an option
is introduced to provide a use case like I described which is likely to be
the most popular in home office environments.
Mauro
On Mon, September 21, 2015 04:53, Atin Mukherjee wrote:
> I again echo the same, if one of the given two server is down, once
> GlusterD comes up it *will not* start the bricks.
>
> IMO, in your 3.5.x setup you never had both the servers down. So in that
> case your brick process(es) can start. But if you bring down both the
> GlusterD and then start one of them, it won't start the bricks, no
> matter whether its 3.5/3.6/3.7. The whole idea of this design is to
> ensure on a 2 node setup if one of the node is down and when the other
> comes up, we never know whether the configuration is stale or not. So we
> trust on other peer's configuration and then make the volume accessible.
>
> An explicit volume start here spawns the brick process(es) because of
> which you are able to mount.
>
> Thanks,
> Atin
>
> On 09/20/2015 07:58 PM, Mauro M. wrote:
>> Hi Atin,
>>
>> Thank you for your kind reply.
>>
>> For a "brick" down I mean the server running the gluster brick service
>> completely turned off.
>>
>> I can circumvent the issue by stopping and starting again the volume as
>> in
>> my previous message. However it does not sound right as it either:
>> - should not be necessary if it is supposed to work as in v3.5
>> - should not work either if your hypothesis is correct
>>
>> Mauro
>>
>> On Sun, September 20, 2015 14:54, Atin Mukherjee wrote:
>>> When you say a brick is down do you mean the glusterd instance on that
>>> node
>>> is also down? If that's the case I stand by with my point. If you meant
>>> only glusterfsd process was not running then could you check whether
>>> you
>>> have enabled quorum by chance?
>>>
>>> -Atin
>>> Sent from one plus one
>>> On Sep 20, 2015 7:20 PM, "Mauro M." <gluster at ezplanet.net> wrote:
>>>
>>>> It does not sound right.
>>>>
>>>> Further to my previous tests, if I stop and start the volume whilst
>>>> brick2
>>>> is down then the glusterfs processes do start and I am able to mount
>>>> the
>>>> volume.
>>>>
>>>> From the status when processes on brick1 are N/A on TCP port I
>>>> execute:
>>>>
>>>> # gluster volume stop gv_home
>>>> # gluster volume start gv_home
>>>>
>>>> at this point the status shows processes listening on TCP port and
>>>> thus
>>>> I
>>>> am able to mount the volume.
>>>>
>>>> I inserted these steps in /etc/rc.local where know I test if /home is
>>>> mounted and if not I stop and start the volume, then mount.
>>>>
>>>> It works to my satisfaction, however why do I have to go through this
>>>> workaround when 3.5 worked flawlessly?
>>>>
>>>> Mauro
>>>>
>>>> On Sun, September 20, 2015 12:50, Atin Mukherjee wrote:
>>>>> This behaviour is expected and in a 2 node cluster setup brick
>>>> processes
>>>> are started only when the other nodes come up. The same would be true
>>>> in
>>>> 3.5.x series as well. Adding a dummy node into the cluster would help
>>>> you
>>>>> to solve your problem.
>>>>> -Atin
>>>>> Sent from one plus one
>>>>> On Sep 20, 2015 4:56 PM, "Mauro M." <gluster at ezplanet.net> wrote:
>>>>>> Hi all,
>>>>>> I hope you might help.
>>>>>> I just upgraded from 3.5.6 to 3.7.4
>>>>>> My configuration is 1 volume with 2 x bricks replicated.
>>>>>> Normally I have brick1 running and brick2 turned off so that when I
>>>> want
>>>>>> to do maintenance on brick1 I turn on brick2, wait for
>>>> synchronization
>>>> to
>>>>>> complete and turn off brick1.
>>>>>> Often I just reboot brick1 with brick2 still turned off.
>>>>>> With glusterfs version 3.5 I could do all of the above.
>>>>>> After the upgrade to 3.7.4 if I boot brick1 (or brick2) without the
>>>> other
>>>>>> node, glusterd starts, but the gluster network processes won't
>>>>>> start.
>>>> Here is the output of gluster volume info:
>>>>>> Volume Name: gv_home
>>>>>> Type: Replicate
>>>>>> Volume ID: ef806153-2a02-4db9-a54e-c2f89f79b52e
>>>>>> Status: Started
>>>>>> Number of Bricks: 1 x 2 = 2
>>>>>> Transport-type: tcp
>>>>>> Bricks:
>>>>>> Brick1: brick1:/brick0/gv_home
>>>>>> Brick2: brick2:/brick0/gv_home
>>>>>> Options Reconfigured:
>>>>>> nfs.disable: on
>>>>>> config.transport: tcp
>>>>>> ... and gluster volume status:
>>>>>> Status of volume: gv_home
>>>>>> Gluster process TCP Port RDMA Port Online
>>>> Pid
>>>>>>
>>>> ---------------------------------------------------------------------------
>>>> Brick brick1:/brick0/gv_home N/A N/A N
>>>> N/A
>>>>>> NFS Server on localhost N/A N/A N
>>>> N/A
>>>>>> Task Status of Volume gv_home
>>>>>>
>>>> ---------------------------------------------------------------------------
>>>> There are no active volume tasks
>>>>>> Under this condition gv_home cannot be mounted.
>>>>>> Only if I start brick2, once glusterd starts on brick2 the gluster
>>>> processes also start on brick1 and gv_home can be mounted:
>>>>>> Status of volume: gv_home
>>>>>> Gluster process TCP Port RDMA Port Online
>>>> Pid
>>>>>>
>>>> --------------------------------------------------------------------------
>>>> Brick brick1:/brick0/gv_home 49158 0 Y
>>>> 30049
>>>>>> Brick brick2:/brick0/gv_home 49158 0 Y
>>>> 14797
>>>>>> Self-heal Daemon on localhost N/A N/A Y
>>>> 30044
>>>>>> Self-heal Daemon on brick2 N/A N/A Y
>>>> 14792
>>>>>> Task Status of Volume gv_home
>>>>>>
>>>> --------------------------------------------------------------------------
>>>> There are no active volume tasks
>>>>>> Once I turn off brick2 then the volume remains available and mounted
>>>> without issues (for as long that the relative gluster processes remain
>>>> active, if I kill them I am back without volume).
>>>>>> The issue is that I would like to safely boot one the bricks without
>>>> having to boot both to get the volume back and mountable which is what
>>>> I
>>>>>> was able to do with glusterfs version 3.5.
>>>>>> Please could you help?
>>>>>> Is there any parameter to set that would enable the same behaviour
>>>>>> as
>>>> in
>>>>>> 3.5?
>>>>>> Thank you in advance,
>>>>>> Mauro
>>>>>> _______________________________________________
>>>>>> Gluster-users mailing list
>>>>>> Gluster-users at gluster.org
>>>>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
More information about the Gluster-users
mailing list