自2012年发展至今，大数据已经***到了每个行业和业务领域，逐渐成为重要的生产因素。但是，面对如此庞大而复杂的数据的处理需求，传统架构无法完全解决大数据平台的需求，电信企业开始尝试专门设计基于云计算、面向数据挖掘和数据可视化等领域的大数据服务容器平台，主要的应用场景包括数据的移植、数据整合、数据处理等，但也存在很多建设难点，如：多数据库协同，如何保证数据ACID及跨域访问；数据源的异构协同、数据的敏捷抽取问题；硬件资源利用的高效化与多复用化；资源调度响应的即点即用和流量穿透等。

针对这些难点和问题，社区上星期邀请到电信企业专家、红帽电信行业技术专家等，分享电信行业大数据分析平台基于OpenShift实现容器化改造的解决方案和国外实践案例，并在线为大家答疑解惑。以下是在活动中，对社区会员所提出问题的十分详细的解答，可供电信行业及其他行业规划相关项目时进行参考。

1、如何应用容器化技术对传统数据仓库进行改造和优化？

【问题描述】如何应用容器化技术对传统的数据仓库及数仓应用进行改造和优化？我们目前使用的数据库环境不断更新，从传统的DB2，Oracle，迁移到MPP，Hive等，但数据的提取，加工和开放使用，还是沿用传统的ETL加工，Portal库+报表展现的方式。请问容器化技术能够应用在哪个环节，能否用于提高数据层的处理能力上，或只能够用于数据应用和数据开放环节呢？以及能够带来的优势有哪些？

@郭维  广东联通 项目经理：

数据主要有三种处理方式：

1)官方数据处理：

提供基础的数据处理服务，包括但不限于图片的转码、水印、原图保护、防盗链等，以及音视频的转码、切片和拼接等。

2)自定义数据处理：允许用户构建、上传自定义的私有数据处理服务，并无缝对接七牛云存储上的数据以及其他数据处理服务。

3)第三方数据处理：一个开放的应用平台，提供大量功能丰富的第三方数据处理服务，比如图片鉴黄、人脸识别、广告过滤、语言翻译、TTS 等。

针对这些数据，我们可以通过增加队列，限流，合理使用IO和CPU等等方式进行优化。容器在这些方面，都已经有了比较多的操作实践。

@zhuqibs Mcd 软件开发工程师：

容器的适用场合在于：应用单一、无状态化的地方。

所以：

（1） 数据的ETL处理：是可以用的，可以将routie的etl脚本容器化；

（2） 数据分析处理： 这种应用系统是可以容器化的，不过不是很好，曾经把rstudio容器化，比较复杂，效果不好，但不少分析工具，官方已经有容器版发布；

（3）数据展现处理：有部分有docker化的提供，比如zeppelin的docker方案。

@赵锡漪 红帽高级解决方案架构师：

1、您提到的 ETL 体系是最适合云化改造的，由于传统的 ETL 途径是由项目初始设计固化设计的，通常会在系统发展过程中偏离数据业务使用目标。因此如果 ETL 转化为动态过程那么就可以实现数据的动态业务目的调整。但另一个问题就出现了，ETL可以 CI/CD 但是数据模型不可以，目前主流的理论都是在外围为数据做注解，这就是数据湖模型。数据湖是将数据仓库中数据动态提取后在湖内形成新的数据池，用以完成面向新数据业务目标的模型。

2、在云端重新实现ETL意味着需要重新构建部分主数据管理，包括数据溯源、数据治理、数据途径等方面的重新实现，这方面微服务体系可以帮上忙。

3、完成了数据供应，接下来就是数据应用。如我在讲解的PPT中所提到，未来数据可能会更加多元化，来源更加复杂，模型更加分散，使用途径和使用习惯可能变为更加倾向数学化使用的Deep learning等模型上，那么数据供应将不再像原有数据仓库体系中那么僵化。

4、我们总是期望数据能告诉我们一些我们不知道的，而数据仓库通常只能告诉我我们已知的结果有没有数据依据做支持。因此未来更多引入 AI/ML 就是为了能让数据产生未知的数据预期。这方面容器化就可以帮主用户快速建立高敏、尝试性数据使用途径。这就是为何我会提到在容器云上实现数据湖的原因。新的云端数据湖将更适应未来无预期数据使用模型的快速CI/CD构建途径。

5、微服务敏态开发的理论中并没有提出面向Portal或Portal库的设计理念，但是微服务会比较适应敏态报表开发。由过去使用经验得知，各种数据仓库自带的快速报表开发工具，通常没法很好的适应真实的业务报表供应场景，因为通用化和可视化化的矛盾永远无法完全磨合。那么与其设计者和最终使用者都觉得别扭，还不如我们通过敏态开发，每次开发一个舒服的报表展现，按需随时提供给使用者使用。虽然会加大开发成本，但好在微服务设计理念给了我们这种开发体系的支持能力，让我可以用最小的代价快速开发敏态报表，随时交给相应人群使用。

