SDN实战团分享（四十）：揭秘Arista EOS三大特性，打造非一般的云网架构

内容简介：SDN实战团分享（四十）：揭秘Arista EOS三大特性，打造非一般的云网架构

▼点击下方收听音频

SDN实战团分享（四十）：揭秘Arista EOS三大特性，打造非一般的云网架构 来自百度VR

编者按：本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。

嘉宾简介：沈之千 ，自1995年起加入 IBM 从事网络职业，有多年的网络设计和实践经验。在加入 Arista 公司之前，曾经在 IBM、Foundry Networks和博科通讯工作，参与过 各种网络技术的设计和实施，涉及运营商网络、数据中心和园区网 等各个领域，是一个典型的传统网工。目前致力于向非传统网工的转型中......

很多人知道目前全球许多大型的云数据中心网络使用了大量 Arista的交换机，那么这些用户看重的是哪些特性？今天我来和大家一起探讨一下云网络数据中心看重的软件驱动因素，因为时间因素我不会涉及各个方面，不会涉及像Spine-Leaf、VXLAN等组网技术或者像Arista引以为豪的 CloudVision一站式管理和自动化平台细节，我只是想和大家一起探讨一下云网架构中有吸引力的软件因素。具体而言我希望分享的是EOS上三个用户看重的特性： 开放性、网络自动化特性和 Telemetry特性 ，或许能给大家一些启发。

我先来演示个例子，这个例子我也经常做给用户看，因为做这个实验你不需要购买任何网络设备和软件，所有的素材都是免费的。这个例子讲的是 Arista交换机利用 XMPP实现多机箱管理特性。XMPP是即时通讯的协议，可以轻易支撑上万个客户端，像 Google Talk也是利用这一协议制作的，实现类似于微信的功能。

大家看到的是我MAC上打开的二个虚拟机，这二个虚拟机是 Arista的网络操作系统虚机版本，你只要在 eos.arista.com上面简单注册就可以下载使用，功能和物理交换机几乎一样。我在上面目前只配置了管理地址和 XMPP客户端开启功能： 我在MAC上安装了 ejabberd XMPP服务器，非常简单：brew install ejabberd就搞定了，配置也非常简单。然后我在MAC上面打开了 adium XMPP客户端：大家看到下面的是我和同事交流的即时通讯人员，中间的 XMPP-test里面包含的就是我打开的二台交换机，我可以一边和同事交流、另一边操作交换机。可以让交换机加入不同的群组，比如POD1群、leaf群、Spine群等，这样你可以对一个群实施操作，比如下发配置策略、获取状态等等……，我还可以写一段脚本，让交换机在BGP接口down的情况下发送消息到我的即时通讯客户端：

只要你有 XMPP客户端，你都可以管理交换机，我又打开了我的 iPhone手机，用了一个 BoggieChat的客户端来检查交换机状态：

我的同事还试了用apple watch上的XMPP客户端也可以操作交换机，原理当然和iPhone上使用是一样的：

上面举的例子说明了Arista的一个特点，就是开放性和配置的极简化，而这一特点可能也是云网用户最关注的地方。你看到你可以免费下载使用EOS来模拟实验，你使用 vEOS可以做绝大部分的实验：搭建8路16路ECMP的Spine-Leaf数据中心网络架构、使用 eAPI、配置 VXLAN、与OpenStack互连、用 python/bash/perl等实现事件触发脚本、在交换机上装载你自己的应用….,也可以做我们这个 XMPP多机管理的实验。

事实上XMPP的特性是多年前Arista为了解决多机箱管理而采用的特性，最早就是在交换机上装了一个 XMPP客户端的扩展程序，后来把它植入到EOS里面了，其实现在有了更好的一站式 CloudVision解决方案了，但是有些用户还是觉得不错，所以EOS还保留着这一特性。如果用户觉得 XMPP等网络服务器搭建要个参考，Arista在 https://github.com/arista-eosplus/ztpserver上提供了一个完整的环境，你可以看到源代码、文档、安装方法等，它提供了完整的 DHCP、XMPP、Email、syslog等服务器功能。Arista的 ZTP零接触部署也非常有特点，支持任意脚本传递和执行，比如perl/bash/python等，所以支持不同云网用户的需求，这些都可以在 vEOS上模拟。

EOS还原生支持在交换机上面植入你自己需要的虚拟机，用户会在上面安装像网络分析、负载均衡、大数据分析等等应用，我也在一台物理交换机上安装了 Vyatta虚拟路由器（仅测试使用）：

