ECOMP白皮书
来源：互联网 发布：出国语言软件 编辑：程序博客网 时间：2024/05/17 01:37
前言：
ECOMP (Enhanced Control, Orchestration, Management & Policy) Architecture White Paper，是 AT&T 前不久发布的白皮书，读者可以在https://www.sdxcentral.com/articles/news/ecomp-one-big-happy-family-open-source-groups/2016/03/?utm_source=feedblitz&utm_medium=FeedBlitzRss&utm_campaign=sdxcentral阅读相关信息，并通过此网页上的链接下载该文档。
Chiosi（AT&T公司杰出的网络架构师，同时是NFV项目组开源平台的主席，欧洲电信标准协会（ETSI）NFV ISG的成员） 认为 ECOMP 是 AT&T 正在构建的 AIC （the AT&T Integrated Cloud – AIC）的三大支柱之一（另两个是 SDN、NFV）。
http://www.3023.com/
下面，我们就来分析一下这个白皮书。
一、ECOMP 架构白皮书文档结构
【笔者注：您也可以先看第二章，再回过头来看这一章，可能更方便理解和阅读】
1.1 章节列表
我们首先就事论事，描述一下这个白皮书的文档架构/章节，如下表所示：
章节
Abstract
1. Introduction
2. ECOMP Platform
3. ETSI – NFV MANO and ECOMP Alignment
4. Metadata Driven Design Time and Runtime Execution
5. Closed-Loop Automation
6. ASDC
7. Policy
8. Orchestration
9. DCAE
10. Active & Available Inventory (A&AI)
11. Business Support Systems Require Pivot to Take Advantage of D2
12. Security
13. Today and Tomorrow
14. Summary
For Further Information
表1. ECOMP 白皮书的章节列表
下面，我们针对每一章节做一个简单的概述。
1.2 章节概述
Abstract
ECOMP 是实现 AT&T D2(Domain 2.0)目标 的关键部件
ECOMP 包含8大子系统，涵盖设计时与运行时两大场景
ECOMP 并不直接支持 Legacy Physical elements，它需要集成传统 OSS 来支持它
1. Introduction
AT&T D2 的战略是基于 NFV、SDN、Cloud 的融合，这个战略同时也塑造了 ECOMP 和 AIC
ECOMP 就是致力于解决为实现 D2 商业/战略目标所面临的技术挑战
ECOMP 通过其“元模型（metadata）驱动的设计/创建平台”和“策略驱动的实时、自动的管理平台”来加速业务上线和减少运营成本（OpEx）和成本支出（CapEx）
传统电信环境，Multi-Vendor（NMS/EMS 接口各不相同），而标准又进展缓慢， ECOMP 目标是推动开源社区与标准的融合来加速解决这一问题（我这段翻译有点问题）
【笔者注：不客气地讲，通过标准和开源（事实标准）来解决多厂商问题，前途漫漫，任重道远。 AT&T 估计也难以成就伟业】
2. ECOMP Platform
ECOMP 包含两大框架：设计时框架和运行时框架
ECOMP 的外围系统有：ECOMP Portal(for Design & Operations)，ECOMP OA&M Controller（for 运维管理 ECOMP 本身）
ECOMP 设计时核心系统： ASDC（AT&T Service Design and Creation）、Policy Creation、Analytic Application Design、Recipe/Engineer Rules & Policy Distribution（前面这三个设计器，其输出就是此）
ECOMP 运行时核心系统：A&AI(Active & Available Inventory )、MSO(Master Service Orchestrator)、Controllers、DCAE(Data Collection, Analytics and Events)
比较有意思的是其关于 Orchestrator 和 Controller 的定义，这个笔者后面会讲述
【笔者注：该章节还对各个系统做了简单介绍，篇幅原因，这个我放到后面介绍。需要注意的是，请您记住这些缩写，对后面的阅读很有帮助。】
3. ETSI – NFV MANO and ECOMP Alignment
ECOMP 在总体遵循 ETSI MANO 架构的同时，做了增强和扩展：
增加了控制器和策略组件
资源描述增强为元模型驱动的一系列的“服务、VNF、策略、约束等等”
把 MANO 认为是传统 EMS 的内容而没有包括在内的VNF 的配置归入 ECOMP 范畴，并期望推进 MANO 标准
【笔者注：对于主业是网络的人来说，不知道是喜还是悲，因为这隐含一个事实：ECOMP 的主要领域还是 NFV，跟 SDN 关系不是太大。笔者会在后面描述。】
4.Metadata Driven Design Time and Runtime Execution
ECOMP 是一个元数据（元模型）驱动的系统，无论它的一系列的设计时系统还是它的运行时系统，而且这两个系统密切相关紧密配合，一条主线/模型穿越其中。
模型不仅对属性、结构（关系）建模，还对行为（功能）建模——熟悉面向对象编程的同学都知道，这就是一个对象，不过它是用模型的语言（而不是普通编程语言比如JAVA）来描述这个对象。
ECOMP 设计时系统是业务相关的建模行为，运行时系统是业务无关的驱动行为（模型引擎）。
ECOMP 的理想是是改变开发模式：在前端，熟悉和了解业务的人员（含第三方人员）进行业务建模（通过设计时系统）；在后端，精通编程的人员（可以不熟悉业务）进行模型引擎的开发（就是运行时系统）。
这同时带来一个好处，业务的创新（变更和新增业务类型），只需要在前端修改业务模型，而无须在后端修改代码（模型引擎）——这是它的理想
ASDC 和 Policy Creation 两大系统负责前端的业务建模（属性、结构（关系），行为，策略），策略也是元模型的一种。
ASDC 集成了很多工具并支持很多类型的数据，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。
ASDC 是一个非常完备的系统，除了支持设计以外，还支持：测试、认证、发布、版本控制等，可以说，ASDC 支持了一套完整的业务开发的生命周期管理解决方案
ECOMP 同时还提供策略冲突检测，这个非常关键，“人”由于其生物性的缺陷，而不能完全察觉/检测出所有的策略的冲突，而冲突的策略，会让系统崩溃的。
【笔者注：ASDC 集成了很多工具并支持很多类型的数据，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。这句话的深意是：如果 ECOMP 没有发明一种新的建模语言而仅仅是集成（堆砌）现有的语言，笔者觉得，它的理想无法实现，它甚至没有理解真谛（虽然它好像提出了这个理想）】
5. Closed-Loop Automation
ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond
为了实现这个闭环自动化，ECOMP 提供了三大类系统（框架）：
设计框架：属性、关系、行为（Policy）设计，包括 ASDC、Policy Creation 等等
协同（编排）和控制框架：具体在下面章节描述
分析框架：事件采集（比如网络是否拥塞、VNF 是否过载等等），如果满足条件（Policy.condition），则执行相应的动作（Policy.action），以处理这个事件（具体在下面章节描述）
值得一提的是， ECOMP 还能分析历史信息（事件），以改良前期的业务设计、策略设计
6. ASDC
ASDC（AT&T Service Design and Creation）是 ECOMP设计时系统，是一个集成设计环境，包括：设计、认证、发布三大功能
ASDC 把 AT&T 的资产建模，这些资产包括：Resource、Service、Product、Offer
ASDC 的模型的物理表现形式是一个 Profile，其由两部分组成： Descriptor 和 Management Recipes
ASDC “Design Studio”本身内置一批基本模型模板，供大家使用及扩展。
ASDC 的认证系统可以提供仿真和测试功能
ASDC 的模型存储采取的而是 AT&T 内部的技术独立格式（technology independent format）（这句话到底该咋翻译？自己独立的知识产权？）
【笔者注：Recipe，这个单词，不知道对应哪个汉语词汇】
7. Policy
策略平台（原文如此，感觉“系统、平台、框架”等等名词，这个白皮书有点混用，没严格定义）是 D2 愿景中关于闭环自动化和业务生命周期管理中的不可或缺的一环。
典型的策略是 ECA 模式，Event-Condition-Action，满足一定 Condition 的 Event，触发相应的 Action。ECOMP 的 Policy 更加广义和普遍，包括 High Level 和 Low Level：
High Level： condition, requirement, constraint, or need
Low Level：基本等价于 ECA（Low Level 的描述中有“machine-readable rule”，没懂，难道 High Level Policy 不是机器可读的？机器如果读不懂，那此 Policy 有啥用呢？）
Policy 平台包括 Policy Creation、Policy Distribution、Policy Decision and Enforcement 几大部件，值得一提的是，ECOMP 中，各个运行时部件（MSO，Controllers，DACE）乃至资源本身（Cloud， Network， VNF）都有可能是 Policy 的执行体（Decision and Enforcement）
Policy 平台利用里现有的各种各样的策略技术（详见后面的描述）
【笔者注：7.4 Policy Unification and Organization，这一小节，笔者几乎看懂每一个单词，每一个句子，但是就是不知道它想表达什么，所以没写在内容简介里，感兴趣的读者可以阅读原文。】
8. Orchestration
Orchestration，翻译为汉语：编排。在这里，AT&T/ECOMP 给出了编排的定义，不管这个定义正确与否，但总算是笔者这几年来看到的唯一的一个定义，让你知道它的编排是干嘛的？
Orchestration，在 AT&T/ECOMP 的定义是： In general, Orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task.The ability to graphically design and modify a workflow process is the key differentiator between an orchestrated process and a standard compiled set of procedural code.（我原文摘抄，尽可能保证原汁原味，红色文字比较有意思，值得深思。）
与传统不同，这里的 Orchestration，不仅仅是协同器（Orchestrator）一个部件完成的工作，它是协同器和控制器一起完成的。在 ECOMP 里完成 Orchestration 的是：MSO（Master Service Orchestrator）、Infrastructure, Network and Application Controllers。
在 ECOMP 这个语境里，Orchestration 完成的是的任务是： Service Delivery or Changes to existing Service，包括 VM 的申请，VNF 的实例化，对应网络的打通， VNF 的配置等等
【笔者注：AT&T 关于 编排的定义，也就是一家之言，各位大可不必奉为权威。在创新的时代，新的名词可以有不同的解读，这符合创新精神。但是天天把编排挂在嘴边而不知所云，那就不好了。】
9. DCAE
前面说过，ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond，而 DCAE（Data Collection, Analytics and Events，我总感觉老外的语文不好，这句话咋翻译？数据采集、分析和事件？这也不通啊。唉，我们理解这意思就行，^_^）所做的事就是从上面“Collect”到“Publish”之间的事情：“Collect Data -> Analyze & Correlate -> Detect Anomalies -> Publish need for Action”.（实际上 DCAE 也内置和集成很多了很多 Application，其目的就是“Respond”）
DCAE 包括：Common Collection Framework, Data Movement, Edge & Central Lake, Analytic Framework, and Analytic Applications
【笔者注：Edge & Central Lake，Data Lake（老外就爱捅词）: A data lake is a massive, easily accessible, centralized repository of large volumes of structured and unstructured data.】
10. Active & Available Inventory (A&AI)
Active and Available Inventory (A&AI) is the ECOMP component that provides real-time views of D2 Resources, Services, Products, and Customer Subscriptions for D2 services. （我原文摘抄，翻译和总结，在这句话面前，都是徒劳的，^_^）
A&AI，使用“图”技术来存储存量之间的关系
A&AI data views are used by homing logic during real-time service delivery, root cause analysis of problems, impact analysis, capacity management, software license management and many other D2 functions.（继续原文摘抄，不是我懒，而是觉得翻译反而会失去原味）
值得一提的是，A&AI 还有一个功能：Identify the controllers to be used for any particular request.（MSO 决定选择哪一个控制器的时候，就是利用此功能）
A&AI 还会维护 Inventory 与其他没有包含在 ECOMP 中的其他实体之间的关系，Maintain relationships to other key entities (e.g., location) as well as non-D2 inventory
【笔者注：A&AI 的数据来源很关键，没有数据来源，等于无源之水。这个笔者会在下文简单描述】
11. Business Support Systems Require Pivot to Take Advantage of D2
BSS 不是 ECOMP 的范围，只是在 AT&T D2 中， BSS 会与 ECOMP 有紧密交互。（到此为止，不再介绍。BSS 是 AT&T 的重点，但不是本文关注的重点）
12. Security
ECOMP 的安全包括其自身系统的安全和它所交付的业务（产品）的安全：security of the platform itself and the capability to integrate security into the cloud services.
为保证安全，ECOMP 除了增强自身的安全基因/措施（部署于安全位置，严格地代码安全检查和测试等等）以外还集成外部安全系统，比如 IAM（偏向与保证 ECOMP 自身），比如 Astra（AT&T 自有知识产权并获奖的产品， ISE® Northeast Project Award Winner 2015 ）
ECOMP 通过 DCAE 和 Policy 系统进行安全分析与防范
13. Today and Tomorrow
In 2015, AT&T successfully deployed 74 AIC nodes (exceeding its target of 69) and surpassed its goal of virtualizing 5% of the target network load.
In the near future, ECOMP will be providing open platform capabilities via the ECOMP Design Framework that enables 3rd parties to make use of, integrate with, create and enhance capabilities of D2 functions or services.
To expedite the delivery of Platform components, AT&T has a preference towards open source software and industry standards.
14. Summary
ECOMP is an open software platform. It is currently optimized to deliver an open management platform for defining, operating and managing products and service based upon virtualized network and infrastructure resources and software
As a network management platform, it includes a framework consistent across cloud infrastructure, applications and network management components
ECOMP is critical in achieving AT&T’s D2 imperatives: increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies.
【笔者注：给总结写总结，我的内心是崩溃的，^_^】
For Further Information
lIf you have questions regarding ECOMP please contact https://www.attsuppliers.com/domain2.asp ......
从第13小节开始，ECOMP 一直在“告别”，艾玛，真啰嗦，整整写了三小节，^_^
二、ECOMP 架构白皮书软件架构
2.1 ECOMP 的范围、场景和目标
每年，AT&T公司的资本支出花费大约200亿美元，这其中的大头当属其庞大的网络开支，而该公司最近宣布了一项大胆的计划：采用软件定义网络（SDN）和网络功能虚拟化（NFV）。AT&T公司架构与设计高级副总裁Andre Fuetsch 在采访中说：让我来进一步明确一下我们的这一目标吧。我们的目标是通过部署虚拟化，到2020年，让我们的 Domain 2.0架构控制我们75%的目标网络。【注】
【注：摘自http://www.gzpbs.com/html/9381462515.html】
AT&T Domain 2.0 的核心就是 AIC（the AT&T Integrated Cloud – AIC）和 NFV， AIC 是它的范围，NFV 是它的技术手段。（咦，怎么漏了 SDN？我不客气地跟你讲，SDN 在不同的语境下有不同的含义，但是很多时候，SDN 最大的作用是拿来应景的，因为不提 SDN，政治上不正确，后面我会继续论述这一问题）。
AT&T D2（Domain 2.0）概念的提出，也跟当前数据中心的发展趋势密切相关。当前，大型化、虚拟化、综合化数据中心服务是主要特征，尤其是云计算技术引入后，数据中心突破了原有的场地出租、线路带宽共享、主机托管维护、应用托管等服务，更注重数据的存储和计算能力的虚拟化、设备维护管理的综合化。新型数据中心采用高性能基础架构，实现资源按需提供服务，并通过规模运营降低能耗。由此，云计算数据中心概念被提出：在数据中心的物理基础设施上，采用虚拟化等云计算技术，提供传统的数据中心业务和各种新型网络应用服务。【注】
【注：摘自http://wenku.baidu.com/link?url=Ey_fqzQEEXQh1LFBu1ESGyaoExEyGrh0a4Vfz8vONm8vKZDMRCA2_nAqXr5bCP8ufRx6RyLLHeaw7nSWagwdCwWRXSdJJeUrO1tQ8-icim7】
而 ECOMP 就是为 AT&T D2/AIC 而生的，它是一个开放的软件平台，纵贯云基础设施（Cloud）、网络和VNF（有时候也叫作 Application）的管理，集美貌与智慧与一身（设计平台与运行平台），通过 Cloud/SDN/NFV 等技术，为实现如下目标而努力：increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies。（请原谅，这段话笔者就不献丑了，不翻译了）
总结一下，ECOMP 的范围、场景和目标：
范围：为 AT&T D2 服务，严格地说，为 AIC 服务
场景：Cloud 是基础，NFV 是核心，SDN 是辅助
目标：AT&T D2/AIC 的强力支柱，increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies
2.2 ECOMP 架构剖析
2.2.1 ECOMP 集美貌与智慧与一身
2.2.1.1 架构概述
ECOMP 是一个集成了设计时与运行时与一体的开放软件平台，如下图所示：
图1 ECOMP：设计 运行
ECOMP 并不是简单集成这两个框架/平台，而是非常紧密的结合，而结合两者的就是“Model”（ECOMP 原文是 Metadata，有时候也称为 metadata model，本文采用 Model 一词，感觉更顺口。但是必须承认，metadata，更准确。）
设计时框架的输出“Model”，就是运行时框架的输入，两者实现无缝对接（关于这一点，笔者会在下面的章节中继续描述）。
我们把 ECOMP 的架构继续打开，如下图所示：
图2ECOMP：设计 运行，组件展开
上述图中，各组件的信息，请参考“1.2 章节概述”，这里只挑几个重点再描述一下。
2.2.1.2 MSO & Controllers
按照经典/传统概念理解，Orchestration（有时候翻译为编排，有时候反应为协同，这里指的是编排）是 Orchestrator（协同器）的职责，而 Controller（控制器）负责 Control（控制）。但是我不客气也不谦虚地讲，所谓协同、所谓编排，所谓控制，到现在为止，一塌糊涂，尤其是在 SDN 领域——而 SDN 本身的概念也是一塌糊涂，这个笔者会在后面论述——这些概念没有明确的定义，Orchestrator 与 Controller 的职责与范围一直纠缠不清。
ECOMP 比较优雅地解决了这一问题，它不仅把编排（Orchestration）做了一个明确的定义，也把 Orchestrator 和 Controller 的职责与范围做了明确的划分。
ECOMP 首先给编排（Orchestration）的定义是：In general, Orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task.The ability to graphically design and modify a workflow process is the key differentiator between an orchestrated process and a standard compiled set of procedural code.
请您仔细阅读这段英文，尤其是红色文字。我对这个定义的态度是：欲迎还拒！首先对于它给出了明确定义这一点，我是欢迎的；但是，这个定义正确与否，我是怀疑的，仅仅是通过 workflow，就能达到编排的目标（Service Delivery or Changes to existing Service）？我非常抗拒！！！
不过无论怎么说，其毕竟给出了编排（Orchestration）的明确定义，我们总体还是持欢迎态度吧。
前文已经提及，编排（Orchestration）的目标是：Service Delivery or Changes to existing Service。为了达成这一目标，ECOMP 使用了 MSO（Master Service Orchestrator）与 Controller（Infrastructure, Network and Application Controllers）一起来完成这个工作，如下图所示：
图3Orchestration（编排）
在完成 Orchestration（编排）这一工作时，各部件的分工如下表所示：
部件
分工
MSO
MSO 负责接收请求并响应，也就是说 MSO 首先是 E2E 负责
分析并分拆 Request，转换为各种资源请求（创建资源），并发送资源请求给各个对应的 Controller
VM 及 VNF的创建发送给 Infrastructure Controller，网络打通（LAN or WAN）发送给 Network Controller, VNF 配置，发送给 Application Controller
由于存在多个控制器实例（不仅仅是多类型），MSO 需要确定合适的控制器实例，这一点，它是从 A&AI 那里获取有效信息
值得一提的是，如果没有合适的控制器实例，MSO 还负责创建一个控制器
同时， MSO 也会将各个 Controller 创建的资源通知 A&AI，令其更新
Infrastructure Controller
创建 VM 及 VNF
Network Controller
打通网络（LAN/WAN/ACCESS）
特别说明：不负责打通 Legacy 网络，必须提前 Ready
Application Controller
VNF 配置
表2. Orchestration 各部件分工
这里我们看到，MSO 在 Orchstration 功能中，除了 E2E 负责（Request/Response）以外，用一句话总结它的职责，就是：资源的分解和分配；而各个控制器的职责就是资源的创建（or 配置）。
还是那句话，对于 ECOMP 关于 Orchestration 的定义与分工，笔者持赞同和欢迎态度，但是对于其能通过 workflow 就能完成 Orchestration 的工作，笔者保留怀疑态度，期待能有更详细的信息以解决笔者心中的困惑。
欲迎还拒！
2.2.1.3 A&AI
得资源者，得天下！
A&AI，Active & Available Inventory，讲述了一些功能和要求，在笔者看来，这些功能和要求，中规中矩，但是，有一点必须强调，资源是一切的基础，如果您想有所追求的话（笔者在后面的章节中，会继续涉及这个话题）。
得资源者得天下！天下几人识此言？
在资源系统中，最难的应该是实时资源采集（及业务还原）。这一点，ECOMP 可能是由于篇幅原因，并没有怎么涉及（也可能其主要领域是 NFV，并没有深入 WAN/LAN 这一领域，资源实时采集这一块，可能并不太是痛点），只是简单带过其资源的来源：MSO、Controllers、DCAE、BSS/OSS、3rd party cloud provider......
实时资源采集（及业务还原）问题不解决，一切都是空......
当然，毕竟 ECOMP 架构白皮书，由于其白皮书的特质，不在这一点细节纠缠也是可以理解的，毕竟白皮书的目的是宣传其理念和逼格。那么 ECOMP 的理念和逼格又是什么呢？
2.2.2 模型打通了任督二脉
用 ECOMP 自己的话说，就是：Metadata Driven Design Time and Runtime Execution。我们一般习惯说，模型驱动（model driven），这样更顺口，但是 ECOMP 的 metadata driven，更准确（这个笔者会在后面解释）。
模型打通了任督二脉，指的是模型（model/metadata）贯穿了设计与开发的始终，并驱动了设计与开发，如下图所示：
图4模型打通了任督二脉
【手机上阅读，图上的字可能看不清楚，但是还是建议您仔细阅读，这是 ECOMP 的理念之一。】
这非常神奇！
熟悉笔者的人，可能会觉得“这非常神奇”这句话是贬义。确实，笔者不相信这样确实能实现，但是在这里，笔者并不是表达贬义，而是表达敬意！
咋一看，这个跟 Tail-f 宣称的“MBD（基于模型的开发）/MDD（模型驱动开发）”很像，而熟悉笔者的人知道，笔者一直是对 Tail-f 没有什么好感，它吹牛太盛！
【如果您感兴趣，可以关注“标哥说天下”，发送相关信息，可以获取笔者以前发表的相关文章，本文最后会列出发送什么信息，获取什么文章】
但是，ECOMP 跟 Tail-f 显著的不同是，Tail-f 仅仅提出了一个模型驱动框架，一个非常纯粹的框架，而 ECOMP 却实实在在地提出了模型——metadata（这就是我前面说的，metadata 更准确），它给出了 metadata 的定义（当然，因为仅仅从白皮书中也只是能看出个示意，具体详细的模型还有待 AT&T 进一步发布）。
另外，同样是叫作“模型引擎”，Tail-f 的模型驱动框架，仅仅是一个 YANG 模型引擎和命令行生成引擎（比这强一点，但是强不到哪里去，你读懂了我这句话，就读懂了 Tail-f），而 ECOMP 的模型引擎（就是设计时框架），我们看到，包括：MSO、Controllers、A&AI、DCAE 等等一些列组件，一些列实打实的组件......
有点跑题了......^_^
我这么贬低 Tail-f，不是代表我盲目崇拜 ECOMP。实际上，正如我前面所说，metadata，仅仅从白皮书中也只是能看出个示意，具体详细的模型还有待 AT&T 进一步发布。在没有详细的 metadata 发布之前，一切都是空的。
从白皮书中，我们可以看到 metadata 的一些蛛丝马迹。ECOMP 的 metadata 包括：结构、方法和策略，如下图所示：
图5ECOMP metadata 概述
图，我是原版 copy 的 ECOMP 白皮书中的图，红色字体是我加的说明，还是那句话，建议您仔细看看这张图。
ECOMP 白皮书没有进一步透露 metadata 的细节。metadata 中，对象及对象之间的关系，从抽象建模技术角度而言，相对简单，其原语无非是包含、关联之类的，而“行为和策略”这两点就非常困难，这是一个“易用性和灵活性”之间的天然不可调和的矛盾：
追求易用性，就需要提供（发明）很多原语，才能达到完备性（如果完备性不够，则很多需求没法表达）。而要想达到完备性，则非常非常困难。（我在后面会继续展开描述）
追求灵活性，追求到极致，就是 C /JAVA/Python 之类的编程语言，足够灵活，但是已经失去意义（我如果使用了 C /JAVA/Python 之类的编程语言，我要你这个 metadata driver 框架干嘛？）
我前面说了，要想达到完备性，非常非常困难，这里我简单展开描述一下：
所谓原语，所谓易用性，从某种意义上讲，就是代号，比如“A”代表：蛋炒饭加两鸡蛋不放葱花口味淡一点吧啦吧啦，“B”代表：鱼香肉丝不要放鱼不要甜只要辣吧啦吧啦。你到饭店只需说：“A B”，不需要吧啦吧啦吧啦吧啦吧啦一大堆，人家就明白你的意思。这就是原语，这就是易用性。
可是，这只是看起来很美好。我们仍然拿饭店来说，有的人感冒了希望放点姜丝，有的人不希望放姜丝，有的人喜欢微辣，有的人喜欢甜，有的人蛋炒饭不要鸡蛋，有的人......这样的需求不是无穷的，也是无尽的。我们如果追求易用性，追求原语，那么将会疲于奔命，没完没了。而且更可怕的是，这样的开发模式将变为灾难，如下图所示：
图6MetaData Driven 开发模式的灾难
ECOMP 没有在这些细节上着墨，其只是提到了其可能用到的建模工具和数据类型，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。
我不谦虚地讲，如果 ECOMP 只是使用现有的建模工具/建模语言进行一些堆砌而没有自己的发明创新，那么其要想达到其理想目标......不大可能（当然，另一种情况是我理解错了 ECOMP 的真实想法......）
在这一小节中，我提到了策略，那么策略是什么，策略又发挥了什么作用呢？
2.2.3 策略成就了雄霸天下
首先，说明一点，策略（Policy）也是 Metadata 的一种。只是策略太多重要，所以我们拿出来专门讲述——实际上，ECOMP 也花了很大的篇幅讲述策略。
ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond。
Design -> Create，是我们上一小节讲述的内容，通过 metadata driven，它的设计和执行（执行包括 create）是一体的，一个业务相关的模型，一个业务无关的引擎，就完成这些工作。
Collect -> Analyze -> Detect-> Publish -> Respond，仍然是 metadata driven 的一部分，但是这里要特别强调 Policy（策略），没有策略，这一切无从谈起。
ECOMP 的 Policy，总的来说，还是符合 ECA 范式：Event-Condition-Action。这里面 Event、Condition、Action 都需要建模，这个模型能不能建好，笔者在上一小节已经涉及，这里不再重复。现在我们就假设这些模型已经建好，看看它的架构吧。
首先我们看策略平台（设计、发布、执行）本身的架构，如下图所示：
图7策略平台架构
这个架构有两点需要特别注意：
策略模板（策略的具体定义），就是我在上一节中说的，如果定义不好，一切都是空。不过笔者现在无法知晓 ECOMP 的 Policy 的详细定义
策略执行，就是上图中最右侧的那一个方框。我们看到，任何组件，包括基础设施本身，都有可能是策略的执行体。
仅仅是有策略的定义，策略的执行是不够的，它还需要一个触发条件，就是前面说的“Event-Condition”，ECOMP 执行事件采集和条件分析的组件是 DCAE，其架构图如下：
图8DCAE 架构图
架构图本身，没什么太多需要讲述，一切尽在图中。不过我们需要通过这张图，能想象出来它的关键技术：采集、分析、存储——巨大数据的实时采集、分析与存储，绝对不是一件容易的事情。（不过这也更进一步加剧我前面的怀疑：什么样的 metadata driven，能够做这么复杂的事情？算了，不纠结了，^_^）
关于策略建模技术，ECOMP 倒是列举了一系列的技术，如下图所示：
图9Policy Technologies
我还是坚持那个观点，如果仅仅是靠这些 Policy Technologies 的堆砌，我怀疑 ECOMP 那个 metadata driven 的目标能否达成。
这里笔者还想再提一点，就是上图中的“OpenStack Congress”，笔者感觉其讲得非常好：Detect policy violation for OpenStack Resources。它就是一个 OpenStack 资源冲突检查工具，说它是策略都勉为其难，而且它的语法特别晦涩甚至已经到了恶心的地步。唉，不说了，太烦......（而且，跑题了，^_^）
我们一直还没有提“Respond”，从语义上说，“Respond”就是“ECA”中的“A”（Action），我们在图7中，也涉及到了这一点。笔者在这里想强调的是，一个好的“Respond”正是 ECOMP 宣称的“Closed Loop Automation”的最后一步：临门一脚！
到现在为止，我们介绍了 ECOMP 的几个关键句：
集美貌与智慧与一身
模型打通了任督二脉
策略成就了雄霸天下
下面我们看看 ECOMP 架构的真身吧。
2.2.4 ECOMP 总体架构图
憋说话，上图！
图10ECOMP Platform components
图11ECOMP Platform Decomposition
来源：3023.com
原文：http://www.3023.com/3/034930021.html
ECOMP (Enhanced Control, Orchestration, Management & Policy) Architecture White Paper，是 AT&T 前不久发布的白皮书，读者可以在https://www.sdxcentral.com/articles/news/ecomp-one-big-happy-family-open-source-groups/2016/03/?utm_source=feedblitz&utm_medium=FeedBlitzRss&utm_campaign=sdxcentral阅读相关信息，并通过此网页上的链接下载该文档。
Chiosi（AT&T公司杰出的网络架构师，同时是NFV项目组开源平台的主席，欧洲电信标准协会（ETSI）NFV ISG的成员） 认为 ECOMP 是 AT&T 正在构建的 AIC （the AT&T Integrated Cloud – AIC）的三大支柱之一（另两个是 SDN、NFV）。
http://www.3023.com/
下面，我们就来分析一下这个白皮书。
一、ECOMP 架构白皮书文档结构
【笔者注：您也可以先看第二章，再回过头来看这一章，可能更方便理解和阅读】
1.1 章节列表
我们首先就事论事，描述一下这个白皮书的文档架构/章节，如下表所示：
章节
Abstract
1. Introduction
2. ECOMP Platform
3. ETSI – NFV MANO and ECOMP Alignment
4. Metadata Driven Design Time and Runtime Execution
5. Closed-Loop Automation
6. ASDC
7. Policy
8. Orchestration
9. DCAE
10. Active & Available Inventory (A&AI)
11. Business Support Systems Require Pivot to Take Advantage of D2
12. Security
13. Today and Tomorrow
14. Summary
For Further Information
表1. ECOMP 白皮书的章节列表
下面，我们针对每一章节做一个简单的概述。
1.2 章节概述
Abstract
ECOMP 是实现 AT&T D2(Domain 2.0)目标 的关键部件
ECOMP 包含8大子系统，涵盖设计时与运行时两大场景
ECOMP 并不直接支持 Legacy Physical elements，它需要集成传统 OSS 来支持它
1. Introduction
AT&T D2 的战略是基于 NFV、SDN、Cloud 的融合，这个战略同时也塑造了 ECOMP 和 AIC
ECOMP 就是致力于解决为实现 D2 商业/战略目标所面临的技术挑战
ECOMP 通过其“元模型（metadata）驱动的设计/创建平台”和“策略驱动的实时、自动的管理平台”来加速业务上线和减少运营成本（OpEx）和成本支出（CapEx）
传统电信环境，Multi-Vendor（NMS/EMS 接口各不相同），而标准又进展缓慢， ECOMP 目标是推动开源社区与标准的融合来加速解决这一问题（我这段翻译有点问题）
【笔者注：不客气地讲，通过标准和开源（事实标准）来解决多厂商问题，前途漫漫，任重道远。 AT&T 估计也难以成就伟业】
2. ECOMP Platform
ECOMP 包含两大框架：设计时框架和运行时框架
ECOMP 的外围系统有：ECOMP Portal(for Design & Operations)，ECOMP OA&M Controller（for 运维管理 ECOMP 本身）
ECOMP 设计时核心系统： ASDC（AT&T Service Design and Creation）、Policy Creation、Analytic Application Design、Recipe/Engineer Rules & Policy Distribution（前面这三个设计器，其输出就是此）
ECOMP 运行时核心系统：A&AI(Active & Available Inventory )、MSO(Master Service Orchestrator)、Controllers、DCAE(Data Collection, Analytics and Events)
比较有意思的是其关于 Orchestrator 和 Controller 的定义，这个笔者后面会讲述
【笔者注：该章节还对各个系统做了简单介绍，篇幅原因，这个我放到后面介绍。需要注意的是，请您记住这些缩写，对后面的阅读很有帮助。】
3. ETSI – NFV MANO and ECOMP Alignment
ECOMP 在总体遵循 ETSI MANO 架构的同时，做了增强和扩展：
增加了控制器和策略组件
资源描述增强为元模型驱动的一系列的“服务、VNF、策略、约束等等”
把 MANO 认为是传统 EMS 的内容而没有包括在内的VNF 的配置归入 ECOMP 范畴，并期望推进 MANO 标准
【笔者注：对于主业是网络的人来说，不知道是喜还是悲，因为这隐含一个事实：ECOMP 的主要领域还是 NFV，跟 SDN 关系不是太大。笔者会在后面描述。】
4.Metadata Driven Design Time and Runtime Execution
ECOMP 是一个元数据（元模型）驱动的系统，无论它的一系列的设计时系统还是它的运行时系统，而且这两个系统密切相关紧密配合，一条主线/模型穿越其中。
模型不仅对属性、结构（关系）建模，还对行为（功能）建模——熟悉面向对象编程的同学都知道，这就是一个对象，不过它是用模型的语言（而不是普通编程语言比如JAVA）来描述这个对象。
ECOMP 设计时系统是业务相关的建模行为，运行时系统是业务无关的驱动行为（模型引擎）。
ECOMP 的理想是是改变开发模式：在前端，熟悉和了解业务的人员（含第三方人员）进行业务建模（通过设计时系统）；在后端，精通编程的人员（可以不熟悉业务）进行模型引擎的开发（就是运行时系统）。
这同时带来一个好处，业务的创新（变更和新增业务类型），只需要在前端修改业务模型，而无须在后端修改代码（模型引擎）——这是它的理想
ASDC 和 Policy Creation 两大系统负责前端的业务建模（属性、结构（关系），行为，策略），策略也是元模型的一种。
ASDC 集成了很多工具并支持很多类型的数据，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。
ASDC 是一个非常完备的系统，除了支持设计以外，还支持：测试、认证、发布、版本控制等，可以说，ASDC 支持了一套完整的业务开发的生命周期管理解决方案
ECOMP 同时还提供策略冲突检测，这个非常关键，“人”由于其生物性的缺陷，而不能完全察觉/检测出所有的策略的冲突，而冲突的策略，会让系统崩溃的。
【笔者注：ASDC 集成了很多工具并支持很多类型的数据，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。这句话的深意是：如果 ECOMP 没有发明一种新的建模语言而仅仅是集成（堆砌）现有的语言，笔者觉得，它的理想无法实现，它甚至没有理解真谛（虽然它好像提出了这个理想）】
5. Closed-Loop Automation
ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond
为了实现这个闭环自动化，ECOMP 提供了三大类系统（框架）：
设计框架：属性、关系、行为（Policy）设计，包括 ASDC、Policy Creation 等等
协同（编排）和控制框架：具体在下面章节描述
分析框架：事件采集（比如网络是否拥塞、VNF 是否过载等等），如果满足条件（Policy.condition），则执行相应的动作（Policy.action），以处理这个事件（具体在下面章节描述）
值得一提的是， ECOMP 还能分析历史信息（事件），以改良前期的业务设计、策略设计
6. ASDC
ASDC（AT&T Service Design and Creation）是 ECOMP设计时系统，是一个集成设计环境，包括：设计、认证、发布三大功能
ASDC 把 AT&T 的资产建模，这些资产包括：Resource、Service、Product、Offer
ASDC 的模型的物理表现形式是一个 Profile，其由两部分组成： Descriptor 和 Management Recipes
ASDC “Design Studio”本身内置一批基本模型模板，供大家使用及扩展。
ASDC 的认证系统可以提供仿真和测试功能
ASDC 的模型存储采取的而是 AT&T 内部的技术独立格式（technology independent format）（这句话到底该咋翻译？自己独立的知识产权？）
【笔者注：Recipe，这个单词，不知道对应哪个汉语词汇】
7. Policy
策略平台（原文如此，感觉“系统、平台、框架”等等名词，这个白皮书有点混用，没严格定义）是 D2 愿景中关于闭环自动化和业务生命周期管理中的不可或缺的一环。
典型的策略是 ECA 模式，Event-Condition-Action，满足一定 Condition 的 Event，触发相应的 Action。ECOMP 的 Policy 更加广义和普遍，包括 High Level 和 Low Level：
High Level： condition, requirement, constraint, or need
Low Level：基本等价于 ECA（Low Level 的描述中有“machine-readable rule”，没懂，难道 High Level Policy 不是机器可读的？机器如果读不懂，那此 Policy 有啥用呢？）
Policy 平台包括 Policy Creation、Policy Distribution、Policy Decision and Enforcement 几大部件，值得一提的是，ECOMP 中，各个运行时部件（MSO，Controllers，DACE）乃至资源本身（Cloud， Network， VNF）都有可能是 Policy 的执行体（Decision and Enforcement）
Policy 平台利用里现有的各种各样的策略技术（详见后面的描述）
【笔者注：7.4 Policy Unification and Organization，这一小节，笔者几乎看懂每一个单词，每一个句子，但是就是不知道它想表达什么，所以没写在内容简介里，感兴趣的读者可以阅读原文。】
8. Orchestration
Orchestration，翻译为汉语：编排。在这里，AT&T/ECOMP 给出了编排的定义，不管这个定义正确与否，但总算是笔者这几年来看到的唯一的一个定义，让你知道它的编排是干嘛的？
Orchestration，在 AT&T/ECOMP 的定义是： In general, Orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task.The ability to graphically design and modify a workflow process is the key differentiator between an orchestrated process and a standard compiled set of procedural code.（我原文摘抄，尽可能保证原汁原味，红色文字比较有意思，值得深思。）
与传统不同，这里的 Orchestration，不仅仅是协同器（Orchestrator）一个部件完成的工作，它是协同器和控制器一起完成的。在 ECOMP 里完成 Orchestration 的是：MSO（Master Service Orchestrator）、Infrastructure, Network and Application Controllers。
在 ECOMP 这个语境里，Orchestration 完成的是的任务是： Service Delivery or Changes to existing Service，包括 VM 的申请，VNF 的实例化，对应网络的打通， VNF 的配置等等
【笔者注：AT&T 关于 编排的定义，也就是一家之言，各位大可不必奉为权威。在创新的时代，新的名词可以有不同的解读，这符合创新精神。但是天天把编排挂在嘴边而不知所云，那就不好了。】
9. DCAE
前面说过，ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond，而 DCAE（Data Collection, Analytics and Events，我总感觉老外的语文不好，这句话咋翻译？数据采集、分析和事件？这也不通啊。唉，我们理解这意思就行，^_^）所做的事就是从上面“Collect”到“Publish”之间的事情：“Collect Data -> Analyze & Correlate -> Detect Anomalies -> Publish need for Action”.（实际上 DCAE 也内置和集成很多了很多 Application，其目的就是“Respond”）
DCAE 包括：Common Collection Framework, Data Movement, Edge & Central Lake, Analytic Framework, and Analytic Applications
【笔者注：Edge & Central Lake，Data Lake（老外就爱捅词）: A data lake is a massive, easily accessible, centralized repository of large volumes of structured and unstructured data.】
10. Active & Available Inventory (A&AI)
Active and Available Inventory (A&AI) is the ECOMP component that provides real-time views of D2 Resources, Services, Products, and Customer Subscriptions for D2 services. （我原文摘抄，翻译和总结，在这句话面前，都是徒劳的，^_^）
A&AI，使用“图”技术来存储存量之间的关系
A&AI data views are used by homing logic during real-time service delivery, root cause analysis of problems, impact analysis, capacity management, software license management and many other D2 functions.（继续原文摘抄，不是我懒，而是觉得翻译反而会失去原味）
值得一提的是，A&AI 还有一个功能：Identify the controllers to be used for any particular request.（MSO 决定选择哪一个控制器的时候，就是利用此功能）
A&AI 还会维护 Inventory 与其他没有包含在 ECOMP 中的其他实体之间的关系，Maintain relationships to other key entities (e.g., location) as well as non-D2 inventory
【笔者注：A&AI 的数据来源很关键，没有数据来源，等于无源之水。这个笔者会在下文简单描述】
11. Business Support Systems Require Pivot to Take Advantage of D2
BSS 不是 ECOMP 的范围，只是在 AT&T D2 中， BSS 会与 ECOMP 有紧密交互。（到此为止，不再介绍。BSS 是 AT&T 的重点，但不是本文关注的重点）
12. Security
ECOMP 的安全包括其自身系统的安全和它所交付的业务（产品）的安全：security of the platform itself and the capability to integrate security into the cloud services.
为保证安全，ECOMP 除了增强自身的安全基因/措施（部署于安全位置，严格地代码安全检查和测试等等）以外还集成外部安全系统，比如 IAM（偏向与保证 ECOMP 自身），比如 Astra（AT&T 自有知识产权并获奖的产品， ISE® Northeast Project Award Winner 2015 ）
ECOMP 通过 DCAE 和 Policy 系统进行安全分析与防范
13. Today and Tomorrow
In 2015, AT&T successfully deployed 74 AIC nodes (exceeding its target of 69) and surpassed its goal of virtualizing 5% of the target network load.
In the near future, ECOMP will be providing open platform capabilities via the ECOMP Design Framework that enables 3rd parties to make use of, integrate with, create and enhance capabilities of D2 functions or services.
To expedite the delivery of Platform components, AT&T has a preference towards open source software and industry standards.
14. Summary
ECOMP is an open software platform. It is currently optimized to deliver an open management platform for defining, operating and managing products and service based upon virtualized network and infrastructure resources and software
As a network management platform, it includes a framework consistent across cloud infrastructure, applications and network management components
ECOMP is critical in achieving AT&T’s D2 imperatives: increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies.
【笔者注：给总结写总结，我的内心是崩溃的，^_^】
For Further Information
lIf you have questions regarding ECOMP please contact https://www.attsuppliers.com/domain2.asp ......
从第13小节开始，ECOMP 一直在“告别”，艾玛，真啰嗦，整整写了三小节，^_^
二、ECOMP 架构白皮书软件架构
2.1 ECOMP 的范围、场景和目标
每年，AT&T公司的资本支出花费大约200亿美元，这其中的大头当属其庞大的网络开支，而该公司最近宣布了一项大胆的计划：采用软件定义网络（SDN）和网络功能虚拟化（NFV）。AT&T公司架构与设计高级副总裁Andre Fuetsch 在采访中说：让我来进一步明确一下我们的这一目标吧。我们的目标是通过部署虚拟化，到2020年，让我们的 Domain 2.0架构控制我们75%的目标网络。【注】
【注：摘自http://www.gzpbs.com/html/9381462515.html】
AT&T Domain 2.0 的核心就是 AIC（the AT&T Integrated Cloud – AIC）和 NFV， AIC 是它的范围，NFV 是它的技术手段。（咦，怎么漏了 SDN？我不客气地跟你讲，SDN 在不同的语境下有不同的含义，但是很多时候，SDN 最大的作用是拿来应景的，因为不提 SDN，政治上不正确，后面我会继续论述这一问题）。
AT&T D2（Domain 2.0）概念的提出，也跟当前数据中心的发展趋势密切相关。当前，大型化、虚拟化、综合化数据中心服务是主要特征，尤其是云计算技术引入后，数据中心突破了原有的场地出租、线路带宽共享、主机托管维护、应用托管等服务，更注重数据的存储和计算能力的虚拟化、设备维护管理的综合化。新型数据中心采用高性能基础架构，实现资源按需提供服务，并通过规模运营降低能耗。由此，云计算数据中心概念被提出：在数据中心的物理基础设施上，采用虚拟化等云计算技术，提供传统的数据中心业务和各种新型网络应用服务。【注】
【注：摘自http://wenku.baidu.com/link?url=Ey_fqzQEEXQh1LFBu1ESGyaoExEyGrh0a4Vfz8vONm8vKZDMRCA2_nAqXr5bCP8ufRx6RyLLHeaw7nSWagwdCwWRXSdJJeUrO1tQ8-icim7】
而 ECOMP 就是为 AT&T D2/AIC 而生的，它是一个开放的软件平台，纵贯云基础设施（Cloud）、网络和VNF（有时候也叫作 Application）的管理，集美貌与智慧与一身（设计平台与运行平台），通过 Cloud/SDN/NFV 等技术，为实现如下目标而努力：increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies。（请原谅，这段话笔者就不献丑了，不翻译了）
总结一下，ECOMP 的范围、场景和目标：
范围：为 AT&T D2 服务，严格地说，为 AIC 服务
场景：Cloud 是基础，NFV 是核心，SDN 是辅助
目标：AT&T D2/AIC 的强力支柱，increase the value of our network to customers by rapidly on-boarding of new services (created by AT&T or 3rd parties), reduce CapEx and OpEx, and provide Operations efficiencies
2.2 ECOMP 架构剖析
2.2.1 ECOMP 集美貌与智慧与一身
2.2.1.1 架构概述
ECOMP 是一个集成了设计时与运行时与一体的开放软件平台，如下图所示：
图1 ECOMP：设计 运行
ECOMP 并不是简单集成这两个框架/平台，而是非常紧密的结合，而结合两者的就是“Model”（ECOMP 原文是 Metadata，有时候也称为 metadata model，本文采用 Model 一词，感觉更顺口。但是必须承认，metadata，更准确。）
设计时框架的输出“Model”，就是运行时框架的输入，两者实现无缝对接（关于这一点，笔者会在下面的章节中继续描述）。
我们把 ECOMP 的架构继续打开，如下图所示：
图2ECOMP：设计 运行，组件展开
上述图中，各组件的信息，请参考“1.2 章节概述”，这里只挑几个重点再描述一下。
2.2.1.2 MSO & Controllers
按照经典/传统概念理解，Orchestration（有时候翻译为编排，有时候反应为协同，这里指的是编排）是 Orchestrator（协同器）的职责，而 Controller（控制器）负责 Control（控制）。但是我不客气也不谦虚地讲，所谓协同、所谓编排，所谓控制，到现在为止，一塌糊涂，尤其是在 SDN 领域——而 SDN 本身的概念也是一塌糊涂，这个笔者会在后面论述——这些概念没有明确的定义，Orchestrator 与 Controller 的职责与范围一直纠缠不清。
ECOMP 比较优雅地解决了这一问题，它不仅把编排（Orchestration）做了一个明确的定义，也把 Orchestrator 和 Controller 的职责与范围做了明确的划分。
ECOMP 首先给编排（Orchestration）的定义是：In general, Orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task.The ability to graphically design and modify a workflow process is the key differentiator between an orchestrated process and a standard compiled set of procedural code.
请您仔细阅读这段英文，尤其是红色文字。我对这个定义的态度是：欲迎还拒！首先对于它给出了明确定义这一点，我是欢迎的；但是，这个定义正确与否，我是怀疑的，仅仅是通过 workflow，就能达到编排的目标（Service Delivery or Changes to existing Service）？我非常抗拒！！！
不过无论怎么说，其毕竟给出了编排（Orchestration）的明确定义，我们总体还是持欢迎态度吧。
前文已经提及，编排（Orchestration）的目标是：Service Delivery or Changes to existing Service。为了达成这一目标，ECOMP 使用了 MSO（Master Service Orchestrator）与 Controller（Infrastructure, Network and Application Controllers）一起来完成这个工作，如下图所示：
图3Orchestration（编排）
在完成 Orchestration（编排）这一工作时，各部件的分工如下表所示：
部件
分工
MSO
MSO 负责接收请求并响应，也就是说 MSO 首先是 E2E 负责
分析并分拆 Request，转换为各种资源请求（创建资源），并发送资源请求给各个对应的 Controller
VM 及 VNF的创建发送给 Infrastructure Controller，网络打通（LAN or WAN）发送给 Network Controller, VNF 配置，发送给 Application Controller
由于存在多个控制器实例（不仅仅是多类型），MSO 需要确定合适的控制器实例，这一点，它是从 A&AI 那里获取有效信息
值得一提的是，如果没有合适的控制器实例，MSO 还负责创建一个控制器
同时， MSO 也会将各个 Controller 创建的资源通知 A&AI，令其更新
Infrastructure Controller
创建 VM 及 VNF
Network Controller
打通网络（LAN/WAN/ACCESS）
特别说明：不负责打通 Legacy 网络，必须提前 Ready
Application Controller
VNF 配置
表2. Orchestration 各部件分工
这里我们看到，MSO 在 Orchstration 功能中，除了 E2E 负责（Request/Response）以外，用一句话总结它的职责，就是：资源的分解和分配；而各个控制器的职责就是资源的创建（or 配置）。
还是那句话，对于 ECOMP 关于 Orchestration 的定义与分工，笔者持赞同和欢迎态度，但是对于其能通过 workflow 就能完成 Orchestration 的工作，笔者保留怀疑态度，期待能有更详细的信息以解决笔者心中的困惑。
欲迎还拒！
2.2.1.3 A&AI
得资源者，得天下！
A&AI，Active & Available Inventory，讲述了一些功能和要求，在笔者看来，这些功能和要求，中规中矩，但是，有一点必须强调，资源是一切的基础，如果您想有所追求的话（笔者在后面的章节中，会继续涉及这个话题）。
得资源者得天下！天下几人识此言？
在资源系统中，最难的应该是实时资源采集（及业务还原）。这一点，ECOMP 可能是由于篇幅原因，并没有怎么涉及（也可能其主要领域是 NFV，并没有深入 WAN/LAN 这一领域，资源实时采集这一块，可能并不太是痛点），只是简单带过其资源的来源：MSO、Controllers、DCAE、BSS/OSS、3rd party cloud provider......
实时资源采集（及业务还原）问题不解决，一切都是空......
当然，毕竟 ECOMP 架构白皮书，由于其白皮书的特质，不在这一点细节纠缠也是可以理解的，毕竟白皮书的目的是宣传其理念和逼格。那么 ECOMP 的理念和逼格又是什么呢？
2.2.2 模型打通了任督二脉
用 ECOMP 自己的话说，就是：Metadata Driven Design Time and Runtime Execution。我们一般习惯说，模型驱动（model driven），这样更顺口，但是 ECOMP 的 metadata driven，更准确（这个笔者会在后面解释）。
模型打通了任督二脉，指的是模型（model/metadata）贯穿了设计与开发的始终，并驱动了设计与开发，如下图所示：
图4模型打通了任督二脉
【手机上阅读，图上的字可能看不清楚，但是还是建议您仔细阅读，这是 ECOMP 的理念之一。】
这非常神奇！
熟悉笔者的人，可能会觉得“这非常神奇”这句话是贬义。确实，笔者不相信这样确实能实现，但是在这里，笔者并不是表达贬义，而是表达敬意！
咋一看，这个跟 Tail-f 宣称的“MBD（基于模型的开发）/MDD（模型驱动开发）”很像，而熟悉笔者的人知道，笔者一直是对 Tail-f 没有什么好感，它吹牛太盛！
【如果您感兴趣，可以关注“标哥说天下”，发送相关信息，可以获取笔者以前发表的相关文章，本文最后会列出发送什么信息，获取什么文章】
但是，ECOMP 跟 Tail-f 显著的不同是，Tail-f 仅仅提出了一个模型驱动框架，一个非常纯粹的框架，而 ECOMP 却实实在在地提出了模型——metadata（这就是我前面说的，metadata 更准确），它给出了 metadata 的定义（当然，因为仅仅从白皮书中也只是能看出个示意，具体详细的模型还有待 AT&T 进一步发布）。
另外，同样是叫作“模型引擎”，Tail-f 的模型驱动框架，仅仅是一个 YANG 模型引擎和命令行生成引擎（比这强一点，但是强不到哪里去，你读懂了我这句话，就读懂了 Tail-f），而 ECOMP 的模型引擎（就是设计时框架），我们看到，包括：MSO、Controllers、A&AI、DCAE 等等一些列组件，一些列实打实的组件......
有点跑题了......^_^
我这么贬低 Tail-f，不是代表我盲目崇拜 ECOMP。实际上，正如我前面所说，metadata，仅仅从白皮书中也只是能看出个示意，具体详细的模型还有待 AT&T 进一步发布。在没有详细的 metadata 发布之前，一切都是空的。
从白皮书中，我们可以看到 metadata 的一些蛛丝马迹。ECOMP 的 metadata 包括：结构、方法和策略，如下图所示：
图5ECOMP metadata 概述
图，我是原版 copy 的 ECOMP 白皮书中的图，红色字体是我加的说明，还是那句话，建议您仔细看看这张图。
ECOMP 白皮书没有进一步透露 metadata 的细节。metadata 中，对象及对象之间的关系，从抽象建模技术角度而言，相对简单，其原语无非是包含、关联之类的，而“行为和策略”这两点就非常困难，这是一个“易用性和灵活性”之间的天然不可调和的矛盾：
追求易用性，就需要提供（发明）很多原语，才能达到完备性（如果完备性不够，则很多需求没法表达）。而要想达到完备性，则非常非常困难。（我在后面会继续展开描述）
追求灵活性，追求到极致，就是 C /JAVA/Python 之类的编程语言，足够灵活，但是已经失去意义（我如果使用了 C /JAVA/Python 之类的编程语言，我要你这个 metadata driver 框架干嘛？）
我前面说了，要想达到完备性，非常非常困难，这里我简单展开描述一下：
所谓原语，所谓易用性，从某种意义上讲，就是代号，比如“A”代表：蛋炒饭加两鸡蛋不放葱花口味淡一点吧啦吧啦，“B”代表：鱼香肉丝不要放鱼不要甜只要辣吧啦吧啦。你到饭店只需说：“A B”，不需要吧啦吧啦吧啦吧啦吧啦一大堆，人家就明白你的意思。这就是原语，这就是易用性。
可是，这只是看起来很美好。我们仍然拿饭店来说，有的人感冒了希望放点姜丝，有的人不希望放姜丝，有的人喜欢微辣，有的人喜欢甜，有的人蛋炒饭不要鸡蛋，有的人......这样的需求不是无穷的，也是无尽的。我们如果追求易用性，追求原语，那么将会疲于奔命，没完没了。而且更可怕的是，这样的开发模式将变为灾难，如下图所示：
图6MetaData Driven 开发模式的灾难
ECOMP 没有在这些细节上着墨，其只是提到了其可能用到的建模工具和数据类型，比如： YANG, HEAT, TOSCA, YAML, BPMN/BPEL 等等。
我不谦虚地讲，如果 ECOMP 只是使用现有的建模工具/建模语言进行一些堆砌而没有自己的发明创新，那么其要想达到其理想目标......不大可能（当然，另一种情况是我理解错了 ECOMP 的真实想法......）
在这一小节中，我提到了策略，那么策略是什么，策略又发挥了什么作用呢？
2.2.3 策略成就了雄霸天下
首先，说明一点，策略（Policy）也是 Metadata 的一种。只是策略太多重要，所以我们拿出来专门讲述——实际上，ECOMP 也花了很大的篇幅讲述策略。
ECOMP 从业务开发到业务发放（实例化）到业务调整，整个形成了一个闭环自动化：Design -> Create -> Collect -> Analyze -> Detect-> Publish -> Respond。
Design -> Create，是我们上一小节讲述的内容，通过 metadata driven，它的设计和执行（执行包括 create）是一体的，一个业务相关的模型，一个业务无关的引擎，就完成这些工作。
Collect -> Analyze -> Detect-> Publish -> Respond，仍然是 metadata driven 的一部分，但是这里要特别强调 Policy（策略），没有策略，这一切无从谈起。
ECOMP 的 Policy，总的来说，还是符合 ECA 范式：Event-Condition-Action。这里面 Event、Condition、Action 都需要建模，这个模型能不能建好，笔者在上一小节已经涉及，这里不再重复。现在我们就假设这些模型已经建好，看看它的架构吧。
首先我们看策略平台（设计、发布、执行）本身的架构，如下图所示：
图7策略平台架构
这个架构有两点需要特别注意：
策略模板（策略的具体定义），就是我在上一节中说的，如果定义不好，一切都是空。不过笔者现在无法知晓 ECOMP 的 Policy 的详细定义
策略执行，就是上图中最右侧的那一个方框。我们看到，任何组件，包括基础设施本身，都有可能是策略的执行体。
仅仅是有策略的定义，策略的执行是不够的，它还需要一个触发条件，就是前面说的“Event-Condition”，ECOMP 执行事件采集和条件分析的组件是 DCAE，其架构图如下：
图8DCAE 架构图
架构图本身，没什么太多需要讲述，一切尽在图中。不过我们需要通过这张图，能想象出来它的关键技术：采集、分析、存储——巨大数据的实时采集、分析与存储，绝对不是一件容易的事情。（不过这也更进一步加剧我前面的怀疑：什么样的 metadata driven，能够做这么复杂的事情？算了，不纠结了，^_^）
关于策略建模技术，ECOMP 倒是列举了一系列的技术，如下图所示：
图9Policy Technologies
我还是坚持那个观点，如果仅仅是靠这些 Policy Technologies 的堆砌，我怀疑 ECOMP 那个 metadata driven 的目标能否达成。
这里笔者还想再提一点，就是上图中的“OpenStack Congress”，笔者感觉其讲得非常好：Detect policy violation for OpenStack Resources。它就是一个 OpenStack 资源冲突检查工具，说它是策略都勉为其难，而且它的语法特别晦涩甚至已经到了恶心的地步。唉，不说了，太烦......（而且，跑题了，^_^）
我们一直还没有提“Respond”，从语义上说，“Respond”就是“ECA”中的“A”（Action），我们在图7中，也涉及到了这一点。笔者在这里想强调的是，一个好的“Respond”正是 ECOMP 宣称的“Closed Loop Automation”的最后一步：临门一脚！
到现在为止，我们介绍了 ECOMP 的几个关键句：
集美貌与智慧与一身
模型打通了任督二脉
策略成就了雄霸天下
下面我们看看 ECOMP 架构的真身吧。
2.2.4 ECOMP 总体架构图
憋说话，上图！
图10ECOMP Platform components
图11ECOMP Platform Decomposition
来源：3023.com
原文：http://www.3023.com/3/034930021.html
阅读全文
0 0
- ECOMP白皮书
- H264白皮书
- vp7白皮书
- DLNA白皮书
- java 白皮书
- jbpm白皮书
- JSP白皮书
- Qt4白皮书
- 什么是白皮书?
- H264白皮书
- Java 白皮书
- Fastcgi 白皮书
- 兼容性白皮书
- 白皮书是什么意思？
- ECOMP已经开源成功，这次AT&T准备推动白盒路由操作系统DNOS
- Java语言白皮书
- .NET 概述白皮书(MS)
- ROSE 技术白皮书
- 数据结构与算法（27）——排序（二）
- RecyclerView系列（二）下拉刷新、上拉加载、Item点击监听
- DNS服务器的配置
- Javabean+JSP 实现文件的上传 显示 下载
- Oracle SQL符号分隔的多行字符串拆分
- ECOMP白皮书
- CEF 嵌入到MFC的流程，包括启动CEF以及CEF程序的关闭流程。
- #一.mybatis简介
- Github详解
- linux启动流程简介
- #二.mybatis-helloworld
- iframe 和 父页面 相互取值及函数调用
- 不解释，看图
- #三.mybatis-小结以及实验题目