6、刚才提到的敏态报表理论就是目前为何 Jupyter Notebook 如此受欢迎的根本原因。OpenShift 上提供的 Open Data Hub 生态环境可以帮助客户快速实现Notebook as a Service 的能力。强化最终数据使用能力和效果。PPT资料里面放入了这部分内容，您可以参考一下PPT中的讲解。

2、不做传统数据库容器化，但应用部署在PaaS平台上，如何去对接数据层和应用层？

@赵锡漪 红帽高级解决方案架构师：

1、通常为了对原有业务的兼容以及容器化改造的简易性，我们容器化的最初阶段都是直接使用原有数据对接模型的。比如仍然使用数据原有连接池，匹配外部数据库连接地址。但如我在PPT内容中谈到的，当应用具备一定规模，这一定会导致原有数据使用压力的增加，因此我们需要在业务的敏态改造中逐步提高数据对接层面的合理性与规划性。

2、为了提高数据对接层面的合理性与规划性，最佳方案是先通过一些技术对数据直连进行隔离。有Kafka就通过Kafka 隔离出读写层，没有 Kafka 可以通过 JBoss Data Virtualization 这样的数据源虚拟化工具进行面向原逻辑的抽象隔离，但需要注意的是 JBoss Data Virtualization 这样的数据源抽象工具对复杂 SQL 使用场景非常容易产生兼容性问题或性能问题。因此将原有的复杂 SQL 这种过程处理逻辑进行一定程度的面向对象改造是很有必要的。

3、如果服务无法完全进行数据源抽象适应，例如无法拆分复杂SQL，那么我们就必须通过一定的开发来实现面向对象数据源改造。此时可以配合Red Hat Data Grid 这样的数据网格技术来实现就近数据源适应的改造了。不要忘记了 Redhat DataGrid 产品可以直接支持 Redis 的所有能力，可以完全兼容 Memcache 使用，因此非常适合将单体数据缓存改为云化适应的数据网格。

4、有了中间的数据隔离技术，Kafka/JBoss Data Grid/JBoss Data Virtulazition 这些技术就可以与原有数据元之间的关系进行梳理。比使用 Redhat Change Data Capture 工具可以很轻松的帮助用户实现如数据同步，多数据中心同步，数据应急，数据灾备，数据异地多中心同步，数据一致性传递，多数据源一致性同步等等目标，同时这些技术之间的梳理就会变的比以前简单，顺便可以重新梳理原有的分库分表结构，读写分离结构等，更进一步提高原有数据使用质量。

3、大数据分析平台容器化优势？

【问题描述】传统方式底层借助大数据平台提供计算资源，上层使用分析平台对数据进行分析，分析平台可容器化，而底层原有部署在裸金属上的组件，转换成容器化部署，是有实质性的优势，还是仅仅跟随潮流？

@赵锡漪 红帽高级解决方案架构师：

1、在另一个问题回答中 “ 应用通过容器部署由K8S调度，对于此类应用的业务连续性要求实现同城双活，异地容灾，需要考虑哪些方面？ ” 我提到了，Kubernetes 应用体系的可靠性是靠可重复部署的描述文件来保障的，由于所有的部署都可以通过yaml所描述的完成整过程快速复现，因此Kubernetes体系可以实现快速、灵活的业务部署与分布。这对于大数据的动态分布会有一定的帮助。

2、 Stateful Set 的核心意义就在于将存储与计算容器捆绑统一调度。但Stateful Set保障的是计算与存储的同步，并不保障存储的可用，因此 OpenShift 推出了 OpenShift Container Storage （OCS产品）来协助解决这个问题。软定义存储的多副本、备份恢复等手段可以结合Kubernetes来保障业务的连续性要求。从目前全球技术趋势来看，也有一种猜测大数据平台全面转向容器化的主流方案可能会在不久推出。这是因为随着Kubernetes Native Infrastructure （KNI）框架的整体成熟度不断提高。基于Ironic的裸金属调度整机容器有可能会成为大数据平台构建的基础框架。通过Stateful Set 接近整机容器的调度模式，调度裸金属的大数据节点部署。优势是，在计算资源闲余时间可以将计算资源调度用于其它计算。但我们仍然面临核心数据的连续性服务能力要求，因为微服务理论中，每个服务的数据都是整体数据模型的小局部供应模型。最终一致性还在核心数据模型上。

