思科ACI撼动了SDN

　　思科高可扩展性的数据中心网络架构为我们带来了惊喜：一款完全开放的API。

　　软件定义的网络的承诺——即通过集中的、软件驱动的控制，实现更简单、更灵活的网络操作其实已经实实在在的为我们服务了好几年了。虽然像许多其他新的概念一样，由于各种营销团队的大肆行销和鼓吹使得其缺乏一个统一的定义，造成其遭受了各种的误解和混乱。但在众多不同的定义之外，我们也看到了一系列不同的方法，其中OpenFlow模型从一开始就一路领先。

　　而思科则采用了另一种方式来开发SDN。思科的以应用为中心的基础架构 (ACI)是与OpenFlow的方法不一样的一种SDN解决方案。正因为如此，其偏离了原来的OpenDaylight SDN项目的方向，而思科曾经是该项目的创始成员。当然，思科仍将继续在OpenDaylight项目计划中扮演相当重要的角色，但显然他们会更偏向于自己的ACI技术。

　　ACI使用OpFlex与网络设备进行通信，这是思科的操作控制协议，而非OpenFlow，其同时也是OpenDaylight的标准。关键的区别就在于，OpFlex是在网络中，而非在控制器进行实际的网络配置决策。控制器抽象更高级别的配置来代替。您可以将其想象成是由控制器告诉架构应该执行什么工作，而不是如何去做。该架构负责执行控制器的说明指示，并汇报成功或失败。

　　思科表示这种方法规模化的程度要比OpenFlow更好，其依赖于控制器执行网络配置的任务。还允许用户通过一个更高级别的策略模型，并根据应用程序的需求来配置网络，而无需担心底层的配置细节。思科的OpFlex代理支持来自微软、IBM、F5、思杰、红帽和Canonical等等的承诺，并提出将OpFlex作为一项IETF标准，作为OpenDaylight的一部分。

　　虽然ACI的SDN内部可能与OpFlex而非OpenFlow进行兼容操作，但这肯定不是传统的网络。其也标志了思科希望走向更加开放的集成，A​​CI的建立是围绕着一个完整的RESTful API，并在很大程度上依赖于Python编程语言，提供了一个开源SDK和工具，并已经公开发布在GitHub上了。

　　具体细节

　　ACI是专为大型数据中心的网络设计的。其是基于思科Nexus交换机架构，在脊/叶布局(spine/leaf layout)具有10G、40G、100G的连通性。一款fabric架构可以小到几个节点或大到五个脊，200叶和180000个端点——思科目前已配置在其实验室中运行。 ACI是为了承载重荷工作。　　

　　思科实验室的大规模ACI基础设施拓扑结构概述，具有五脊和200多叶。

　　ACI也意味着重塑数据中心网络的概念，引入一个模型，本质上是L2和L3独立的，而不是使用租户的概念来划分流量固有的应用程序和服务到逻辑分组，同时在这些分组外使用VXLAN。这意味着您可以在多个不同的租户使用相同的IP子网、VLAN、甚至MAC地址，而不发生任何冲突。在基础设施中的每个租户存在于其自己的逻辑岛，而且每个租户可以托管应用程序，划分为不同的层，或逻辑端点组(EPG)。EPG之间的通信在ACI中通过分层策略控制。

　　EPG不是服务器或虚拟机，但本质上子网包含这些资源。这些子网可以被分配到VLAN配置在裸机服务器物理交换端口或hypervisors管理程序的虚拟交换机内。它们被设计为包含针对特定服务器实例类型的流量，例如Web服务器或数据库服务器。

　　例如，我们可能有一个租户，去可能是一个商业集团，也可能是一个金融集团。我们可以使用ACI定义一款应用程序并创建EPG，将包含不同层的应用程序堆栈——Web、应用程序和数据库。我们为EPG定义了一个子网和VLAN，指定其将连接到的资源，如哪些VMware vSphere集群或域。ACI在需要的地方执行所有的工作来创建网络对象，如在vSphere基础设施的虚拟分布式交换机以及在Nexus fabric本身。一旦我们租户的EPG创建完毕，虚拟机或裸机的资源就可以打开，并分配给这些网络。

 

