智能城市方案:OpenStack合力K8s打造IoT平台
物联网(IoT)是云计算领域的“下一件大事”。领先的行业供应商都提供了自己的IoT解决方案,并将其视作自己的业务战略。因此IoT这个词已经被滥用成为描述不同供应商专有解决方案的一个新流行词汇。“IoT”这个词几乎可以代表一切,甚至比“云计算服务”更加空泛。物联网主要围绕日益增加的计算机间通信,可通过用于收集数据传感器的网络和连接到云计算服务的执行程序处理各类信息。这个技术可以让我们生活中的一切,从
物联网(IoT)是云计算领域的“下一件大事”。领先的行业供应商都提供了自己的IoT解决方案,并将其视作自己的业务战略。因此IoT这个词已经被滥用成为描述不同供应商专有解决方案的一个新流行词汇。“IoT”这个词几乎可以代表一切,甚至比“云计算服务”更加空泛。物联网主要围绕日益增加的计算机间通信,可通过用于收集数据传感器的网络和连接到云计算服务的执行程序处理各类信息。这个技术可以让我们生活中的一切,从街边路灯到港口都变得更加“智能”。
我们对IoT的看法与其他供应商有所差异。我们会通过相同的方法向客户提供私有云解决方案,并使用现有的开源项目对云服务的实现方式进行扩展,借此打造通用IoT平台,以应对不同用例的需求。为此我们定义了下列需求:
开源软件 整个平台必须基于现有的开源解决方案,并且绝对不能只由某一家供应商开发。我们希望使用现有的平台:OpenStack、Kubernetes、Docker、OpenContrail等。
不依赖具体硬件和供应商 软硬件方面不能存在供应商锁定的情况。IoT网关CPU必须支持x86/64或ARM架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。
互操作性 IoT平台必须是通用的,可以适合不同用例。举例来说,如果某一IoT网关可用于统计街灯数量,那么也必须能通过相同的方式将其用于智能工厂或工业4.0应用程序中。
因此我们设计出涉及OpenStack、Kubernetes、OpenContrail和Docker开源项目的下列高层体系结构。
开源软件
整个平台必须基于现有的开源解决方案,并且绝对不能只由某一家供应商开发。我们希望使用现有的平台:OpenStack、Kubernetes、Docker、OpenContrail等。
不依赖具体硬件和供应商
软硬件方面不能存在供应商锁定的情况。IoT网关CPU必须支持x86/64或ARM架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。
互操作性
IoT平台必须是通用的,可以适合不同用例。举例来说,如果某一IoT网关可用于统计街灯数量,那么也必须能通过相同的方式将其用于智能工厂或工业4.0应用程序中。
下文技术概述一节将详细介绍其中的技术细节。首先一起来看看我们构建解决方案原型的两个用例。
智能城市原型
第一个用例是为捷克共和国一个名为皮斯克(Pisek)的小城市构建的智能城市项目。智能城市的理念和架构需要部署超过3000个端点,以及大约300个IoT网关,这些网关以高可用模式运行在Kubernetes驱动的容器中。该解决方案还包含开放数据门户,并通过数据API为第三方公司提供了下列信息:
-
交通流量、路线、停车位
-
监控和管理能源的使用以实现节能
-
电子商务、营销、旅游信息
-
环境分析
-
生活方式、社交服务、社交网络
该解决方案使用基于RaspberryPi 2的IoT网关。来自网关的数据存储在Graphite中,通过自行开发的数据挖掘应用程序进行处理,将结果显示在基于Leonardo CMS构建的市民门户网站中。Leonardo CMS是一种Web服务,可以将复杂的可视化结果混合显示在一起呈现任何内容。这个开放数据门户可以通过可视化仪表盘或API提供数据访问。
下图展示了特定时间内,Kollarova和Zizkova两条街道十字路口的机动车和行人通行情况。
若要详细了解该项目,建议阅读奥斯丁SuperUser杂志《更进一步,让城市变得更智能》一文,或观看KubeCon 2016演讲。
OpenStack奥斯丁峰会上的智能会议系统
为了证明我们的IoT平台真正不依赖某种应用程序环境,在OpenStack峰会过程中,我们将智能城市项目中使用的IoT网关(RaspberryPi 2)带到了奥斯丁会议中心,通过基于IQRF的网状网络将其与传感器连接在一起,借此测量湿度、温度,以及二氧化碳浓度。这个演示证明了IoT网关可以对IQRF、蓝牙、GPIO,以及任何其他基于Linux平台的通信标准进行管理并收集数据。
我们在会议中心三层楼内部署了20个传感器和20个路由器,通过一个IoT网关接收来自整个IQRF网状网络的数据,并将其中继至一个专门的时序数据库,本例中使用的数据库是Graphite。数据收集器使用了Docker容器内运行,通过Kubernetes管理的MQQT-Java网桥。其中最有趣的地方是距离,运行Docker容器的Raspberry位于美国奥斯丁的会议中心内,而虚拟机运行在欧洲的数据中心。动态网络覆盖渠道由OpenContrail SDN提供。下文技术概述一节还将对该平台进行进一步介绍。
下图展示了传感器和路由器发现过程中找到的一个无线IQRF网状网络。区域0 - 1覆盖会议中心一楼,区域2 - 4覆盖四楼。
IQRF是一种工作在亚GHz ISM波段的无线网状网络技术,可提供简单易行的集成能力,良好的互操作性,最多支持240个跃点的健壮网状网络连接,工作距离可达数百米,能耗非常低。
下图展示了会议中心二楼不同房间的二氧化碳实时浓度。历史图表显示了自周一以来的数值。从中可以直观了解到主题演讲的开始时间和午饭时间。
奥斯丁这套平台的数据收集方面,我们使用了下列服务架构。
技术概述
本节进一步介绍了这个IoT平台的一些技术构思。这个IoT平台以“通用”为愿景,旨在以安全的方式收集、管理和处理来自数千个端点的数据,并以动态的方式集中管理所有数据。
因此整个体系结构可以分为下列两大主要部分:
数据中心
数据中心是整个IoT平台的中心管理点。其中包含OpenStack IaaS云,以及伴随云同时运行的虚拟机和SDN控制面板。这些计算机负责了时序存储、数据处理群集、数据API网关访问,以及可视化Web服务等任务。
网关
IoT网关可位于任何目标位置,例如街灯、工厂机械、家用电器中。SDN提供的传输层将远程IoT网关与云服务连接在一起。网关可支持多平台,甚至可能混合使用了x86/64和ARM设备。该技术可以通过一个网关为多个客户承载多种传感器平台,这一特性是通过微服务分隔(Docker容器)和Kubernetes对多租户的支持实现的。整个平台可以提供可伸缩的多租户环境,无论多远距离的应用程序和传感器都可位于同一个网络中。
下列架构图展示了数据中心层和网关端的相关组件。下文架构详情一节提供了进一步介绍。
架构详情
架构图展示了整个IoT平台在体系结构方面的逻辑视图。左侧是数据中心,右侧是上文提到的网关。
从下图可以看到,这里使用OpenStack作为承载所有控制服务的云,同时所有大数据处理和前端可视化任务也是在这里进行的。网关使用Kubernetes对服务进行微分隔,为了实现多租户功能并确保不同传感器的安全,这一步是必须的。同时该平台还使用OpenContrail将两端连接在一起,并为Kubernetes POD和OpenStack Project虚拟机提供网络分隔。
上文曾提到过,分隔是通过SDN覆盖实现的。这里的重点在于数据中心边缘路由器和IoT网关之间只存在IP连接。网关操作系统和数据中心边缘路由器之间的VPN连接可以看作该平台的最底层,该层之上是SDN,在这里可以通过OpenContrail实现虚拟机(OpenStack云)和容器(网关)之间的直接通信。这种方法使得用户可以自由选择不同类型的传感器和执行程序,为其设置权限,并用安全的方式将其与云中负责任务处理的应用程序连接在一起。
数据中心包含下列服务:
管理服务
硬件群集中运行的虚拟机承载了所有控制服务:OpenStack控制器、OpenContrail控制器(SDN)、Kubernetes主机、Salt主机。
OpenStack云
OpenStack项目为数据库(Graphite、Influxdb、openTSDB)、大数据处理(Hadoop),以及数据可视化(Grafana、LeonardoCMS)所涉及的不同虚拟机服务提供了分隔和划分。这个云运行在KVM hypervisor之上,通过OpenContrail的Neutron插件实现网络连接。
边缘路由器
OpenContrail会与数据中心边缘路由器创建iBGP对端,这样便可以将OpenStack虚拟机和Kubernetes POD的动态网络路由传播至IoT网关。该设备可以MPLSoverGRE或MPLSoverUDP方式创建标准的L3VPN。
远程网关包含下列组件:
Kubernetes Minion
Kubernetes minion负责与数据中心内的Kubernetes主机通信,并负责管理Kubeletand POD。Kubelet使用了Opencontrail插件,借此将Docker容器与vRouter代理连接在一起。
Kubernetes POD
Kubernetes POD是连接到vRouter的一个或多个Docker容器。POD可按照标签进行分隔,这样即可启动不同应用程序,从不同消息总线以IQRF、蓝牙,或GPIO方式读取数据。
Docker容器
Kubernetes POD中的Docker容器为整个平台提供了极大的收益,可在无需特别安装的情况下支持任何类型的操作系统。例如,IQRF使用了某一版本的简单Java应用程序,可通过容器在几分钟内交付,并且不会与网关本身的操作系统产生不匹配的情况。
应用程序视图
下列架构图详细介绍了应用程序视图。从图中可知,借助OpenContrail覆盖的帮助,OpenStack云内部的虚拟机可以通过L2或L3私有网络联系位于任何地理位置的Docker容器。因此应用程序开发者可以使用标准云平台中用过的同一套工具。他们可以通过HEAT部署虚拟机应用程序控制器,随后通过简单的Yaml文件在远程网关上的容器中部署Kubernetes服务。
以通过环境传感器收集数据的做法为例:传感器直接连接至容器,数据在Docker容器中处理后发送至Graphite时序数据库。因为我们希望以图形化方式实时呈现数据,因此使用了另一个虚拟机,通过Leonardo CMS借助Graphite API读取数据,并将其显示在网站上。据此我们可以通过同一个云平台,按照相同的原则创建不同项目,并使用多种输入和输出位置。
结论
我们希望对这个IoT平台的愿景和已经部署的原型进行一个简要的介绍。目前我们正在完成整个智慧城市解决方案的细节设计工作。
今年在奥斯丁举行的OpenStack峰会和伦敦举行的KubeCon上对该方案进行介绍后,我们收到了来自社区成员的大量反馈。在IoT平台的安全性、弹性,以及性能方面,我们的构想得到了大家的认可,很多技术合作伙伴希望通过合作对我们的IoT平台进行扩展,借此构建他们自己的解决方案。我们现在正在着手有关工业4.0的构想,打算通过开源项目创建第一个智能工厂。
更多推荐
所有评论(0)