第1章 大數據與雲計算
1.2 雲計算——大數據的計算
-
雲計算按照服務類型大致可以分為三類：將基礎設施作為服務（IaaS）、將平台作為服務（PaaS）和將軟件作為服務（SaaS）
-
IaaS將硬件設備等基礎資源封裝成服務供用戶使用，如亞馬遜雲計算AWS（Amazon Web Services）的彈性計算雲EC2和簡單存儲服務S3。
-
PaaS對資源的抽象層次更進一步，它提供用戶應用程序的運行環境，典型的如GoogleApp Engine。微軟的雲計算操作系統Microsoft Windows Azure也可大致歸入這一類。
-
SaaS的針對性更強，它將某些特定應用軟件功能封裝成服務
-
雲計算技術體系結構分為四層：物理資源層、資源池層、管理中間件層和SOA（Service-Oriented Architecture，面向服務的體系結構）構建層。
第2章 Google雲計算原理與應用
2.1 Google文件系統GFS
-
2.1.1 系統架構
-
Google GFS采用廉價的商用機器構建，對硬件設施要求不高， 是分布式文件系統
-
GFS將整個系統節點分為三類角色
-
Client（客戶端）
-
Client是GFS提供給應用程序的訪問接口，以庫文件的形式提供
-
-
Master（主服務器）
-
保存元數據
-
-
Chunk Server（數據塊服務器）
-
Chunk Server負責具體的存儲工作
-
數據以文件的形式存儲在Chunk Server上， Chunk Server的個數可以有多個，它的數目直接決定了GFS的規模。GFS將文件按照固定大小進行分塊，默認是64MB，每一塊稱為一Chunk（數據塊）
-
-
控制流和數據流分離
-
-
GFS的實現機制
-
客戶端首先訪問Master節點，獲取交互的Chunk Server信息，然后訪問這些Chunk Server，完成數據存取工作。這種設計方法實現了控制流和數據流的分離。
-
Client與Master之間只有控制流，而無數據流，極大地降低了Master的負載。
-
Client與Chunk Server之間直接傳輸數據流，同時由於文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使得整個系統的I/O高度並行，系統整體性能得到提高。
-
-
GFS的特點
-
采用中心服務器模式
-
缺點：Master極易稱為整個系統性能和可靠性上的瓶頸
-
-
不緩存數據
-
數據量不大；訪問頻率高；數據更改頻率低
-
-
在用戶態下實現
-
只提供專用接口
-
-
-
2.1.2 容錯機制
-
Master容錯
-
Master
-
命名空間（Name Space），也就是整個文件系統的目錄結構。
-
Chunk與文件名的映射表。 與命名空間一塊構成日志
-
Chunk副本的位置信息，每一個Chunk默認有三個副本。 直接保存在各個Chunk Server上
-
-
-
Chunk Server容錯
-
GFS采用副本的方式實現Chunk Server的容錯，每一個Chunk有多個存儲副本（默認為三個）
-
對於每一個Chunk，必須將所有的副本全部寫入成功，才視為成功寫入
-
相關的副本出現丟失或不可恢復等情況，Master自動將該副本復制到其他Chunk Server
-
GFS中的每一個文件被划分成多個Chunk，Chunk的默認大小是64MB
-
每一個Chunk以Block為單位進行划分，大小為64KB，每一個Block對應一個32bit的校驗和
-
-
-
2.1.3 系統管理技術
-
大規模集群安裝技術
-
故障檢測技術
-
節點動態加入技術
-
節能技術
-
2.2 分布式數據處理MapReduce
-
2.2.1 產生背景
-
MapReduce現在逐漸被開源的Apache Beam取代； 處理海量數據的並行編程模式
-
-
2.2.2 編程模型
-
Map（映射）
-
Map輸入參數：in_key和in_value，它指明了Map需要處理的原始數據
-
Map輸出結果：一組<key,value>對，這是經過Map操作后所產生的中間結果
-
-
Reduce（化簡）
-
Reduce輸入參數：（key,[value1,…,valuem]）
-
Reduce工作：對這些對應相同key的value值進行歸並處理
-
Reduce輸出結果：（key, final_value），所有Reduce的結果並在一起就是最終結果
-
-
-
2.2.3 實現機制
-
（1）MapReduce函數首先把輸入文件分成M塊
-
（2）分派的執行程序中有一個主控程序Master
-
（3）一個被分配了Map任務的Worker讀取並處理相關的輸入塊
-
（4）這些緩沖到內存的中間結果將被定時寫到本地硬盤，這些數據通過分區函數分成R個區
-
（5）當Master通知執行Reduce的Worker關於中間<key,value>對的位置時，它調用遠程過程，從Map Worker的本地硬盤上讀取緩沖的中間數據
-
（6）Reduce Worker根據每一個唯一中間key來遍歷所有的排序后的中間數據，並且把key和相關的中間結果值集合傳遞給用戶定義的Reduce函數
-
（7）當所有的Map任務和Reduce任務都完成的時候，Master激活用戶程序
-
由於MapReduce在成百上千台機器上處理海量數據，容錯機制不可或缺
-
MapReduce通過重新執行失效的地方來實現容錯。失效分為：Master失效和Worker失效
-
-
-
2.2.4 案例分析
-
怎樣通過MapReduce完成排序工作，使其有序（字典序）呢？
-
第一個步驟：對原始的數據進行分割（Split）， 得到N個不同的數據分塊 。
-
第二個步驟：對每一個數據分塊都啟動一個Map進行處理。 采用桶排序的方法，每個Map中按照首字母將字符串分配到26個不同的桶中。
-
第三個步驟：對於Map之后得到的中間結果，啟動26個Reduce。 按照首字母將Map中不同桶中的字符串集合放置到相應的Reduce中進行處理。
-
-
2.3 分布式鎖服務Chubby
-
2.3.1 Paxos算法
-
Chubby是Google設計的提供粗粒度鎖服務的一個文件系統，它基於松耦合分布式系統，解決了分布的一致性問題，是一種建議性的鎖。
-
GFS使用Chubby來實現對GFS Master服務器的選取
-
Leslie Lamport 提出Paxos算法。Paxos是基於消息傳遞的一致性算法；解決分布式系統中的一致性問題；一致性算法中，該算法最常用、公認最有效
-
Paxos算法
-
三類節點
-
proposers：提出決議
-
acceptors：批准決議
-
learners：獲取並使用已經通過的決議
-
-
三個條件
-
決議只有在被proposers提出后才能批准
-
每次只批准一個決議
-
只有決議確定被批准后learners才能獲取這個決議
-
-
Proposers→acceptors→learners 少數服從多數原則，大多數； 集合論：兩組多數派至少有一個公共的acceptor； 每個acceptor只能接受一個決議
-
-
系統的約束條件
-
p1：每個acceptor只接受它得到的第一個決議。
-
p2：一旦某個決議得到通過，之后通過的決議必須和該決議保持一致。
-
p2a：一旦某個決議v得到通過，之后任何acceptor再批准的決議必須是v。
-
p2b：一旦某個決議v得到通過，之后任何proposer再提出的決議必須是v。
-
p2c：如果一個編號為n的提案具有值v，那么存在一個“多數派”，要么它們中沒有誰批准過編號小於n的任何提案，要么它們進行的最近一次批准具有值v。
-
-
為了保證決議的唯一性，acceptors也要滿足一個約束條件：當且僅當 acceptors 沒有收到編號大於n的請求時，acceptors 才批准編號為n的提案。
-
-
一個決議分為兩個階段
-
准備階段
-
proposers選擇一個提案並將它的編號設為n
-
將它發送給acceptors中的一個“多數派”
-
acceptors 收到后，如果提案的編號大於它已經回復的所有消息，則acceptors將自己上次批准的編號和value（如果有）回復給proposers，並不再批准小於n的提案。
-
-
批准階段
-
當proposers接收到acceptors 中的這個“多數派”的回復后，就向回復請求的acceptors發送accept請求（編號為n，value為v），在符合acceptors一方的約束條件下，acceptors收到accept請求后即批准這個請求。
-
-
-
-
2.3.2 Chubby系統設計
-
Chubby的設計目標主要有以下幾點: (1)高可用性和高可靠性。(2)高擴展性。(3)支持粗粒度的建議性鎖服務。(4)服務信息的直接存儲。(5)支持通報機制。(6)支持緩存機制。
-
細節問題
-
在Chubby系統中采用了建議性的鎖而沒有采用強制性的鎖。兩者的根本區別在於用戶訪問某個被鎖定的文件時，建議性的鎖不會阻止訪問，而強制性的鎖則會阻止訪問，實際上這是為了方便系統組件之間的信息交互。
-
Chubby還采用了粗粒度（Coarse-Grained）鎖服務而沒有采用細粒度（FineGrained）鎖服務，兩者的差異在於持有鎖的時間。細粒度的鎖持有時間很短，常常只有幾秒甚至更少，而粗粒度的鎖持有的時間可長達幾天，選擇粗粒度的鎖可以減少頻繁換鎖帶來的系統開銷。
-
-
Chubby的基本架構
-
客戶端
-
在客戶這一端每個客戶應用程序都有一個Chubby程序庫（Chubby Library），客戶端的所有應用都是通過調用這個庫中的相關函數來完成的。
-
-
服務器端
-
服務器一端稱為Chubby單元，一般是由五個稱為副本（Replica）的服務器組成的，這五個副本在配置上完全一致，並且在系統剛開始時處於對等地位。
-
-
-
-
2.3.3 Chubby中的Paxos
-
Paxos算法在 Chubby中起什么作用? Paxos算法在 Chubby中起到保證副本之間數據一致的作用 ( Chubby cel(單元)中的所有副本都要保持完全一致)
-
容錯日志的API實現過程
-
1.選擇一個副本成為協調者
-
2.協調者選擇一個值，通過accept廣播給所有副本
-
3.超半數副本接收值后，協調者向相關副本發送一個commit消息
-
-
Chubby不是一個完全經過理論上驗證的系統
-
-
2.3.5 通信協議
-
KeepAlive握手協議
-
可能出現的兩種故障
-
客戶端租約過期：危險事件
-
主服務器出錯：紀元號（Epoch Number）
-
-
2.4 分布式結構化數據表Bigtable
-
2.4.1 設計動機與目標
-
Bigtable是Google開發的基於GFS和Chubby的分布式存儲系統。
-
基本目標
-
廣泛的適用性
-
很強的可擴展性
-
高可用性
-
簡單性
-
-
-
2.4.2 數據模型
-
行
-
倒排便於數據壓縮，可以大幅提高壓縮率。如：com.cnn.www
-
Bigtable以子表為單位，按行存儲
-
字表：每個子表包含多個行，是數據划分和負載均衡的基本單位
-
-
列
-
族同時也是Bigtable中訪問控制（Access Control）的基本單元
-
-
時間戳
-
數據管理方式
-
保留最近N個不同版本； 保留限定時間內的所有不同版本
-
-
-
-
2.4.3 系統架構
-
Bigtable 中 Chubby 的主要作用
-
選取並保證同一時間內只有一個主服務器（Master Server）。
-
獲取子表的位置信息。
-
保存Bigtable的模式信息及訪問控制列表。
-
-
執行Open（）操作來打開一個鎖（實際上就是獲取了文件目錄）
-
客戶端主要與子表服務器通信，幾乎不和主服務器進行通信，這使得主服務器的負載大大降低；實際的數據是存儲在子表服務器上
-
-
2.4.4 主服務器
-
Bigtable中主服務器對子表服務器的監控是通過Chubby完成的
-
每個主服務器被設定了一個會話時間的限制。當某個主服務器到時退出后，管理系統就會指定一個新的主服務器，這個主服務器的啟動需要經歷以下四個步驟。 （1）從Chubby中獲取一個獨占鎖，確保同一時間只有一個主服務器。 （2）掃描服務器目錄，發現目前活躍的子表服務器。 （3）與所有的活躍子表服務器取得聯系以便了解所有子表的分配情況。 （4）通過掃描元數據表（Metadata Table），發現未分配的子表並將其分配到合適的子表服務器。
-
關鍵詞：會話時間，啟動新的主服務器
-
-
-
2.4.5 子表服務器
-
SSTable 格式的基本示意
-
Bigtable中實際的數據都是以子表的形式保存在子表服務器上的。 索引：記錄塊的位置信息、
-
SSTable是Google為Bigtable設計的內部數據存儲格式。 所有的SSTable文件都存儲在GFS上，用戶可以通過鍵來查詢相應的值。
-
SSTable中的數據被划分成一個個的塊（Block），每個塊的大小是可以設置的，一般 來說設置為64KB。在SSTable的結尾有一個索引（Index），這個索引保存了SSTable中塊 的位置信息，在SSTable打開時這個索引會被加載進內存，這樣用戶在查找某個塊時首先 在內存中查找塊的位置信息，然后在硬盤上直接找到這個塊
-
-
子表實際組成
-
每個子表都是由多個SSTable以及日志（Log）文件構成。 不同子表的SSTable可以共享。 Bigtable中的日志文件是一種共享日志，也就是說系統並不是對子表服務器上每個子表都單獨地建立一個日志文件，每個子表服務器上僅保存一個日志文件，某個子表日志只是這個共享日志的一個片段。 Bigtable規定將日志的內容按照鍵值進行排序，這樣不同的子表服務器都可以連續讀取日志文件了。
-
-
子表地址組成
-
Bigtable系統的內部采用的是一種類似B+樹的三層查詢體系
-
為了減少訪問開銷，提高客戶訪問效率，Bigtable使用了緩存（Cache）和預取（Prefetch）技術
-
子表地址→元數據表→元數據子表
-
-
Bigtable 數據存儲及讀/寫操作
-
較新的數據存儲在內存中一個稱為內存表（Memtable）的有序緩沖里，較早的數據則以SSTable格式保存在GFS中。
-
讀和寫操作有很大的差異性 數量過多的SSTable顯然會影響讀的速度
-
內存表的空間畢竟是很有限的，當其容量達到一個閾值時，舊的內存表就會被停止使用並壓縮成SSTable格式的文件。在Bigtable中有三種形式的數據壓縮，分別是次壓縮（Minor Compaction）、合並壓縮（Merging Compaction）和主壓縮（Major Compaction）。
-
三種形式壓縮之間的關系： 次壓縮的對象是單個內存表； 在Bigtable中，讀操作實際上比寫操作更重要，因此Bigtable會定期地執行一次合並壓縮的操作，將一些已有的SSTable和現有的內存表一並進行一次壓縮。 主壓縮其實是合並壓縮的一種，只不過它將所有的SSTable一次性壓縮成一個大的SSTable文件。主壓縮也是定期執行的，執行一次主壓縮之后可以保證將所有的被壓縮數據徹底刪除，如此一來，既回收了空間又能保證敏感數據的安全性（因為這些敏感數據被徹底刪除了）。
-
關鍵詞：主壓縮是合並壓縮的一種； 執行一次主壓縮后可以保證所有的被壓縮數據徹底刪除
-
-
主壓縮是合並壓縮的一種，執行一次主壓縮后可以保證所有的被壓縮數據徹底刪除
-
-
2.5 分布式存儲系統Megastore
-
2.5.1 設計目標及方案選擇
-
目標：關系型數據庫：性能和穩定性； NoSQL數據庫：便於擴展；Metastore介於二者之間
-
可用性
-
實現了一個同步的（Paxos）、容錯的、適合遠距離傳輸的復制機制
-
-
可擴展性
-
將整個大的數據分割成很多小的數據分區，每個數據分區連同它自身的日志存放在NoSQL數據庫中，具體來說就是存放在Bigtable中
-
-
ACID：原子性，一致性，隔離性和持久性
-
-
2.5.2 Megastore數據模型
-
數據模型
-
Megastore中，所有的表要么是實體組根表（Entity Group Root Table），要么是子表（Child Table）
-
Megastore實例中有若干個不同的根表，表示不同類型的實體組集
-
所有的子表必須有一個參照根表的外鍵，該外鍵通過ENTITY GROUP KEY聲明
-
-
Megastore索引
-
局部索引
-
定義在單個實體組中，作用域僅限於單個實體組（ 如PhotosByTime ）
-
-
全局索引
-
可以橫跨多個實體組集進行數據讀取操作（ 如PhotosByTag ）
-
-
-
Bigtable的列名實際上是表名和屬性名結合在一起得到，不同表中實體可存儲在同一個Bigtable行中。如User.name
-
-
2.5.3 Megastore中的事務及並發控制
-
Megastore提供的三種讀
-
current
-
總是在單個實體組中完成
-
在開始某次current讀之前，需要確保已提交的寫操作已經全部生效，然后應用程序再從最后一個成功提交的事務時間戳位置讀數據
-
-
snapshot
-
總是在單個實體組中完成
-
系統取出已知的最后一個完整提交的事務的時間戳，接着從這個位置讀數據。
-
讀的時候可能還有部分事務提交了但還未生效
-
-
inconsistent
-
忽略日志的狀態直接讀取最新的值
-
適用於要求低延遲並能忍受數據過期或不完整的讀操作
-
-
-
Megastore的寫操作
-
預寫式日志
-
只有當所有的操作都在日志中記錄下后，寫操作才會對數據執行修改。
-
一個寫事務總是開始於一個current讀，以便確認下一個可用的日志位置
-
提交操作將數據變更聚集到日志，接着分配一個比之前任意一個都高的時間戳，然后使用Paxos將數據變更加入日志中。
-
協議：樂觀並發
-
-
-
Megastore中的事務機制
-
Megastore中事務間的消息傳遞通過隊列（Queue）實現
-
兩階段提交：請求階段和提交階段
-
Megastore中的消息能夠橫跨實體組，在一個事務中分批執行多個更新或者延緩作業； 在單個實體組上執行的事務除了更新它自己的實體外，還能夠發送或收到多個信息； 每個消息都有一個發送和接收的實體組； 如果這兩個實體組是不同的，那么傳輸將會是異步的
-
-
-
2.5.4 Megastore基本架構
-
在Megastore中共有三種副本： 完整副本、見證者副本、只讀副本
-
快速讀與快速寫
-
快速讀
-
利用本地讀取實現
-
協調者是一個服務
-
-
快速寫
-
如果一次寫成功，那么下一次寫的時候就跳過准備過程，直接進入接受階段
-
復制服務器會定期掃描
-
-
-
-
2.5.5 核心技術——復制
-
復制的日志
-
即使這些數據記錄正從一個之前的故障中恢復數據，副本也要保證其能夠參與到寫操作中的Paxos算法。
-
-
數據讀取
-
追趕：在一次Current讀之前，要保證至少有一個副本上的數據是最新的，所有之前提交到日志中的更新必須復制到該副本上並確保在該副本上生效
-
-
2.6 大規模分布式系統的監控基礎架構Dapper
-
2.6.1 基本設計目標
-
兩個基本要求
-
-
廣泛可部署性
-
-
-
不間斷的監控
-
-
-
三個基本設計目標
-
低開銷
-
對應用層透明
-
可擴展性
-
-
-
2.6.2 Dapper監控系統簡介
-
兩種監控方案
-
黑盒：輕便，基於統計學，不准確
-
基於注釋的監控：利用應用程序或中間件給每條記錄賦予一個全局性的標示符
-
-
Dapper監控系統的三個基本概念
-
監控樹
-
一個同特定事件相關的所有消息
-
-
區間
-
區間實際上就是一條記錄 每個區間包括： 區間名(Span Name) 區間id(Span id) 父id(Parent id) 監控id(Trace id)
-
通過父id才能夠對樹中不同區間的關系進行重建
-
一棵監控數中所有區間的監控id是相同的，這個id是隨機分配的，並且在整個Dapper中是唯一的。
-
雙主機區間：最常見，每個RPC區間都包含來自於客戶端和服務器端的注釋
-
-
注釋
-
注釋主要用來輔助推斷區間關系，也可以包含一些自定義的內容
-
注釋方式：文本方式、鍵值對
-
-
-
監控信息的匯總
-
三個步驟
-
（1）將區間的數據寫入到本地的日志文件
-
（2）所有機器上的本地日志文件匯集
-
（3）匯集后的數據寫入到Bigtable存儲庫中
-
寫入數據后的Bigtable中，單獨的一行表示一個記錄，而一列則相當於一個區間。
-
-
-
-
-
2.6.3 關鍵性技術
-
輕量級核心功能庫
-
小規模庫
-
通用線程
-
控制流
-
RPC代碼庫
-
-
主要功能是實現區間創建、抽樣和在本地磁盤上記錄日志。
-
保證了Dapper的監控過程基本對應用層透明。
-
-
二次抽樣技術
-
解決了低開銷及廣泛可部署性的問題。
-
海量數據，關注的事件出現的次數足夠多 統一抽樣率：不利於流量較低的服務，可能忽略關鍵性事件，遂采用適應性抽樣率
-
-
2.7 海量數據的交互式分析工具Dremel
-
2.7.1 產生背景
-
MapReduce
-
優點：便攜
-
缺點：效率低
-
-
開發實時的交互式查詢系統Dremel
-
Dremel不開源，但是提供BigQuery服務 MapReduce←→Hadoop Dremel←→Apache Drill
-
-
2.7.2 數據模型
-
Google的數據平台需滿足
-
通用性；實時交互查詢
-
兩方面的技術支撐
-
統一的存儲平台
-
統一的數據存儲格式
-
-
-
是第一個在嵌套數據模型基礎上實現列存儲的系統。 關鍵詞：嵌套模型
-
處理時只需要使用涉及的列數據
-
列存儲更利於數據的壓縮
-
-
嵌套模型的形式化定義
-
記錄型數據包括三種類型：必須的（Required）、可重復的（Repeated）以及可選的（Optional）
-
屬性通過完整的路徑表示，如Name.Language.Code
-
字符τ是一個數據類型的定義，可以是原子類型，也可以是記錄類型 Ai代表該τ的命名，即Ai就是某個τ類型的變量
-
原子類型（Atomic Type）
-
原子類型允許的取值類型包括整型、浮點型、字符串等
-
-
記錄類型（Record Type）
-
記錄類型則可以包含多個域，是使用遞歸方式定義的，即τ能夠由其余以前定義好的τ組成，就像c中的結構體，與結構體不大相同的是，每一個包含的τ的值能夠有多個（*，repeated，相似c中的數組），還能夠是可選的（?，optional，以前那個數組能夠不包含任何元素）
-
-
-
-
2.7.3 嵌套式的列存儲
-
數據結構的無損表示
-
Dremel定義了兩個變量：r（Repetition Level，重復深度）和d（Definition Level，定義深度）
-
-
數據重組
-
Dremel數據重組方法的核心思想是為每個字段創建一個有限狀態機（FSM），讀取字段值和重復深度，然后順序地將值添加到輸出結果上。
-
-
第3章 Amazon雲計算AWS
3.1 基礎存儲架構Dynamo
-
3.1.1 Dynamo概況
-
為了保證其穩定性，Amazon的系統采用完全的分布式、去中心化的架構
-
作為底層存儲架構的Dynamo也同樣采用了無中心的模式
-
Dynamo只支持簡單的鍵/值（key/value）方式的數據存儲，不支持復雜的查詢
-
Dynamo中存儲的是數據值的原始形式，即按位存儲，並不解析數據的具體內容,這使得Dynamo幾乎可以存儲所有類型的數據
-
-
3.1.2 Dynamo架構的主要技術
-
Dynamo需要解決的主要問題及解決方案
-
數據均衡分布：改進的一致性哈希算法
-
數據備份：參數可調的弱quorum機制
-
數據沖突處理：向量時鍾
-
成員資格及錯誤檢測：基於Gossip協議的成員資格和錯誤檢測
-
臨時故障處理: Hinted handoff（數據回傳機制）
-
永久故障處理:Merkle哈希樹
-
-
Dynamo的存儲節點
-
Dynamo中的存儲節點呈無中心的環狀分布。
-
兩個基本概念
-
preference list：存儲與某個特定鍵值相對應的數據的節點列表
-
coordinator：執行一次讀或寫操作的節點
-
通常，coordinator 是 preference list 上的第一個節點
-
-
-
1.數據均衡分布的問題
-
Dynamo中使用改進后的一致性哈希算法
-
1）一致性哈希算法
-
一致性哈希算法是目前主流的分布式哈希表（Distributed Hash Table，DHT）協議之一，於1997年由麻省理工學院提出。 一致性哈希算法通過修正簡單哈希算法，解決了網絡中的熱點問題，使得DHT可以真正地應用於P2P環境中。
-
一致性哈希算法除了能夠保證哈希運算結果充分分散到整個環上外，還能保證在添加或刪除設備節點時只會影響到其在哈希環中的前驅設備節點，而不會對其他設備節點產生影響。
-
一致性哈希算法可以大大降低在添加或刪除節點時引起的節點間的數據傳輸開銷
-
-
2）改進的一致性哈希算法
-
缺點：一致性哈希算法在設備節點數量較少的情況下，有可能造成環上節點分布的不均勻；並且沒有考慮哈希環上不同設備節點的性能差異。
-
Dynamo中引入了虛擬節點的概念
-
每個虛擬節點都隸屬於某一個實際的物理節點，一個物理節點根據其性能的差異被分為一個或多個虛擬節點。
-
各個虛擬節點的能力基本相當，並隨機分布在哈希環上。
-
數據對象先按照其鍵的哈希值被分配到某個虛擬節點上，並存儲在該虛擬節點所對應的物理節點中
-
進一步提高數據均衡分布的均衡性
-
Dynamo將整個哈希環划分成Q等份，每個等份稱為一個數據分區（Partition）
-
數據分區的好處
-
減小數據分布不均衡的可能性
-
添加或刪除設備節點時引起較小的數據傳輸
-
-
隨着節點的增加，特別是S接近Q后，Dynamo的性能會急劇下降。需要選擇好Q的取值
-
-
-
-
2.數據備份
-
為了提高數據的可用性，Dynamo中在存儲每個數據對象時，保存了其多個副本作為冗余備份。假設每個數據對象保存在系統中的副本數為N（通常為3），考慮到存在節點失效的情況，preference list中節點的個數大於N，並且為實際的物理節點。
-
-
3.數據沖突問題
-
分布式系統架構中通常考慮的三個因素:可靠性、可用性、一致性
-
Dynamo選擇通過犧牲一致性來保證系統的可靠性和可用性，沒有采用強一致性模型而采用了最終一致性模型。
-
由於Dynamo中可能出現同一個數據被多個節點同時更新的情況，且無法保證數據副本的更新順序，這有可能會導致數據沖突。
-
數據沖突問題如何解決
-
常用的解決沖突的方案有兩種： 通過客戶端由用戶來解決； 系統自動選擇時間戳最近的版本；由於集群內的各個節點並不能嚴格保證時鍾同步，所以不能完全保證最終版本的准確性。向量時鍾的數量是有限制的，當超過限制時將會根據時間戳刪除最早的向量時鍾
-
-
-
4.成員資格及錯誤檢測
-
為了保證每個節點都能擁有最新的成員節點信息，Dynamo中采用了一種類似於Gossip（閑聊）協議的技術，每個節點間隔固定時間（1秒）從其他節點中任意選擇一個與之通信
-
Dynamo中還通過Gossip來實現錯誤檢測。 任何節點向其他節點發起通信后，如果對方沒有回應，則認為對方節點失效，並選擇別的節點進行通信，如果對方有回應，則可以重新建立通信
-
倒的二叉樹，樹高為logn，即時間復雜度為logn
-
-
5.容錯機制
-
廉價服務器，物理節點失效作為常態處理
-
臨時故障處理機制
-
帶有監聽的數據回傳機制
-
-
永久性故障處理機制
-
節點失效超過設定時間仍不能重用，認定為永久性故障
-
Dynamo采用Merkle哈希樹技術來加快檢測和減少數據傳輸量
-
-
-
3.2 彈性計算雲EC2
-
3.2.1 EC2的基本架構
-
主要包括了Amazon機器映象、實例、存儲模塊等組成部分
-
Amazon機器映象（AMI）
-
四種獲取AMI的途徑
-
免費使用Amazon提供的公共AMI
-
根據自身需要定制一個或多個私有AMI
-
向開發者付費購買AMI
-
使用其他開發者分享的共享AMI
-
-
-
實例
-
EC2中實例由AMI啟動，可以像傳統的主機一樣提供服務。同一個AMI可以用於創建具有不同計算和存儲能力的實例。
-
Amazon提供了多種不同類型的實例，分別在計算、GPU、內存、存儲、網絡、費用等方面進行了優化
-
-
彈性塊存儲（EBS）
-
EBS存儲卷的設計與物理硬盤相似，其大小由用戶設定，目前提供的容量從1GB到1TB不等。同一個實例可以連接多個EBS，每個EBS同一時刻只能連接一個實例
-
EBS存儲卷適用於數據需要細粒度地頻繁訪問並持久保存的情形，適合作為文件系統或數據庫的主存儲。
-
快照功能是EBS的特色功能之一，用於在S3中存儲Amazon EBS卷的時間點副本。
-
-
-
3.2.2 EC2的關鍵技術
-
地理區域和可用區域
-
地理區域：按照實際的地理位置划分
-
可用區域：是否有獨立的供電系統和冷卻系統等
-
EC2系統中包含多個地理區域，而每個地理區域中又包含多個可用區域。
-
-
EC2的通信機制
-
IP地址
-
公共IP地址
-
私有IP地址
-
公有私有IP通過網絡地址轉換技術實現轉換; EC2的實例一旦被創建就會動態地分配公共IP地址和私有IP地址: 私有IP地址由動態主機配置協議（DHCP）分配產生
-
彈性IP地址
-
-
-
彈性負載平衡
-
允許EC2實例自動分發應用流量;支持容錯；識別狀態，重新分配流量
-
-
監控服務
-
監控EC2實例狀態、資源利用率、需求狀況、CPU利用率、磁盤讀取、寫入和網絡流量等指標
-
用戶只需要選擇EC2實例，設定監視時間，CloudWatch就可以自動收集和存儲檢測數據
-
-
自動縮放
-
自動縮放可以按照用戶自定義的條件，自動調整EC2的計算能力： 在需求高峰期時，該功能可以確保EC2實例的處理能力無縫增大； 在需求下降時，自動縮小EC2實例規模以降低成本。 自動縮放功能特別適合周期性變化的應用程序，它由CloudWatch自動啟動。
-
-
服務管理控制台
-
基於web的控制環境，用於啟動、管理EC2實例和提供各種管理工具和API接口。
-
-
-
3.2.3 EC2的安全及容錯機制
-
EC2采用了安全組（Security Group）技術。 安全組是一組規則，用戶利用這些規則來決定哪些網絡流量會被實例接受，其他則全部拒絕。
-
用戶在訪問EC2時需要使用SSH（Secure Shell）密鑰對（Key Pair）來登錄服務。 當用戶創建一個密鑰對時，密鑰對的名稱（Key Pair Name）和公鑰（Public Key）會被存儲在EC2中。 在用戶創建新的實例時，EC2會將它保存的信息復制一份放在實例的元數據（Metadata）中，然后用戶使用自己保存的私鑰（Private Key）就可以安全地登錄EC2並使用相關服務。
-
關鍵詞：元數據、私鑰
-
-
3.3 簡單存儲服務S3
-
3.3.1 S3的基本概念和操作
-
簡單存儲服務（Simple Storage Services，S3）構架在Dynamo之上，用於提供任意類型文件的臨時或永久性存儲。S3的總體設計目標是可靠、易用及低成本。
-
兩個基本概念
-
桶：桶的名稱全局唯一
-
對象：S3的基本存儲單元，由數據和元數據組成
-
每個對象在所在的桶中有唯一的鍵（key）。通過將桶名和鍵相結合的方式，可以標識每個對象。
-
鍵在對象創建后無法被更改，即重命名對於S3中的對象是無效的。
-
-
-
-
S3中支持對桶和對象的操作，主要包括：Get、Put、List、Delete和Head。
-
3.3.2 S3的數據一致性模型
-
與其構建的基礎Dynamo相同，S3中采用了：最終一致性模型；創建新的對象、替換、刪除，返回原數據，則出現不一致情況
-
-
3.3.3 S3的安全措施
-
身份認證
-
S3中使用基於HMAC-SHA1的數字簽名方式來確定用戶身份。HMAC-SHA1是一種安 全的基於加密Hash函數和共享密鑰的消息認證協議，它可以有效地防止數據在傳輸過程 中被截獲和篡改，維護了數據的完整性、可靠性和安全性。HMAC-SHA1消息認證機制的 成功在於一個加密的Hash函數、一個加密的隨機密鑰和一個安全的密鑰交換機制。在新 用戶注冊時，Amazon會給每個用戶分配一個Access Key ID和一個Secret Access Key。 Access Key ID是一個20位的由字母和數字組成的串，Secret Access Key是一個40位的字符 串。Access Key ID用來確定服務請求的發送者，而Secret Access Key則參與數字簽名過 程，用來證明用戶是發送服務請求的賬戶的合法擁有者。
-
-
訪問控制列表（ACL）
-
訪問控制列表是S3提供的可供用戶自行定義的訪問控制策略列表。
-
權限：WRITE_ACP相當於擁有所有權限
-
S3的ACL不具有繼承性：桶和對象的ACL是各自獨立的，對桶有某種訪問權限不代表對桶中的對象也具有相同的權限。
-
-
S3中有三大類型的授權用戶
-
所有者（Owner）
-
所有者是桶或對象的創建者，默認具是WRITE_ACP權限。
-
所有者默認就是最高權限擁有者。
-
-
個人授權用戶（User）
-
兩種授權方式，
-
-
通過電子郵件地址授權，即授權給和某個特定電子郵件地址綁定的AWS用戶；
-
-
-
通過用戶ID進行授權，即直接授權給擁有某個特定AWS ID的用戶。
-
-
通過電子郵件地址方式授權的方法最終還是在S3服務器內部轉換成相應的用戶ID進行授權
-
-
組授權用戶（Group）
-
一種是AWS用戶組，它將授權分發給所有AWS賬戶擁有者；
-
另一種是所有用戶組，允許匿名訪問，是一種有着很大潛在危險的授權方式。
-
-
-
3.4 非關系型數據庫服務SimpleDB和DynamoDB
-
3.4.1 非關系型數據庫與傳統關系數據庫的比較
-
S3：提供任意類型文件的臨時或永久性存儲 非關系型數據庫SimpleDB和DynamoDB：存儲結構化數據，並為這些數據提供查找、刪除等基本的數據庫功能
-
關系型數據庫：具有高一致性，在ACID方面很強，移植性很高，但可擴展性方面能力較弱
-
非關系型數據庫:具有很高的可擴展性，具有很好的並發處理能力，但缺乏數據一致性保證，處理事務性問題能力較弱，且難以處理跨表、跨服務器的查詢
-
-
3.4.2 SimpleDB
-
SimpleDB基本結構包含了域、條目、屬性、值等概念。
-
SimpleDB存儲的數據范圍極其有限
-
-
3.4.3 DynamoDB
-
DynamoDB以表為基本單位，表中的條目同樣不需要預先定義的模式。
-
DynamoDB中取消了對表中數據大小的限制，用戶設置任意大小，並由系統自動分配到多個服務器上。
-
-
3.4.4 SimpleDB和DynamoDB的比較
-
SimpleDB：限制了每張表的大小，更適合於小規模復雜的工作。自動對所有屬性進行索引，提供了更加強大的查詢功能。
-
DynamoDB：支持自動將數據和負載分布到多個服務器上，並未限制存儲在單個表中數據量的大小，適用於較大規模負載的工作。
-
3.5 關系數據庫服務RDS
-
3.5.1 RDS的基本原理
-
非關系數據庫在處理ACID類問題時存在一些先天性的不足，為了滿足相關應用的需求，Amazon提供了相關數據庫服務（Relational Database Service，RDS）
-
Amazon RDS將MySQL數據庫移植到集群中，在一定的范圍內解決了關系數據庫的可擴展性問題。
-
MySQL集群方式采用了Share-Nothing架構。
-
每台數據庫服務器都是完全獨立的計算機系統，通過網絡相連，不共享任何資源。
-
集群MySQL通過表單划分的方式將一張大表划分為若干個小表，分別存儲在不同的數據庫服務器上，從邏輯上保證了數據庫的可擴展性
-
集群MySQL通過主從備份和讀副本技術提高可靠性和數據處理能力。癱瘓、升級、並發處理
-
-
3.5.2 RDS的使用
-
就是mysql擴展到集群上
-
3.6 簡單隊列服務SQS
-
3.6.1 SQS的基本模型
-
解決不同組件之間的通信，包含三個組成部分
-
系統組件
-
系統組件是SQS的服務對象
-
-
隊列
-
隊列是存放消息的容器，類似於S3中的桶
-
隊列在傳遞消息時會盡可能 “先進先出”
-
-
消息
-
消息的大小是有限制的，但是消息的數量並未做限制
-
SQS允許用戶在消息中添加有關的序列數據、
-
-
-
-
3.6.2 SQS的消息
-
由以下四部分組成：消息ID、接收句柄、消息體、消息體MD5摘要
-
消息取樣
-
隊列中的消息是被冗余存儲的
-
為了解決該問題，SQS采用了基於加權隨機分布的消息取樣
-
-
消息的可見性超時值及生命周期
-
如果用戶未接收到數據或接收到數據並沒有執行刪除操作，SQS將在隊列中保留該消息 為了保證其他組件不會看見用戶的消息，SQS會將該消息阻塞，也就相當於給消息加了一把鎖。但是這把鎖並不會一直鎖住消息，因為系統保留消息的目的是給用戶重傳數據。 為此SQS引入了一個可見性超時值（Visibility Timeout）
-
可見性表明該消息可以被所有的組件查看，可見性超時值相當於一個計時器，在設定好的時間內，發給用戶的消息對於其他所有的組件是不可見的。 如果在計時器到時之前用戶一直未執行刪除操作，則SQS會將該消息的狀態變成可見並給用戶重傳這個消息。 可見性超時值可以由用戶自行設置，用戶可以根據自己操作的需要改變這個值，太長或太短的超時值都不合適。 計數器計時過程中可以對計時器進行兩種操作：擴展和終止。
-
-
3.7 內容推送服務CloudFront
-
3.7.1 CDN
-
DNS在對域名進行解析時不再向用戶返回網站服務器的IP，而是返回了由智能CDN負載均衡系統選定的某個邊緣節點的IP。
-
CDN的實現需要多種網絡技術的支持，主要包括以下幾種：
-
負載均衡技術
-
分布式存儲
-
緩存技術
-
-
-
3.7.2 CloudFront
-
CloudFront的收費方式: 按用戶實際使用,使用非常簡單
-
第4章 微軟雲計算Windows Azure
4.1 微軟雲計算平台
-
微軟的雲計算服務平台Windows Azure屬於PaaS模式， 一般面向的是軟件開發商。 當前版本的Windows Azure平台包括4個組成部分
-
Windows Azure：雲計算操作系統。底層架構
-
SQL Azure：雲中的關系數據庫，提供結構化服務
-
Windows Azure AppFabric：提供基於雲的基礎架構服務。提供應用
-
Windows Azure Marketplace：提供購買服務
-
4.2 微軟雲操作系統Windows Azure
-
4.2.1 Windows Azure概述
-
微軟雲計算戰略的核心——雲計算操作系統
-
Windows Azure包括五個部分
-
計算服務
-
為在Azure平台中運行的應用提供支持。
-
-
存儲服務
-
主要用來存儲二進制和結構化的數據。可以存儲大型二進制對象Blobs，並提供消息隊列用於應用組件間的通信，還提供一種表形式存儲結構化數據
-
-
Fabric控制器
-
主要用來部署、管理和監控應用。
-
-
內容分發網絡CDN
-
提高全球用戶訪問Windows Azure存儲中的二進制數據的速度
-
-
Windows Azure Connect
-
在本地計算機和Windows Azure之間創建IP級連接，使本地應用和Azure平台相連; 本地計算機和邊緣節點相連
-
-
-
-
4.2.2 Windows Azure計算服務
-
Windows Azure應用程序包括Web Role實例、Worker Role實例和VM Role實例
-
Web Role
-
基於Web Role可以使基於Web的應用創建過程變得簡單 開發者可以使用非微軟的技術，如PHP、Java等
-
-
Worker Role
-
Worker Role用來運行各種各樣的基於Windows的代碼。 應用通過Web Role與用戶相互作用，然后用worker Role進行任務處理
-
-
VM Role
-
VM Role運行系統提供的Windows Server 2008 R2鏡像。 幫助將本地的Windows Server應用移到Windows Azure。
-
-
Web Role和Worker Role的最大不同在於：Worker Roles內部沒有安裝IIS，所以IIS並沒有托管 Worker Roles運行的代碼
-
-
-
4.2.3 Windows Azure存儲服務
-
Windows Azure四種主要的數據存儲結構
-
Blob
-
存儲二進制數據，相當於亞馬遜S3
-
-
Table
-
提供更加結構化的數據存儲,相當於谷歌BigTable非關系型數據庫
-
-
Queue
-
和微軟消息隊列相近，支持組件之間的通信
-
-
File
-
共享文件數據
-
-
-
存儲名空間被划分為三部分：
-
賬戶名（AccountName）
-
DNS主機名的一部分，是客戶為訪問存儲而選擇的賬戶名 可以將訪問請求定位到集群
-
-
分區名（PartitionName）
-
使用賬戶名定位存儲集群后，在集群內將數據訪問請求進一步定位到存儲節點
-
-
對象名（ObjectName）
-
用來對分區中的多個對象進行區分。 對一些類型的數據，分區名可以唯一標識賬戶里的對象時，對象名就變得可要可不要了
-
-
-
體系架構
-
存儲域：N個裝滿存儲節點的存儲櫃構成的一個集群，每個集群擁有10～20個存儲櫃，每個存儲櫃由18個掛滿磁盤的存儲節點構成。 每個存儲櫃都有單獨的冗余網絡和電源實現的容錯保護機制。
-
位置服務：管理所有的存儲域，同時負責不同的存儲域之間的賬戶名空間管理。 把賬戶分配到各個存儲域上，並實現跨存儲域管理這些賬戶來支持災難恢復和負載平衡 它自身也放在兩個不同的地理位置來實現自身的容災
-
-
存儲域的層次結構
-
前端
-
由一組無狀態服務器構成來處理訪問請求 一旦接收到一個請求，該層會查找賬戶名，認證請求，再把請求路由到分區層的服務器
-
-
分區層
-
域間操作，負責管理和理解上層數據抽象類型（Blog、表、隊列和文件），提供一個可擴展的名空間，保證數據對象事務處理順序和強一致性，在數據流層之上存儲數據，緩存數據對象來減少磁盤I/O
-
-
文件流層
-
針對某個存儲域進行域內復制，存儲數據在磁盤上，負責在多個服務器間分布和復制數據來保持存儲域中數據的可用性。 該層可以被認為是存儲域內的分布式文件系統層。
-
-
-
雙復制引擎
-
為了實現數據高可用，WAS通過在文件流層進行域內數據復制和在分區層進行域間數據復制，實現必要的數據容災保護機制。
-
域內復制
-
WAS在文件流層實現同步復制，保證存儲域內的所有數據寫在其內部是可靠的。
-
-
域間復制
-
在對象級進行，對給定賬戶的整個對象或最近的差分更新進行復制
-
-
用戶請求關鍵路徑上的低延遲域內復制至關重要 域間復制在充分使用網絡貸款的條件下，保持可接受的復制延遲
-
-
文件流層
-
包括流管理器和區塊節點
-
文件流層提供一個只為分區層使用的內部接口，具有類似文件系統的名空間和應用接口，但所有的寫只能追加。 用戶可允許對稱為流（Stream）的大文件進行打開、關閉、刪除、重命名、讀、追加寫以及合並等操作。 一系列追加的塊（Block）被稱為區塊（Extent），流就是一連串有序區塊的指針列表。 文件流層包括流管理器（Stream Manager，SM）和區塊節點（Extent Node，EN）兩大部分
-
流管理器：負責管理文件流的名空間、流到區塊的映射，以及區塊到存儲節點的分配信息。流管理器周期性地同步區塊節點的狀態和節點上所存的區塊，並保持區塊有期望的副本數目
-
流只能夠追加寫，已有的數據不能再修改。
-
追加寫是以數據塊為單位的原子操作，也可以一次追加寫多個塊。
-
每個追加寫操作將相應的區塊復制三份，分別存放在不同的區塊節點上。
-
WAS追加寫的操作流程如下。 步驟1：客戶端將追加寫請求發送到主區塊節點，主節點確定追加寫在區塊內的偏移量。 步驟2：當同一區塊有多個並發追加寫請求時，對所有追加寫請求進行排序。 步驟3：發送追加寫請求到兩個次區塊節點，並附上選定的區塊偏移量。步驟4：當三個區塊節點都成功追加寫內容到磁盤后，反饋寫成功消息給客戶端。
-
在區塊節點內 數據的追加寫操作步驟如下。 步驟1：將所有數據追加寫到日志盤。 步驟2：對數據盤上的區塊追加寫請求進行隊。 步驟3：如果日志操作先完成，則數據被緩存在內存中。 步驟4：一旦寫成功就返回。
-
日志盤：文件流層讓每個區塊節點保留一個磁盤或者固態硬盤來充當日志盤，記錄節點所有追加寫操作的日志信息
-
-
-
分區層
-
分區層能夠提供：不同存儲對象類型的數據模型，不同類型對象處理的邏輯和語義，大規模擴展的對象命名空間，跨多個可用分區服務器訪問對象的負載平衡，以及訪問對象的事務排序和強一致性。
-
分區層提供一種重要的內部數據結構——對象表（Object Table）。類似BigTable字表作用
-
分區層包括三個主要的體系結構模塊
-
分區管理器
-
負責保存對象表到分區段的划分和每個分區段到相應分區服務器的分配情況。 負責分區服務器之間的負載平衡。
-
-
分區服務器
-
負責處理由分區管理器分配給它的一組分區段的請求。
-
-
鎖服務
-
Paxos鎖服務用於分區服務器的主服務器選舉。 此外，每個分區服務器為服務分區也保持鎖服務租賃。
-
-
-
負載分散
-
控制存儲域內分區的總數
-
划分
-
合並
-
-
負載平衡
-
當給定的分層管理器負載過高時，將一個或多個分區段重新分配到其他負載較低的分區服務器。
-
-
-
-
-
4.2.4 Windows Azure Connect
-
Connect在Windows Azure應用和本地運行的機器之間建立一個基於IPsec協議的連接，使兩者更容易結合起來使用
-
終端代理使用IPsec連接應用中的一個具體的Role。
-
Connect創建完成之后，Windows Azure應用中的Roles將會和本地的機器一樣顯示在同一個IP網絡中，並允許以下兩個事件
-
（1）Windows Azure應用能夠直接訪問本地的數據庫。
-
（2）Windows Azure應用能夠區域連接到本地環境。
-
-
-
4.2.5 Windows Azure CDN
-
為了提高訪問性能，Windows Azure提供了一個內容分發網絡CDN（Content Delivery Network）。這個CDN存儲了距離用戶較近的站點的Blobs副本。Blob所存放容器都能夠被標記為Private或Public READ；Windows Azure CDN只對存儲在“Public READ”Blob上的容器起作用。
-
-
4.2.6 Fabric控制器
-
又稱結構控制器；在數據中心中， Windows Azure的機器集合和運行在這些機器上的軟件均由Fabric控制器控制。
-
Fabric控制器是一個分布式應用，擁有計算機、交換機、負載均衡器等各種資源。
-
4.3 微軟雲關系數據庫SQL Azure
-
4.3.1 SQL Azure概述
-
SQL Azure提供了關系型數據庫存儲服務，包含三部分
-
SQL Azure數據庫
-
提供了一個雲端的數據庫管理系統（DBMS），這使得本地應用和雲應用可以在微軟數據中心的服務器上存儲數據。
-
-
SQL Azure報表服務
-
SQL Server Reporting Service（SSRS）的雲化版本。主要是用SQL Azure數據庫提供報表服務，允許在雲數據中創建標准的SSRS報表
-
-
SQL Azure數據同步
-
允許同步SQL Azure數據庫和本地SQL Server數據庫中的數據，也能夠在不同的微軟數據中心（不同存儲域之間的同步）之間同步不同的SQL Azure數據庫。
-
-
-
-
4.3.2 SQL Azure關鍵技術
-
SQL Azure數據庫
-
SQL Azure數據庫是SQL Azure的一種雲服務，提供了核心的SQL Server數據庫功能。
-
SQL Azure 數據庫支持TDS（表格格式數據流）和Transact-SQL（T-SQL）
-
SQL Azure與SQL Server的差別
-
SQL Azure缺點
-
SQL Azure省略了SQL Server中的一些技術點，比如SQL CLR（Current Language Runtime，公共語言運行時）、全文本搜索技術等
-
用戶沒有底層管理功能，所有管理功能都由微軟實現。
-
用戶不能直接關閉自身運行的系統，也不能管理運行應用的硬件設施。
-
-
SQL Azure優點
-
SQL Azure運行環境比較穩定
-
應用獲取的服務比較健壯
-
存儲的所有數據均備份了3份
-
-
-
-
SQL Azure報表服務
-
基於SQL Server報表服務（SSRS，SQL Server Reporting Services）實現SQL Azure報表服務。現在SQL Azure Reporting主要有兩個使用場景： 一、SQL Azure報表服務創建的報表可以發布到某一個門戶上，雲端用戶可以訪問這個門戶的報表，也可以通過URL地址直接訪問報表； 二、ISV（Independent Software Vendor，獨立的軟件開發商）能夠嵌入發布到SQL Azure報表門戶的報表。
-
SQL Azure Reporting與SSRS
-
共同點：SQL Azure Reporting與SSRS的報表格式是相同的，都使用微軟定義的RDL
-
不同點：SQL Azure Reporting並沒有實現本地情況下SSRS提供的所有的功能。如不支持調度和訂閱功能，這使得報表每隔一定的時間將會運行和分發一次
-
-
-
SQL Azure數據同步
-
“輪輻式（hub-and-spoke）”模型，所有的變化將會首先被復制到SQL Azure數據庫“hub”上，然后再傳送到其他“spoke”上。
-
該技術主要包括以下兩個方面。
-
（1）SQL Azure數據庫與SQL Server數據庫之間的數據同步。注意：網絡故障、數據調度、數據丟失
-
（2）SQL Azure數據庫之間的同步。需滿足高性能需求
-
-
-
-
4.3.3 SQL Azure和SQL Server對比
-
1．物理管理和邏輯管理
-
SQL Azure能夠自動復制所有存儲的數據以提供高可用性
-
SQL Azure還可以管理負載均衡、故障轉移等功能
-
用戶不能管理SQL Azure的物理資源
-
SQL Azure不能使用SQL Server備份機制，所有的數據都是自動復制備份的
-
-
2．服務提供
-
部署SQL Azure時，准備和配置所需要的硬件和軟件均由SQL Azure服務程序來執行
-
用戶在Windows Azure平台上創建了一個賬戶后便可以使用SQL Azure數據庫
-
每個SQL Azure訂閱都會綁定到微軟數據中心的某個SQL Azure服務器上
-
-
3．Transact-SQL支持
-
大多數SQL Server Transact-SQL語句都有一些參數，但適用於SQL Azure
-
-
4．特征和類型
-
SQL Azure不支持SQL Server的所有特征和數據類型
-
SQL Azure提供物理管理，會鎖住任何試圖操作物理資源的命令語句
-
另外還有一些操作是不允許的，比如設置服務器選項和SQL追蹤標簽、使用SQL Server分析器或使用“數據庫引擎優化顧問”
-
-
4.4 Windows Azure AppFabric
-
4.4.1 AppFabric概述
-
AppFabric為本地應用和雲中應用提供了分布式的基礎架構服務，使用戶本地應用與雲應用之間進行安全聯接和信息傳遞
-
AppFabric目前主要提供互聯網服務總線（Service Bus）、訪問控制（Access Control）服務和高速緩存服務。
-
-
4.4.2 AppFabric關鍵技術
-
服務總線
-
注冊步驟
-
1.注冊服務總線終端
-
2.顯示服務總線終端
-
3.發現服務總線終端
-
4.調用服務總線終端的操作
-
5.調用服務終端的操作
-
-
用戶服務需要使用AppFabric服務總線的開放TCP連接顯示終端，並保持這個連接一直處於開放的狀態，這就解決了兩個問題：
-
服務總線上的開放連接可以路由到應用程序
-
通過連接將消息傳回應用時防火牆不會阻止該消息
-
-
-
訪問控制
-
步驟1：用戶打算通過瀏覽器訪問應用
-
步驟2：如果應用接受IdP令牌（Token），那么將重新定位瀏覽器到這個IdP（Identity Providers）。用戶使用IdP來進行授權，比如通過輸入用戶名和密碼的方式來進行授權，IdP返回的令牌包含申明信息
-
步驟3：用戶瀏覽器發送IdP Token到訪問控制中去
-
步驟4：訪問控制驗證接受到的IdP Token，其次根據事先定義好的應用規則來創建一個新的Token
-
步驟5：訪問控制包含了一個規則引擎，允許每個應用管理員定義不同的IdPs Token轉換到AC（Access Control）Token方式。最后訪問控制將AC Token返回到瀏覽器
-
步驟6：再由瀏覽器將這個新的Token發送給應用
-
步驟7：一旦應用獲得了AC Token，可以驗證這個Token並使用其中所包含的聲明
-
-
高速緩存
-
本地緩存提高訪問效率
-
-
第7章虛擬化技術
7.1虛擬化技術簡介
-
虛擬化意味着對計算機資源的抽象。構建雲計算環境的一項關鍵技術。
-
主要用於當時的IBM大型機的服務器虛擬化，虛擬化技術的核心思想是利用軟件或固件管理程序構成虛擬化層，把物理資源映射為虛擬資源。在虛擬資源上可以安裝和部署多個虛擬機，實現多用戶共享物理資源。
-
數據中心的虛擬化
-
作用
-
實現資源的動態分配和調度，提高現有資源的利用率和服務可靠性
-
提供自動化的服務開通能力，降低運維成本
-
具有有效的安全機制和可靠性機制，滿足公眾客戶和企業客戶的安全需求
-
方便系統升級、遷移和改造
-
-
數據中心的虛擬化是通過服務器虛擬化、存儲虛擬化和網絡虛擬化實現的。 服務器虛擬化在雲計算中最重要、最關鍵 服務器虛擬化之后，可以集中管理，能夠跨越物理平台而不受物理平台的限制
-
7.2服務器虛擬化
-
7.2.1服務器虛擬化的層次
-
寄居虛擬化
-
就操作系統層的虛擬化而言，沒有獨立的Hypervisor層
-
-
裸機虛擬化
-
當虛擬機中的操作系統通過特權指令訪問關鍵系統資源時，Hypervisor將接管其請求，並進行相應的模擬處理。
-
為了使這種機制能夠有效地運行，每條特權指令的執行都需要產生“自陷”（陷入異常），以便Hypervisor能夠捕獲該指令，從而使VMM能夠模擬執行相應的指令。
-
Hypervisor模擬特權指令的執行，並將處理結果返回給指定的客戶虛擬系統，實現了不同虛擬機的運行上下文保護與切換，能夠虛擬出多個硬件系統，保證了各個客戶虛擬系統的有效隔離
-
x86體系結構的處理器並不是完全支持虛擬化的，因為某些x86特權指令在低特權級上下文執行時，不能產生自陷，導致VMM無法直接捕獲特權指令
-
不能自陷解決辦法
-
完全虛擬化
-
具有很好的兼容性
-
-
半虛擬化
-
使不能自陷的指令自陷
-
-
-
-
-
7.2.2服務器虛擬化的底層實現
-
CPU虛擬化
-
CPU虛擬化技術把物理CPU抽象成虛擬CPU
-
任意時刻，一個物理CPU只能運行一個虛擬CPU指令
-
每個客戶操作系統可以使用一個或多個虛擬CPU，在各個操作系統之間，虛擬CPU的運行相互隔離，互不影響
-
-
內存虛擬化
-
內存虛擬化的思路主要是分塊共享
-
內存共享的核心思想是內存頁面的寫時復制（Copy on Write）
-
虛擬機管理器完成並維護物理機內存和虛擬機所使用的內存的映射關系
-
虛擬內存的管理包括3種地址：機器地址(邏輯地址)、物理地址、虛擬地址
-
虛擬地址 = 線性地址
-
邏輯地址+段基址+段內偏移 = 線性地址（虛擬地址） 段式內存管理
-
線性地址經過分頁轉換 = 物理地址 頁式內存管理
-
-
I/O設備虛擬化
-
I/O設備的異構性和多樣性，導致I/O設備的虛擬化相較於CPU和內存的虛擬化要困難和復雜
-
I/O設備虛擬化同樣是由VMM進行管理的，主要有全虛擬化、半虛擬化和軟件模擬三種思路，目前主流的設備與I/O虛擬化大多是通過軟件方式來實現的。
-
-
-
7.2.3虛擬機遷移
-
-
虛擬機動態遷移
-
內存的遷移最有難度和挑戰性，因為內存中的信息必不可少而且數據量比較大
-
CPU狀態和I/O設備雖然也很重要，但是它們只占遷移總數據量很少的一部分
-
磁盤的遷移最為簡單，在局域網內可以通過NFS（Network File System）的方式共享，而非真正遷移。
-
-
-
遷移的步驟
-
步驟1：預遷移（Pre-Migration）。主機A打算遷移其上的一個虛擬機VM，首先選擇 一個目的計算機作為VM的新主機。 步驟2：預定資源（Reservation）。主機A向主機B發起遷移請求，先確認B是否有必 需的資源，若有，則預定這些資源；若沒有，VM仍在主機A中運行，可以繼續選擇其他 計算機作為目的計算機。 步驟3：預復制（InterativePre-Copy）。在這一階段VM仍然運行，主機A以迭代的方 式將VM的內存頁復制到主機B上。在第一輪迭代中，所有的頁都要從A傳送到B，以后的 迭代只復制前一輪傳送過程中被修改過的頁面。 步驟4：停機復制（Stop-and-Copy）。停止主機A上的VM，把它的網絡連接重定向到 B。CPU狀態和前一輪傳送過程中修改過的頁都在這個步驟被傳送。最后，主機A和主機B 上有一致的VM映象。 步驟5：提交（Commitment）。主機B通知A已經成功收到了VM的映像，主機A對這 個消息進行確認，然后主機A可以拋棄或銷毀其上的VM。 步驟6：啟動（Activation）。啟動遷移到B上的VM，遷移后使用目的計算機的設備驅 動，廣播新的IP地址。
-
-
-
遷移的內容
-
1) 內存的遷移
-
第一階段，Push階段。在VM運行的同時，將它的一些內存頁面通過網絡復制到目的機器上。為了保證內容的一致性，被修改過的頁需要重傳。 第二階段，Stop-and-Copy階段。VM停止工作，把剩下的頁面復制到目的計算機上，然后在目的計算機上啟動新的VM。 第三階段，Pull階段。新的虛擬機運行過程中，如果訪問到未被復制的頁面，就會出現頁錯誤並從原來的VM處把該頁復制過來。
-
Stop-and-Copy
-
靜態遷移
-
-
工作集：改動頻繁的頁
-
-
2) 網絡資源的遷移
-
包括協議狀態（如TCP連接狀態）以及IP地址都要隨之一起遷移。
-
在局域網內，可以通過發送ARP重定向包，將VM的IP地址與目的機器的MAC地址相綁定，之后的所有包就可以發送到目的機器上。
-
關鍵詞：ARP重定向包
-
-
-
3） 存儲設備的遷移
-
共享的方式共享數據和文件系統，而非真正遷移。大多數集群使用NAS（Network Attached Storage，網絡連接存儲）作為存儲設備共享數據。
-
-
-
-
7.2.4隔離技術
-
兩個隔離機制
-
內存隔離
-
MMU是Memory Management Unit的縮寫，中文名是內存管理單元，它是中央處理器（CPU）中用來管理虛擬存儲器、物理存儲器的控制線路，同時也負責將虛擬地址映射為物理地址，以及提供硬件機制的內存訪問授權。
-
-
網絡隔離
-
關鍵
-
在於系統對通信數據的控制
-
即通過不可路由的協議來完成網間的數據交換
-
-
安全要素：數據的機密性、完整性、可用性、可控性、抗抵性等
-
安全機制: 訪問控制、身份認證、加密簽名等
-
實現原理是通過專用通信設備、專有安全協議和加密驗證機制及應用層數據提取和鑒別認證技術，進行不同安全級別網絡之間的數據交換
-
-
-
-
7.2.5案例分析
-
虛擬機遷移工具VMotion和存儲遷移工具Storage VMotion
-
7.3存儲虛擬化
-
7.3.1存儲虛擬化的一般模型
-
存儲虛擬化是指將存儲網絡中的各個分散且異構的存儲設備按照一定的策略映射成一個統一的連續編址的邏輯存儲空間，稱為虛擬存儲池。
-
優點
-
減少存儲系統的管理開銷
-
實現存儲系統數據共享
-
提供透明的高可靠性和可擴展性。
-
-
-
7.3.2存儲虛擬化的實現方式
-
基於主機的存儲虛擬化
-
基於主機的存儲虛擬化，也稱基於服務器的存儲虛擬化或者基於系統卷管理器的存儲虛擬化，其一般是通過邏輯卷(LVM)管理來實現的。
-
虛擬機主要功能是在系統和應用級上完成多台主機之間的數據存儲共享、存儲資源管理（存儲媒介、卷及文件管理）、數據復制及遷移、集群系統、遠程備份及災難恢復等存儲管理任務。
-
優點：性價比高； 缺點：性能下降、可擴展性差、不支持異構平台
-
-
基於存儲設備的存儲虛擬化
-
基於存儲設備的存儲虛擬化主要是在存儲設備的磁盤、適配器或者控制器上實現虛擬化功能。
-
優點：這類存儲子系統與主機無關，對系統性能的影響比較小，也比較容易管理，同時，對用戶和管理人員都是透明的。 缺點：對包含有多家廠商的設備效果不好，可擴展性差
-
-
基於網絡的存儲虛擬化
-
基於網絡的存儲虛擬化方法是在網絡設備上實現存儲虛擬化功能，包括基於互連設備 和基於路由器兩種方式。 基於互連設備的虛擬化方法能夠在專用服務器上運行，它在標准操作系統中運行，和主機的虛擬存儲一樣具有易使用、設備便宜等優點。 同樣，它也具有基於主機虛擬存儲的一些缺點，因為基於互連設備的虛擬化方法同樣需要一個運行在主機 上的代理軟件或基於主機的適配器，如果主機發生故障或者主機配置不合適都可能導致訪問到不被保護的數據。 基於路由器的虛擬化方法指的是在路由器固件上實現虛擬存儲功能。大部分控制模塊存儲在路由器的固件里面， 相對於上述幾種方式，基於路由器的虛擬化在性能、效果和安全方面都要好一些。 當然，基於路由器的虛擬化方法也有缺點，如果連接主機到存儲網絡的路由器出現故障，也可能會使主機上的數據不能被訪問，但是只有與故障路由器連接在一起的主機才會受到影響，其余的主機還是可以用其他路由器訪問存儲系統，且路由器的冗余還能夠支持動態多路徑。
-
-
-
7.3.3案例分析
-
vSphere提出了虛擬機文件系統（Virtual Machine File System，VMFS），允許來自多個不同主機服務器的並發訪問，即允許多個物理主機同時讀寫同一存儲器。VMFS的功能主要包括以下三點。 （1）磁盤鎖定技術。磁盤鎖定技術是指鎖定已啟動的虛擬機的磁盤，以避免多台服務器同時啟動同一虛擬機。如果物理主機出現故障，系統則釋放該物理主機上每個虛擬機的磁盤鎖定，以便這些虛擬機能夠在其他物理主機上重新啟動。 （2）故障一致性和恢復機制。故障一致性和恢復機制可以用於快速識別故障的根本原因，幫助虛擬機、物理主機和存儲子系統從故障中恢復。該機制中包括了分布式日志、故障一致的虛擬機I/O路徑和計算機狀況快照等。 （3）裸機映射（RDM）。RDM使得虛擬機能夠直接訪問物理存儲子系統（iSCSI或光纖通道）上的LUN（Logical Unit Number）。
-
vmx：虛擬機配置文件；vmdk：虛擬磁盤文件
-
7.4網絡虛擬化
-
概述
-
傳統的數據中心
-
多種技術和業務之間的孤立性→數據中心網絡結構復雜： 獨立的三張網，包括數據網、存儲網和高性能計算網，以及多個對外I/O接口 服務器之間的操作系統和上層軟件異構、接口與數據格式不統一 數據中心內網絡傳輸效率低
-
-
使用雲計算后
-
大流量的數據同步傳送、備份、虛擬機遷移等
-
采用統一的交換網絡減少布線、維護工作量和擴容成本
-
-
引入虛擬化技術之后
-
在不改變傳統數據中心網絡設計的物理拓撲和布線方式的前提下，實現網絡各層的橫向整合，形成一個統一的交換架構。
-
數據中心網絡虛擬化分為核心層、接入層和虛擬機網絡虛擬化三個方面
-
-
-
7.4.1核心層網絡虛擬化
-
核心層網絡虛擬化，主要指的是數據中心核心網絡設備的虛擬化。它要求核心層網絡 具備超大規模的數據交換能力，以及足夠的萬兆接入能力；提供虛擬機箱技術，簡化設備 管理，提高資源利用率，提高交換系統的靈活性和擴展性，為資源的靈活調度和動態伸縮 提供支撐。
-
-
7.4..2接入層網絡虛擬化
-
根據數據中心的走線要求，接入層交換機要求能夠支持各種靈活的部署方式和新的以太網技術。
-
-
7.4.3虛擬機網絡虛擬化
-
虛擬機網絡交互包括物理網卡虛擬化和虛擬網絡交換機，在服務器內部虛擬出相應的交換機和網卡功能。虛擬交換機在主機內部提供了多個網卡的互連，虛擬網卡是在一個物理網卡上虛擬出多個邏輯獨立的網卡，使得每個虛擬網卡具有獨立的MAC地址、IP地址，同時還可以在虛擬網卡之間實現一定的流量調度策略。
-
虛擬機網絡交互需要實現以下功能：
-
虛擬機的雙向訪問控制和流量監控
-
虛擬機的網絡屬性應包括VLAN、QoS、ACL、帶寬等。要與物理機網絡屬性一致
-
動態遷移
-
遷移過程中業務不中斷
-
-
IEEE 802.1Qbg EVB 和802.1Qbh BPE是為擴展虛擬數據中心中交換機和虛擬網卡的功能而制定的，也稱邊緣網絡虛擬化技術標准
-
-
7.4.4案例分析：VMware的網絡虛擬化技術
-
通過vNetwork實現，vNetwork包括虛擬網絡接口卡vNIC、虛擬交換機vSwitch、分布式交換機
-
虛擬網絡接口卡
-
每個虛擬機都可以配置一個或者多個虛擬網絡接口卡vNIC。
-
安裝在虛擬機上的客戶操作系統和應用程序利用通用的設備驅動程序與vNIC進行通信。
-
從虛擬機的角度看，客戶操作系統中的通信過程就像與真實的物理設備通信一樣。
-
在虛擬機的外部，vNIC擁有獨立的MAC地址以及一個或多個IP地址，且遵守標准的以太網協議。
-
-
虛擬交換機vSwitch
-
虛擬交換機用來滿足不同的虛擬機和管理界面進行互連。
-
每台服務器都有自己的虛擬交換機。
-
虛擬交換機的一端是與虛擬機相連的端口組，另一端是與虛擬機所在服務器上的物理以太網適配器相連的上行鏈路。
-
虛擬機通過與虛擬交換機上行鏈路相連的物理以太網適配器與外部環境連接。
-
虛擬交換機可將其上行鏈路連接到多個物理以太網適配器以啟用網卡綁定。通過網卡綁定，兩個或多個物理適配器可用於分攤流量負載，或在出現物理適配器硬件故障或網絡故障時提供被動故障切換。
-
-
分布式交換機
-
虛擬機可在跨多個主機進行遷移時確保其網絡配置保持一致
-
在虛擬機之間進行內部流量路由
-
連接物理以太網適配器鏈接外部網絡
-
為每個vSwitch分配一個或多個dvPort組
-
-
端口組
-
端口組是一種策略設置機制
-
與同一端口組相連的所有虛擬機均屬於虛擬環境內的同一網絡
-
可將端口組配置為執行策略，以提供增強的網絡安全、網絡分段、更佳的性能、高可用性及流量管理。
-
-
7.5桌面虛擬化
-
行業翹楚：微軟桌面，實質同服務器虛擬化