【IT168 技术】思科ACI架构从2013年底被提出到现在，走过了2个年头。选择它的客户已经近2000家，其中选择其Nexus 9000系列的客户有1700家，选择了ACI核心应用策略基础中心APIC的用户，根据思科最新透露的数据已经有近500家。而且ACI的每次技术演进总能牵动产业的神经，即便是这样，ACI的潜在价值还不为大多数用户所知晓，尤其是中国用户。近期IT168发表了关于思科ACI的系列文章《ACI是SDN技术吗?》，这篇文章解读了思科ACI对ONF白皮书《软件定义网络：网络新常态》中所提及的SDN诸多挑战的理解，以及详细剖析了思科各部分组件如ACI Fabric、APIC(应用策略控制器)，GBP(组策略模型)等组件的实现方法和功能。

　　但ACI真如文章所阐述的那样，完全可以满足SDN目前所有的需求?以及ACI如何做到后发先至?与其他SDN架构相比，ACI自身的优势如何体现?ACI构建之初的逻辑是怎样的?等等话题，IT168独家对话了思科大中华区首席解决方案架构师马元骐和思科大中华区数据中心交换机产品线产品总监李少杰。

　　打破网络架构底层的束缚

　　在网络基础协议，以及架构形成的过程中，有许多有趣的事情。比如早期的以太网等标准，在其诞生之初并没有被业界广泛认可，马元骐谈到，“当初最不被看好的，反而衍伸为最后被广泛使用的标准，从而造成了网络技术发展中产生了许多问题的来源。”这隐含的意思，就是在传统网络架构中，基于物理设备、固定IP、VLAN域等已经驾轻就熟的功能和手段，当面临云、虚拟化的时候，反而使得网络成为了制约其发展的因素。

　　在ONF的白皮书中也做了这样的阐述，如丰富的网络协议和功能显著提高了网络复杂性，VLAN的隔离策略，降低了业务变更的灵活性;而当虚拟机发生迁移的时候，在当前网络需要跨数百或数千网络设备手动配置安全和服务质量(QoS)策略，工程繁杂，而且手工配置容易出错;当新业务需求来时，要对网络架构进行扩展则意味着对端点、服务和带宽等等大量的规划和重新设计。

　　满足云环境的基础架构要更加灵活、弹性、规模扩展上更加简单。马元骐认为“SDN诞生之初，公认的是在广域网中去调配路由的分配，而经过这些年的发展，SDN依然没有形成在数据中心中比较理想的实现模型。”马元骐在判断目前SDN还不够完善的同时，也隐约解释了思科ACI后发的原因。因为要将已经广泛使用的以太网、TCP/IP等技术标准打破，需要更多的思考。

　　所以思科希望将基础架构，尤其是网络底层的限制打破，特别是还要保证以太网、TCP/IP等逻辑还在。只是当网络对业务商业化实现造成困扰时间，将它们打破。他举例道，“今天服务器、虚拟机到底配置了怎样的IP，应该处于哪个VLAN，这些对用户都不重要。重要的是知道服务器A到服务器B之间应不应该产生关联，下一跳是连到服务器C，或者其他。来完成用户的业务流程，中间是需要安全、策略来满足它的条件，才是业务实现最重要的。”

　　ACI在构建之初的逻辑就是，从应用部署的逻辑性、关联性来谈底层架构如何部署，ACI以这个为着眼点出来作为主要的设计理念。

　　打破策略变更的紧密耦合

　　传统的网络架构到底有什么束缚?答案是，网络协议和功能、转发和策略的紧密耦合。因为这种耦合，策略中的变更可能会给转发带来不利影响。在现网环境中，最大的冲突产生在了系统应用开发部门和IT运维部门之间，而且这种冲突越来越无法调和。

　　系统开发人员会考虑功能模式是怎样的?如何串接起来?有几个功能组件与下一级的功能组件沟通，在系统应用开发人员中就是这样，他们对底层实现的IP、位置、VLAN这些根本不关心。而当系统开发人员与IT运维团队谈的时候，往往遇到的反馈是VLAN只剩多少?IP网段只剩几个位置?你的这些需求在现网无法实现。

　　所以，为了在数据中心基础设施提供灵活性和简单性，需要新的语言描述连接的抽象化意图，以使最终用户不需要丰富的网络知识来描述连接的需求。此外，这个意图应该从网络转发语义中解耦，以便最终用户可以描述策略，让策略中的变更不会影响转发行为。

