包括核心层、用户接口和配备有基于容器的用户空间的服务层的超融合系统的制作方法

本申请要求2016年5月23日提交的发明名称相同、发明人相同并且以引用方式整体并入本文中的美国临时专利申请no.62/340,508的优先权的利益。本申请还要求2016年5月23日提交的发明名称相同、发明人相同并且以引用方式整体并入本文中的美国临时专利申请no.62/340,514的优先权的利益。本申请还要求2016年5月24日提交的发明名称相同、发明人相同并且以引用方式整体并入本文中的美国临时专利申请no.62/340,520的优先权的利益。本申请还要求2016年5月24日提交的发明名称相同、发明人相同并且以引用方式整体并入本文中的美国临时专利申请no.62/340,537的优先权的利益。

本发明总体上涉及超融合系统，并且更明确地说，涉及包括核心层、服务层和用户接口的超融合系统。

发明背景

超融合是用于将存储、网络化和虚拟化计算集成在数据中心中的it基础框架。在超融合基础架构中，存储组件、计算组件和网络组件的所有元件被优化以在来自单个供应商的单个日用电器上一起工作。超融合掩盖了下层系统的复杂性并且简化了数据中心维护和管理。此外，由于超融合提供的模块化，可以通过添加其它模块来容易地扩展超融合系统。

虚拟机(vm)和容器是调制解调器数据中心的超融合基础架构的组成部分。vm是基于实际计算机或假想计算机的功能和计算机架构来操作的特定计算机系统的仿真。vm配备有已虚拟化的全服务器硬件栈。因此，vm包括虚拟化网络适配器、虚拟化存储器、虚拟化cpu和虚拟化bios。由于vm包括全硬件栈，因此每个vm需要完整的操作系统(os)才能运作，并且vm实例化因此需要启动全os。

与提供物理硬件级的抽象(例如，通过使整个服务器硬件栈虚拟化)的vm大不相同，容器提供os级的抽象。在大多数容器系统中，还对用户空间进行抽象。典型实例是应用程序呈现系统，诸如来自citrix的xenapp。xenapp为应用程序的每个实例创建分段用户空间。xenapp可以用于(例如)向数十或数千远程工作者部署办公室套件。在这样做时，xenapp为每个连接用户在windows服务器上创建沙盒用户空间。虽然每个用户共享包括内核、网络连接和基本文件系统的相同os实例，但是办公套件的每个实例具有单独的用户空间。

由于容器不需要为每个用户会话加载单独的内核，因此容器的使用避免了vm所经历的与多个操作系统相关联的开销。因此，容器通常使用比运行类似工作负荷的vm少的存储器和cpu。此外，由于容器仅仅是操作系统内的沙盒环境，因此初始化容器所需的时间通常非常少。

技术实现要素：

在一个方面中，提供一种超融合系统，所述超融合系统包括多个容器，其中每个容器包括虚拟机(vm)和虚拟化解决方案模块。

在另一个方面中，提供一种用于实施超融合系统的方法。所述方法包括：(a)提供至少一个服务器；以及(b)通过将多个容器载入到与所述服务器相关联的存储器装置上来在所述至少一个服务器上实施超融合系统，其中每个容器包括虚拟机(vm)和虚拟化解决方案模块。

在另一个方面中，提供有形的非暂时性介质，所述有形的非暂时性介质中记录有合适的编程指令，所述编程指令在由一个或多个计算机处理器执行时执行前述方法中的任一者，或者促进或建立前述系统中的任一者。

在另一个方面中，提供一种超融合系统，所述超融合系统包括：操作系统；核心层，所述核心层配备有硬件，所述硬件启动并更新所述操作系统并且所述硬件向所述操作系统提供安全特征；服务层，所述服务层提供由所述操作系统利用的服务并且所述服务层借助于至少一个应用程序接口来与所述核心层介接；以及用户接口层，所述用户接口层借助于至少一个应用程序接口来与所述核心层介接；其中所述服务层配备有具有多个容器的至少一个用户空间。

在另一个方面中，提供一种超融合系统，所述超融合系统包括：(a)操作系统；(b)核心层，所述核心层配备有硬件，所述硬件启动并更新所述操作系统并且所述硬件向所述操作系统提供安全特征；(c)服务层，所述服务层提供由所述操作系统利用的服务并且所述服务层借助于至少一个应用程序接口来与所述核心层介接；以及(d)用户接口层，所述用户接口层借助于至少一个应用程序接口来与所述核心层介接；其中所述核心层包括系统级，并且其中所述系统级包括操作系统内核。