3、因此在今天分享的内容中多处提到了如何实现局部小数据模型如何与核心数据模型的同步与快速供应方案。这部分方案其实就是我们现在关注的数据中台，通过隔离局部数据逻辑与核心数据模型，我们通常要分拆成部分核心数据模型的子集，用于面向部分具有共性数据需求的业务上，这部分能力就是数据中台。数据中台相当于过去中间件的数据库连接池，它的实现可以帮助用户进一步解放前端业务的创新能力。借助一些微服务概念，通过蓝绿部署，金丝雀部署等方式，屏蔽数据底层核心逻辑，实现无感知化化面向应急数据源或灾备数据源的目的。从而强化容器化PaaS平台的持续服务能力。并且可以使大数据技术更容器接受一些面向未来的技术创新，使之成为数据多元化处理的引擎。

4、通过Redhat Change Data Capture 这样的技术可以实现复杂/异构/异地/差异逻辑的多数据源同步，从而协助用户实现同城双活、异地双活、异地容灾等需求的实现。并且可以有效帮助前端业务实现屏蔽后端数据技术复杂度。

@郭维  广东联通 项目经理：

众所周知，Hadoop的出现加速大数据技术的应用推广，随着应用场景的不断丰富，近几年也涌现出多款优秀的计算框架，如Spark、Flink等。此前在大数据分布式调度平台中，大家普遍采用是Yarn，但是随着应用场景丰富和规模扩大，平台逐渐暴露出一些问题，如资源隔离限制较弱、监控信息不完善、弹性扩展能力弱、GPU支持不足等。

随着容器化的快速发展，大数据原有的Hadoop Yarn分布式任务调度模式，正在被基于Kubernetes的技术架构所取代。容器凭借轻量秒级部署、一次构建、处处运行的巨大优势，推动了快捷、自动化的工作流程，同时Kubernetes提供的强大编排能力以及蓬勃发展的社区生态，为大数据容器化提供了便捷的平台。

大数据系统原生支持on Kubernetes，例如Spark 从官方2.3版本开始就可以无需任何修改直接运行在 Kubernetes 上，这是一个里程碑式的事件，表明了未来技术架构的发展方向。

由于大数据应用的复杂性，会使用多种类型的机型作为Work节点，如利用云主机应对快速的流量扩容、利用云物理服务器提供无性能损耗能力、利用云GPU服务器的大规模线程和高速计算力优势等等，来满足计算的需求。

容器引擎提供混合集群的统一管理服务，在一个集群可以实现多种类型节点的统一管理，通过Label的设置可以实现对整体资源的统一调度部署，避免了多个集群的使用，一方面大幅降低了使用成本，另一方面有效提升管理效率。

大数据业务对计算的需求是动态的，并且波动较大，容器引擎支持Cluster AutoScaler实现集群工作节点的弹性伸缩，节省开支。目前，容器引擎本身免费对外提供使用，同时提供免费的企业级容器镜像仓库服务，用户仅需支付所使用资源的费用，工作节点支持预付费包年包月、按日配置付费、按小时配置计费等灵活的计费策略选择。

大数据云平台利用容器引擎集群、云物理机集群、云服务器集群构建大数据控制平台和共享服务资源池，为用户提供租户隔离、安全可靠的大数据托管服务。

4、传统数据库如何逐步过迁移到PaaS平台？

【问题描述】目前OSS域的支撑系统的云化改造基本完成，但主要进行采集层、分析层和应用层的云化改造，基本不涉及数据库。今年都在推进大中台的建设，数据共享就涉及到数据库或者说是数据的PaaS层改造，业内并没有具体的方案可借鉴，如何快速实施又保障质量呢？

@zhuqibs Mcd 软件开发工程师：

公有云上的数据库要注意以下几点：

（1） 安全性，如果是金融数据库，有等保的要求，需要将数据库部署在金融云上。

（2） 可靠性， 公有云上的数据库，可以设置需要多少副本，副本越多，价格越高，要选用合适的。

（3） 种类， 云上的数据库PaaS也有很多种类，MySQL、Posgresql  ， AWS上还有 DynamoDB，Neptune，你要根据原先传统数据库服务的需求，选用合适的云数据Paas。

（4）迁移， 现在各个云厂商为了把云PaaS做大做强，都有工具支持从外界数据往云上迁移，你可以去找找，或联系云厂商的技术了解一下。

@赵锡漪 红帽高级解决方案架构师：

1、大中台建设从我的理解来看就是优化前端数据使用通道，相当于当年我们做三层改造时构建Model （数据中台） Control （业务中台），只是将构建范围从单个中间件平台扩大到整体容器化PaaS平台概念上。因此其改造还是很有必要和很重要的。只有推进中台建设才能真正解放前端PaaS云业务的创新能力。

2、就短期来讲数据库的PaaS构建还没有获得技术方案的统一。不同角度的厂家会推荐不同技术栈的解决方案。因此，我个人认为，短期建设任务应关注在如何构建半整合云化数据使用体系上。半整合体系将包括如何通过一些技术中台组件，连通云化业务使用数据与固化数据模型之间的通道，实现云化微服务对核心数据模型的解耦。可以通过Kafka中台技术将读写隔离，也可以通过云化数据网格实现数据中间层，还可以考虑在数据中台侧建立中间数据层。并通过一些联动、同步手段实现多层间数据的一致。

