openstack存儲
Ⅰ 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的網路原理和實現,主要內容包括: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,它到底是什麼包含什麼
(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融合度較好的就是ceph,國內大多數雲環境都使用ceph作為openstack的唯一後端存儲。國內使用ceph開發出分布式存儲系統的廠商有深圳元核雲、北京xsky等,性能都還不錯的。
Ⅳ OpenStack平台的資料庫和存儲節點怎麼做冗餘
OpenStack其實有三個與存儲相關的組件,這三個組件被人熟知的程度和組件本身出現時間的早晚是相符的,按熟悉程度排列如下:
Swift——提供對象存儲 (Object Storage),在概念上類似於Amazon S3服務,不過swift具有很強的擴展性、冗餘和持久性,也兼容S3 API
Glance——提供虛機鏡像(Image)存儲和管理,包括了很多與Amazon AMI catalog相似的功能。(Glance的後台數據從最初的實踐來看是存放在Swift的)。
Cinder——提供塊存儲(Block Storage),類似於Amazon的EBS塊存儲服務,目前僅給虛機掛載使用。
(Amazon一直是OpenStack設計之初的假象對手和挑戰對象,所以基本上關鍵的功能模塊都有對應項目。除了上面提到的三個組件,對於AWS中的重要的EC2服務,OpenStack中是Nova來對應,並且保持和EC2 API的兼容性,有不同的方法可以實現)
Ⅵ OpenStack怎麼對接分布式存儲
OpenStack對接對象存儲的方式有很多,我們的OpenStack就是通過Glance、Cinder、Nova等組件對接元核雲的對象存儲,方便好用。
Ⅶ 分布式存儲技術與OpenStack有什麼關系
他們是一種相互關系,分布式存儲技術可以為openstack很好的解決存儲這塊的問題,而openstack和分布式存儲相結合能避免它對存儲這塊的缺陷,查看此鏈接,可以學習了解存儲與openstack關系 ,網頁鏈接
Ⅷ openstack中,為什麼要分離存儲
增加額外持久化的空間。
非持久化存儲用來運行操作系統,Cinder用來增加額外持久化的空間,Swift用於保存鏡像和數據,也可用於大數據。
非持久存儲開始,也稱為臨時存儲。顧名思義,在OpenStack環境中使用虛擬機的用戶在虛擬機終止後將丟失關聯的磁碟。當租戶在OpenStack集群上啟動虛擬機時,Glance鏡像的一份拷貝會下載到計算節點上。此鏡像將作為Nova實例的第一個磁碟,它提供臨時存儲。一旦Nova實例終止,存儲在該磁碟上的所有內容都將丟失。
Ⅸ 如何構建OpenStack存儲雲
使用 OpenStack 實現雲計算和存儲
http://www.oschina.net/question/129540_69702
詳細可以參考這個,有圖解教程,希望可以幫到你