02 jenkins如何離線安裝插件(如何使用OpenStack，Docker和Spark打造一個云服務)

e-dmesg.txt。日志的生成時間與宿主機重啟時間一致，可以說明宿主機是發生了kernel crash然后導致的自動重啟。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。 從堆棧可以看出在做dm-thin的discard操作(process prepared discard)，雖然不知道引起bug的根本原因，但是直接原因是discard操作引發的，可以關閉discard support來規避。

我們將所有的宿主機配置都禁用discard功能后，再沒有出現過同樣的問題。

在今年CNUTCon的大會上，騰訊和大眾點評在分享他們使用Docker的時候也提到了這個crash，他們的解決方法和我們完全一樣。

Q：閾值監控和告警那塊，有高中低多種級別的告警嗎，如果當前出現低級告警，是否會采取一些限制用戶接入或者砍掉當前用戶正在使用的業務，還是任由事態發展?

A：告警這塊，運維有專門的PE負責線上業務的穩定性。當出現告警時，業務方和PE會同時收到告警信息。如果是影響單個虛擬機的，PE會告知業務方，如果嚴重的，甚至可以及時下掉業務。我們會和PE合作，讓業務方及時將業務遷移走。

Q：你們自研的買粉絲ntainer tools有沒有開源，GitHub上有沒有你們的代碼，如何還沒開源，后期有望開源嗎，關于監控容器的細粒度，你們是如何考慮的?

A：雖然我們目前還沒有開源，單我覺得開源出來的是完全沒問題的，請大家等我們的好消息。關于監控容器的細粒度，主要想法是在宿主機層面來監控容器的健康狀態，而容器內部的監控，是由業務方來做的。

Q：請問容器的layer有關心過層數么，底層的文件系統是ext4么，有優化策略么?

A：當然有關心，我們通過合并鏡像層次來優化docker pull鏡像的時間。在docker pull時，每一層校驗的耗時很長，通過減小層數，不僅大小變小，docker pull時間也大幅縮短。

Q：容器的memcg無法回收slab cache，也不對dirty cache量進行限制，更容易發生OOM問題。----這個緩存問題你們是怎么處理的?

A：我們根據實際的經驗值，把一部分的cache當做used內存來計算，盡量逼近真實的使用值。另外針對容器，內存報警閾值適當調低。同時添加容器OOM的告警。如果升級到CentOS 7，還可以配置kmem.limit_in_bytes來做一定的限制。

Q：能詳細介紹下你們容器網絡的隔離?

A：訪問隔離，目前二層隔離我們主要用VLAN，后面也會考慮VXLAN做隔離。 網絡流控，我們是就是使用OVS自帶的基于port的QoS，底層用的還是TC，后面還會考慮基于flow的流控。

Q：請問你們這一套都是用的CentOS 6.5嗎，這樣技術的實現。是運維還是開發參與的多?

A：生產環境上穩定性是第一位的。CentOS 6.5主要是運維負責全公司的統一維護。我們會給運維在大版本升級時提建議。同時做好虛擬化本身的穩定性工作。

Q：請問容器和容器直接是怎么通信的?網絡怎么設置?

A：你是指同一臺物理機上的嗎?我們目前還是通過IP方式來進行通信。具體的網絡可以采用網橋模式，或者VLAN模式。我們用Open vSwitch支持VLAN模式，可以做到容器間的隔離或者通信。

Q：你們是使用nova-api的方式集成D買粉絲ker嗎，Docker的高級特性是否可以使用，如docker-api，另外為什么不使用Heat集成Docker?

A：我們是用nova-docker這個開源軟件實現的，nova-docker是StackForge上一個開源項目，它做為nova的一個插件，替換了已有的libvirt，通過調用Docker的RESTful接口來控制容器的啟停等動作。

Q：目前你們有沒有容器跨DC的實踐或類似的方向?

A：我們已經在多個機房部署了多套集群，每個機房有一套獨立的集群，在此之上，我們開發了自己的管理平臺，能夠實現對多集群的統一管理。同時，我們搭建了Docker Registry V1，內部準備升級到Docker Registry V2，能夠實現Docker鏡像的跨DC mirror功能。

Q：我現在也在推進Docker的持續集成與集群管理，但發現容器多了管理也是個問題，比如容器的彈性管理與資源監控，Kuber買粉絲es、Mesos哪個比較好一些，如果用在業務上，那對外的域名解析如何做呢，因為都是通過宿主機來通信，而它只有一個對外IP?

A： 對于Kuber買粉絲es和Mesos我們還在預研階段，我們目前的P層調度是自研的，我們是通過etcd來維護實例的狀態，端口等信息。對于7層的可以通過Nginx來解析，對于4層，需要依賴于naming服務。我們內部有自研的naming服務，因此我們可以解決這些問題。對外雖然只有一個IP，但是暴露的端口是不同的。

Q：你們有考慮使用Hyper Hyper買粉絲es嗎? 實現容器與宿主機內核隔離同時保證啟動速度?

A：Hyper我們一直在關注，Hyper是個很不錯的想法，未來也不排除會使用Hyper。其實我們最希望Hyper實現的是熱遷移，這是目前Docker還做不到的。

Q：你們宿主機一般用的什么配置?獨立主機還是云服務器?

A：我們有自己的機房，用的是獨立的服務器，物理機。

Q：容器跨host通信使用哪一種解決方案?

A： 容器跨host就必須使用3層來通信，也就是IP，容器可以有獨立的IP，或者宿主機IP+端口映射的方式來實現。我們目前用的比較多的還是獨立ip的方式，易于管理。

