Configuring clustering
The cluster topology for GitHub Enterprise Server provides horizontal scaling for environments with tens of thousands of developers.
Who can use this feature?
GitHub determines eligibility for clustering, and must enable the configuration for your instance's license. Clustering requires careful planning and additional administrative overhead. For more information, see About clustering.
About clustering
The cluster topology for GitHub Enterprise Server is designed to support tens of thousands of users where other topologies would experience resource exhaustion. In a cluster, the instance's services scale horizontally across multiple nodes.
Differences between clustering and high availability (HA)
Learn about the differences between deployment topologies for the virtual machines (VMs) that comprise a GitHub Enterprise Server instance.
About cluster nodes
In a GitHub Enterprise Server cluster, nodes are individual virtual machines (VMs) running the GitHub Enterprise Server software that comprise the instance. Each node runs a set of services.
Cluster network configuration
A GitHub Enterprise Server cluster requires proper DNS name resolution, load balancing, and communication between nodes.
Initializing the cluster
A GitHub Enterprise Server cluster must be set up with a license and initialized using the administrative shell (SSH).
Deferring database seeding
You can speed up the process of adding a new MySQL replica node to your cluster by opting to defer database seeding.
Upgrading a cluster
To upgrade a GitHub Enterprise Server cluster to the latest release, use the administrative shell (SSH).
Monitoring the health of your cluster
To ensure the performance and redundancy of a GitHub Enterprise Server cluster, you can monitor the cluster's health.
Monitoring the health of your cluster nodes with Node Eligibility Service
You can monitor when nodes in a GitHub Enterprise Server cluster have been offline long enough to cause issues by using Node Eligibility Service.
Rebalancing cluster workloads
You can force your GitHub Enterprise Server cluster to evenly distribute job allocations for workloads on the cluster's nodes.
Evacuating a cluster node running data services
If a node in your GitHub Enterprise Server cluster runs services that store distributed data, you can ensure redundancy as you prepare to replace the node by evacuating the node's data.
Replacing a cluster node
If a node fails in a GitHub Enterprise Server cluster, or if you want to add a new node with more resources, mark any nodes to replace as offline, then add the new node.
Configuring high availability replication for a cluster
You can configure a replica of your entire GitHub Enterprise Server cluster in a separate datacenter, allowing your cluster to fail over to redundant nodes.
Initiating a failover to your replica cluster
If your GitHub Enterprise Server cluster fails, you can fail over to the replica.