㈠ 雲存儲的底層關鍵技術有哪些
一切以客戶的需求為出發點。傳統存儲以文件系統為典型代表，但是隨著數據爆炸性增長，傳統文件系統已經無法滿足對存儲系統的容量、性能等需求，因此，雲存儲應運而生。雲存儲最大的特點是數據被集中存儲在數據中心，公有雲存儲將客戶數據存放在公有雲服務商數據中心，而私有雲存儲則是將公有雲存儲能力私有化部署在客戶自身的數據中心。既然提到了數據中心，可想而知雲存儲最大的特點應該是海量：解決數以PB至EB的數據存儲需求。所有雲存儲技術面對的通用問題有如下幾個：
擴展性：即容量可以通過橫向增加伺服器、磁碟等線性擴展，軟體不應該成為限制擴展性的瓶頸；
可靠性：如何保證數據不丟失，或者丟失概率極低；
可用性：如何保證數據always online；
性能：不同的客戶的不同使用場景對雲存儲性能提出不同需求。
㈡ 如何在AWS S3存儲段中設置CloudFront分布
AWS CloudFront是一個用戶用於加速靜態或動態內容發布的內容發布服務，這里所謂的靜態或動態內容主要包括媒體（圖像或視頻）文件、HTML、Java腳本程序、CSS文件以及其它。
作者：文:Ofir Nachmani 譯:滕曉龍來源：TechTarget中國|2015-03-09 10:12
收藏
分享
AWS CloudFront可配合一些其他的服務一起使用，其中就包括了EC2和S3。遵循以下步驟可從一個S3存儲段中設置一個CloudFront分布。
AWS CloudFront是一個用戶用於加速靜態或動態內容發布的內容發布服務，這里所謂的靜態或動態內容主要包括媒體（圖像或視頻）文件、HTML、Java腳本程序、CSS文件以及其它。它的簡潔用戶界面可以幫助管理員設置CloudFront發布。但是，這一過程並不只是指向和點擊那麼簡單。下面，就讓我們來看看CloudFront的工作原理以及應當如何來部署它。
在CloudFront中，每一片的內容都被組織成為具有獨特URL並可從網路被訪問的發布。該服務可從邊緣加速節點數據中心發布這一內容；目前，AWS在全球部署著52個邊緣加速節點數據中心以供內容緩存使用。
AWS CloudFront支持兩種形式的發布：流形式與下載方式。當一名用戶使用CloudFront URL來請求靜態內容時，該服務就會根據發出請求的IP以及緩存這一內容的數據中心的位置來找到距離這個IP最近的邊緣加速節點數據中心。這樣一來，所有來自於相同位置的請求就會減少延遲時間。
CloudFront可配合多個AWS服務使用，其中包括了簡單存儲服務（S3）、彈性計算雲（EC2）、彈性負載平衡（ELB）以及Route 53。CloudFront的主要功能包括：
支持動態內容（減少未來請求的延遲時間）
支持自定義域名
設備檢測（移動設備和網路設備）
支持Post/PUT以及其它的HTTP協議
自定義錯誤響應
支持cookies、查詢字元串以及其它
鏈接一個CloudFront發布至S3
為了從一個S3建立一個CloudFront網路發布，你將需要一個S3存儲和一個可公開訪問的對象（如圖1）。
圖1 S3存儲段以及一個可公開訪問的對象
然後，可遵循以下步驟：
1. 轉至CloudFront並創建一個網路發布
圖2 選擇初始域名存儲段
2. 在初始域名欄位，選擇存儲段名稱，並在限制存儲段訪問中選擇「No」。這樣做可以限制只能從CloudFront訪問對象，所以就沒有人可以從S3訪問這個存儲段了（如圖2）。
3. 使用以下參數配置緩存設置：
路徑模式：默認。針對特定對象應用緩存處理。如果選擇了默認值（*），它就會把所有請求發送到選中的存儲段中。
瀏覽器協議策略：HTTP 和 HTTPS。如果用戶想要求CloudFront允許瀏覽器使用HTTP或HTTPS協議來訪問用戶的網路內容。
允許的HTTP方法：GET，HEAD。選擇用戶希望這一緩存操作所允許的HTTP方法列表。
轉發頭文件：None。如果用戶希望根據請求中發送的頭文件來緩存內容，那麼就可以使用它。理想情況下，保持「None」項是可以提高性能的。
對象緩存：使用初始緩存頭文件。當你的初始伺服器將增加一個緩存控制頭文件以便於控制對象被保存在CloudFront緩存中多長時間時，可選擇這一選項。
轉發cookies：無。如果用戶希望CloudFront在它發送給初始伺服器的請求中囊括所有的用戶cookies，那麼就可以指定「None」。否則，可指定你希望包含在內的cookies。選擇「None」，就可配置CloudFront不要發送cookies。
轉發請求字元串：不。為了根據URL中的請求字元串獲得不同版本的對象；設置「Yes」選項以便於在發送給初始伺服器的請求URL中包含請求字元串。
限制瀏覽器訪問：No。在理想情況下，選擇「yes」以提高安全性。選擇「no」可讓每個人都能夠查看內容。限制瀏覽器訪問意味著要求使用者為安全訪問而創建一個簽名的URL（如圖3）。
圖3 限制瀏覽器訪問
4. 接下來，是設定發布設置
價格類別：使用所有的邊緣加速節點數據中心。這一操作可以讓用戶自行選擇願意為CloudFront服務支付的最高價格。
CNAMEs：空白。這一操作可以允許用戶為對象使用URL而不是CloudFront分配的域名。因此，用戶可以指定一個自定義URL，而不是CloudFront發布。
SSL證書：默認CloudFront。這一項可以讓管理員上傳他們自己的證書。用戶還可以保留其它的選項作為默認值，並創建發布（如圖4）。
圖4默認的CloudFront設置。
一旦創建了發布，那麼你將有一個CloudFront URL，例如："http://d3ptzllcr53x1i.CloudFront.net＂。然後，就可以使用這個URL來訪問對象了。
㈢ 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的兼容性，有不同的方法可以實現）
三個組件中，Glance主要是虛機鏡像的管理，所以相對簡單；Swift作為對象存儲已經很成熟，連CloudStack也支持它。Cinder是比較新出現的塊存儲，設計理念不錯，並且和商業存儲有結合的機會，所以廠商比較積極。
Swift
關於Swift的架構和部署討論，除了官方網站，網上也有很多文章，這里就不重復.(也可以參考我之前在OpenStack中國行活動中上海站演講的PPT)。從開發上看，最近也沒有太大的結構性調整，所以我想主要說說比較適用的應用領域好了。
從我所了解的實際案例來看，Swift出現的領域有4個，(應該還有更多，希望大家看到實際用例能夠指教)
1.網盤。
Swift的對稱分布式架構和多proxy多節點的設計導致它從基因里就適合於多用戶大並發的應用模式，最典型的應用莫過於類似Dropbox的網盤應用，Dropbox去年底已經突破一億用戶數，對於這種規模的訪問，良好的架構設計是能夠支撐的根本原因。
Swift的對稱架構使得數據節點從邏輯上看處於同級別，每台節點上同時都具有數據和相關的元數據。並且元數據的核心數據結構使用的是哈希環，一致性哈希演算法對於節點的增減都只需重定位環空間中的一小部分數據,具有較好的容錯性和可擴展性。另外數據是無狀態的，每個數據在磁碟上都是完整的存儲。這幾點綜合起來保證了存儲的本身的良好的擴展性。
另外和應用的結合上，Swift是說HTTP協議這種語言的，這使得應用和存儲的交互變得簡單，不需要考慮底層基礎構架的細節，應用軟體不需要進行任何的修改就可以讓系統整體擴展到非常大的程度。
2.IaaS公有雲
Swift在設計中的線性擴展，高並發和多租戶支持等特性，使得它也非常適合做為IaaS的選擇，公有雲規模較大，更多的遇到大量虛機並發啟動這種情況，所以對於虛機鏡像的後台存儲具體來說，實際上的挑戰在於大數據（超過G）的並發讀性能，Swift在OpenStack中一開始就是作為鏡像庫的後台存儲，經過RACKSpace上千台機器的部署規模下的數年實踐，Swift已經被證明是一個成熟的選擇。
另外如果基於IaaS要提供上層的SaaS 服務，多租戶是一個不可避免的問題，Swift的架構設計本身就是支持多租戶的，這樣對接起來更方便。
3.備份歸檔
RackSpace的主營業務就是數據的備份歸檔，所以Swift在這個領域也是久經考驗，同時他們還延展出一種新業務--「熱歸檔」。由於長尾效應，數據可能被調用的時間窗越來越長，熱歸檔能夠保證應用歸檔數據能夠在分鍾級別重新獲取，和傳統磁帶機歸檔方案中的數小時而言，是一個很大的進步。
4. 移動互聯網和CDN
移動互聯網和手機游戲等產生大量的用戶數據，數據量不是很大但是用戶數很多，這也是Swift能夠處理的領域。
至於加上CDN，如果使用Swift，雲存儲就可以直接響應移動設備，不需要專門的伺服器去響應這個HTTP的請求，也不需要在數據傳輸中再經過移動設備上的文件系統，直接是用HTTP 協議上傳雲端。如果把經常被平台訪問的數據緩存起來，利用一定的優化機制，數據可以從不同的地點分發到你的用戶那裡，這樣就能提高訪問的速度，我最近看到Swift的開發社區有人在討論視頻網站應用和Swift的結合，竊以為是值得關注的方向。
Glance
Glance比較簡單，是一個虛機鏡像的存儲。向前端nova（或者是安裝了Glance-client的其他虛擬管理平台）提供鏡像服務，包括存儲，查詢和檢索。這個模塊本身不存儲大量的數據，需要掛載後台存儲（Swift，S3。。。）來存放實際的鏡像數據。
Glance主要包括下面幾個部分：
l API service： glance-api 主要是用來接受Nova的各種api調用請求，將請求放入RBMQ交由後台處理，。
l Glacne-registry 用來和MySQL資料庫進行交互，存儲或者獲取鏡像的元數據，注意，剛才在Swift中提到，Swift在自己的Storage Server中是不保存元數據的，這兒的元數據是指保存在MySQL資料庫中的關於鏡像的一些信息，這個元數據是屬於Glance的。
l Image store： 後台存儲介面，通過它獲取鏡像，後台掛載的默認存儲是Swift，但同時也支持Amazon S3等其他的鏡像。
Glance從某種角度上看起來有點像虛擬存儲，也提供API，可以實現比較完整的鏡像管理功能。所以理論上其他雲平台也可以使用它。
Glance比較簡單，又限於雲內部，所以沒啥可以多展開討論的，不如看看新出來的塊存儲組件Cinder，目前我對Cinder基本的看法是總體的設計不錯，細節和功能還有很多需要完善的地方，離一個成熟的產品還有點距離。
Cinder
OpenStack到F版本有比較大的改變，其中之一就是將之前在Nova中的部分持久性塊存儲功能（Nova-Volume）分離了出來，獨立為新的組件Cinder。它通過整合後端多種存儲，用API介面為外界提供塊存儲服務，主要核心是對卷的管理，允許對卷，卷的類型，卷的快照進行處理。
Cinder包含以下三個主要組成部分
API service：Cinder-api 是主要服務介面, 負責接受和處理外界的API請求，並將請求放入RabbitMQ隊列，交由後端執行。 Cinder目前提供Volume API V2
Scheler service: 處理任務隊列的任務，並根據預定策略選擇合適的Volume Service節點來執行任務。目前版本的cinder僅僅提供了一個Simple Scheler, 該調度器選擇卷數量最少的一個活躍節點來創建卷。
Volume service: 該服務運行在存儲節點上，管理存儲空間，塔處理cinder資料庫的維護狀態的讀寫請求，通過消息隊列和直接在塊存儲設備或軟體上與其他進程交互。每個存儲節點都有一個Volume Service，若干個這樣的存儲節點聯合起來可以構成一個存儲資源池。
Cinder通過添加不同廠商的指定drivers來為了支持不同類型和型號的存儲。目前能支持的商業存儲設備有EMC 和IBM的幾款，也能通過LVM支持本地存儲和NFS協議支持NAS存儲，所以Netapp的NAS應該也沒問題，好像華為也在努力中。我前段時間還在Cinder的blueprints看到IBM的GPFS分布式文件系統，在以後的版本應該會添加進來
到目前為止，Cinder主要和Openstack的Nova內部交互，為之提供虛機實例所需要的卷Attach上去，但是理論上也可以單獨向外界提供塊存儲。
部署上，可以把三個服務部署在一台伺服器，也可以獨立部署到不同物理節點
現在Cinder還是不夠成熟，有幾個明顯的問題還沒很好解決，一是支持的商業存儲還不夠多，而且還不支持FC SAN，另外單點故障隱患沒解決，內部的schele調度演算法也太簡單。另外由於它把各種存儲整合進來又加了一層，管理倒是有辦法了，但是效率肯定是有影響，性能肯定有損耗，但這也是沒辦法的事了。
Openstack通過兩年多發展，變得越來越龐大。目前光存儲就出現了三種：對象存儲、鏡像存儲和塊存儲。這也是為了滿足更多不同的需求，體現出開源項目靈活快速的特性。總的說來，當選擇一套存儲系統的時候，如果考慮到將來會被多個應用所共同使用，應該視為長期的決策。Openstack作為一個開放的系統，最主要是解決軟硬體供應商鎖定的問題，可以隨時選擇新的硬體供應商，將新的硬體和已有的硬體組成混合的集群，統一管理，當然也可以替換軟體技術服務的提供商，不用動應用。這是開源本身的優勢！
㈣ 公有雲的雲存儲好在哪裡
公有雲的雲存儲，現在一般都是網盤服務，有私人的有企業的。雲存儲的最大特點是擴容方便，因為雲具有可擴展性。公有雲雲存儲的特點主要是維護不用自己管，大服務商的安全性比自建系統要高很多，速度快，更新快，功能全，隨處都可以訪問，任何終端都可以訪問，還有很多介面供開發利用。目前私人網盤管理的比較嚴，一般不能發外鏈，共享是個問題。企業網盤功能比較全，聯想、搜狐、開普雲都有，費用也不算高，好像開普雲還有免費的服務。
㈤ 公有雲與私有雲的區別
「公有雲」和「私有雲」其本質都是一種能提供更好服務的存儲架構技術，但他們卻有著明顯的差別，最顯著差別在於對數據的掌控。接下來優炫軟體帶你看看這兩朵「雲」都有那些區別。
在正式開講前，我們先來了解一下「公有雲」和「私有雲」的定義：
1、公有雲（PublicClouds）：
「公有」反映了這類雲服務並非用戶所擁有，公有雲是面向大眾提供計算資源的服務。是由IDC服務商或第三方提供資源，如應用和存儲，這些資源是在服務商的場所內部署。用戶通過Internet互聯網來獲取這些資源的使用。公有雲服務提供商有Amazon、Google和微軟，以及國內的阿里雲、騰訊雲、百悟雲等。
公有雲的優勢是成本低，擴展性非常好。缺點是對於雲端的資源缺乏控制、保密數據的安全性、網路性能和匹配性問題。
2、私有雲（PrivateClouds）：
私有雲是企業傳統數據中心的延伸和優化，能夠針對各種功能提供存儲容量和處理能力。「私有」更多是指此類平台屬於非共享資源，而非指其安全優勢。私有雲是為了一個客戶單獨使用而構建的，所以這些數據、安全和服務質量都較公有雲有著更好地保障。而私有雲由於是客戶獨享，則用戶擁有著構建雲的基礎設置，並可以控制在此技術設置上部署應有程序的方式。
在私有雲模式中，雲平台的資源為包含多個用戶的單一組織專用。私有雲可由該組織、第三方或兩者聯合擁有、管理和運營。私有雲的部署場所可以是在機構內部，也可以在外部。
通過定義我們可以看出，私有雲構築一個公司企業數據中心內的專用雲。而公有雲則是針對外部客戶，通過網路方式提供可擴展的彈性服務。在選擇公有雲還是私有雲時，根據用戶自身的需求各有偏重。
除了應用場景， 「安全」是首要關心的問題，因為對於任何的業務來說安全無疑是最基本的要求。畢竟大數據時代，企業信息就是企業的生命。
採用公有雲辦公的企業必需將數據託管於雲辦事商的數據中心，企業對數據的掌控力度自然減弱。一旦數據中心因自然災害、報答因素或法律規范等各方面因素導致數據丟失，將對企業或政府機構形成致命傷害。
私有雲在數據安全、數據備份等方面具有更多的可選擇空間。公有雲當然也具備數據安全辦事和數據備份能力，但企業對此的控制力度較差，不處於主導地位。
㈥ MicroFocus的Data Protector支持阿里雲和騰訊雲的對象存儲嗎
MicroFocus的Data Protector支持國內公有雲的S3介面的對象存儲。
㈦ 新一代私有雲是什麼私有雲有什麼價值與意義
私有雲是什麼？
參照維基網路定義：
私有雲（Private cloud）是將雲基礎設施與軟硬體資源建立在防火牆內，以供機構或企業內各部門共享數據中心內的資源。私有雲完全為特定組織而運作的雲端基礎設施，管理者可能是組織本身，也可能是第三方；位置可能在組織內部，也可能在組織外部。
3大私有雲主流落地方案，超融合正成為構建新一代私有雲「基石」的主流方案
目前主流企業級私有雲落地方案主要有以下三種，下面逐一介紹，並講解其各自特點：
將AWS、Azure、阿里雲等商業公有雲方案全套落地到私有環境；
使用類似 OpenStack、Ceph 等開源軟體構建私有雲；
使用類似 VMware、SmartX、Nutanix 等虛擬化或超融合產品配合 CMP 組件等成熟的商業組件構建私有雲。
一個有趣的現象是，由於 HCI 架構為私有雲帶來的諸多優勢，方式 1、2 也都衍生了基於超融合架構的落地方案，超融合正成為構建新一代私有雲「基石」的主流方案。以下逐一介紹。
公有雲移植構建私有雲
將公有雲移植到企業數據中心，方案最大的優勢是它來自於公有雲成功經驗，並經過長時間，大規模營運的考驗，擁有比較全面的功能，以 AWS 為例展示其落地方案及架構。
在資源池的構建上方式上，以往 VMware vSpere 、FC 網路、FC SAN 存儲傳統三層式架構占據統治地位，但超融合方案正在越來越多地替換原有的架構。VMware、SmartX、等主流超融合廠商配合成熟的商用 CMP 產品都提供了諸多基於超融合架構的私有雲案例。相比於以上兩種方案，該落地方案具有獨特的特點：
1.相比於公有雲廠商以及全棧的私有雲方案，該方案具備更好的開放性，更靈活輕量；
2. 相比於基於的開源產品，該方案穩定簡單，具備真正「生產就緒「能力。
私有雲有什麼價值與要求？
公有雲用戶只需關注資源使用和付費，私有雲不僅要求資源交付上需具備可擴展、彈性的能力，更大的挑戰還來自於：整體方案從規劃、部署到交付、運維各個環節都需要符合以下核心要求：
按需投資：可以根據業務實際需要進行不同層面以及不同規模的按需投資。例如 IaaS 層和 PaaS 層的分階段構建，IaaS 層中管理平台和資源池的分別構建，以及資源池根據業務情況的逐步擴容；
快速上線：私有雲不僅要求資源的快速交付，還要求支持業務系統的自動部署及便捷的線上擴容；
運維簡單：私有雲場景下，企業既是使用方同時也是營運方，運維人員是非常有限的。因此，私有雲的運維應盡可能簡單，同時保證系統復雜性不隨系統規模擴大而大幅增加。這樣可以避免復雜的運維成為業務快速增長的瓶頸，以及對系統的穩定性帶來隱患；
生產就緒：當用戶進行私有雲化改造的時候，通常只關注了功能特性，而忽略了私有雲最終是要承載生產業務，才能真正實現的企業數據中心「雲化」轉型目標。因此，方案乃至供應商服務的「生產就緒「能力可以保障架構轉型可持續、深入地進行，而不是僅停留在實驗階段；
成本合理：所有的轉型最終都需要以經濟效益衡量。私有雲方案不僅需要關注采購成本，還要關注使用成本、維護成本以及軟硬體維保和升級等各方面成本。
㈧ 企業網盤公有雲，私有雲和混合雲的區別
區別在於網盤部署位置。
私有雲是在企業自己的伺服器內部署網盤，公有雲是第三方伺服器內，混合雲就是公有和私有雲的混合體，目前雲網盤計算很成熟。