Home 新闻中心 行业动态

华为云原生底座+AI对遥感影像各类地物元素进行自动化的检测

发布时间:2021-11-15 22:14:00   浏览量:34   作者:GIS前沿

在Docker容器技术即将统治世界的趋势下,作为地理遥感领域的AI处理解译平台,华为云GeoGenius空天地平台,早已开始全面的云原生方向转型。本文总结大规模遥感影像处理在云原生平台的落地经验,期间各种性能并发等场景优化经验有不少借鉴意义,与各遥感同行分享。

本文作者:唐盛军,华为云城市智能体架构师,拥有多年开发经验,先后从事:网络协议识别&解析、业务控制网关等网络协议相关工作;13年开始转战云计算,熟悉OpenStack,CloudFoundry,Docker,Kubernetes实现原理,精通常见的物理&云网络技术。目前负责容器业务产品化,如:遥感,基因,大数据,AI等

AI牛啊,云原生牛啊,所以1+1>2?

遥感影像,作为地球自拍照,能够从更广阔的视角,为人们提供更多维度的辅助信息,来帮助人类感知自然资源、农林水利、交通灾害等多领域信息。

AI技术,可以在很多领域超过人类,关键是它是自动的,省时又省力。可显著提升遥感影像解译的工作效率,对各类地物元素进行自动化的检测,例如建筑物,河道,道路,农作物等。能为智慧城市发展&治理提供决策依据。
云原生技术,近年来可谓是一片火热。易构建,可重复,无依赖等优势,无论从哪个角度看都与AI算法天生一对。所以大家也可以看到,各领域的AI场景,大都是将AI推理算法运行在Docker容器里面的。AI+云原生这么6,那么强强联手后,地物分类、目标提取、变化检测等高性能AI解译不就手到擒来?我们也是这么认为的,所以基于AI+Kubernetes云原生,构建了支持遥感影像AI处理的空天地平台。详见:https://www.huaweicloud.com/product/geogenius.html

不过理想是好的,过程却跟西天取经一般,九九八十一难,最终修成正果。

业务场景介绍

遇到问题的业务场景叫影像融合(Pansharpen),也就是对地球自拍照进行“多镜头合作美颜”功能。(可以理解成:手机的多个摄像头,同时拍照,合并成一张高清彩色大图)。
所以业务简单总结就是:读取2张图片,生成1张新的图片。该功能我们放在一个容器里面执行,每张融合后的结果图片大约5GB。

问题的关键是,一个批次业务量需要处理的是3000多张卫星影像,所以每批任务只需要同时运行完成3000多个容器就OK啦。云原生YYDS!

业务架构图示

为了帮助理解,这里分解使用云原生架构实现该业务场景的逻辑图如下:
图片
在云上,原始数据,以及结果数据,一定是要存放在对象存储桶里面的。因为这个数据量,只有对象存储的价格是合适的。(对象存储,1毛钱/GB。文件存储则需要3毛钱/GB)

因为容器之间是互相独立无影响的,每个容器只需要处理自己的那幅影像就行。例如1号容器处理 1.tif影像;2号容器处理2.tif影像;依次类推。

所以管理程序,只需要投递对应数量的容器(3000+),并监控每个容器是否成功执行完毕就行(此处为简化说明,实际业务场景是一个pipeline处理流程)。那么,需求已经按照云原生理想的状态分解,咱们开始起(tang)飞(keng)吧~

注:以下描述的问题,是经过梳理后呈现的,实际问题出现时是互相穿插错综复杂的。

K8s死掉了

当作业投递后,不多久系统就显示作业纷纷失败。查看日志报调用K8s接口失败,再一看,K8s的Master都已经挂了。。。

K8s-Master处理过程,总结版:

  1. 发现Master挂是因为CPU爆了

  2. 所以扩容Master节点(此处重复N次);

  3. 性能优化:扩容集群节点数量;

  4. 性能优化:容器分批投放;

  5. 性能优化:查询容器执行进度,少用ListPod接口;

详细版:

看监控Master节点的CPU已经爆掉了,所以最简单粗暴的想法就是给Master扩容呀,嘎嘎的扩。于是从4U8G * 3 一路扩容一路测试一路失败,扩到了32U64G * 3。可以发现CPU还是爆满。看来简单的扩容是行不通了。
3000多个容器,投给K8s后,大量的容器都处于Pending状态(集群整体资源不够,所以容器都在排队呢)。而正在Pending的Pod,K8s的Scheduler会不停的轮训,去判断能否有资源可以给它安排上。所以这也会给Scheduler巨大的CPU压力。扩容集群节点数量,可以减少排队的Pod数量。
另外,既然排队的太多,不如就把容器分批投递给K8s吧。于是开始分批次投递任务,想着别一次把K8s压垮了。每次投递数量,减少到1千,然后到500,再到100。

