要不要也来分享分享一下啊
ECE

ECE

Day 21 - ECE 版本升级扫雷实战

ElasticsearchBen_Wu 发表了文章 • 1 个评论 • 1095 次浏览 • 2018-12-21 10:50 • 来自相关话题

Elastic Cloud Enterprise 出来也有一年多的时间了。对于这类的开源软件企业版本,基本都是在可管理性和稳定性上面下功夫。但是新产品免不了需要经历一下bug的打磨才会变得成熟。 下面分享的这个案例是当我们在把集群从5.4.1 升级到5.6.12 的过程中,遇到节点关闭受阻,升级不完整等情景。以及对应的处理方法。 首先在ECE中,版本是通过stack的方式管理  
QQ20181221-104539@2x.png
Ref : https://www.elastic.co/guide/e ... .html 这些版本都是以docker images的形式存储
QQ20181221-104619@2x.png
因此,ECE根据不同的版本,然后选择对应的docker image就可以创建一个节点了. 那么升级的过程就可以简单分成几个步骤 1.exclude准备升级的节点。 2.停止节点ES进程,更换container 版本。 3.重新启动节点,加入集群。 4.在其他节点上重复以上流程。 在这个过程中, 实际使用的时候发现有一些需要注意的雷区. 扫雷一:使用UI触发升级,必须保证集群没有自定义插件和bundles ECE 里面的集群操作是通过plan来控制的
QQ20181221-104650@2x.png
任何的集群操作最终都会生成一个plan的diff。如上图,把集群从5.4.1 升级到 5.6.12 会产生以上diff. 正常情况下是没有问题的. 如果集群配置了自定义bundles, 比如LDAP bundles, ref:https://www.elastic.co/guide/e ... .html 那么在集群的plan里面就会存在这么一段配置
QQ20181221-104718@2x.png
那么当我们在按下升级按钮的时候
QQ20181221-104744@2x.png
ECE 只在plan中修改了集群大版本的配置, 但是并没有修改自定义bundles中的版本号(仍然是5.4.1). 在这种情况下去执行升级,会直接产生报错.
QQ20181221-104810@2x.png
界面上没有显示原因, 但是这是因为plan里面大版本和bundle中的版本不一致,然后会导致新增的节点无法启动. 于是ECE 就认为集群升级失败了. 解决方法是手动编辑plan,把自定义bundles中的版本号改成和集群版本一致
QQ20181221-104848@2x.png
然后使用ECE 提供的一种手动使用plan进行集群升级的方式进行升级. 扫雷二:节点无法关闭 ECE 控制container 是通过一个叫做 constructor的服务。constructor 通过接收集群的更改需求,制定具体的更改计划与步骤,指导allocator对container进行操作。同时也负责保证集群高可靠性,通过Availability Zone的数量在不同的AZ上面部署节点。 当Allocator接受到关闭container命令的时候,会尝试去关闭container,如果container处于一个阻塞状态无法响应, 那么关闭命令无法执行成功。这个时候constructor会等待节点关闭,但是allocator又认为节点已经接受到关闭命令了。又或者constructor发送给allocator的过程中网络丢包, 这个时候allocator 没有正确接受关闭container的命令. 整个升级进程就卡住了。 这种情况十分罕见,通常发现一个container如果处于”正在关闭”时间太久了, 那么通常就是中间的通信出现问题了.
QQ20181221-104926@2x.png
解决办法是可以通过手动停止container, 在对应的allocator上面找到container,使用 docker stop <container_name> 停止container,这样可以出发allocator更新container的健康状态,上报这个container已经关闭了, 从而打通流程并执行下一步。 扫雷三: 多版本并存 如果使用上面的方式强行关闭docker container, 虽然可以让升级进程继续进行下去. 但是被手动关闭的节点会保留原来的版本。于是在升级后查看各个节点的版本,会发现部分节点是5.4.1, 部分是5.6.12. 因为节点是强制关闭的, ECE直接认为节点已经完成升级,并重新启动这个container. 而在这个处理中,跳过了升级docker image的一步. 为什么不是生成一个新的container呢? 因为从plan里面可以看到
QQ20181221-104951@2x.png
在默认情况下, ECE 处理版本升级是使用rolling 策略 Ref: https://www.elastic.co/guide/e ... .html 在这个策略下,ECE会停止当前container并直接修改重启。 如果ECE集群容量允许, 可以改成grow_and_shrink 策略, 这样ECE 会创建新的container并且销毁旧的container, 避免集群出现多版本. 如果出现了多版本的集群,可以通过更改集群任意一个配置来触发 grow_and_shrink 同样可以使到版本回归一致. 总结来说ECE 在版本升级方面还是有很多需要改进的地方. 对于ECE用户再说在使用ECE的版本升级功能的时候主要有以下建议 1. 自己学会手动修改plan. 这也是每一个ECE support engineer 都会干的事情. 2.如果集群容量允许,尽量使用 grow_and_shrink的策略来进行集群操作.  