这个例子说明了 Arista的网络设计开放性：采用的协议是开放的、沟通的渠道是开放的、连EOS的素材也是开放的，很多云网络用户看重这一特性。事实上建设云网络架构需要的是全面的开放性，我们看看EOS的做法：

EOS的做法是将网络的各个层面开放出来，底层采用未经修改的Fedora Linux，保持小巧高效和可更新的特性，其他厂商可能会采用修改内核、层层包裹的方法，造成不少系统积重难返、内核老化等窘境。EOS可以执行 Linux bash、进入bash、执行bash所有命令、在bash上访问 CLI…, EOS的CLI其实就是 Linux 的一个shell，你也可以自己定制CLI命令。

数据层面的开放性不仅支持 OpenFlow，支持ODL等各种SDN控制器，也支持无控制器模式的 OpenFlow（称为 DirectFlow）。无控制器模式的OpenFlow简化了SDN的实现流程，为很多用户程序化交换机数据转发带来了很大便利，比如你需要在数据中心的 Service Leaf实现服务链的功能，你不再需要搭建一个SDN控制器，你只要自己编写服务链流程，让交换机直接下发/修改/撤销流表、与此同时交换机工作在混合模式下，很多用户发现用编程语言或者 Python 来实现一个SDN应用要比搭建SDN控制器，然后再编写SDN应用要灵活快捷。当然如果你在全网实现SDN应用还是要用控制器的。大家可以在网上找找 Arista做的一个数据中心防火墙池的对称扩展文章，里面包含原理、算法、脚本等就是用这样的方式实现的，云网络用户利用这一特性可以随时实现软件定义网络的灵活运用。

控制平面是云网用户关注的地方，因为你需要一个真正的实时响应的事件触发机制（不是通过屏幕抓取监控的方式），你需要监控网络的各种状态变化（比如端口状态、ARP/MAC变化、日志中的某些信息、路由变化乃至系统内部的状态信息等），你会需要在某些状态发生变化的时候采取自动化的操作，这里面其实既包含了网络状态信息的开放性、同时也包含了一旦我要执行自动化操作时可以实施的手段是否也是开放的，如果只能执行的是CLI的范围，那如何实现同步数据中心其他应用？EOS的做法是开放所有状态并且让你实施CLI加上 Linux服务器可以实现的任何程序。

管理平面开放性是实现DevOps自动化运维的重头戏，无论是自动化部署、数据中心单一管理、还是与数据中心管理系统的集成都会要用到它，EOS采用了eAPI的接口，采用JSON格式，事实上EOS所有的命令你都可以输出JSON格式，也提供GUI方式让你熟悉，方便你的编程，而eAPI获得的结果都是key、value的dictionary格式，非常方便现在流行的各种编程。我们开始演示的 XMPP也是管理层面的开放协议。当然云网用户很多也需要SDK的支持，所以SDK的完整便捷也是管理平面开放的重要方面。EOS不仅提供了 python和 Ruby 的客户端，方便用户编程，而且针对不少云用户热衷的 Go 语言提供了 Go eAPI。

虚拟化层面开放性代表了网络支持虚拟化技术的手段，你可能需要把自己的程序作为虚拟机植入交换机，在混合云架构时需要网络NFV，也就是将你的网络操作系统植入X86虚拟化平台…., EOS在这方面本身支持装载虚拟机、支持EOS装在任意Hypervisor上，最近还推出了容器版本的 cEOS等，事实上 cEOS也是Arista应某些云网用户要求而推出的，其应用场景包含在开放网络架构中运行EOS、在云平台上运行EOS、在白牌交换机上运行 EOS等。大家可以看看下面的图例，是二种 cEOS应用场景。

应用开放性其实是不少私有云用户所需要的，一些云网用户希望网络能够和现有应用有良好的集成，这些应用可能包含商用的 VMware ESXi/NSX、Splunk、Hadoop、Nutanix等，这些 EOS都内置支持了，当然用户也可以利用 SDK工具自己开发最好的应用整合方案。

云网络建设的一个重点是网络自动化

，网络自动化在不同的云网用户上也有不同的需求和体现：超大型云数据中心用户依仗自己拥有的强大软件开发能力和资源，会选择自己开发网络控制器，实现网络自动化部署、运维、工作流等工作；而一些电信运营商和大中型企业会选择使用开源的自动化 工具 和市面上现有的云平台控制器，这些工具和控制器平台有Ansible、Chef、Puppet和 OpenStack、ODL、Nuage等控制器；如果是传统企业的云平台则更多的倾向于选择一站式交钥匙工程的网络管理和自动化平台。