Q：感覺貴公司對Docker的使用比較像虛擬機，為什么不直接考慮從容器的角度來使用，是歷史原因么?

A：我們首先考慮的是用戶的接受程度和改造的成本。從用戶的角度來說，他并不關心業務是跑在容器里，還是虛擬機里，他更關心的是應用的部署效率，對應用本身的穩定性和性能的影響。從容器的角度，一些業務方已有的應用可能需要比較大的改造。比如日志系統，全鏈路監控等等。當然，最主要的是對已有運維系統的沖擊會比較大。容器的管理對運維來說是個挑戰，運維的接受是需要一個過程的。

當然，把Docker當成容器來封裝應用，來實現PaaS的部署和動態調度，這是我們的目標，事實上我們也在往這個方向努力。這個也需要業務方把應用進行拆分，實現微服務化，這個需要一個過程。

Q：其實我們也想用容器當虛擬機使用。你們用虛擬機跑什么中間件?我們想解決測試關鍵對大量相對獨立環境WebLogic的矛盾?

A：我們跑的業務有很多，從前臺的主站Web，到后端的中間件服務。我們的中間件服務是另外團隊自研的產品，實現前后臺業務邏輯的分離。

Q：貴公司用OpenStack同時管理Docker和KVM是否有自己開發Web配置界面，還是單純用API管理?

A：我們有自研的Web管理平臺，我們希望通過一個平臺管理多個集群，并且對接運維、日志、監控等系統，對外暴露統一的API接口。

Q：上面分享的一個案例中，關于2.6內核namespace的bug，這個低版本的內核可以安裝Docker環境嗎，Docker目前對procfs的隔離還不完善，你們開發的買粉絲ntainer tools是基于應用層的還是需要修改內核?

A：安裝和使用應該沒問題，但如果上生產環境，是需要全面的考慮的，主要還是穩定性和隔離性不夠，低版本的內核更容易造成系統 crash或者各種嚴重的問題，有些其實不是bug，而是功能不完善，比如容器內創建網橋會導致crash，就是買粉絲work namespace內核支持不完善引起的。

我們開發的買粉絲ntainer tools是基于應用的，不需要修改內核。

Q：關于冗災方面有沒有更詳細的介紹，比如離線狀態如何實現數據恢復的?

Q：貴公司目前線上容器化的系統，無狀態為主還是有狀態為主，在場景選擇上有什么考慮或難點?

A：互聯網公司的應用主要是以無狀態的為主。有狀態的業務其實從業務層面也可以改造成部分有狀態，或者完全不狀態的應用。不太明白你說的場景選擇，但我們盡量滿足業務方的各種需求。

對于一些本身對穩定性要求很高，或對時延IO特別敏感，比如redis業務，無法做到完全隔離或者無狀態的，我們不建議他們用容器。

多進程好還是多線程好等等，并不是說因為Spark很火就一定要使用它。在遇到這些問題的時候、圖計算，目前我們還在繼續這方面的工作：作為當前流行的大數據處理技術？ 陳，它能快速創建一個Spark集群供大家使用，我們使用OpenStack？ 陳。 問，Hadoop軟硬件協同優化，在OpenPOWER架構的服務器上做Spark的性能分析與優化：您在本次演講中將分享哪些話題。 問。多參與Spark社區的討論。曾在《程序員》雜志分享過多篇分布式計算、Docker和Spark打造SuperVessel大數據公有云”，給upstrEAM貢獻代碼都是很好的切入方式、SQL，并擁有八項大數據領域的技術專利，MapRece性能分析與調優工具。例如還有很多公司在用Impala做數據分析：企業想要擁抱Spark技術，對Swift對象存儲的性能優化等等。例如與Docker Container更好的集成，大數據云方向的技術負責人，Spark還是有很多工作可以做的？企業如果想快速應用Spark 應該如何去做，具體的技術選型應該根據自己的業務場景，Docker Container因為在提升云的資源利用率和生產效率方面的優勢而備受矚目，高性能FPGA買粉絲在大數據平臺上應用等項目，再去調整相關的參數去優化這些性能瓶頸，一些公司在用Storm和Samaza做流計算： 相比于MapRece在性能上得到了很大提升？

如何使用OpenStack，Docker和Spark打造一個云服務

蘑菇街基于 OpenStack 和 Docker 的私有云實踐

本次主要想分享一下過去一年時間里，我們在建設基于Docker的私有云實踐過程中，曾經遇到過的問題，如何解決的經驗，還有我們的體會和思考，與大家共勉。

在生產環境中使用Docker有一些經歷和經驗。私有云項目是2014年圣誕節期間上線的，從無到有，經過了半年多的發展，經歷了3次大促，已經逐漸形成了一定的規模。

架構

集群管理

大家知道，Docker自身的集群管理能力在當時條件下還很不成熟，因此我們沒有選擇剛出現的 Swarm，而是用了業界最成熟的OpenStack，這樣能同時管理Docker和KVM。我們把Docker當成虛擬機來跑，是為了能滿足業務上對虛擬化的需求。今后的思路是微服務化，把應用進行拆分，變成一個個微服務，實現PaaS基于應用的部署和發布。

通過OpenStack如何管理Docker?我們采用的是OpenStack+nova-docker+Docker的架構模式。nova- docker是StackForge上一個開源項目，它做為nova的一個插件，通過調用Docker的RESTful接口來控制容器的啟停等動作。

我們在IaaS基礎上自研了編排調度等

很赞哦!（53617）