unitedstack市值

1. OpenStack部署都有哪些方式

OpenStack部署都有：

2. 同方有雲（北京）科技有限公司怎麼樣

簡介：UnitedStack有雲是一家OpenStack開源雲計算公司，為企業和雲服務商提供基於OpenStack的產品和開源服務。
法定代表人：程輝
成立時間：2013-01-21
注冊資本：2000萬人民幣
工商注冊號：110105015562773
企業類型：其他有限責任公司
公司地址：北京市海淀區王莊路1號院清華同方科技大廈D座17層1711-06號

3. openstack基金會是什麼組織

概述

OpenStack基金會是OpenStack的全球獨立家園，旨在推動OpenStack雲操作系統在全球的發展、傳播和使用。OpenStack基金會的目標是在全球范圍內服務開發者、用戶及整個生態系統，為其提供共享資源，以擴大OpenStack公有雲與私有雲的成長，從而幫助技術廠商選擇平台，助力開發者開發出行業最佳的雲軟體。

OpenStack基金會它是一家非盈利組織，在2012年成立，SUSE的行業創新總監Alan Clark擔任OpenStack基金會主席這一要職。OpenStack基金會分為個人會員和企業會員兩大類。OpenStack基金會個人會籍是免費無門檻的，他們可憑借技術貢獻或社區建設工作等參與到OpenStack社區中。而公司參與的會根據各司贊助會費的情況，分成白金會員、黃金會員、企業贊助會員以及支持組織者，其中白金和黃金會員的話語權最大，目前，OpenStack基金會的董事會有兩名成員是來自於中國的公司，而整個基金會中黃金會員級別的公司中中國企業已經占據到3家，他們分別是華為、EasyStack和UnitedStack有雲。

董事會成員選拔

OpenStack基金會董事成員包括24位，白金會員在董事會里的8名席位是固定的，不用參與競選，而剩餘的16位將是競選得出，其中的8位要在所有黃金會員里進行角逐，方式是由黃金會員們在1天內投票決定，並且不對社區進行公開。另外的8位被稱作個人獨立董事，他們是由千萬社區個人會員經過1周投票最終決定的。席位在基金會董事會里是可以影響OpenStack發展和建設方向的，重要性不言而喻，所以這也就成為了企業們對會員級別和董事會席位趨之若鶩的原因。

基金會企業會員的劃分

說完了董事會成員的劃分，再來看看企業會員都有誰，准確來講，OpenStack基金會只允許最多8家白金會員資格和24家黃金會員資格。

白金會員僅限的8個席位已被AT&T、Canonical、惠普、IBM、英特爾、Rackspace、紅帽和SUSE這8家囊括。

而黃金會員僅限24個席位，如下圖所示包括了Aptira、CCAT、思科、戴爾、DreamHost、EasyStack、EMC、愛立信、富士通、日立、華為、inwinStack、Juniper Networks、Mirantis、NEC、NetApp、賽門鐵克，UnitedStack 以及Virtuozzo這19家，目前尚有5個空缺位置。

OpenStack基金會主席Alan Clark告訴我們，社區對於個人會員而言是非常開放的，基本上向任何人敞開。但如果想要成為金牌會員的話，那麼就必須要通過一系列的標准對後備公司進行審核，並且必須經由基金會、董事會成員批准。考核的首要一點就是要看他們是否對OpenStack社區做出了貢獻。

4. 雲宏CNware和戴爾什麼關系

戴爾與雲宏攜手合作，為客戶提供更高安全級別的混合雲解決方案。
雙方整合在基礎架構平台以及軟體方面的各自優勢，推出以「宏雲+」為品牌的一體機方案。
戴爾擬把雲宏信息虛擬化產品cnware列入其主要的國產第三方虛擬化軟體合作品牌，進行伺服器的捆綁銷售，以進一步增強其伺服器銷售優勢。
合作將為包括政府、金融在內的各行業客戶帶來可靠的安全保障。

