[SAC] OSGeo Ganeti Cluster

[Lance Albertson]

On Thu, Dec 28, 2017 at 11:47 AM, Alex Mandel <tech_dev at wildintellect.com>
wrote:

> I would have never suggested libvrt if I didn't know the compatibility.
> Both are managers on top of KVM, with the disks of the vms being lvm
> volumes. Moving a vm is a matter of copying the lvm volume and declaring
> a config to use it as it's disk.
>

​This is true​ and wouldn't be that difficult to do.


> The feature we'd be losing is DRBD, which is a multi server hotcopy
> failover system, which we don't really use because of performance issues
> with load on some our machines. Ganeti also isn't really designed for
> less than 3 servers, and kind of expects those servers to all be roughly
> the same.
>

​While I agree it works better with at least 3 servers, clusters running
only two is OK still.​ I don't recall what issues you had in the past with
DRBD but it hasn't been that much of problem lately on our clusters.


> You are correct if we moved off ganeti we'd remove OSUOSL from anything
> but the hardware management. This came up as SAC has never really had
> good access to the hosts osgeo3 and osgeo4, and OSUOSL doesn't always
> have time to troubleshoot some of our unusual issues.


​That's OK with us, we can do whatever makes the most sense for you and
your project.​ At the time, Ganeti was the best option, but now there are a
few other options available. We have been using OpenStack internally for
several years and are almost ready to open up a larger cluster for FOSS
projects. It's a bit more complicated to maintain, but it offers a lot more
flexibility in how you manage and access the VMs using a standard public
API.

What are your project's needs?


> On 12/28/2017 10:15 AM, Regina Obe wrote:
> > Lance,
> >
> > I'm afraid we are further behind on new server than I thought.   Seems
> more questions came out of the meeting than answers.
> >
> > Any thoughts you have to add would be greatly appreciated.
> >
> > One of the surprising outcomes for me was I thought sticking with Ganeti
> was done deal.  Seems it is not and libvrt is under consideration
> >
> > You have any thoughts between Ganeti and Libvrt, what we would be losing
> if we switch to Libvrt.  Are the image formats even compatible?  I suspect
> they are not but haven't done the research.  I'm more concerned with OSUSL
> being able to support us if we decide to go with libvrt and rebuilding our
> currently in use VMs on libvrt.
> >
> > Minutes from last meeting here: https://wiki.osgeo.org/wiki/
> SAC_Meeting_2017-12-21#Minutes
> >
> > (transcript starts around 20:15 – 22:01ish  http://irclogs.geoapt.com/
> osgeo-sac/%23osgeo-sac.2017-12-21.log )
> >
> > To summarize OSU specific outcomes
> >
> > 1)      We still need to pick out specs on new server.  Alex is going to
> propose some options on the mailing list as I recall from here -
> https://www.siliconmechanics.com/ to fit in a $5000 ish budget.
> >
> > 2)      We are debating with sticking with Ganeti or moving to something
> easier for us to manage like libvrt.  I'm concerned with having just one
> libvrt and it doesn't solve the problem we have of just having 1 Ganeti
> cluster we can trust so would just assume stick with Ganeti, but I'm less
> knowledgeable on the subject of the difference between the 2.  So I guess
> this means a hold-off for you on your plans unless you have any options we
> missed. :(
> >
> > 3)      On the existing Ganeti clusters we have to inventory what is
> easy to move off and what we actually are still using cause on quick
> finding, I think a lot of things on those servers are not in use.  I think
> Martin was in middle of migrating stuff off because all those VMs are old
> Debian 5 or 6 and have to be rebuilt anyway, but I'm not confident we'll
> have enough bandwidth in next month or two to move everything off.
> >
> >
> >
> > Thanks,
> >
> > Regina
>


-- 
Lance Albertson
Director
Oregon State University | Open Source Lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20180105/9ab36230/attachment-0001.html>