《專家觀察 | 潘文杰：“OpenStack在恒豐銀行的生產實踐”》要點：
本文介紹了專家觀察 | 潘文杰：“OpenStack在恒豐銀行的生產實踐”，希望對您有用。如果有疑問，可以聯系我們。

由工業和信息化部指導,中國信息通信研究院主辦,業界知名組織云計算開源產業聯盟(OSCAR)承辦的2017全球云計算開源大會于4月19日-20日在北京國家會議中心順利召開.本文為本屆大會嘉賓分享的大會演講速記內容,敬請瀏覽.

嘉賓介紹:潘文杰

公司職務：恒豐銀行平臺與自動化部門負責人潘文杰

大會演講速記

潘文杰：我給大家帶來的是OpenStack在恒豐銀行的生產實踐.

今天會議的主題是我們的全球云計算開源大會,大家介紹的也都是一些開源產品,作為云計算領域最大的開源項目,OpenStack實際上最近一段時間比較火,我們給大家介紹的就不去講一些很新很炫的東西了,因為在大會上OpenStack基金會的成員給大家介紹了OpenStack.

今天我給大家主要介紹一下我們作為一個金融的行業,金融的甲方,我們從甲方的角度來看一下OpenStack如何在生產上進行部署以及我們一些運維的實踐.

演講主要六個部分,第一個部分是我們看一下恒豐銀行現在部署的情況,為什么選擇OpenStack,我們如何部署管理運維它,最后是一些我們后續的發展.

現狀,恒豐銀行現在的OpenStack部署情況是這樣,右側是我們的規模,現在五百個以上的結算節點,因為是超融合的,所以存儲節點超過五百個了,我們現在運行著一萬個以上的虛擬機.

我們幾乎所有的業務都跑在OpenStack上虛擬化,當然數據庫和大數據結點除外,因為金融行業對于穩定性的要求比較高,大數據都是用裸機的,所以不需要使用.我們也是標準的兩地三中心的架構,三個數據中心我們都部署了OpenStack集群,多個網絡區包括我們的隔離網和業務網都運行著OpenStack集群,生產個測試環境,包括我們的生產環境上的網商銀行,電話銀行,核心的信貸等等的業務系統,現在前端除了數據庫都是部署在OpenStack集群上,已經運行超過一年了,這是我們在恒豐銀行在OpenStack上的使用情況.

我們強調一下我們使用了多租戶隔離的,在我們恒豐銀行內部為什么也要做呢?實際上我們內部也分為一個集團下的多個子公司,那么這些集團和集團之間我們都是使用多租戶的方式來進行資源的隔離的.

現狀,恒豐銀行現在的OpenStack部署情況是這樣,右側是我們的規模,現在五百個以上的結算節點,因為是超融合的,所以存儲節點超過五百個了,我們現在運行著一萬個以上的虛擬機.

我們幾乎所有的業務都跑在OpenStack上虛擬化,當然數據庫和大數據結點除外,因為金融行業對于穩定性的要求比較高,大數據都是用裸機的,所以不需要使用.我們也是標準的兩地三中心的架構,三個數據中心我們都部署了OpenStack集群,多個網絡區包括我們的隔離網和業務網都運行著OpenStack集群,生產個測試環境,包括我們的生產環境上的網商銀行,電話銀行,核心的信貸等等的業務系統,現在前端除了數據庫都是部署在OpenStack集群上,已經運行超過一年了,這是我們在恒豐銀行在OpenStack上的使用情況.

我們強調一下我們使用了多租戶隔離的,在我們恒豐銀行內部為什么也要做呢?實際上我們內部也分為一個集團下的多個子公司,那么這些集團和集團之間我們都是使用多租戶的方式來進行資源的隔離的.

我們說一下我們為什么選擇OpenStack,半年前可能還有很多的顧慮,我覺得現在應該沒有什么太多顧慮了.

第一個主要是自主可控,因為畢竟OpenStack是一個開源的產品,哪怕你去找一些廠商,實際上背后還是那套開源的東西.

第二個就是它還是油價格優勢的,因為畢竟是開源的產品,所以廠商賣給你的時候就是服務.

第三個也是最重要的,是完全開放的狀態,集合社區的力量,這也是比較舊的數據,整個社區超過六萬的開發者,代碼行數超過兩萬行.

這是兩個版本以前的數據,那么到現在只會更多,那么在這么大規模,剛才也說了這個是第二大的,那么它的產品其實也已經相當成熟了,有些人擔心我們的金融行業往往都求穩,為什么我們敢用?