　　然而，我们也需要明确地启用这些EPG之间的通信，甚至在同一EPG内的主机之间的通信。在我们的一个三层应用程序的例子中，我们可能需要允许流量在一个特定的TCP端口从Web服务器EPG传输到应用程序的EPG，而数据库的流量从应用程序EPG传输到数据库的EPG。我们使用一个被称为合同的概念来实现，一套在EPG之间简单适用的规则，规定了怎样的流量被允许在驻留在这些EPG上的主机之间传输。我们也可以让这里的规定适用于外部设备，如防火墙和负载均衡器。除了思科自己的解决方案，ACI还可以与多家第三方供应商的L4至L7的设备集成，如来自F5、思杰和帕洛阿尔托网络的设备。　　

　　一个包含了端点组的三层应用程序，以及适用于它们之间的流量合同的详细视图。

　　然后，我们可以清理和重复每一个租户所需的每一款应用程序，我们在租户定义中定义的一切都将包含在该租户的保护伞之下。我们可以在其他租户之间有重复的子网，重复的VLAN，甚至重复的MAC地址，而不会发生冲突。此外，我们可以让EPG共享相同的子网或超级网络，并仍旧在主机之间执行流量规则。因此，我们的三层应用程序可以有连续IP地址的网络、应用程序和数据库服务器，而我们的流量管理合同仍然适用。

　　租户可能是企业集团，比如在我们的例子中，或客户在主机托管或服务环境，或者只是最适合部署逻辑分组的集合。由于每个租户都是在自己的筒仓内存在，在网络层不会与其他租户重叠。这就是说，有一些特殊领域可用于向多个租户分发共同服务。这些服务可能是DNS、NTP和被所有租户使用的目录服务。

　　所有这些后端配置都是由ACI控制器处理，称为应用策略基础架构控制器(Application Policy Infrastructure Controllers，APICs)。这些都是在一个集群中运行的物理服务器，用于负载平衡和冗余的目的。一般来说，每个ACI fabric您将至少有三个APICs。

　　APICs在数据路径之外，他们不是fabric功能所必需的。如果没有可用的APICs，ACI fabric将继续正常运行，但不能做任何更改。APICs为fabric提供配置，提供管理Web UI，及托管ACI围绕建立的RESTful API。任何一个APICs都可以服务Web UI或API的请求，而其功能与其他控制器相呼应。ACI的配置和状态数据存储在控制器的SQLite并能够跨控制器集群共享。　　

　　运行在思科实验室的大型ACI基础设施容量仪表板图。请注意，运营商已经超过其规定的三类限制。

　　ACI fabric使得所有基于上面图表的流量决策保持在fabric本身，无论是在本地端点的叶还是在fabric的剩余部分的脊。针对线上的每个数据包，fabric都会根据这些规则做出将其发送到何处的决策，并以线速执行。这便是ACI如何规避传统的IP子网和VLAN的边界，以及东西走向的流量可以通过合同的配置控制的原因了，即使是在同一个子网中的主机之间。

 

　　此外，这种设计消除了对于地址解析协议(ARP)和broadcast flooding的需要，所以流量被默认撤销了——fabric已经知道每一个端点的位置。如果所需的是特定的应用程序，就会在桥域级别有允许ARP 和broadcast flooding的规定。

　　在一个较高的水平，这就是ACI了——其是建立和维持一个网络fabric架构的方法，省去了传统网络的概念和方法，以非常大的规模提供了重要的软件控制、自动化和线速的交换机。

　　构建fabric

　　实施ACI非常简单，甚至是在大规模的建设的情况下。最繁琐的部分是布线，但这是任何fabric结构典型的特点。在ACI环境下采用Nexus 9000系列交换机运行一款修改后的被称为iNXOS的操作系统，具备ACI管理所要求的hooks脚本功能。　　