3、云化数据主体正在逐渐成熟，我个人偏爱云化数据网格技术，他可以很好的成为中间态技术。加之我们在使用MapReduce 技术上已经有很成熟的经验，可以考虑在内存层构建相当于内存 MapReduce 的敏态NoSQL数据层。对于异构数据同步我们通过大量的分库分表建设，异地/应急建设也都有了相当的经验，因此这种数据体系的构建可以充分利用我们之前的建设经验。当然这需要大量的改造配合，好在构建中台给了我们这个窗口，可以在中台建设中充分尝试新技术来提升整体系统云化成熟度。

5、容器化服务做到了模板化，当面对的是复杂产品的结构的时候，如何实现自由编排来保证创建产品环境的灵活性？

@郭维  广东联通 项目经理：

在企业级大规模容器化的情况下，如何在分布式环境中部署应用、如何管理跨机器应用，如何维护并实现负载均衡、资源配额、自动调度、在线扩容等等：这就是容器编排系统的作用。容器编排系统的英文单词是container orchestration，其中orchestration直译为“管弦乐编曲”，编曲时要考虑到如何让不同的乐器交织、如何通过先后不同乐章中让乐曲更加美妙动听。

企业在管理容器集群时更是需要容器编排系统，目前比较主流的两大方案是源自谷歌的Kubernetes和Docker公司自研的Docker Swarm。其中Kubernetes是集群管理软件，用于容器化应用程序的自动部署、扩展和管理，它支持包括Docker等在内的一系列容器工具。

早期的Kubernetes并不是很成熟，存在安全能力较弱、部署复杂等不足，而2016年Kubernetes发展迅猛，目前已经非常完备。所以，容器团队选择了在合适的时间推出Kubernetes服务，在此前的Docker Swarm基础上再添加对Kubernetes的支持。如此，用户便可以根据需要选择不同的技术方案。

条条大路通罗马，殊途同归。两者都是很好的编排系统，重点在于如何借助容器技术助力企业创新。不论是Swarm 还是Kubernetes 亦或是自有方案，用户都可以根据自己情况，选择编排方案，在技术选型上有着更大的自由。

@赵锡漪 红帽高级解决方案架构师：

非常赞同上面郭经理的专业回复。在这里再补充一点。

容器部署模板是容器化平台实现 CI/CD DevOps 的基础，业务场景部署到容器PaaS平台时，最佳实践是通过模板来控制整体部署，包括环境变量的匹配和混搭。您提到的复杂产品确实是在混合编排时比较难于标准化的关键实现。针对这种情况 Redhat 自去年起就在社区生态环境中大力推动 Operator Framework。Operator Framework 是针对复杂产品的标准化实现的最佳途径。由于 Operator 的构造中可以混入代码，因此可以保障在初始供应时实现更加复杂的判断与配置等操作。因此现在主流的复杂组件大都提供了 Operator 来强化使用体验，例如 MySQL 就有很多 Operator 可以帮助用户构建复杂的集群关系，以保证 Admin Node，SQL Node， Storage Node 可以快速有效的协同工作，同时也能够保证为最终用户供应集群时可以有更好的操作体验。同时还可以将复杂组件的开发维护、运维维护、使用维护任务区分供应来提升 DevOps 的整体工作效率。因此我个人推荐在容器PaaS平台上定制复杂产品结构，进行一定程度的任务封装，通过 Operator 来对部分可原子化的复杂组件操作进行合理的封装虽然会加大初期设计实现投入，但会有效降低真正运维期的使用难度和工作压力。

6、如何做到对容器化测试环境的管理，当用户对测试环境有任何需求的时候可以一键部署？

@mtming333 太平洋保险 系统运维工程师：

容器平台在面对测试开发时，最常见的就是换包和换配置。

在没有实现CICD的情况下，建议应用先做好配置分离改造，容器平台做好配置管理模块。

容器启动时采用模式：标准镜像+程序包+配置文件

发布生产时打成helm chart包。

@zhuqibs Mcd 软件开发工程师：

你所说的，就是传统的CICD环境啊，现在有很多工具链可以做到这点

（1）Ansible

（2）Jenkins + spinnaker

（3）gitlab-ci

（4）drone

总之，非常多，你可以选择自己熟悉的。

@赵锡漪 红帽高级解决方案架构师：

1、您问到的一键式部署是容器化云平台的核心意义所在。虽然现阶段为了兼容很多之前的业务，我们经常采取妥协态度。例如，允许开发商使用封闭式镜像，以镜像为单元部署业务等。这样的行为其实会破坏平台的一键部署能力。通常我们提供的解决方案都倾向于 Source to Image （S2I）。因为这样才能固化发布过程，保证只要开发人员可以部署到测试环境上，他的行为模式就会通过各种 S2I 的yaml直接固化并形成 Ops 人员可操作可理解的一键部署能力。那么测试人员或者维护组就可以从最新代码发起一键部署过程。而部署的关联性通常通过 CI/CD 流程保障，例如使用 Jenkins。

