现代云数据中心服务器架构选型

1、现代云数据中心服务器架构选型Agenda33传统企业的互联网之路分布式架构转型之路服务器平台如何选型经验分享互联网时代传统行业如何转型以运营商为例：传统电信运营商 业务套餐复杂，内容僵化且计费 成本高，使用体验差。未来电信 业务的转型可多向互联网业务学 习以用户体验为中心的业务设计 模式，简化业务规则、简化系统 设计难度并尝试后向收费模式。从执行层面分析，当前可以重点从以下几个方面进行业务转型：（1）真正以客户为中心，提升客户体验（2）全渠道接触，贴近客户，增强客户黏性（3）推动数字化运营，向数据要效益运营商传统业务互联网业务业务设计核心目标以流程为中心以用户体验为中心业务规则组合业务多，规则

2、复杂单品业务多，规则简单业务套餐设计内部人员设计，一般不能用户定制开放给用户灵活定制业务计费方式前向收费为主后向收费为主业务体验业务体验与资费基本无法挂钩业务体验与资费直接对应业务流程设计以安全性为第一以可用性为第一计费规则复杂简单43互联网IT架构的发展对传统行业的启示传统企业和互联网公司的业务需求差异业务需求的巨大差异必然带来IT架构设计的迥异传统企业业务需求互联网企业业务需求系统设计目标优先级可用性第一安全和业务一致性第 二安全和业务一致性第二可用性第二业务流程长流程、复杂流程多短流程组合为主事务复杂性复杂事物多基本没有复杂事物性能要求业务并发变化小，一般可以提前预估性能变化业务并发变化

3、大，要求系统能够快速响应性能伸缩数据类型以结构化数据为主非结构化数据很多业务需求和IT设计关系业务需求主导IT设计IT设计可以影响或引导业务需求读写比例7：3或8：210：1以上54“互联网+”时代的业务系统对IT基础架构提出多样化的要求High PerformanceMature and Growth Markets Large Scale AdoptionScalabilitySecurityEfficiencyData CapabilitiesIndustry AffiliationReliability and AvailabilityAdvanced VirtualizationAu

4、tomation分析洞察系统5核心交易系统智能资源调配应用快速部署架构灵活扩展业务持续运行海量数据处理实时分析响应数据安全合规软件定义架构互动参与系统设备无缝接入安全可控至上敏捷开发迭代开放互联协作混合IT架构将成为企业IT架构新常态混合IT 将现有技术与新兴技术相融合，协助 企业满足并超出客户日益增长的需求与期望设备应用传感器交互系统、洞察系统+HRERP记录系统CRMDB企业混合IT环境公有云传统IT私有云6传统IT架构向互联网架构学习转变思路基础架构云化：实现资源的精确供给、动态 伸缩、快速应用部署、自动化运维关键应 用资源 池一般应用 资源池存储 资源 池对外服务SOA化：梳理服务类型

5、和接口，实 现对外服务的标准化，和能力的对外开放应用逻辑模块化：将标准化的服务，使用分布式的应用架构实现，服务实体可以横向伸缩现现自顶上顶 而层下层 的设设设 计计，计7从服实务实SOA化高到高 应可用可 模靠块靠 化性再性 到要资要源求池求化纵向解耦、横向分层SOA化，构建统一服务 层分布式架构轻量级中间件模块化组合灵活扩展，快速部署， 水平伸缩Agenda99传统企业的互联网之路分布式架构转型之路服务器平台如何选型经验分享分布式计算一定强？分布式计算的Trade-off并行计算后的Time Overhead：Mater节点任务分解和汇总的开销各节点通信的开销子任务启动和停止的系统开销长尾子

6、任务的延时开销并行计算后的Cost Overhead：更多的节点=更多的附属不可压缩成本(线缆、磁盘、端口、空间)更多的节点和OS=更多的运维成本更多的节点和OS=更多的系统开销(OS系统常驻内存、系统进程)更多的节点=更难的资源均衡和更低的平均资源利用率并行计算需要更多的软件优化和开发成本更多的节点=更高的子任务长尾概率以上对比假设原始任务可以分解为任意多 个可以并行的子任务123456789101112123456789101112TimeTimeMaster节点:750MHz CPUSlave节点:750MHz CPUSlave节点:750MHz CPUSlave节点:750MHz CP