在另一个方面中，提供一种超融合系统，所述超融合系统包括：(a)协调器，所述协调器在一群容器主机上安装并协调容器节点(pod)；(b)多个容器，所述多个容器由所述协调器安装并且在主机操作系统内核集群上运行；以及(c)配置数据库，所述配置数据库借助于应用程序接口来与所述协调器通信，其中所述配置数据库为所述集群提供共享配置和服务发现，并且其中所述配置数据库可由通过所述协调器安装的容器读取和写入。

附图说明

为了更完全地理解本发明以及其优点，现在参考结合附图进行的以下描述，在附图中，相同的附图标记指示相同的特征。

图1是根据本文中的教导的系统的系统架构的图示。

图2是图1的系统级模块的图示。

图3是图1的供应服务模块的图示。

图4是图1的核心/服务模块的图示。

图5是图1的永久存储模块的图示。

图6是图1的用户空间容器模块的图示。

图7是图1的管理服务模块的图示。

图8是图1的增值服务模块的图示。

图9是图1的管理系统模块的图示。

具体实施方式

近来，在本领域中已出现在容器内部运行vm的概念。所得的vm容器具有习知容器的外观和感觉，但是相较于vm和习知容器提供若干优点。docker容器的使用尤其有利。docker是通过在linux上提供操作系统级虚拟化的额外抽象层和自动化层来使应用程序在软件容器内部的部署自动化的开源计划。举例来说，docker容器保留vm的隔离和安全性质，同时又允许软件作为容器来封装和分发。docker容器还准许现有工作负荷的加载，这对于希望采用基于容器的技术的组织来说是常见的挑战。

kvm(基于内核的虚拟机)是在含有虚拟化扩展(intelvt或amd-v)的x86硬件上的linux的全虚拟化解决方案。kvm由提供核心虚拟化基础架构的可加载内核模块(kvm.ko)和处理器特定模块(kvm-intel.ko或kvm-amd.ko)组成。使用kvm，可以运行多个虚拟机，所述虚拟机运行未修改的linux或windows镜像。每个虚拟机具有专用的虚拟化硬件(例如，网卡、磁盘、图形适配器以及类似者)。kvm的内核组件包括在主线linux中，并且kvm的用户空间组件包括在主线qemu(快速仿真器，执行硬件虚拟化的主机监视器)中。

利用vm容器的一个现有系统是ranchervm系统，所述系统在docker容器内部运行kvm，并且所述系统可在https://github.com/rancher/vm处获得。ranchervm提供用于开源虚拟化技术的可用管理工具，诸如kvm。然而，虽然ranchervm系统具有一些所要属性，但是它还含有许多弱点。

举例来说，ranchervm系统在主机操作系统上使用kvm模块。这会为整个主机产生单个故障点和安全性漏洞，因为损坏kvm模块会损坏整个主机。这种布置还使更新变复杂，因为必须重新启动主机操作系统以便使更新生效(这又需要停止所有的虚拟客户端)。此外，只有新平台配备有包括kvm模块的操作系统，ranchervm系统中的vm容器才可以移动到新平台。

现在已发现，可以通过本文中描述的系统和方法来解决前述问题。在优选实施方案中，这些系统和方法将虚拟化解决方案模块(所述模块优选是kvm模块)合并到每个vm容器中。这种方法消除了在ranchervm系统中发现的单个故障点(因为损坏本文中描述的系统中的kvm模块仅会损坏特定容器，而非主机系统)，提高系统的安全性，并且顺便允许在容器级而非系统级实施更新。此外，根据本文中的教导产生的vm容器可以在能够运行虚拟化的任何物理平台上运行，无论主机操作系统是否包括kvm模块，并且因此明显比ranchervm系统的vm容器更易于移植。可以从以下详细描述中进一步了解本文中描述的系统和方法的这些和其它优点。

图1至图9示出根据本文中的教导的系统的第一特定、非限制性实施方案。

参看图1，其中绘示的系统包括系统级模块103、供应服务模块105、核心/服务模块107、永久存储模块109、用户空间容器模块111、管理服务模块113、增值服务模块115、管理系统模块117和输入/输出装置119。如下文更详细地阐释，这些模块经由合适的应用程序接口、协议或环境而彼此交互(直接地或间接地)以完成所述系统的目标。

从顶层视角来看，前述模块交互以提供核心层121、服务层123和用户接口(ui)层125，应理解，所述模块中的一些向这些层中的一者以上提供功能性。还应了解，可以再利用这些模块(也就是说，本文中描述的系统的优选实施方案是一次写入多次使用的模型)。。