2、我们通常提供的方案会将环境拆分为3个部分，测试环境/Staging环境/生产环境，目的是测试环境配合测试数据，不管数据来源在哪里，但测试数据是安全脱敏，压力脱敏，引用脱敏的，开发人员可以自由发挥，完成各种业务创新与CI/CD尝试。而Staging阶段则不在参与S2I，部署是通过CI/CD流程自动化从测试环境迁移过来的。数据是安全脱敏的，其它与生产库基本一致。这个阶段我们完成压力测试，数据逻辑测试。而任何开发和变更不会反应到这个阶段。最终的生产环境是从 Staging 环境，通过审批的半自动化流程将镜像推过来的，生产的镜像库都是独立的，封闭的，不参与外部CI/CD的。任何镜像依赖在这个阶段已经不再需要，独立的完整，安全的可靠的稳定的镜像是生产业务最终持续化服务的最终保障。因此测试环境到生产环境之间是由审批隔离的，所以测试需求不会自动被推到生产商，而是由运维人员统一控制如何从 Staging转向生产。

3、测试环境与Staging环境/生产环境之间的数据供应是要统一的。接口要统一，特别是实现数据中台后。也就是说所有的数据中台接口必须统一。但内容要区别化。特别是测试环境中逐步形成的敏态数据中台逻辑。需要有合理的控制途径与管理通道才能到达生产。因为由敏态开发逻辑造成的快速变更数据接口通常相对生产环境会具有一定但差异性与时延性。因此在数据中台能力的发布对接上，我们在测试环境中需要有相应的实现方案来统管，既保证数据能力的自由组织，同时也要避免有些微发布的敏态数据中台逻辑污染数据使用通道，造成一键部署的数据逻辑错误。这一点需要具体项目具体分析。

7、大数据组件容器化如何保证存储同步的可靠性？

【问题描述】假设大数据分析平台涵盖了大数据平台组件，将大数据平台组件容器化，其中涉及到存储服务的容器化。而且大数据组件例如HDFS的3副本，如何保证容器化后存储同步的可靠性，尽可能的满足副本同步的实效性？是否需要借助外部组件来保证，还是仅仅靠平台自身的同步机制？

@赵锡漪 红帽高级解决方案架构师：

1、通常短期内我们不愿意过多的修改原有 Hadoop 体系，这里面包括了由 HDFS 所实现的多副本保障无需借助容器化来进行提升，Hadoop 体系的运算能力通常就是冗余的，因为批量运算时的性能与日常运维的资源需求差别太大，BigData 本身就是借助硬件成本降低来使用海量硬件承担特定运算任务的体系。这与容器的充分合理调配硬件资源保障有限资源内更多执行合理任务的思路是相反的等方面的原因。因此通常意义上来讲将原封不动将 Hadoop 完全照搬到容器平台上是没有意义的。但如果未来 Hadoop 体系承担的任务越多，越繁杂，那么它改造的需求就会越大。假设我们容器化了他们大部分的组件，那么参考另一个问题 “ 大数据分析平台容器化后底层存储如何设置？ ” 的答案我们可以转化HDFS在容器上的使用形式以适应容器化平台。

2、您提到的HDFS副本在容器化后如果使用其它存储解决方案时，确实会遇到同步的时效性问题。通常软件定义存储，如Ceph的副本数（Ceph采用多副本同步写不会产生写丢失的问题）与副本备份时效性都是可以配置的，但终归有可能会发生终断点于两备份中间的情况。这是任何一种备份机制都无法规避的风险。我们要做的更多是综合考虑PV所在位置与整体数据之间一致性关系的问题，就是多个关联PV之间同步备份的问题，这个需要在实施方案中具体设计。这一部分的能力如 OpenShift 来说，就是 OpenShift + OpenShift Container Storage 共同实现的，因为是配套组件所以也不能算是外部组件但也没法完全算是平台自身保障的，因为Kubernetes 的 PV/PVC 机制是不关注这一部分实现的。

3、但转化HDFS并不是目标，目标是如何将业务目标转向敏态开发与敏态部署上。因此我个人认为如果大数据平台容器化后，那么在容器云平台必然派生出大量的附加结构来，例如通过内存数据网格实现敏态数据湖，利用数据虚拟化实现统一数据视图等等，这些实现都会依赖到 Change Data Capture 这样的同步工具上来，在如何保障数据最终一致性的同时，尽量解放数据在中间使用的能力是我们将大数据平台容器化的核心意义所在。

