openstack運維命令

A. 運維工程師需要掌握什麼技能

運維工程師需要掌握的技能：

1、首先是主機、網路及操作系統基本知識。在出現問題時，懂得在各個網路位置抓包，來確認故障設備或線路，會使用linux的tcpmp抓包或者ethreal、sniffer、Wireshark等抓包軟體，會在網路設備上配置鏡像，將關心的流量抓出來進行分析。

2、懂開發，能實現自動化運維。比如使用Shell、Python、Perl等腳本語言做一些自動化運行腳本、診斷故障的腳本，使用這些腳本可以提升工作效率，將重復性的簡單工作交給腳本程序處理，也可以通過這些腳本判斷故障發生的位置和原因，高效的運維將不再需要人工去逐個字元地去輸入各種命令。

3、未來雲計算與大數據勢必成為整個互聯網行業的支撐。所有雲計算運維工程師以及大數據工程師的作用就越來與明顯，同時雲計算以及大數據相關高端人才的需求量也會越來越大。

B. 運維的運維工程師使用的平台、工具

運維工程師使用的運維平台和工具包括： Web伺服器：apache、tomcat、nginx、lighttpd 監控：nagios、ganglia、cacti、zabbix 自動部署：ansible、sshpt 配置管理：puppet、cfengine 負載均衡：lvs、haproxy 傳輸工具：scribe、flume 備份工具：rsync、wget 資料庫：mysql、oracle、sqlserver 分布式平台：hdfs、maprece、spark、storm、hive 分布式資料庫：hbase、cassandra、redis、MongoDB 容器：lxc、docker 虛擬化：openstack、xen、kvm 安全：kerberos、selinux、acl、iptables 問題追查：netstat、top、tcpmp、last 廣義上所有開源的軟體都是運維工程師會使用到的平台和工具，同時也包括運維各個技術方向上自行研發的各類平台。

C. OpenStack部署都有哪些方式

對於每一個剛接觸到OpenStack的新人而言，安裝無疑是最困難的，同時這也客觀上提高了大家學習OpenStack雲計算的技術門檻。想一想，自己3年前網上偶然接觸到OpenStack時，一頭茫然，手動搭建一個多節點環境時居然用了3個星期。
時至今日，真是感觸頗多，從某種角度而言，也很慶幸當時自己並未因困難而放棄OpenStack，否則，應該是去做其他領域了吧！
言歸正傳，咱們就來數落數落部署OpenStack都有哪些方式吧。這里，我們根據使用者群體的不同類型來進行分類和歸納：
個人使用方面
DevStack
無疑，在可預見的未來時間內，DevStack仍將是眾多開發者們的首選安裝方式或工具。該方式主要是通過配置參數，執行shell腳本來安裝一個OpenStack的開發環境。
Github: https://github.com/openstack-dev/devstack
Wiki: https://wiki.openstack.org/wiki/DevStack
Rdo
Rdo是由Red Hat開源的一款部署OpenStack的工具，同DevStack一樣，支持單節點和多節點部署。但Rdo只支持CentOS系列的操作系統。需要注意的是，該項目並不屬於OpenStack官方社區項目。
Docs：https://www.rdoproject.org/install/quickstart
手動部署
手動部署all-in-one、multi-node、multi-HA-node環境。
其他
企業、團體方面
Puppet
Puppet由Ruby語言編寫。應當說，Puppet是進入OpenStack自動化部署中的早期一批項目，歷史還算悠久。目前，它的活躍開發群體們是Red hat、 Mirantis、UnitedStack等。
Red
hat自從收購Ansible之後，如今仍然保持強勢勁頭在Puppet
OpenStack項目中的Commit數量和質量，其技術實力不容小覷；Mirantis出品的Fuel部署工具中，大量的模塊代碼便使用的是
Puppet。就國內而言，UnitedStack是Puppet社區貢獻和使用的最大用戶。
Github：
https://github.com/openstack/puppet-keystone
Governance：
Wiki：
https://wiki.openstack.org/wiki/Puppet
Ansible
Ansible
是新近出現的自動化運維工具，已被Red
Hat收購。基於Python開發，集合了眾多運維工具（puppet、cfengine、chef、saltstack等）的優點，實現了批量系統配
置、批量程序部署、批量運行命令等功能，它一方面總結了Puppet的設計上的得失，另一方面也改進了很多設計。比如是基於SSH方式工作，故而不需要在
被控端安裝客戶端。使得在和OpenStack結合上沒有歷史包袱，更加能夠輕裝上陣，未來發展潛力不容小覷號稱是「你一直尋找的下一代Iaas」的
Zstack，使用到的部署工具也是基於Ansible。
Openstack-ansible項目，最早是由老牌Rackspace公司在Launchpad官網上注冊。
在最新的Ansible OpenStack項目社區Commit貢獻中，Rackspace也可謂是遙遙領先，而緊隨其後的是Red Hat、國內九州雲等公司。
Github：https://github.com/openstack/openstack-ansible
SaltStack
SaltStack
也是一款開源的自動化部署工具，基於Python開發，實現了批量系統配置、批量程序部署、批量運行命令等功能，和Ansible也是挺相近的。不同之一
是，由於SaltStack的master和minion認證機制和工作方式，需要在被控端安裝minion客戶端，在加之其他原因，自然和
Ansible相比，其優缺點便很明顯了。
需要注意的是，使用Saltstack部署OpenStack，並不屬於OpenStack社區項目。目前，主要還是處於用戶自研自用的階段。據筆者所知，目前國內的攜程應該是使用Saltstack部署OpenStack規模最大的用戶。
Saltstack部署OpenStack示例：https://github.com/luckpenguin/saltstack_openstack
Saltstack部署OpenStack模塊：
TripleO
Tripleo
項目最早由HP於2013.4在launchpad上注冊BP。用於完成OpenStack的安裝與部署。TripleO全稱「OpenStack On