你看OpenStack社區里面主的項目,包括這六個是它的核心的項目,nova、neutron、swift等五年前就已經推出了,持續不斷的改進都是增加新的功能,對大家最常使用的問題和bug我們認為它已經修改了很完善了,你如果不去碰它比較新的功能,有很多新的功能包括容器都在支持,在你不需要用的時候,而且變化大的是在網絡的部分開發量非常大,實際上你不需要使用這些東西的情況你用到的往往是它非常穩定和成熟的代碼,我們認為Open Stack已經是一個生產或者金融行業可用的系統了,當然你除了這個以外開源部分你也沒有選擇.

還要說一下的是整個OpenStack的架構的優勢,這一點就是我不得不佩服OpenStack一開始創始人或者一開始的核心代碼貢獻者,整個OpenStack的架構是非常非常的標準式異構的結構,使我們增加任何我們想要的功能都非常的容易和可擴展,我們幾乎不會動到它所有核心的地方,它給你留下了足夠多的可以擴展的地方,不管是什么東西都是可以扒插對接的,哪怕我們對它后期進行調整也是非常容易的融合進來整個社區的,或者我從社區就可以很容易的拿到相應的,這點相較于廠商我認為優勢非常大.

大家會提一個需求給廠商,廠商回去開發半年都不一定做出來,你可能提的想法和點子別人都提到過,這是一個我認為社區里架構也有優勢,社區人也多,這是一個非常大的趨勢.

廠商就不說了,這都已經洗牌過一次了,中國的廠商也不斷的加入,華為也是白金的會員,這么多廠商的參與下你可以看到它的解決方案也是非常成熟的.比如你想找一個跟EMC我們商業存儲的,或者跟思科對接的方案這里面幾乎都有現成的解決方案,現在很多東西都是非常成熟了,你幾乎都能找得到,所以他已經有這么多的廠商支持他,這么多的能力擴展,你對接不上的廠商給他提需求.比如國內廠商他們現在也基本上全部都認為要對

接到OpenStack上,如果你不是用他標準的OpenStack方案反而它就不支持了,我們找廠商談的時候他說我現在就支持OpenStack的,你自己搞一套還不好對接.

我們講一下我們如何部署的,剛才說了金融行業往往要求的是可靠性,可用性,連續性等等,都有很高的要求,社區上最開始給的標準的部署方案單節點的,可以變成多節點的部署,這里面還是有很多功夫要下的.

首先我們把它分為控制節點和計算節點兩種,因為我是超融合的,所以我的計算節點里放的是多個角色.比如我的API的角色,MQ的角色等等,VTS控制器以及我HAProxy,這些我都做成虛機跑到三個物理機上.

這個圖我講控制節點如何分布,因為我們剛才說了都要盡量的做到三活的結構,因為三臺選組的時候容易腦裂,所以我要盡量的讓三臺控制器分布在三個故障域里,不要再一個里面,這樣故障率會導致它一次就壞兩個的可能.

所以我們建議是說你至少要做大于二的基數,這是因為它要選組,你要盡量的把它分散在不同的故障率里,我們的做法是把控制器分布在我們的AB兩個機房模塊挨著的防火隔離,我們把另外一個放到樓下的網絡機房.

這樣至少能保證兩個以上的或者快速的協商出來一個新的,我們在上面還有一些公共的節點,比如說我們的很多節點是統一布放的,不需要放在三個節點上的.

我們看一下控制節點高可用的方案,首先剛才說了都是要能做到多活的都做到多活,能做到準備的要盡量的準備,多活都是三節點部署,我們在最外面是做一層負載均衡,所有中間的API的節點實際上都是三活的,數據庫這一層我們用了三活的集群,我們來說一下為什么.

我們要把這個做成三活,實際上已經支持三個數據庫的節點全部三活,我們怎么做?我們讓它做成三個節點復制的集群,但是我只選中一組將所有的數據庫請求留給這一個組,因為我們認為實際上你不需要用三個,它之間的溝通還會有大的麻煩,如果我不用這個方案的話如果我夜里出現故障還得爬吸收修,或者要做主備切換,這個時候我只需要檢查三個的狀態,如果主的壞了切換到一個備機就可以.

對于數據庫來說已經自動的完成切換了,我們說為了可用連續性,我的數據庫還在同城機房擺了一臺備機,三活加一倍,實際使用的時候數據庫是一組在用,另外兩個活的不跑業務,也不做查詢,這是我們OpenStack控制節點高可用的方案.我們多套的OpenStack集群都是這樣的.