4、Hadoop 在设计最初是希望能够替代传统 OLAP 实现更高性能的多维运算，而在真实业务场景中，这个目标并没有实现，而是我们新的建立起一套相对独立的数据使用手段。Hadoop 当年的出现时的地位与现阶段 AI/ML 出现的地位何其相似。因此未来，这两者之间一定会首先融合。融合的第一个问题就是，Hadoop 运算的很多能力与 AI/ML 是重叠的。因此慢慢的它从某种意义会变为 AI/ML 的数据供应者。而目前 AI/ML 运算模型的复杂度问题就导致 AI/ML 的供应倾向于容器化供应。

8、传统数据库迁移自建云平台后如何解决I/O瓶颈问题？

【问题描述】传统数据库迁移云平台之后，遇到的最大问题就是在较大业务压力的时候会出现明显的IO瓶颈，早期是采用集中存储方式IO问题严重，后期采用分布式存储测试效果也并不是很理想，是因为我们云化平台的主机数量太少的缘故么？我们这边整体主机数量大概几十台主机的规模。

@赵锡漪 红帽高级解决方案架构师：

1、通常来说传统数据库迁移至云平台时，我们对整体框架不做过多的变更，这意味着从数据库角度来讲基础的优化手段是不变的，这样数据库内部的索引/表/数据文件/分区/各种参数等优化过的结构都不会变。这样一来面临的主要瓶颈就只剩网络 I/O 和磁盘读写 I/O 两个重要问题需要解决。

2、通常意义上通过增加计算能力就可以满足业务需求的数据库就不考虑其I/O瓶颈了，我们只考虑性能敏感数据库。

3、数据库网络I/O优化建议考虑通过多网络平面来实现在云平台内部的网络通道优化，通过Multus这样的项目可以将数据网络通信独立到高质量网卡及对应交换机上，从而优化其网络通信能力，这包含了前段访问网络，也包含了实例间通信网络和实例至存储通信网络。但这也意味着容器化数据库的实例搭建不能完全标准化，要基于容器云平台的多网络平面设计进行适应性调整。

4、由于传统数据库迁移至云平台时通常会综合考虑多实例的调整，由于容器云平台更适应多实例统一工作，因此在多实例间的路由与转发也是需要关注的优化点。像Openshift这样基于 iptables 来实现内部service通信底层实现的方式可以有效的提升多节点间互通信息的连接效率。

5、目前来讲容器云到存储的解决方案还没有统一的高性能实现途径，大都是根据不同存储解决方案自身特点来实现的，因此最终优化途径要落实到具体选择的那种存储方案上。选择传统的高性能存储，利用Storage Class Plugin 来实现与原有存储完全一致的方案仍然是最主要提升存储I/O性能的方案。但目前也有大量的软定义存储厂商在提供各自的高性能云化存储方案，比如有些云存储厂商正在提供基于 Infiniband + RDMA 来实现PV供应的方案，从理论上来说类似这样的方案一定能够有效提升存储 I/O 的性能，有些方案可以直追高性能存储方案。但是由于这种厂商方案通常比较新，没有经过长期的市场验证。需要我们对其进行全面细致的适应性评估。

@zhuqibs Mcd 软件开发工程师：

应该说，只要有好的规划、有钱，IO根本不是事儿，自建的云平台以OpenStack为例，分为计算中心、网络中心，存储中心，调研以下三方面内容

（1）IO太慢，那一定是存储中心的问题，存储中心的CPU消耗和内存消耗要调研一下，如果太高了，要增加服务器，

（2）此外存储中心的服务器的磁盘全部换上SSD，

（3）OpenStack的存储效率也是基于网络的，所以查一下，存储中心到其他两个中心的内网连接是不是有问题。

@hufeng719 某钢铁企业 系统工程师：

个人感觉应该想下所谓的IO瓶颈是什么？主要在磁盘上对吧。无论是传统存储还是分布式存储你主要看下磁盘是哪种类型？闪存盘还是普通SAS盘 ，普通SAS盘的话转速多少？一般大容量TB的机械盘转速都不会太高。这是制约性能的一大因素。还取决于你对数据库系统分配的虚拟化资源（CPU、内存大小）等，跟主机数量多少没关系吧。

9、OpenShift是否具备跨引擎分析于同一编排的能力？

@郭维  广东联通 项目经理：

Openshift是一个开源容器云平台，是一个基于主流的容器技术Docker和Kubernetes构建的云平台。Openshift底层以Docker作为容器引擎驱动，以Kubernetes 作为容器编排引擎组件，并提供了开发语言，中间件，DevOps自动化流程工具和web console用户界面等元素，提供了一套完整的基于容器的应用云平台。OpenShift 生态系统成了 Kubernetes 生态系统。其核心技术使生态系统可以非常地灵活，社区已经在 API 和接口上做了标准化，这为统一集成的新思想成为了可能。它还使我们可以在任何云平台上部署 OpenShift，比如 AWS、 Azure、 GCP、 OpenStack、 VMware、 RHV，以及 bare meta。