OpenStack」，意思即為「雲上雲」，可以簡單理解為利用OpenStack來部署OpenStack，即首先基於V2P(和P2V相反，也就是指
把虛擬機的鏡像遷移到物理機上)的理念事先准備好一些OpenStack節點（計算、存儲、控制節點）的鏡像，然後利用已有openstack環境的裸機
服務Ironic項目去部署裸機，軟體安裝部分的diskimage-builder，最後通過Heat項目和鏡像內的DevOps工具(Puppet
Or Chef)再在裸機上配置運行openstack。
和其他部署工具不同的是，TripleO利用OpenStack本來的基礎設施來部署OpenStack，基於Nova、 Neutron、Ironic和Heat，來自動化部署和伸縮OpenStack集群。
應
當確切的說，TripleO項目屬於當前OpenStack社區主推的「Big Tent」開發模式下的big tent
project（OpenStack下的項目分為三種，core project: nova/neutron等核心項目，big tent
project: 非核心項目，但也被OpenStack 基金會接受；第三種就是其它項目，只是放在OpenStack下，但是社區還沒有接受）。
在該項目的社區Commit貢獻上，Red hat可謂是遙遙領先，而緊隨其後的是IBM等公司。
Wiki：https://wiki.openstack.org/wiki/TripleO
Kolla
在
國內一些互聯網資料上，常看到關於kolla是TripleO項目的一部分這樣的描述，其實是不準確的。真實的是，Kolla項目起源於Tripleo項
目，時至今日，與它沒有任何關系（雖然它們的目標都是做自動化部署，但走的道路卻不同）。比之於Tripleo和其他部署工具，Kolla走的是
docker容器部署路線。
kolla項目起源於TripleO項目，聚焦於使用docker容器部署OpenStack服務。該項目由
Cisco於2014年9月提出，是OpenStack的孵化項目。當前Kolla項目在Kollaglue
repo提供了以下服務的docker鏡像。 # docker search kollaglue
Kolla的優勢和使用場景，體現在如下幾個方面：
原子性的升級或者回退OpenStack部署；
基於組件升級OpenStack；
基於組件回退OpenStack；
這里，我們予以拆分來理解：
Kolla
的最終目標是為OpenStack的每一個服務都創建一個對應的Docker Image，通過Docker
Image將升級的粒度減小到Service級別，從而使升級時，對OpenStack影響能達到最小，並且一旦升級失敗，也很容易回滾。升級只需要三
步：Pull新版本的容器鏡像，停止老版本的容器服務，然後啟動新版本容器。回滾也不需要重新安裝包了，直接啟動老版本容器服務就行，非常方便。
Kolla是通過Docker Compose來部署OpenStack集群的，現在主要是針對裸機部署的，所以在部署Docker Container時，默認的網路配置都是Host模式。
首
先，只需要通過一個命令就可以把管理節點部署完成，這個命令是調用Docker
Compose來部署OpenStack的所有服務，然後我們可以在每一個計算節點上通過Docker
Compose安裝計算節點需要的服務，就能部署一個OpenStack集群。因為Kolla的Docker
Image粒度很小，它針對每個OpenStack服務都有特定的Image，所以我們也可以通過Docker
Run來操作某個具體的OpenStack服務。
目前，我所在的公司九州雲的一位同事近日獲得提名成為Kolla項目Core。為OpenStack社區中增添了一份來自於中國的力量。
Fuel
Fuel
是針對OpenStack生產環境目標
（非開源）設計的一個端到端」一鍵部署「的工具，大量採用了Python、Ruby和JavaScript等語言。其功能含蓋自動的PXE方式的操作系統
安裝，DHCP服務，Orchestration服務 和puppet 配置管理相關服務等，此外還有OpenStack關鍵業務健康檢查和log
實時查看等非常好用的服務。
Fuel，這款讓很多人即愛且痛的工具，在國內外都很盛名。愛的原因是，它確實很棒；痛的原因是，要想徹底掌握
它，可不是一件容易事（各個模塊集成度高、使用技術復雜）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技術實
力非常雄厚的OpenStack服務集成商，他是社區貢獻排名前5名中唯一一個靠OpenStack軟體和服務盈利的公司。同時，Fuel的版本節奏也很
快，平均每半年就能提供一個相對穩定的社區版。
從和筆者接觸到的一些情況來看，國內研究、使用Fuel的個人、群體還是為數不少的。不少國內OpenStack初創公司的安裝包就是基於Fuel去修改的。

