没有负载平衡云服务器标配器的负载平衡_Web云服务器租用_云数据库

小编：CloudFlare在上周末中断了一个小时。谢天谢地，对于我们的服务来说，这样的中断是比较罕见的。尽管有成千上万的客户，他们所产生的大量合法流量，以及我们不断为他们抵御的大规

没有负载平衡器的负载平衡

不带负载平衡器的负载平衡

CloudFlare在上周末中断了一个小时。谢天谢地，对于我们的服务来说，这样的中断是比较罕见的。尽管有成千上万的客户，他们所产生的大量合法流量，以及我们不断为他们抵御的大规模拒绝服务攻击，但这一点还是存在的。虽然上周末的停机暴露了我们架构中的一个缺陷，我们正在努力彻底消除这个缺陷，但我们的系统在很大程度上是设计成平衡的，没有单点故障。我们还没有谈论过CloudFlare系统的体系结构，但我们认为社区的其他成员可能会从我们所做的一些选择中受益，我们如何平衡系统的负载，以及这如何使我们能够快速高效地扩展。失败不是选择，这是事实CloudFlare的架构从一个假设开始：失败将会发生。因此，我们必须在每一个层面上计划失败，并设计一个系统，在发生故障时优雅地处理它。要了解我们是如何做到这一点的，您必须了解CloudFlare边缘系统的组件。以下是我们在网络边缘部署的四个关键组件：网络：CloudFlare其23个数据中心（内部我们称之为POP）通过多个提供商与世界其他地区相连。这些连接既通过传输（带宽）提供商，也通过我们直接对等的其他网络。路由器：在我们每个POP的边缘都是一个路由器。此路由器公布数据包从Internet的其余部分进入CloudFlare网络的路径。交换机：在每个PoP中，将有一个或多个交换机聚合PoP的局域网（LAN）内的流量。服务器：每个交换机后面都有一组服务器。这些服务器执行一些关键任务来支持CloudFlare的服务，包括DNS解析、代理、缓存和日志记录。这是我们在世界各地运行的机架中发现的四个组件。您会注意到，典型的硬件堆栈中似乎缺少一些东西。例如，没有硬件负载平衡器。硬件负载平衡器（以及硬件防火墙）的问题在于，它们常常成为瓶颈，并自行造成单点故障。我们使用路由协议来传播流量和处理故障，而不是依赖硬件来平衡整个网络的负载。选角是你的朋友对于大多数Internet，IP地址对应于连接到公共Internet的单个设备。在您的家庭或办公室中，您可能有多个设备位于使用网络地址转换（NAT）的网关后面，但只有一个公共IP地址，并且位于网络后面的所有设备都使用唯一的专用IP地址（例如，在192.168.X.X或10.X.X.X空间中）。因特网上的一般规则是每个设备有一个唯一的IP。这是一种称为单播的路由方案。然而，这并不是唯一的办法。有四种主要的路由方案：单播、多播、广播和选播。多播和广播是所谓的一对多路由方案。通过广播，一个节点发送命中所有接收方节点的数据包。广播不再被广泛使用，实际上也没有在IPv6中实现（其最大的当代用途可能是发起SMURF DDoS攻击）。对于多播，一个节点发送的数据包命中选择加入组的多个（但不是所有）接收方节点（例如，有线电视公司如何通过IP网络传送电视广播）。

无负载的负载平衡平衡器