@赵锡漪 红帽高级解决方案架构师：

针对这个问题不知道我是否理解的正确。我理解的是 a）OpenShift 是否可以跨集群跨技术实现统一容器编排？b） OpenShift 是否具有跨集群跨技术的统一分析引擎？c）复杂的统一编排数据是否可以被用于监控、分析。

1、Openshift 的跨引擎编排是依赖生态软件的统一性的。例如在Kubernetes上通常依赖较为流行的 Jenkins 流程编排引擎。由于OpenShift与其它Kuberenetes平台的的Jenkins是一致的，因此可以实现多集群的或者跨集群的统一编排。而在这种场景编排主体并不是 OpenShift ，而是 Jenkins。OpenShift 内嵌提供自动化 Jenkins 供应，用户可以选择使用OpenShift供应的 Jenkins，还是使用自行构建的Jenkins Server，来统一调度包括 OpenShift 在内的多集群容器编排任务。

2、OpenShift 目前使用的管理体系是 EFK （ElasticSearch/Flund/Kibana）再加 Promethues + Grafana。这是目前最主流的监控、分析管理技术栈。用户在使用 OpenShift 的时候能够自动获得相应的完整软件堆栈。但我不得不指出想要用好这个完整的技术栈，需要大量的适应性配置与集群定制。这方面 Redhat 提供了各种服务来帮助用户实现这部分的使用，就是因为将它们定制的完全适应业务需求是一个长期的体系化的系统化任务。

3、OpenShift 社区正在实现一个 Hive 项目，他的目标是让整个 Kubernetes Cluster as a Serverice。也就是说，用户未来可能面临的是随时可以快速构建的整个集群，连带集群上的所有业务及数据。这种方式更适合未来的使用模型，比如灵活数据中心模型，多云供应模型，边缘计算供应模型等。这个Hive项目中就包括了多集群，甚至混合自制 kubernetes 都可以实现统一监控的能力。当然也包括实现上面的混合编排等。

4、Kubernetes 的监控管理体系是一个开放体系，正在不断的加入各种新的、开放的分析能力。包括未来的 AI/ML 的 AIOps 能力，也可以通过这种开放体系不断注入。在可见的未来，您可能就可以在 Redhat OpenData Hub上通过 Operator 快速订阅一个包含 ML 能力的完整 AIOps 插件，用以在 OpenShift 庞大的监控、分析管理数据中发现那些人为管理所无法关注到的隐性管理问题。

10、OpenShift是如何支撑持续交付的？

【问题描述】现在开发中持续交付是基本的要求，也就是说我们需要跟研发流程中所涉及到的各个系统，比如 jira 系统、github 系统发布系统集成起来，达到代码的持续集成持续发布的目的，OpenShift是如何支撑持续交付的？

@郭维  广东联通 项目经理：

如果要打造一个持续交付的流水线，首先要考虑多环境的问题。一般一个应用程序会有多个环境，比如开发环境、集成测试环境、系统测试环境、用户验收测试环境、类生产环境、生产环境。如何在OpenShift中隔离并建立对这些环境的部署流程有多种方案可以选择。

1. 同一个project中使用label和唯一名称来区分不同的环境；

2. 集群中的不同project来隔离环境；

3. 跨集群来隔离环境。我们以第二种方式为例，演示下多环境管理问题。  在上图中，我们有一个build project。build project包含了一组相互依赖性比较强的应用，每个应用对应一个build config，产生的Image Stream存放在image register中。而每个环境各对应一个project，其中包含了该应用的deployment config，其镜像输入是build config产生的Image Stream。之所以这样做，有以下几点考虑：

4. 不同的环境分布在不同的project中，可以很好的借助project的特性进行环境隔离。比如sys project的容器只能部署在label为sys的node上，prod project的容器只能部署在label为prod的node上。

5. 不同的project可以分别定义权限访问和控制。比如只有QA才能操作sys project中的资源，运维工程师才能操作prod project中的资源。

6. 不同的环境共用一个Image Stream，保证了应用程序镜像在不同环境中的是完全一致的，防止由于测试环境和生产环境不一致而引入缺陷。

@赵锡漪 红帽高级解决方案架构师：

感谢郭经理的专业答复，郭经理将完整的持续交付流程描述的非常清楚。在这里我只补充一点：

在另一个问题的答复中我也提到 OpenShift 与大部分主流的开发体系是可以无缝对接的，比如 jira 、Iris、github 、gitlab。 用户可以仍然使用其原有习惯发起统一持续发布任务，能够有效的实现代码的持续集成持续发布的目的。但在实现持续发布的过程中通常我个人愿意建议企业级用户将实现持续交付的镜像库分为三层。用户只与第一层和第二层镜像库发生自动化关联的持续发布，第三层处于生产区，其持续发布是独立的倾向 Ops 的，而不是 Dev 的。