D. VMware 與 OpenStack 如何最佳整合

vSphere與OpenStack整合
到目前為止我們應該很清楚了，VMware vSphere與OpenStack兩者任何一個都無法滿足多種應用類型。Rackspace就有一些用戶，由於他們應用的分布式本質，用戶已經將應用放到基於OpenStack的共有雲或私有雲之上了。相反，大多數用戶都運營著傳統型應用，這些應用通常運行在裸機或在虛擬化架構之上，並且它們並不那麼容易地去遷移到如OpenStack這樣的雲架構之上。對於這些用戶，共存、非替代可能是應用OpenStack的正確之道。這條混合之路通常伴隨三種解決方案，如下：

孤島型解決方案

hybrid-vsphere.8

孤島型架構是用戶選擇最多的。通常，這種方案涉及到保存在vSphere上的現有遺留傳統應用和在獨立OpenStack雲上建立新應用的抉擇。雖然這是最最無痛的融合OpenStack的解決方案，但是它保持了IT基礎架構的孤島劣勢，並且增加了運維和復雜性，通常我們需要兩個獨立團隊去維護這兩套獨立系統，這也會帶來額外的開銷。

多虛擬機管理器集成解決方案

hybrid-vsphere.9

另一種解決方案是基於VMware已完成的工作將vSphere與OpenStack相集成。這種方案類似於孤島型解決方案，傳統型應用仍然運行在vSphere之上，而新的下一代應用則運行在新的虛擬機管理器之上，如KVM或在XEN。在這種情況下，OpenStack成為多虛擬機管理器的控制平台，它將允許新創建的應用被分配到最適合他們的虛擬機管理平台之上。這種架構的主要缺點是vSphere與OpenStack整合這種方案非常新，這帶來了很多問題，比如兩平台的整合邊緣過於粗糙仍需改進，比如平台的資源如何調度等問題仍然需要解決。

Rackspace的混合實踐方案

hybrid-vsphere.10

上圖是Rackspace給出的OpenStack與vSphere混合解決方案。在分離管理平台這方面，這種架構非常像孤島型架構，此外，它還保證不同類型應用可以被部署到合適的虛擬機管理平台之上。

這里的目標是保持架構的獨立，整合兩個環境的運維團隊使他們可以共同工作來打造一個集成的平台。這其中的一個關鍵是應用技術，如Rackspace的RackConnect把這些基礎架構連接起來，使每個架構都可以與其他架構協同工作。這里舉一個例子，一個應用運行在基於OpenStack的Rackspace私有雲之上，通過RackConnect與運行在vSphere集群上的Oracle資料庫相連接。

E. 如何對openstack進行監控

