ECE
Day 21 - ECE 版本升级扫雷实战
Elasticsearch • Ben_Wu 发表了文章 • 1 个评论 • 3035 次浏览 • 2018-12-21 10:50
Elastic Cloud Enterprise 出来也有一年多的时间了。对于这类的开源软件企业版本，基本都是在可管理性和稳定性上面下功夫。但是新产品免不了需要经历一下bug的打磨才会变得成熟。
下面分享的这个案例是当我们在把集群从5.4.1 升级到5.6.12 的过程中，遇到节点关闭受阻，升级不完整等情景。以及对应的处理方法。
首先在ECE中，版本是通过stack的方式管理
Ref : https://www.elastic.co/guide/e ... .html
这些版本都是以docker images的形式存储
因此，ECE根据不同的版本,然后选择对应的docker image就可以创建一个节点了. 那么升级的过程就可以简单分成几个步骤
1.exclude准备升级的节点。
2.停止节点ES进程，更换container 版本。
3.重新启动节点，加入集群。
4.在其他节点上重复以上流程。
在这个过程中, 实际使用的时候发现有一些需要注意的雷区.
扫雷一：使用UI触发升级，必须保证集群没有自定义插件和bundles
ECE 里面的集群操作是通过plan来控制的
任何的集群操作最终都会生成一个plan的diff。如上图，把集群从5.4.1 升级到 5.6.12 会产生以上diff.
正常情况下是没有问题的.
如果集群配置了自定义bundles, 比如LDAP bundles, ref:https://www.elastic.co/guide/e ... .html
那么在集群的plan里面就会存在这么一段配置
那么当我们在按下升级按钮的时候
ECE 只在plan中修改了集群大版本的配置, 但是并没有修改自定义bundles中的版本号(仍然是5.4.1).
在这种情况下去执行升级,会直接产生报错.
界面上没有显示原因, 但是这是因为plan里面大版本和bundle中的版本不一致,然后会导致新增的节点无法启动. 于是ECE 就认为集群升级失败了.
解决方法是手动编辑plan,把自定义bundles中的版本号改成和集群版本一致
然后使用ECE 提供的一种手动使用plan进行集群升级的方式进行升级.
扫雷二：节点无法关闭
ECE 控制container 是通过一个叫做 constructor的服务。constructor 通过接收集群的更改需求，制定具体的更改计划与步骤，指导allocator对container进行操作。同时也负责保证集群高可靠性，通过Availability Zone的数量在不同的AZ上面部署节点。
当Allocator接受到关闭container命令的时候，会尝试去关闭container，如果container处于一个阻塞状态无法响应, 那么关闭命令无法执行成功。这个时候constructor会等待节点关闭，但是allocator又认为节点已经接受到关闭命令了。又或者constructor发送给allocator的过程中网络丢包, 这个时候allocator 没有正确接受关闭container的命令. 整个升级进程就卡住了。 这种情况十分罕见,通常发现一个container如果处于”正在关闭”时间太久了, 那么通常就是中间的通信出现问题了.
解决办法是可以通过手动停止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里面可以看到
在默认情况下, 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的策略来进行集群操作.
社区日报 第483期 (2018-12-19)
社区日报 • elk123 发表了文章 • 0 个评论 • 1699 次浏览 • 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 版本升级扫雷实战
Elasticsearch • Ben_Wu 发表了文章 • 1 个评论 • 3035 次浏览 • 2018-12-21 10:50
Elastic Cloud Enterprise 出来也有一年多的时间了。对于这类的开源软件企业版本，基本都是在可管理性和稳定性上面下功夫。但是新产品免不了需要经历一下bug的打磨才会变得成熟。
下面分享的这个案例是当我们在把集群从5.4.1 升级到5.6.12 的过程中，遇到节点关闭受阻，升级不完整等情景。以及对应的处理方法。
首先在ECE中，版本是通过stack的方式管理
Ref : https://www.elastic.co/guide/e ... .html
这些版本都是以docker images的形式存储
因此，ECE根据不同的版本,然后选择对应的docker image就可以创建一个节点了. 那么升级的过程就可以简单分成几个步骤
1.exclude准备升级的节点。
2.停止节点ES进程，更换container 版本。
3.重新启动节点，加入集群。
4.在其他节点上重复以上流程。
在这个过程中, 实际使用的时候发现有一些需要注意的雷区.
扫雷一：使用UI触发升级，必须保证集群没有自定义插件和bundles
ECE 里面的集群操作是通过plan来控制的
任何的集群操作最终都会生成一个plan的diff。如上图，把集群从5.4.1 升级到 5.6.12 会产生以上diff.
正常情况下是没有问题的.
如果集群配置了自定义bundles, 比如LDAP bundles, ref:https://www.elastic.co/guide/e ... .html
那么在集群的plan里面就会存在这么一段配置
那么当我们在按下升级按钮的时候
ECE 只在plan中修改了集群大版本的配置, 但是并没有修改自定义bundles中的版本号(仍然是5.4.1).
在这种情况下去执行升级,会直接产生报错.
界面上没有显示原因, 但是这是因为plan里面大版本和bundle中的版本不一致,然后会导致新增的节点无法启动. 于是ECE 就认为集群升级失败了.
解决方法是手动编辑plan,把自定义bundles中的版本号改成和集群版本一致
然后使用ECE 提供的一种手动使用plan进行集群升级的方式进行升级.
扫雷二：节点无法关闭
ECE 控制container 是通过一个叫做 constructor的服务。constructor 通过接收集群的更改需求，制定具体的更改计划与步骤，指导allocator对container进行操作。同时也负责保证集群高可靠性，通过Availability Zone的数量在不同的AZ上面部署节点。
当Allocator接受到关闭container命令的时候，会尝试去关闭container，如果container处于一个阻塞状态无法响应, 那么关闭命令无法执行成功。这个时候constructor会等待节点关闭，但是allocator又认为节点已经接受到关闭命令了。又或者constructor发送给allocator的过程中网络丢包, 这个时候allocator 没有正确接受关闭container的命令. 整个升级进程就卡住了。 这种情况十分罕见,通常发现一个container如果处于”正在关闭”时间太久了, 那么通常就是中间的通信出现问题了.
解决办法是可以通过手动停止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里面可以看到
在默认情况下, 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的策略来进行集群操作.
社区日报 第483期 (2018-12-19)
社区日报 • elk123 发表了文章 • 0 个评论 • 1699 次浏览 • 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
