由工業和資訊化部指導，中國資訊通訊研究院主辦，業界知名組織雲端計算開源產業聯盟（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的運維階段有所借鑑，還有就是我們的日誌和監控的分析。

我們要完成效能採集，現在的採集不能支援我們效能再大的發展，我們還要完成容器和檔案儲存馬尼拉的服務，這些都是我們在做的事情。

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

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