核心层121是提供启动操作系统所需的所有服务的硬件层。所述核心层提供更新系统的能力并且提供一些安全特征。服务层123提供所有所述服务。ui层125提供用户接口，以及一些restapi调用。这些层中的每一者具有与其相关联的各种应用程序接口(api)。这些api中的一些是表述性状态转移(rest)api，广泛被称作restfulapi或restapi。

如图2中所见，系统级模块103包括配置服务201、系统供应者203、系统级任务管理器205、主机linuxos内核207和硬件层209。配置服务201经由合适的restapi与配置数据库407(参见图3)、供应管理程序409(参见图3)和供应服务303(参见图3)通信。配置服务201与系统供应者203经由合适的exec函数来介接。类似地，系统供应者203与系统级任务管理器205经由合适的exec函数来介接。

系统级模块103的硬件层209被设计成支持各种硬件平台。

系统级模块103的主机linuxos内核207(核心os)组件优选地包括基于linux内核并且被设计用于向集群部署提供基础架构的开源、轻量级操作系统。主机linuxos内核207在自动化、应用程序部署的简易性、安全性、可靠性和可缩放性方面提供优点。作为操作系统，所述主机linuxos内核仅提供在软件容器内部部署应用程序所需的最少功能性，以及用于服务发现和配置共享的内置机构。

系统级任务管理器205是基于systemd，即，由一些linux发布商套件用于开机启动用户空间并且随后管理所有进程的初始化系统。因而，系统级任务管理器205实施守护进程，所述守护进程是在系统启动期间激活的初始进程，并且继续运行直到系统101关闭为止。

系统供应者203是容易地处理云实例的初始化的云初始化系统(诸如ubuntu软件包)。云初始化系统提供可以经由网络(诸如，例如，因特网)远程地发送配置的手段。如果云初始化系统是ubuntu软件包，那么其安装在ubuntu云镜像中并且还安装在办公ubuntu镜像中，所述办公ubuntu镜像在ec2上可获得。所述系统供应者可以用于配置以下各者：设置默认区域设置、设置主机名称、产生ssh私人密钥、将ssh密钥添加至用户的ssh/授权_密钥使得其可以登录，以及设置临时挂载点。所述系统供应者还可以用于提供许可证授权、用户认证以及由用户根据配置选项购买的支持。系统供应者203的行为可以经由用户数据来配置，所述用户数据可以由用户在实例启动时间时供应。

配置服务201使操作系统和服务得到更新。此服务(在所绘示的实施方案中，所述服务以编程语言go来编写)允许进行纠错或实施系统改进。所述配置服务提供以下能力：连接至云，检查新版本的软件是否可用，并且如果可用，那么下载、配置和部署所述新软件。配置服务201还负责所述系统的初始配置。可以利用配置服务201来按逐链方式配置多个服务器。也就是说，在利用配置服务201来配置第一服务器之后，可以利用所述第一服务器来解决其它服务器的任何额外配置。

配置服务201还检查运行中的容器的健康状况。在配置服务201守护进程确定容器的健康状况受损的情况中，所述配置服务提供服务来校正容器的健康状况。校正可以包括(例如)重新启动所述容器的工作负荷或在别处(例如，在另一个机器上、在云中等)重新产生所述容器的工作负荷。容器已受损的确定可以是基于(例如)所述容器已丢掉预定数目的ping的事实。

类似地，可以基于iops(每秒输入/输出操作，其是存储速度的测量值)来做出此类确定。举例来说，当建立存储器连接性并且对iops执行查询时，如果iops掉落到如在配置中限定的某水平以下，那么可以确定存储器过于繁忙、无空闲或潜伏，并且所述连接性可以移动到较快速的存储器。

同样地，可以基于安全标准测试来做出此类确定。举例来说，在后台对照安全标准进行测试期间，可以确定不应开放的端口开放。接着可以假设容器被攻击或者是不恰当的类型(例如，缺少恰当的安全性供应的开发容器可能被放到主机中)。在此种情况中，可以停止并启动所述容器，并且对所述容器进行如所述配置可能施加的恰当的安全筛选。

类似地，可以在某人作为特定用户登录、所述特定用户认证被否认或不起作用并且所述认证与微服务或网络使用有关(例如，并非整个系统的用户)时，可以做出此类确定。这可能是因为系统已受损，用户已被删除或者密码已改变。

