在本文中，我们将研究在设备数量显着增加的情况下，传统的L2级别的本地网络合并方法无效的原因，并告诉您在合并位于不同站点的项目的过程中我们能够解决哪些问题。
普通L2电路
随着数据中心中IT基础架构的发展，客户需要将服务器，存储设备，防火墙组合到单个网络中。 为此，Selectel最初建议使用局域网。
本地网络被安排为同一数据中心内的经典“校园”网络，只有访问交换机直接位于服务器的机架中。 接入交换机进一步组合为单个汇聚层交换机。 每个客户都可以为他在数据中心租用或放置的任何设备
订购与本地网络
的连接 。
为了组织局域网，使用专用的访问和聚合交换机，以使Internet网络中的问题不会影响局域网。
下一台服务器位于哪个机架上都没有关系-Selectel将服务器组合到一个本地网络中，无需考虑交换机或服务器的位置。 您可以在需要时
订购服务器 ，该
服务器将连接到本地网络。
当数据中心的大小较小时（不是所有机架都装满），L2的效果很好。 但是随着机架，机架中的服务器，交换机，客户端数量的增加，电路变得更加难以维护。
一个客户端的服务器可以位于多个
数据中心中，以确保容灾能力，或者如果不可能将服务器放置在现有数据中心中（例如，所有机架和所有位置都被占用）。 在多个数据中心之间，也需要连接-本地网络上的服务器之间。
随着数据中心，机架，服务器数量的增加，电路变得更加复杂。 首先，仅使用VLAN技术在聚合交换机级别上完成不同数据中心服务器之间的连接。
但是VLAN标识空间非常有限（4095个VLAN ID）。 因此，对于每个数据中心，您都必须使用自己的VLAN组，这将减少在数据中心之间可以使用的标识符的数量。
L2问题
在使用VLAN的L2级别使用方案时，数据中心中一台服务器的错误操作可能导致其他服务器上的服务提供中断。 最常见的问题包括：
- STP（生成树协议）问题
- 广播风暴的问题
- 多播处理不正确的问题
- 人为因素（链接传输，VLAN传输）
- L2预订组织方面的问题
- 单播流量未知的问题
- MAC地址数量问题
STP的问题通常与客户端服务器或客户端设备的设置有关。 与流行的流量交换点不同，当STP PDU到达时，我们无法完全过滤访问端口上的STP并终止端口。 在STP上，许多网络设备制造商都实现了数据中心交换机的基本功能，例如检测网络中的环路。
如果STP在客户端上无法正常工作，则可能会影响至少一个访问交换机的整个STP域。 使用STP扩展（例如MSTP）也不是解决方案，因为端口，VLAN，交换机的数量通常超过STP协议的体系结构可伸缩性。
广播节目
数据中心中的网络可以建立在不同制造商的设备上。 有时，即使交换机软件版本上的差异也足以使交换机以不同的方式处理STP。 因此，例如，在
Dubrovka 3数据中心中，有280个机架，超过了一个STP域中交换机的最大数量。
随着STP在此类网络中的广泛使用，对任何更改的响应时间（尤其是仅打开或关闭端口）的响应时间将超过所有等待阈值。 您不希望当其中一个客户端打开端口时，您的网络连接消失几分钟吗？
广播流量问题通常是由于服务器上的错误操作（例如，在多个服务器端口之间创建一个网桥）以及服务器上的错误软件配置引起的。 我们尝试用到达网络的广播流量来解决可能的问题。 但是我们可以在一个服务器连接端口上执行此操作，并且如果一台交换机中包含5台服务器，每个服务器未超过设置的阈值，则它们可以共同产生足够的流量以触发对聚合交换机的控制。 根据我们自己的实践，服务器网卡的特定故障可能导致服务器端广播风暴问题。
通过保护整个网络，汇聚交换机将“放置”发生网络异常的端口。 不幸的是，这将导致导致此事件的五台服务器无法运行，以及其他服务器（在数据中心中多达几个机架）无法运行。
多播
多播流量处理不正确的问题是非常特殊的问题，由于服务器上的软件和交换机上的软件操作不正确，因此会导致复杂情况。 例如，Corosync在多台服务器之间以多播模式配置。 通常，小批量交换Hello数据包。 但是在某些情况下，安装了Corosync的服务器可以转发很多数据包。 该卷已经需要对交换机进行特殊配置，或者需要使用正确的处理机制（IGMP连接和其他机制）。 如果机制操作不正确或触发阈值，则可能会有服务中断影响其他客户。 当然，交换机上的客户端越少，发生另一个客户端的问题的可能性就越小。
人为因素是使用网络设备时可能发生的一种无法预料的问题。 当网络管理员一个人呆在他能胜任的工作，记录动作并思考其动作的后果时，发生错误的可能性就很小。 但是，当数据中心运行的设备数量不断增加，员工人数很多，任务很多时，则需要一种完全不同的组织工作的方法。
某些类型的典型动作已自动执行以避免人为错误，但是目前无法自动执行许多类型的动作，或者此类动作的自动化成本过高。 例如，在配线架上物理切换跳线，连接新链接，替换现有链接。 一切与与SCS进行物理接触有关。 是的，有些配线架可以进行远程切换，但是它们非常昂贵，需要大量准备工作并且功能非常有限。
如果需要，没有自动配线架会铺设新电缆。 在配置交换机或路由器时，您可能会犯错。 输入数值时，请指出错误的端口号，VLAN号，并加以密封。 指定任何其他设置时，请不要考虑它们对现有配置的影响。 随着方案的复杂性增加，冗余方案变得复杂（例如，由于当前方案达到缩放极限），人为错误的可能性增加。 无论设备是处于配置阶段，服务器，交换机，路由器还是某种转接设备，任何人都可能会犯人为错误。
乍一看，在L2上组织冗余对于小型网络而言似乎是一项简单的任务。 Cisco ICND课程涵盖了将STP用作最初旨在提供L2冗余的协议的基础知识。 STP有很多限制，在此协议中称为“按设计”。 我们一定不要忘记，任何STP域的“宽度”都非常有限，也就是说，与数据中心中机架的数量相比，一个STP域中的设备数量非常少。 原始版本的STP协议将链路分为已使用和备用链路，在正常运行期间无法提供对上行链路的完全利用。
使用其他L2保留协议有其局限性。 例如，ERPS（以太网环保护交换）-用于所使用的物理拓扑，用于一台设备上的环数，用于所有链路的利用率。 通常，使用其他协议会涉及不同制造商的专有更改，或者将网络建设限制为一种选定的技术（例如，使用Avaya设备的TRILL / SPBm工厂）。
未知单播
我尤其要强调单播流量未知的问题的子类型。 这是什么 通过L3发往特定IP地址但通过L2在网络上广播的流量，即，该流量将传输到属于此VLAN的所有端口。 例如，当收到未占用的IP地址的DDoS时，可能会由于多种原因而出现这种情况。 或者，如果在服务器配置中出现输入错误，则将网络上不存在的地址指定为备份，并且在服务器上，此地址历来都是静态ARP记录。 当存在ARP表中的所有条目，但在转接交换机的交换表中缺少接收者的MAC地址时，就会出现未知单播。
例如，具有给定地址的网络主机所在的端口通常处于关闭状态。 这种流量受转接交换机的限制，通常以与广播或多播相同的方式提供服务。 但是与它们不同的是，未知单播流量可以“从Internet”发起，而不仅仅是从客户端网络发起。 当边界路由器上的过滤规则允许从外部欺骗IP地址时，未知单播流量的风险尤其高。
甚至纯粹的MAC地址数量有时也可能是一个问题。 看起来，如果数据中心的大小为200个机架，每个机架40个服务器，则MAC地址的数量不太可能大大超过数据中心中的服务器数量。 但是，这不再是正确的说法，因为可以在服务器上启动一个虚拟化系统，并且每个虚拟机都可以由其MAC地址表示，甚至可以由多个MAC地址表示（例如，在虚拟机中模拟多个网卡时）。 总共，我们可以从40台服务器中的一个机架中获得数千个合法的MAC地址。
如此多的MAC地址可能会影响某些交换机型号上的交换表的完整性。 另外，对于某些交换机模型，在填写交换表时，会使用散列，并且某些MAC地址可能会导致散列冲突，从而导致出现未知单播流量。 在租用服务器上以每秒4,000个地址的速度随机搜索MAC地址可能会导致交换表在访问交换机上溢出。 交换机自然会对在交换机端口上可以学习的MAC地址数量施加限制，但是根据此机制的具体实现，可以用不同的方式解释数据。
同样，将流量发送到通过此机制过滤的MAC地址会导致出现未知单播流量。 在这种情况下最不愉快的是，在交换台溢出的情况下，制造商很少对开关进行自愈测试。 该表的单个溢出（例如，由于一个客户端在hping参数中的错误或编写监视其基础结构的脚本而导致的溢出）可能导致交换机重启并中断机架中所有服务器的通信。 如果在聚合级别交换机上发生此类溢出，则重新启动交换机可能会导致整个数据中心的本地网络停机15分钟。
我想表达的是，仅在有限的情况下使用L2是合理的，并且施加了许多限制。 段的大小，L2段的数量-这些是每次您添加具有L2连接性的新VLAN时必须评估的所有参数。 L2网段越小，网络运行越简单，结果越可靠。
典型的L2用例
如前所述，随着一个数据中心基础设施的逐步发展，使用了L2本地网络。 不幸的是，这种使用也隐含在另一个数据中心或其他技术（例如，云中的虚拟机）中的项目开发中。
链接前端和后端，备份
通常，使用局域网首先要分离前端和后端服务的功能，然后将DBMS分配给单独的服务器（以提高性能，以将应用程序服务器和DBMS上的OS类型分开）。 最初，出于这些目的使用L2似乎是合理的，在该段中只有几个服务器，通常它们甚至位于同一机架中。
服务器包含在一个VLAN中，一台或几台交换机中。 随着设备数量的增加，数据中心新机架的交换机中包含了越来越多的新服务器，L2域的宽度开始从中增长。
出现新服务器，包括备份数据库服务器，备份服务器等。 只要项目位于一个数据中心，通常就不会出现扩展问题。 应用程序开发人员只是习惯了这样一个事实，即在本地网络上的下一台服务器上，IP地址仅在最后一个八位位组中发生更改，并且您无需编写任何单独的路由规则。
当项目扩展，以下服务器已经在另一个数据中心中租用或项目的某些部分移至
云中的虚拟机时，要求开发人员采用类似的方案。 在图片中，一切看起来都非常简单和美观：
似乎您只需要将DC1和DC2中的两个聚合交换机与一个VLAN连接即可。 但是，此简单操作的背后是什么？
资源预留
首先，我们增加了L2域的宽度，因此DC1的所有潜在问题都可能出现在DC2中。 谁会喜欢他的服务器位于DC2中，并且由于DC1内部的错误操作而发生与本地网络不可访问性有关的事件？
其次，您需要注意备份此VLAN。 每个数据中心中的聚合交换机都是故障点。 数据中心之间的电缆是另一个故障点。 每个故障点都应保留。 两个汇聚交换机，从汇聚交换机到接入交换机的两根电缆，数据中心之间的两根电缆……每当组件数量增加，电路就会变得更加复杂。
该方案的复杂性是由于需要保留系统中的每个元素而引起的。 对于设备和链接的完整备份，您需要复制几乎每个元素。 在如此大的网络上，不再可以使用STP来组织备份。 可以将所有网络元素（尤其是接入交换机）作为MPLS云的组件呈现，然后由于MPLS协议的功能而获得了冗余。
但是，MPLS设备通常比非MPLS设备贵两倍。 应当指出的是，1U中的MPU交换机具有良好的可扩展性，实际上直到最近才在控制平面中实现完整的MPLS功能。 结果，我想摆脱或最小化L2问题对现有网络的影响，但同时保持保留资源的能力。
过渡到L3
如果网络中的每个链路都表示为一个单独的IP段，而每个设备都表示为一个单独的路由器，则我们不需要L2级别的冗余。 链路和路由器冗余通过动态路由协议和网络中的路由冗余来确保。
在数据中心内部，我们可以通过L2相互保存现有的服务器交互方案，而通过L3访问另一个数据中心中的服务器。
因此，数据中心通过L3连接性互连。 也就是说，它被模拟为在数据中心之间安装了一个路由器（实际上，有几个用于备份）。 这使您可以在数据中心之间拆分L2域，在每个数据中心中使用自己的VLAN，并在它们之间进行通信。 对于每个客户端，您可以使用IP地址的重复范围，网络彼此完全隔离，并且您不能从一个客户端的网络进入另一个客户端的网络（除非两个客户端都同意这种连接）。
我们建议您将10.0.0.0/8寻址中的IP网段用于本地网络。 对于第一个数据中心，网络将是例如10.0.1.0/24，对于第二个数据中心-10.0.2.0/24。 路由器上的Selectel规定了该子网的IP地址。 通常，.250-.254地址是为Selectel网络设备保留的，而.254地址用作通往其他LAN的网关。 该路由已分配给所有数据中心中的所有设备：
route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254其中x是数据中心编号。 由于此路由，数据中心中的服务器通过路由彼此“看到”。
在例如第三数据中心的出现的情况下，这种路由的存在简化了方案的扩展。 然后，对于第三个数据中心中的服务器，将下一个范围10.0.3.0/24的IP地址注册到路由器上，即地址10.0.3.254。
这种方案的实施的显着特征是，在数据中心或外部通信通道发生故障的情况下，不需要额外的保留。 因此，例如，如果数据中心1发生故障，则数据中心2和数据中心3之间的连接将完全保留，并且当通过其中一个数据中心之间的L2馈送实施该方案时，如图所示：
数据中心2和数据中心3之间的连接取决于数据中心1的效率。或者，需要附加链路的组织和复杂L2预留方案的使用。 而且，尽管保留了L2方案，但整个网络仍然对错误的交换，交换环路的形成，各种流量风暴和其他麻烦非常敏感。
项目内的L3段
除了在不同的数据中心中使用不同的L3网段外，还应为通常使用不同技术制造的不同项目中的服务器分配单独的L3网络。 例如，数据中心中的硬件服务器在一个IP子网中，虚拟服务器在同一数据中心中，但在VMware云中，在另一个IP子网中，一些暂存相关的服务器在第三个IP子网中。 然后，这些网段之一中的随机错误不会导致本地网络中包含的所有服务器完全故障。
路由器预约
这一切都令人印象深刻，但是项目之间存在单点故障-这就是路由器。 在这种情况下该怎么办？ 实际上，路由器并不孤单。 为每个数据中心分配了两个路由器，并为每个客户使用VRRP协议形成了虚拟IP .254。
在两个具有相同L2网段的相邻设备之间使用VRRP是合理的。 对于地理分布的数据中心，使用不同的路由器，并在它们之间组织MPLS。 因此，以这种方式连接到本地网络的每个客户端都连接到在这些MPLS路由器上为其创建的单独的L3VPN。 与现实近似的方案如下所示：
每个.254段的网关地址由VRRP在两个路由器之间保留。
结论
总结以上所有内容，将本地网络的类型从L2更改为L3，我们可以保持扩展能力，提高可靠性和容错能力，还可以实现其他冗余方案。 此外，这规避了L2的现有限制和“陷阱”。
随着项目和数据中心的发展，现有的标准解决方案已达到可扩展性的极限。 这意味着它们不再适合有效地解决问题。 整个系统对可靠性和稳定性的要求不断提高，这反过来又影响了规划过程。 重要的是要考虑到这样一个事实，即应考虑乐观的增长预测，以便将来没有无法扩展的系统。
告诉我们-您已经在使用L3VPN吗？ 在评论中见。