26 ms·
> gitlab [...] also [...] has no HA roadmap in sight unless you > want to break apart its rube-goldberg structure and attempt to > HA the individual com
by avar 9y ago
> gitlab [...] also [...] has no HA roadmap in sight unless you
> want to break apart its rube-goldberg structure and attempt to
> HA the individual components of it.
We run a very large in-house GitLab installation and the HA is easy
because:
1) GitLab stores data on the FS, and you can outsource this problem
to e.g. a NetApp filer.
2) The data it doesn't store on NFS it stores in psql or MySQL, which
has established HA solutions.
Once you have that set up you can load-balance the GitLab nodes and
provision / destroy them at will.
- sytse 9y agoThanks, you can indeed do HA this way. When Gitaly 1.0 lands you won't have to mount the NFS volumes on the application servers anymore as everything will go over gRPC.
- avar 9y agoThat just splits up the task of application server & git executor into two, it doesn't get rid of the dependency on a monolithic storage backend. I understand that this is something gitlab.com is working towards and excited about, presumably because it'll allow for provisioning web workers unrelated to the CPU you're spending on running git, but for us I don't see it being useful. I hope GitLab eventually gets something like GitHub Spokes[1] which'll allow for provisioning the entire setup on a bunch of dumb boxes with RAID 0. 1. https://githubengineering.com/introducing-dgit/ https://githubengineering.com/introducing-dgit/
- sytse 9y agoThe advantage is that if one storage nose is offline the rest of the site can still function. Spokes is more elaborate can can deal with node failure. We plan to rely on cloud storage so we can quickly attach a new VM with Gitaly.
- qaq 9y agoIt's hard to imagine that TCO for NetApp + Gitlab is less than Github or some other hosted solution.