Mark Shuttleworth在十幾年前發起了Ubuntu inux項目，現在他在Canonical(一家提供Ubuntu支持服務的公司)主管戰略和用戶體驗。他認為新一輪的服務器虛擬化浪潮與前一輪不太相同。
在他的指導下，Canonical和其他的Linux機構一樣，在其發布版本中先是Xen Hypervisor，接著是KVM然后繼續支持Docker，成功地趕上了虛擬化的幾輪潮流。當Eucalyptus是用的可計算云控制器時該公司成為排頭兵，而當業界開始支持另一個開源項目- OpenStack而且OpenStack做為Linux的首選被部署到多個公有云上時，他們也迅速地轉向OpenStack。Docker及其軟件容器方式完全類似于虛擬化并且讓云計算服務商為之癲狂，但是讓Shuttleworth興奮的是另一種稱為Linux容器 (縮寫為LXC)的技術及與之相應的稱為LXD的Hypervisor。LXD是由Canonical開發的一個后臺進程來管理這些容器并且提供了或多或少與開源的Xen及KVM、微軟的Hyper-V或者VMware的ESXi這些服務器虛擬化Hypervisor類似的功能。
Shuttlworth向The Next Platform表示：“我們相信這是十年來對Linux虛擬化最大的突破，你可以看到我們對此是多么興奮”。
LXC容器的想法和初期的工作都是由Google完成的，容器化應用程序已經在其基礎架構上運行了超過十年時間，而且據說每天會啟動超過20億的容器。Canonical和其他大約80個組織已經開始致力于LXC的商業化，因為LXC最初并不是一個對用戶很友好的技術。商業化是為了讓其具有常見服務器虛擬化的觀感和體驗，盡管它使用的是非常不同且簡化的技術。
“對于容器，很多人并不了解的是我們用來配置容器的系統其實可以用很多種方法來做虛擬或者模擬”，Shuttleworth解釋說”有時你希望模仿看起和Docker類似的東西，而有時你又想模擬其他的東西。就LXC而言，我們想要創建容器的途徑是創建假想的主機，而不是運行操作系統的主機或者構成一個操作系統的所有進程。這與Docker所作的完全不同,雖然它們都使用相同的底層原語，但是創建了不同的的東西。LXC的宗旨是不借助硬件虛擬化來創建虛擬機“
說起Docker，它在早期是基于LXC的但是現在它有了自己的抽象層，它更像一個運行在文件系統之上的單個進程，就好比你啟動了主機但并沒有運行 Init和所有構成操作系統的進程而是直接運行數據庫或者其他的東西，然后在一臺主機上啟動多個容器并把它們一起置于其中。通過LXC及其LXD守護進程，Canonical希望保持擁有一個完整Debian、CentOS、Ubuntu或其他Linux操作系統的感觀。
“在LXC 1.0中，常見的情景是程序員說：“給我創建這個容器”。現在我們做法接收代碼然后將其納入LXD守護進程來管理，因此并不需要由程序員去創建每一個容器，我可以擁有上百個虛擬機并且與LXD守護進程進行通信來進行統一管理，因此我所擁有的虛擬機集群與你使用VMware ESXi hypervisor所構建的類似。把LXC打包到一個守護進程中就使得它變成了一個hypervisor。什么是ESXi?它基本上是一個操作系統，你可以通過網絡跟它通信并且讓它給你創建一個虛擬機。通過LXD，你可以跟一個運行LXC的主機說給我創建一個運行CentOS的新容器。這成為一個集群的導引機制。”
LXD也提供了另一個重要功能：它是運行的在兩臺不同物理主機上的一個軟件，從而使得LXC實例能夠在主機間在線地遷移。
程序員都追求簡潔而且他們喜歡保持事物有序和整潔。在某種程度上，只是因為硬件虛擬化的成本很高就不得不把程序部署到多個主機上已經成了一個痛點。現在，你可以快速地在一臺主機上運行多個程序而沒有這些開銷并且始終保持他們的原始狀態和隔離。
本周，Canonical發布了首次包括LXD hypervisor的LXC 2.0 beta版本。在本月將要發布的Ubuntu Server 15.10的更新中就包括這兩個組件，而Canonical也通過統一步驟把LXC 2.0反推入Ubuntu Server 14.04 LTS(LTS是Long Term Support的縮寫)的服務器版本。LTS版本每兩年發布一次而且具有五年的支持生命期。由于它的穩定性有保證，所以70%的客戶都在生產環境中運行 Ubuntu服務器的LTS版本。據Shuttleworth說，包含LXD hypervisor的LXC 2.0生產級別版本將在明年亮相，根據命名方案的建議可能就在二月或者三月最遲到4月就與新的企業級版本 – Ubuntu Server 16.04 LTS一同發布。負責Ubuntu產品和戰略的Dustin Kirklan對TheNext Platform說，從下一個LTS版本開始，在每一個Ubuntu Server中就會缺省安裝LXC和LXD組件，這樣每個主機都可以運行幾十到幾百個容器 –IBM在最大的使用POWER處理器的服務器上甚至可以運行數千個容器。
相比于依靠硬件虛擬化的常規虛擬機，LXC容器具有兩個巨大的優勢：一臺主機上可以打包的容器數量和這些容器的啟動速度。盡管為了在一臺硬件上用不同的容器運行不同的Linux需要一些額外的工作，但是由于LXC其實就是用Linux運行Linux，所以不需要虛擬什么。
“這在性能方面前進了一步，而在密度方面的改進則是巨大的”，Shuttleworth無不得意地說：“而這對于低延遲、實時型的應用程序具有顯著的改善。在云計算環境中這類事情都變得容易處理了，當然過去他們可不是這樣。如果你的云平臺運行了LXC，很快高性能計算可以搞定了、云計算平臺上的實時計算也可以搞定了，而且如果你是一個需要低傳輸延遲的電信運營商的話，那么NFV(網絡功能虛擬化)也可以搞定了。在這些需要巨大資金投入的領域，人們真的希望使用云計算和虛擬化，而LXC使其成為可能。這是非常令人振奮的”
Shuttleworth說LXC容器在密度方面可以達到諸如EXSi、Xen或KVM這類使用虛擬機的hypervisor的14倍，而且 LXC和LXD組合在開銷方面卻只占基于硬件虛擬化的Hypervisor的20%不到。對于空閑的負載而言，VM和LXC容器就和大多數VM和物理主機所作的一樣大部分時間在等待。對于繁忙的VM而言，LXC容器則能夠提供明顯要好得多的I/O吞吐量和更低的延遲。因此，對于空閑的主機你專注于整合，而對于繁忙的主機你專注于吞吐量和延遲。而且由于Hypervisor和VM的特定開銷可以釋放出來用于實際工作，所以你可以得到大約20%的性能提升。
現在已經開始對LXC及LXD組合進行基準測試。在上周東京召開的OpenStack峰會上，Canonical LXD開發團隊的Tycho Andersen展示了一些在虛擬化環境中的測試基準，其中一個是使用Hadoop TeraSort測試而另一個是對Cassandra NoSQL數據存儲的壓力測試。這兩個測試中，主機運行的是在峰會期間發布的最新OpenStack “Liberty”云控制器和同樣剛發布的Ubuntu 15.10. 15.10，它既有KVM也有LXD hypervisor和各自的虛擬機和容器。這些服務器配備了24核和48GB內存，一個控制器負責管理OpenStack而其他三臺用作基本的計算節點。
在TeraSort測試開始的時候，在三臺主機上LXC和KVM的表現基本一致，但是當OpenStack/Hadoop集群中的主機數量隨著數據集的規模增長后，兩種不同的虛擬化手段在性能方面的差異開始顯現。
你可以看到LXC/LXD同KVM在延遲和吞吐量上的差異是非常明顯的。
愛立信研究院和阿爾托大學發表了一篇很有意思的論文，它表明主機在運行LXD和Docker時比運行Xen和KVM能節省更多的能耗，你可以點擊這里查看。在CPU和內存的基準測試結果中，隨著更多的VM或者容器加到主機上，服務器的功率隨之消耗上升而且兩者之間的差距并不明顯，但是當他們處理網絡流量時，Docker和LXC在完成相同的工作時要少消耗10%的能耗。
由于容器的輕便特性，使得LXC容器毫無意外地用于很多云計算平臺，而且極有可能成為未來基礎架構云的基礎 – 至少是那些只運行Linux的云基礎架構平臺，因為LXC不能運行在數據中心中的另一種重要操作系統 – Windows server上。但盡管如此，大多數重要的新軟件是在Linux之上開發的 – Hadoop、Spark、NoSQL數據庫、多種文件系統等等，所以這不會受限于人們所構建的平臺的特定部分。
有意思的是正如那句俗話“吃自家的狗食”所言，現在Canonical也在用LXC容器部署他們的Ubuntu OpenStack。這使得管理員能夠分步地升級OpenStack或者把部分負載從硬件上移走來發揮硬件的性能。Shuttleworth說，在一個典型的小規模OpenStack云中你可以用八臺管理節點來運行管理平臺的所有組件，而且你希望以一式三份的方式來運行它，這樣即使有你失去了一個節點，還能通過另外兩個來保持高可用。這就需要32臺物理服務器。通過把這些組件打包到LXC容器并通過LXD hypervisor進行管理，這些管理平臺的大部分組件都可以打包到同一個物理服務器上從而縮減了OpenStack管理平臺的物理服務器規模卻不會犧牲性能和可用性。
“程序員都追求簡潔而且他們喜歡保持事物有序和整潔。“Shuttleworth解釋道，”在某種程度上，只是因為硬件虛擬化的成本很高就不得不把程序部署到多個主機上已經成了一個痛點。現在，你可以立刻在一臺主機上運行多個程序而沒有這些開銷并且始終保持他們的原生態和隔離。很開心的是可以看到當LXD出現時是如何改變了他們的行為。它在感覺上很像一個虛擬機但是卻更加輕量”
談起LXC，Shuttleworth告訴我們”紅帽很難忽視我們而且他們最終把LXC加到了RHEL 7當中“，而Kirklan說盡管Canonical做了很多努力使得KVM管理工具libvirt支持LXC，但是libvirt的維護者還是專注于 KVM虛擬機而非容器。”所以他認為這事兒有點棘手。而Shuttleworth說：”紅帽一直以來想試圖把容器的想法曲解為輕量級的VM，因為他們在 KVM投入了大量的資金，而這就扭曲了他們的世界觀”
推動LXC和LXD普及的關鍵因素是這樣的一個事實，即企業(超大規模的)和高性能計算(HPC – High Performance Computing)中心里的大量負載都是運行在Linux之上，而且這些組織希望在遷移基礎架構的時候能夠保留這些應用程序。恰恰是這個需求使得 VMware成為企業數據中心領域60億美元的巨頭。
作為一個例證，Shuttleworth說Canonical已經與Intel和其他一些不具名的HPC中心在LXC容器基礎上利用LXD hypervisor以近乎裸機的性能來測試以前的仿真和建模代碼。”想一想這是怎樣的場景。現在一個超級計算機運行著管理員最喜歡的操作系統，而科學家們能夠獲得裸機的性能同時還可以訪問他們最熟悉的操作環境。這一切都得益于虛擬化而且兩者獲得了所期望的東西而沒有任何物理主機虛擬化帶來的困惑。
私有云先行，而后公有云
LXC和LXD都不需要使用OpenStack云控制器，但是在數據中心里這三者將極有可能要在一起配合。 Shuttleworth說根據OpenStack社區的最新統計，Ubuntu server支撐著全世界一半以上已安裝的OpenStack云而且它也占據了最大的OpenStack集群中百分之六十五的份額。Canonical的 Ubuntu OpenStack發行版本已經被沃爾瑪、AT&T、Verizon、NTT、彭博社及德國電信所采用 – 都是成功的大單。此外，上周在東京的OpenStack峰會上，Shuttleworth補充說他看到沒有一個在Ubuntu上運行OpenStack的企業客戶對LXD不感興趣，因為其經濟性和密度實在是太棒了。
總體而言，這些都是私有云的成功案例。Shuttleworth認為長期目標是使公有云服務商把LXC和LXD作為其基礎架構和平臺服務的基礎，但是要實現這個目標大多數公有云服務商可能要等到X86、Power及ARM服務器擁有虛擬化專用電路來為LXC和LXD提供與KVM、Xen或者 Hyper-V等同的硬件安全(當然，這和平臺有關)。當前，Linux社區能夠為LXC容器提供Linux內核內的安全防護，但是這對于云服務提供商而言是不夠的。至于這些功能合適會加入到至強、Opteron、Power和ARM芯片中還不得而知，而且Shuttleworth也沒有透漏 Canonical的硬件合作伙伴的路線圖。
京公網安備 11010502049343號