Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.
� 

� 

This version of GitHub Enterprise was discontinued on 2023-01-18. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

Configuring clustering

Learn about clustering and differences with high availability.

  • About clustering

    GitHub Enterprise Server clustering allows services that make up GitHub Enterprise Server to be scaled out across multiple nodes.

  • Differences between clustering and high availability (HA)

    GitHub Enterprise Server High Availability Configuration (HA) is a primary/secondary failover configuration that provides redundancy while Clustering provides redundancy and scalability by distributing read and write load across multiple nodes.

  • About cluster nodes

    Nodes are GitHub Enterprise Server instances that operate in a cluster. Each node runs a set of services that are provided to the cluster, and ultimately to the users.

  • Cluster network configuration

    GitHub Enterprise Server clustering relies on proper DNS name resolution, load balancing, and communication between nodes to operate properly.

  • Initializing the cluster

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

  • Upgrading a cluster

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

  • Monitoring cluster nodes

    A GitHub Enterprise Server cluster is comprised of redundant services that are distributed across two or more nodes. If an individual service or an entire node were to fail, it should not be immediately apparent to users of the cluster. However since performance and redundancy are affected, it is important to monitor the health of a GitHub Enterprise Server cluster.

  • Replacing a cluster node

    To replace a GitHub Enterprise Server node, you must mark the affected nodes offline in the cluster configuration file (cluster.conf) and add the replacement nodes. This might be necessary if a node were to fail, or to add a node with more resources to increase performance.

  • Evacuating a cluster node

    You can evacuate data services on a cluster node.

  • Configuring high availability replication for a cluster

    You can configure a passive replica of your entire GitHub Enterprise Server cluster in a different location, 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 passive replica .