Configuring 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.

Learn about the differences between deployment topologies for the virtual machines (VMs) that comprise a GitHub Enterprise Server instance.

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.

A GitHub Enterprise Server cluster requires proper DNS name resolution, load balancing, and communication between nodes.

A GitHub Enterprise Server cluster must be set up with a license and initialized using the administrative shell (SSH).

You can speed up the process of adding a new MySQL replica node to your cluster by opting to defer database seeding.

To upgrade a GitHub Enterprise Server cluster to the latest release, use the administrative shell (SSH).

To ensure the performance and redundancy of a GitHub Enterprise Server cluster, you can monitor the cluster's health.

You can monitor when nodes in a GitHub Enterprise Server cluster have been offline long enough to cause issues by using Node Eligibility Service.

You can force your GitHub Enterprise Server cluster to evenly distribute job allocations for workloads on the cluster's nodes.

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.

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.

If your GitHub Enterprise Server cluster fails, you can fail over to the replica.