对于超大型云数据中心用户来说，他们看重的就是网络设备的开放性，如果你在各个层面上开放、如果你提供的API和SDK完整简洁、如果你支持不同语言的沟通工具，如果你能够提供开放的数据模型、网络状态流反馈，那就基本满足要求了。这类用户会选择自己的管理、自动化、工作流控制器，开发最适合自己的数据模型和工具，甚至会提出开源标准…，比如OpenConfig就是一个例子。目前超大型数据中心网络选择Arista的很重要原因就是EOS本身在各个层面上的开放性。

那么对于一些电信运营商和大中型企业而言，他们追求使用开源工具和软件来实现云网络的自动化管理、部署、工作流。他们会选择 Ansible、Chef、Puppet等工具和 OpenStack、ODL、Nuage等控制器，试想一下针对云网络节点从上千个到几万个甚至更大的环境，缺乏网络自动化工具和工作流工具是难以想象的。支持这些控制器和工具的完整程度、易用性、兼容性也会影响云网络用户的选择，除此之外，有些企业会选择混合云的部署，支持云端API变得越来越重要了。对于EOS而言，这些方面目前都做的非常好，Arista不仅提供完善的 EOS DevOps开发工具，简化优化像Ansible、Chef、Puppet等工具的开发，也有很多用户在使用这些工具以及使用第三方控制器与网络的集成，现在还提出了支持 “Any Cloud API”的口号，支持像Azure、Amazon、Softlayer等公有云的API。

最后有不少传统企业和小型运营商也在积极地建设云数据中心，他们很多需要的是一站式交钥匙方式，也就是厂商或者集成商提供一个云架构网络的一体化平台，这一平台承担了云网络管理部署、自动化、工作流、监控、分析等功能、还要提供与开源和商用控制器的集成，这个也是目前不少网络厂商的重心。目前Arista公司是通过 CloudVision平台来提供云网络的“交钥匙”解决方案的，它可以集中化呈现分布式网络状态，允许实现单点集成和全网络可见性与分析、通过使用开放式 API（如 OVSDB、JSON和 Openstack 插件）为物理和虚拟工作负载编排提供与控制器无关的支持等等…,由于时间关系我就不介绍这一内容了。大家可以看一下下面二张图，第一张是 CloudVision的基本功能、第二张是与外部对接的示意图：

最后我想和大家分享的是 Telemetry

这一网络遥测、实时监控的特性，这是目前云网络用户较为关注的特性。为什么 Telemetry会受到关注？原因很简单：传统的由外部应用发起请求获取网络信息的 SNMP协议太古老了，不能实时反映出网络的状态，而由网络设备推送的实时信息自然地更受欢迎。能够捕捉网络的“所思所想”和“所作所为”是真正的网络自动化和分析的基础，传统网络长期受制于网络可见性的限制，很大原因是由于无效的轮询机制只能提供有限的数据子集。因此，在涉及到真正的网络洞察力时，传统网络的运营者基本上是盲目的。

其实 Telemetry不是新的发明，NetFlow、sFlow早已实现了网络数据的实时推送，但是 NetFlow、sFlow推送的是最原始的数据，数据以IP报文和以太网报文（sFlow）格式呈现给分析工具、而非用户期望的以规范化数据模型方式来表达，这样一来分析工具的效率和优劣至关重要，优异的分析工具其扩展性和性价比难以承担整个云数据中心网络的责任，更多地在某一分析任务中起作用。另一方面，数据流量并非网络的状态的全部，网络设备的 CPU、内存信息无法透过NetFlow、sFlow协议导出、网络拥塞的实时信息、网络事件的日志信息也无法通过sFlow等实时传递出来。

而云网络用户希望获得的 Telemetry数据更进一步：不仅是数据流实时信息，而且希望获得实时的网络配置、流量统计、计数、报错、表项、环境、缓存等一些列信息。Google等云巨头推动 OpenConfig的一个重要原因就是希望能够以单一标准化数据模型 （YANG）来定义数据和实时状态反馈（state streaming），其实就是数据定义加上 Telemetry的特性。因为云网络中实现 Telemetry特性的话，用户才能方便和全面地实时了解云网络状态，这对于云网建设、运维、分析和网络实时调整都具有重大的意义 。

