一文梳理新一代云化园区网络建设方案-运维篇（2023版）
从运维需求的传递链条来看，云网络和园区网络也高度相似。首先，租户（用户）的业务开通/变更申请会提交至管理平台（运维部门），管理平台（运维部门）分解任务后，下发给网络控制器（网络运维人员），由他们完成具体网络配置并将结果反馈给需求方。当然，云网络中依靠网络控制器和REST API接口早已实现了自动化运维，而传统园区大多还停留在依靠网络管理员和手工配置网络设备的“人肉运维”阶段。
如今，在云化园区网络架构下，我们将有机会把云中广泛使用的，面向未来的软件编程、自动化、NetDevOps等先进技术和理念应用到园区场景，在网络运维方面大大解放生产力，提高效率！
集中控制器与分布式路由/转发
与云网络类似，云化的园区网络架构采用了“集中控制器+分布式路由+分布式转发”的整体结构，具体如下图所示：
集中控制器+分布式路由+分布式转发
在云化园区网络中：
- 网络管理员对网络的配置通过具备图形化界面的网络控制器统一进行，无需再通过命令行逐台设备地进行，网络控制器在定位和功能设计方面超越了传统的集中网管系统，除了能够完成基础的配置管理功能，还可以将网络管理员的意图转换为对网络中每一台网络设备的配置，并且实时收集、分析和呈现网络的运行状态，帮助网络管理员避免繁重的配置运维工作、降低引入人为错误的风险、快速预警风险和定位故障；
- 在基于OpenFlow的SDN模型中，所有的路由学习与计算能力是集中式的部署在网络控制器上的，网络设备只需要接受来自网络控制器下发的转发表、按照转发表完成转发动作即可。在云化园区网络中则不同，网络的路由学习计算功能分布式地部署在所有的网络设备之上，借助IP网络成熟高效的路由算法，智能学习、动态传播、快速同步整网的路由信息，充分利用了每台网络设备的计算能力，并且有效地规避了网络控制器单点故障带来的风险；
- 与分布式路由相对应的，则是所有网络流量在所有网络设备上的分布式转发，无需在某些特殊情况下将流量集中到网络控制器上做集中转发，对于无法转发的错误流量，网络设备将直接丢弃，这一点也从根本上解决了OpenFlow SDN模型性能低、可靠性低的问题。
开放的编程接口
借助于开放网络操作系统的软件编程接口能力，在云化园区网络中，各种网络业务与应用可以通过软件编程的方式自动、按需地调度网络，网络管理员甚至可以开发自有的网络应用以满足各种业务和应用的需求，让“应用定义网络”成为现实。
开放的编程接口
上图，以星融元的开放网络操作系统AsterNOS为例说明了如上的概念。AsterNOS SDK所提供的面向机器的软件编程接口使得在各种环境中对网络进行软件定义成为可能。在运行着AsterNOS的网络中，使用者除了使用传统的命令行、WebUI对网络进行基础的运维之外，还可以通过AsterNOS SDK所提供的REST API和/或System API自动化地、高效地运维网络，甚至为自己的网络开发新的应用。
分层简化配置
传统园区网络中，往往是“一个设备、一个配置”，即每一台网络设备的配置都是不同的。对于较大规模、结构复杂的网络来说，网络配置和配置的维护、变更是网络管理员所面临的巨大挑战之一，面对复杂的网络结构、众多的网络设备、多个版本的网络配置文件，稍有不慎就会因为错误配置引发网络故障。
分层简化配置
云化园区网络架构追求极简的另一个有力例证就是将网络设备的配置改进为“一层设备、一个配置”。简单来说，通过创新的设计，云化园区网络架构彻底规避了“同层设备、配置不同”的问题，在一个二级三层的Clos网络中，无论有几十台还是上百台网络设备，只需要维护三个网络配置即可，同层设备在配置方面的差异性，完全通过软件设计上的创新和初始配置的自动化屏蔽了。在云化园区网络中，网络配置的数量不再被网络设备的总数量所决定，而是只跟网络的层数相关，将配置管理工作带给网络运维的复杂度降低了2-3个数量级，帮助网络的拥有者大幅度降低运维的综合成本。
零配置部署
进一步的，云化园区网络架构引入了在服务器、云网络运维体系中广泛使用的零配置部署机制。
零配置部署
在零配置部署机制中：
- 网络管理员在管理服务器上部署文件传输系统的服务器端，并将网络操作系统镜像和按照规划生成的网络配置管理文件存放在指定目录下；
- 云化园区网络的每台交换机上都运行着开源软件ONIE（Open Network Install Environment，开放网络安装环境），ONIE在交换机加电开机时自动运行并连接到管理服务器，按照预先设置的规则申请特定的网络操作系统镜像和对应的配置文件；
- 管理服务器将系统镜像和配置文件传送到交换机后，交换机将自动加载新获得的网络操作系统镜像，并根据配置文件完成系统的初始配置；
- 以上申请、加载、配置的过程均不需要网络管理员介入，完全自动化地完成，试想，对于一个有着成百上千台交换机的网络来说，零配置部署机制对网络升级、变更所带来的效率提升是非常可观的。
NetDevOps
DevOps（Development and Operations，开发运营）是一种新型的产品交付与运营模型，它将与产品生命周期和业务运营过程中的各个相关环节（例如研发、测试、部署、运营等）以一种空前的方法连接了起来。DevOps对应到开放网络世界中，就是NetDevOps。
云化园区网络架构天然地支持NetDevOps。下面，基于星融元的AsterNOS及其SDK、REST API，围绕一个安全运维场景来说明云化园区网络如何支持NetDevOps。
一个NetDevOps的示例
如上图所示，出于对安全的考虑，网络运维人员往往需要对重要的应用系统进行访问情况的审计与分析；针对这些应用系统，如果发生了访问控制的缺失、访问状况的异常，管理员希望第一时间得到通知，以便采取相应的动作。这些审计与分析的内容可能包括：网络对重要应用系统的访问是否进行了控制（以便判定该应用系统是否被保护）、对这些重要应用的访问情况是否发生了突然的变化（以便判定该应用系统是否处于可能的攻击中）等。
下面，我们就来看看通过AsterNOS SDK如何便捷、高效地实现这一需求。在网络中，访问控制一般是通过ACL（Access Control List，访问控制列表）实现的。
AsterNOS支持ACL功能，并且能够提供所有ACL被命中过的统计数据；AsterNOS SDK所提供的REST API中，包含对ACL各个字段和统计数据的访问接口，通过调用这些接口，即可直接获得ACL的这些信息用以分析。具体思路如下：
- 重要的应用系统可以用IP地址来标识（如果需要更精确地定义，还可以增加该应用所使用的TCP/UDP端口信息）；
- 通过调用REST API，获得AsterNOS中当前配置的所有ACL的“目的IP地址”字段，以便判断所定义的重要应用系统是否被ACL进行访问控制；
- 通过调用REST API，获得对这些重要应用系统的访问量的统计信息，以便判断是否出现异常状况；
- 对于出现的访问控制缺失或访问异常状况，该程序自动通知管理员进行干预。
假设运行着AsterNOS的网络设备的管理接口IP地址和端口为192.168.1.200:4430，则上述思路的示意性伪代码可以如下：
这段伪代码仅用于示意，并未严格地写出循环、边界条件判断、具体日志与告警实现等。其中，“GET https://192.168.1.200:4430/rest/v3/acl/…”即AsterNOS SDK中获取ACL及其具体信息的REST API，“TABLE_y:RULEz:”dst_ip””和“TABLE_y:RULEz:“stats””即一条ACL的“目的IP地址字段”和“该ACL的命中数量统计”。需要强调的是，编程者通过AsterNOS SDK的REST API获得的已经是ACL的每一个具体字段及其值，无需再使用复杂的文本解析程序进行处理。
将这段非常简单的程序用Docker进行容器化封装，部署在AsterNOS中，并且自动化地定时运行，即可实现前文所述的运维需求，并且，通过对更多ACL字段与值的调用，即可实现更高级的运维功能。
总结：新思路、新架构、新网络
云计算掀起数据中心网络的变革热潮，而随着中大型园区网络规模的进一步扩增，传统园区网络面临着运维复杂、扩展性差、架构封闭等诸多挑战，借鉴云数据中心网络的发展经验，星融元Asterfusion创新性地提出了新一代精简高效的云化园区网络架构。
我们可以看到基于开放网络架构的新一代云化园区网络的确会在方方面面为园区网络带来改变。总结来看，这些改变主要包括：
- 全新的网络规划思路：采用领先的开放网络理念，基于最新的数据中心级网络技术、开放的网络操作系统，“一网多用”地构建出能够同时承载多种业务的超大规模园区网络；
- 全新的网络建设架构：抛弃传统园区网络架构所背负的历史包袱，通过纯三层网络、统一路由结构、天然无环、去堆叠、自主内生安全等创新的技术，建设架构极简、更可靠、更安全、更高性能新一代园区网络；
- 全新的高效运维体系：将开放网络的集中控制器、软件可编程引入到园区网络的运维系统中以有效支持NetDevOps，同时通过简化配置、自动部署等创新性设计大幅度提升网络运维的效率。
所有这些改变，都将带给园区网络的拥有者和运营者最直接的价值：降低网络建设的成本，提升网络运营的效率，支撑无限创新的可能！