　　一个具备三个APICs，四个节点，两个脊的ACI fabric架构的拓扑图。

　　一旦您的Nexus脊和叶进行了正确的连接，通过叶连接到多个脊，然后脊又彼此连接，您就可以连接和启动APIC服务器，这是建立在思科UCS 1U服务器硬件上的。如果当前的服务器是APIC集群的第一个成员，该APIC启动到一个非常简单的命令行(CLI)配置脚本，要求基本的IP子网和名称信息。

　　第一个APIC控制器开始自动发现fabric的其余部分。这种情况发生得很快，甚至是在大规模的fabric上。一旦自动发现完成，ACI的Web UI显示整个fabric的逻辑布局，以及可以配置的解决方案。与此同时，其他APIC控制器可以被启动，并通过初始安装脚本分配IP地址。然后，他们将自动加入APIC集群。

　　假设布线完成后，ACI fabric从开始到结束的整个过程可能只需要几分钟的时间。加上第三方元件如负载平衡器和防火墙，一款功能性fabric可通过Web UI或API来完成。

　　配置与管理

　　这是ACI所带来的一些真正的惊喜。ACI的每一部分都可以通过RESTful API来控制。事实上，思科ACI客户不使用CLI或Web UI管理工具，而是仅用API完全照本宣科即可。此外，思科还发布了一个完整的Python SDK，使脚本ACI直截了当。

　　这应该是非常清楚的：这不是一个扣在提供的管理工具上的API，或并排运行的解决方案。API是管理工具。CLI 与Web UI均需使用API以执行每一项任务。事实上，从CLI到ACI对于思科管理员都非常熟悉，都具备通常的IOS权限和配置模式，而其只是一个使用API 的Python脚本。

　　如果您企业参与了开源社区和现代开发社区，这似乎没什么大不了的，但对思科而言，这是一个非常重要的一步。不仅是ACI成为了非常开放的架构，同时也意味着思科正在积极通过服务客户及为其他感兴趣的ACI维护代码而做出贡献。思科的GitHub的资源库包含了大量非思科雇用的开发人员所提交的资源。思科正在积极支持各地ACI社区聚会，而该社区也已经收获了思科的开放姿态所带来的回报。这是思科迈出的一大步，并为ACI带来了一个非常正面的立场。

　　使用SDK，一个Python脚本实现一个新租户的基本功能可能只有几行代码。Python的方法是精心布置、易于理解的。此外，思科还参考APIC的Web UI内置了整个API和SDK，所以他们很容易被发现。思科公司也已经在ACI Web UI内置了非常便利的开发工具。例如，有一款对象浏览器，允许开发人员通过ACI基础设施搜索和查看任何对象的所有要素，以便在脚本中使用。　　

　　此示例中的Python代码将通过Python SDK在 ACI创建一个租户。该代码是通过思科维护的一个开放源码的Python脚本传递的一个JSON对象编程生成的。

　　另一款工具，称为ACI Inspector，本质上是一种对所有进入ACI API请求的现场调试。因此，您可以打开这款工具，看看被发送到API的到底是什么请求，并能够很容易地在其他地方复制它们的代码。此外，您可以剥离API并夺取通过的JSON。然后，使用一款称为arya的工具，该工具在GitHub上的ACI工具包可找到，您可以将JSON数据合并到Python代码的功能，使用Python SDK重新创建事件。因此，您可以在用户界面中执行一个操作，并且在几分钟内就可以重新创建这个动作的功能脚本。

　　这是ACI的开放性，脚本易编写的一个例子。其结果将是其将直截了当的被直接集成到自定义的ACI自动化和管理解决方案，如集中的管理工具和自助服务门户网站。

　　故障排除与维护

　　ACI的政策驱动的性质似乎对某些网络管理员有点过于放手。有了这么多的实际网络配置抽象出来，并隐藏在fabric中，问题检测和故障排除工具变得非常重要。　　

