Skip to main content

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

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

Кто может использовать эту функцию?

GitHub определяет право на кластеризация и должен включить конфигурацию лицензии вашего экземпляра. Кластеризация требует тщательного планирования и дополнительных административных накладных расходов. Дополнительные сведения см. в разделе Сведения о кластеризации.

Сведения о сети для кластера GitHub Enterprise Server

Каждый узел в кластере GitHub Enterprise Server должен иметь возможность взаимодействовать со всеми другими узлами в кластере по сети. Вы можете просмотреть необходимые порты и протоколы для конечных пользователей, администрирования и обмена данными между узлами. Чтобы распределить трафик между интерфейсными узлами, GitHub рекомендует настроить внешнюю подсистему балансировки нагрузки.

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

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

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

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

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

ПортDescriptionEncrypted
22/TCPGit по протоколу SSH
25/TCPSMTPТребуется STARTTLS
80/TCPHTTP

Если протокол SSL включен, этот порт перенаправляется на HTTPS
443/TCPHTTPS
9418/TCPПростой порт протокола Git
(Отключено в частном режиме)

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

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

ПортDescriptionEncrypted
ICMPICMP Ping
122/TCPАдминистративный SSH
161/UDPSNMP
8080/TCPHTTP консоли управления

Если протокол SSL включен, этот порт перенаправляется на HTTPS
8443/TCPHTTPS консоли управления

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

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

ПортDescription
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. Для подключений Git по протоколу SSH IP-адрес будет иметь значение подсистемы балансировки нагрузки. В некоторых средах IP-адреса клиента в журнале аудита экземпляра могут отображаться 127.0.0.1неправильно.

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

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

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

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

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

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

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

http(s)://HOSTNAME/status

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

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

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

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