5. UnitedStack會成為OpenStack圈剩下的那個嗎

近一年來，筆者幾乎與OpenStack圈的各個重要玩家都接觸過，創業公司像UnitedStack、EasyStack、AWCloud、99Cloud，傳統IT公司如IBM、華為、惠普。
誰家最好呢？用那句廣告詞來講是「沒有最好，只有更好」。誰更好呢？恐怕沒人能說清。技術方向上，各有優劣、各有側重;客戶層面，誰家都有不少拿得出手的客戶案例。所以如果你想考慮OpenStack，還是別糾結這些了，還不如認真考慮下誰最終會成為OpenStack領域那最後的佼佼者，因為這很重要。

6. ceph是採用kvm虛擬化技術嗎

OpenStack和CloudStack的對比
1）歷史背景和概況
OpenStack由NASA和Rackspace公司在2010年聯合發布，兩者分別貢獻計算代碼（Nova）和存儲代碼（Swift），以Apache許可協議進行授權。OpenStack的目標是提供一個既可以用來建設公有雲也能建設私有雲的通用的開源雲計算平台，而且做到雲平台的搭建盡量的簡單方便，同時能夠快速的橫向擴展。OpenStack獨立於任何企業，遵循開源、開放設計、開放開發流程和開放社區的理念，完全由社區主導和維護。OpenStack的發布周期是半年，到目前為止已經發布8個正式版本，最新的版本是Havana，在每個版本發布之後社區都會舉行一次峰會，來自世界各地的公司和開發者一起討論下一個版本的設計，同時進行OpenStack相關的技術分享，值得一提的是，最近的一次峰會在中國的香港舉行。
CloudStack最初由Cloud.com公司開發，分為商業和開源兩個版本，開源版本通過GPLv3（GNU General Public License, version 3）許可協議進行授權，Citrix公司在2011年收購Cloud.com後，將全部代碼開源，並在2012年將CloudStack貢獻給Apache軟體基金會，成為Apache的孵化項目，同時將授權協議改為更加寬松開放和商業友好的Apache許可協議，CloudStack在2013年3月份升級為Apache的正式項目。CloudStack的目標是提供高度可用的、高度可擴展的能夠進行大規模虛擬機部署和管理的開放雲平台。CloudStack的發布周期並不固定，目前最新的版本是4.2，社區每年會舉行一次全球協作會議（CloudStack Collaboration Conference）進行技術分享和交流。
2）平台架構
OpenStack採用分布式架構，整個平台按照功能不同分為多個模塊項目，如圖2所示，項目之間通過消息隊列中間件和RESTful形式的API進行交互通信（其中認證項目為其它項目提供認證和服務注冊），因此每個項目都可以單獨部署在不同的主機上，架構非常的靈活，OpenStack對外提供豐富和功能強大的API，使得資源可以被用戶方便的使用和調度，同時提供和Amazon AWS（Amazon Web Services）兼容的API。

圖2、OpenStack分布式架構圖
CloudStack採用集中式的單體架構（Monolithic architecture），如圖3所示，整個平台只有一個項目構成，不同模塊之間通過的本地調用進行交互，在一台主機上就可以完成平台的部署，非常方便，CloudStack同樣地對外提供自身API和與Amazon AWS相兼容的API。

圖3、CloudStack集中式架構圖
可以看到兩者的架構幾乎是相對的，OpenStack的分布式架構靈活性好，不同的項目可以單獨部署，因此可以很容易的根據實際需要進行功能組合，並且由於不同的項目間耦合性低，項目間功能劃分明確，因此針對單獨功能進行定製開發也非常方便，缺點是部署麻煩，每個項目都要部署配置一遍；CloudStack因為只有一個項目，所以部署起來會相對容易很多，然而平台的擴展性就要相對弱一些。
3）平台整體比較
OpenStack和CloudStack的功能對比如表1所示，我們從授權協議、支持的底層技術和用戶群等不同方面對兩者進行了比較。