　　对象健康的概念是在整个ACI存在的。当检测到问题时，一个对象的健康评分从100下降，得分越低说明问题越严重。这是分层的，因此，虽然在一个单一端点的一个被断开的端口会显示健康评分为0，包含该端口的fabric的健康评分可能显示50，而包含下行端点上的应用程序则可能显示得分为​​80。这可以通过Web UI选择受影响的应用程序来进行健康视觉跟踪。这使得非常容易在一个巨大的fabric中查明问题。　　

　　ACI仪表盘显示的ACI基础设施健康统计一览

　　ACI提供了一些工具，帮助问题的检测，并在Web UI中的操作部分进行解决。从这里您可以通过应用程序和IP地址在fabric选择两个端点，ACI会告诉您他们是如何通过数据包遍历识别叶和脊跨fabric连接的。

　　ACI甚至提供了一种回到过去的方法，看看哪里出现故障或问题可能已经开始。此操作在一个令人惊讶的低水平，其可能在fabric中选择几个对象，显示过去的几个小时数据包级别流量相关的对象的细节。ACI在fabric中为所有对象存储，默认时间为240分钟，但数据可以保留长达24小时。此外，如果需要较长时间的数据，您可以导出统计数据。这个工具在故障排除工作时被证明是非常有用的。　　

　　使用的应用程序的显示健康来定位问题的根源。在这种情况下，是一个在node-101/eth1/3的下行链路。

　　还有交换机端口分析器(SPAN)和封装的远程SPAN(ERSPAN)功能，可用于两个端点或fabric对象之间的所有流量，指示到fabric在别处的端口上。因此，在该端口的一个服务器监听可以通过识别SPAN配置捕捉到跨所有流量。在一个大的fabric，这种方法使得跟踪数据包级别的问题远比传统的方法简单得多。

　　与大多数思科网络产品一样，ACI的配置可以浓缩成一个JSON或XML文件进行备份，并定期上传到服务器。同样，每个独立的租户配置可以独立备份和重新导入。此方法可用于导出/导入全部租户配置，可在其它地方修改，所以模板创建和导入文件一样简单。

　　就维修保养而言，固件升级到fabric硬件可以进行自动安排和管理，而不需要影响生产系统(假设所有端点有多个冗余路径到fabric)。这种方法可以显着地减少执行大的fabric所需的时间和精力。

　　外部整合

　　ACI管理虚拟化平台的网络功能，如Hyper-V，Xen和VMware，但不能管理虚拟机或提供服务器。为了实现了一个软件驱动的数据中心，ACI可以与其他解决方案整合，提供更完整的业务流程解决方案。

　　利用RESTful API，ACI可与业务流程和管理解决方案，如VMware的vRealize Orchestrator和vRealize Automation进行整合。以便在每一个层面实现自动化服务部署。这包括配置虚拟服务器，存储，网络，以及资源的控制，资源成本，自动扣款，自动淘汰等等，管理虚拟机资源以及配置fabric。　　

　　通过与vCenter集成整合，ACI可以在一个VMware vSphere集群管理分布式交换机。

　　当然，ACI可以与思科统一计算系统(UCS)集成整合。结合ACI和UCS基础设施，可以自动完成整个数据中心，采用了虚拟机和裸机服务器配置的UCS控制，并借鉴UCS Director与ACI API的整合以便于动态网络fabric结构配置。

　　也有使用ACI管理扩展与微软的系统中心虚拟机管理器和Azure Pack集成整合的可能性。

　　思科ACI是一款强大的解决方案，是专为大规模部署服务的。这是设计和规模从传统网络迈出的重要的一步，更是思科网络管理朝着开放和现代的API控制结构迈进的重要一步。

　　ACI也代表着从OpenDaylight SDN项目方向的一个偏离，其带来了一个面向应用程序策略的模型和替代OpFlex的一项控制协议。思科及其客户究竟能够推动ACI走多远，尚有待时间的检验。