如图3中所见，供应服务模块105包括供应服务303、服务仓库305、服务模板307、硬件模板309、因特网上的ipxe311子模块和启用程序313。启用程序313与供应服务模块105的其余组件介接。供应服务303经由restapi与系统级模块103的配置服务201(参见图2)介接。类似地，因特网上的ipxe311子模块经由ipxe与系统级模块103的硬件层209(参见图2)介接。

因特网上的ipxe311子模块包括因特网允用开源网络启动固件，所述固件提供完全预启动执行环境(pxe)实现方式。通过额外特征增来增强pxe以使得能够从各种源启动，诸如从网络服务器(经由http)启动、从iscsisan启动、从光纤信道san(经由fcoe)启动、从aoesan启动、从无线网络启动、从广域网启动或从无限带宽网络启动。因特网上的ipxe311子模块还允许通过脚本来控制启动进程。

如图4中所见，核心/服务模块107包括协调器403、平台管理器405、配置数据库407、供应管理程序409和容器引擎411。协调器403经由合适的api与管理服务模块113的平台插件715(参见图7)通信。配置数据库407和供应管理程序409经由合适的restapi与系统级模块103的配置服务201(参见图2)通信。

协调器403是容器协调器，也就是说，到系统的连接，所述系统能够安装和协调被称作节点的多组容器。图4中绘示的核心/服务模块107的特定、非限制性实施方案利用kubernetes容器协调器。协调器403处理容器创建的定时和容器的配置以便允许所述容器彼此通信。

协调器403充当容器引擎411以上的层，所述容器引擎通常用docker和rocket来实施。明确地说，虽然docker操作限于单个主机上的动作，但是kubernetes协调器403提供用于管理一群容器主机上的容器的大集合的机制。

简单地说，kubernetes集群由三个主要活动组件组成：(a)kubernetes应用服务、kuberneteskubelet代理和etcd分布式密钥/值数据库。应用服务是kubernetes集群的前端(例如，控制接口)。其用于接收来自客户端的创建和管理集群内的容器、服务和重复控制器的请求。

etcd是为核心os集群提供共享配置和服务发现的开源分布式密钥值存储。etcd在集群中的每个机器上运行，并且在网络分割和失去当前主机期间处理主机选择。在核心os集群上运行的应用容器可以从etcd读取数据和将数据写入到etcd中。常见的实例是存储数据库连接详情、高速缓冲存储器设置和特征标志。etcd服务是用于kubernetes集群的通信总线。应用服务响应于命令和查询而向etcd数据库张贴集群状态变化。

kubelet读取etcd数据库的内容并且作用于其检测到的任何改变。kubelet是活动代理。其驻留于kubernetes集群成员节点上，进行轮询以发现指令或状态变化并且用于在主机上执行所述变化。配置数据库405实施为etcd数据库。

如图5中所见，永久存储模块109包括虚拟驱动器503、永久存储器505和共享块和对象永久存储器507。虚拟驱动器503与用户空间容器模块111的虚拟引擎607(参见图6)介接，永久存储器505与用户空间容器模块111的容器609(参见图6)介接，并且共享块和对象永久存储器507与增值服务模块115的vm云备份服务809(参见图8)介接(经由合适的api)。将了解，前文的描述与特定的使用案例有关，并且云备份是共享块和对象永久存储器507可以执行的仅一个特定功能。举例来说，共享块和对象永久存储器还可以执行从云恢复、对代理备份和升级机器功能等。

如图6中所见，用户空间容器模块111包括容器609和含有虚拟api605、容器中的vm603和虚拟引擎607的子模块。虚拟引擎607经由合适的api与虚拟api605介接。类似地，虚拟引擎607经由合适的api与容器中的vm603介接。虚拟引擎607还与永久存储模块109的虚拟驱动器503(参见图5)介接。容器609与永久存储模块109的永久存储器505(参见图5)介接。

如图7中所见，管理服务模块113包括构造器703、模板市场705、状态机707、模板引擎709、硬件(hw)和系统监测模块713、调度器711和平台插件715。状态机707经由restapi与构造器703介接，并且经由数据推送与hw和系统监测模块713介接。模板引擎709经由合适的restapi与构造器703、调度器711和模板市场705介接。类似地，模板引擎709经由restapi与增值服务模块115的vm软件迁移模块807(参见图8)介接。平台插件715经由合适的api与核心/服务模块107的协调器403介接。