第一层，是企业级基础镜像库，它将用于存储企业内部所有用于基础构建的的基础镜像，包括通过一些前期沉淀形成的技术型基础镜像，用于帮助企业内部实现基础镜像统一化、安全化、可控化。特别是一些基础的安全防范、安全扫描、漏洞扫补都需要在这一层完善，保障整体企业持续构建的安全可靠。在一些大型企业中，这个基础镜像库可以是去中心化多点同步的，包括在边缘计算场景中，这个基础镜像中心也可以是全国统一同步的。

第二层，是OpenShift内部镜像库，在OpenShift 内是通过 Image Streams组件提供的，它的任务是承载/管理用户在持续构建中不断创建各种版本的业务镜像。这部分能力 OpenShift 已经完全为用户设计好了，在 OpenShift 中它是租户隔离的。可以与基础镜像及产品镜像库自动安全互通的，但是被安全隔离的中间镜像库。

第三层，是真正的产品镜像库，它的任务是承担所有产品化版本的镜像。除了保障镜像的安全、可靠外。它的变更是需要审批的，他的入库是自动化的，通过版本控制统一调度的。因为它将会承担最终面向用户的产品版本镜像。企业将基于这个镜像库来完成最终产品化镜像的发布与回退。因此它的镜像必须具备完整的轨迹管理与审计管理，必须要保留完整的版本序列。保证业务发布时，不同组件间的版本同步性，同步上线或同步回退。

虽然第一层和第三层有时候在物理上可以合一，但逻辑上还是要分开的，因为其中的管理策略会有差异。

11、容器化服务做到了模板化，当面对的是复杂产品的结构的时候，如何实现自由编排来保证创建产品环境的灵活性？

@赵锡漪 红帽高级解决方案架构师：

容器部署模板是容器化平台实现 CI/CD DevOps 的基础，业务场景部署到容器PaaS平台时，最佳实践是通过模板来控制整体部署，包括环境变量的匹配和混搭。大部分业务场景 OpenShift 提供的Template构建足以应付常见业务编排场景。但您提到的复杂产品确实是在混合编排时比较难于标准化的关键实现，有些足够复杂的业务场景会导致模版编排的过于复杂，或导致有些参数无法完全灵活应对各种场景。针对这种情况 Redhat 自去年起就在社区生态环境中大力推动 Operator Framework。Operator Framework 是针对复杂产品的标准化实现的最佳途径。由于 Operator 的构造中可以混入代码，因此可以保障在初始供应时实现更加复杂的判断与配置等操作。因此现在主流的复杂组件大都提供了 Operator 来强化使用体验，例如 MySQL 就有很多 Operator 可以帮助用户构建复杂的集群关系，以保证 Admin Node，SQL Node， Storage Node 可以快速有效的协同工作，同时也能够保证为最终用户供应集群时可以有更好的操作体验。同时还可以将复杂组件的开发维护、运维维护、使用维护任务区分供应来提升 DevOps 的整体工作效率。因此我个人推荐在容器PaaS平台上定制复杂产品结构，进行一定程度的任务封装，通过 Operator 来对部分可原子化的复杂组件操作进行合理的封装虽然会加大初期设计实现投入，但会有效降低真正运维期的使用难度和工作压力。

当 Operator 的抽象设计相对合理时，一方面可以保证面对复杂产品结构的一键管理性，另一方面通过重组的参数交互式制定可以有效保障创建的灵活性。这是一种将复杂度转嫁给产品提供者的技术。但通常产品提供者会更了解产品的各种复杂场景下的合理应对方式，从这个角度讲 Operator Framework 是一种更合理的技术难度分配框架。

@zhuqibs Mcd 软件开发工程师：

（1）helm

它是一个命令行工具，帮你同时编排多个K8S资源（比如：Deployment+Service+Ingress这样的经典组合），统一发布到K8S。底层原理就是调用K8S的apiserver，逐个YAML推送给K8S，和我们手动去做没多少差别，所以 其弊端就是缺乏对资源的全生命期监控

（2）CRD

它就是自定义K8S资源类型。内置的资源类型包含POD、Deployment、Configmap等等，我们可以通过CRD机制注册新的资源类型到K8S中。

（3）operator

 是开发CRD的一个脚手架项目，目的是帮我们实现CRD。

（4）operator+helm

operator实现了一套针对Helm的通用CRD controller，我们可以直接把提前写好的helm编排配置随着CRD controller一起打包成docker镜像，然后把它部署到K8S里运行。此后，我们只要创建CRD对应的资源对象，在YAML的spec里填写helm的模板参数，那么CRD controller就会把值填充到helm模板里，然后按照helm的方式发布到K8S集群里。

标签：数据分析,容器,实现,可以,平台,数据,OpenShift
来源： https://blog.51cto.com/u_15127582/2750516