　　所以思科提出了GBP的逻辑模型，全称是(Group-Based Policy)，基于组的策略。它分离了关于应用连接要求的信息与关于底层网络基础设施的详细信息。需要特别指出的是，思科创造了GBP的模型，还把它推送到了OpenStack和OpenDaylight中的工作项目中，OpenDaylight称基于组的策略是“应用为中心的策略模型”。而在思科ACI的逻辑实现上被称为ANP(Application Network Policy)。

　　马元骐提到，“ANP是思科在ACI中的策略实现，GBP是思科将模型推送到开源社区的说法。也是希望开源社区能够基于APIC获得价值。”

　　GBP或ANP的优势在于：

　　1.更简单的以应用为中心的表达策略：通过创建策略来映射应用程序语义，这个框架提供了更简单的自我记录机制来捕捉策略要求，而不需要非常了解网络。

　　2.提高自动化：分组结构允许更高级别的自动化工具简单地同时操作网络端点组。

　　3.一致性：通过分组端点和应用策略到各组，该框架提供了一致的方法来处理策略变更。

　　4.可扩展策略模型：由于这种策略模型是抽象的，没有绑定到特定网络部署，它可以简单地捕捉连接、安全、QoS等。

▲图：可更加直观的理解GBP模型的实现。

　　理解了GBP，但它毕竟是一个逻辑，是一个模型。落实到实体上就是ACI的控制器APIC。APIC是通过基于组策略表示的基于策略配置的控制节点，就是ACI架构中的控制器。它的主要功能是为思科ACI架构及设备提供策略控制和策略解析机制。有了APIC，用户不再需要触碰每个网络元素以及手动确保所有策略而得到适当的配置。

　　马元骐特别提到了APIC的几个关键点。“其一APIC并不直接参与数据平面转发，因此集群中所有思科APIC元件的断连并不会影响转发功能，这提高了整个系统的可靠性。即便是APIC遭到安全威胁，那么除了新的策略和分发失效之外，其他数据转发不受影响。其二APIC的可视化，透过APIC对底层的了解，让用户很直观的了解的设备的等级、网络的等级，应用端到端等级，如掉包率增加了与否，延时增加与否等等。其三，APIC可满足用户当前的应用开发逻辑需求，随后当用户梳理清楚自身的应用模型后，用户可以用自己定义的应用模型转述底层的基础架构该怎么支撑。其四，APIC在策略的下发方面可以通过图形化的方式，也可以将APIC的逻辑释放给用户，由用户通过开发脚本来进行策略的下发。其五，关于OpFlex，它是思科专为交换基于组的策略信息而开发的新策略协议，它是南向API。Opflex是从逻辑到物理呈现的协议，是属于APIC与物理设备沟通的对话机制，功能是将APIC的策略逻辑呈现在物理的Config上，物理设备也会反馈给APIC，逻辑功能是否能够实现。OpFlex也可用于其他的控制器。”

　　此外APIC还支持多租户和基于角色的访问控制，具体可参考《ACI是SDN技术吗?》一文。

　　对于ACI的基础Fabric，马元骐也表达了对数据中心扁平化的见解。目前思科ACI有成功的在网案例，Spine-Leaf结构中Leaf节点140台的规模。

　　他谈到，“在物理结构上，目前Spine-Leaf的结构跟传统的三层结构差异性并不大，其实只是视觉逻辑上的感受不一样，为什么OSI二层结构中需要那么多标准和协议?为什么谈到高可用性就必须要主备，都以二为单位呢?其实组网协议和标准完全可以将这些抛开。那么二层的问题就会迎刃而解。Spine-Leaf是有固定的布线模型的要求，Spine与Spine之间不能有横向连接，Leaf与Leaf之间中间不能有横向连接，每个Leaf要能够连接到每个Spine，这是数据中心网络扁平化的绝对要求。这个是解决东西向流量增长的方法。这个模型是有数学模型可以验证每个硬件盒子上联和下联端口各有多少，可以算出拓扑大概是怎样的。”

　　通过以上的介绍，用户就完全可以从网络功能的虚拟资源实现层面、控制器层面和基础架构连接层面完全理解思科在GBP、APIC和Fabric方面构建ACI的想法了。

　　打破业界对思科的固有认知?

　　不管是封闭，还是ACI是硬件架构，是思科在面对用户，面对市场，都会被每每质疑的论调。虽然思科在公开或非公开的很多场合都会做出解释，但往往会引来更多的解读和批判。

　　在《ACI是SDN技术吗?》一文中，对思科ACI的开放API、合作伙伴生态系统做了说明，引用到这里。后面还有思科二位专家的QA。

