云计算与虚拟化笔记1:云计算分类及体系分层、GFS架构概述

By | 2020年5月24日

本系列为博主个人听课学习笔记,内容整理自西安电子科技大学王琨老师的《云计算与虚拟化》课程

分类及体系分层

云服务将计算任务分布在大量计算机构成的资源池上,使各种应用系统能够根据需要获得计算能力、存储空间和信息服务。配备的资源可以根据需求进行动态伸缩。

云计算按服务类型的分类

  • SaaS,直接将特定软件功能封装,并作为服务来提供;
  • PaaS,提供用户应用程序的运行环境,比如Google App Engine;
  • IaaS,封装硬件设备等基础资源作为服务来提供,如各家 ECS、CVM;

上述三者从上往下逐渐通用。

近些年似乎比较流行各种 *aaS ,印象中至少已经见过 A(I)aaS、B(ackend)aaS、B(lockchain)aaS、C(ontainer)aaS。23333333333333

体系分层


– SOA:Service-Oriented Architecture,将云计算能力封装成服务的一种架构模型;
– 管理中间件:对资源进行管理,为上层应用提供基础;
– 资源池层:把各种同类的资源在这里划分进不同的资源池;
– 物理资源层:承载所有服务的各类软硬件。

GFS架构概述


GFS 在 Google 的地位及应用参考上图。

相比于传统的数据中心,GFS 在理念上有了本质的不同:其使用普通商用硬件作为构建服务的基础,将故障视为正常现象,使用软件解决可靠性问题。

Chunk

先回忆一下本地 FS 怎么存东西


– 本地 FS 将硬盘分割成一个个的 block ,每个 block 尺寸相同,存储文件时要将文件进行分割,分开存入一段 block 中(可不连续);
– 文件的基础信息叫做元数据,其包含文件的基本属性以及文件物理位置的索引。index 的编号唯一指定了 block 的地址。

因为元数据也是数据,也储存在硬盘中,所以想要读取硬盘中的文件,实际上要进行两次读取:先读元数据,再根据元数据去读实际文件。因此,我们可以通过让元数据常驻内存的方法来显著提升硬盘读取速度。但随着文件数量的增多、尺寸的增大,元数据的大小也会不断增长。
在文件数量非常多、体积非常大的情况下,可能全部的内存都放不下全部的元数据。这种问题在通过网络通信的分布式系统的场景下就会更加突出(浪费空间和带宽)。

为了显著减小元数据的尺寸,可以改用更大的块来存文件。这就是 Chunk,1chunk = 64MB


这样虽然在存储小文件时会导致相对严重的空间浪费,但在实际应用中,Google 采用将小文件拼接成大文件的方式来减小空间的浪费(比如用 bigtable 存网页)。

GFS 系统架构

节点分类

GFS 系统中共有三类节点:Client、Master、Chunk Server

Client:客户端 是一组接口,是 GFS 以库文件形式提供给应用的访问接口。使用了这个接口的应用就会成为 GFS 系统中的 Client 来与其他的部分协作。该图中的“应用程序”是指使用 GFS 的各种具体 Google 产品,比如 Google Maps、Earth 等等;

Master:主服务器 是 GFS 的管理节点,管理文件的命名空间(即文件系统的目录结构)、元数据信息和 chunk 副本的位置。元数据描述了存储某个文件的 Chunk Server 以及在该 server 内的具体存储位置(即 chunk 与文件名的映射)。
Master 还掌握整个系统中各个 server 的负载情况、空间信息等,可以直接控制下方的 server 进行负载均衡。当接收到写请求时,master 会根据既定的分配策略来在 chunk server 中选择空间,之后将选定的 chunk server 及指定的位置信息告知应用程序,应用程序就会直接连接对应的 chunk server 来提交要写入的数据。
一个 GFS 系统中可以有多个物理 Master,但对外只体现为一个单一的逻辑 Master(通常是五个一模一样的服务器组成的 master 小集群)。这个小集群内部的一致性使用 Chubby 来维持。

