多主配置 (译文)
本文档介绍如何使用共享后端设置多个Gerrit主服务器：共享数据库和共享git存储库。
通过使用多个Gerrit主服务器，可以使用户访问具有更多空闲资源的服务器来减轻服务器负载，
并且还可以通过允许在主服务器发生故障时将服务转移到任何剩余主服务器来提供更高的可用性。
设置多主运行本质上很复杂，并且根据配置和可用的外部硬件软件，可以配置具有不同服务级别的多主设置。支持的配置选项如下。
共享Git存储库
单站点多主机布置通常包括通过共享文件系统将所有主机指向git存储库的相同副本。
A single site multi-master arrangement generally consists of pointing all the masters to the same copy of the git repositories via a shared file system.
简单共享主机测试的设置
最简单的例子是在同一主机上托管两个gerrit服务器，并将两个服务器指向git repos所在的同一目录。
这可能仅作为测试的示例，因为在同一主机上运行两个gerrit服务器不太可能提供任何额外的负载平衡或非常提高可用性。
但是，对于那些有兴趣了解多主设置如何工作的人来说，这可能很有用，因为它很容易设置。
通过网络文件系统共享
将每个主节点运行在单独的物理主机提供一个负载均衡.
尽管任何支持的共享文件系统的JGit也可以使用，但NFS等共享文件系统可能是这种情况的最佳选择。
要共享git repos，请初始化Gerrit实例，如下所示：
$java -jar {path/}gerrit.war init -d
# ...
*** Git Repositories
***
#Location of Git repositories [git]: /path/to/nfs/git
# 选择一个网络共享文件系统上用以指定git存储库位置。
# 注意：git存储库的位置必须由所有服务器共享。
# 如果您使用默认的[git]，那么存储库将位于本服务器的“site1/git”中。
# 建议您避免使用默认值并指定git存储库的完整路径，即使它位于此服务器上也是如此。
# 然后可以在设置其他服务器时使用完整路径。
$java -jar {path/}gerrit.war init -d
# ...
*** Git Repositories
***
Location of Git repositories [git]: /path/to/nfs/git
# 选择和第一台服务相同的位置
instance uses
# ...
共享数据库
所有服务器必须使用相同的数据库，以确保用户可以访问相同的数据。
因此，应该使用PostgreSQL或MySQL作为数据库。
由于多个服务器无法在嵌入模式下连接到同一H2数据库，因此无法使用默认的嵌入式H2数据库。
要共享数据库，请初始化Gerrit实例，如下所示:
$java -jar {path/}gerrit.war init -d
# ...
*** SQL Database
***
Database server type [H2/?]:
# 选择除h2之外的其他类型数据库:
# 配置用户名密码等.
# ...
$java -jar {path/}gerrit.war init -d
# ...
*** SQL Database
***
Database server type [H2/?]:
# 选择和上述相同的数据库,填写相同的配置.
# ...
缓存一致性
Gerrit使用缓存来加速数据访问。每个服务器都使用自己的本地缓存，这意味着这些缓存中的数据不会与其他服务器共享。
虽然跨服务器的不连贯缓存不会导致数据库或git层的数据一致性问题(即它不会破坏您的数据)，但它可能导致许多面临用户的问题。
一般而言，面临问题的会导致令人不快的用户体验，例如，在一台服务器上创建的新项目不会显示在其他服务器上。
但是，在某些情况下，缓存一致性问题可能具有安全隐患。
例如，在一台服务器上的成员身份更改显示在其他服务器上之前会有很长的延迟。此延迟可能导致过时的ACLs应用于某些用户。
一些值得注意的缓存是：
账户: 活跃用户的重要详细信息，包括其显示名称，配置，电子邮件地址和组成员身份
项目: 项目描述记录
组员: 组员的资格信息
sshkeys: 用户SSH密钥的解压缩版本,内部SSH守护程序可以在身份验证期间与它们匹配
缓存强一致性
确保缓存一致性的最简单的解决方案是禁用缓存，以便每个服务器都被迫从数据库获取最新数据并在每个请求上重新发布。
显然，这种方法对master有性能影响，只有在拥有多个master的优势超过这种性能损失时才应该使用。
请将以下行添加到每个服务器的 /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
重新启动所有服务器以使配置更改生效。
$.//bin/gerrit.sh restart
$.//bin/gerrit.sh restart
Web Sessions
Web sessions 是缓存的特例.
web session 缓存具有权威性，并且不会存储在其他任何位置.
因此，使用标准的gerrit，无法在主服务器之间共享web sessions.
非共享 Web Sessions
由于使用主机名识别Web会话，因此可以为每个master服务器简单地创建不同的会话。
通过这样的设置，登录或退出一个master服务器不会影响将其他master服务器上的登录和退出。
对于用户来说，master只是作为不同的站点出现(但后端数据仍然相同)。
当然，如果没有共享web sessions，则不会对这些会话进行自动负载均衡或故障转移。
非共享web sessions无法提供理想的解决方案; 用户必须在服务器之间手动切换以进行负载平衡或故障转移。
大多数情况下，这并不能提供非常令人满意的用户体验，但是，有些情况下，这种解决方案仍然优于使用单个主机。
改善体验的一种方法是为每个用户分配一个master，并尝试在服务器之间平均分配用户。
当用户自然分裂时，这可能很有效：可能是将用户从远程站点拆分，或者将自动化用户拆分到他们自己的服务器。
在许多情况下，通过使用独立主设备，这种分裂可能在没有多主解决方案的情况下发生。
缺乏替代方案，值得一提的是，非共享Web会话方法是否可能比独立主服务器有所改进。
有关您可能希望使用此设置的其他原因，请参阅基本原理。(本段译文有待改进,原文如下)
One way to improve the experience is to point each user to a per user master and attempting to split users evenly across servers.
This may work well when there is a natural split in your users:
perhaps to split users from a remote site, or automation users off to their own server.
Such splits might happen without a multi-master solution anyway in many situations by using independent masters.
Lacking an alternative it is worth asking if the non-shared web sessions approach might be an improvement over independent master.
See rationale for other reasons why you might want to use this setup.
HTTP Access
每个服务器必须侦听不同的http://ip:port.
为了负载平衡或故障转移用户到不同的主机，它们必须通过master分配。
Separate Host URLs
如果不在主服务器之间共享Web会话，则必须使用不同的主机URL去访问每个主服务器，并且须手动完成故障转移。
使用不同的主机URL将根据用户选择访问主服务器的初始URL分发用户。后续访问将是同一个主服务器。
If web sessions are not shared across masters,
different host URLs must be used for each master and http load balancing and fail over
must be done manually.
Using a different host URL will distribute users based on the initial URL they choose to access the master.
Subsequent accesses will be to the same master.
虽然单独的主机URL无法提供出色的http用户体验.
但请参阅理由，了解为什么您可能希望在没有任何其他解决方案的情况下执行此操作。
While separate host URLs does not provide a great http user experience,
see rationale for why you might want to do this absent any other solutions.
$java -jar {path/}gerrit.war init -d
# ...
*** HTTP Daemon
***
Listen on address [*]: server1
Listen on port [8080]: port1
$java -jar {path/}gerrit.war init -d
# ...
*** HTTP Daemon
***
Listen on address [*]: server2
Listen on port [8080]: port2
# choose a different : combination for HTTP
daemons than what the first instance uses (ifthis
instance is on another server, you can still use the
defaults)
# ...
相同的主机URL和负载平衡
注意：必须先设置共享Web会话。使用相同主机URL访问不同服务器上的主服务器需要使用负载平衡器。
通过负载均衡器连接到主服务器，用户只能看到一个主机名(负载均衡器)，因此只有一个会话。可以使用任何标准负载平衡器。
NOTE: Shared web sessions must be setup first.
Accessing masters on different servers using the same host URL requires using a load balancer.
By connecting to the masters through a load balancer, the users will see only one hostname (the load balancer's),
and thus will have just one session. Any standard load balancer can be used.
负载均衡器的前端http地址应与任何主站的http地址不同。使用所有主服务器的http地址配置负载均衡器的后端。
要让主服务器指示客户端连接到负载均衡器的http地址，请将以下行添加到每个主服务器的配置中/etc/gerrit.config：
The load balancer‘s front-end http address should be made different from that of any master.
Configure the load balancer’s back-end with the http addresses of all the masters.
To have the masters direct clients to connect to the load balancer‘s http address,
add the following lines to each master’s config, /etc/gerrit.config:
[gerrit]
canonicalWebUrl = http[s]://:
# http address of the load balancer
重新启动所有服务器以使配置更改生效。
使用HAProxy的示例设置如下：
global
daemon
pidfile /var/run/haproxy.pid
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend http-in
bind :
# NOTE: users should connect over http to
:, which should be the same as the
gerrit.canonicalWebUrl parameter in the
'gerrit.config' files
default_backend http-servers
backend http-servers
server server1 :
server server2 :
See Using HAProxy for how to start and stop HAProxy.
SSH Access
与http一样，每个服务器必须侦听不同的ssh://ip：port.
$java -jar {path/}gerrit.war init -d
# ...
*** SSH Daemon
***
Listen on address [*]: server1
Listen on port [29418]: port1
$java -jar {path/}gerrit.war init -d
# ...
*** SSH Daemon
***
Listen on address [*]: server2
Listen on port [29418]: port2
# choose a different : combination for SSH
daemons than what the first instance uses (ifthis
instance is on another server, you can still use the
defaults)
# ...
要防止用户在通过ssh连接时收到安全警告，
请让所有主服务器通过从任何一个复制/etc/ssh_host_rsa_key和/etc/ssh_host_rsa_key.pub来使用相同的ssh-rsa主机密钥。
负载均衡
为了将用户负载平衡或故障转移到不同的主服务器，它们必须分布在主服务器上。
但是，由于ssh会话在连接中不是持久的，因此可以使用任何标准ssh负载平衡器在可用主服务器之间分发ssh连接。
In order to load balance or fail-over users to different masters they must be distributed across masters.
However, since ssh sessions are not persistent across connections,
any standard ssh load balancer can be used to distribute ssh connections across the available masters.
载均衡器的前端ssh地址应与任何主站的不同。使用所有主服务器的ssh地址配置负载均衡器的后端。
要让主服务器指示客户端连接到负载均衡器的ssh地址，请将以下行添加到每个主服务器的配置中/etc/gerrit.config：
The load balancer‘s front-end ssh address should be made different from that of any master.
Configure the load balancer’s back-end with the ssh addresses of all the masters.
To have the masters direct clients to connect to the load balancer‘s ssh address,
add the following lines to each master’s config, /etc/gerrit.config:
[sshd]
advertisedAddress = : # ssh address of the load balancer
重启所有服务器以使配置更改生效。
HAProxy的示例文件:
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 :
# NOTE: users should connect over ssh to
# :, which should be the same as the
# sshd.advertisedAddress parameter in the
# 'gerrit.config' files
default_backend ssh-servers
backend ssh-servers
option redispatch
server server1 : check
server server2 : check
有关如何启动和停止HAProxy，请参阅Using HAProxy.
Rationale
如果您主要关注ssh流量的负载平衡而不关心用户点击哪个http主机，则不同的主机URL设置很有用。
与Gerrit ssh流量相比，Gerrit http流量通常非常轻(除非使用git over http)。
这可以用作从站的简单升级路径，允许它们用作ssh数据的主站。
这对于匿名git http流量的负载平衡也很有用，因为它不需要会话。
如果您选择仅为ssh使用多主机，则需要将规范URL设置为指向单个http主机，以便将每个主机创建的上载消息更改为正确的http
The different host URL setup is valuable if you mainly care to load balance ssh traffic and don't care which http master your users hit.
Gerrit http traffic is generally very light compared to Gerrit ssh traffic (unless git over http is used).
This can be used as a simple upgrade path for slaves allowing them to be used as masters for ssh data.
This is also useful for load balancing anonymous git http traffic since it does not require a session.
If you choose to use multi-masters only for ssh,
you want to set your canonical URL to point to the single http master
so that change upload messages created by each master point to the correct http URL.
Using HAProxy
检查HAProxy配置文件是否有效:
$sudohaproxy -f -c
启动 HAProxy:
$sudohaproxy -f
可以使用sudo kill 来停止HAProxy。
可以使用ps -e | grep haproxy找到HAProxy PID.
如果您使用示例配置文件，也可以在/var/run/haproxy.pid中找到PID。
要以最小的服务影响重新加载新配置并且不影响已有的session，请运行：
$sudohaproxy -f haproxy.cfg -sf
扫一扫
528
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
