当我坐在这里在凯悦酒店的大厅参加本周CloudConnect甚至说一点我清单的小腿歌新俚语的花园州配乐(一个好的顺便说一句,特别是如果你想冷静下来,类型,而不是被迫偷听你周围的三个对话,而这些都是无意中有趣的),当我听“新俚语”我不停地改变歌词“新的规模。所以，虽然这篇文章的标题让人想起了休伊·刘易斯(Huey Lewis)和80年代的新闻记忆，但我必须承认，花园州才是真正的起源。
那么为什么我需要一个新的秤呢?
过去，当我们讨论网络交换机和路由器时，我们会使用一套相当一致的指标来确定哪个产品或技术更优越或最适合给定的任务。这些指标包括如下:
设备有多少接口，以什么速度?
它是否以线的速度转发它们?
它能在同一时间以线速度转发所有这些信息吗?
如果它不能以线的速度转发它们，它如何和在哪里超额订阅?
如果它是超额订阅，它如何决定什么是被删除?有报道下降吗?
它是否允许QoS影响和帮助选择什么是要删除和什么是不删除?
我可以告诉如果我放弃正在下降,因为我的网络元素没有向前的能力,或者是由于出口接口,转发引擎/表被选中的拥挤和缓冲区已经过期,无法处理更多的数据吗?
我的设备能处理多少路由对等点和邻接?
它收敛的有多快?
在耗尽处理ACL的能力之前，ACL可以处理多少ACL和行?
它能处理多少IP路由?那么IPv6呢?
你明白我的意思了……
现在，我听到许多精通网络的人在谈论一项技术、产品等时不断地抱怨:“X无法扩展。”(对于许多有关网络技术的本应鼓舞人心的争论来说，这可以说是敲响了丧钟。大多数讨论到此结束]
真正的问题是“它能扩大规模吗”，最好的回答总是在上下文而不是抽象的。所以在很多情况下，‘它不适合规模化’实际上应该被重申:‘它今天可能符合我的要求;然而，考虑到我预期的增长速度和需求，它不太可能在未来满足它们，因为我的it需求已经超过了这款产品的能力。”
在这个虚拟化、云计算、有时是移动工作负载、结构、叠加分割模型和机器可读编程api的令人生畏的时代，有关规模的讨论需要包含一些人们过去忽略的新指标。可以看到，数据中心中的大多数网络都是在断言访问层每个雷竞技电脑网站端口有一台主机的情况下构建的。这一台主机在大多数情况下有一个MAC地址和一个IP地址。
然而，在虚拟化的数据中心或云中，它通常可能有多个。雷竞技电脑网站例如，以现在众所周知的Amazon ECU(弹性计算单元)为例，您可以将大约25-40个ECU塞到双插槽Intel Westmere上，此后不久，您应该能够使用Intel Romley芯片组完成超过50个ECU。如果您的应用程序是更多的VDI，那么您可以很容易地看到100-200个VDI会话在一个强大的服务器上。
这改变了我们衡量网络容量及其随业务需求增长的能力的规模。原因如下:
新的度量标准#1:ARP表
大多数供应商计划在合理规模的网络广播域。一个交换机需要知道在一个广播域内存在的每个MAC的MAC地址，否则它会将未知的MAC地址发送到参与该广播域的所有接口。在历史上，访问层的大多数交换机的MAC地址表有大约8000到16000个条目。这是好时默认网关的子网,或聚合层开关上面是默认网关,或只有几个开关都在同一个子网-图5 - 10人左右,也许20如果你有点疯了大的子网。
最近，一些厂商推出了更大的MAC表——例如Broadcom Trident+芯片组支持128k MAC地址。这曾经是您在聚合层中看到的大小，如果它作为每个子网的默认网关，那么它可能必须在多个子网中支持40-50个交换机。
ARP表或IP主机表已经成为新的主要瓶颈之一，尽管Broadcom Trident+芯片支持128k MAC条目，但它只有16000个ARP条目。这听起来可能很多，但让我们评估以下场景:
一家供应商最近描述了它的大型、扁平的L2拓扑，能够支持6000多个端口。16000个ARP条目除以6000个端口，得到每个端口2.6个MAC/IP对。如果我们想将6000个端口放到私有云中，运行平均容量的虚拟机，每个虚拟机有2个vnic，那么需要6000台服务器* 20VMs *2个vnic = 240,000 IP/MAC对。
教训:如果你计划部署一个大型的、平面的L2网络或织物，请检查ARP表的大小和计划消耗。我不打算在这里讨论哪家供应商是最好的还是最差的——只要检查一下，确保你没有把自己弄得到处都是。
新的规模度量#2:缓冲
在过去的16年里，我们不需要过多地讨论缓冲区容量，因为思科在Cat 5000交换机上做得很好。Catalyst 5000每10Mb以太网端口使用192KB的每个端口缓冲内存。它被划分基于7:1的比例在圣ASIC给24KB的输入缓冲区和168KB的传输缓冲区。缓冲区在某种程度上是灵活的，因为缓冲区内存使用一个内存单位大小，以确保没有太多内存被浪费，所以您可以用64B帧或巨型帧填充缓冲区，它们仍然可以得到充分的缓冲。
但时间在流逝，建筑也在变化。输入端口缓冲区逐渐被基于输入的具有fabric仲裁的虚拟输出队列结构所取代。这将把所有拥塞推到入口缓冲区，并进行仲裁，因此直到出口端口能够接收到流量并将其序列化到线路上，流量才会在交换机结构上移动。通过移动所有的拥堵点入口缓冲它变得简捷计算congestion-based时下降,同时,它使您能够检测时提前充塞之前下降——VOQ本质上就是让我们建立一个基于无损的以太网功能在横杆的模块化系统。
通过在入口上处理所有的拥塞，你可以暂停进入的流量，让出口缓冲区在你转发到它之前和在你接受如此多的数据之前消耗时间。
一个问题是，我们很多人都指望QCN能够发挥作用，并被市场广泛接受。看，我们认为QCN可以让我们将拥塞扩散回N个接口，这些接口将为一个拥塞的节点提供数据，我们可以利用分布式缓冲区的聚合优势——因此我们不必再在asic中构建大型缓冲区。由于种种原因，QCN并没有得到广泛的采用，一些人非常害怕它。所以，让我们看看催化剂5000 10Mb端口的缓冲公式，并将其向前扩展……
10 mb = 192 kb
100Mb = 1.92 MB
1000 mb = 19.2 mb
10 gb = 192 mb
我承认，您可以基于VOQ体系结构减少这一点，因此在VOQ系统中，在10Gb的情况下，您可能不需要每个端口有192MB的数据包缓冲区，因为您可以在入口时获得端口的聚合。但是在这个场景中使用的Catalyst 5000至少是24KB的两倍，所以对于基于voq的系统，在每个端口的入口缓冲上应该会看到以下情况:
10 mb = 48 kb
100 mb = 480 kb
1000 mb = 4.8 mb
10 gb = 48 mb
对缓冲区的真正测试是在TCP流量拥塞的情况下它提供“goodput”的效果如何，而不是仅仅测量原始吞吐量。为此，我喜欢拿出我的手带宽延迟产品计算器和断言大多数3-5交换机跳网组成的模块和固定交换机在边缘有平均端到端延迟10usec:
10000000000位/秒。00002s = 2,000,000位* 1字节/8位= 250,000字节
这意味着在10 gb网络与2 - 3开关跳你需要大约250 kb的包缓冲/ TCP流你打算支持如果你声称你需要能够缓冲整个TCP窗口,所以交通拥堵并不创建一个tail-drop重新传输,从而导致整个窗口,这将减少整体的TCP goodput基础设施。
因此，在48MB时，您可以支持192个并发TCP会话，拥有足够的缓冲区容量来处理整个TCP窗口。这与每个端口支持更多数量的vm是一致的。
教训:检查您正在查看的缓冲区大小。对于单开关跳，低延迟网络或多播/UDP，其中流控制不是最重要的一个小缓冲区可能是可以接受的。但是，如果您的应用程序是基于tcp的，那么您需要了解需要支持多少流，以及您的基础设施是否具有处理该数量的缓冲区容量。
所以我考虑增加另一个关于L2拓扑结构可伸缩性使用TRILL或其他此类技术。我现在有点骑墙，因为不同的供应商采用不同的实现路径。我当然知道我讨厌管理一个100交换机的平面网络，我也不确定在颤音环境中is规模的上限，但我不能说今天的实际界限在哪里。
伊凡Pepelnjak在我们昨晚的谈话中我提出了一个很好的观点——你不能在一个vSphere实例中放置超过1000台主机，你不能在一个vNetwork分布式交换机中放置超过300台主机，你不能在一个active DRS组中放置超过32台主机。1000台主机是最大的数量，大多数机架容纳40台1RU服务器[在许多情况下，空间和热限制都超过了这个数字]，很难想象一个实际的需求，大约25个机柜或大约50个开关。
50个开关4xQSFP的上线，每个将是200个40GbE接口或800个10GbE接口，将需要终止在聚合层。这意味着，根据产品的密度支持，您将需要2或3个聚合开关来支持此拓扑。有趣的是，如果您可以用两个交换机支持这种拓扑，那么对TRILL的需求就会被否定，但是我同意，如果您实际的业务/应用程序需求是超过1000台主机或更少的超量订阅，那么您可能需要更广泛的聚合层。(正如你所看到的，这是一个未知的领域，我希望能有一些深思熟虑的意见来确定衡量这一领域的正确方法是什么)。
我不作明确的答复，而是考虑以下方面:
- 在L2拓扑中可以存在多少个开关?[一定要知道拓扑构造协议的限制/边界，而不仅仅是TRILL规范中为rbridge保留的位的数量]
- 在每个聚合框上有多少端口?在我的TRILL/Fabric实现中支持多少多路径?[这将定义子网中可用的聚合端口数量的上限条件]
- 然后一定要检查你的默认网关-确保你可以得到流量的L2网络。理想情况下，默认网关将存在于每个聚合设备上，并且它们将具有ARP规模来处理在这个基础设施中生成的IP/MAC对的数量。
好了，今天的内容可能已经够多了，我确信我遗漏了一些值得作为缩放参数来讨论的东西，这些可以在后续的文章中完成。如果任何人有任何想法，请在评论中或通过我联系我LinkedIn。