跳至内容

大数据/部署专用建模的实用DevOps

来自 Wikibooks,开放世界中的开放书籍

DIA 和这些 DIA 操作的大数据资产是工业创新的关键。然而,要实现数据密集型需要付出很多努力,不仅在设计方面,还在系统/基础设施配置和部署方面 - 这些仍然通过大量的手动微调和试错来完成。我们概述了支持数据密集型部署和操作的抽象和自动化,以自动化的 DevOps 方式进行,包括基础设施即代码和 TOSCA。

关于基础设施即代码和 TOSCA,它们反映了 DevOps 的策略,即在基础设施设计中采用源代码实践。更具体地说,基础设施即代码设想基础设施设计的源代码的定义、版本控制、评估、测试等,就像应用程序代码的定义、版本控制、评估和测试一样。TOSCA 是 OASIS 针对基础设施即代码的标准定义语言,代表“云应用程序的拓扑和编排规范”。

DDSM 允许使用 UML 表达 DIA 在云上的部署。

技术概述

[编辑 | 编辑源代码]

一方面,IasC 是一种典型的 DevOps 策略,它提供了标准方式来指定部署基础设施,并使用人类可读的符号来支持运营问题。IasC 范式具有以下特点:(a)用于云应用程序规范的特定领域语言(DSL),例如 TOSCA,即“云应用程序的拓扑和编排规范”标准,用于对云应用程序的部署方式进行编程;(b)特定执行器,称为编排器,它使用 IasC 蓝图,并根据这些 IasC 蓝图自动执行部署。

另一方面,DDSM 框架是一个基于 UML 的建模框架,它基于 MODAClouds4DICER 元模型,该元模型是 MODACloudsML 元模型的转置和扩展,它适应了数据密集型部署的目标和目的。MODACloudsML 是一种语言,它允许对利用基于组件的方法的多云应用程序的配置和部署进行建模。在 TOSCA 之上采用这种语言的主要动机是,我们希望使设计方法独立于 TOSCA,这样设计者不必成为 TOSCA 专家,甚至不必了解 TOSCA,而只需要遵循建议的方法。此外,MODACloudsML 语言基本上与 TOSCA 标准具有相同的目的,但它具有更高的抽象级别,因此使用起来更加友好。下图显示了 MODAClouds4DICER 元模型的摘录。主要概念直接继承自 MODACloudsML。MODACloudsML 模型是一组组件,这些组件可以由云提供商 ExternalComponents 或应用程序提供商 InternalComponents 拥有。组件可以是应用程序、平台或物理主机。虽然 ExternalComponent 只提供 Ports 和 ExecutionPlatforms,但 InternalComponent 也可以要求它们,因为它受应用程序提供商控制。Ports 和 ExecutionPlatforms 充当将组件连接到一起的方式。ProvidedPorts 和 RequiredPorts 可以通过 Relationship 概念进行链接,而 ProvidedExecutionPlatforms 和 RequiredExecutionPlatforms 可以通过 ExecutionBinding 概念进行链接。后者可以看作是两个组件之间的一种特定类型的关系,它表明其中一个组件正在执行另一个组件。

ModaClouds4TOSCA 或 DDSM 符号。

MODACloudsML 已通过扩展元素进行调整,以捕获数据密集型特定概念,例如数据密集型应用程序通常利用的系统,例如 NoSQLStorage 解决方案和 ParallelProcessingPlatforms,它们通常由一个 MasterNode 和一个或多个 SlaveNodes 组成。

DDSM UML 部署配置文件

[编辑 | 编辑源代码]

从之前的技术概述来看,在下面我们将详细说明必要的 DDSM 原型,这些原型在下面的表格中进行了介绍。