同时,查询Pod进度的时候,避免使用ListPod接口,改为直接查询具体的Pod信息。因为List接口,在K8s内部的处理会列出所有Pod信息,处理压力也很大。

这一套组合拳下来,Master节点终于不挂了。不过,一头问题按下去了,另一头问题就冒出来了。

容器跑一半,挂了

虽然Master不挂了,但是当投递1~2批次作业后,容器又纷纷失败。

容器挂掉的处理过程,总结版:

  1. 发现容器挂掉是被eviction驱逐了;

  2. Eviction驱逐,发现原因是节点报Disk Pressure(存储容量满了);

  3. 于是扩容节点存储容量;

  4. 延长驱逐容器(主动kill容器)前的容忍时间;

详细版:

(注:以下问题是定位梳理后,按顺序呈现给大家。但其实出问题的时候,顺序没有这么友好)

容器执行失败,首先想到的是先看看容器里面脚本执行的日志呗:结果报日志找不到~

于是查询Pod信息,从event事件中发现有些容器是被Eviction驱逐干掉了。同时也可以看到,驱逐的原因是 DiskPressure(即节点的存储满了)。
当Disk Pressure发生后,节点被打上了驱逐标签,随后启动主动驱逐容器的逻辑:


由于节点进入Eviction驱逐状态,节点上面的容器,如果在5分钟后,还没有运行完,就被Kubelet主动杀死了。(因为K8s想通过干掉容器来腾出更多资源,从而尽快退出Eviction状态)。
这里我们假设每个容器的正常运行时间为1~2个小时,那么不应该一发生驱动就马上杀死容器(因为已经执行到一半的容器,杀掉重新执行是有成本浪费的)。我们期望应该尽量等待所有容器都运行结束才动手。所以这个 pod-eviction-timeout 容忍时间,应该设置为24小时(大于每个容器的平均执行时间)。

Disk Pressure的直接原因就是本地盘容量不够了。所以得进行节点存储扩容,有2个选择:1)使用云存储EVS(给节点挂载云存储)。2)扩容本地盘(节点自带本地存储的VM)。

由于云存储(EVS)的带宽实在太低了,350MB/s。一个节点咱们能同时跑30多个容器,带宽完全满足不了。最终选择使用 i3类型的VM。这种VM自带本地存储。并且将8块NVMe盘,组成Raid0,带宽还能x8。

对象存储写入失败

容器执行继续纷纷失败。

容器往对象存储写入失败处理过程,总结版:

  1. 不直接写入,而是先写到本地,然后cp过去。

  2. 将普通对象桶,改为支持文件语义的并行文件桶。

详细版:

查看日志发现,脚本在生成新的影像时,往存储中写入时出错:
我们整集群是500核的规模,同时运行的容器数量大概在250个(每个2u2g)。这么多的容器同时往1个对象存储桶里面并发追加写入。这个应该是导致该IO问题的原因。

对象存储协议s3fs,本身并不适合大文件的追加写入。因为它对文件的操作都是整体的,即使你往一个文件追加写入1字节,也会导致整个文件重新写一遍。

最终这里改为:先往本地生成目标影像文件,然后脚本的最后,再拷贝到对象存储上。相当于增加一个临时存储中转一下。
在临时中转存储选择中,2种本地存储都试过:1)块存储带宽太低,350MB/s影响整体作业速度。2)可以选择带本地存储的VM,多块本地存储组成Raid阵列,带宽速度都杠杠滴。

同时,华为云在对象存储协议上也有一个扩展,使其支持追加写入这种的POSIX语义,称为并行文件桶。后续将普通的对象桶,都改为了文件语义桶。以此来支撑大规模的并发追加写入文件的操作。

K8s计算节点挂了

So,继续跑任务。但是这容器作业,执行又纷纷失败鸟~

计算节点挂掉,定位梳理后,总结版:

  1. 计算节点挂掉,是因为好久没上报K8s心跳了。

  2. 没上报心跳,是因为kubelet(K8s节点的agent)过得不太好(死掉了)。

  3. 是因为Kubelet的资源被容器抢光了(由于不想容器经常oom kill,并未设置limit限制)

  4. 为了保护kubelet,所有容器全都设置好limit。

详细版,直接从各类奇葩乱象等问题入手:

1) 容器启动失败,报超时错误。
2) 然后,什么PVC共享存储挂载失败:
3) 或者,又有些容器无法正常结束(删不掉)。

4) 查询节点Kubelet日志,可以看到充满了各种超时错误:
图片

啊,这么多的底层容器超时,一开始感觉的Docker的Daemon进程挂了,通过重启Docker服务来试图修复问题。