第一類監控服務: 基本數據監控服務
阿里雲在這方面的工作跟盛大雲、Google Cloud Engine類似，主要覆蓋了三個基本指標分別是VM的CPU，存儲帶寬和網路流量。但是目前而言，歷史功能都不是太豐富，這些都是基本不可能讓SA依賴這些功能去運維的。

第二類監控服務: 多維度數據監控服務
AWS一直是將服務可運維作為一個重要目的，如果AWS在EC2，EBS的努力一樣，數據監控和報警在AWS的CloudWatch上體現。
AWS的CloudWatch API設計是作者比較推崇的，它將任意維度、類型的監控指標都可以通過一個簡單的模型來集中管理。對CloudWatch不太了解的可以去官方文檔一探究竟Amazon CloudWatch Getting Started Guide 。
從下圖可以發現CloudWatch的三個重要概念，在Viewing欄是Namspace，在表格欄是Metric，它可以通過不同的dimension來定位。最後是一個Metric在時間維度和統計方法、不同時間粒度的展現。在這里我們可以發現AWS支持的數據監控和展示優點有: 1.數據監控和報表的基本功能覆蓋，如時間維度，統計粒度。2. 增加服務或者監控項目非常方便。

上面提到的僅僅是數據收集的方式，CloudWatch的API無疑是非常好的設計。但在顯示上CloudWatch無疑還有更多工作，AWS在自己的CloudWatch上並沒有太多工作是為了將顯示交給用戶。這給很多用戶帶來的不便，提供一個類型多樣的顯示模板或許能做的更好。
第三類監控服務: 特定類型數據監控服務
ScaleIO是一家致力於與Amazon EBS競爭的存儲Startup，同樣是寄希望於打破傳統存儲廠商的壁壘和綁定，ScaleIO提供了軟體層面的塊存儲，並且對SSD，HDD，Network做到了不可知。
不過，現在我們主要關注ScaleIO提供的非常酷炫的監控Dashboard。

通過對存儲服務的定製化展示來達到驚艷的效果，把監控當做一個系統的重要亮點。不過，顯而易見的是，這類展示是需要額外工作的，在用戶方面很難復用這類展示。

在OpenStack如何實現強大的監控系統
從以上不同類型甚至不同產品的監控展示系統上我們可以理出一個對IAAS平台的思路。在IAAS平台上，數據監控從架構角度分為三層，物理機、虛擬機和應用。然後從用戶角度可以分為三類需求，普通用戶，定製用戶和高級用戶。普通用戶希望直接能使用默認監控項，並且能大部分滿足需求。定製用戶會適當修改默認監控項顯示或者位置。高級用戶希望自定義輸入，輸出，組合監控項。
在數據收集方面，利用OpenStack現有項目Ceilometer的工作，它提供了OpenStack所有Core Project的支持並且具備一個與CloudWatch類似的存儲設計和API支持。但是由於Ceilometer目前的局限和CloudWatch API的良好設計上，我們可以結合兩者，為Ceilometer同樣實現CloudWatch API，這樣可以大大增加了Ceilometer的兼容性，帶來了CloudWatch社區的廣大福利(眾多第三方庫和數據收集腳本)。目前這個計劃已經在社區的bp中。
在數據顯示方面，需要補強AWS CloudWatch在這方面的脆弱點，大大加強數據顯示上的選擇和使用。相對於AWS CloudWatch簡單的折線圖和ScaleIO的定製化Dashboard做一個折中，設計類似於源數據->顯示單元的前端解析框架，可以為同樣的數據套上不同的顯示單元。通過這一方式，我們將收集和顯示完全解耦，將顯示單元也同樣暴露給用戶可視化復用。

F. 運維工程師必須掌握的基礎技能有哪些

運維工程師必須掌握的基礎技能有：基礎命令、基礎服務、自動化技能、安全。

1、基礎命令：

這個基礎就包括：用戶管理命令，文件管理命令，許可權管理命令，軟體包管理命令，vim命令，網路管理命令等。這些命令好學，因為每個命令都有相應的help幫助文檔，而且很多網站都集成了命令幫助，把這些站點進行收藏，時不時的查下就記住了。

2、基礎服務：

企業常用的基礎服務就包括DHCP,NTP,DNS,Nginx,Apache,Mysql,Redis,Vsftpd,Nfs。基礎服務的掌握，相比命令稍微的難一點，但是同樣有很多技巧。比如可以去各大視頻站獲取優質的免費視頻學習。

3、自動化技能：