Chunk Server:数据块服务器在逻辑上位于主服务器之下,负责具体的数据存储工作,每个 Chunk 默认 64MB,每个 Chunk 对应一个索引号。
每个在 GFS 中存储的文件,都会被分割备份存储在不同的 chunk server 中,默认每块存三份。

实现机制

  • 控制流、数据流分离:Master 只与客户端进行控制流通信,根据客户端的读写需求来提供 Chunk Server 信息; 得到信息的客户端直接与 Chunk Server 进行数据流通信,完成读写操作。
  • I/O 并行:GFS 系统内的文件都会被分割为多个 Chunk 进行分布式存储,客户端就可以同时对多个 Chunk Server 进行并行独写,提高系统性能。

特色

中心服务器模式
  • 所有的 Chunk Server 都要在 Master 进行注册并由 Master 统一管理,而 Chunk Server 之间没有任何联系;
  • Master 掌握所有系统内 Chunk Server 的情况,方便进行负载均衡;
  • 由于元数据都由一个 Master 管理,故不存在元数据一致性的问题;
  • 通过控制元数据规模、对 Master 进行备份、控制流和数据流分开等方式来削弱 Master 的瓶颈问题。
不缓存数据

对于 chunk server 而言,由于 Chunk 内的数据都以文件形式存储,故可以直接由 OS 管理本地 FS 的 cache ,而不需要在 GFS 这一层再单独另行控制。 此外,也受到物理内存尺寸、成本、一致性维护困难等问题限制。

Master 为了提高性能,会直接将元数据读入内存进行缓存。

用户态实现

Master、Chunk 都利用 POSIX 接口实现,并在操作系统中以用户态运行。有利于降低和 OS 的耦合性,能够提高安全性并方便 GFS、内核各自维护升级。

只提供专用接口

GFS 是在应用层实现的软件系统,仅以库文件形式为 Client 提供接口。这样方便针对应用增加专用的支持,且专用接口直接连接 Master、Chunk Server、Client,能够减少 OS 之间的上下文切换。

容错机制

Master 容错

master 中有一种叫做“操作日志”的东西,Master 中对命名空间、chunk 与文件名的映射表的所有读写操作都存储在操作日志中。当 master 出现故障时,可以使用该日志完全恢复这些数据。Chunk 的副本直接保存在各个 chunk server 中。当一个 master 出现故障时,chunk server 会自动寻找新的 master 来替换原来的 master。系统再次启动之后,chunk server 会注册到新的 master 并提交自己的信息。

另外,master 也会进行实时的远程备份。

Chunk Server 容错

chunk server 使用副本方式实现容错。GFS 会动态检查并保证同一时刻都会有确定数量的副本存在不同的 chunk server 中。对于每一个 chunk,必须所有的副本全都写入成功才算写入成功。

此外,每个 chunk 又划分为一个个 64KB 的 block,每个 block 都有一个校验和来保证正确。

Chunk Server 写数据


1. client 连接 Master,说明要写入的数据大小信息;
2. master 为 client 分配 chunk server 节点,并告知 client 可在哪些 chunk server 存哪些东西;
3. (以下以存储一个数据块为例)master 为这一块数据的存储选了三个 chunk server,其中一个是主副本,另外两个是secondary副本。client 得到信息后,直接向这些节点写数据。写入顺序没有要求。该图中就是client 直接向 Secondary Replica A 写入,该节点收到数据的同时就将数据转发到其他的副本服务器中;
4. 完成所有数据写入后,client 会向主 chunk server 发条结束写操作的请求;
5. 主 chunk server 收到后,将该请求转发给其他副本服务器;
6. 其他副本服务器接收到请求后,会对主服务器进行操作成功的响应;
7. 主服务器回复操作结果给 client,任何出现的错误也都会被发送给 client。

上述任何一步出现问题,系统都会重新执行操作。

系统管理技术

大规模集群安装技术:可以自动进行系统的安装部署和升级;

故障检测技术:能够进行故障检测,进行相关的处理和恢复;

节点动态加入技术:新的 chunk server 可以以裸机状态加入,就能自动获取并安装系统

点击量:294