7、USlave节点:750MHz CPU4Ghz CPU原始任务9美国加州.伯克利大学EricBrewer教授提出CAP理论-一 个分布式系统不可能 同时满足一致性、可用性 和分区容忍性这三项需求, 最多同时只能 满足其中两 项。因此集中式处理方式 更适用于要求数据完整性 核心帐务交易处理分布式架构要牺牲可用性或一致性10系统分布化的难点：事物交易系统为什么OLTP在线交易数据库集群要采用共享式架构？CAP理论告诉我们集群系统状态下 如果数据不共享，必须要牺牲A（可 用性）或者C（一致性）的其中一个。支付业务属于高并发、高可用性要 求和高一致性的典型应用，其数据 库只能采用共享式集群架构。Ora

8、cle RAC架构Oracle RAC为典型的集中共享式集群，所有节点共享一份数据，节点间通 过网卡高速交换内存数据，保证状态一致性，并通过共享磁盘保证持久化 数据一致性Oracle RAC适合对数据一致性和可用性要求很高的支付应用其架构横向扩展困难，需要纵向扩展Oracle RAC对系统硬件（CPU、内存、IO板卡、磁盘）均有极高的可靠性 要求，任何轻微的硬件故障均可能导致Oracle重启11进行分布式架构转变需要考虑的问题131312可用性：小型机存储的高冗余机制,PC和MySQL能否做到一致性：Oracle物理级别一致性,MySQL有没有问题(语句模式)高性能：高端小机存储的性能和IO能

9、力很强,PC能否顶得过；MySQL和Oracle对SQL的处理性能是否相同 扩展性：分多少库分多少表,什么维度分 后期二次拆分如何更方便（1）数据迁移，包括异构数据迁移，全量怎么迁移，增量怎么迁移？怎样才能无缝升级？（2）数据路由，如何屏蔽分表给应用带来的复杂性 ？如何解决多维度查询？如何解决跨分表查询？（3）数据同步，搜索、数据仓库、其他业务方都有数据导出需求，如何实现实时同步，并且只同步一次（4）分布式事务，一个事务涉及到2张不同纬度的表该怎么办？一个事务涉及到2个分库该怎么办?（5）规模化运维，如跨库数据订正怎么解决？DDL的问题怎么处理等这类日常运维工作？如何应对从一台到几千台的运维量

10、变，监控、告警怎么搞？如何应对更多的业务需求变化,开发能否对DB的操作实现自助？拆分数据库带来的问题事务的有限支持。支持基于单库的事务,但不支持跨库 进行事务。一旦业务需要跨库的事务处理, 要么使用复 杂的数据模型和应用逻辑来保障,要么使用昂贵的系统 方法(降低其扩展能力)。无法处理局部热点。局部热点不会随着数据拆分而消 失,另外拆分的数据平衡也是极其复杂的问题。开发的低效性 。数据”分区”是非标准化的解决方案, 只支持很基本的SQL操作.使用该方法将造成程序员开发的低效性和提高应用逻辑的复杂度。架构的独特性。独特的架构引入了维护与监控以及和 其他商业软件的互联互通等一系列独有的问题.以支付宝

11、为例,为了保证其扩展性和可用性,牺牲数据一致性,每笔支付需要500条SQL和80个数据库事务通过 近500个系统来完成，这与运营商的实现方式完全不同。数据库拆分的方法，引入中间层，牺牲一致性13分布式计算集中式计算，各有不同用点，适合不同的业务场景需求14互联网应用确实将分布式计算带到了新的台阶,但是并没有突破计算机科学的CAP基本原理。因此需要 牺牲数据一致性换得处理能力的线性可扩展性。而传统企业业务需要注重数据的实时强一致性采用集中处理,在一个统一的唯一数据视图上进行横向和 竖向的扩展来满足业务的吞吐量要求。所以传统企业的架构是集中和分布的综合体。选择完整性/可用性(C/A)保证数据的强一

