⑴ 雲計算主要有哪幾種類型
雲計算通常可以分為三類：將基礎設施作為服務（IaaS）、將平台作為服務（PaaS）和將軟體作為服務（SaaS）。
1、IaaS：將硬體設備等基礎資源封裝成服務供用戶使用。 在IaaS環境中，用戶相當於在使用裸機和磁碟，既可以讓它運行Windows，也可以讓它運行Linux。 IaaS最大優勢在於它允許用戶動態申請或釋放節點，按使用量計費。而IaaS是由公眾共享的，因而具有更高的資源使用效率。
2、PaaS：提供用戶應用程序的運行環境，典型的如Google App Engine。PaaS自身負責資源的動態擴展和容錯管理，用戶應用程序不必過多考慮節點間的配合問題。但與此同時，用戶的自主權降低，必須使用特定的編程環境並遵照特定的編程模型，只適用於解決某些特定的計算問題。
3、SaaS：針對性更強，它將某些特定應用軟體功能封裝成服務。SaaS既不像PaaS一樣提供計算或存儲資源類型的服務，也不像IaaS一樣提供運行用戶自定義應用程序的環境，它只提供某些專門用途的服務供應用調用。
注意：隨著雲計算的深化發展，不同雲計算解決方案之間相互滲透融合，同一種產品往往橫跨兩種以上類型。
⑵ 雲計算主要有3種服務類型，每種類型的功能和服務對象都是什麼
1、平台即服務（PaaS）
平台即服務是面向開發者的雲計算。這種雲計算最大的特徵是它自帶開發環境，並向開發者提供開發工具包。
2、軟體即服務（SaaS）
軟體即服務是普通消費者可以感知到的雲計算，這種雲計算最大的特徵就是消費者並不購買任何實體的產品，而是購買具有與實體產品同等功能的服務。
3、基礎架構即服務（IaaS）
基礎架構即服務一般面向的是企業用戶，這種雲計算最大的特徵在於，它出租的是伺服器的計算能力和存儲能力。
雲計算的實現形式
雲計算是建立在先進互聯網技術基礎之上的，其實現形式眾多，主要通過以下形式完成：
（1）軟體即服務。通常用戶發出服務需求，雲系統通過瀏覽器向用戶提供資源和程序等。值得一提的是，利用瀏覽器應用傳遞服務信息不花費任何費用，供應商亦是如此，只要做好應用程序的維護工作即可。
（2）網路服務。開發者能夠在API的基礎上不斷改進、開發出新的應用產品，大大提高單機程序中的操作性能。
（3）平台服務。一般服務於開發環境，協助中間商對程序進行升級與研發，同時完善用戶下載功能，用戶可通過互聯網下載，具有快捷、高效的特點。
（4）互聯網整合。利用互聯網發出指令時，也許同類服務眾多，雲系統會根據終端用戶需求匹配相適應的服務。
（5）商業服務平台。構建商業服務平台的目的是為了給用戶和提供商提供一個溝通平台，從而需要管理服務和軟體即服務搭配應用。
（6）管理服務提供商。此種應用模式並不陌生，常服務於IT行業，常見服務內容有：掃描郵件病毒、監控應用程序環境等。
⑶ 雲計算環境下數據存儲的特點
雲計算是以分布式計算做為數據存儲管理為基礎的，所以宏觀世界具有高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率為特徵。
⑷ 雲計算塊存儲是什麼，誰能給個解釋呢
什麼是塊存儲?
塊存儲與存儲區域網路(SAN)是同義詞，並且支持網路附加存儲(NAS)系統中使用的文件存儲技術無法實現的存儲服務。塊存儲涉及將數據保存在塊或原始存儲卷中。
這些存儲塊中的每一個可以作為一個單獨的硬碟驅動器出現在外部伺服器操作系統上。操作系統依次使用光纖通道(FC)、乙太網上的光纖通道(FCOE)或ISCSI協議來訪問這些塊。
塊存儲和SAN因此在企業IT環境中很普及的原因是由於其靈活性和性能特徵。塊存儲支持各種需要低延遲、基於網路的存儲操作的工作負載，其中包括業務關鍵型應用程序、虛擬機、RAID實施和資料庫。
雖然不應該將其與文件存儲系統混淆，這種類型使組織能夠通過網路使用NAS-a文件系統為員工提供共享文件服務，可以將其分層存儲在塊存儲上，因為塊存儲顯示為原始存儲到伺服器操作系統。
在雲平台中，塊存儲可從AWS ElasTIc Block Store或AWS EBS等服務獲得，該服務提供可擴展塊存儲，供ElasTIc Compute Cloud(EC2)實例使用。
⑸ 雲計算時代操作系統Kubernetes之存儲（中）
我們在POD中定義數據卷的時候，必須指定數據卷的類型。由於存儲技術的發展遠遠早於Kubernetes平台的誕生，並且隨著Kubernetes的日益流行，新的存儲技術和方案也在日新月異，因此數據卷可以說理所當然的有很多很多類型，有些是通用的類型，而有些需要底層特定存儲技術的支持，下邊是Kubernetes支持的數據卷類型不完全清單：
- emptyDir類型，emptyDir類型的數據卷允許POD將數據保存到指定的文件夾中，並且數據在POD的整個生命周期中可見。保存數據的文件夾在POD啟動前被創建，並且剛開始文件夾為空，這也是叫empty的緣由。
- hostPath類型，從宿主機的文件系統掛載文件到POD中。
- nfs類型，NFS類型的存儲卷掛載到POD中。
- cephfs，cinder，fc等，用來支持不同類型的網路存儲。
- configMap，secret，downwardAPI，以及projected類型，四種卷類型，用來將POD和Kubernetes的相關信息通過文件暴露給外部，這些卷類型主要用來配置應用程序。這幾種類型筆者會在後續的文章中詳細介紹。
- persistentVolumeClaim類型（PVC），一種輕量級的集成外部存儲能力的方案。在這種類型的數據卷類型中，PersistentVolumeClaim類型的存儲對象指向PersistentVolume類型的存儲對象，真實的外部存儲系統由PersistentVolume這個對象來引用。由於這是Kuberntes強烈建議大家使用的存儲類型，因此筆者會在後續的文章中，單獨來詳細介紹。
- csi類型，一種通過CSI來擴展存儲的方式。這種方式允許所有實現了CSI（Container Storage Interface）介面的存儲實現能夠被POD引用，在POD初始化的過程中，CSI驅動會將存儲卷attach到POD上。
上邊羅列的只是數量巨大存儲卷類型中很小一部分，每種類型都有對應的使用場景。筆者在本篇以及後續的文章中，著重介紹最具代表性的幾個類型，來幫助大家理解Kubernetes存儲體系。首先我們從最簡單的emptyDir類型開始，這種類型的數據卷用來在容器重啟場景中保持狀態。
還記得我們在前邊文章中介紹如何在同一個POD中部署兩個容器實例的例子嗎？當時的做法是通過post-start hook來執行fortune命令產生一個名言警句寫入文件中，運行在另外一個容器中的Nginx伺服器由於掛載了相同的volume，因此會直接將這個信息返回給客戶端請求。這個保存fortune產生的名言警句的文件在容器的文件系統中，這就意味著當容器由於liveness probe三次失敗重啟後，你會看到不同的名言警句，雖然說看起來問題不大，但是從原理上講，數據由於容器重啟丟失。
我們來驗證一下上邊的推理是否符合事實，請在自己的本地環境中部署yunpan-fs.yaml，然後執行kubectl port-forward yunpan-fs 1080:80來創建客戶端代理，訪問服務返回名言警句。然後通過命令讓Nginx重新啟動，重新訪問服務，你可以看到兩次返回的數據不一致，這就證明了保存在容器文件系統的數據，在容器重啟的場景下，不會保持。在筆者的本地環境輸出如下圖：
如上圖所示，重啟容器後會產生新的名言警句，這就意味著容器重啟後保存在文件系統中的數據丟失了。如果我們要在這種重啟的場景中保持數據狀態，那麼就必須確保數據被保存在數據卷中，而emptyDir是解決這個問題的完美方案。當emptyDir類型的數據卷被掛載到容器中，應用寫到掛載目錄的數據文件，在容器重啟後，能夠繼續保持。
emptyDir類型的數據卷可以讓容器即便是重啟後，可以讓寫到文件中的數據狀態保持；或者容器的文件系統為只讀，但是應用在運行的過程中，需要寫狀態到文件中等場景，我們也可以使用emptyDir類型的數據卷來在同一個POD的多個容器之前，進行數據共享。
廢話不多說了，咱直接修改fortune pod來把post-start hook執行fortune命令返回的名言警句寫到emptyDir類型的數據卷中，這樣當容器重啟後，就不會出現數據丟失了。我們其實要修改的地方不多，主要包括：1，給POD增加emptyDir類型的數據卷定義；2，在容器中將這個數據卷掛載到指定的目錄。
另外我們對命令的執行進行了一點點優化，post-start hook會在每次容器啟動後都會執行，因此我們需要防止重啟後對fortune命令輸出對已經存在文件的覆蓋，因此我們對post-start命令腳本也做了優化，如下圖所示：
註：post-start hook腳本被更新成"ls /usr/share/nginx/html/quote || (apk add fortune && fortune > /usr/share/nginx/html/quote)"，如果讀者對Linux shell腳本不是很熟悉，這句肯定看的雲里霧里，我們來稍微解釋一下。首先ls命令先執行，我們這里用ls來檢查quote文件是否存在，你有所不值得是，當ls後邊給的文件存在的時候，命令返回0，而如果不存在，就返回非0。由於我們使用||將兩個表達式進行了組合，因此當左邊的ls quote執行成功，那麼右邊的語句就壓根不會執行。通過這種方式，如果quote文件存在，那麼咱就直接跳過了。而當文件不存在，才需要執行右邊的一串命令，安裝fortune和執行fortune來產生名言警句。這句腳本確保名言警句只被生成並寫入一次，也就是只在容器第一次啟動的時候。
如上圖所示，我們定義了emptyDir類型的數據卷content，並掛載到nginx容器指定目錄/usr/share/nginx/html（這個是Nginx伺服器默認用來掃描靜態資源的目錄）。在POD中配置volume需要提供配置參數，接下來我們詳細聊聊如何配置emptyDir類型的數據卷。
對於emptyDir類型的存儲卷，Kubernetes要求配置如下兩個屬性：
- medium，文件夾的存儲介質，如果留空不配置，那麼默認就是宿主機的（工作節點）磁碟。除了磁碟之外，我們還可以配置Memory，這會導致數據卷使用tmpfs文件系統，這是一個在內存文件系統。
- sizeLimit，文件夾需要的磁碟空間大小，比如我們如果需要限制這個文件夾中文件的大小為10M，那麼就可以設置為10Mi。
註：我們上邊的例子中，emptyDir類型的數據卷content未顯示的定義任何欄位，取默認值，大括弧非常明確的表達了這一點，但是並不是必須的。
在POD中定義完數據卷只完成了工作的一半，工作的另一半就是將數據卷掛載到容器實例中，這通過在容器spec.containers域通過volumeMounts來引用。volumeMounts除了要制定name之外，還需要包含mountPath欄位，來指定數據卷被具體掛載到容器文件系統的文件目錄樹的那個路徑。筆者上邊提供的例子中，emptyDir類型的數據卷被掛載到了/usr/share/ngxin/html目錄，因為這也是post-start hook將名言警句寫到文件的路徑。
由於使用了emptyDir類型的數據卷之後，名言警句被寫入到了宿主機的文件系統，因此數據在POD的整個生命周期都會保持，因此我們無論重啟nginx容器多少次，返回的數據（名言警句）都不應該有任何變化。
接下來，我們將這個新版本基於fortune命令的名言警句網站部署到Kubernetes集群，並人為的讓nginx容器重啟，你會發現無論我們重啟多少次，quote介面返回的內容都一樣。背後的原理是，因為我們只在容器第一次啟動的時候，才創建quote文件，並且當容器重啟重新掛載數據卷後，這個quote文件仍然存在。你可能會問，這個文件到底在宿主機的啥地方啊，可以運行kubectl exec yunpan-emptydir -- mount --list | grep nginx/html來發現，如下圖所示：
如上圖所示，通過使用emptyDir類型的數據局content，我們成功讓容器重啟之後，保持數據狀態。接下來，我們繼續看另外一個例子，如何通過數據卷在兩個容器時間共享數據。
如筆者前邊多次提到，我們也可以使用emptyDir類型的數據卷來在同一個POD中的兩個容器之間共享數據，這里需要注意的是，我們無法通過emptyDir類型的數據卷在不同PDO中不同的容器間共享數據，請繼續閱讀。
我們基於fortune的名言警句網站目前略顯無趣，因為每次都返回相同的諺語，我們希望這個行為能夠增強，比如每30分鍾更換一次。為了實現這個功能，我們需要將post-start hook替換成容器，並且在容器中，fortune命令每30秒運行一次。為了使大家學習更加容易，筆者已經構建好了需要的容器，並上傳到Docker Hub，大家可以自行通過命令 docker pull qigaopan/yunpan-fortune:v1.0拉取。
好了，我們已經把需要的容器鏡像都准備好了，接下來我們來編寫POD的YAML文件，如下圖所示：
如上圖所示，emptyDir類型的數據卷被兩個容器共享（共同掛載），容器fortune將數據寫到content數據卷，在nginx容器中，相同的數據卷被以read-only的模式被掛載到nginx的默認目錄。
註：我們在前邊文章中反復強調過一個事實，同一個POD中的多個容器幾乎是同時啟動的，因此可能存在微小的一段時間，ngxin伺服器已經成功運行起來，但是quote文件尚未生成。聰明的你可能想到了，要避免這種場景，我們可以使用初始化容器。
接著，我們將fortune POD部署到Kubernetes集群中，兩個容器幾乎同時開始運行。fortune容器每30秒更新一次諺語（名言警句），nginx容器基於相同的數據文件服務客戶端請求，當POD中的兩個容器都Ready後，可以驗證一下輸出，是否每30秒後，quote請求對應的諺語的返回會更新。
由於在fortune例子中emptyDir類型的數據卷會在宿主機的磁碟上創建共享目錄，因此數據讀寫的性能，完全取決於工作節點上硬體的類型。如果我們的應用需要高性能的IO操作，那麼磁碟可能不是最合適的存儲介質。
Kubernetes允許我們使用tmpfs文件系統來創建數據卷，而tmpfs將數據保存在內存中，我們只需要在POD的YAML文件中，把emptyDir的欄位meim設置為Memory。
其實Memory類型的數據卷除了提供較高的IO之外，數據安全性也比磁碟高。由於數據並沒有落盤，因此數據不容易被惡意攻擊者竊取，因此建議大家可以在自己的項目上考慮這種數據卷類型。另外我們也可以通過參數sizeLimit來約束數據卷的size，特別對於Memory類型的數據卷來說，請務必設置sizeLimit，以防內存被耗盡。
在前邊的內容中，我們將目光主要集中在如何在POD中定義數據卷，而沒有詳細介紹volume是如何掛載到容器中的，接下來我們來看看在容器中掛載數據卷具體需要設置哪些參數。如下圖所示，是我們在新版本的fortune POD定義中關於content數據卷掛載的配置：
從上圖可以看出，掛載數據卷到容器中，我們需要至少配置兩個欄位：name和mountPath，其中name欄位是我們在POD定義的數據卷的名字，而mountPath欄位指定了數據卷應該掛載到容器文件系統的文件數的那個目錄。
除了這兩個必須提供的參數之外，我們還有一些可選的參數可以配置，詳細的可配置參數清單如下：
- name欄位，如筆者上邊的介紹，name欄位就是我們在POD中掛載的數據卷的name
- mountPath欄位，前文應介紹，不累述
- readOnly欄位，是否以只讀的模式掛載數據卷，默認是false，也就是以讀寫的方式掛載數據卷。
- mountPropagation欄位，設置如果在數據卷內部掛載額外的文件系統會發生什麼。有幾個選項，默認是none，指如果宿主機在數據卷中掛在了額外的文件系統，容器不會收到任何通知，反之亦然；還有兩個選項HostToContainer和Bidirectional，具體含義如命名，如果要了解詳情，可以參考官方文檔。
- subPath欄位，默認為「」，意味著整個數據卷都被掛載到mountPath指定的目錄，當設置為非空的字元串後，只有subPath指定的文件路徑被掛載到容器中
- subPathExpr欄位，使用類似於shell提供的$(ENV_VAR_NAME)語句，只能使用環境變數。
在大部分場景下，我們只需要設置name和mountPath就可以了，頂多額外多配置參數readOnly。mountPropagation參數只有在一些復雜配置的場景下才會用到，當我們用一個數據卷來提供不同的文件夾給不同的容器的時候，subPath和subPathExpr非常有用。另外這兩個參數也可以用作多個PDO共享一個數據卷的場景。
好了，這篇文章的內容就這么多了，下篇文章我們繼續介紹存儲，看看如何訪問宿主機文件系統中的數據文件，敬請期待！
⑹ 雲存儲結構模型大概是什麼
朋友， 雲存儲系統的結構模型是由4層去組成。 1存儲層 2基礎管理層3應用介面層4訪問層。其實雲存儲就是你可以隨時隨地，通過一些客戶端方便自由地在不同電腦、手機、平板間達到同步數據；或者直接通過網路使用你存儲的數據，比如直接觀看在線視頻，編輯文檔。
雲存儲十分好用的，就相當於網路u盤，目前好用的雲存儲目前來說不會很多，像360雲、網路雲、天翼雲都是不錯的雲存儲。其中我就用過360雲、天翼雲，360雲容量大，安全性好，速度也不錯，而天 翼 雲 ，有15G的初始空間，首次登陸其客戶端就能一次性拿到10T，它有移動和pc的客戶端，能同步數據，還支持在線視頻，編輯文檔等，也是一個不錯的雲存儲。
⑺ 雲存儲架構分哪些層次,各自實現了什麼功能
(1)存儲層
雲存儲系統對外提供多種不同的存儲服務，各種服務的數據統一存放在雲存儲系統中，形成一個海量數據池。從大多數網路服務後台數據組織方式來看，傳統基於單伺服器的數據組織難以滿足廣域網多用戶條件下的吞吐性能和存儲容量需求；基於P2P架構的數據組織需要龐大的節點數量和復雜編碼演算法保證數據可靠性。相比而言，基於多存儲伺服器的數據組織方法能夠更好滿足在線存儲服務的應用需求，在用戶規模較大時，構建分布式數據中心能夠為不同地理區域的用戶提供更好的服務質量。
雲存儲的存儲層將不同類型的存儲設備互連起來，實現海量數據的統一管理，同時實現對存儲設備的集中管理、狀態監控以及容量的動態擴展，實質是一種面向服務的分布式存儲系統。
(2)基礎管理層
雲存儲系統架構中的基礎管理層為上層提供不同服務間公共管理的統一視圖。通過設計統一的用戶管理、安全管理、副本管理及策略管理等公共數據管理功能，將底層存儲與上層應用無縫銜接起來，實現多存儲設備之間的協同工作，以更好的性能對外提供多種服務。
(3)應用介面層
應用介面層是雲存儲平台中可以靈活擴展的、直接面向用戶的部分。根據用戶需求，可以開發出不同的應用介面，提供相應的服務。比如數據存儲服務、空間租賃服務、公共資源服務、多用戶數據共享服務、數據備份服務等。
(4)訪問層
通過訪問層，任何一個授權用戶都可以在任何地方，使用一台聯網的終端設備，按照標準的公用應用介面來登錄雲存儲平台，享受雲存儲服務。
2雲存儲技術的優勢
作為新興的存儲技術，與傳統的購買存儲設備和部署存儲軟體相比，雲存儲方式存在以下優點：
(1)成本低、見效快
傳統的購買存儲設備或軟體定製方式下，企業根據信息化管理的需求，一次性投入大量資金購置硬體設備、搭建平台。軟體開發則經過漫長的可行性分析、需求調研、軟體設計、編碼、測試這一過程。往往在軟體開發完成以後，業務需求發生變化，不得不對軟體進行返工，不僅影響質量，提高成本，更是延誤了企業信息化進程，同時造成了企業之間的低水平重復投資以及企業內部周期性、高成本的技術升級。在雲存儲方式下，企業除了配置必要的終端設備接收存儲服務外，不需要投入額外的資金來搭建平台。企業只需按用戶數分期租用服務，規避了一次性投資的風險，降低了使用成本，而且對於選定的服務，可以立即投入使用，既方便又快捷。
(2)易於管理
傳統方式下，企業需要配備專業的IT人員進行系統的維護，由此帶來技術和資金成本。雲存儲模式下，維護工作以及系統的更新升級都由雲存儲服務提供商完成，企業能夠以最低的成本享受到最新最專業的服務。
(3)方式靈活
傳統的購買和定製模式下，一旦完成資金的一次性投入，系統無法在後續使用中動態調整。隨著設備的更新換代，落後的硬體平台難以處置；隨著業務需求的不斷變化，軟體需要不斷地更新升級甚至重構來與之相適應，導致維護成本高昂，很容易發展到不可控的程度。而雲存儲方式一般按照客戶數、使用時間、服務項目進行收費。企業可以根據業務需求變化、人員增減、資金承受能力，隨時調整其租用服務方式，真正做到「按需使用」。
3雲存儲技術趨勢
隨著寬頻網路的發展，集群技術、網格技術和分布式文件系統的拓展，CDN內容分發、P2P、數據壓縮技術的廣泛運用，以及存儲虛擬化技術的完善，雲存儲在技術上已經趨於成熟，以「用戶創造內容」和「分享」為精神的Web2.0推動了全網域用戶對在線服務的認知
⑻ AWS雲計算助手級架構師認證之EC2-存儲類型
日常生活中經常用到的電腦存儲類型，一般都是磁碟存儲，如果使用的是Windows操作系統的話，就是C盤，D盤等。當我們使用EC2實例的時候，必須為該實例指定將在該實例上運行的數據保存在什麼卷上。一般有兩種存儲類型，EBS卷存儲，和實例存儲卷（Ephemeral）存儲。
EBS卷存儲：
①EC2實例啟動的時候，可以和EBS卷結合使用（作為根卷或者是附加卷），實例中使用的數據都會被永久性的保存在EBS卷上，實例停止（Stop）或終止（Terminate）後，數據仍然可以隨著EBS卷保存下來（需要改變實例的EBS卷保留屬性。EBS卷保留屬性：當終止實例的時候是否保留使用的EBS卷）。
② EBS卷和EC2實例相連接的方式和日常生活中常見的電腦和硬碟的連接方式類似，單獨買的硬碟，通過USB可以將硬碟和任意一台電腦相連接，不需要時可以拔下來。同樣，EBS卷可以和不同的EC2實例相連接，但一個EBS卷一次只能和一個EC2實例相結合，而一個EC2實例可以和很多EBS卷相結合。EBS卷和EC2實例的連接方式是通過網路。
③EBS卷還可以以快照的形式將數據保存下來，待以後有需要時再還原成EBS卷。比如說我的EBS卷上有很多重要的數據，在別的EC2實例上也需要，那麼我們可以通過對現在的EBS卷拍照，生成一個快照，然後再把該快照還原成EBS卷，最後把這個EBS卷和別的EC2實例相關聯使用。需要注意的是，EBS卷是不能夠跨區域（Region）使用的，當另外一個區域內的EC2實例想使用這個區域內的EBS卷的時候，必須對EBS卷拍攝快照，然後將生成的快照復制到另一個區域內才可以。
④有幾個時機的注意點需要注意：當EC2實例啟動的時候可以將EBS卷添加到EC2實例中，在EC2實例啟動之後也可以把更多的EBS卷添加到EC2實例中。而卷保留屬性，就是當終止運行的EC2實例時，是否刪除該實例利用的EBS卷的一個屬性，可以設置刪除或者保留，而這個屬性只能在啟動EC2實例的時候設置。
實例存儲卷（Ephemeral）存儲：
① 當EC2實例和實例存儲卷（Ephemeral）結合使用的時候（作為根卷或者附加卷），當EC2實例在運行狀態下，實例中的數據會被保存在實例存儲卷上，而當實例被停止（Stop）或終止（Terminate）的狀態下，保留在實例上的數據會消失，（但對實例進行重啟，即Restart的情況下，實例存儲卷上的數據是不會消失的），也就是說保存在實例存儲卷上的數據不是永久性的。但有別的方法將實例存儲卷上的數據保存下來，方法就是對該實例生成一個AMI，然後利用該AMI啟動實例，利用這個方法可以保存實例存儲卷上的數據。
②有很多實例類型，但是並不是所有的實例類型都支持實例存儲卷。實例和實例存儲卷的連接方式是物理連接，其實實例存儲卷是EC2實例物理主機上的磁碟存儲卷。當AWS生成實例存儲卷的是時候，它會利用保存在S3存儲桶中的一個實例存儲卷模板。在實例存儲卷被完全生成之前，EC2實例是不會被啟動的。而AWS生成EBS卷的時候，它會利用EBS快照。並且啟動EC2實例時所需的部分EBS卷很少，只要從EBS快照恢復出來那一部分就可以完成啟動EC2實例的動作。所以利用實例存儲卷的EC2實例啟動速度會比利用EBS卷的EC2實例的啟動速度要慢。
③只有在啟動EC2實例的時候才能把實例存儲卷添加到EC2實例中，在啟動EC2實例之後便不能再添加新的實例存儲卷，這點和EBS卷是不同的。
注意：將實例終止或者停止之後再開始，則AWS可能會在不同的物理主機上啟動新的實例，而將EC2實例重啟的話，則是在同一個物理主機上。所以實例存儲卷的數據在重啟之後不會丟失，而在終止或停止之後則會丟失。並且當物理主機由於資源不足等錯誤造成EC2實例不能正常工作等致命錯誤時，最簡單的方法就是將該EC2實例停止掉，然後再開始啟動即可。
⑼ 雲計算使得信息的儲存是一個什麼樣的方式。
產品定義：
BC—oNest(Object Nest)是一個以對象形式存儲和管理海量非結構化數據的雲存儲系統。BC—oNest可以為互聯網業務和企業用戶提供低成本的PB級存儲規模，具備高可靠、高安全性和高擴展性的雲存儲服務。
產品實現了跨機架的海量對象存儲和備份功能：提供WEB方問(業務使用門戶以及REST API)以及SDK：提供批量導入導出工具來支持oNest和Linux本地目錄之間的相互拷貝：支持Windows客戶端工具，方便用戶的使用。
產品特點
按需分配的存儲空間：系統支持TB級到PB級的存儲空間管理，存儲容量可在線平滑擴容。
可靠的數據存儲：系統支持對象數據跨機架存儲；在每個AZ內多副本存儲。系統的健康檢查模塊保證副本減少的情況下，自動修復副本數量：同時系統內部實現了數據的完整性校驗機制，防止數據被非法篡改或損壞。
安全的數據訪問控制：系統的認證鑒權和ACI一訪問控制機制保證數據只被授權用戶訪問：同時系統支持密鑰簽名機制，保證用戶訪問消息在傳輸通道上的安全性。
高性能的數據處理：提供Multi Part的並發上傳功能提高大對象上傳速度：支持基於Range的多點並發下載功能提高對象下載速度：數據節點內部採用文件聚合的方法提高性能：支持高並發的用戶訪問和高吞吐的數據流量。
高可用的數據服務能力：AZ內多副本存儲和副本自動修復能力，提高了系統持續服務能力，在常見的伺服器集群節點或局部網路故障情形中，系統具有高可用性。
提供多種數據訪問介面：系統對外提供WEB訪問(業務使用門戶及REST API)以及SDK，並提供批量導入導出工具來支持oNest和Linux本地目錄之間的相互拷貝。
在服產品版本及特性:
5.X版本：
自主研發的以對象形式存儲和管理海量非結構化數據的存儲系統
基於跨機架的大規模數據中心環境設計，具有極強的水平擴展能力
提供類AWS S3的REST API和SDK，以及本地批量數據導入導出工具
支持用戶、容器以及對象的訪問許可權管理和控制
服務可用性99.9%，數據可靠性99.999999999%，無單點故障，支持線性擴展
支持至少千億級對象存儲，單個對象最大5TB，千兆網路環境下4KB對象讀取響應時間小於100ms
支持用戶可選的伺服器端及客戶端數據加密存儲，整個過程對用戶透明
支持系統和存儲資源監控及告警功能，易運營可管理
提供面向系統、用戶和容器三個級別的准實時統計計量能力，支持用戶按需付費
6.0版本：
基於主流ceph產品，支持糾刪碼，支持主流s3介面
核心功能：
1：對象相關功能
對象管理：系統支持對象的創建、讀取和刪除、設置用戶自定義元數據等功能。
對象訪問控制：系統支持設置或獲取容器和對象訪問許可權(ACL)等功能。
2：容器相關功能
容器管理：系統按容器組織對象，每個用戶可擁有零或多個容器，每個用戶可包合零或多個對象。系統支持容器的創建、刪除，按字典序列出容器內的對象等功能。
3：用戶相關功能
用戶認證及許可權：對用戶的身份進行認證，確認訪問用戶的身份，完成認證後基於用戶狀態、配額和許可權進行確認。
4：系統相關功能
計量信息：提供為資源池管理系統提供計費需要的計量信息，包括空間佔用、訪問流量等。
用戶控制：提供用戶運營管理訪問控制包括簽約對象存儲服務、查看對象存儲服務等功能。
日誌管理：提供對系統日誌的記錄及瀏覽功能。
統計報表：提供對系統各項指標的統計和分析，包括系統數據日誌、用戶日誌及日誌管理、訪問統計、統計總空間佔用、統計總用戶數、統計各個節點上佔用空間大小、容器總數量、流量信息統計等。
運維管理：提供雲存儲系統內部管理、維護，包括系統管理用戶認證鑒權、系統管理角色管理、設備狀態監控、設備維護等功能。
產品優勢：
BC—oN est是基於標准X86伺服器集群的對象存儲系統。產品優勢主要體現在：
容量和性能隨節點增加而線性增強，且支持無縫的在線擴容和升級維護。
基於X86存儲伺服器的結構具有低成本特點。
系統的高可靠設計，單磁碟和單伺服器故障不會影響系統服務，保障用戶數據的可用性。
安全認證和數據加密手段，為用戶提供安全的數據存儲服務。
應用場景：
廣泛應用於公眾雲存儲服務，為用戶和企業提供按需擴展的雲存儲服務。支持各類互聯網應用，如網盤
類應用中對圖片、文檔和音視頻的存儲j對象存儲通過與主流備份軟體結合，可向用戶提供更具成本效益、
更低TCO的備份方案j對象存儲與歸檔軟體、分級存儲軟體結合，可以將在線系統中的數據無縫歸檔／分級
存儲到對象存儲系統，減少陣列等在線系統存儲資源。
應用案例：中國移動公眾服務雲
一：應用背景和面臨的問題
雲存儲是laaS核心服務之一，主要支撐海量非結構化數據的存儲和處理需求。傳統的非結構數據存儲系統主要採用磁碟陣列和NAS設備實現，為本地伺服器提供塊存儲空間或文件存儲空間，本質上屬於數據中心內部的解決方案，主要存在的問題包括：首先，兩者的服務介面協議上都不能滿足在廣域網范圍提供服務的能力要求j其次，磁碟陣列和NAS設備的擴展I生也有限，不能滿足百億級文件的存儲需求j最後，設備成本較高，基於陣列設備提供的雲存儲服價格不具備競爭性。
二：解決方案
公眾服務雲的對象存儲服務使用BC—oNest產品實現。300台存儲伺服器可以提供PB級的對象存儲服務空間支持百億級的對象存儲。
三：商業價值
中國移動公眾服務雲採用自主研發的BC—oNest，系統建設上相比使用商用解決方案節約成本數百萬元。自主研發產品的應用也使得研發和運營實現緊密互動，對象存儲服務的功能可隨著市場競爭的要求實現快速迭代開發。
基於BC—oNest的對象存儲服務是中國移動在公眾服務雲布局的重要環節之一，將為中國移動拓展行業雲應用奠定堅實的基礎。
歡迎撥打4001100865至中移軟體技術有新公司咨詢！
⑽ 雲計算架構
雲計算架構主要可分為四層，其中有三層是橫向的，分別是顯示層、中間件層和基礎設施層，通過這三層技術能夠提供非常豐富的雲計算能力和友好的用戶界面，還有一層是縱向的，稱為管理層，是為了更好地管理和維護橫向的三層而存在的。下面介紹每個層次的作用和屬於這個層次的主要技術。
顯示層
這層主要是用於以友好的方式展現用戶所需的內容，並會利用到下面中間件層提供的多種服務，主要有五種技術：
HTML：標準的Web頁面技術，現在主要以HTML4為主，但是將要推出的HTML5會在很多方面推動Web頁面的發展，比如視頻和本地存儲等方面。
JavaScript：一種用於Web頁面的動態語言，通過JavaScript，能夠極大地豐富Web頁面的功能，最流行的JS框架有jQuery和Prototype。
CSS：主要用於控制Web頁面的外觀，而且能使頁面的內容與其表現形式之間進行優雅地分離。
Flash：業界最常用的RIA(Rich Internet Applications)技術，能夠在現階段提供HTML等技術所無法提供的基於Web的富應用，而且在用戶體驗方面，非常不錯。
Silverlight：來自業界巨擎微軟的RIA技術，雖然其現在市場佔有率稍遜於Flash，但由於其可以使用C#來進行編程，所以對開發者非常友好。
在顯示層，大多數雲計算產品都比較傾向HTML，、JavaScript和CSS這對黃金組合，但是Flash和Silverlight等RIA技 術也有一定的用武之地，比如VMware vCloud就採用了基於Flash的Flex技術，而微軟的雲計算產品肯定會在今後使用到Silverlight。
中間件層
這層是承上啟下的，它在下面的基礎設施層所提供資源的基礎上提供了多種服務，比如緩存服務和REST服務等，而且這些服務即可用於支撐顯示層，也可以直接讓用戶調用，並主要有五種技術：
REST：通過REST技術，能夠非常方便和優雅地將中間件層所支撐的部分服務提供給調用者。
多租戶：就是能讓一個單獨的應用實例可以為多個組織服務，而且保持良好的隔離性和安全性，並且通過這種技術，能有效地降低應用的購置和維護成本。
並行處理：為了處理海量的數據，需要利用龐大的X86集群進行規模巨大的並行處理，Google的MapRece是這方面的代表之作。
應用伺服器：在原有的應用伺服器的基礎上為雲計算做了一定程度的優化，比如用於Google App Engine的Jetty應用伺服器。
分布式緩存：通過分布式緩存技術，不僅能有效地降低對後台伺服器的壓力，而且還能加快相應的反應速度，最著名的分布式緩存例子莫過於Memcached。
對於很多PaaS平台，比如用於部署Ruby應用的Heroku雲平台，應用伺服器和分布式緩存都是必備的，同時REST技術也常用於對外的介面， 多租戶技術則主要用於SaaS應用的後台，比如用於支撐Salesforce的Sales Cloud等應用的Force.com多租戶內核，而並行處理技術常被作為單獨的服務推出，比如Amazon的Elastic MapRece。
基礎設施層
這層作用是為給上面的中間件層或者用戶准備其所需的計算和存儲等資源，主要有四種技術：
虛擬化：也可以理解它為基礎設施層的「多租戶」，因為通過虛擬化技術，能夠在一個物理伺服器上生成多個虛擬 機，並且能在這些虛擬機之間能實現全面的隔離，這樣不僅能減低伺服器的購置成本，而且還能同時降低伺服器的運維成本，成熟的X86虛擬化技術有 VMware的ESX和開源的Xen。
分布式存儲：為了承載海量的數據，同時也要保證這些數據的可管理性，所以需要一整套分布式的存儲系統，在這方面，Google的GFS是典範之作。
關系型資料庫：基本是在原有的關系型資料庫的基礎上做了擴展和管理等方面的優化，使其在雲中更適應。
NoSQL：為了滿足一些關系資料庫所無法滿足的目標，比如支撐海量的數據等，一些公司特地設計一批不是基於關系模型的資料庫，比如Google的BigTable和Facebook的Cassandra等。
現在大多數的IaaS服務都是基於Xen的，比如Amazon的EC2等，但VMware也推出了基於ESX技術的vCloud，同時業界也有幾個 基於關系型資料庫的雲服務，比如Amazon的RDS(Relational Database Service)和Windows Azure SDS(SQL Data Services)等。關於分布式存儲和NoSQL，它們已經被廣泛用於雲平台的後端，比如Google App Engine的Datastore就是基於BigTable和GFS這兩個技術之上的，而Amazon則推出基於NoSQL技術的Simple DB。
管理層
這層是為橫向的三層服務的，並給這三層提供多種管理和維護等方面的技術，主要有下面這六個方面：
帳號管理：通過良好的帳號管理技術，能夠在安全的條件下方便用戶地登錄，並方便管理員對帳號的管理。
SLA監控：對各個層次運行的虛擬機，服務和應用等進行性能方面的監控，以使它們都能在滿足預先設定的SLA(Service Level Agreement)的情況下運行。
計費管理：也就是對每個用戶所消耗的資源等進行統計，來准確地向用戶索取費用。
安全管理：對數據，應用和帳號等IT資源採取全面地保護，使其免受犯罪分子和惡意程序的侵害。
負載均衡：通過將流量分發給一個應用或者服務的多個實例來應對突發情況。 運維管理：主要是使運維操作盡可能地專業和自動化 ，從而降低雲計算中心成本。
負載均衡：通過將流量分發給一個應用或者服務的多個實例來應對突發情況。
運維管理：主要是使運維操作盡可能地專業和自動化，從而降低雲計算中心的運維成本。
現在的雲計算產品在帳號管理，計費管理和負載均衡這三個方面大都表現地不錯，在這方面最突出的例子就是Amazon 的EC2，但可惜的是，大多數產品在SLA監控，安全管理和運維管理等方面還有所欠缺。
舉例
接下來，將以Salesforce的Sales Cloud和Google的App Engine這兩個著名的雲計算產品為例，來幫助大家理解本文所提到的雲計算架構：
Salesforce Sales Cloud
也就是之前的Salesforce CRM(客戶關系管理)，屬於雲計算中的SaaS層，主要是通過在雲中部署可定製化的CRM應用，來讓企業用戶在很低初始投入的情況下使用上CRM，並且 可根據自身的流程來進行靈活地定製，而且只需接入網路就能使用。在技術層面上大致的架構：
採用的主要技術：
顯示層：基於HTML、JavaScript和CSS這對黃金組合。
中間件層：在此層，Salesforce引入了多租戶內核和為支撐此內核運行而經過定製的應用伺服器。
基礎設施層：雖然在後端還是使用在企業環境中很常見的Oracle資料庫，但是其為了支撐上層的多租戶內核做了很多的優化。
管理層：在安全管理方面，Salesforce提供了多層保護，並支持SSL加密等技術，除此之外，其還在帳號管理、計費管理和負載均衡這三方面有不錯地支持。
Google App Engine
App Engine屬於雲計算中的PaaS層，其主要提供一個平台，來讓用戶在Google強大的基礎設施上部署和運行應用程序，同時App Engine會根據應用所承受的負載來對應用所需的資源進行調整，並免去用戶對應用和伺服器等的維護工作，而且支持Java和Python這兩種語言。由 於App Engine屬於PaaS平台，所以關於顯示層的技術選擇由應用的自身需要而定，與App Engine無關，關於App Engine在技術層面上大致的架構。
採用的主要技術：
中間件層：既有經過定製化的應用伺服器，比如上面已經提到過的Jetty，也提供基於Memcached的分布式緩存服務。
基礎設施層： 在分布式存儲GFS的基礎上提供了NoSQL資料庫BigTable來對應用的數據進行持久化。
管理層：由於App Engine是基於Google強大的分布式基礎設施，使其在運維管理技術方面非常出色，同時其計費管理能做到非常細粒度的API級計費，而且App Engine在帳號管理和負載均衡這兩方面都有非常好地支持。
以上內容分析源自OFweek物聯網，希望對大家有幫助。