Hi! I did HA for GitLab but... I used the VirtualMachine1 (VM1) and VM2 with GitLba instances, file server (FS) with MySQL DB and redis server plus repository. FS mounted to VM1 and VM2 by nfsd. Users balanced between VM1 and VM2 by haproxy (ssh) and nginx (http). It works fine, but I don't use this in the production. Because if two or more people try to push to repository, we will have a .lock file on FS and nobody can push to this repository. I don't know how resolve this problem...
среда, 7 мая 2014 г., 3:05:48 UTC+6 пользователь praven john написал: > > I know this is a pretty old topic - but did anyone ever try doing HA for > gitlab? > > I'm thinking of setting up a primary-secondary setup, using 2 gitlab > instances running on 2 seperate servers, and sharing a NFS and ofcourse the > DB between them. My real question is what all should i put on the NFS, and > what should be local to the server? I think we would only need > $HOME/repositories on the NFS? > > Regards > Praven > > On Monday, 15 October 2012 12:32:52 UTC-4, Jason Armitage wrote: >> >> "+1" - I'm looking at HA as well. I was thinking of clustering the >> back-end MySQL DB. >> But, has anyone run multiple gitlab servers on the same database? >> >> On Sunday, 14 October 2012 19:13:10 UTC+1, Kiran Patil wrote: >>> >>> For that we need to use "Pacemaker" from http://www.clusterlabs.org/. >>> >>> It has the following features, >>> >>> - Detection and recovery of machine and application-level failures >>> - Unified and scriptable shell for cluster administration >>> - Supports both quorate >>> <http://en.wikipedia.org/wiki/Quorum_%28Distributed_Systems%29> and >>> resource-driven >>> >>> <http://devresources.linux-foundation.org/dev/clusters/docs/ResourceDrivenClusters.pdf> >>> >>> clusters >>> - Configurable strategies >>> >>> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-cluster-options.html#id36137161> >>> >>> for dealing with quorum >>> <http://en.wikipedia.org/wiki/Quorum_%28Distributed_Systems%29> loss >>> (when multiple machines fail) >>> - Supports application startup/shutdown ordering >>> >>> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-ordering.html>, >>> >>> regardless machine(s) the applications are on >>> - Supports applications that must/must-not run on the same machine >>> >>> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-colocation.html> >>> - Supports applications which need to be active on multiple machines >>> >>> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-clone.html> >>> - Supports applications with multiple modes (eg. master/slave >>> >>> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-resource-multistate.html> >>> ) >>> - Provably correct response to any failure or cluster state. >>> The cluster's response to any stimuli can be tested offline *before* >>> the condition exists >>> >>> Installation steps link for ubuntu, >>> http://www.clusterlabs.org/wiki/Install#Ubuntu >>> >>> Thanks, >>> Kiran Patil. >>> >>> On Thursday, 11 October 2012 22:24:53 UTC+5:30, Steve Pereira wrote: >>>> >>>> Does anyone have any experience with configuring Gitlab to be highly >>>> available? I'd like to have 2 Gitlab servers behind something like HAproxy >>>> in order to have a seamless failover in place. >>>> >>>> If this is something more people are interested in I'd be happy to >>>> share my findings here if I have to set it up from scratch. >>>> >>> -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to gitlabhq+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/b1eb56f3-d429-4e85-b742-07b6ac7dc821%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
