国产成人av网站网址-国产成人av无码精品-国产成人av无码精品天堂-国产成人av无码片在线观看-国产成人av无码一区二区三区不卡-国产成人av无码永久免费

首頁 新聞中心 行業動態

華為云原生底座+AI對遙感影像各類地物元素進行自動化的檢測

發布時間:2021-11-15 22:14:00   瀏覽量:4541   作者: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地理信息系統研發、數字孿生城市制作、數字沙盤模型等業務的創新型科技公司,為您提供一站式地理信息服務。

中国人妻被两个老外三P| 人妻无码一区二区三区久| 三个男人换着躁我一| 亚洲精品TV久久久久久久久久 | 欧美成人片在线观看网站| 同性男男黄网站在线观看国外| 伊人久久大香线蕉精品| 夫妻互换呻吟抽插小说| 国产精品久久久天天影视香蕉| 久章草在线毛片视频播放| 色综合久久久久综合体桃花网| 亚洲线精品一区二区三区影音先锋| 成人综合婷婷国产精品久久| 久久久国产精品ⅤA麻豆LL| 色偷偷亚洲女人的天堂| 1313午夜精品理论片| 国产美女自卫慰黄网站| 欧美性操大鸡狠狠| 亚洲精品欧美二区三区中文字幕| 成人综合激情另类小说| 欧美丰满美乳XXⅩ高潮| 性色AV蜜臀AV色欲AV| JAPAN丰满人妻HDXXXX| 精品久久久无码人妻中文字幕豆芽| 日本真人裸交试看120秒| 亚洲中文久久久久久精品| 国产成人精品一区二区秒播| 能在线观看的一区二区三区| 亚洲AV综合A∨一区二区| 厨房掀起裙子从后面进去视频| 久久无码喷吹高潮播放不卡| 无遮挡H肉动漫在线播放| 9精产国品一二三产区| 久久99精品国产自在现线小黄鸭| 丝袜灬啊灬快灬高潮了视频| AV无码精品久久久久精品免费| 精品系列无码一区二区三区| 无码福利日韩神码福利片| AV电影在线观看| 军人暴力性强迫RAPE| 亚洲综合一区二区三区四区五区| 国产精品多人P群无码| 强被迫伦姧惨叫VIDEO| 野花社区WWW在线视频官网| 精品国精品国产自在久国产应用| 天堂久久天堂AV色综合| とらぶるだいありぴーち在线| 久久婷婷五月综合色精品| 亚洲中文在线精品国产| 精品无码国产一区二区三区AV | 985大学排名一览表| 国产一区内射最近更新| 色噜噜狠狠色综合久色AⅤ网黑| 18禁超污无遮挡无码免费动态图| 老汉扛起娇妻玉腿进入| 樱桃CHERRY官网| 久爱无码精品免费视频在线观看| 亚洲 自拍 另类小说综合图区| 国产精品亚洲A∨天堂不卡| 日韩乱码人妻无码系列中文字幕| 8090私人影院| 精品无码久久久久久国产| 亚洲精品欧美综合四区| 很嫩很紧直喷白浆在线| 无码人妻一区二区三区一| 从今天开始当城主| 色悠久久久久综合先锋影音下载 | 小婷又紧又嫩又窄又多水| 成人精品一区二区www| 欧美黑人男士和白人美女a级黄片视频在线播放 | 日韩欧美视频一区二区| YY4480高清影院播放器| 免费无码一区二区三区蜜桃大| 亚洲色无码专区一区| 韩漫嘿啾漫画进入| 无码专区永久免费AV网站| 丰满少妇被猛烈进AV毛片| 秋霞免费理论片在线观看| 999ZYZ玖玖资源站在线观看| 欧美裸体XXXX极品少妇| 365天天色综合网| 久久亚洲精品AB无码播放| 亚洲熟妇无码乱子AV电影| 久久综合亚洲鲁鲁九月天| 中文字幕AV无码一区二区蜜芽三| 久久久久久精品免费免费4K| 亚洲欧美国产国产一区二区| 狠狠色伊人亚洲综合网站野外 | 久久久午夜成人噜噜噜| 亚洲AV影院一区二区三区| 国产农村妇女毛片精品久久麻豆| 偷拍东北熟女BBWW| 国模GOGO中国人体私拍| 性无码一区二区三区在线观看 | 久久久久人妻一区二区三区VR | 人妻少妇精品久久| 99国产欧美另娄久久久精品| 前夫6天要了我25次| 丰满少妇人妻HD高清大乳在线| 无码专区人妻系列日韩精品少妇| 娇喘连连抽搐高潮小说| 亚洲精品成人无码| 麻豆传播媒体APP大全免费版 | 人妻少妇乱子伦无码视频专区| 成人区人妻精品一区二区三区| 无码纯肉视频在线观看| 极品少妇高潮XXXXX| 在公交上被灌满白浆的视频| 美女粉嫩饱满的一线天MP4| 中国女人FREE性HD| 人人妻人人爽人人澡欧美二区| 国产成人片一区在线观看| 无遮挡无码H纯肉动漫在线观看| 精品无码黑人又粗又大又长AV| 最新永久无码AV网址亚洲| 欧美成年黄网站色视频| 丰满人妻被粗大爽ⅩXOO| 亚洲AV网站在线| 含羞草四叶草三叶草| 亚洲女同成AV人片在线观看| 免费无码AV污污污在线观看| 成人做爰高潮A片免费视频| 无遮挡边吃摸边吃奶边做| 久久精品亚洲综合专区| WW久久综合久中文字幕| 国产一区二区三区影院| 人妻少妇久久精品电影| 国产精品国产免费无码专区蜜桃| 亚洲欧美另类久久久精品| 好硬好涨老师受不了了 | 麻花豆传媒MV在线播放| 暴躁少女CSGO图片| 色爱无码AV综合区老司机非洲| 国内精品久久影院综合日日| 中文人妻熟妇乱又伦精品| 色欲AV永久无码精品无码| 精品人妻AV区乱码| MM1313午夜视频在线观看| 日日狠狠久久偷偷色综合免费 | 日本无码视频精品一二三区| 日本公与丰满熄的| 大香伊蕉AⅤ在人线国产| 天天天欲色欲色WWW免费| 久久AV无码AⅤ高潮AV喷吹| YEEZY380蜜桃粉满天| 羞羞漫画_成人漫画_成人专用| 蜜臀98精品国产免费观看| MD豆传媒一二三区进站口在线看| 无人区码一码二码三码四码| 麻花传媒0076在线观看| 国产AV无码专区亚洲AV麻豆丫| 性欧美大战久久久久久久| 91人妻人人澡人爽人精品 | AVAST中文官方网站| 天堂资源中文WWW| 久久99精品久久久大学生 | 欧洲熟妇色XXXX欧美老妇多毛| 国产精选午睡沙发系列999| 中文中文字幕成人无码AⅤ| 铜铜铜铜铜铜铜铜好大免费| 浪潮AV激情高潮国产精品| 国产成人综合欧美精品久久| 亚洲成AV人片在线观看无码 | 韩国电影理伦片完整| 99久久国产露脸国语对白| 亚洲A∨国产AV综合AV麻豆丫 | 国产午夜精品无码理论片| 亚洲婷婷综合色高清在线| 色妺妺AⅤ爽爽影院偷拍| 久久久久久久精品无码AV少妇 | FREEHDXXXX学生妹| 亚洲AV无码专区在线观看成人| 奇米影视7777久久精品| 精品久久久久国产免费| 成年女人A级毛片免费观看| 亚洲AV高清一区二区三区| 清纯JK校花被啪啪AV免费| 精品人妻AV区乱码| 丰满少妇AV无码区| 中文区中文字幕免费看| 亚洲AV成人无码网天堂| 人人妻人人爽人人澡人人少妇 | AV片在线观看免费| 亚洲AV无码乱码一级毛片孕妇 | 亚洲AV无码乱码在线观看| 漂亮人妻洗澡被公强 日日躁| 精品久久久久久亚洲精品| 赤裸羔羊Ⅲ致命快感 电影| 中国老太毛茸茸XXXXHD| 亚洲AV成人片无码网站网一区 | 呦女IUU极品资源| 人妻人人做人妻人人添| 久久久久久一区国产精品| 国产精品久久久久久妇女| JAPANESEHD熟女熟妇| 亚洲熟妇另类久久久久久| 无套内射GIF舔B吃奶| 日韩AV影院在线观看| 精品一区二区三区在线成人 | 新妺妺窝人体色WWW|