Elasticsearch容器化私有云实践Word格式.docx
- 文档编号:22147153
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:18
- 大小:606.71KB
Elasticsearch容器化私有云实践Word格式.docx
《Elasticsearch容器化私有云实践Word格式.docx》由会员分享,可在线阅读,更多相关《Elasticsearch容器化私有云实践Word格式.docx(18页珍藏版)》请在冰豆网上搜索。
背景与现状
2015年底到2016年初的这段时间,公司业务线对ES的需求量暴增,传统的使用ES的方式逐渐显现出一些弊端,主要有一下几点的内容:
针对上述所列的几点弊端,我们最初制定的几点设计目标如下:
最终,为了达到这几点目标,我们就设计和开发了这个平台。
自从16年3、4月份这个平台上线以来,工作效率得到了很大改进,主要有以下三个方面:
下面这个图是统计的过去传统的使用方式与现在的平台的方式使用ES所带来的资源利用率的提升:
这个是我们目前的平台规模:
整个平台支持了很多重要系统后端的数据存储,比如:
技术实现
刚开始做这个平台的时候,我们主要调研参考了以下三个系统和平台:
第一个ElasticCloud是Elastic官方提供的一个公有云的服务,他能够提供快速集群构建的能力,也具备自助化配置,快速扩容能力,比较符合我们的预期功能。
第二个AmazonElasticsearchService同样也是一个公有云服务,能够提供快速的集群构建能力,自助化配置等等,同样也为我们提供了极大的参考价值。
第三个是一个开源的基于Mesos的一个调度框架,他的设计是一个Framework代表一个ES集群,Framework的每一个Executor代表一个ES节点,但是也有许多不支持,包括不支持多种角色节点的配置,不支持自助化的配置,不支持插件的安装,这与我们的设计初衷是相违背的。
结合了上述三个例子,我们设计指定了我们自己的技术方案。
整个平台基于Mesos,所有组件以Docker容器的形式被Marathon调度跑起来,这个是一个整体的结构图:
我们底层所有的机器都是被同一个Mesos来进行统一管理的,Mesos之上运行着Marathon调度框架,值得注意的是,我们有两层的Marathon,底层比较大的Marathon我们称之为RootMarathon,上层包含在RootMarathon之中的小的Marathon我们称之为SubMarathon,RootMarathon只负责调度内层的SubMarathon,内存的SubMarathon才是真正承载着我们每一个EsSaas服务。
我们所有的组件都是跑在Docker容器里面的。
那么我们平台的资源是怎么分配的呢,这个图是一个分配的结构图,可以看到资源是按照Marathon分层的这种方式来分配的,RootMarathon拥有系统所有的资源,SubMarathon是资源分配的最小单位,每一个都有它既定的资源,资源结构如此,当然集群间的逻辑隔离也是如此。
SubMarathon不仅有他自己的资源,而且我们将它和业务线做了一一映射,也就是说一个SubMarathon唯一的代表一个业务线,同时它也是承载了业务线的所有集群。
下面这个图展示的是SubMarathon内部细节的结构图:
一个SubMarathon可以承载多个ES集群,每一个ES集群有4个重要的组件,分别是:
Bamboo,es-master,es-datanode,es2graphite,这4个组件是组成ES集群的基础,他们分别对应着一个Marathon的APP,APP的task是真正的ES节点。
下面这个图展示了上述4种基础组件之间的关系:
默认的ES有3个master节点和3个datanode节点,他们分为两个MarathonAPP独立运行,他们之间互相的服务发现是由Bamboo+HAProxy这个组件来完成的,这样他们才能连成一个集群,es2graphite负责收集ES集群指标,它的原理就是调用ES内部的接口获取指标,然后聚合打到后端的Graphite上分析展示。
pyadvisor这个组件不是存在每一个集群中的,而是run在每一个mesosslave上的一个服务,他们负责收集容器维度的指标,聚合之后打到后端Graphite上实时展示,下面就是一个具体的slave机器上的快照:
每个机器上可以跑多个ES节点,不同的ES节点之间使用端口号来区别。
在每一个ES集群中,起着至关重要作用的就是服务发现,而这个服务发现是由Bamboo+HAProxy这个组件来完成的。
Bamboo是一个开源的跑在Marathon之上服务发现的工具,它的原理就是注册了Marathon的callback接口接受Marathon事件消息时时解析并reloadhaproxy。
ES集群内部服务发现的配置其实只是用了一句图中的配置项,这个配置项是ES的单播地址,是告诉ES节点去哪个机器的哪个端口找master的,我们只是简单的把他替换成了Haproxy的host和port。
ES节点在起来的时候,Bamboo检测到启动事件,随即通过MarathonAPI获取到真实的Master的host和port,然后ReloadHaproxy建立端口转发关系,同时,ESDatanode节点在起来的时候,就会通过Haproxy的前端host和port经转发到真实的Master地址上,由此实现了服务发现的过程。
三个Master之间也是同样的道理,他们通过Haproxy再“回连”自己。
在数据持久化和可靠性方面我们做了一下几个方面的工作:
配置和部署
接下来介绍一下我们做的自助配置和持续构建方面的工作,有关所有的ES的配置我们都存在了GitLab中,包括一个特殊的pre-run文件,这个文件定义了在我们启动ES节点实例之前我们该做些什么,这个文件是可以修改的,可以由业务线同学自定义。
同时一些其他的配置文件也是存在GitLab上的,修改之后,只需要重启容器即可生效。
同时我们在自助管理方面也做了一些工作,下图是我们自己做的一个Web系统,用来展示详细的集群信息和做一些自助化配置方面的工作。
在新集群交付的时候,我们也是直接交付这个Web页面,业务线同学可以很方便的查到信息,也可以很方便的做一些操作。
说到交付,我们在持续构建方面也做了一些工作。
这个是新的ES集群从配置到部署到上线的整个过程,都是基于Jenkins来做的,一共有三步,第一步是配置的初始化,这一步中会生成部署过程中所有的配置文件,生成之后直接存储到GitLab中,到了第二步集群部署的时候,我们会按照顺序读取配置,一一的将各个组件提交到Marathon,最后一步就是Marathon调度运行,等全部完成之后,我们一个完整的ES集群也就work了。
监控与报警
最后一部分说一下监控和报警,监控指标的收集,主要有两个方式:
下面是指标聚合之后的一个示例:
关于报警,主要有一下几个方面:
最后,用一张图来总结一下所有的内容:
从ES的建立到销毁,我们做到了ES集群整个生命周期的管理,建立初我们会做容量预估和参数的配置,等到部署的时候,我们有持续构建部署的工具来做,服务上线之后我们提供了可以自助配置,自助插件的web工具,极大的方便了开发人员,同时也有完备的监控和报警。
集群下线的时候,统一的回收资源,做一些清理拓补的工作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Elasticsearch 容器 私有 实践