Конфигурация нескольких мастер-серверов Gerrit (перевод)

Для просмотра оригинального текста перейдите к README.md

Документ описывает, как настроить несколько мастер-серверов Gerrit с общим задействованным backend: общим хранилищем данных и общими git-репозиториями. Использование нескольких мастер-серверов позволяет пользователям обращаться к серверам с большими ресурсами, что снижает нагрузку на серверы, а также повышает доступность, позволяя перенаправлять сервис на любой оставшийся мастер-сервер в случае отказа основного.

Настройка нескольких мастер-серверов по своей сути является сложной задачей, и в зависимости от конфигурации и доступного внешнего аппаратного и программного обеспечения, можно настроить несколько мастер-серверов с различными уровнями обслуживания. Поддерживаемые варианты конфигурации приведены ниже.

Общие git-репозитории

Односайтовая конфигурация нескольких мастер-серверов обычно включает в себя указание всех мастер-серверов на одну и ту же копию git-репозиториев через общую файловую систему. Односайтовая конфигурация обычно состоит в том, чтобы указать все мастер-серверы на одну и ту же копию git-репозиториев через общую файловую систему.

Упрощённое тестирование с общим хостомПростейший пример — это размещение двух серверов Gerrit на одном хосте и указание обоих серверов на одинаковый каталог, содержащий git-репозитории.

Это может быть использовано только в качестве примера для тестирования, так как размещение двух серверов Gerrit на одном хосте маловероятно обеспечит дополнительное балансирование нагрузки или существенно повысит доступность. Однако это может быть полезно для тех, кто хочет понять, как работает конфигурация многочисленных мастер-серверов, так как это легко настроить.

Общий доступ через сеть

Запуск каждого мастер-сервера на отдельном физическом хосте обеспечивает балансировку нагрузки. Хотя любой поддерживаемый JGit общедоступный файловый системный может быть использован, NFS и другие общедоступные файловые системы могут быть лучшим выбором в этом случае.

Чтобы сделать git-репозитории общими, инициализируйте экземпляр Gerrit следующим образом:

$ java -jar {path/}gerrit.war init -d <site1>
# ...
*** Git Repositories
***# Расположение Git-репозиториев   [git]:  /path/to/nfs/git
# Выберите общедоступную сетевую файловую систему для указания местоположения git-репозиториев.
# Обратите внимание: местоположение git-репозиториев должно быть общим для всех серверов.
# Если вы используете значение по умолчанию [git], то репозитории будут расположены в "site1/git" на этом сервере.
# Рекомендуется избегать использования значения по умолчанию и указывать полный путь к git-репозиториям, даже если они находятся на этом сервере.
# Затем полный путь можно использовать при настройке других серверов.

$ java -jar {path/}gerrit.war init -d <site2>
# ...
*** Git Repositories
***## Расположение репозиториев Git
*** Расположение репозиториев Git
```Путь к репозиториям Git:
[git]: /path/to/nfs/git
# Выберите и используйте ту же позицию, что и для первой службы
экземпляр использует
# ...

## Общий базовый слой данных

Все серверы должны использовать одинаковый базовый слой данных, чтобы обеспечить возможность доступа пользователей к одному и тому же набору данных.
Поэтому следует использовать PostgreSQL или MySQL в качестве базы данных.
Так как несколько серверов не могут подключаться к одному встроенному H2 базе данных, использование встроенной H2 базы данных по умолчанию невозможно.

Чтобы использовать общий базовый слой данных, инициализируйте экземпляр Gerrit следующим образом:
```bash
$ java -jar {path/}gerrit.war init -d <site1>
# ...
*** SQL Database ***
***

Тип сервера базы данных [H2/?]:
# Выберите другой тип базы данных, отличный от H2:
# Настройте имя пользователя, пароль и т.д.
# ...

$ java -jar {path/}gerrit.war init -d <site2>
# ...
*** SQL Database ***
***

Тип сервера базы данных [H2/?]:
# Выберите тот же тип базы данных, что и выше, и заполните одинаковые настройки
# ...

Кэш-совместимостьGerrit использует кэши для ускорения доступа к данным. Каждый сервер использует собственный локальный кэш, что означает, что данные в этих кэшах не будут совместно использоваться другими серверами.