12、致性事务处理 交易, 是传统企业在过去的三十几年的业务发展过程中要求遵循的基本架构及编程原则。采用数据库、交易管理中间件从系统级提供的数据强一致性,简化业务应用的编程使其致力于业务功能 的实现是运营商过去的最佳实践。因此,集中式计算体系依然至关重要。在互联网业务这种保持数据弱一致性非事务处理交易,采用分布式计算则是最经济的选择。同理, 传统的面向客户服务的互联网业务平台也可以采用分布式架构未来传统企业的架构一定是一种集中式和分布式混合体系。新兴的面向互联网业务平台架构转型思路161615传统企业的面向互联网业务平台，与互联网公司的业务系统有着相似的业务特征和系统建设需求，因此可以全面学习互 联

13、网公司的系统架构和建设思路。针对互联网业务平台的应用场景，需要根据数据类型和数据价值考虑结构化、半结构化和非结构化数据的存储方案。此 外，需要格外关注动态可扩展性和分布式计算，基于shared-nothing技术架构构建分布式数据库，支持数据节点的最大 横向扩展要求，满足海量数据存储与海量用户的并发处理能力。同时采用读写分离操作模式，有效地减轻数据库与I/O 压力。大数据领域属于读多写少分析为主的场景，一般不用考虑CAP冲突，因此可以方便的使用分布式架构进行设计。需重点 考虑分布式文件系统、NoSQL数 据库、并行计算框架和流数据处理等技术，从而支持海量数据的存储、检索、分析及 对流数据的动态

14、实时分析处理。大数据分析提供的客户与市场洞察、网络与客户体验洞察优化、运营洞察与优化能力促 进了传统企业核心竞争力的提升，同时催生出新的商业模式创新和新产品的创新，而这正是互联网时代传统企业转型战 略的内容。此外，针对客户行为及喜好的分析，为客户提供个性化、精准的服务，从而达到增强用户体验的目的。数据库架构扩展两种思路逻辑上仍然采用传统集中式处理架构，但是物理上采用闪存介质和可分布式存储 层等方式，构建更加容易扩展更加高效的数据库资源平台。实现对应用完全透明。171716运营商数据库架构优化应坚持以ScaleUP为主传统企业需要谨慎使用业务补偿机制,选择以Scale-Up为主,Scale-Ou

15、t为辅的解决方案较为符合现状。181817传统企业尤其是国企负有政治责任，不能随意采用业务补偿机制 数据库架构可以使用大Scale-Up,小Scale-Out架构不掌握核心开发团队,尽量在技术架构解决问题核心业务系统以稳定为第一，在保持稳定可靠并且对业务逻辑影响最小的的前提下，尽量通过硬件技术的进步提升系统性能。传统企业“去Oracle”可选的产品路线191918，产品路线操作意义可行性分析1Oracle以外的 商业数据库使用O以外的商业数据库来实现去O,投 机取巧的选择,不具备任何意义如果去O,不能是采用其他商用数据库软件来替换Oracle,而是应该去除所有国外商业数据库2使用纯国产数据库对

16、现有系统迚行重构,直接使用纯国产 数据库 来实现去O,简单粗暴的选择,但 国产数据库稳 定性以及性能未得到长 时间运行验证,风险极高国产数据库在没有经过运营商核心系统运行的验 证, 同时选择国产数据库,会迚入到产品的细小分 支, 后续支持力度可能会存在问题3收购数据库其本质还是商业数据库,跟路线一类似, 只有 象征意义国内厂商收购的国外数据库, 国人完全掌控需要 一段时间,建议以观察为主4采用纯开源数 据库方案互联网业界主流的去O方案,要求较高 的技术门槛, 同时需要对现有系统迚行 大幅改造开源数据库是于联网去O的主流选择。但 需要较 高的技术掌控门槛,同时需要较强的定制能力 ， 运营商近期不

17、具备掌控能力5基于开源数据库进行定制对纯开源数据库,定制版在高可用能力、维 护支持力度上有较大改善定制开源数据库需要小心与开源主流分支的兼容 同时定制数据库本质上与研发数据库需要同样水 平的开发能力。Oracle数据库架构优化思路Oracle数据库性能优化主要有两条路：一个是存储层分布式化+数据库一体机，这种方式采用InfinibandSSD产品成本高昂，软硬件紧密耦合绑定，且增加 了运营维护难度。另一种思路是利用全闪存介质替代磁盘阵列作为持久化存储，从而大幅提高数据库性能。此种方式对Oracle数据库应 用架构没有任何更改，保持了运维手段的一致性。典型的代表有IBM 全闪存阵列方案，近年在国

