Ⅰ openstack 支持多大的內存
目前OpenStack支持的虛擬機宿主包括KVM,XEN，... 命名為Node1: CPU:Intel G530 2.4GHz 內存：2G DDR3 硬碟 500G 電腦2僅作為雲計算節....
Ⅱ openstack對象存儲可以使用哪些
最近在quora上有人提到一個問題，有關hadoop分布式文件系統和openstack對象存儲的不同。
問題原文如下：
「hdfs （hadoop分布式文件系統）和openstack對象存儲（openstack object storage）似乎都有著相似的目的：實現冗餘、快速、聯網的存儲。什麼樣的技術特性讓這兩種系統因而不一樣？這兩種存儲系統最終趨於融合是否大有意義？」
問題提出之後，很快有openstack的開發者進行了回復。本文在此摘抄了前兩名回復進行翻譯，以供各位參考。
排名第一的答案來自rackspace的openstack swift開發者chuck their：
雖然hdfs與openstack對象存儲（swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。
1. hdfs使用了中央系統來維護文件元數據（namenode，名稱節點），而在swift中，元數據呈分布式，跨集群復制。使用一種中央元數據系統對hdfs來說無異於單一故障點，因而擴展到規模非常大的環境顯得更困難。
2. swift在設計時考慮到了多租戶架構，而hdfs沒有多租戶架構這個概念。
3. hdfs針對更龐大的文件作了優化（這是處理數據時通常會出現的情況），swift被設計成了可以存儲任何大小 .....
Ⅲ OpenStack怎麼對接分布式存儲
OpenStack對接對象存儲的方式有很多，我們的OpenStack就是通過Glance、Cinder、Nova等組件對接元核雲的對象存儲，方便好用。
Ⅳ 全面認識openstack，它到底是什麼包含什麼
（1）官方的解釋相信大家都已經了解了，不了解也沒有關系。現在從常識的角度來給大家解釋和說明。
OpenStack是一個雲平台管理的項目，它不是一個軟體。這個項目由幾個主要的組件組合起來完成一些具體的工作。
OpenStack是一個旨在為公共及私有雲的建設與管理提供軟體的開源項目，OpenStack被公認作為基礎設施即服務（簡稱IaaS）資源的通用前端。
如果這些還不明白，那麼從另外的角度給大家介紹：
首先讓大家看下面兩個圖就很簡單明了了：
此圖為openstack的登錄界面
下面是openstack的一個管理界面
從這兩個圖，相信有一定開發經驗，就能看出openstack是什麼了。可以說他是一個框架，甚至可以從軟體的角度來理解它。如果不明白，就從傳統開發來講解。不知道你是否了解oa，erp等系統，如果不了解可以到網上去找，資料一大把。他和oa，erp有什麼不同。很簡單就是openstack是用做雲計算的一個平台，或則一個解決方案。它是雲計算一個重要組成部分。
上面對openstack有了一個感性的認識。
（2）openstack能幹什麼。
大家都知道阿里雲平台，網路雲平台，而阿里雲平台據傳說就是對openstack的二次開發。對於二次開發相信只要接觸過軟體的都會明白這個概念。不明白的自己網上去查一下。也就是說openstack，可以搭建雲平台，什麼雲平台，公有雲，私有雲。現在網路在招聘的私有雲工程師，應該就是這方面的人才。
（3）openstack自身都包含什麼
以下是5個OpenStack的重要構成部分：
l Nova – 計算服務
l Swift – 存儲服務
l Glance – 鏡像服務
l Keystone – 認證服務
l Horizon – UI服務
圖1 OpenStack基本構架
下圖展示了Keystone、Dashboard二者與其它OpenStack部分的交互。
下面詳細介紹每一個服務：
（一）OpenStack計算設施—-Nova Nova是OpenStack計算的彈性控制器。OpenStack雲實例生命期所需的各種動作都將由Nova進行處理和支撐，這就意味著Nova以管理平台的身份登場，負責管理整個雲的計算資源、網路、授權及測度。雖然Nova本身並不提供任何虛擬能力，但是它將使用libvirt API與虛擬機的宿主機進行交互。Nova通過Web服務API來對外提供處理介面，而且這些介面與Amazon的Web服務介面是兼容的。
功能及特點
l 實例生命周期管理
l 計算資源管理
l 網路與授權管理
l 基於REST的API
l 非同步連續通信
l 支持各種宿主：Xen、XenServer/XCP、KVM、UML、VMware vSphere及Hyper-V
OpenStack計算部件
l Nova彈性雲包含以下主要部分：
l API Server（nova-api）
l 消息隊列（rabbit-mq server）
l 運算工作站（nova-compute）
l 網路控制器（nova-network）
l 卷管理（nova-volume）
l 調度器（nova-scheler）
API伺服器（nova-api）
API伺服器提供了雲設施與外界交互的介面，它是外界用戶對雲實施管理的唯一通道。通過使用web服務來調用各種EC2的API，接著API伺服器便通過消息隊列把請求送達至雲內目標設施進行處理。作為對EC2-api的替代，用戶也可以使用OpenStack的原生API，我們把它叫做「OpenStack API」。
消息隊列（Rabbit MQ Server）
OpenStack內部在遵循AMQP（高級消息隊列協議）的基礎上採用消息隊列進行通信。Nova對請求應答進行非同步調用，當請求接收後便則立即觸發一個回調。由於使用了非同步通信，不會有用戶的動作被長置於等待狀態。例如，啟動一個實例或上傳一份鏡像的過程較為耗時，API調用就將等待返回結果而不影響其它操作，在此非同步通信起到了很大作用，使整個系統變得更加高效。
運算工作站（nova-compute）
運算工作站的主要任務是管理實例的整個生命周期。他們通過消息隊列接收請求並執行，從而對實例進行各種操作。在典型實際生產環境下，會架設許多運算工作站，根據調度演算法，一個實例可以在可用的任意一台運算工作站上部署。
網路控制器（nova-network）
網路控制器處理主機的網路配置，例如IP地址分配，配置項目VLAN，設定安全群組以及為計算節點配置網路。
卷工作站（nova-volume）
卷工作站管理基於LVM的實例卷，它能夠為一個實例創建、刪除、附加卷，也可以從一個實例中分離卷。卷管理為何如此重要？因為它提供了一種保持實例持續存儲的手段，比如當結束一個實例後，根分區如果是非持續化的，那麼對其的任何改變都將丟失。可是，如果從一個實例中將卷分離出來，或者為這個實例附加上卷的話，即使實例被關閉，數據仍然保存其中。這些數據可以通過將卷附加到原實例或其他實例的方式而重新訪問。
因此，為了日後訪問，重要數據務必要寫入卷中。這種應用對於數據伺服器實例的存儲而言，尤為重要。
調度器（nova-scheler）
調度器負責把nova-API調用送達給目標。調度器以名為「nova-schele」的守護進程方式運行，並根據調度演算法從可用資源池中恰當地選擇運算伺服器。有很多因素都可以影響調度結果，比如負載、內存、子節點的遠近、CPU架構等等。強大的是nova調度器採用的是可插入式架構。
目前nova調度器使用了幾種基本的調度演算法：
隨機化：主機隨機選擇可用節點；
可用化：與隨機相似，只是隨機選擇的范圍被指定；
簡單化：應用這種方式，主機選擇負載最小者來運行實例。負載數據可以從別處獲得，如負載均衡伺服器。
（二）OpenStack鏡像伺服器—-GlanceOpenStack鏡像伺服器是一套虛擬機鏡像發現、注冊、檢索系統，我們可以將鏡像存儲到以下任意一種存儲中：
本地文件系統（默認）
l OpenStack對象存儲
l S3直接存儲
l S3對象存儲（作為S3訪問的中間渠道）
l HTTP（只讀）
功能及特點
提供鏡像相關服務
Glance構件
l Glance控制器
l Glance注冊器
（三）OpenStack存儲設施—-Swift
Swift為OpenStack提供一種分布式、持續虛擬對象存儲，它類似於Amazon Web Service的S3簡單存儲服務。Swift具有跨節點百級對象的存儲能力。Swift內建冗餘和失效備援管理，也能夠處理歸檔和媒體流，特別是對大數據（千兆位元組）和大容量（多對象數量）的測度非常高效。
功能及特點
l 海量對象存儲
l 大文件（對象）存儲
l 數據冗餘管理
l 歸檔能力—–處理大數據集
l 為虛擬機和雲應用提供數據容器
l 處理流媒體
l 對象安全存儲
l 備份與歸檔
l 良好的可伸縮性
Swift組件
l Swift賬戶
l Swift容器
l Swift對象
l Swift代理
l Swift RING
Swift代理伺服器
用戶都是通過Swift-API與代理伺服器進行交互，代理伺服器正是接收外界請求的門衛，它檢測合法的實體位置並路由它們的請求。
此外，代理伺服器也同時處理實體失效而轉移時，故障切換的實體重復路由請求。
Swift對象伺服器
對象伺服器是一種二進制存儲，它負責處理本地存儲中的對象數據的存儲、檢索和刪除。對象都是文件系統中存放的典型的二進制文件，具有擴展文件屬性的元數據（xattr）。
注意：xattr格式被Linux中的ext3/4，XFS，Btrfs，JFS和ReiserFS所支持，但是並沒有有效測試證明在XFS，JFS，ReiserFS，Reiser4和ZFS下也同樣能運行良好。不過，XFS被認為是當前最好的選擇。
Swift容器伺服器
容器伺服器將列出一個容器中的所有對象，默認對象列表將存儲為SQLite文件（譯者註：也可以修改為MySQL，安裝中就是以MySQL為例）。容器伺服器也會統計容器中包含的對象數量及容器的存儲空間耗費。
Swift賬戶伺服器
賬戶伺服器與容器伺服器類似，將列出容器中的對象。
Ring（索引環）
Ring容器記錄著Swift中物理存儲對象的位置信息，它是真實物理存儲位置的實體名的虛擬映射，類似於查找及定位不同集群的實體真實物理位置的索引服務。這里所謂的實體指賬戶、容器、對象，它們都擁有屬於自己的不同的Rings。
（四）OpenStack認證服務（Keystone）
Keystone為所有的OpenStack組件提供認證和訪問策略服務，它依賴自身REST（基於Identity API）系統進行工作，主要對（但不限於）Swift、Glance、Nova等進行認證與授權。事實上，授權通過對動作消息來源者請求的合法性進行鑒定。如下圖所示：
Keystone採用兩種授權方式，一種基於用戶名/密碼，另一種基於令牌（Token）。除此之外，Keystone提供以下三種服務：
l 令牌服務：含有授權用戶的授權信息
l 目錄服務：含有用戶合法操作的可用服務列表
l 策略服務：利用Keystone具體指定用戶或群組某些訪問許可權
認證服務組件
服務入口：如Nova、Swift和Glance一樣每個OpenStack服務都擁有一個指定的埠和專屬的URL，我們稱其為入口（endpoints）。
l 區位：在某個數據中心，一個區位具體指定了一處物理位置。在典型的雲架構中，如果不是所有的服務都訪問分布式數據中心或伺服器的話，則也稱其為區位。
l 用戶：Keystone授權使用者
譯者註：代表一個個體，OpenStack以用戶的形式來授權服務給它們。用戶擁有證書（credentials），且可能分配給一個或多個租戶。經過驗證後，會為每個單獨的租戶提供一個特定的令牌。[來源：http://blog.sina.com.cn/s/blog_70064f190100undy.html]
l 服務：總體而言，任何通過Keystone進行連接或管理的組件都被稱為服務。舉個例子，我們可以稱Glance為Keystone的服務。
l 角色：為了維護安全限定，就雲內特定用戶可執行的操作而言，該用戶關聯的角色是非常重要的。
譯者註：一個角色是應用於某個租戶的使用許可權集合，以允許某個指定用戶訪問或使用特定操作。角色是使用許可權的邏輯分組，它使得通用的許可權可以簡單地分組並綁定到與某個指定租戶相關的用戶。
l 租間：租間指的是具有全部服務入口並配有特定成員角色的一個項目。
譯者註：一個租間映射到一個Nova的「project-id」，在對象存儲中，一個租間可以有多個容器。根據不同的安裝方式，一個租間可以代表一個客戶、帳號、組織或項目。
（五）OpenStack管理的Web介面—-Horizon
Horizon是一個用以管理、控制OpenStack服務的Web控制面板，它可以管理實例、鏡像、創建密匙對，對實例添加卷、操作Swift容器等。除此之外，用戶還可以在控制面板中使用終端（console）或VNC直接訪問實例。總之，Horizon具有如下一些特點：
l 實例管理：創建、終止實例，查看終端日誌，VNC連接，添加卷等
l 訪問與安全管理：創建安全群組，管理密匙對，設置浮動IP等
l 偏好設定：對虛擬硬體模板可以進行不同偏好設定
l 鏡像管理：編輯或刪除鏡像
l 查看服務目錄
l 管理用戶、配額及項目用途
l 用戶管理：創建用戶等
l 卷管理：創建卷和快照
l 對象存儲處理：創建、刪除容器和對象
l 為項目下載環境變數
Ⅳ 什麼是OpenStack
本文詳細介紹了Openstack的網路原理和實現，主要內容包括：Neutron的網路架構及網路模型還有neutron虛擬化的實現和對二三層網橋的理解。
一、Neutron概述
Neutron是一個用Python寫的分布式軟體項目，用來實現OpenStack中的虛擬網路服務，實現軟體定義網路。Neutron北向有自己的REST API，中間有自己的業務邏輯層，有自己的DB和進程之間通訊的消息機制。同時Neutron常見的進程包括Neutron-server和Neutron-agent，分布式部署在不同的操作系統。
OpenStack發展至今，已經經歷了20個版本。雖然版本一直在更替，發展的項目也越來越多，但是Neutron作為OpenStack三大核心之一，它的地位是不會動搖的。只不過當初的Neutron也只是Nova項目的一個模塊而已，到F版本正式從中剝離，成為一個正式的項目。
從Nova-Network起步，經過Quantum，多年的積累Neutron在網路各個方面都取得了長足的發展。其主要的功能為：
（1）支持多租戶隔離
（2）支持多種網路類型同時使用
（3）支持隧道技術（VXLAN、GRE）
（4）支持路由轉發、SNAT、DNAT技術
（5）支持Floating IP和安全組
多平面租戶私有網路
圖中同時有VXLAN和VLAN兩種網路，兩種網路之間互相隔離。租戶A和B各自獨佔一個網路，並且通過自己的路由器連接到了外部網路。路由器為租戶的每個虛擬機提供了Float IP，完成vm和外網之間的互相訪問。
二、Neutron架構及網路模型
1、Neutron架構
Neutron-sever可以理解為類似於nova-api那樣的一個專門用來接收API調用的組件，負責將不同的api發送到不同Neutron plugin。
Neutron-plugin可以理解為不同網路功能實現的入口，接收server發來的API，向database完成一些注冊信息。然後將具體要執行的業務操作和參數通知給對應的agent來執行。
Agent就是plugin在設備上的代理，接受相應的plugin通知的業務操作和參數，並轉換為具體的命令行操作。
總得來說，server負責交互接收請求，plugin操作資料庫，agent負責具體的網路創建。
2、Neutron架構之Neutron-Server
（1）Neutron-server的本質是一個Python Web Server Gateway Interface（WSGI），是一個Web框架。
（2）Neutron-server接收兩種請求：
REST API請求：接收REST API請求，並將REST API分發到對應的Plugin（L3RouterPlugin）。
RPC請求：接收Plugin agent請求，分發到對應的Plugin（NeutronL3agent）。
3、Neutron架構之Neutron-Plugin
Neutron-plugin分為Core-plugin和Service-plugin。
Core-plugin：ML2負責管理二層網路，ML2主要包括Network、Subnet、Port三類核心資源，對三類資源進行操作的REST API是原生支持的。
Service-plugin：實現L3-L7網路，包括Router、Firewall、VPN。
4、Neutron架構之Neutron-Agent
（1）Neutron-agent配置的業務對象是部署在每一個網路節點或者計算節點的網元。
（2）網元區分為PNF和VNF：
PNF：物理網路功能，指傳統的路由器、交換機等硬體設備
VNF：虛擬網路功能，通過軟體實現的網路功能（二層交換、三層路由等）
（3）Neutron-agent三層架構如下圖：
Neutron-agent架構分為三層，北向為Neutron-server提供RPC介面，供Neutron server調用，南向通過CLI協議棧對Neutron VNF進行配置。在中間會進行兩種模型的轉換，從RPC模型轉換為CLI模型。
5、Neutron架構之通信原理
（1）Neutron是OpenStack的核心組件，官網給出Neutron的定義是NaaS。
（2）Naas有兩層含義：
對外介面：Neutron為Network等網路資源提供了RESTful API、CLI、GUI等模型。
內部實現：利用Linux原生或者開源的虛擬網路功能，加上硬體網路，構建網路。
Neutron接收到API請求後，交由模塊WSGI進行初步的處理，然後這個模塊通過Python API調用neutron的Plugin。Plugin做了相應的處理後，通過RPC調用Neutron的Agent組件，agent再通過某種協議對虛擬網路功能進行配置。其中承載RPC通信的是AMQP server，在部署中常用的開源軟體就是RabbitMQ
6、Neutron架構之控制節點網路模型
控制節點沒有實現具體的網路功能，它對各種虛擬設備做管理配合的工作。
（1）Neutron：Neutron-server核心組件。
（2）API/CLI：Neutron進程通過API/CLI介面接收請求。
（3）OVS Agent：Neutron通過RPC協議與agent通信。
控制節點部署著各種服務和Neutron-server，Neutron-server通過api/cli介面接收請求信息，通過RPC和Agent進行交互。Agent再調用ovs/linuxbridge等網路設備創建網路。
7、Neutron架構之計算節點網路模型
（1）qbr：Linux Bridge網橋
（2）br-int：OVS網橋
（3）br-tun：OVS隧道網橋
（4）VXLAN封裝：網路類型的轉變
8、Neutron架構之網路節點網路模型
網路節點部署了Router、DHCP Server服務，網橋連接物理網卡。
（1）Router：路由轉發
（2）DHCP： 提供DNS、DHCP等服務。
（3）br-ex： 連接物理網口，連接外網
三、Neutron虛擬化實現功能及設備介紹
1、Neutron虛擬化實現功能
Neutron提供的網路虛擬化能力包括：
（1）二層到七層網路的虛擬化：L2（virtual Switch）、L3（virtual Router 和 LB）、L47（virtual Firewall ）等
（2）網路連通性：二層網路和三層網路
（3）租戶隔離性
（4）網路安全性
（5）網路拓展性
（6）REST API
（7）更高級的服務，包括 LBaaS，FWaaS，VPNaaS 等
2、Neutron虛擬化功能之二層網路
（1）按照用戶許可權創建網路：
Provider network：管理員創建，映射租戶網路到物理網路
Tenant network：租戶創建的普通網路
External network：物理網路
（2）按照網路類型：
Flat network：所有租戶網路在一個網路中
Local network：只允許在伺服器內通信，不通外網
VLAN network：基於物理VLAN實現的虛擬網路
VXLAN network：基於VXLAN實現的虛擬網路
3、Neutron虛擬化實現功能之租戶隔離
Neutron是一個支持多租戶的系統，所以租戶隔離是Neutron必須要支持的特性。
（1）租戶隔離三種含義：管理面隔離、數據面的隔離、故障面的隔離。
（2）不同層次租戶網路的隔離性
租戶與租戶之間三層隔離
同一租戶不同網路之間二層隔離
同一租戶同一網路不同子網二層隔離
（3）計算節點的 br-int 上，Neutron 為每個虛機連接 OVS 的 access port 分配了內部的 VLAN Tag。這種 Tag 限制了網路流量只能在 Tenant Network 之內。
（4）計算節點的 br-tun 上，Neutron 將內部的 VLAN Tag 轉化為 VXLAN Tunnel ID，然後轉發到網路節點。
（5）網路節點的 br-tun 上，Neutron 將 VXLAN Tunnel ID 轉發了一一對應的 內部 VLAN Tag，使得 網路流被不同的服務處理。
（6）網路節點的 br-int 上連接的 DHCP 和 L3 agent 使用 Linux Network Namespace 進行隔離。
4、Neutron虛擬化實現功能之租戶網路安全
除了租戶隔離以外 Neutron還提供數據網路與外部網路的隔離性。
（1）默認情況下，所有虛擬機通過外網的流量全部走網路節點的L3 agent。在這里，內部的固定IP被轉化為外部的浮動IP地址
（1）Neutron還利用Linux iptables特性，實現其Security Group特性，從而保證訪問虛機的安全性
（3）Neutron利用網路控制節點上的Network Namespace中的iptables，實現了進出租戶網路的網路防火牆，從而保證了進出租戶網路的安全性。
5、Neutron虛擬化設備
（1）埠：Port代表虛擬網路交換機上的一個虛擬交換機埠
虛擬機的網卡連接到Port上就會擁有MAC地址和IP地址
（2）虛擬交換機：Neutron默認採用開源的Openvswitch，
同時還支持Linux Bridge
（3）虛擬路由器VR：
- 路由功能
- 一個VR只屬於一個租戶，租戶可以有多個VR
- 一個VR可以有若干個子網
- VR之間採用Namespace隔離
四、Neutron網橋及二三層網路理解
1、Neutron-Local-Bridge
僅用於測試；網橋沒有與物理網卡相連VM不通外網。
圖中創建了兩個local network，分別有其對應的qbr網橋。Vm123的虛擬網卡通過tap連接到qbr網橋上。其中2和3屬於同一個network可以通信，1屬於另一個網路不能和23進行通信。並且qbr網橋不連物理網卡，所以說local網路虛擬機只能同網路通信，不能連通外網。
2、Neutron-Flat-Bridge
- Linux Bridge直接與物聯網卡相連
- 每個Flat獨佔一個物理網卡
- 配置文件添加響應mapping
Flat網路是在local網路的基礎上實現不同宿主機之間的二層互聯，但是每個flat network都會佔用一個宿主機的物理介面。其中qbr1對應的flatnetwork 連接 eth1 qbr2，兩個網路的虛機在物理二層可以互聯。其它跟local network類似。
3、Neutron-VLAN-Bridge
在基於linux bridge的vlan網路中，eht1物理網卡上創建了兩個vlan介面，1.1連接到qbr1網橋，1.2連接到了qbr2網橋。在這種情況下vm通過eth1.1或者eth1.2發送到eth1的包會被打上各自的vlan id。此時vm2和vm3屬於同一個network所以是互通的，vm與vm2和vm3不通。
4、Neutron-VXLAN-Bridge
這個是以Linux bridge作agent的Vxlan網路：
Vxlan網路比Vxlan網路多了個VXLAN隧道，在Openstack中創建好內部網路和實例後，agent就會在計算節點和網路節點創建一對vxlan vtep.組成隧道的兩個端點。
Vxlan連接在eth0網口。在網路節點多了兩個組件dhcp 和router，他們分別通過一對veth與qbr網橋連接在一起，多個dhcp和路由之間使用namesapce隔離，當vm產生ping包時，發往linux 網橋qbr1，通過網橋在vxlan12上封裝數據包，數據通過eth0網卡出計算節點到網路節點的eth0，在vxlan12解包。到達路由器之後經過nat地址轉換，從eth1出去訪問外網，由租戶網路到運營商網路再到外部網路。
5、Neutron-VLAN-OVS
與Linux bridge不同，openvswitch 不是通過eth1.1 eth1.2這樣的vlan介面來隔離不同的vlan，而是通過openvswitch的流表規則來指定如何對進出br-int的數據進行轉發，實現不同vlan的隔離。
圖中計算節點的所有虛擬機都連接在int網橋上，虛擬機分為兩個網路。Int網橋會對到來的數據包根據network的不同打上vlan id號，然後轉發到eth網橋,eth網橋直連物理網路。這時候流量就從計算節點到了網路節點。
網路節點的ehx int網橋的功能相似，多了一個ex網橋，這個網橋是管理提前創建好的，和物理網卡相連，ex網橋和int網橋之間通過一對patch-port相連，虛擬機的流量到達int網橋後經過路由到ex網橋。
6、Neutron-VXLAN-OVS
Vxlan的模型和vlan的模型十分相似，從表面上來看，他倆相比只有一個不同,vlan對應的是ethx網橋，而vxlan對應的是tun網橋。
在這里ethx和tun都是ovs網橋，所以說兩者的差別不是實現組件的差別而是組件所執行功能的差別，ethx執行的是普通二層交換機的功能，tun執行的是vxlan中的vtep的功能，圖中倆tun對應的介面ip就是vxlan的隧道終結點ip。所以說虛機的數據包在到達tun網橋之前是打的是vlan tag，而到達tun之後會發生網路類型的轉換，從vlan封裝為vxlan然後到達網路節點。而之前的vlan類型的網路，虛機數據包的類型一直都是vlan。
7、物理的二層與虛擬的二層（VLAN模式)
（1）物理的二層指的是：物理網路是二層網路，基於乙太網協議的廣播方式進行通信。
（2）虛擬的二層指的是：Neutron實現的虛擬網路也是二層網路（openstack的vm機所用的網路必須是大二層），也是基於乙太網協議的廣播方式進行通信，但毫無疑問的是該虛擬網路是依賴於物理的二層網路。
（3）物理二層+虛擬二層的典型代表：VLAN網路模式。
8、物理的三層與虛擬的二層（GRE模式與VXLAN模式）
（1）物理三層指的是：物理網路是三層網路，基於IP路由的方式進行通信。
（2）虛擬的二層指的是：Neutron實現的虛擬網路仍然是二層網路（openstack的vm機所用的網路必須是大二層），仍然是基於乙太網的廣播方式進行通信，但毫無疑問的是該虛擬機網路是依賴於物理的三層網路，這點有點類似於VPN的概念，根本原理就是將私網的包封裝起來，最終打上隧道的ip地址傳輸。
（3）物理三層+虛擬二層的典型代表：GRE模式與VXLAN模式。
Ⅵ Openstack和VMware Esxi的不同
首先遇到的坑是存儲問題
VMware ESxi是單機系統即便使用了NFS或者其他外接存儲設備，照樣是映射到了系統的某個路徑下。而OpenStack支持多種存儲方式，任何一種存儲都是用戶無關的，這看似方便的設定，其實意味著最終用戶根本不知道虛擬機的磁碟文件路徑保存在什麼位置，系統無法對文件直接操作。
處於保守考慮，整個項目第一期直接放棄了OpenStack的SAN/NFS/NAS這類共享存儲的設定，每一個主機只能使用自己的本地磁碟。這種考慮其實本質上是放棄了OpenStack的集群負載能力而保留那套僅存的API，為的是換取根Esxi相類似的拓撲結構。可事實上並沒有降低絲毫的復雜度，而且給日後又挖了一個不小的坑。
然後是虛擬機部署流程的問題
VMWare的所有solution的虛擬機部署流程根本上說就是一個傳統上買電腦裸機的過程：定製硬體、設置好啟動方式、光碟iso安裝操作系統、安裝配置完成交付用戶。而OpenStack的虛擬機部署流程更像一個廠商安裝的過程：定製硬體、通過現有的模板定製克隆一塊新的虛擬硬碟、掛裝硬碟到虛擬機、啟動系統完成配置、交付用戶。傳統上用戶說我有個iso想要裝台虛擬機這樣的過程根本不成立！而且對於我們使用的Havana版本OpenStack來說，沒有任何方式可以修改默認的啟動順序，啟動順序永遠是第一塊硬碟為空的情況下無限嘗試pxe網路啟動。
作為虛擬機來說，還有一個重要的用途是通過拷貝虛擬磁碟文件的方式大量克隆主機。這對於VMware來說，第一知道文件路徑；第二都是本地磁碟操作的模式來說真的非常方便，而且眾所周知的是VMware對這個拷貝過程做了大量的優化，允許用戶選擇僅拷貝一個體積很小繼承文件。但對於OpenStack來說，有現成的API可以將虛擬機直接轉換成模板，然後通過模板大量部署。可問題來了：盡管只用了本地存儲，OpenStack本質上是一個集群，很大的可能你虛擬機轉模板或者模板轉虛擬機的過程中需要跨主機之間通訊。動輒以10G計算的虛擬磁碟文件一下子就吃光了所有的網路帶寬和IO，讓這個過程變得極其難以預測。當然，你可以選擇共享存儲的方式優化OpenStack，表現上甚至於遠遠好於VMware 的終極解決方案Vcenter。但痛苦的是我們跳進了自己挖的坑……
接下來是網路問題
這一點上感覺其實OpenStack更適合大批量部署，OpenStack通過Neutron組件可以在虛擬機部署的同時就給虛擬機分配合適的IP並通過API返回給用戶，這個IP是在DHCP里與mac直接綁定的，這也就意味著只要虛擬機的DHCP沒有問題，它的IP是固定不變的。但傳統上VMware必須通過工作在虛擬主機上的插件獲取虛擬的IP，插件的前提是VMware願意提供而且要記得安裝，這對於很多妖孽的操作系統來說就呵呵了。由於脫胎於傳統的「裝機模式」Vmware似乎更推薦用戶手工指定IP或者通過外部網路的DHCP，而OpenStack更喜歡自己管理一套DHCP服務。
對於VMware VCenter支持的分布式交換機技術而言，盡管我有Vcenter的環境，但受軟體授權的限制並不支持，只能說說OpenStack集成了網路管理能力，支持Vlan切換和調整，但至少Exsi這個級別的產品，VMware提供的和OpenStack出入不大。但很明顯的是licence 的不同導致了VMware本身網路管理的差異化也不小。
各式各樣的細節問題
我們一路上碰到的各種不同之處
VMware允許用戶隨意的組合CPU/RAM/disk的配置，而OpenStack只允許用戶在多個預先設置的CPU/RAM/disk的配置（flavor）中多選一。
電源管理部分，真心說差異太大。比如VMWare的開機按鈕可以覆蓋任何其他按鈕事件，無論當時的狀態是暫停、掛起還是關機，直接開機；而OpenStack則需要對應到暫停、恢復和開機3個按鈕事件。
唯一標示的問題：VMware主機名和磁碟文件名是一一對應的，而OpenStack則不具備此特性。
控制台部分，OpenStack用noVNC的HTML5來實現控制台，而Vmware則是IE插件，兼容性你懂得。
OpenStack的各種各樣的bug
吐槽部分，作為開源軟體的軟肋，bug是最讓人頭疼的，何況作為復雜的OpenStack更是如此。隨便說幾個吧：
novnc，當時的版本在觸摸屏主機上滑鼠失效，鍵位混亂。
虛擬機在刪除網卡之後查看狀態照舊，每次必現（想像下一個上百個網卡的主機吧）。盡管作為一個虛擬機管理系統會造成很大困擾，但不影響使用。離奇的是刪除該問題主機後會報錯說嘗試刪除一個不存在的網卡。
主機信息中網卡的排序混亂，你可能用於無法從虛擬機狀態信息中得知那塊是eth0，哪個是eth1，排序規則完全看心情。
Ⅶ 分布式存儲技術與OpenStack有什麼關系
他們是一種相互關系，分布式存儲技術可以為openstack很好的解決存儲這塊的問題，而openstack和分布式存儲相結合能避免它對存儲這塊的缺陷，查看此鏈接，可以學習了解存儲與openstack關系 ，網頁鏈接
Ⅷ OpenStack選用哪種後端存儲系統比較好
和openstack融合度較好的就是ceph，國內大多數雲環境都使用ceph作為openstack的唯一後端存儲。國內使用ceph開發出分布式存儲系統的廠商有深圳元核雲、北京xsky等，性能都還不錯的。
Ⅸ 文件系統和OpenStack對象存儲有何不同
雖然HDFS與Openstack對象存儲（Swift）之間有著一些相似之處，但是這兩種系統的總體設計卻大不一樣。
1. HDFS使用了中央系統來維護文件元數據（Namenode，名稱節點），而在Swift中，元數據呈分布式，跨集群復制。使用一種中央元數據系統對HDFS來說無異於單一故障點，因而擴展到規模非常大的環境顯得更困難。
2. Swift在設計時考慮到了多租戶架構，而HDFS沒有多租戶架構這個概念。
3. HDFS針對更龐大的文件作了優化（這是處理數據時通常會出現的情況），Swift被設計成了可以存儲任何大小的文件。
4. 在HDFS中，文件寫入一次，而且每次只能有一個文件寫入；而在Swift中，文件可以寫入多次；在並發操作環境下，以最近一次操作為准。
5. HDFS用Java來編寫，而Swift用Python來編寫。
另外，HDFS被設計成了可以存儲數量中等的大文件，以支持數據處理，而Swift被設計成了一種比較通用的存儲解決方案，能夠可靠地存儲數量非常多的大小不一的文件。
排名第二的答案來自Joshua McKenty，他是美國宇航局Nebula雲計算項目的首席架構師，是OpenStack Nova軟體的早期開發者之一，目前是OpenStack項目監管委員會的成員，還是Piston.cc這家基於OpenStack的公司的創始人。
Chuck剛才詳細介紹了兩者的技術差異，但是沒有討論兩者可想而知的融合，OpenStack設計峰會上拋出了融合這個話題。簡而言之，HDFS被設計成可以使用Hadoop，跨存儲環境裡面的對象實現MapRece處理。對於許多OpenStack公司（包括我自己的公司）來說，支持Swift裡面的處理是路線圖上面的一個目標，不過不是每個人都認為MapRece是解決之道。
我們已討論過為HDFS編寫包裝器，這將支持OpenStack內部存儲應用編程介面（API），並且讓用戶可以針對該數據來執行Hadoop查詢。還有一個辦法就是在Swift裡面使用HDFS。但是這些方法似乎沒有一個是理想的。
OpenStack社區方面也在開展研究開發方面的一些工作，認真研究其他替代性的MapRece框架（Riak和CouchDB等）。
最後，現在有別的一些存儲項目，目前「隸屬於」OpenStack社區（SheepDog和HC2）。充分利用數據局部性，並且讓對象存儲變得「更智能」，這是預計會取得進步的一個領域。