Хотя несогласованные кэши между серверами не приведут к проблемам согласованности данных в базе данных или на уровне Git (то есть они не повредят ваши данные), они могут привести к проблемам, которые будут неприятны для пользователей.В общем, проблемы согласованности кэша могут привести к неприятному опыту использования, например, новый проект, созданный на одном сервере, может не отображаться на других серверах. Однако в некоторых случаях проблемы согласованности кэша могут привести к уязвимостям безопасности. Например, изменения в членстве группы, сделанные на одном сервере, могут отображаться на других серверах с большим запозданием. Это запоздание может привести к применению устаревших ACL к некоторым пользователям.

Некоторые важные кэши включают:

• Пользователи: важные сведения о активных пользователях, включая их имя, настройки, адрес электронной почты и членство в группах
• Проекты: записи описаний проектов
• Членство в группах: сведения о членстве в группах
• sshkeys: развернутые версии SSH-ключей пользователей, которые могут быть использованы внутренним SSH-демоном для проверки подлинности

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

Для отключения кэширования добавьте следующие строки в конфигурационный файл <site>/etc/gerrit.config на каждом сервере:

[cache "accounts"]
  memoryLimit = 0
  diskLimit = 0
[cache "projects"]
  memoryLimit = 0
  diskLimit = 0
[cache "groups_members"]
  memoryLimit = 0
  diskLimit = 0
[cache "sshkeys"]
  memoryLimit = 0
  diskLimit = 0

Перезапустите все серверы, чтобы изменения вступили в силу.

$ ./<site1>/bin/gerrit.sh restart
$ ./<site2>/bin/gerrit.sh restart
```## Веб-сессии

Веб-сессии являются частным случаем кэширования. 
Кэширование веб-сессий является авторитетным и не хранится в других местах.
Поэтому с использованием стандартного Gerrit невозможно обмениваться веб-сессиями между основными серверами.

### Несовместимые веб-сессии

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

Несовместимые веб-сессии не предлагают идеального решения; пользователи должны переключаться между серверами вручную для балансировки нагрузки или переключения на резервный сервер.
В большинстве случаев это не обеспечивает очень удовлетворительного пользовательского опыта, но в некоторых случаях это решение все же лучше, чем использование одного сервера.Улучшить опыт можно, назначив каждому пользователю отдельный основной сервер и пытаясь равномерно распределить пользователей между серверами. Это может быть эффективным, когда пользователи естественно делятся: возможно, пользователи из удаленных сайтов или автоматизированные пользователи могут быть разделены на свои собственные серверы. В большинстве случаев это разделение может произойти без использования решения с несколькими основными серверами. Отсутствие альтернатив, стоит отметить, что метод с несовместимыми веб-сессиями может быть лучше, чем использование отдельных основных серверов. Для других причин, по которым вы можете захотеть использовать это настроение, обратитесь к основным принципам. 

Один из способов улучшить опыт — это направить каждого пользователя к персональному мастеру и попытаться равномерно распределить пользователей по серверам. Это может хорошо работать, когда есть естественное разделение пользователей: например, разделить пользователей из удаленного сайта или пользователей автоматизации на свой собственный сервер. Такие разделения могут происходить и без решения с множеством мастеров, используя независимые мастеров.В отсутствие альтернативы стоит задуматься, может ли подход с незащищенными веб-сессиями быть улучшением по сравнению с независимыми мастерами. См. обоснование для других причин, по которым вы можете захотеть использовать эту конфигурацию. ## Доступ по HTTPКаждый сервер должен прослушивать разные http://ip:port.
Для балансировки нагрузки или переключения на другой сервер в случае отказа, пользователи должны быть распределены через мастер-сервер.

### Отдельные URL-адреса хостов

Если веб-сессии не разделяются между мастерами, для каждого мастера должны использоваться отдельные URL-адреса хостов, а балансировка нагрузки и переключение на другой сервер должны выполняться вручную.
Использование отдельных URL-адресов хостов распределяет пользователей на основе начального URL-адреса, который они выбрали для доступа к мастеру. Последующие доступы будут осуществляться к тому же мастеру.

Хотя отдельные URL-адреса хостов не обеспечивают отличный HTTP-опыт пользователя,
см. причины, по которым вы можете захотеть выполнить это в отсутствие других решений.

```bash
$ java -jar {path/}gerrit.war init -d <site1>
# ...
*** HTTP Daemon
***

Listen on address              [*]: server1
Listen on port                 [8080]: port1

$ java -jar {path/}gerrit.war init -d <site2>
# ...
*** HTTP Daemon
***