由 Goggle、微软、Facebook、ATT、Comcast等网络运营商发起的 OpenConfig目前正吸引了越来越多的云网用户的关注，OpenConfig本身希望能通过定义一些列开放且独立于网络厂商的标准模型来实现更方便标准的网络可编程性，其中数据模型采用 YANG，实现多厂商环境下开放标准的网络配置、实时状态流反馈和开放API，OpenConfig不仅仅如它字面上写的只是负责网络配置，还包含了网络 Telemetry遥测的功能，这一功能是很多云网络用户所希望用到的。目前由于OpenConfig定义的模型还未完善，处于起步阶段。EOS目前已经支持 OpenConfig，顺便说一下，EOS的 OpenConfig组件是由 Go语言写的。另外EOS的数据模型和实时状态流反馈早已实现并且都是开放的，但是其状态流标准是私有的，大家可以比较一下：

由于 OpenConfig其数据模型定义还在完善阶段，加上支持的厂商还不多，所以用户还不能大规模地使用。另一方面EOS凭借其架构的先天优势从诞生之初就具备了 Telemetry特性。大家知道 EOS的一个设计基本理念是抛弃了传统的复杂 IPC进程间消息传递机制，采用了中央数据库与各个模块推、送信息的SysDB设计方式：

SysDB具备真正意义上的模块化网络操作系统设计，现在不少人在学习、借鉴这一架构理念。SysDB本身就是保存网络设备所有实时状态的数据库，并且 SysDB也是开放的，EOS提供API和SDK供用户随时获得网络的全部状态，包含实时的配置、统计、计数、报错、表项、环境、缓存等一些列信息。随着云数据中心汇聚了大量网络设备，EOS也在云数据中心提供整体的 NetDB汇聚中央数据库，NetDB同样提供开放的 API，所以EOS本身天然具备实时传送云网络中每一台设备的每一刻状态信息，这些信息的汇聚无疑给云网络提供不小的价值。

云网络用户可以利用 EOS的API和SDK自己开发 Telemetry的应用，EOS也通过一站式平台 CloudVision提供 Telemetry的应用，用户可以获得整个云网络的事件分析、设备状态、表项信息、关联分析等实时状态，这是一个 Telemetry应用示意图：

以上就是我今天的分享内容。

Q&A

Q：Telemetry与NetFlow的区别是什么？

A ：其实 Telemetry不是新的发明，NetFlow、sFlow早已实现了网络数据的实时推送，但是 NetFlow、sFlow推送的是最原始的数据，数据以IP报文和以太网报文（sFlow）格式呈现给分析工具、而非用户期望的以规范化数据模型方式来表达，这样一来分析工具的效率和优劣至关重要，优异的分析工具其扩展性和性价比难以承担整个云数据中心网络的责任，更多地在某一分析任务中起作用。另一方面，数据流量并非网络的状态的全部，网络设备的 CPU、内存信息无法透过NetFlow、sFlow协议导出、网络拥塞的实时信息、网络事件的日志信息也无法通过sFlow等实时传递出来。而云网络用户希望获得的 Telemetry数据更进一步：不仅是数据流实时信息，而且希望获得实时的网络配置、流量统计、计数、报错、表项、环境、缓存等一些列信息。Google等云巨头推动 OpenConfig的一个重要原因就是希望能够以单一标准化数据模型 （YANG）来定义数据和实时状态反馈（state streaming），其实就是数据定义加上 Telemetry的特性。因为云网络中实现 Telemetry特性的话，用户才能方便和全面地实时了解云网络状态，这对于云网建设、运维、分析和网络实时调整都具有重大的意义 。

Q：EOS的商业合作模式是什么样的？

A ：目前EOS基本不合作，只用于Arista的交换机上，但是cEOS可能会开放给第三方（cEOS目前只有微软在使用），vEOS就是云平台的软件，EOS可以单独出售，仅用于Amazon等几个大云用户。总的来说，EOS作为Arista最看重的资产不会轻易供第三方硬件使用。

以上所述就是小编给大家介绍的《SDN实战团分享（四十）：揭秘Arista EOS三大特性，打造非一般的云网架构》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 『互联网架构』软件架构-实战Hystrix实战（96）
• 系统架构系列 (三)：业务架构实战上篇
• 系统架构系列（四）：业务架构实战下篇
• 安全架构评审实战
• 零信任架构远程办公实战
• 秒杀系统架构分析与实战

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。