DDSM 主要原型
# 原型 含义
1. InternalNode 由应用程序所有者管理和部署的服务
2. ExternalNode 由第三方提供商管理和部署的服务
3. VMsCluster 虚拟机集群
4. PeerToPeerPlatform 以点对点方式运行的数据密集型平台
5. MasterSlavePlatform 以主从方式运行的数据密集型平台
6. StormCluster Storm 集群的一个实例
7. CassandraCluster Cassandra 集群的一个实例
8. BigDataJob 要执行的实际 DIA
9. JobSubmission BigDataJob 与其相应的执行环境之间的部署关联
  • DDSM 区分 InternalNode(应用程序所有者管理和部署的服务)和 ExternalNode(第三方提供商拥有和管理的服务,请参见 ExternalNode 原型的 providerType 属性)。InternalNodeExternalNode 原型都扩展了 UML 元类 Node


  • VMsCluster 原型被定义为 ExternalNode 的特殊化,因为租赁计算资源(如虚拟机)是云提供商提供的最主要服务之一(也称为基础设施即服务)。VMsCluster 还扩展了 Device UML 元类,因为虚拟机集群在逻辑上代表单个具有处理能力的计算资源,应用程序和服务可以在其上部署以执行。VMsCluster 具有一个 instances 属性,表示其复制因子,即组成集群的虚拟机数量。集群中的虚拟机大小相同(就内存量、内核数量、时钟频率而言),这可以通过 VMSize 枚举来定义。


  • 或者,用户可以为虚拟机的特性指定上下限(例如,minCore/maxCoreminRam/maxRam),假设所使用的云编排器能够根据某些标准确定最佳云产品,以匹配指定的界限。VMsCluster 原型对于为 DDSM 用户提供正确的抽象级别至关重要,这样他们就可以对 DIA 的部署进行建模,而无需处理底层分布式计算基础设施所带来的复杂性。事实上,用户只需要将他们的虚拟机集群建模为原型化的设备,这些设备可以包含表示托管的分布式平台的嵌套 InternalNodes。此外,一个特定的 OCL 约束规定,每个 InternalNode 必须包含在一个具有 VMsCluster 原型的设备中,因为根据定义,InternalNode 必须由应用程序提供商部署和管理,因此必须拥有必要的托管资源。


  • 然后我们定义 DIA 特定的部署抽象,即 PeerToPeerPlatformMasterSlavePlatform 原型,作为 InternalNode 的进一步特殊化。这两种原型基本上允许建模语言捕获两种通用类型分布式体系结构之间的关键差异。例如,MasterSlavePlatform 原型允许指定一个专用的主机作为主节点,因为它可能需要更多的计算资源。通过扩展我们的部署抽象,我们实现了一组技术建模元素(StormClusterCassandraCluster 等),每个元素对应于我们支持的技术。DIA 执行引擎(例如 Spark 或 Storm)也扩展了 UML ExecutionEnvironment,以便区分 DIA 作业可以提交到的这些平台。每个技术元素允许对特定于给定技术的部署方面进行建模,例如平台特定的配置参数或对其他技术的依赖关系,如果这些依赖关系是强制性的,则通过 OCL 约束来强制执行。


  • BigDataJob 原型表示可以提交到任何可用执行引擎以执行的实际应用程序。它被定义为 UML Artefact 的特殊化,因为它实际上对应于 DIA 可执行工件。它允许指定特定于作业的信息,例如可以从其中检索应用程序可执行文件的 artifactUrl。


  • JobSubmission 原型(扩展了 UML Deployment)用于指定 DIA 的其他部署选项。例如,它允许指定作业调度选项,例如它必须提交多少次以及两次后续提交之间的时间间隔。这样,可以使用不同的部署选项将相同的 DIA 作业部署在多个实例中。一个额外的 OCL 约束要求每个 BigDataJob 通过 JobSubmission 连接到一个 UML ExecutionEnvironment,该 ExecutionEnvironment 包含一个扩展 MasterSlavePlatformPeerToPeerPlatform 原型之间的原型的原型。

UML 部署建模:WikiStats 示例

[编辑 | 编辑源代码]

我们通过将定义的配置文件应用于对一个名为 Wikistats 的简单 DIA 的部署进行建模,来展示该配置文件,Wikistats 是一个流式应用程序,它处理维基媒体文章以提取有关其内容和结构的统计数据。该应用程序以 Apache Storm 作为流处理引擎,并使用 Apache Cassandra 作为存储技术。Wikistats 是一个简单示例,它展示了 DIA 需要多个异构的分布式平台,例如 Storm 和 Cassandra。此外,Storm 还依赖于 Apache Zookeeper。Wikistats 应用程序本身是一个 Storm 应用程序(一个流式作业),打包在可部署的工件中。下图显示了 Wikistats 示例的 DDSM。

Wikistats 示例的 DDSM。

在这个特定的示例场景中,所有必要的平台都部署在来自 OpenStack 安装的相同 2 个大型 VM 集群中。每个所需的平台元素都被建模为一个Node,并用相应的技术特定构造型进行注释。特别是 Storm 被建模为一个ExecutionEnvironment,因为它是执行实际 Wikistats 应用程序代码的应用程序引擎。此时,DDSM 支持的关键方面是对云基础设施和各种平台进行微调。技术构造型允许以一种易于快速测试不同配置的方式对每个平台进行配置,从而在多次部署中进行测试,并使 DIA 的持续架构成为可能。Storm 对 Zookeeper 的依赖通过先前讨论的 OCL 约束库强制执行,该库自动安装在 DDSM 配置文件中。Wikistats 应用程序的部署被建模为一个Artefact,用BigDataJob 构造型进行注释,并使用一个Deployment 依赖关系与StormCluster 元素链接,该依赖关系被构造型为JobSubmission。最后,BigDataJobJobSubmission 可用于详细说明 Wikistats 作业以及如何调度该作业。

DICE 基于 UML 的部署建模在很大程度上围绕 DDSM 展开,DDSM 是一个经过改进的 UML 配置文件,用于使用带有适当数据密集型增强构造型的简单 UML 部署图来指定基础设施即代码。

华夏公益教科书