如图8中所见，增值服务模块115在所绘示的特定实施方案中包括管理仪表板803、日志管理805、vm软件迁移模块807、vm云备份服务809以及用于配置云备份服务的配置模块811(此处，请注意，迁移服务和云备份服务是服务模块115的特定实现方式)。管理仪表板803经由restapi与日志管理805和vm云备份服务809介接。在一些实施方案中，可以提供日志搜索容器，所述日志搜索容器与日志管理805介接以排查故障。

vm软件迁移模块807经由restapi与管理服务模块113的模板引擎709(参见图7)介接。vm云备份服务809经由合适的api与共享块和对象永久存储器507介接。vm云备份服务809经由restapi与管理系统模块117的dr备份909(参见图9)介接。用于配置云备份服务的配置模块811经由restapi与管理系统模块117的配置备份911(参见图9)介接。

如图9中所见，管理系统模块117包括仪表板903、远程管理905、解决方案模板907、灾难与恢复(dr)备份909、配置备份911、监测模块913和云服务915。云服务915与管理系统模块117的所有其余组件介接。仪表板903经由合适的协议或restapi与外部装置917、919介接。dr备份909经由restapi与vm云备份服务809介接。配置备份911经由restapi与配置模块811介接。

输入/输出装置119包括经由管理系统模块117与系统101介接的各种装置917、919。如上文所指出，这些介接是经由各种api和协议而发生。

本文中公开的系统和方法可以利用至少三种不同的部署形态。这些部署形态包括：(1)将虚拟机放到容器内部；(2)创建运行其自己的工作负荷的容器(在此类实施方案中，通常无虚拟机，因为容器自身是免除对虚拟机的需要的虚拟实体)；或(3)将应用程序限定为一起形成将被称作应用程序之物的一连串vm和/或一连串容器。虽然本文中公开的系统和方法的典型实现方式仅利用这些部署形态中的一种，但是利用所述部署形态中的任一者或全部的实施方案是可能的。

可以通过考虑上文指出的第三种部署形态在部署应用程序(诸如关系数据库产品oracle9i)中的使用来进一步理解所述第三种部署形态。oracle9i配备有数据库、用于连接至数据库的代理、安全守护进程、索引引擎、安全引擎、报告引擎、集群(或多个机器中的高可用性)引擎和多个窗口小部件。在oracle9i在常规服务器上的典型安装中，通常需要安装几个(例如，10个)二进制文件，所述二进制文件在开启时交互以实施所述关系数据库产品。

然而，使用本文中描述的第三种部署形态，这10个服务可能要作为容器来运行，并且10个容器的组合一起运行将表示oracle在盒上成功地运行。在优选实施方案中，用户只需要采取适当动作(例如，将单词“oracle”从左到右拖拽跨过屏幕)，并且所述系统将会在后台自动地做完所有这样的事情(例如，激活10个窗口小部件)。

本文中引用的所有参考文献(包括公布、专利申请和专利)特此以引用方式并入，程度如同每个参考文献被单独地并且特别地指示为以引用方式并入并且在本文中整体地陈述。

在描述本发明的上下文中(尤其是在以下权利要求的上下文中)术语“一”、“一个”和“所述”以及类似指代词的使用将被理解为涵盖单数与复数，除非本文中另外指示或上下文清楚地相反指示。除非另外指出，否则术语“包括”、“具有”、“包含”和“含有”将被理解为开放性术语(即，表示“包括但不限于，”)。除非本文中另外指示，否则本文中对值范围的叙述仅意欲用作单独地提及属于所述范围内的每个单独的值的速记法，并且每个单独的值合并到本说明书中，如同在本文中对所述值单独地进行叙述。除非本文中另外指示或者上下文清楚地相反指示，否则本文中描述的所有方法可以按任何合适的次序来执行。除非另外声明，否则本文中提供的任何和所有实例或示例性语言(例如，“诸如”)的使用仅意欲更好地说明本发明并且不会对本发明的范围施加限制。本说明书中的语言不应被理解为指示任何非要求权利保护的元件对于本发明的实践为必需的。

在本文中描述本发明的优选实施方案，包括发明人已知的用于实施本发明的最好模式。在阅读了前文描述之后，那些优选实施方案的变型可以变成本领域的普通技术人员显而易见的。发明人期望本领域技术人员在适当时采用此类变型，并且发明人希望本发明以不同于本文中具体描述的方式来实践。因此，本发明包括在适用法律准许时在所附权利要求中叙述的主题的所有修改和等效物。此外，除非本文中另外指示或者上下文清楚地相反指示，否则本发明涵盖上述元件以其所有可能变型的任何组合。