這是講我們如何部署了整個OpenStack,我們講一下我們怎么管它,這些都是一些比較基本的辦法,很簡單.

第一個我們說銀行擔心的是出現整體性的故障和風險,我們會搞很多的隔離區,業務區等等這些東西,我用OpenStack也一樣,如果我們整個都跑在一個集群上集群壞了怎么辦?如果我的存儲集群壞了怎么辦?

我上面的虛機會觸發整體性的風險,之前也不是沒有遇到過,之前擴容的時候整個集群宕一下,上面跑了這么多集群誰能受得了?所以我們使用一個數據中心多套OpenStack方案做的,一個數據中心多套OpenStack,但是它的帳戶體系是一套,我就裝了一套,大家都對上了,然后我的一個OpenStack里面是有兩個ceph集群的,如果網銀要十臺機器,我會根據調度算法把它切分在兩個ceph集群,這樣任何一個ceph的故障不會導致我整個宕機.

有人說這就是矛盾,你要做資源池,實際上我們的意思是故障率要小,但是資源還是會很大,就是說我們在一個集群下也要跑所有的業務,整個的容量也是很大的.

這是剛才我們說到的故障率要盡可能的小,我們資源怎么調度?

剛才也說了,我們都是為業務服務的,我們上面跑著很多的業務,這些業務我們邀請的其實是銀行還是保險都是一樣的,要求的是業務的高可用,不是需要我云平臺的高可用,最終的價值是要完成業務的高可用,這些業務的高可用只能說我要盡可能的把雞蛋不放在一個籃子里,所以我們就搞出了好多的非輕核性的調度,有一些就是輕的,為了更方便.

我們用的更多是非輕核性的,把同樣的一組應用盡可能的分散在不同的物理機上,不同的可用域上,最上層從應用要兩地雙活部署.這個時候由OpenStack再上一層的管理平臺,我們叫云管理平臺來調度,也就保證它同一個應用同一個節點.

比如網銀的外部節點要分散在不同的OpenStack集群里,我上面掛DNS就可以,到達一個OpenStack以后我們就使用機房和機柜的非親和性,我要讓它的節點盡可能的分散在不同的模塊里.

因為我們剛才看到了,我們的架構剛才是雙模塊的部署,所以兩個模塊都是防火隔離完全對等復制的,這樣換一個機房模塊原則講也不會對我們的使業務產生影響,我們就使用HostAgreation來做,還不能跑同一個宿主機上.

說極端一點的情況,我還盡量的要求它不能落在同一個機柜里,因為一個柜子都會壞,所以我們要盡可能的把資源分散的調度到不同的節點上,有很多的辦法,包括存儲也要分散開,計算也要分散開,甚至要在同城分開等等,這是講我們在用OpenStack的時候應該怎么樣.

后面我們講最復雜怎么運維,可能大家都很困擾,就是云化下面其實我們的運維可能有些時候會變.

第一個就是OpenStack整個集群它的可靠性和可用性就要求很高了,因為如果我的ceph可用率只有99.9%,那很難再超過99%了,因為我是基礎設施,那我對整個ceph都有很多的要求,前面搞得那么變態,弄那么多節點,還要用這個那個的,還要擺在不同的網絡機房模塊里,因為我要防止一個機房模塊斷裂,也不是沒有發生過,有前車之鑒所以我們要小心.

然后就是監控,服務器的故障X86的服務器,故障也是經常的,網絡會抖動,各種各樣的情況都會發生我們都要監控,

現在的監控手段主要是通過Zabbix完成CPU內存這些的監控以及服務器的狀態,我們通過Smokeping來保證全網之間控制平面和控制節點到業務節點還有所有的存儲節點之間的網絡都是可達的,可靠的,因為實際上網絡稍微有一個抖動,你的ceph是最先被感知的,甚至有可能就被踢掉了,這是一個很容易做的,我們也發生過很多次,整個過程中還是踩了很多的坑,這些都是總結下來的.

還有一個模擬應用,我們寫了一個應用,模擬標準的BS的業務,它從LB開始,把請求發過來,我在里面處理這些業務,內部互相盯,模擬一個數據庫的訪問,模擬一個寫盤,我在互相拼一下節點之間痛不痛,因為太多的網絡區太多的租戶了,我必須要排除如果我的模擬應用是好的,起碼證明我的基礎網絡存儲區,

