第1章 大数据与云计算
1.2 云计算——大数据的计算
-
云计算按照服务类型大致可以分为三类：将基础设施作为服务（IaaS）、将平台作为服务（PaaS）和将软件作为服务（SaaS）
-
IaaS将硬件设备等基础资源封装成服务供用户使用，如亚马逊云计算AWS（Amazon Web Services）的弹性计算云EC2和简单存储服务S3。
-
PaaS对资源的抽象层次更进一步，它提供用户应用程序的运行环境，典型的如GoogleApp Engine。微软的云计算操作系统Microsoft Windows Azure也可大致归入这一类。
-
SaaS的针对性更强，它将某些特定应用软件功能封装成服务
1.4 云计算实现机制
-
云计算技术体系结构分为四层：物理资源层、资源池层、管理中间件层和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桌面虚拟化
-
行业翘楚：微软桌面，实质同服务器虚拟化