后面继续定位发现,K8s集群显示,好多计算节点Unavailable了(节点都死掉啦)。


图片

继续分析节点不可用(Unavailable),可以发现是Kubelet好久没有给Master上报心跳了,所以Master认为节点挂了。说明不仅仅是Docker的Daemon受影响,节点的Kubelet也有受影响。

那什么情况会导致Kubelet,Docker这些主机进程都不正常呢?这个就要提到Kubernetes在调度容器时,所设计的Request和Limit这2个概念了。

Request是K8s用来调度容器到空闲计算节点上的。而Limit则会传递给Docker用于限制容器资源上限(触发上限容易被oom killer 杀掉)。前期我们为了防止作业被杀死,仅为容器设置了Request,没有设置Limit。也就是每个容器实际可以超出请求的资源量,去抢占额外的主机资源。大量容器并发时,主机资源会受影响。

考虑到虽然不杀死作业,对用户挺友好,但是平台自己受不了也不是个事。于是给所有的容器都加上了Limit限制,防止容器超限使用资源,强制用户进程运行在容器Limit资源之内,超过就Kill它。以此来确保主机进程(如Docker,Kubelet等),一定是有足够的运行资源的。

K8s计算节点,又挂了

于是,继续跑任务。不少作业执行又双叒失败鸟~

节点又挂了,总结版:

  1. 分析日志,这次挂是因为PLEG(Pod Lifecycle Event Generator)失败。

  2. PLEG异常是因为节点上面存留的历史容器太多(>500个),查询用时太久超时了。

  3. 及时清理已经运行结束的容器(即使跑完的容器,还是会占用节点存储资源)。

  4. 容器接口各种超时(cpu+memory是有limit保护,但是io还是会被抢占)。

  5. 提升系统磁盘的io性能,防止Docker容器接口(如list等)超时。

详细版:

现象还是节点Unavailable了,查看Kubelet日志搜索心跳情况,发现有PLEG is not healthy 的错误:
于是搜索PLEG相关的Kubelet日志,发现该错误还挺多:
图片

这个错误,是因为kubelet去list当前节点所有容器(包括已经运行结束的容器)时,超时了。

看了代码:

https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/pleg/generic.go#L203

kubelet判断超时的时间,3分钟的长度是写死的。所以当pod数量越多,这个超时概率越大。很多场景案例表明,节点上的累计容器数量到达500以上,容易出现PLEG问题。(此处也说明K8s可以更加Flexible一点,超时时长应该动态调整)。

缓解措施就是及时的清理已经运行完毕的容器。但是运行结束的容器一旦清理,容器记录以及容器日志也会被清理,所以需要有相应的功能来弥补这些问题(比如日志采集系统等)。

List所有容器接口,除了容器数量多,IO慢的话,也会导致超时。

这时,从后台可以看到,在投递作业期间,大量并发容器同时运行时,云硬盘的写入带宽被大量占用:
对存储池的冲击也很大:
这也导致了IO性能变很差,也会一定程度影响list容器接口超时,从而导致PLEG错误。

该问题的解决措施:尽量使用的带本地高速盘的VM,并且将多块数据盘组成Raid阵列,提高读写带宽。


这样,该VM作为K8s的节点,节点上的容器都直接读写本地盘,io性能较好。(跟大数据集群的节点用法一样了,强依赖本地shuffle~)。

在这多条措施实施后,后续多批次的作业都可以平稳的运行完。

总结:“AI+云原生”这条路

云原生是趋势,已经成为大家的共识,各领域也都开始以云原生为底座的业务尝试。AI是未来,这也是当前不可阻挡的力量。但是当AI踏上这条云原生的道路却不那么一帆风顺。至少可以看到,华为云的云原生底座(当然,也包括存储、网络等周边基础设施)还可以有更多的进步空间。

但是,大家也不用担心太多,因为当前华为云的空天地平台,在经历了多年的AI+云原生的积累,目前可以很稳定的处理PB级每日的遥感影像数据,支撑各类空基、天基、地基等场景,并且在该领域保持绝对领先的战斗值。虽然大家看到此间过程有点曲折,但是所有的困难都是涅槃的火种,克服过的困难都是今后可以对客户做的承诺。在这里可以很明确的告诉各位:AI+云原生=真香。

写这篇文章的目的,不是在阐述困难,而是为了总结分享。与同领域的人分享并促进遥感领域的快速发展,共同推动AI+云原生的落地。

来源:https://blog.csdn.net/qq_43173805/article/details/121064717

成都途远GIS是一家专业致力于无人机航空摄影测绘、航空数据处理、GIS地理信息系统研发、数字孪生城市制作、数字沙盘模型等业务的创新型科技公司,为您提供一站式地理信息服务。