您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    重磅!GitHub 开源负载平衡组件 GLB Director
    时间:2018-08-11 08:12 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    技术沙龙 | 8月25日与多位资深技术大咖讨论小顺序电商实战

    8 月 8 日,GitHub 发布了开源负载平衡组件 GitHub Load Balancer Director(GLB) Director,GLB 是 GitHub 针对裸机数据中心的可扩展负载平衡处置方案,它支持大少数 GitHub 的对外效劳,并且还为诸如高可用 MySQL 集群这样最为关键的外部系统提供负载平衡效劳。

    项目地址:https://github.com/github/glb-director

    重磅!GitHub 开源负载平衡组件 GLB Director

    GLB Director 有如下诸多优势:

    运用ECMP扩展IP

    4层负载平衡器的基本属性是可以运用单个IP地址在多个效劳器之间完成平衡衔接。 为了扩展单个IP以处置更多的流量,我们不只需求在后端效劳器之间停止流量拆分,还需求可以扩展负载平衡器本身。 这实践上是另一层负载平衡。

    通常,我们将IP地址视为单个物理机器,将路由器视为将数据包移动到下一个最近路由器的机器。 在最复杂的状况下,总是有一个最佳的下一跳,路由器选择该跳并转发一切数据包直抵到达目的地。

    重磅!GitHub 开源负载平衡组件 GLB Director

    实践上,大少数网络都要复杂得多。 两台计算机之间通常有多条途径可用,例如,运用多个ISP或许两台路由器经过多条物理电缆衔接在一同以添加容量并提供冗余。 这是等价多途径(ECMP)路由发扬作用的中央 - 而不是由路由器选择单个最佳下一跳,ECMP中很多途径具有相反成本(通常定义为到目的地的AS的数量), 路由器分散流量以便在一切可用的相反成本途径之间平衡衔接。

    重磅!GitHub 开源负载平衡组件 GLB Director

    ECMP经过对每个数据包停止hash以确定其中一个可用途径。此处运用的hash函数因设备而异,但通常是基于源和目的IP地址以及TCP流量的源和目的端口的分歧性hash。这意味着同一个TCP衔接的多个数据包通常会遍历相反的途径,这意味着即使途径具有不同的延迟,数据包也会以相反的顺序抵达。值得留意的是,在这种状况下,途径可以在不中缀衔接的状况下停止更改,由于它们总是最终位于同一个目的效劳器上,此时它所采用的途径大多有关紧要。

    ECMP的另一种用法是当我们想要跨多个效劳器而不是跨多个途径上的同一效劳器时。每个效劳器都可以运用BGP或其他相似的网络协议运用相反的IP地址,从而使衔接在这些效劳器之间停止分片,路由器不知道衔接是在不同的中央处置的,而非传统做法那样一切的衔接都同一台机器上处置。

    重磅!GitHub 开源负载平衡组件 GLB Director

    虽然ECMP会像对流量停止分片,但它有一个庞大的缺陷:当相反IP的效劳器更改(或沿途的任何途径或路由器发作变化)时,衔接必须重新平衡,才能保证每个效劳器上的衔接比较平衡。 路由器通常是有形状设备,只是为每个数据包做出最佳决策而不思索它所属的衔接,这意味着在这种状况下某些衔接会中缀。

    重磅!GitHub 开源负载平衡组件 GLB Director

    在下面的例子中,我们可以想象每种颜色代表一个活动的衔接。 添加新的代理效劳器运用相反的IP。 路由器保证分歧性哈希,将1/3衔接移动到新效劳器,同时保持2/3衔接在老效劳器上。 不幸的是,关于停止中的1/3衔接,数据包如今抵达了无衔接形状的效劳器,因此衔接会失败。

    将director/proxy别离

    以前仅运用ECMP的处置方案的成绩在于它不知道给定数据包的残缺上下文,也不能为每个数据包/衔接存储数据。理想证明,通常运用Linux Virtual Server(LVS)等工具。我们创立了一个新的“director”效劳器层,它经过ECMP从路由器获取数据包,但不是依托路由器的ECMP hash来选择后端代理效劳器,而是对一切链接控制hash和存储形状(选择后端)。当我们更改代理层效劳器时,director层有望不变,我们的衔接也不会断掉。

    重磅!GitHub 开源负载平衡组件 GLB Director

    虽然这在许多状况下效果很好,但它确实有一些缺陷。在下面的示例中,我们同时添加了LVS director和后端代理效劳器。新的director接纳到一些数据包,但是还没有任何形状(或许具有延迟形状),因此将其作为新衔接停止hash处置并能够使其出错(并招致衔接失败)。 LVS的典型处置办法是运用多播衔接同步来保持一切LVS director效劳器之间共享的衔接形状。这依然需求传达衔接形状,并且依然需求重复形状 - 不只每个代理都需求Linux内核网络堆栈中每个衔接的形状,而且每个LVS director还需求存储衔接到后端代理效劳器的映射。

    将一切形状从director层移除

    当我们设计GLB时,我们决议要改善这种状况而不是重复形状。 经过运用已存储在代理效劳器中的流形状作为维护来自客户端的已树立Linux TCP衔接的一部分,GLB采用与上述办法不同的办法。

    关于每个进入的衔接,我们选择可以处置该衔接的主效劳器和辅佐效劳器。 当数据包抵达主效劳器且有效时,会将数据包转发到辅佐效劳器。 选择主/辅佐效劳器的散列是预先完成一次,并存储在查找表中,因此不需求在每个流或每个数据包的基础上重新计算。 添加新的代理效劳器时,关于1/N衔接,它将成为新的主效劳器,旧的主效劳器将成为辅佐效劳器。 这允许现有流程完成,由于代理效劳器可以运用其本地形状(单一理想来源)做出决策。 从本质上讲,这使得数据包在抵达保持其形状的预期效劳器时具有“第二次时机”。

    (责任编辑:admin)