On Tue, Apr 12, 2016 at 2:05 PM, Luiz Claudio Prazeres Goncalves <
luiz...@gmail.com> wrote:

> Hi Sandro, I've been using gluster with 3 external hosts for a while and
> things are working pretty well, however this single point of failure looks
> like a simple feature to implement,but critical to anyone who wants to use
> gluster on production  . This is not hyperconvergency which has other
> issues/implications. So , why not have this feature out on 3.6 branch? It
> looks like just let vdsm use the 'backupvol-server' option when mounting
> the engine domain and make the property tests.
>
> Could you add this feature to the next release of 3.6 branch?
>

Having it in 3.6 is hard in terms of integration team capacity. Also
consider than 4.0 will be probably out before we'll be able to backport it
to 3.6.



>
> Thanks
> Luiz
>
> Em ter, 12 de abr de 2016 05:03, Sandro Bonazzola <sbona...@redhat.com>
> escreveu:
>
>> On Mon, Apr 11, 2016 at 11:44 PM, Bond, Darryl <db...@nrggos.com.au>
>> wrote:
>>
>>> My setup is hyperconverged. I have placed my test results in
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1298693
>>>
>>>
>> Ok, so you're aware about the limitation of the single point of failure.
>> If you drop the host referenced in hosted engine configuration for the
>> initial setup it won't be able to connect to shared storage even if the
>> other hosts in the cluster are up since the entry point is down.
>> Note that hyperconverged deployment is not supported in 3.6.
>>
>>
>>
>>>
>>> Short description of setup:
>>>
>>> 3 hosts with 2 disks each set up with gluster replica 3 across the 6
>>> disks volume name hosted-engine.
>>>
>>> Hostname hosted-storage configured in /etc//hosts to point to the host1.
>>>
>>> Installed hosted engine on host1 with the hosted engine storage path =
>>> hosted-storage:/hosted-engine
>>>
>>> Install first engine on h1 successful. Hosts h2 and h3 added to the
>>> hosted engine. All works fine.
>>>
>>> Additional storage and non-hosted engine hosts added etc.
>>>
>>> Additional VMs added to hosted-engine storage (oVirt Reports VM and
>>> Cinder VM). Additional VM's are hosted by other storage - cinder and NFS.
>>>
>>> The system is in production.
>>>
>>>
>>> Engine can be migrated around with the web interface.
>>>
>>>
>>> - 3.6.4 upgrade released, follow the upgrade guide, engine is upgraded
>>> first , new Centos kernel requires host reboot.
>>>
>>> - Engine placed on h2 -  h3 into maintenance (local) upgrade and Reboot
>>> h3 - No issues - Local maintenance removed from h3.
>>>
>>> - Engine placed on h3 -  h2 into maintenance (local) upgrade and Reboot
>>> h2 - No issues - Local maintenance removed from h2.
>>>
>>> - Engine placed on h3 -h1 into mainteance (local) upgrade and reboot h1
>>> - engine crashes and does not start elsewhere, VM(cinder)  on h3 on same
>>> gluster volume pauses.
>>>
>>> - Host 1 takes about 5 minutes to reboot (Enterprise box with all it's
>>> normal BIOS probing)
>>>
>>> - Engine starts after h1 comes back and stabilises
>>>
>>> - VM(cinder) unpauses itself,  VM(reports) continued fine the whole
>>> time. I can do no diagnosis on the 2 VMs as the engine is not available.
>>>
>>> - Local maintenance removed from h​1
>>>
>>>
>>> I don't believe the issue is with gluster itself as the volume remains
>>> accessible on all hosts during this time albeit with a missing server
>>> (gluster volume status) as each gluster server is rebooted.
>>>
>>> Gluster was upgraded as part of the process, no issues were seen here.
>>>
>>>
>>> I have been able to duplicate the issue without the upgrade by following
>>> the same sort of timeline.
>>>
>>>
>>> ________________________________
>>> From: Sandro Bonazzola <sbona...@redhat.com>
>>> Sent: Monday, 11 April 2016 7:11 PM
>>> To: Richard Neuboeck; Simone Tiraboschi; Roy Golan; Martin Sivak; Sahina
>>> Bose
>>> Cc: Bond, Darryl; users
>>> Subject: Re: [ovirt-users] Hosted engine on gluster problem
>>>
>>>
>>>
>>> On Mon, Apr 11, 2016 at 9:37 AM, Richard Neuboeck <h...@tbi.univie.ac.at
>>> <mailto:h...@tbi.univie.ac.at>> wrote:
>>> Hi Darryl,
>>>
>>> I'm still experimenting with my oVirt installation so I tried to
>>> recreate the problems you've described.
>>>
>>> My setup has three HA hosts for virtualization and three machines
>>> for the gluster replica 3 setup.
>>>
>>> I manually migrated the Engine from the initial install host (one)
>>> to host three. Then shut down host one manually and interrupted the
>>> fencing mechanisms so the host stayed down. This didn't bother the
>>> Engine VM at all.
>>>
>>> Did you move the host one to maintenance before shutting down?
>>> Or is this a crash recovery test?
>>>
>>>
>>>
>>> To make things a bit more challenging I then shut down host three
>>> while running the Engine VM. Of course the Engine was down for some
>>> time until host two detected the problem. It started the Engine VM
>>> and everything seems to be running quite well without the initial
>>> install host.
>>>
>>> Thanks for the feedback!
>>>
>>>
>>>
>>> My only problem is that the HA agent on host two and three refuse to
>>> start after a reboot due to the fact that the configuration of the
>>> hosted engine is missing. I wrote another mail to users@ovirt.org
>>> <mailto:users@ovirt.org>
>>> about that.
>>>
>>> This is weird. Martin,  Simone can you please investigate on this?
>>>
>>>
>>>
>>>
>>> Cheers
>>> Richard
>>>
>>> On 04/08/2016 01:38 AM, Bond, Darryl wrote:
>>> > There seems to be a pretty severe bug with using hosted engine on
>>> gluster.
>>> >
>>> > If the host that was used as the initial hosted-engine --deploy host
>>> goes away, the engine VM wil crash and cannot be restarted until the host
>>> comes back.
>>>
>>> is this an Hyperconverged setup?
>>>
>>>
>>> >
>>> > This is regardless of which host the engine was currently running.
>>> >
>>> >
>>> > The issue seems to be buried in the bowels of VDSM and is not an issue
>>> with gluster itself.
>>>
>>> Sahina, can you please investigate on this?
>>>
>>>
>>> >
>>> > The gluster filesystem is still accessable from the host that was
>>> running the engine. The issue has been submitted to bugzilla but the fix is
>>> some way off (4.1).
>>> >
>>> >
>>> > Can my hosted engine be converted to use NFS (using the gluster NFS
>>> server on the same filesystem) without rebuilding my hosted engine (ie
>>> change domainType=glusterfs to domainType=nfs)?
>>>
>>> >
>>> > What effect would that have on the hosted-engine storage domain inside
>>> oVirt, ie would the same filesystem be mounted twice or would it just break.
>>> >
>>> >
>>> > Will this actually fix the problem, does it have the same issue when
>>> the hosted engine is on NFS?
>>> >
>>> >
>>> > Darryl
>>> >
>>> >
>>> >
>>> >
>>> > ________________________________
>>> >
>>> > The contents of this electronic message and any attachments are
>>> intended only for the addressee and may contain legally privileged,
>>> personal, sensitive or confidential information. If you are not the
>>> intended addressee, and have received this email, any transmission,
>>> distribution, downloading, printing or photocopying of the contents of this
>>> message or attachments is strictly prohibited. Any legal privilege or
>>> confidentiality attached to this message and attachments is not waived,
>>> lost or destroyed by reason of delivery to any person other than intended
>>> addressee. If you have received this message and are not the intended
>>> addressee you should notify the sender by return email and destroy all
>>> copies of the message and any attachments. Unless expressly attributed, the
>>> views expressed in this email do not necessarily represent the views of the
>>> company.
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users@ovirt.org<mailto:Users@ovirt.org>
>>> > http://lists.ovirt.org/mailman/listinfo/users
>>> >
>>>
>>>
>>> --
>>> /dev/null
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@ovirt.org<mailto:Users@ovirt.org>
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com<http://redhat.com>
>>>
>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to