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.

Конфигурация сети кластера

Для правильной работы кластеризации GitHub Enterprise Server используется правильное разрешение DNS-имен, балансировку нагрузки и обмен данными между узлами.

Рекомендации по сети

Реализация самого простого проекта сети для кластеризации заключается в размещении узлов в одной локальной сети. Если кластер должен охватывать подсети, не рекомендуется настраивать правила брандмауэра между сетями. Задержка между узлами должна быть меньше 1 миллисекунд.

Для обеспечения высокой доступности задержка между сетью с активными узлами и сетью с пассивными узлами должна составлять менее 70 миллисекунд. Не рекомендуется настраивать брандмауэр между двумя сетями.

Порты приложений для конечных пользователей

Порты приложений предоставляют конечным пользователям доступ к веб-приложениям и Git.

ПортОписаниеС шифрованием
22/TCPGit по протоколу SSHДа
25/TCPSMTPТребуется STARTTLS
80/TCPHTTPНет
(Если протокол SSL включен, этот порт перенаправляет на HTTPS)
443/TCPHTTPSДа
9418/TCPПростой порт протокола Git
(Отключено в частном режиме)
Нет

Административные порты

Административные порты не требуются для использования основного приложения конечными пользователями.

ПортОписаниеС шифрованием
ICMPПроверка связи ICMPНет
122/TCPАдминистративный SSHДа
161/UDPSNMPНет
8080/TCPHTTP консоли управленияНет
(Если протокол SSL включен, этот порт перенаправляет на HTTPS)
8443/TCPHTTPS консоли управленияДа

Порты взаимодействия кластера

Если брандмауэр уровня сети установлен между узлами, эти порты должны быть доступны. Обмен данными между узлами не шифруется. Эти порты не должны быть доступны извне.

ПортОписание
1336/TCPВнутренний API
3033/TCPВнутренний доступ к SVN
3037/TCPВнутренний доступ к SVN
3306/TCPMySQL
4486/TCPДоступ к регулятору
5115/TCPСерверная часть служба хранилища
5208/TCPВнутренний доступ к SVN
6379/TCPRedis
8001/TCPGrafana
8090/TCPВнутренний доступ к GPG
8149/TCPДоступ к файловому серверу GitRPC
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPУправляющая программа Git
9102/TCPФайловый сервер Pages
9105/TCPСервер LFS
9200/TCPElasticsearch
9203/TCPСлужба семантического кода
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

Настройка подсистемы балансировки нагрузки

Рекомендуется использовать внешнюю подсистему балансировки нагрузки на основе TCP, которая поддерживает протокол PROXY для распределения трафика между узлами. Рассмотрите возможность использования следующих конфигураций подсистемы балансировки нагрузки:

  • TCP-порты (как показано ниже) следует перенаправить на узлы, на которых запущена служба web-server. Это единственные узлы, обслуживающие внешние клиентские запросы.
  • Прикрепленные сеансы не должны быть включены.

Предупреждение. При прекращении подключений HTTPS в подсистеме балансировки нагрузки запросы от подсистемы балансировки нагрузки к GitHub Enterprise Server также должны использовать протокол HTTPS. Понижение уровня подключения к HTTP не поддерживается.

Обработка сведений о подключениях клиентов

Так как подключения клиентов к кластеру выполняются из подсистемы балансировки нагрузки, IP-адрес клиента может быть потерян. Для корректной записи сведений о подключении клиента требуется учесть некоторые особенности.

Мы настоятельно рекомендуем реализовать протокол PROXY, если подсистема балансировки нагрузки поддерживает его. Если поддержка PROXY недоступна, нагрузку на порты HTTP и HTTPS можно также распределять с помощью заголовка X-Forwarded-For.

Предупреждение системы безопасности. Если включена поддержка прокси-сервера или перенаправление HTTP, крайне важно, чтобы внешний трафик не мог напрямую поступать на устройства GitHub Enterprise Server. Если внешний трафик не будет блокироваться должным образом, существует риск подделки исходных IP-адресов.

Включение поддержки PROXY на GitHub Enterprise Server

Настоятельно рекомендуется включить поддержку PROXY для экземпляра и подсистемы балансировки нагрузки.

Примечание. GitHub Enterprise Server поддерживает протокол PROXY версии 1, несовместимый с подсистемами балансировки сетевой нагрузки AWS. Если вы используете подсистемы балансировки сетевой нагрузки AWS с GitHub Enterprise Server, не включайте поддержку PROXY.

  • Для имеющегося экземпляра используйте следующую команду:

    $ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
  • Для подсистемы балансировки нагрузки следуйте инструкциям, предоставленным поставщиком.

    Сопоставления TCP-портов протокола ПРОКСИ

Исходный портКонечный портОписание службы
2223Git по протоколу SSH
8081HTTP
443444HTTPS
80808081HTTP консоли управления
84438444HTTPS консоли управления
94189419Git

Включение поддержки X-Forwarded-For на GitHub Enterprise Server

Используйте протокол X-Forwarded-For только в том случае, если протокол PROXY недоступен. Заголовок X-Forwarded-For работает только с HTTP и HTTPS. IP-адрес, сообщаемый для подключений Git по протоколу SSH, будет представлять IP-адрес подсистемы балансировки нагрузки.

Чтобы включить заголовок X-Forwarded-For, используйте следующую команду:

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply

Сопоставления портов протокола TCP для использования без поддержки PROXY

Исходный портКонечный портОписание службы
2222Git по протоколу SSH
2525SMTP
8080HTTP
443443HTTPS
80808080HTTP консоли управления
84438443HTTPS консоли управления

Настройка проверок работоспособности

Проверки работоспособности позволяют подсистеме балансировки нагрузки прекратить направлять трафик узлу, который не отвечает, в случае неудачной попытки выполнения предварительно настроенной проверки этого узла. Если узел кластера завершается сбоем, проверки работоспособности, связанные с избыточными узлами, обеспечивают высокий уровень доступности.

Настройте подсистему балансировки нагрузки, чтобы проверить один из следующих URL-адресов:

  • https://HOSTNAME/status, если протокол HTTPS включен (по умолчанию);
  • http://HOSTNAME/status, если протокол HTTPS выключен.

Проверка вернет код состояния 200 (ОК), если узел работоспособен и доступен для запросов конечных пользователей.

Примечание. Если устройство находится в режиме обслуживания, в URL-адресе https://HOSTNAME/status вернется код состояния 503 ("Служба недоступна"). Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.

Требования к DNS

Поиски DNS для имени узла GitHub Enterprise Server должны разрешаться в подсистему балансировки нагрузки. Рекомендуется включить изоляцию поддомена. Если изоляция поддомена включена, дополнительная запись с подстановочными знаками (*.HOSTNAME) также должна разрешаться в подсистему балансировки нагрузки. Дополнительные сведения см. в разделе Включение изоляции поддомена.