18、内各大券商得到广泛 应用和推广，在保持对应用透明的基础上均提高交易能力5倍以上。Oracle数据库的性能优化遵循漏斗法则，磁盘IO的优化往往比CPU和内存的扩容效 果更加显著。使用全闪存阵列存放所有数据是综合性能提升效果最明显，对系统架构改变最小， 最成熟稳定和容易维护的方案。典型的代表有IBM 全闪存阵列方案，今年在国内各 大券商得到广泛应用和推广，在保持现有应用架构不变的基础上均提高交易能力5 倍以上。202019Oracle数据库一体机方案Oracle数据库“一体机”的核心思路是通过将存储层分布式化，并利用Infiniband和闪存技术极大降低数据交互延迟提升 数据IOPS来提升性能。O

19、racle数据库“一体机”的最好方案是Exadata，但是Exadata最大的问题是高昂的价格和封闭技术路线无法在传统企业 大规模使用。国内涌现出大量的山寨版Oracle数据库“一体机”方案，其实现分布式存储无非是以下几种技术：1、Oracle ASM技术2、分布式存储技术（Sheepdog，Ceph，VSAN） 山寨版Oracle数据库“一体机”方案风险在于：需要注意Oracle原厂support问题堆叠了大量Infiniband和闪存，成本很高架构维护难度远高于传统IOE架构212120Agenda传统企业的互联网之路分布式架构转型之路服务器平台如何选型经验分享两种系统架构对硬件平台的需求

20、区别集中式架构系统更高的单节点性能纵向扩展能力单节点的可靠性高应用架构 特点22对服务器 的需求单机高性能RISC指令集大规模多处理器架构32256core CPU单机可靠性99.997%服务器产品代表IBM PowerHP SuperDomeOracle/Sun M9000分布式架构系统较低的单节点性能横向扩展能力单节点的可靠性低单机性能要求不高RISC/MICS指令集简单多处理器架构232core CPU单机可靠性98%X86 PC服务器Power PC服务器ARM 服务器如何根据系统应用选择服务器平台非功能性需求（NFR）系统业务需求如业务峰值，并发度，业务复合增 长率，业务连续性需求，

21、业务可靠 性需求等系统软件架构软件扩展方式，软件HA模式，软件 负载均衡方式，软件FailureOver方 式等IT管控与运维IT安全规定，内控规定，运维管理要求等其他限制条件如已有软件架构，与现有平台的兼 容性，机房集中网管备份条件，机 房占地能耗要求，技术自主可控 等性能需求可靠性需求扩展性需求安全性需求可管理性需求兼容性需求节能环保需求虚拟化需求其他需求高端服务器中端服务器低端服务器23性能与可靠性：服务器平台的分类性能Power710/7 40X86低端小Power机PC高端服务器领域以IBM Z代表的大型机以IBM Power代表的小型机面向高端企业级市场不断追求更高单机性能更高的硬

22、件可靠性低端服务器领域以X86代表的PC兼容服务器面向消费市场和低端企业市场不断追求更低的硬件成本放宽可靠性设计以ARM为代表的更廉价服务器以IBM Power PC为代表的新一代服务器可靠性ARM大型机IBM Z高端小型机Power78024中端小型机Power750如何基于系统应用负载需求特征进行平台选型单机可靠性应用节点少，系统业务重要，要求很高的 单机可靠性多节点应用集群，主要靠软件保障可靠性，不要求很高的单机可靠性单机性能对单机性能要求较高对单机性能要求较低纵向/横向扩展性应用横向扩展困难，以纵向扩展为主应用为分布式横向扩展架构，可以方便地 进行横向扩展安全隔离要求应用安全性高，需要

23、物理级的安全隔离应用安全性不高，不要求严格的安全隔离应用更新频度应用一年更新一次或更少，强调系统稳定应用经常更新，应用逻辑变化快廉价要求系统采购以低成本为第一要求系统采购以综合造价/TCO为评价要求绿色节能要求部署核心机房，机房资源少造价高，要求 设备尽量减少空间能耗部署一般机房，机房造价较低，对设备节 能和空间消耗要求较低技术支持要求要求本地的原厂售后技术支持一般不需要原厂售后技术支持25互联网系统架构发展思路和平台选择采用SOA和服务总线，结合轻量级中间件、分布式文件系统、分布式缓存、分布式NoSQL数据库，结合建立横向扩展的，基于服务松耦合的分布式架构。前端展现层服务层数据库层NoSQL

