Global Clusters¶
概述¶
Swift 的默认配置目前设计为在单个区域内工作，其中区域定义为机器组，它们之间具有高带宽、低延迟的链路。但是，存在配置选项，可以实现运行高性能多区域 Swift 集群。
在本文档的其余部分，我们将假设一个双区域 Swift 集群：旧金山 (SF) 的区域 1 和纽约 (NY) 的区域 2。每个区域在其内部包含 3 个区域，编号为 1、2 和 3，总共 6 个区域。
配置 Global Clusters¶
注意
以下代理服务器配置选项可以在 [app:proxy-server] 配置部分中给出通用设置，或者使用 每个策略的配置 为单个策略给出特定设置。
read_affinity¶
此设置与 sorting_method 设置结合使用，使代理服务器优先选择本地后端服务器来处理 GET 和 HEAD 请求，而不是非本地服务器。例如，SF 代理服务器通过与 SF 对象服务器通信来服务对象 GET 请求是首选，因为客户端将接收到更低的延迟和更高的吞吐量。
默认情况下，Swift 会随机选择三个副本中的一个提供给客户端，从而均匀地分配负载。在地理分布式集群的情况下，管理员可能更倾向于保持流量本地化，而不是均匀地分配结果。这就是 read_affinity 设置的作用所在。
示例
[app:proxy-server]
sorting_method = affinity
read_affinity = r1=100
这将使代理首先尝试从区域 1 的后端服务 GET 和 HEAD 请求，然后再联系区域 2 的任何后端。但是，如果区域 1 中没有可用的后端（由于副本放置、硬件故障或其他原因），则代理将回退到其他区域的后端服务器。
示例
[app:proxy-server]
sorting_method = affinity
read_affinity = r1z1=100, r1=200
这将使代理首先尝试从区域 1 区域 1 的后端服务 GET 和 HEAD 请求，然后是区域 1 的后端，然后是任何其他后端。如果代理物理上靠近特定的区域或区域，这可以节省带宽。例如，如果一个区域对应于特定机架中的服务器，并且代理服务器位于同一机架中，那么将 read_affinity 设置为优先从机架内读取将减少机架间交换机之间的流量。
read_affinity 设置可以包含任何数量的区域/区域说明符；优先级数字（等号之后）决定了联系后端服务器的顺序。数字越小，优先级越高。
请注意，read_affinity 仅影响主节点（有关主节点的定义，请参阅 ring 文档）的排序，而不影响 handoff 节点的排序。
write_affinity¶
此设置使代理服务器优先选择本地后端服务器来处理对象 PUT 请求，而不是非本地服务器。例如，SF 代理服务器通过与 SF 对象服务器通信来服务对象 PUT 请求可能是首选，因为客户端将接收到更低的延迟和更高的吞吐量。但是，如果使用此设置，请注意，NY 代理服务器处理使用 write affinity 上传的对象的 GET 请求可能需要通过 WAN 链路获取它，因为该对象不会立即在 NY 中拥有任何副本。但是，复制将把对象的副本移动到 SF 和 NY 中的正确位置。
write_affinity 的一个潜在问题是，最终用户在复制之前删除对象时可能会收到 404 错误。write_affinity_handoff_delete_count 设置与 write_affinity 一起使用，以解决该问题。使用其默认配置，Swift 将计算发送请求的适当数量的 handoff 节点。
请注意，只有对象 PUT/DELETE 请求受 write_affinity 设置影响；POST、GET、HEAD、OPTIONS 以及 account/container PUT 请求不受影响。
此设置允许您用吞吐量来交换数据分布。如果启用了 write_affinity，则对象副本最初将全部存储在特定区域或区域内，从而降低了数据分布的质量，但副本将在快速 WAN 链路上传输，从而为客户端提供更高的吞吐量。请注意，复制器最终会将对象移动到其正确且分布良好的位置。
write_affinity 设置仅在您通常不在写入后立即读取对象时才有用。例如，考虑主要备份的工作负载：如果您在 NY 中有一些机器定期将备份写入 Swift，那么您不太可能立即在 SF 中读取这些备份。如果您的工作负载看起来不像这样，那么您可能不应该使用 write_affinity。
write_affinity_node_count 设置仅与 write_affinity 结合使用才有用；它控制在回退到非本地服务器之前将尝试多少个本地对象服务器。
示例
[app:proxy-server]
write_affinity = r1
write_affinity_node_count = 2 * replicas
假设 3 个副本，此配置将使对象 PUT 尝试将对象的副本存储在区域 1 (“r1”) 中的最多 6 个磁盘上（“2 * 副本”）。代理服务器尝试找到 3 个设备来存储对象。当设备不可用时，它查询环以获取第 4 个设备，依此类推，直到第 6 个设备。如果第 6 个磁盘仍然不可用，则最后一个副本将发送到其他区域。这并不意味着区域 1 中将有 6 个副本。
您应该意识到，如果您将数据以比您的复制器将其传输到 NY 更快的速度传输到 SF，那么您的集群的数据分布会随着对象在 SF 中堆积而越来越差。如果发生这种情况，建议禁用 write_affinity 并简单地让对象 PUT 遍历 WAN 链路，因为这将自然地限制对象增长速率到您的 WAN 链路可以处理的程度。