Listen on address              [*]: server2
Listen on port                 [8080]: port2
# выберите другую комбинацию <ip>:<port> для HTTP-демонов, отличную от используемой первым экземпляром (если этот экземпляр находится на другом сервере, вы все равно можете использовать значения по умолчанию)
# ...

Одни и те же URL-адреса хостов и балансировка нагрузкиПримечание: сначала необходимо настроить разделяемые веб-сессии. Использование одного и того же URL-адреса хоста для доступа к мастерам на разных серверах требует использования балансировщика нагрузки.

Подключаясь к мастерам через балансировщик нагрузки, пользователи видят только один хост (балансировщик нагрузки), и поэтому имеют только одну сессию. Можно использовать любой стандартный балансировщик нагрузки. Адрес HTTP-интерфейса балансера нагрузки должен отличаться от адреса HTTP любого основного сервера. Настройте бэкенд балансера нагрузки с использованием адресов HTTP всех основных серверов. Чтобы основные серверы направляли клиентов для подключения к адресу HTTP балансера нагрузки, добавьте следующие строки в конфигурацию каждого основного сервера, <site>/etc/gerrit.config:

[gerrit]
  canonicalWebUrl = http[s]://<ip>:<port>
                    # адрес HTTP балансера нагрузки

Перезапустите все серверы, чтобы вступили в силу изменения конфигурации.

Пример настройки HAProxy:

global
  daemon
  pidfile /var/run/haproxy.pid

defaults
  mode http
  timeout connect 5000ms
  timeout client 50000ms
  timeout server 50000ms

frontend http-in
  bind <ip>:<http_port>
  # ПРИМЕЧАНИЕ: пользователи должны подключаться по протоколу http к
  # <ip>:<http_port>, который должен совпадать с параметром
  # gerrit.canonicalWebUrl в файлах конфигурации 'gerrit.config'
  default_backend http-servers
```backend http-servers
  server server1 <server1_ip>:<server1_http_port>
  server server2 <server2_ip>:<server2_http_port>

См. Использование HAProxy для информации о запуске и остановке HAProxy.

SSH-доступ

Как и для HTTP, каждый сервер должен прослушивать разные адреса ssh://ip:port.

$ java -jar {path/}gerrit.war init -d <site1>
# ...
*** SSH Daemon
***

Listen on address              [*]: server1
Listen on port                 [29418]: port1

$ java -jar {path/}gerrit.war init -d <site2>
# ...
*** SSH Daemon
***

Listen on address              [*]: server2
Listen on port                 [29418]: port2
# выберите другую комбинацию <ip>:<port> для SSH
  демонов, отличную от используемой первым экземпляром (если этот
  экземпляр находится на другом сервере, вы все равно можете использовать
  значения по умолчанию)
# ...

Чтобы предотвратить появление пользователем предупреждений безопасности при подключении по SSH, убедитесь, что все основные серверы используют одинаковый SSH-RSA-ключ хоста. Это можно сделать путем копирования файлов <site>/etc/ssh_host_rsa_key и <site>/etc/ssh_host_rsa_key.pub с одного сервера на все остальные.### Балансировка нагрузки

Чтобы балансировать нагрузку или перенаправлять пользователей на различные основные серверы, они должны быть распределены между основными серверами. Однако, поскольку SSH-сессии не являются устойчивыми между соединениями, любой стандартный балансировщик SSH-соединений может использоваться для распределения SSH-соединений между доступными основными серверами.Адрес SSH-балансировщика переднего плана должен быть сделан отличным от адреса любого основного сервера. Настройте задний план балансировщика с адресами SSH всех основных серверов. Чтобы основные серверы направляли клиентов для подключения к адресу SSH балансировщика, добавьте следующие строки в конфигурацию каждого основного сервера, <site>/etc/gerrit.config:

[sshd]
  advertisedAddress = <ip>:<port>    # адрес SSH балансировщика

Перезапустите все серверы, чтобы вступили в силу конфигурационные изменения.

Пример файла конфигурации HAProxy <haproxy_config>:

global
  daemon
  pidfile /var/run/haproxy.pid

defaults
  mode tcp
  retries 3
  timeout connect 5000ms
  timeout client 50000ms
  timeout server 50000ms

frontend ssh-in
  bind <ip>:<ssh_port>
  # ЗАМЕЧАНИЕ: пользователи должны подключаться по SSH к
  # <ip>:<ssh_port>, который должен быть таким же, как параметр
  # sshd.advertisedAddress в файлах конфигурации 'gerrit.config'
  default_backend ssh-servers
```backend ssh-servers
  option redispatch
  server server1 <server1_ip>:<server1_ssh_port> check
  server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к Использование HAProxy.### Обоснование Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。 По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP). Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH. Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий. Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers option redispatch server server1 <server1_ip>:<server1_ssh_port> check server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к [Использование HAProxy].### Обоснование
Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。
По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP).
Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH.
Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий.
Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers
  option redispatch
  server server1 <server1_ip>:<server1_ssh_port> check
  server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к Использование HAProxy.### Обоснование Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。 По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP). Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH. Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий. Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers option redispatch server server1 <server1_ip>:<server1_ssh_port> check server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к [Использование HAProxy].### Обоснование
Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。
По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP).
Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH.
Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий.
Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers
  option redispatch
  server server1 <server1_ip>:<server1_ssh_port> check
  server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к Использование HAProxy.### Обоснование Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。 По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP). Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH. Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий. Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers option redispatch server server1 <server1_ip>:<server1_ssh_port> check server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к [Использование HAProxy].### Обоснование
Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。
По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP).
Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH.
Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий.
Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers
  option redispatch
  server server1 <server1_ip>:<server1_ssh_port> check
  server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к Использование HAProxy.### Обоснование Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。 По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP). Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH. Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий. Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers option redispatch server server1 <server1_ip>:<server1_ssh_port> check server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к [Использование HAProxy].### Обоснование
Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。
По сравнению с трафиком SSH в Gerrit, HTTP-трафик в Gerrit обычно очень легок (если только вы не используете git через HTTP).
Это можно использовать как простой путь для обновления резервных серверов, позволяя им служить основными серверами для трафика SSH.
Это также полезно для балансировки нагрузки анонимного трафика HTTP Git, так как он не требует сессий.
Если вы выберете использовать многохостовое соединение только для SSH, вам потребуется установить нормализованный URL, указывающий на одиночный HTTP-хост, чтобы изменить сообщения о загрузке, созданные каждым хостом, на правильный HTTP.