24、缓存技术、分布式文件系统、流和更快的横向扩展提供多种分库分表的路由，支持读写分 离、一主多备的数据分布。为应用提供数据透明访问接口，屏蔽数 据分布的变化支持数据访问的流量管理和故障切换。核心库仍以Oracle数据库为主通过历史数据剥离、垂直分库及读写分 离等难度较低方式，逐步降低核心数据 库的压力服务SOA化，实现服务的标准化与可重用。数据中间层演进思路对平台的需求使用轻量级Web服务器，结合分布式量分发和均衡技术，实现更高的并发能力 使用服务总线技术，结合流程引擎技术和 消息总线技术，实现高性能、分布式、易 扩展的服务层。横向扩展架构，多节点集群侧重多并发多线程能力 对单机可靠性要求较低业务

25、需求变化快，强调架构的灵活和快速相应混合扩展架构，多节点集群对单机可靠性要求较高业务需求变化一般，强调架构相对稳定 和灵活横向扩展架构，多节点集群对单机可靠性要求较高业务需求变化较慢，强调架构稳定纵向扩展架构，双节点集群对单机可靠性要求很高业务需求变化很慢，强调架构稳定II类II类I类I类26I类应用平台建设建议安全隔离 应用更新廉价要求横向扩展性I类:核心关键负载类单机可靠性技术支持单机性能绿色节能纵向扩展性平台选型建议：27Power小型机+Power虚拟化技术，构建关键应用云化资源池，并保持平台的性能、可靠性和QoS。结合LPM， Remote Restart、Enterprise Po

26、ol等创新技术，实现应用的灵活伸缩和扩展，及应用的快速部署和故障迁移，提 高架构的弹性和可靠性原因分析：Power虚拟化技术是目前市场最能够满足Oralce数据库等核心关键应用负载的企业级虚拟化技术Power云化对现有应用来说迁移工作量和风险最小，并可以做到不降低原有应用的QoS要求PowerVM可以采用中高端小型机的动态分区模式，使用专有CPU和IO满足系统数据库等关键应用对性能和可 靠性的苛刻需求Power创新的Enterprise Pool技术，实现更加简单灵活的资源弹性使用采用PowerVM可充分利旧现有的设备，减少资源浪费Power小型机能耗水平低，占地空间少，有利于节约核心机房宝贵

27、的机房资源(如核心数据库/交易中间件/内存数据库)应用云化思路以平台的稳定可靠为宗旨，并进行云化改 造，实现应用和硬件松耦合。对集中的数 据库按照地域和功能进行拆分，部署松耦 合的应用架构，提高架构的弹性和灵活性。数据库系统基础平台平台需求的分析系统软件架构系统软件采用Oracle RAC，典型的集中共享式高可 用架构，适合对数据一致性和可用性要求很高的支付 应用软件架构横向扩展困难，需要纵向扩展Oracle RAC对系统硬件（CPU、内存、IO板卡、磁 盘）均有极高的可靠性要求，任何轻微的硬件故障均可能导致Oracle重启系统业务需求典型OLTP在线交易应用要求高并发事务处理未来业务量连续增

28、长，要求具备平滑扩展能 力属于在线支付业务，业务中断造成的损失大，要求极高的业务连续性，保障用户资金安 全IT管控与运维满足公司安全法规满足公司内控规定满足运维集中监控、网管、故障告警、备份、容灾等要求其他限制条件28硬件平台必须兼容现有的数据库软件，必须有大量实际运行案例必须兼容现有网管、监控、容灾、备份等系统满足机房供电规范，满足机房能耗和节能要求，满足 机架标准数据库硬件选型的对比29数据库平台其他一般应用平台性能双节点集群，采用1+1 HA方式，要求故障时每个节点的单机性能必需能接管全部业务采用多节点集群方式，N+1 HA，对单个节点的性能没有很高要求，整个系统的性能靠多节点叠加实现可