我的這些連通性沒有什么大的問題,我的ceph也沒有問題,必須我要用我的模擬應用排除我整個OpenStack或者基礎平臺的問題,因為應用說的要么就是不通,要么業務中斷了,我們要自證清白,模擬應用在ceph層面比較復雜的,因為如果我只是讀寫一下,那實際上你可能只是在檢測ceph的一個OSD,相當于一塊盤,那怎么樣能夠盡可能多的檢測到足夠多的不同的盤.

我們要寫入的時候我們是16兆一塊,可能就要先寫16兆的前一段,再跳過去寫下16兆,我多寫幾個16兆連續的讀寫,一有這樣的情況,整個ceph沒有問題,但是ceph個別節點出現問題,這個時候你看ceph的監控一切正常,但是這個時候IO已經不正常,這種經過我們都需要做,所以花在這上面的精力比較多.

還有就是剛才也說了,自動化運維,今天的話題很多的嘉賓都談到了,確實自動化就是一切,因為我們節點也很多的,一個參數配的不一致,產生了無窮的隱患,所以我們現在全部要求一切自動化,我們能做到標準化.

按照剛才前一個嘉賓講的,我的成熟度應該是第四級,我要求的是所有的服務器,所有的參數配置必須是用puppet推,我就會強行的改掉所有的參數,也就是我的服務器全是標準的.

剛才提到了我的代碼是自動從GIT撿出的,每一臺機器的擴容要自動的GIT下載社區的代碼,然后直接打包.

我的Goldenimage,因為上面已經跑了一萬的虛機,管理也是非常頭疼的事情,我們都使用標準化的鏡像,通過這種方式保證設備盡量的一致,所以我們一開始在這里做了標準化和自動化,我們堅定的認為標準化和自動化是唯一我們可以解放自己的辦法.

我們就說高可用,銀行的業務還是很變態的,所以我們必須要保證虛擬機是高可用的,所以做了好多的功能,比如虛擬機熱遷移是OpenStack本身代的,但是他遇到了我們控制器以后也不靈了,所以要修改.

虛擬機HA是我們自己研究的,快照也不用說了,我要經常的對虛擬機進行快照和備份,出問題有恢復的地方.

我們還有一個宿主機HA,宿主機也許可能壞,壞的時候上面的虛機都有問題,我要一個獨立運行的自動化流程來保證快速的把這些虛擬機先要停掉,因為有可能它的狀態都不對,這個時候我要先把特都清掉以后快速的在其他的服務器上啟動起來,這是一個標準的.

最后我們說一下展望,我們也已經在OpenStack社區里參與了很長時間了,所以現在我們是在用mogan解決虛擬機的編排問題,

大家也都聽過nova是用在上層的,現在社區地方向是華為、因特爾還有我們一起在OpenStack社區里面做的項目,項目名字叫莫干山,這個項目主要負責配合與nova相對應的完成物理機編排,包括Ironic等等都是完成物理機部署,部署的過程我們也提出了使用Cloudboot來替換的方案,我們必須支持可拔插的driver,這個也在給社區回饋.

還有就是我們自動化擴容,因為目前我們五百個節點不是一日建成的,已經擴了幾十次了,最大的一次擴了幾百個節點,我們希望用一個標準化的流程,通過容量管理觸發一個標準的PBU一個資源池的擴容,擴容以后我通過裝機來完成這些宿主機安裝,把配置全部下發再完成上線,這是自動化擴容方面努力的方向.

剛才說了莫干的項目,我們要完成X86的裸機的服務,還有就是我們的Power小機,也在想辦法完成它的對接,還有存儲的備份,這個備份指的是我放在對象存儲上,還有異構的計算資源的租戶網絡,計算資源有各種各樣的了.因為我一年的發展有一些老機器,不同的機器實際上新舊程度不一樣,性能也不一樣,這個時候我要支持各種異構的資源池了,還有就是今天上午我們談到的運維知識庫,我們要完善開源社區的玩法一樣,我們要用開源的運維知識庫貢獻一些腳本和案例,方便大家在整個Open Stack的運維階段有所借鑒,還有就是我們的日志和監控的分析.

我們要完成性能采集,現在的采集不能支持我們性能再大的發展,我們還要完成容器和文件存儲馬尼拉的服務,這些都是我們在做的事情.

最后我們說一下今天的會議主題是我們要擁抱開源,我們是緊隨社區,希望大家回饋社區,我們只是從社區索取,只提了一段代碼,以后會更多的,所以也希望大家不忘初心,方得始終,謝謝大家.

文章來自微信公眾號：云計算開源產業聯盟

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4092.html