　　思科ACI支持可扩展的合作伙伴生态系统，其中包括4-7层网络服务;虚拟机管理程序;以及管理、监测和云编排平台。所有合作伙伴都使用思科ACI的开放API和开发工具包、设备封装和插件，以及OpFlex。

　　开放API：思科ACI支持通过REST接口的API接入、GUI和CLI以及一些软件开发工具包(包括Python和Ruby)。思科APIC支持跨HTTP/HTTPS的REST API，并绑定XML和JSON编码。这个API同时提供类级别和树级数据访问。REST是分布式系统软件架构，多年来，它一直是领先的Web服务设计模型，并已经逐渐取代简单对象访问(SOAP)和Web服务描述语言(WSDL)等其他设计模型。

　　合作伙伴生态系统和OpFlex：南向API—OpFlex是开放的可扩展策略协议，用于在策略控制器(例如思科APIC)和任何设备(包括管理程序交换机、物理交换机和4-7层网络设备)之间的XML或JSON传输抽象策略。思科的合作伙伴包括英特尔、微软、Red Hat、Citrix、F5、Embrane和Canonical，现在他们正与IETF和开源社区合作来规范OpFlex，并提供参考部署。

　　思科将APIC装进了盒子，部署在了其UCS服务器上。每当思科要将其某项强大的功能和软件绑定在硬件产品上时，业界总会吹毛求疵一些。李少杰指出了几点，“其一，APIC部署在UCS服务器上，能够给APIC更好的安全健壮性;其二，思科有UCS服务器产品，如果其他网络供应商有自己的服务器产品，相信也会是这种解决方案;其三，APIC从诞生之初就没有考虑过APIC单独提供;其四，将APIC单独以软件形式提供给用户，完全没有技术上的问题。如果用户接受ACI概念，还会在乎一台UCS服务器吗?”

　　在与思科两位专家的interview之后，思科又对“将APIC放在UCS中，以硬件形式提供”做了进一步的邮件说明，回复如下：“在软件领域的任何实现成果都极易受到安全威胁的影响。思科也确实考虑在软件或者虚拟机环境中率先引入APIC控制器。然而，参与过alpha/beta测试的客户们给出结论称，思科需要提供更进一步的保护手段、而非单纯对底层操作系统及应用程序进行强化。APIC设备当中通过TPM建立起基于硬件的安全密钥机制，旨在进一步巩固这套控制器平台。借助这种方式，利用代码插入方式攻击该控制器的行为将在很大程度上得到避免。”

　　不过，APIC或其他厂商的控制器是通过软件提供给用户，还是落到标准化的服务器上，最终还是由市场和客户决定吧，思科做出了硬件方式的选择而已。

　　木秀于林，风必摧之;行高于人，众必非之。当IT168提到业界的一些质疑声时，二位专家是这样解答的。

　　IT168：思科ACI晚了吗?

　　马元骐：思科在前期一直在观察SDN的发展，SDN最初的发展虽然很热闹，但缺少明确的方向性，思科不会为了抢市场的话语权而轻易说，网络必须要向SDN转变，而是要从思科所拥有的庞大客户群的角度出发了解SDN的需求，呈现到底如何。现在我们后发先至了。

　　IT168：ACI封闭吗?

　　李少杰：首先要看ACI是否解决了客户的问题，其次思科ACI的接口都是开放的，如果客户有能力的话，完全可以做一个控制器来管理APIC都行。将GBP、Opflex推送给开源社区和标准组织就是最好的证明。

　　IT168：怎么看待白牌交换机的发展?

　　马元骐：白牌交换机如果没有自研芯片和软件就没有未来，而这两个方面是需要积累的。同时，小型机转向x86就是过往最好佐证。

　　李少杰补充：白牌交换机在初期也许可能没有问题，但后续软件版本的升级、维护和技术支持谁来保证?

　　IT168：Opflex是私有协议吗?

　　马元骐：任何技术在它的成长和完善阶段都可以认为是私有协议，但随着不断成熟并商用，它的私有性会越来越弱化。

　　IT168：中国用户对ACI买账吗?

　　李少杰：目前在中国市场，在半生产网、实验局的用户总计大概有20几家。

　　结语：不管是SDN，NFV仍然还处于不断完善和变化中，标准组织、厂商和用户的磨合都让这次深层次的架构性变革走的踏实。我们观察到，思科凭借ACI在SDN市场的影响力正在加大，客户的选择就是见证。采访中思科还透露了ACI未来的发展方向，如更多的弹性，与Docker的结合，支持Openstack的后续发展，以及定义4-7层服务Service Chaining等等。