简洁明了而言，PlatformSymphony是一个给出的数据派发、任务调度及其资源优化配置的公司级分布式计算架构，而且适用异构化的IT自然环境。Symphony由双层构架构成，一层是承担资源优化配置的EGO，另一层是任务管理器的SOAM。在Symphony的群集中，客户必须依据Symphony出示的API保持Client和Service程序流程。

Client程序流程用以递交每日任务到Symphony群集，Symphony会在EGO层为此类运用申请办理云计算服务器，然后在相匹配的设备上起动客户的Service。Service接受每日任务数据信息并开展测算，最后会根据Symphony将每日任务結果回到Client程序流程。

PMC是Symphony出示的一个技术专业WEB操作面板，其能够 订制Symphony群集的配备，及其管理方法每日任务等。

CLI是Symphony出示了一些命令行工具的结合，针对习惯性应用指令实际操作的客户而言，更为便捷和高效率。KnowledgeCenter是Symphony产品文档的WEB插口，客户能够 在这其中寻找Symphony每个作用的详细介绍和操作方法。

分布式框架的归类

在详解PlatformSymphony与互联网大数据生态链的关联以前，我们一起先了解一下全部互联网大数据生态体系。我本人理解是：现阶段这一制造行业能够 简洁明了的分成三大块，分别是数据库、数据处理方法及其数据统计分析。数据统计分析是立即将大数据转换为经济收益的行业，在数据统计分析的行业会明确提出各种各样业务流程要求。数据处理方法行业则是承担保持数据统计分析明确提出的要求，这一行业也就是人们常常说的基础设施建设构架层(Infrastructure)。数据库指的便是数据信息造成的地区。在这里三块中间也是一些对接的手机软件行业，但是通常也都归在了数据处理方法行业(系统架构层)，比如对接数据库与数据处理方法层的数据信息导进专用工具(如sqoop等)，及其对接数据统计分析和数据处理方法的运用插口(如：SQL插口的Hive，及其流的插口等)。在互联网大数据的这三大行业中有很多开源系统及其非开源系统的商品，熟识的开源系统的Hadoop、Spark等，都归属于数据处理方法行业，也就是系统架构这方面。IBMPlatformSymphony毫无疑问也归属于这一块。总的来说，假如宏观经济的抽象性出全部互联网大数据绿色生态涉及到的有关行业。

根据对互联网大数据有关行业的宏观经济叙述，出来人们就再说谈下系统架构这一块。现阶段大多数开源系统有关的大数据框架基础能够 所属到基础设施建设构架这方面。以便更强的了解每个架构中间的关联，人们又将基础设施建设构架这方面分成四层，分别是数据储存层、群集資源高管、测算模块层、及其运用插口层。除开一些出示便捷性、健壮性及其可扩展性的架构以外(一般还可以通称为管理类专业)，其它绝大多数都能够归在这里四类。比如HDFS归属于数据储存层，Mesos和Yarn则归属于群集資源高管，HadoopMapReduce、Storm、Spark等则属于测算模块层，Hive、Pig则为数据统计出示插口。Ambari则是一个提高便捷性和健壮性的专用工具，Zookeeper出示了可扩展性(HA)。这种系统软件中间实际的关联。

那麼PlatformSymphony我们可以看得出，在大数据的应用情景中，PlatformSymphony既处于資源高管，也包含了测算模块层。因而许多原来的大数据的应用，都能够很光滑的转移到Symphony的群集中运作，比如Hive、Pig等。而且客户之前在HadoopMapReduce上开发设计的运用还可以很光滑的运作在Symphony之中。

对比开源系统的架构，PlatformSymphony中的EGO类似与Yarn和Mesos处在群集資源高管，SOAM处在测算模块层，承担任务管理器和生产调度。SymphonyMapReduce仅仅Symphony内嵌的一种运用(HadoopMapReduce也是内放置Yarn的一种运用)。客户实际上能够 依据Symphony的API保持各种各样不一样的Symphony运用。现阶段Symphony早已与开源系统Yarn和Spark集成化，换句话说客户以前在Yarn和Spark上边的运用，能够 立即根据Symphony管理方法和生产调度群集資源。

PlatformSymphony的控制模块和基本知识

在文章内容的刚开始人们就早已提到了PlatformSymphony的系统架构，这儿人们就讨论一下PlatformSymphony双层构架中都有哪些详尽的控制模块。

EGO介绍

用一句说，EGO(全称之为EnterpriseGridOrchestrator)便是一个管理方法群集資源的控制模块。最先它会将物理学資源，开展虚似抽象性并管理方法，随后在好几个运用中间开展融洽和分派。这也是其设计方案的初心。类似开源系统的Yarn，但是要了解EGO这一设计方案及保持全是十几年前就早已拥有，而Yarn则是这几年才发展趋势起來的(公司级的分布式服务，一般都是累积沉定好长时间才会保持稳定)。EGO会将群集连接点分成管理方法连接点和测算连接点，并界定一套资源配置的对策。人们还可以说EGO便是由这三一部分构成。

管理方法连接点，一般会运作一些形式化的服务项目，比如管理方法Symphony每日任务的服务项目(SessionManager和WEB的服务项目系统进程，后边会详细介绍)。测算连接点则是承重客户测算每日任务的连接点。图上的Mastercandidate归属于一个Standby的Master连接点。针对Symphony的Master连接点而言，这就是它的HA。Master和MasterCandidate都归属于管理方法连接点，他们会共享资源一个文件目录(NFS)来纪录运作时的一些新闻媒体信息内容。当Master服务器宕机或长期不回应的情况下，MasterCandidate会对接群集变成新的Master，并从NFS的新闻媒体信息内容中修复已经实行的每日任务信息内容。CPUslot是一个用于考量云计算服务器的组成部分。一个Slot能够 用于起动一个客户的Service案例(在预估连接点)，还可以用于起动一个SessionManager那样的管理服务案例(在管理方法连接点)。实际上管理方法连接点和测算连接点仅仅EGO内嵌的二种資源排序，人们也叫ResourceGroup。客户还可以自定其独有的ResourceGroup来防护不一样的运用。ResourceGroup中间还可以有优先，还可以订制化资源共享。这也是EGO出示给顶层的作用。

这儿也详细介绍下EGO中好多个关键的服务项目系统进程，VEMKD、EGOSC、PEM。VEMKD等于Yarn中的RM，它起动在Master连接点上边，用以检测群集的資源的情况及其管理方法群集資源。顶层的运用最后都是向VEMKD来申请办理資源(Slot)。EGOSC全称便是EGOservicecontroller，它会向VEMKD申请办理資源起动一些管理信息系统的服务项目。PEM全称ProcessManager，用以起动系统进程案例，和检测系统进程案例的情况。