即使director依然会将衔接发送到错误的效劳器，该效劳器也会知道如何将数据包转发到正确的效劳器。 就TCP流而言，GLB director层是完全有形状的：director效劳器可以随时进出，并且总是选择相反的主/辅效劳器，只需它们的转宣布婚配（但它们很少改动）。 在变更代理时有些细节需求留意，我们将在下面引见。

维护Hash集合不变

GLB Director设计的中心归结为一直如一地选择主效劳器和辅佐效劳器，并允许代理层效劳器依据需求排空和填充。 我们以为每个代理效劳器都有一个形状，当有效劳器参加或许参加时调整形状。

我们创立一个静态二进制转宣布，它以相反方式在每个控制器效劳器上生成，以将进入的衔接映射到给定的主效劳器和辅佐效劳器。 我们并没有采用在数据包处置时从一切可用效劳器中选择效劳器的这种复杂逻辑，而是经过创立表（65k行）这种直接的方式，每行包含主效劳器和辅佐效劳器IP地址。 该表以二维数组的方式将数据存储在内存中，每个表大约512kb。 当数据包抵达时，我们一直将其（仅基于数据包数据）hash到该表中的同一行（运用hash作为数组的索引），这提供了分歧的主效劳器和辅佐效劳器对。

我们希望每个效劳器在主要和辅佐字段中大致相反，并且永远不会出如今同一行中。 当我们添加新效劳器时，我们希望某些行使其主效劳器成为辅佐效劳器，并且新效劳器将成为主效劳器。 异样，我们希望新效劳器在某些行中成为辅佐效劳器。 当我们删除效劳器时，在它是主效劳器的任何行中，我们希望辅佐效劳器成为主效劳器，而另一个效劳器则成为辅佐效劳器。

这听起来很复杂，但可以用几个不变量繁复地概括：

当我们更改效劳器集时，应保持现有效劳器的相对顺序。

效劳器的顺序应该是可计算的，除了效劳器列表之外没有任何其他形状（能够还有一些预定义的种子）。

每个效劳器在每行中最多应出现一次。

每个效劳器在每列中的出现次数应大致相反。

针对上述的一些成绩，集合hash是一个理想的选择，由于它可以很好地满足这些不变量。 每个效劳器（在我们的例子中，IP）都与行号一同停止hash，效劳器按该hash（只是一个数字）停止排序，并且我们取得该给定行的效劳器的独一顺序。 我们辨别将前两个作为主要和主要。

将保持相对顺序，由于无论包含哪些其他效劳器，每个效劳器的hash都是相反的。 生成表所需的独一信息是效劳器的IP。由于我们只是对一组效劳器停止排序，因此效劳器只出现一次。 最后，假设我们运用伪随机的良好hash函数，那么排序将是伪随机的，因此散布将如我们所希冀的那样平均。

代理(Proxy)相关操作

添加或删除代理效劳器，我们需求一些特别的处置方式。这是由于转宣布条目仅定义主要/辅佐代理，因此排空/缺点转移仅适用单个代理主机。 我们为代理效劳器定义以下有效形状和形状转换：

当代理效劳器处于活动形状，耗尽或填充时，它将包含在转宣布条目中。 在波动形状下，一切代理效劳器都是活动的，并且下面描画的集合点散列将在主列和辅佐列中具有大致平均且随机的每个代理效劳器散布。

当代理效劳器转换为耗尽时，我们经过交流我们本来包含的主要和主要条目来调整转宣布中的条目：

这具有将数据包发送到先前主要的效劳器的效果。 由于它首先接纳数据包，它将接受SYN数据包，因此接受任何新衔接。 关于任何不了解为与本地流有关的数据包，它将其转发到其他效劳器（先前的主效劳器），这允许完成现有衔接。

这样可以优雅地耗尽所需的衔接效劳器，之后可以完全删除它，并且代理可以随机填充到第二个空槽：

填充中的节点看起来就像活动一样，由于该表本身允许第二次时机：

此完成要求一次只要一个代理效劳器处于活动形状以外的任何形状，这实践上在GitHub上运转良好。对代理效劳器的形状更改可以与需求维护的最长衔接继续时间一样快。我们正努力于设计的扩展，不只支持主要和主要，而且一些组件（如下面列出的标题）曾经包含对恣意效劳器列表的初始支持。

数据中心内封装

如今有了一个算法来分歧地选择后端代理效劳器，但是如何在数据包内把辅佐效劳器（secondary server ）的信息也封装出来呢？这样主效劳器可以在不了解数据包的状况下转发数据包。

(责任编辑：admin)