云计算第二章2-3教学ppt.ppt

第2章Google云计算原理与应用 提纲 Google文件系统GFS 分布式数据处理MapReduce 分布式锁服务Chubby 分布式结构化数据表Bigtable 分布式存储系统Megastore 大规模分布式系统的监控基础架构Dapper Google应用程序引擎 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 在互联网的应用中 为了达到好的可扩展性 常常会采用NoSQL存储方式 但是从应用程序的构建方面来看 传统的关系型数据库又有着NoSQL所不具备的优势 Google设计和构建了用于互联网中交互式服务的分布式存储系统Megastore 该系统成功的将关系型数据库和NoSQL的特点与优势进行了融合 设计目标及方案选择 可用性 实现了一个同步的 容错的 适合远距离传输的复制机制 引入Paxos算法并对其做出一定的改进以满足远距离同步复制的要求 可扩展性 借鉴了数据库中数据分区的思想 将整个大的数据分割成很多小的数据分区 每个数据分区连同它自身的日志存放在NoSQL数据库中 具体来说就是存放在Bigtable中 设计目标 一种介于传统的关系型数据库和NoSQL之间的存储技术 尽可能达到高可用性和高可扩展性的统一 数据分区和复制 数据分区和复制 Megastore中 这些小的数据分区被称为实体组集 EntityGroups 每个实体组集包含若干实体组 EntityGroup 相当于分区中表的概念 而一个实体组中又包含很多的实体 Entity 相当于表中记录的概念 从图中还可以看出单个实体组支持ACID语义 实体组集之间只具有比较松散的一致性 每个实体组都通过复制技术在数据中心中保存若干数据副本 这些实体组及其副本都存储在NoSQL数据库 Bigtable 中 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore数据模型 传统的关系型数据库是通过连接 Join 来满足用户的需求的 但是就Megastore而言 这种数据模型是不合适的 主要有以下三个原因 1 对于高负载的交互式应用来说 可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多 2 Megastore所面对的应用是读远多于写 因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上 3 在Bigtable这样的键 值存储系统中存储和查询级联数据 HierarchicalData 是很方便的 Megastore数据模型怎么设计 Google设计了一种能够提供细粒度控制的数据模型和模式语言 同关系型数据库一样 Megastore的数据模型是在模式 schema 中定义的且是强类型的 stronglytyped 每个模式都由一系列的表 tables 构成 表又包含有一系列的实体 entities 每实体中包含一系列属性 properties 属性是命名的且具有类型 这些类型包括字符型 strings 数字类型 numbers 或者Google的ProtocolBuffers 这些属性可以被设置成必须的 required 可选的 optional 或者可重复的 repeated 即允许单个属性上有多个值 数据模型实例 照片共享服务数据模型实例 图中表Photo就是一个子表 因为它声明了一个外键 User则是一个根表 一个Megastore实例中可以有若干个不同的根表 表示不同类型的实体组集 图中实例还可以看到三种不同属性设置 既有必须的 如user id 也有可选的 如thumbnail url 值得注意的是Photo中的可重复类型的tag属性 这也就意味着一个Photo中允许同时出现多个tag属性 索引 Index Megastore索引分成两大类 局部索引 localindex 和全局索引 globalindex 局部索引定义在单个实体组中 作用域仅限于单个实体组 如PhotosByTime 全局索引则可以横跨多个实体组集进行数据读取操作 如PhotosByTag Megastore还提供了一些额外的索引特性 STORING子句 STORINGClause 可重复的索引 RepeatedIndexes 内联索引 InlineIndexes Bigtable中数据存储情况 表中不难看出 Bigtable的列名实际上是表名和属性名结合在一起得到 不同表中实体可存储在同一个Bigtable行中 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore中的事务及并发控制 Megastore三种方式的读 分别是current snapshot和inconsistent 其中current读和snapshot读总是在单个实体组中完成 对于snapshot读 系统取出已知的最后一个完整提交的事务的时间戳 接着从这个位置读数据 inconsistent读忽略日志的状态直接读取最新的值 Megastore中的事务及并发控制 Megastore事务中的写操作采用了预写式日志 Write aheadLog 一个写事务总是开始于一个current读以便确认下一个可用的日志位置 提交操作将数据变更聚集到日志 接着分配一个比之前任意一个都高的时间戳 然后使用Paxos将数据变更加入到日志中 协议使用了乐观并发 OptimisticConcurrency 尽管可能有多个写操作同时试图写同一个日志位置 但只会有1个成功 读 获取最后一次提交的事务的时间戳和日志位置 完整事务周期 应用逻辑 从Bigtable读取且聚集数据到日志入口 提交 使用Paxos达到一致 将个入口追加到日志 生效 将数据更新到Bigtable中的实体和索引 清除 清理不再需要的数据 Megastore中的事务机制 消息队列机制 消息能够横跨实体组 每个消息都有一个发送和接收实体组 如果两个实体组是不同的 则传输将是异步 特点 规模 声明一个队列后可以在其他所有的实体组上创建一个收件箱 支持两阶段提交 增加竞争风险 不鼓励使用 Megastore中的事务机制 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 Megastore的基本架构 Megastore中三种副本 完整副本 Bigtable中存储完整的日志和数据 见证者副本 在Paxos算法执行过程中无法产生一个决议时参与投票 只读副本 读取最近过去某一个时间点一致性数据 Megastore的基本架构 Megastore中提供快速读 FastReads 和快速写 FastWrites 机制 快速读 如果读操作不需要副本之间进行通信即可完成 那么读取的效率必然相对较高 利用本地读取 LocalReads 实现快速读 能够带来更好的用户体验及更低的延迟 确保快速读成功的关键是保证选择的副本上数据是最新的 为了达到这一目标 引入了协调者的概念 协调者是一个服务 该服务分布在每个副本的数据中心里面 它的主要作用就是跟踪一个实体组集合 协调者的状态是由写算法来保证 快速写 Megastore采用了一种在主 从式系统中常用的优化方法 如果一次写成功 那么下一次写的时候就跳过准备过程 直接进入接受阶段 Megastore没有使用专门的主服务器 而是使用leaders leader主要是来裁决哪个写入的值可以获取0号提议 优化 提交值最多的位置附近选择一副本作为leader 客户端 网络及Bigtable的故障都会导致一个写操作处于不确定的状态 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 复制的日志 预写式日志 当日志有不完整的前缀时我们就称一个日志副本有 缺失 Holes 图中0 99的日志位置已经被全部清除 100的日志位置被部分清除 101的日志位置被全部副本接受 102的日志位置被 获得 103的日志位置被副本A和C接受 副本B则留下了一个 缺失 104的日志位置则未达到一致性 数据读取 数据读取 数据读取过程 本地查询 QueryLocal 发现位置 FindPosition 本地读取 LocalRead 多数派读取 MajorityRead 追赶 Catchup Paxos将会促使绝大多数副本达成一个共识值 达到一种分布式一致状态 验证 Validate 查询数据 QueryData 数据写入 数据写入 数据写入完整过程 1 接受leader 请求leader接受值作为0号提议 快速写方法 若成功 跳至步骤 3 2 准备 将值替换成拥有最高提议号的那个值 3 接受 请求剩余的副本接受该值 如果大多数副本拒绝这个值 返回步骤 2 4 失效 将不接受值的副本上的协调者进行失效操作 5 生效 将值的更新在尽可能多的副本上生效 如果选择的值和原来提议的有冲突 返回一个冲突错误 协调者的可用性 协调者在系统中是比较重要的 协调者的进程运行在每个数据中心 每次的写操作中都要涉及协调者 因此协调者的故障将会导致系统的不可用 Megastore使用了Chubby锁服务 为了处理请求 一个协调者必须持有多数锁 一旦因为出现问题导致它丢失了大部分锁 协调者就会恢复到一个默认保守状态 除了可用性问题 对于协调者的读写协议必须满足一系列的竞争条件 设计目标及方案选择 Megastore数据模型 Megastore中的事务及并发控制 Megastore基本架构 核心技术 复制 产品性能及控制措施 可用性分布情况 可用性分布情况 Megastore在Google中已经部署和使用了若干年 有超过100个产品使用Megastore作为其存储系统 从图中可以看出 绝大多数产品具有极高的可用性 99 999 这表明Megastore系统的设计是非常成功的 基本达到了预期目标 产品延迟情况分布 应用程序的平均读取延迟在万分之一毫秒之内 平均写入延迟在100至400毫秒之间 避免Megastore的性能下降 可采取以下三种应对方法 可能结合使用 1 重新选择路由使客户端绕开出现问题的副本 2 将出现问题副本上的协调者禁用 确保问题的影响降至最小 3 禁用整个副本 平均延迟的分布 需要指出 Megastore已经是Google相对过时的存储技术 Google目前正在使用的存储系统是Spanner架构 Spanner的设计目标是能够控制一百万到一千万台服务器 Spanner最强大之处在于能够在50毫秒之内为数据传递提供通道 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 用户将一个关键字通过Google的输入框传到Google的后台 在我们看来很简单的一次搜索实际上涉及了众多Google后台子系统 这些子系统的运行状态都需要进行监控 广泛可部署性 不间断的监控 监控系统设计两个基本要求 设计目标 03 02 01 广泛可部署性的必然要求 监控系统的开销越低 对于原系统的影响就越小 系统的开发人员也就越愿意接受这个监控系统 Google的服务增长速度是惊人的 设计出的系统至少在未来几年里要能够满足Google服务和集群的需求 如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话 这个监控系统肯定不是一个完善的监控系统 低开销 应用层透明 可扩展性 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 基本概念 图中 用户发出请求X 前端A发现该请求的处理需要涉及服务器B和服务器C 因此A又向B和C发出两个RPC 远程过程调用 B收到后立刻做出响应 但是C在接到后发现它还需要调用服务器D和E才能完成请求X 因此C对D和E分别发出了RPC D和E接到后分别做出了应答 收到D和E的应答之后C才向A做出响应 在接收到B和C的应答之后A才对用户请求X做出一个应答X 在监控系统中记录下所有这些消息不难 如何将这些消息记录同特定的请求 本例中的X 关联起来才是分布式监控系统设计中需要解决的关键性问题之一 典型分布式系统的请求及应答过程 方案一黑盒 BlackBox 方案 方案比较轻便 但在消息关系判断过程中 主要是利用一些统计学知识来进行推断 有时不是很准确 方案二基于注释的方案 利用应用程序或中间件给每条记录赋予一个全局性的标示符 借此将相关消息串联起来 Google最终选择 基本概念 Dapper监控系统中三个基本概念 监控树 TraceTree 区间 Span 和注释 Annotation 图示是一个典型的监控树 实际上就是一个同特定事件相关的按照一定的规律以树的形式组织起来所有消息 每一个节点称为一个区间 一条记录 所有记录联系在一起就构成了对某个事件的完整监控 每个区间包括如下的内容 区间名 SpanName 区间id Spanid 父id Parentid 和监控id Traceid 监控树 监控id图中并没有列出 一棵监控树中所有区间的监控id相同 随机分配且唯一 区间Helper Call的详细信息 图中区间包含来自客户端的注释信息 ClientSend ClientRecv 和 也包含来自服务器端的注释信息 ServerRecv foo 和 ServerSend 除 foo 是用户自定义的注释外 其他的注释信息都是和时间相关的信息 Dapper不但支持用户进行简单的文本方式的注释 还支持键 值对方式的注释 基本概念 监控信息的汇总 监控信息汇总 监控信息汇总 1 将区间的数据写入到本地的日志文件 2 所有机器上的本地日志文件汇集 3 汇集后的数据写入到Bigtable存储库中 监控数据汇总是单独进行的 而不是伴随系统对用户的应答一起返回的 如此选择主要原因 内置的汇总方案 监控数据随RPC应答头返回 会影响网络动态 内置的汇总方案需要保证所有的RPC都是完全嵌套 安全问题 应用层注释提供一种方便的选择机制 Opt inMechanism 应用程序开发者可以将任何对后期分析有益的数据和区间关联起来 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 Dapper三个设计目标中 实现难度最大的是 应用层透明 怎么实现应用层透明 轻量级的核心功能库 二次抽样技术 轻量级核心功能库 将Dapper的核心监控实现限制在一个由通用线程 UbiquitousThreading 控制流 ControlFlow 和RPC代码库 RPCLibraryCode 组成的小规模库基础上 其中最关键的代码基础是基本RPC 线程和控制流函数库的实现 主要功能是实现区间创建 抽样和在本地磁盘上记录日志 二次抽样技术 第一次抽样 实践中 设计人员发现当抽样率低至1 1024时也能够产生足够多的有效监控数据 即在1024个请求中抽取1个进行监控也是可行的 从而可以捕获有效数据 第二次抽样 发生在数据写入Bigtable前 具体方法是将监控id散列成一个标量z 0 z 1 如果某个区间的z小于事先定义好的汇总抽样系数 则保留这个区间并将它写入Bigtable 否则丢弃 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 Dapper存储API Dapper的 存储API 简称为DAPI 提供了对分散在区域Dapper存储库 DEPOTS 的监控记录的直接访问 一般来说 有以下三种方式可以对这些记录进行访问 1 监控id访问 AccessbyTraceid 利用全局唯一的监控id直接访问所需的监控数据 2 块访问 BulkAccess 借助MapReduce对数以十亿计的Dapper监控数据的并行访问 3 索引访问 IndexedAccess Dapper存储库支持单索引 SingleIndex 根据不完全统计 目前大约有三个基于DAPI的持久应用程序 八个额外的基于DAPI的按需分析工具及大约15 20个使用DAPI框架构建的一次性分析工具 Dapper用户界面 1 选择监控对象 起止时间 区分监控模式的信息及一个衡量开销的标准 2 用户对这些执行模式进行排序并选择某个查看更多细节 Dapper用户界面 3 分布式执行模式图形化描述呈现给用户 4 根据最初选择的开销度量标准 Dapper以频度直方图的形式将步骤 3 中选中的执行模式的开销分布展示出来 Dapper用户界面 5 用户选择了某个监控样例后 就会进入所谓的监控审查视图 TraceInspectionView 基本设计目标 Dapper监控系统简介 关键性技术 常用Dapper工具 Dapper使用经验 新服务部署中Dapper的使用 利用Dapper对系统延迟情况进行一系列的跟踪 进而发现存在的问题 定位长尾延迟 AddressingLongTailLatency 因此发现关键路径上的网络延迟常常就能够发现端到端性能表现不佳的原因 利用Dapper恰恰能够比较准确的发现关键路径 Dapper使用经验 关键路径网络延迟对于端到端性能表现的影响 确定不同服务的网络使用情况 利用Dapper平台构建了一个连续不断更新的控制台 用来显示内部集群网络通信中最活跃的应用层终端 Dapper使用经验 推断服务间的依存关系 InferringServiceDependencies Google的 服务依存关系 项目使用监控注释和DPAI的MapReduce接口实现了服务依存关系确定的自动化 利用Dapper进行 火拼 FirefightingwithDapper 火拼 是指处于危险状态的分布式系统的代表性活动 正在 火拼 中的Dapper用户需要访问最新的数据却没有时间来编写新的DAPI代码或者等待周期性的报告 此时可以通过和Dapper守护进程的直接通信 将所需的最新数据汇总在一起 Dapper使用经验 分层的共享式存储系统 没有Dapper之类的工具的情况下对于这种共享式服务资源的争用也同样难以调试