Elastic日报 第483期 (2018-12-19)

Elastic日报elk123 发表了文章 • 0 个评论 • 559 次浏览 • 2018-12-19 19:35 • 来自相关话题

1、ECE 2.0:为你的使用场景助力加油。 http://t.cn/E421UUE ​2、(自备梯子)如何使用es和react构建电子商务搜索。 http://t.cn/E42BSad ​3、Elastic:Beyond Search! http://t.cn/E42dIzz 编辑:wt 归档:https://elasticsearch.cn/article/6210 订阅:https://tinyletter.com/elastic-daily
1、ECE 2.0:为你的使用场景助力加油。 http://t.cn/E421UUE ​2、(自备梯子)如何使用es和react构建电子商务搜索。 http://t.cn/E42BSad ​3、Elastic:Beyond Search! http://t.cn/E42dIzz 编辑:wt 归档:https://elasticsearch.cn/article/6210 订阅:https://tinyletter.com/elastic-daily

Day 21 - ECE 版本升级扫雷实战

ElasticsearchBen_Wu 发表了文章 • 1 个评论 • 1095 次浏览 • 2018-12-21 10:50 • 来自相关话题

Elastic Cloud Enterprise 出来也有一年多的时间了。对于这类的开源软件企业版本,基本都是在可管理性和稳定性上面下功夫。但是新产品免不了需要经历一下bug的打磨才会变得成熟。 下面分享的这个案例是当我们在把集群从5.4.1 升级到5.6.12 的过程中,遇到节点关闭受阻,升级不完整等情景。以及对应的处理方法。 首先在ECE中,版本是通过stack的方式管理  
QQ20181221-104539@2x.png
Ref : https://www.elastic.co/guide/e ... .html 这些版本都是以docker images的形式存储
QQ20181221-104619@2x.png
因此,ECE根据不同的版本,然后选择对应的docker image就可以创建一个节点了. 那么升级的过程就可以简单分成几个步骤 1.exclude准备升级的节点。 2.停止节点ES进程,更换container 版本。 3.重新启动节点,加入集群。 4.在其他节点上重复以上流程。 在这个过程中, 实际使用的时候发现有一些需要注意的雷区. 扫雷一:使用UI触发升级,必须保证集群没有自定义插件和bundles ECE 里面的集群操作是通过plan来控制的
QQ20181221-104650@2x.png
任何的集群操作最终都会生成一个plan的diff。如上图,把集群从5.4.1 升级到 5.6.12 会产生以上diff. 正常情况下是没有问题的. 如果集群配置了自定义bundles, 比如LDAP bundles, ref:https://www.elastic.co/guide/e ... .html 那么在集群的plan里面就会存在这么一段配置
QQ20181221-104718@2x.png
那么当我们在按下升级按钮的时候
QQ20181221-104744@2x.png
ECE 只在plan中修改了集群大版本的配置, 但是并没有修改自定义bundles中的版本号(仍然是5.4.1). 在这种情况下去执行升级,会直接产生报错.
QQ20181221-104810@2x.png
界面上没有显示原因, 但是这是因为plan里面大版本和bundle中的版本不一致,然后会导致新增的节点无法启动. 于是ECE 就认为集群升级失败了. 解决方法是手动编辑plan,把自定义bundles中的版本号改成和集群版本一致
QQ20181221-104848@2x.png
然后使用ECE 提供的一种手动使用plan进行集群升级的方式进行升级. 扫雷二:节点无法关闭 ECE 控制container 是通过一个叫做 constructor的服务。constructor 通过接收集群的更改需求,制定具体的更改计划与步骤,指导allocator对container进行操作。同时也负责保证集群高可靠性,通过Availability Zone的数量在不同的AZ上面部署节点。 当Allocator接受到关闭container命令的时候,会尝试去关闭container,如果container处于一个阻塞状态无法响应, 那么关闭命令无法执行成功。这个时候constructor会等待节点关闭,但是allocator又认为节点已经接受到关闭命令了。又或者constructor发送给allocator的过程中网络丢包, 这个时候allocator 没有正确接受关闭container的命令. 整个升级进程就卡住了。 这种情况十分罕见,通常发现一个container如果处于”正在关闭”时间太久了, 那么通常就是中间的通信出现问题了.
QQ20181221-104926@2x.png
解决办法是可以通过手动停止container, 在对应的allocator上面找到container,使用 docker stop <container_name> 停止container,这样可以出发allocator更新container的健康状态,上报这个container已经关闭了, 从而打通流程并执行下一步。 扫雷三: 多版本并存 如果使用上面的方式强行关闭docker container, 虽然可以让升级进程继续进行下去. 但是被手动关闭的节点会保留原来的版本。于是在升级后查看各个节点的版本,会发现部分节点是5.4.1, 部分是5.6.12. 因为节点是强制关闭的, ECE直接认为节点已经完成升级,并重新启动这个container. 而在这个处理中,跳过了升级docker image的一步. 为什么不是生成一个新的container呢? 因为从plan里面可以看到
QQ20181221-104951@2x.png
在默认情况下, ECE 处理版本升级是使用rolling 策略 Ref: https://www.elastic.co/guide/e ... .html 在这个策略下,ECE会停止当前container并直接修改重启。 如果ECE集群容量允许, 可以改成grow_and_shrink 策略, 这样ECE 会创建新的container并且销毁旧的container, 避免集群出现多版本. 如果出现了多版本的集群,可以通过更改集群任意一个配置来触发 grow_and_shrink 同样可以使到版本回归一致. 总结来说ECE 在版本升级方面还是有很多需要改进的地方. 对于ECE用户再说在使用ECE的版本升级功能的时候主要有以下建议 1. 自己学会手动修改plan. 这也是每一个ECE support engineer 都会干的事情. 2.如果集群容量允许,尽量使用 grow_and_shrink的策略来进行集群操作.  

Elastic日报 第483期 (2018-12-19)

Elastic日报elk123 发表了文章 • 0 个评论 • 559 次浏览 • 2018-12-19 19:35 • 来自相关话题

1、ECE 2.0:为你的使用场景助力加油。 http://t.cn/E421UUE ​2、(自备梯子)如何使用es和react构建电子商务搜索。 http://t.cn/E42BSad ​3、Elastic:Beyond Search! http://t.cn/E42dIzz 编辑:wt 归档:https://elasticsearch.cn/article/6210 订阅:https://tinyletter.com/elastic-daily
1、ECE 2.0:为你的使用场景助力加油。 http://t.cn/E421UUE ​2、(自备梯子)如何使用es和react构建电子商务搜索。 http://t.cn/E42BSad ​3、Elastic:Beyond Search! http://t.cn/E42dIzz 编辑:wt 归档:https://elasticsearch.cn/article/6210 订阅:https://tinyletter.com/elastic-daily