29、靠性Oracle RAC对硬件的可靠性有很高的要求一般靠软件实现Failure Over，单个节点故障对整个集群影响 可控，对硬件可靠性要求可适当降低扩展性纵向扩展为主，要求硬件必须具备很强的单机 扩展能力横向扩展为主，硬件单机不要求很强的扩展能力安全性核心交易业务，系统安全要求高要求操作系统安全性高，漏洞少，抗病毒和攻 击能力强数据库节点间要严格物理隔离一般业务，系统安全要求可适当放宽对操作系统漏洞和抗病毒等要求相对宽松，一般采用开放的linux平台应用节点间不要求严格隔离，一般共享资源提高利用率可管理性要求随机具备完善的原厂管理和监控软件一般采用第三方或开源的监控和管理软件维护保障要求原厂

30、的售后维护保障机制，具备本地完善的支持团队采用第三方代维即可兼容性必须兼容现有系统架构和软件必须兼容现有系统架构和软件节能环保满足机房节能环保要求满足机房节能环保要求虚拟化要求虚拟化性能损失小，一般不做虚拟化可接受适当的虚拟化性能损失，一般做虚拟化II类应用平台建设建议应用云化思路采用低成本云化平台，建设完全云化的资源池，实现完 全共享、横向扩展和动态伸缩的云化架构，实现应用和 硬件的完全解耦。平台选型建议：PowerLinux低成本服务器平台，采用成熟可靠虚拟化技术，并结合开放的可软件定义的云管理平台，并积极探索PaaS云 技术，实现更高层次的云化。实现基于自动化手段的集中式监控，实现大规模

31、集群的高效自动化运维。原因分析：Linux平台，业界使用最广泛，平台成熟，兼容性风险小，开发和维护成本低根据应用负载对单机性能要求的不同，可灵活选择高端PC服务器或低端PC服务器Powerlinux产品，标准Linux平台的高端PC服务器，兼顾性能、可靠性和低成本，并适于横向扩展，是替代低端PC服 务器的更好选择Powerlinxu的虚拟化技术与Power相同，更加便于资源池的统一维护和管理基于OpenStack等开源云管理方案，可实现灵活定制的云管理流程，并能广泛兼容各种型号和品牌的服务器产品。31II类:一般应用负载类单机可靠性技术支持单机性能绿色节能纵向扩展性廉价要求安全隔离 横向扩展性

32、应用更新30(如前端Web服务器/接口机/网管/报表服务器)Agenda3322传统企业的互联网之路分布式架构转型之路服务器平台如何选型经验分享33IBM系统基础架构全面支撑企业向“互联网+”转型基础硬件平台（开放，自主安全可控，深度定制，软件定义，自由扩展）应用平台软件（开放，开源，优化）能力开放，API经济传统系统平台化，水平化，灵 活扩展互联网系统敏捷化，移动化，无 缝化大数据系统实时化， 海量化， 数据安全移动APPFlash Systems混合云资源管理平台（开放，兼容，灵活定义，安全）BHYRIDHybrid Cloud创新业务Linux社区贡献排名公司第2，主流Linux发行版均

33、有Power优化版本， Power支持KVM虚拟化。IBM Power与开源的合作白金赞助商，19 个核心贡献者，贡 献排名第2，超过100个活跃开发者。IBM基础架构云全面以OpenStack为中心。投入10亿美金发 展 Linux及相关 开源技术。IBM发起创立软件定义 网络开源联盟Hadoop社区主要贡献者，提供Hadoop发行版，发起成立ODP，提供Hadoop增强方案。IBM与国内实力最强的 星环、亚信，巨杉等新 技术公司合作，开发Power优化的Hadoop版本和NewSQL数据库，与国内公司一起拓展 开源商业生态系统。IBM与Redis合作，基于IBM CAPICPU硬件加速技术

34、，建立创新的Redis方案。IBM 和 Docker 宣布建立战略伙伴关系，提供基于Power的Docker优化版本。Power+PostgreSQL提供分布式事务处 理数据库优化方案33/ibmsoeIBM Power支持各领域主流开源软件34Docker on Power：下一代云方案Docker是业界领先的轻量级虚拟化开源方案， 能够提供更加快速、灵活、低成本和云兼容的云 化方案，代表了未来云计算技术发展的方向。2014年6月10日 双方建立合作伙伴 关系DockerHub将支持托管在SoftLayer之上IBM将提供WebSphere应 用中间件镜像Docker容器可以部署在SoftL