這個自動化就包括腳本自動化，需要熟悉掌握shell腳本或者Python腳本；包括監控自動化，不能靠傳統的點擊頁面，查看進程來判斷服務是否在線，需要熟悉掌握zabbix,Prometheus等主流監控軟體；還包括工具自動化，需要掌握向ansible，puppet，Jenkins等自動化軟體，實現服務的批量部署與業務的自動化。

4、安全：

作為運維工程師，首先就要時刻保障公司業務系統，伺服器安全穩定運行。所以安全至關重要，主流的iptables，firewalld防火牆技術要熟練掌握，有必要的話常見的挖礦病毒，ddos等攻擊有段也要有所了解。

運維工程師(Operations)，負責維護並確保整個服務的高可用性，同時不斷優化系統架構提升部署效率、優化資源利用率提高整體的ROI。

運維工程師面對的最大挑戰是大規模集群的管理問題，如何管理好幾十萬台伺服器上的服務，同時保障服務的高可用性，是運維工程師面臨的最大挑戰。

G. 如何使用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基礎上自研了編排調度等組件，支持應用的彈性伸縮、灰度升級等功能，並支持一定的調度策略，從而實現了PaaS層的主要功能。
同時，基於Docker和Jenkins實現了持續集成(CI)。Git中的項目如果發生了git push等動作，便會觸發Jenkins Job進行自動構建，如果構建成功便會生成Docker Image並push到鏡像倉庫。基於CI生成的Docker Image，可以通過PaaS的API或界面，進行開發測試環境的實例更新，並最終進行生產環境的實例更新，從而實現持續集成和持續交付。
網路和存儲
網路方面，我們沒有採用Docker默認提供的NAT網路模式，NAT會造成一定的性能損失。通過OpenStack，我們支持Linux bridge和Open vSwitch，不需要啟動iptables，Docker的性能接近物理機的95%。
容器的監控
監控方面，我們自研了container tools，實現了容器load值的計算，替換了原有的top、free、iostat、uptime等命令。這樣業務方在容器內使用常用命令時看到的是容器的值，而不是整個物理機的。目前我們正在移植Lxcfs到我們的平台上。
我們還在宿主機上增加了多個閾值監控和報警，比如關鍵進程監控、日誌監控、實時pid數量、網路連接跟蹤數、容器oom報警等等。
冗災和隔離性
冗災和隔離性方面，我們做了大量的冗災預案和技術准備。我們能夠在不啟動docker daemon的情況下，離線恢復Docker中的數據。同時，我們支持Docker的跨物理機冷遷移，支持動態的CPU擴容/縮容，網路IO磁碟IO的限速。
遇到的問題及解決方法
接近一年不到的產品化和實際使用中我們遇到過各種的問題，使用Docker的過程也是不斷優化Docker、不斷定位問題、解決問題的過程。
我們現在的生產環境用的是CentOS 6.5。曾經有個業務方誤以為他用的Docker容器是物理機，在Docker容器裡面又裝了一個Docker，瞬間導致內核crash，影響了同一台物理機的其他Docker容器。
經過事後分析是2.6.32-431版本的內核對network namespace支持不好引起的，在Docker內創建bridge會導致內核crash。upstream修復了這個bug，從2.6.32-431升級到2.6.32-504後問題解決。
還有一個用戶寫的程序有bug，創建的線程沒有及時回收，容器中產生了大量的線程，最後在宿主機上都無法執行命令或者ssh登陸，報的錯是"bash: fork: Cannot allocate memory"，但通過free看空閑的內存卻是足夠的。
經過分析，發現是內核對pid的隔離性支持不完善，pid_max(/proc/sys/kernel/pid_max)是全局共享的。當一個容器中的pid數目達到上限32768，會導致宿主機和其他容器無法創建新的進程。最新的4.3-rc1才支持對每個容器進行pid_max限制。
我們還觀察到docker的宿主機內核日誌中會產生亂序的問題。經過分析後發現是由於內核中只有一個log_buf緩沖區，所有printk列印的日誌先放到這個緩沖區中，docker host以及container上的rsyslogd都會通過syslog從kernel的log_buf緩沖區中取日誌，導致日誌混亂。通過修改 container里的rsyslog配置，只讓宿主機去讀kernel日誌，就能解決這個問題。
除此之外，我們還解決了device mapper的dm-thin discard導致內核crash等問題。
體會和思考
最後分享一下我們的體會和思考，相比KVM比較成熟的虛擬化技術，容器目前還有很多不完善的地方，除了集群管理、網路和存儲，最重要的還是穩定性。影響穩定性的主要還是隔離性的不完善造成的，一個容器內引起的問題可能會影響整個系統。
容器的memcg無法回收slab cache，也不對dirty cache量進行限制，更容易發生OOM問題。還有，procfs上的一些文件介面還無法做到per-container，比如pid_max。
另外一點是對容器下的運維手段和運維經驗的沖擊。有些系統維護工具，比如ss，free，df等在容器中無法使用了，或者使用的結果跟物理機不一致，因為系統維護工具一般都會訪問procfs下的文件，而這些工具或是需要改造，或是需要進行適配。
雖然容器還不完善，但是我們還是十分堅定的看好容器未來的發展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相關的開源軟體，都是我們關注的重點。
Q&A
Q：請問容器間的負載均衡是如何做的?
A： 容器間的負載均衡，更多是PaaS和SaaS層面的。我們的P層支持4層和7層的動態路由，通過域名的方式，或者名字服務來暴露出對外的介面。我們能夠做到基於容器的灰度升級，和彈性伸縮。
Q：請問你們的OpenStack是運行在CentOS 6.5上的嗎?
A: 是的，但是我們針對OpenStack和Docker依賴的包進行了升級。我們維護了內部的yum源。
Q：請問容器IP是靜態編排還是動態獲取的?
A: 這個跟運維所管理的網路模式有關，我們內部的網路沒有DHCP服務，因此對於IaaS層，容器的IP是靜態分配的。對於PaaS層來說，如果有DHCP服務，容器的App所暴露出來IP和埠就可以做到動態的。
Q：請問你們當時部署的時候有沒有嘗試過用Ubuntu，有沒有研究過兩個系統間的區別，另外請問你們在OpenStack上是怎樣對這些虛擬機監控的?
A: 我們沒有嘗試過Ubuntu，因為公司生產環境上用的是CentOS。我們的中間件團隊負責公司機器的監控，我們和監控團隊配合，將監控的agent程序部署到宿主機和每個容器里，這樣就可以當成虛擬機來進行監控。
當然，容器的數據是需要從cgroups里來取，這部分提取數據的工作，是我們來實現的。
Q：容器間的網路選型有什麼建議，據說採用虛擬網卡比物理網卡有不小的性能損失，Docker自帶的weaves和ovs能勝任嗎?
A: 容器的網路不建議用默認的NAT方式，因為NAT會造成一定的性能損失。之前我的分享中提到過，不需要啟動iptables，Docker的性能接近物理機的95%。Docker的weaves底層應該還是採用了網橋或者Open vSwitch。建議可以看一下nova-docker的源碼，這樣會比較容易理解。
Q：靜態IP通過LXC實現的嗎?
A: 靜態IP的實現是在nova-docker的novadocker/virt/docker/vifs.py中實現的。實現的原理就是通過ip命令添加 veth pair，然後用ip link set/ip netns exec等一系列命令來實現的，設置的原理和weaves類似。
Q：容器內的進程gdb你們怎麼弄的，把gdb打包到容器內嗎?
A: 容器內的gdb不會有問題的，可以直接yum install gdb。
Q：共享存儲能直接mount到容器里嗎?
A: 雖然沒試過，但這個通過docker -v的方式應該沒什麼問題。
Q：不啟動Docker Daemon的情況下，離線恢復Docker中的數據是咋做到的?
A: 離線恢復的原理是用dmsetup create命令創建一個臨時的dm設備，映射到Docker實例所用的dm設備號，通過mount這個臨時設備，就可以恢復出原來的數據。
Q：Docker的跨物理機冷遷移，支持動態的CPU擴容/縮容，網路IO磁碟IO的限速，是怎麼實現的，能具體說說嗎?
A：Docker的冷遷移是通過修改nova-docker，來實現OpenStack遷移的介面，具體來說，就是在兩台物理機間通過docker commit，docker push到內部的registry，然後docker pull snapshot來完成的。
動態的CPU擴容/縮容，網路IO磁碟IO的限速主要是通過novadocker來修改cgroups中的cpuset、iops、bps還有TC的參數來實現的。
Q：請問你們未來會不會考慮使用Magnum項目，還是會選擇Swarm?
A：這些都是我們備選的方案，可能會考慮Swarm。因為Magnum底層還是調用了Kubernetes這樣的集群管理方案，與其用Magnum，不如直接選擇Swarm或者是Kubernetes。當然，這只是我個人的看法。
Q：你們的業務是基於同一個鏡像么，如果是不同的鏡像，那麼計算節點如何保證容器能夠快速啟動?
A：運維會維護一套統一的基礎鏡像。其他業務的鏡像會基於這個鏡像來製作。我們在初始化計算節點的時候就會通過docker pull把基礎鏡像拉到本地，這也是很多公司通用的做法，據我了解，騰訊、360都是類似的做法。
Q：做熱遷移，有沒有考慮繼續使用傳統共享存儲的來做?
A： 分布式存儲和共享存儲都在考慮范圍內，我們下一步，就計劃做容器的熱遷移。
Q：請問你們是直接將公網IP綁定到容器嗎，還是通過其他方式映射到容器的私有IP，如果是映射如何解決原本二層的VLAN隔離?
A：因為我們是私有雲，不涉及floating ip的問題，所以你可以認為是公網IP。VLAN的二層隔離完全可以在交換機上作。我們用Open vSwitch劃分不同的VLAN，就實現了Docker容器和物理機的網路隔離。
Q：Device mapper dm-thin discard問題能說的詳細些嗎?
A：4月份的時候，有兩台宿主機經常無故重啟。首先想到的是查看/var/log/messages日誌，但是在重啟時間點附近沒有找到與重啟相關的信息。而後在/var/crash目錄下，找到了內核crash的日誌vmcore-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：你們自研的container 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的方式集成Dcoker嗎，Docker的高級特性是否可以使用，如docker-api，另外為什麼不使用Heat集成Docker?
A：我們是用nova-docker這個開源軟體實現的，nova-docker是StackForge上一個開源項目，它做為nova的一個插件，替換了已有的libvirt，通過調用Docker的RESTful介面來控制容器的啟停等動作。
使用Heat還是NOVA來集成Docker業界確實一直存在爭議的，我們更多的是考慮我們自身想解決的問題。Heat本身依賴的關系較為復雜，其實業界用的也並不多，否則社區就不會推出Magnum了。
Q：目前你們有沒有容器跨DC的實踐或類似的方向?
A：我們已經在多個機房部署了多套集群，每個機房有一套獨立的集群，在此之上，我們開發了自己的管理平台，能夠實現對多集群的統一管理。同時，我們搭建了Docker Registry V1，內部准備升級到Docker Registry V2，能夠實現Docker鏡像的跨DC mirror功能。
Q：我現在也在推進Docker的持續集成與集群管理，但發現容器多了管理也是個問題，比如容器的彈性管理與資源監控，Kubernetes、Mesos哪個比較好一些，如果用在業務上，那對外的域名解析如何做呢，因為都是通過宿主機來通信，而它只有一個對外IP?
A： 對於Kubernetes和Mesos我們還在預研階段，我們目前的P層調度是自研的，我們是通過etcd來維護實例的狀態，埠等信息。對於7層的可以通過Nginx來解析，對於4層，需要依賴於naming服務。我們內部有自研的naming服務，因此我們可以解決這些問題。對外雖然只有一個IP，但是暴露的埠是不同的。
Q：你們有考慮使用Hyper Hypernetes嗎? 實現容器與宿主機內核隔離同時保證啟動速度?
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的隔離還不完善，你們開發的container tools是基於應用層的還是需要修改內核?
A：安裝和使用應該沒問題，但如果上生產環境，是需要全面的考慮的，主要還是穩定性和隔離性不夠，低版本的內核更容易造成系統 crash或者各種嚴重的問題，有些其實不是bug，而是功能不完善，比如容器內創建網橋會導致crash，就是network namespace內核支持不完善引起的。
我們開發的container tools是基於應用的，不需要修改內核。
Q：關於冗災方面有沒有更詳細的介紹，比如離線狀態如何實現數據恢復的?
A：離線狀態如何實現恢復數據，這個我在之前已經回答過了，具體來說，是用dmsetup create命令創建一個臨時的dm設備，映射到docker實例所用的dm設備號，通過mount這個臨時設備，就可以恢復出原來的數據。其他的冗災方案，因為內容比較多，可以再另外組織一次分享了。你可以關注一下http://mogu.io/，到時候我們會分享出來。
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在性能上得到了很大提升？