OpenStack

CloudStack

授權協議

Apache 2.0，可以免費商用

Apache 2.0，可以免費商用

虛擬化技術

XenServer/XCP,KVM,QEMU，
LXC,VMware ESXi/vCenter,Hyper-V Baremetal,Docker,Xen/Libvirt

XenServer,KVM,QEMU,
VMware vCenter ,LXC

網路服務

VLAN,Flat,FlatDHCP
Quantum虛擬化網路

VLAN,Flat,OpenFlow

存儲支持

iSCSI,Ceph,NFS,LVM,Swift,Sheepdog

NFS,LVM,Ceph,Swift

調度策略

模型全面，易擴展

模型簡單，可擴展

用戶界面

功能完善，界面簡單

功能完善，界面友好

資料庫

PostgreSQL,MySQL,SQLite

MySQL

虛擬機模板

支持

支持

組件

Nova,Glance,Keystone,
Horizon,Swift,Cinder,
Quantum,Heat,Ceilometer

Console Proxy VM,
Second Storage VM,
Virtual Router VM,
Host Agent,Management Server

開發主導

開源社區

Citrix公司

開發語言

Python

Java

官方文檔

非常詳細

詳細

版本問題

存在版本兼容性問題

不存在版本兼容性問題

用戶群

160家左右，包括NASA、
RedHat、Rackspace、HP、
網易、UnitedStack等

不到60家，包括諾基亞、
日本電話電報公司、Zynga、
阿爾卡特、迪斯尼等

表1、OpenStack與CloudStack 比較
4）平台選擇
經過前面的比較分析我們能夠獲得這樣的結論，OpenStack和CloudStack都是功能強大的開源雲平台，滿足企業私有雲建設的需求，並且因為開放開源，都可以根據需要進行定製。不同的是CloudStack因為是從商業軟體開源出來的，所以對企業來說會更容易上手，在雲平台構建時會比較方便，然而同樣因為其帶有商業軟體屬性，平台架構比較集中，模塊間耦合度比較高，因此擴展性不是太好，同時二次開發的成本較高；OpenStack自誕生之初就是開源軟體，並採用分布式的架構，所有的開發都是由社區承擔，不同的項目之間幾乎沒有耦合，所以可以方便的進行開發定製，然而因為其有多個項目組成，每個項目都要單獨安裝，並且要保證項目間的協作，所以部署會比較麻煩，另外由於OpenStack處於高速發展階段，不同版本之間項目可能會有較大的變動，因此版本間的升級會比較困難。
另外值得一提的是，OpenStack和CloudStack雖然都對VMware的ESXi虛擬化技術提供支持，但支持方式是不一樣的，如圖4所示。CloudStack要經過vCenter才可以實現對ESXi宿主機上虛擬機的管理；而OpenStack支持直接和ESXi通信，實現對虛擬機的基本管理，只有高級功能才需要vCenter的支持。針對目前中小企業普遍採用VMware的免費虛擬化技術而沒有vCenter的現狀，這也是在平台選擇時需要考慮的。

圖4、VMware ESXi管理方式對比圖
恆天雲採用OpenStack開源平台進行私有雲建設，因為OpenStack架構非常開放，方便定製開發，並且擁有眾多技術廠商的支持，非常有可能成為雲計算IaaS平台領域的Linux，所以通過對OpenStack定製開發，積累雲計算的技術能力，從長遠來看對企業也是非常有益的。

7. Openstack 最多支持多少主機

從目前現有的公司，如unitedstack等的部署經驗來看，物理機千台到萬台左右的規模是沒有問題的。虛擬機與物理機的比例大概是1:10左右。虛擬機規模可達十萬的量級。更大規模的openstack，尚未有成功部署樣例。

8. 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去修改的。