单播和选播是一对一的路由方案。在这两种情况下，数据包都有一个发送方和一个接收方。两者之间的区别在于，尽管通过单播发送的数据包在整个网络上只有一个可能的目的地，但是在Anycast中有多个可能的目的地，并且网络本身选择最优先的路由。在广域网（WAN）——又名。Internet—此首选项是从发件人到收件人的最短路径。在局域网上，可以用路由器所遵循的权重来设置首选项。广域网选播在CloudFlare，我们在两个级别使用Anycast：广域网和局域网。在广域网级别，CloudFlare 23个数据中心中的每个路由器都会公布我们所有面向外部的IP地址。例如，CloudFlare为DNS服务宣布的一个ip是173.245.58.205。所有23个CloudFlare数据中心都宣布了到该IP地址的路由。当你把一个包发送到那个IP地址时，它会经过一系列路由器。这些路由器查看到CloudFlare端点的可用路径，并将数据包发送到沿途站点最少的站点（即"跳数"）。您可以运行traceroute来查看这些步骤。如果我从CloudFlare位于旧金山的办公室运行traceroute，那么我的数据包的路径是：$traceroute 173.245.58.205traceroute到173.245.58.205（173.245.58.205），最多64跳，52字节数据包1 192.168.2.1（192.168.2.1）3.473毫秒1.399毫秒1.247毫秒2 10.10.11.1（10.10.11.1）3.136毫秒2.857毫秒3.206毫秒3 ge-0-2-5.cr1.sfo1。美国.nlayer.net（69.22.X.X）2.936毫秒3.405毫秒3.193毫秒4 ae3-70g.cr1.pao1。美国.nlayer.net（69.22.143.170）3.638毫秒4.076毫秒3.911毫秒5 ae1-70g.cr1.sjc1。美国.nlayer.net（69.22.143.165）4.833毫秒4.874毫秒4.973毫秒6 ae1-40g.ar2.sjc1。美国.nlayer.net（69.22.143.118）8.926毫秒8.529毫秒6.742毫秒7 as13335.xe-8-0-5.ar2.sjc1。美国.nlayer.net（69.22.130.146）5.048毫秒8 173.245.58.205（173.245.58.205）4.601毫秒4.338毫秒4.611毫秒如果您从伦敦的Linode服务器运行相同的traceroute，我的数据包采用的路径是：$traceroute 173.245.58.205traceroute到173.245.58.205（173.245.58.205），最多30跳，60字节数据包1 212.111.X.X（212.111.X.X）6.574毫秒6.514毫秒6.522毫秒2 212.111.33.X（212.111.33.X）0.934毫秒0.935毫秒0.969毫秒3 85.90.238.69（85.90.238.69）1.396毫秒1.381毫秒1.405毫秒4号ldn-b3-链接.telia.net（80.239.167.93）0.700毫秒0.696毫秒0.670毫秒5号ldn-bb1-链接.telia.net（80.91.247.24）2.349毫秒0.700毫秒0.671毫秒6号ldn-b5-链接.telia.net（80.91.246.147）0.759毫秒0.771毫秒0.774毫秒7 cloudflare-ic-154357-ldn-b5.c。电信网（80.239.161.246）0.917毫秒0.853毫秒0.833毫秒8 173.245.58.205（173.245.58.205）0.972毫秒1.292毫秒0.916毫秒在这两种情况下，第8跳和最后一跳是相同的。但是，从第7跳（下面用红色突出显示）中的提示可以看出，它们正在攻击不同的CloudFlare数据中心：as13335.xe-8-0-5.ar2.sjc1。美国.nlayer.net表明它正在袭击圣何塞和cloudflare-ic-154357-ldn-b5.c。电信网表明它正在袭击伦敦。由于数据包将遵循最短路径，因此如果一个特定的路径被撤回，那么数据包将找到它们通向下一个最短可用路径的路径。对于UDP这样的不维护状态的简单协议，Anycast是理想的，并且它已经被广泛用于负载平衡DNS一段时间。在CloudFlare，我们做了大量的工程来允许TCP在Anycast上运行而不需要抖动。这包括仔细调整路由以获得最佳路由，同时也需要调整我们处理协议协商本身的方式。虽然维护起来比单播网络更复杂，但好处是我们可以失去整个数据中心，数据包会流到下一个最近的设施，而不会有人注意到和打嗝。局域网中的选播一旦数据包作为特定的CloudFlare数据中心到达，我们希望确保它到达能够正确处理请求的服务器。CloudFlare的服务器执行四项关键任务：DNS、代理、缓存和日志记录。我们倾向于遵循类似Google的方法，部署通用的白盒服务器，这些服务器可以执行许多不同的功能。（顺便说一句，如果有人感兴趣，我们正在考虑写一篇博文"游览"一个典型的CloudFlare服务器，并讨论我们在与制造商合作设计它们时所做的选择。）由于服务器可能会出现故障或过载，我们需要能够围绕问题智能地路由流量。为此，我们回到我们的老朋友Anycast。

无负载的负载平衡平衡器

使用Anycast，每个CloudFlare数据中心内的每个服务器都被设置为接收来自任何公共IP地址的流量。到这些服务器的路由是通过边界网关协议（BGP）从服务器本身宣布的。为了做到这一点，我们使用了一个叫做Bird的软件。（你只要看看它的一个开发人员就可以知道它是一个非常紧张的网络软件。）虽然所有服务器都为所有IP宣布了一条跨LAN的路由，但每个服务器都为每个IP路由分配了自己的权重。路由器然后被配置成使得具有最小权重的路由是首选的。如果服务器崩溃，Bird会停止向路由器通告BGP路由。然后路由器开始用下一个权重最低的路由向服务器发送流量。我们还监视每台服务器上的关键进程。如果这些关键过程中的任何一个失败了，它就可以向Bird发出信号，让它撤回一条路线。这不是全部或全部。监视器知道服务器自身的负载以及数据中心中其他服务器上的负载。如果某个特定的服务器开始过载，并且在其他地方似乎有足够的容量，那么就可以撤销一些BGP路由，从而从过载的服务器上带走一些流量。除了故障转移之外，我们还开始尝试使用BGP来实现真正的负载平衡。在这种情况下，对多个服务器的权重是相同的，路由器对源IP、目标IP和端口进行哈希处理，以便一致地将流量路由到同一个服务器。可以调整哈希映射表以增加或减少集群中任何计算机的负载。对于UDP这样的简单协议，这是相对容易的，所以我们在DNS中使用它。这是更棘手的协议

当前网址：http://www.vmchk.com/tutorials/5179.html

你可能喜欢的：