35、ayer上，无论是裸机还是虚拟机2014年12月4日 双方建立战略合作 伙伴关系IBM将通过集成方案和单独产品两种模式生产和销售Docker Hub企业版。IBM将通过集成了Docker 编配引擎的IBM BlueMix提 供容器服务。2014年12月9日2015年Docker已经被移植到Power8小端 架构上，可通过Ubuntu源安装。Docker官方Top15镜像都已经或正 在支持Power架构，百余应用镜像 也在移植到Power8架构中。/press/us/en/pressrelease/45597.wss35Stream基于Powerlinux的创新方案PowerPowerPower

36、PowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerGPFS/HDFSETL清单 查询日志 分析流量 分析精确 营销Symphy/Hadoop/SparkHive/HBase文档管理SequiaDB MongoDB行为分析DB2GBase数据 仓库数据 集市海量NAS软件定义存储 云存储无状态 计算数据挖掘PowerMatlab/Excel可视数 据挖掘Power实时计算 告警分析SPSS/SAS计费批价分布式服务 总线36利用Powerlinux适于大数据处理的特性，基于IBM自有/开源/第三方商业软件，发展各种新

37、型的数据采集、处理、存储、查询和分析应用方案基于Powerlinux的创新方案PowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerPowerDPDKPowerMySQL/PostgreSQL交易数据库Redis/Memcache内存数据库网格BES/ACE交易中间件利用Powerlinux适合Java应用的特性，围绕Java的生态系统，融合商用/开源的各种数据库和中间件,支撑分布 式系统架构JavaddWAS/Weblogic/BESWeb服务集群Nginx/LVSHTTP服务器SDNOpenMP

38、EG视频处理37PostgresQLPostgresQL-XC on Power8：国内与中移苏研合作进行 基于Power8的分布式数据库平台测试。PostgresQL-XL on Power8：国内与亚信合作进行基于 Power8的分布式数据库平台测试。以下是在亚信进行的测试结果：Power + PostgresQL/MariaDB：分布式OLTP数据库MariaDBMariaDB在Power8上运行比x86上可获得 2.2倍的每秒交易数，同时每个交易的成本 只有x86平台的56%。Projections are based performance results reported in /

39、partnerworld/wps/servlet/ContentHandler/stg_ast_sys_wp_ibm-power- systems-solution-for-mariadb/lc=en_ALL_ZZ. Individual results will vary depending on individual workloads, configurations and conditions. IBM Power System S822L with (per socket) 10 cores / 80 threads, POWER8; 3.67GHz, 128 GB memory,

40、Ubuntu 14.04 IBM; Linux kernel: 3.13.0-35-generic with MariaDB 10.0.14 compared to Competitive stack: IBM System x3650 M4 with (per socket) 12 cores / 24 threads; Intel E5-2697 v2; 2.7 GHz; 128 GB , Ubuntu 14.04 IBM; Linux kernel: 3.13.0-35-generic with MariaDB 10.0.14.S822L results were extrapolate

41、d to an C812L-M based 10c 3.5 GHz / 1-socket / 256 GB memory / 2x4TB drive system. The HP DL380p results wereextrapolated to E5-2620: 12c 2.0 Ghz / 2 socket / 256 GB memory / 2x4TB drives. The results were obtained under laboratory conditions, and not in an actual customer environment. IBMs internal

42、 workload studies are not benchmark applications, nor are they based on any benchmark standard. As such, customer applications, differences in the stack deployed, and other systems variations or testing conditions may produce different results and may vary based on actual configuration, applications

43、, specific queries and other variables in a production environment.38Power + LVS/Keepalived: 高性能web接入服务器IDC交换机 视频自有交换机Real Server 1Nginx 反向代 理LVSDirector2公网 VLAN 私网 VLAN单个公网 IP 接入：VIP（22）LVSDirector1VIP：22DIP：（私网地址）DIP：（私网地址）RIP：（私网地址）Real Server 2Nginx 反向代 理RIP：（私网地址）私网网关公网网关上海视频 交换机内容服务器ApacheKeepalived 是集群管理中保证集群高可用的一个服务软件，其 功能类似于heartbeat，用来防止LVS节点