backend ssh-servers
  option redispatch
  server server1 <server1_ip>:<server1_ssh_port> check
  server server2 <server2_ip>:<server2_ssh_port> check

Для получения информации о том, как запускать и останавливать HAProxy, обратитесь к Использование HAProxy.### Обоснование Если вы главным образом заботитесь о балансировке нагрузки для трафика SSH,而不关心用户点击哪个HTTP主机，则不同的主机URL设置很有用。 По сравнению с трафиком SSH в GerrВнимание: В исходном тексте есть куски, которые были переведены с китайского языка, поэтому для полноты перевода было необходимо перевести их на русский язык. Однако, исходный текст был указан как на английском языке, поэтому предполагается, что перевод должен быть выполнен с английского на русский. В данном случае, для сохранения смысла и контекста, были переведены оба варианта текста.

Различная настройка URL-адресов хоста полезна, если вы в основном заботитесь о балансировке нагрузки SSH-трафика и не беспокоитесь, какой HTTP-мастер будет использоваться вашими пользователями. Трафик HTTP в Gerrit обычно очень легок по сравнению с трафиком SSH в Gerrit (если только не используется git через HTTP). Это может быть использовано как простой путь для обновления рабочих узлов, позволяющий им использоваться как мастера для SSH-данных. Это также полезно для балансировки нагрузки анонимного трафика git через HTTP, так как он не требует сессии. Если вы решите использовать многомастерную конфигурацию только для SSH, вы хотите установить ваш URL-адрес по умолчанию, чтобы он указывал на единственный HTTP-мастер, чтобы сообщения о загрузке изменений, созданные каждым мастером, указывали на правильный HTTP-URL.

Использование HAProxy

Дополнительную информацию можно найти по ссылке haproxy.1wt.eu.Проверьте, является ли конфигурационный файл HAProxy валидным:

$ sudo haproxy -f <haproxy_config> -c

Запустите HAProxy:

$ sudo haproxy -f <haproxy_config>

Вы можете использовать sudo kill <haproxy_pid> для остановки HAProxy. Вы можете использовать ps -e | grep haproxy для поиска PID HAProxy. Если вы используете пример конфигурационного файла, PID также можно найти в /var/run/haproxy.pid. Чтобы перезагрузить новый конфигурационный файл с минимальным влиянием на сервис и без прекращения существующих сессий, выполните:

$ sudo haproxy -f haproxy.cfg -sf <haproxy_pid>