iptables的CLUSTER target与以太网交换机的思想

时间：2014-07-20 00:00:31 阅读：278 评论：0 收藏：0 [点我收藏+]

标签：blog http 数据 2014 问题 re

周末的空气闷热，一想到以后再也不会像样地下雨就心里一阵悲哀。每个周末我都会抽出一个晚上总结一周的所有事情，不管是工作的，生活的，还是上下班路上的所见所闻抑或者路上的读后感，由于不再下雨，我决定周六晚上好好睡一觉，那就周五晚上折腾。
在给同事解释交换机和HUB的原理的时候，想到了某些时候，HUB才是更加高效的选择，你看，iptables的朴实的CLUSTER target和F5的高大上负载均衡设备之间区别不就是一台HUB和一台学习型以太网交换机之间的区别吗？我们先来看看CLUSTER target。
很简单，如下图所示：

bubuko.com,布布扣

将是否处理包的决策权交给了每一台服务器本身，而不是集中的负载均衡设备。这是典型的BMA方式，对应到以太网上就是总线方式或者HUB方式，以太数据帧会到达每一台主机，至于是否处理该数据帧，取决于目标MAC是不是本地的，或者它是不是特殊的比如多播帧，广播帧之类的。总线，HUB时代的以太网实际上和CLUSTER target的思想是一致的。中心设备简单，单包转发高效，决策平摊到每一台终端设备上，效率提升了不少，但是缺点是什么呢？缺点就是有效带宽的利用率降低了，因为除了一个包会被处理之外，其它的都被终端丢弃了，对于早期的总线型以太网而言，CSMA/CD的开销也不可小觑，它的开销大大超过了交换机出现后的查表开销，正是因为这个开销而不是别的，才导致了HUB/交换机的出现，学习型交换机出现后，全双工模型仅仅带来了查表的开销而已。
       然而，CLUSTER target却没有这个问题，或者说带宽利用率的问题并不明显。好处却是显而易见的。CLUSTER target省去的是中心负载均衡设备内的复杂运算以及其单点故障，带来的是部署上的简单，维护上的简单，以及高可用性。
       确实，有时候，广播并不是什么坏事，精确的定点传输并不一定是好事，查表也是有开销的，此时需要评估查表的效率，在某些情况下，比如硬件加速卡查表时，它带来的高效带宽利用的优势就抵消了查表开销。软实现的查表，在简单情况下，都是无益的，正因为如此，VMWare的虚拟交换机中并没有实现MAC/Port映射，即MAC地址学习。一直以来，只要人们一说负载均衡，总要联系到一台设备，这个设备就是做负载均衡的，就像人们一直以来都认为一台设备能TMD加速数据流一样(只要是设备，都是减速的，加速是一场骗局，实际上用的是cache！)，对于负载均衡而言，本来有N个处理节点，结果都要TMD汇集到一台所谓的负载均衡设备上，由它来决定数据的流向，这种集中化的控制更多的是为了将处理节点的分发集中在一个可控的范围内，逻辑上讲，是对服务器本身配置的不放心不信任(怎么才能让它们合作起来呢？难道不需要跑来跑去去配置它们吗？)，物理上讲，人为引入了单点问题-瓶颈以及故障，经济上，可以卖出去一台设备，为了解决单点问题，再卖出去几台设备...再卖出去几台。
       以太网广播开销的问题让分布式帧接收改变成了中心式的分发控制，然而iptables的CLUSTER target又让人们看到了分布式分发的优势，在说带宽利用率低的时候，请首先计算一下高的带宽利用率是拿什么换来的，对于中毒太深的资深人员而言，他们可能对我的观点不屑一顾，然而一家之间，恳求不喜勿喷。

iptables的CLUSTER target与以太网交换机的思想,布布扣,bubuko.com

iptables的CLUSTER target与以太网交换机的思想

标签：blog http 数据 2014 问题 re

原文地址：http://blog.csdn.net/dog250/article/details/37965347

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行