保险行业PaaS容器云平台解决方案

保险行业PaaS容器云平台解决方案目录保险行业S容器云平台解决方案 项目背景 3PaaS容器云平台概述 3保险技术转型概述 3红帽OpenShift平台概述 4需求分析 5架构设计 5整体部署架构 5平台架构图 6权限管理 7多租户管理 8日志和监控 8DMZ区计算节点应用部署方案 13传统应用访问策略 13数据库访问方案及防火墙策略 14高可用 17docker本地存储 21持久化存储 21项目总结 21项目背景PaaS进入21世纪，我们的社会和经济发生了巨大的变化，社会对各行业服务的要求越来越高、越来越细致。新的需求如洪水一样滔滔不绝地从市场的第一线喷涌到企业的产品部门和IT部门。为了满足业务的需求，企业IT在不断地变革，而且从未停步。从客户端/服务器模型，变革为浏览器/服务端模型，从庞大的信息孤岛，变革为基于服务的架构（SOA），从物理机，到虚拟化，再到基础架构云（IaaS）和应用云（PaaS）。通过近十年云化的推进，大多数有一定规模的企业已经实现了基础架构资源的云化和池化，这里的资源指的是诸如虚拟机、数据库、网络、存储。用户可以用很短的时间获取业务应用所需的机器、存储和数据库。基础架构资源云化其实并不是目的，而是手段。最终的目标是让承载业务的应用可以更快地上线。但现实是，通过IaaS获取的大量的基础架构资源并不能被我们的最终业务应用直接消费。应用还必须进行或繁或简的部署和配置，才可能运行在云化的虚拟机之上。部署涉及操作系统配置的修改、编程语言运行环境的安装配置以及中间件的安装配置等。部署的过程在一些企业仍然是通过手工完成，低效且容易出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了后期更高级别的要求，如动态扩容、持续部署。即使勉强通过了简单的自动化实现，后期随着部署平台类型的增多以及复杂化，维护的难度将会陡然增高，无法真正做到随时随地持续交付、部署。基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的地位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。保险技术转型概述未来的规划，保险将以保险行业的产业链延伸、客户导向及互联网+为战略发展方向，需要BI分析、业务动态扩展、以及敏捷的产品与服务对接和装配的能力支撑，基于以上的技术要求，优化建设支撑企业业务及应用运营的基础设施，结合基础资源现状，建立云计算技术能力，形成快速响应，可持续发展的下一代数据中心。如图所示，对比传统方案，容器云的方案，将在对微服务架构的支持、业务弹性扩容、自动化部署、产品快速上线、敏捷/迭代、全面系统监控等方面对IT部门带来全方位的提升。OpenShiftOpenShiftDockerKubernetes5DockerCloudFoundryWarden、OpenShiftDearDockerDocker，并推出了市场上第一个基于DockerKubernetesPaaSOpenShiftDockerKubernetesOpenShiftRedHatOpenShiftDockerKubernetes通过OpenShift这个平台，企业可以快速在内部网络中构建出一个多租户的云平台，在这朵云上提供应用开发、测试、部署、运维的各项服务。OpenShift在一个平台上贯通开发、测试、部署、运维的流程，实现高度的自动化，满足应用持续集成及持续交付和部署的需求；满足企业及组织对容器管理、容器编排的需求。通过OpenShift的灵活架构，企业可以以OpenShift作为核心，在其上搭建一个企业的DevOps引擎，推动企业的DevOps变革和转型。需求分析秉承统筹规划、顶层设计原则，围绕“移动、云、大数据”等新技术，提高信息数字化水战略实施，最终将数字化打造成保险的核心竞争力。对基础架构的建设提出了新的要求：对于渠道类系统（如网销、网关、移动），的波动和动态扩张，此类系统需要资源的动态供给；对于运营类系统（如承保再保系统），的可扩展、易管理能力的支撑；对于数据分析类系统（如大数据分析平台、车联网平台），存储、大数据分布式流计算、异步消息传输支持，需要云平台的支撑。架构设计整体部署架构DMZ2OpenshiftDMZDMZOpenshiftOpenshift平台架构图本次采取的产品方案是红帽Openshift3.5（参照应用使用版本，RHEL最新是7.3；使用一主多从模式）。OCP以Docker技术和kubernetes框架为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（s2i/jenkins）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案。权限管理对于企业级的应用平台来说，会有来自企业内外不同角色的用户，所以灵活的、细粒度的、可扩展的权限管理是必不可少的。OCP从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。1OCPOCPAPIOCPAPIOCPOCPOAuthOAuth2、鉴权：权策略决定了一个用户是否具有对个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。除了传统的认证和鉴权功能，OCP还提供了针对pod的细粒度权限控SCC（securitycontextconstraints），可以限制pod具备何种类型的权限，比如容器是否可以运行在特权模式下、是否可以挂在宿主机的目录、是否可以使用宿主机的端口、是否可以以root用户运行等。Openshift部署环境不与统一认证对接，采取预先创建账户基于Htpasswd存储的模式。多租户管理租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。OCPprojectkubernetesnamespace，Project，OCPOCPprojectproject网络隔离。OCPopenvswitchprojectprojectID（VNID），VNIDopenvswitchRouterRouterOCPOCP集群内部的能力。OCPRouterproject物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针对这种类型的需求，OCPnodeSelectorproject日志和监控传统应用日志有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，对于这部分的日志我们需要持久化到外置存储中。日志的分类如下：中间件日志dump应用日志NFSOCPnamespace新应用日志应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：日志采集，将日志集中在一起索引日志内容，快速返回查询结果具有伸缩性，在各个环节都能够扩容强大的图形查询工具、报表产出工具EFK是Elasticsearch(以下简写为ES)+Fluentd+Kibana的简称。ES负责数据的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。Fluentd无论在性能上，还是在功能上都表现突出，尤其在收集容器日志领域更是独树一帜，成为众多PAAS平台日志收集的标准方案。Openshift部署环境使用EFK进行日志管理。QA环境和生产环境部署描述如下：FluentdDaemonSetdockerOCPFluentdES用于日志存储，会部署在infra结点，同时配置成replicas=2，实现高可用。监控PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总和信息展示等几个部分组成。Openshiftkubenetescadvisorheapster，heapsterCassandrahawkularCassandra1、组件说明Openshift的监控组件，用于对pod运行状态的CPU、内存、网络进行实时监控，和Kubernetes使用的监控技术栈一样，包括三个部分：HEAPSTER用于监控数据的采集/kubernetes/heapsterHAWKULARMETRICS属于开源监控解决方案Hawkular，基于JSON格式管理、展示监控数据/CASSANDRAApacheCassandra是一个开源的分布式数据库，专门用于处理大数据量业务/2、架构概述如下图所示，HeapsterNodecAdvisorCassandra，由HawkuarMetricsQA环境和生产环境部署描述如下：HEAPSTER,HAWKULAR,CASSANDRA组件都以容器方式运行在OCP计算结点中，并且分别配置成replicas=2，实现高可用。3、与OCP系统集成WebMetricsOCPWebpodCPU点击pod的Metrics按钮，可以看到一段时间内监控信息的变化数据：弹性伸缩目前OCP系统可以基于CPU阈值的配置，对pod的复制数量进行弹性伸缩。而弹性伸缩的CPU数据，基于Metrics采集获取。相关介绍如下：/latest/dev_guide/pod_autoscaling.html资源初始化OCP系统可以基于类似pod资源消耗情况，对新部署pod的消耗资源进行预判，并以此分配初始资源。RestAPIHawkularMetrics提供了RestAPI接口，可以调用该接口进行监控、报警等进一步定制，参照：/openshift/origin-metrics/blob/master/docs/hawkular_metrics.adocOpenshift部署环境使用自带的监控方式对容器和平台进行监控。DMZ在DMZ区应用部署遵循以下策略：用请新的计算资源本期项目中，XXXDMZ2；XXX2DMZXXX2在部署XXX应用使，nodeSelector需要指明使用的节点的标签为XXX=XXX。传统应用访问策略OpenshiftNodePortServiceService端口都会预留给该应用所用。F5VSPoolMemberKeepalivedHA应用系统和用户不用改变现有的访问方式NodePortSVC我们可以直接通过端口30001访问应用。数据库访问方案及防火墙策略内网计算节点可以直接访问数据库DMZ区计算节点访问数据库有2种方案：计算节点直接通过内网防火墙访问该应用数据库内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期项目，xxx应用仅使用2个节点，则防火墙仅开通这2个节点访问xxx数据库的权限Outbound路由通过内网防火墙访问内网数据ooOutboundOpenshiftEgressRoutero因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限高可用外部镜像仓库高可用OCPOCPQACD2F5F5F5NFSMasterOpenshift的Master主控节点承担了集群的管理工作，计算节点（容器应用）高可用计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。应用高可用基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。dockerdocker运行过程中