网志栈编辑推荐
导语_点评_推荐词 ；
内容简介
本书从云计算*基本的概念开始，由浅入深地带领读者领会云计算的精髓，以梳理知识脉络和要点的方式，带领读者登堂入室。 本书的第1~3章为云计算的基础部分，包括云计算的产生、发展、基本概念和实现云计算的机制部分； 第4~7章为云计算的技术部分，包括虚拟化、分布式文件系统、分布式存储系统和数据处理与并行编程技术等实现云计算必须的技术； 第8章为限制云计算的安全问题； 第9章向读者提到了目前存在的一些热门的云计算应用； 第10章为综合实践，讲述了云计算与Docker技术结合的实践内容。 本书既适合作为高等院校计算机相关专业的云计算导论课程的教材，也适合非计算机专业的学生及广大计算机爱好者阅读。
作者简介
暂无
目录
目录
；
第1章云计算概论
；
1.1什么是云计算
；
1.2云计算的产生背景
；
1.3云计算的发展历史
；
1.4如何学好云计算
；
1.5小结
；
1.6习题
；
第2章云计算基础
；
2.1分布式计算
；
2.2云计算的基本概念
；
2.3云计算的关键技术
；
2.3.1分布式海量数据存储
；
2.3.2虚拟化技术
；
2.3.3云平台技术
；
2.3.4并行编程技术
；
2.3.5数据管理技术
；
2.4云交付模型
；
2.4.1软件即服务（SaaS）
；
2.4.2平台即服务（PaaS）
；
2.4.3基础设施即服务（IaaS）
；
2.4.4基本云交付模型的比较
；
2.4.5容器即服务（CaaS）
；
2.5云部署模式
；
2.5.1公有云
；
2.5.2私有云
；
2.5.3混合云
；
2.6云计算的优势与挑战
；
2.7典型云应用
；
2.7.1云存储
；
2.7.2云服务
；
2.7.3云物联
；
2.8云计算与大数据
；
2.9小结
；
2.10习题
；
第3章云计算机制
；
3.1云基础设施机制
；
3.1.1虚拟网络边界
；
3.1.2虚拟服务器
；
3.1.3云存储设备
；
3.1.4资源备份
；
3.1.5就绪环境
；
3.2云管理机制
；
3.2.1远程管理系统
；
3.2.2资源管理系统
；
3.2.3SLA管理系统
；
3.2.4计费管理系统
；
3.3云监控机制
；
3.3.1资源监控
；
3.3.2能量监控
；
3.3.3SLA监控
；
3.3.4安全监控
；
3.4特殊云机制
；
3.4.1自动伸缩监听器
；
3.4.2负载均衡器
；
3.4.3故障转移系统
；
3.4.4虚拟机监控器
；
3.4.5资源集群
；
3.4.6多设备代理
；
3.4.7状态管理数据库
；
3.5小结
；
3.6习题
；
第4章虚拟化
；
4.1虚拟化简介
；
4.1.1什么是虚拟化
；
4.1.2虚拟化的发展历史
；
4.1.3虚拟化带来的好处
；
4.2虚拟化的分类
；
4.2.1服务器虚拟化
；
4.2.2网络虚拟化
；
4.2.3存储虚拟化
；
4.2.4应用虚拟化
；
4.2.5技术比较
；
4.3系统虚拟化
；
4.4虚拟化与云计算
；
4.5开源技术
；
4.5.1Xen
；
4.5.2KVM
；
4.5.3OpenVZ
；
4.6虚拟化未来发展趋势
；
4.7小结
；
4.8习题
；
第5章分布式文件系统
；
5.1概述
；
5.1.1本地文件系统
；
5.2.2分布式文件系统
；
5.2基本架构
；
5.2.1服务器介绍
；
5.2.2数据分布
；
5.2.3服务器间协议
；
5.3GFS
；
5.3.1架构设计
；
5.3.2实现流程
；
5.3.3特点
；
5.4HDFS
；
5.4.1基本概念
；
5.4.2架构设计
；
5.4.3优缺点分析
；
5.5分布式应用协调器ZooKeeper
；
5.5.1基本概念
5.5.2工作原理
5.5.3ZooKeeper应用对HDFS的改进
5.5.4主要应用场景
5.6云存储
5.6.1基本概念
5.6.2云存储的分类
5.6.3云存储的结构模型
5.6.4典型的云存储应用
5.7小结
5.8习题
第6章分布式存储系统
6.1概述
6.2NoSQL数据库
6.3分布式存储系统BigTable
6.3.1数据模型
6.3.2BigTable的构件
6.4分布式存储系统HBase
6.4.1HBase的访问接口和数据模型
6.4.2HBase系统架构
6.5HBase存储格式
6.6多元数据的管理与应用
6.7小结
6.8习题
第7章数据处理与并行编程
7.1数据密集型计算
7.1.1数据密集型计算的概念
7.1.2数据密集型计算的应用
7.2分布式数据处理
7.2.1分布式数据处理的含义
7.2.2分布式数据处理的范围
7.2.3分布式数据处理的控制
7.2.4信息中心
7.2.5集中式数据处理与分布式数据处理比较
7.3并行编程模型概述
7.4并行编程模型MapReduce
7.4.1MapReduce简介
7.4.2MapReduce总体研究状况
7.4.3MapReduce总结及未来的发展趋势
7.5云处理技术Spark
7.6MapReduce的开源实现—Hadoop
7.6.1Hadoop概述
7.6.2Hadoop核心架构
7.6.3Hadoop和高效能计算、网格计算的区别
7.6.4Hadoop发展现状
7.6.5Hadoop和MapReduce比较
7.7小结
7.8习题
第8章云安全
8.1基本术语与概念
8.2云安全威胁
8.3云安全防护策略
8.3.1基础设施安全
8.3.2数据安全
8.3.3应用安全
8.3.4虚拟化安全
8.4典型云安全应用
8.4.1金山毒霸“云安全”
8.4.2卡巴斯基-全功能安全防护
8.4.3瑞星“云安全”
8.4.4趋势科技“云安全”
8.5小结
8.6习题
第9章云计算的应用
9.1概述
9.2Google公司的云计算平台与应用
9.2.1MapReduce分布式编程环境
9.2.2分布式大规模数据库管理系统BigTable
9.2.3Google的云应用
9.3亚马逊的弹性计算云
9.3.1开放的服务
9.3.2灵活的工作模式
9.3.3总结
9.4IBM蓝云云计算平台
9.4.1蓝云云计算平台中的虚拟化
9.4.2蓝云云计算平台中的存储结构
9.5清华大学透明计算平台
9.6阿里云
9.6.1简介
9.6.2阿里云的发展过程
9.6.3阿里云的主要产品
9.7Microsoft Azure
9.7.1简介
9.7.2Microsoft Azure架构
9.7.3Microsoft Azure服务平台
9.7.4开发步骤
9.8小结
9.9习题
第10章综合实践： Docker与云计算
10.1Docker简介
10.2Docker的核心概念
10.2.1Docker镜像
10.2.2Docker仓库
10.2.3Docker容器
10.2.4容器即服务（CaaS)
10.3实验一： Docker的安装
10.3.1Ubuntu
10.3.2CentOS
10.3.3Windows
10.4实验二： 容器操作
10.4.1启动容器
10.4.2守护态运行
10.4.3终止容器
10.5实验三： 搭建一个Docker应用栈
10.5.1获取镜像
10.5.2应用栈容器节点互联
10.5.3应用栈容器节点启动
10.5.4应用栈容器节点配置
10.6实验四： 实现私有云
10.6.1启动Docker
10.6.2获取镜像
10.6.3实现sshd，在Base镜像基础上生成一个新镜像
10.6.4开始分配容器
10.6.5搭建自己的私有仓库
参考文献
媒体评论
评论
前沿
前言
在过去的几十年里，计算机技术的进步和互联网的发展极大地改变了人们的工作和生活方式。计算模式也经历了从最初的把任务集中交付给大型处理机到基于网络的分布式任务处理再到目前的按需处理的云计算方式的极大改变。自2006年亚马逊公司推出弹性计算云(EC2)服务，让中小型企业能够按照自己的需要购买亚马逊数据中心的计算能力后，云计算的时代就此正式来临。“云计算”的概念随之由Google公司于同年提出，其本质是给用户提供像传统的电、水、煤气一样的按需计算的网络服务，是一种新型的计算使用方式。它以用户为中心，使互联网成为每一个用户的数据中心和计算中心。Gartner公司早在2011年1月发布的IT行业十大战略技术报告中就已经将“云计算技术”列为十大战略技术之首，目前世界上主要国家和跨国企业都积极地加快着战略部署，推动云计算的高速发展。我国也将云计算上升到了国家战略高度，中央、地方政府、产业界都在共同推动我国云计算的应用和发展，除此之外，像Google、IBM、Microsoft、Amazon、阿里巴巴、腾讯等在内的知名IT企业也都在大力地开发相关云计算产品。然而在教育普及方面，经作者调研，即使计算机相关专业的学生对于云计算的相关知识也知之甚少，而对用户而言，如果不提前进行了解就去使用云计算是很危险的事情。目前，虽然市场上关于云计算技术相关的书籍较多，但是适合读者进行云计算入门的书籍还较少，因此本书定位为“云计算导论”课程的专业教材，旨在传授读者云计算的基础入门知识，本书也适合非计算机专业学生以及广大的计算机爱好者阅读。本书的章节内容如下： 第1~3章为云计算的基础部分，包括云计算的产生、发展、基本概念和实现云计算的机制部分； 第4~7章为云计算的技术部分，包括虚拟化、分布式文件系统、分布式存储系统和数据处理与并行编程技术等实现云计算必须的技术； 第8章为限制云计算的安全问题； 第9章向读者提到了目前存在的一些热门的云计算的应用； 第10章为综合实践，讲述了云计算与Docker技术结合的实践内容。在本书的编写过程中，尽量做到仔细认真，但由于作者的水平有限，还是可能出现一些不妥之处，在此非常欢迎广大读者进行批评指正。同时也希望广大读者将自己读书学习的心得体会反馈给作者(yunxianglu@hotmail．com)。编者2016年8月
免费在线读
第5章分布式文件系统
本章介绍的是分布式文件系统，分布式文件系统是实现云计算的关键技术。首先介绍分布式文件系统，以及分布式文件系统的基本架构，包含服务器、数据分布以及服务器间的协议； 然后重点介绍两种分布式文件系统，分别是GFS和HDFS，包括它们的基本概念、架构设计、实现流程以及特点分析； 接着提到协调器zookeeper，用来协调分布式系统的实现； 最后讲解云存储的基本概念、分类、结构模型以及典型应用。通过对本章的学习，读者可以对分布式文件系统形成系统的认识。5.1概述5.1.1本地文件系统
文件系统是操作系统用来组织磁盘文件的方法和数据结构。传统的文件系统指各种UNIX平台的文件系统，包括UFS、FFS、EXT2、XFS等，这些文件系统都是单机文件系统，也称本地文件系统。它们管理本地的磁盘存储资源、提供文件到存储位置的映射，并抽象出一套文件访问接口供用户使用。本地文件系统通常仅仅位于一个磁盘或一个磁盘分区上，它只能被唯一的主机访问，不能被多个主机共享。本地文件系统通常包含的四类信息如下。(1) 超级块： 用来描述文件系统整体信息的，含有整个文件系统中数据块和inode的相关信息； (2) inode： 用来描述文件和目录的属性和文件块在块设备上的位置信息； (3) 文件内容： 是用户的数据，是无结构的； (4) 目录内容： 是目录项，是有结构的。超级块通常位于磁盘(或分区)上的固定位置。根据文件系统类型，可定位超级块； 通过超级块可定位根目录的inode，从而读出根目录的内容。通过在文件系统名字空间的逐级名字解析，可得到指定文件的ino。根据ino可定位文件的inode在磁盘上的位置，从而读出文件的inode。根据inode中的块映射信息，最后定位指定的文件块，从而读出或写入数据。归结起来，本地文件系统所含的信息可以分为三类，它们是文件数据、文件系统元数据和存储元数据。随着互联网的高速发展以及网络的兴起，用户对数据存储的要求越来越高，而且模式各异，如淘宝网的大量商品图片，其特点是文件较小，但数量巨大； 而类似于YouTube、优酷这样的视频服务网站，其后台存储着大量的视频文件，尺寸大多在数十M到数G字节不等。这些应用场景都是传统文件系统不能解决的。而本地文件系统只能访问与主机通过I/O总线直接相连的磁盘上的数据。当局域网出现后，主机间通过网络互连起来。如果每台主机上都保存一份大家都需要的文件，既浪费存储资料，又不容易保持各份文件的一致性。于是就提出文件共享的需求，即一台主机需要访问其他主机的磁盘(或文件系统)。因此为了解决资源共享问题，出现了分布式文件系统。5.2.2分布式文件系统分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统使得分布在多个节点上的文件如同位于网络上的一个位置一样便于动态扩展和维护。如图5.1所示是一个分布式文件的拓扑结构，由于分布式文件系统中的数据可能来自很多不同的节点，它所管理的数据也可能存储在不同的节点上，这使得分布式文件系统中有很多设计和实现与本地文件系统存在巨大的差别。
图5.1分布式文件系统
1. 发展历程分布式文件系统的发展主要经历如下四个阶段。(1) 1980—1990年，早期的分布式文件系统一般以提供标准接口的远程文件访问为目的，更多地关注访问的性能和数据的可靠性。早期的文件系统以NFS和AFS最具代表性，它们对以后的文件系统设计也具有十分重要的影响。(2) 1990—1995年，20世纪90年代初，面对广域网和大容量存储需求，出现了xFS、Tiger Shark并行文件系统及Frangipani等分布式文件系统。(3) 1995—2000年，网络技术的发展和普及极大地推动了网络存储技术的发展，基于光纤通道的存储区域网络(Storage Area Network，SAN)、网络附属存储(Network Attached Storage，NAS)得到了广泛应用。这也推动了分布式文件系统的研究。这个阶段，出现了多种体系结构，充分利用了网络技术，像具有鲜明特点的GFS(Google File System)和GPFS(General Parallel File System)等。数据容量、性能和共享的需求使得这一时期的分布式文件系统管理的系统规模更大、更复杂，对物理设备的直接访问、磁盘布局和检索效率的优化、元数据的集中管理等都反映了对性能和容量的要求。规模的扩展使得系统具有动态性，如在线增减设备、缓存的一致性、系统可靠性的需求逐渐增强，更多的先进技术被应用到系统实现中，如分布式锁、缓存管理技术、SoftUpdates技术、文件级的负载平衡等。(4) 2000年以后，随着SAN和NAS两种体系结构逐渐成熟，研究人员开始考虑如何将这两种体系结构结合起来，以充分利用两者的优势； 另一方面，基于多种分布式文件系统的研究成果，人们对体系结构的认识不断深入，网格的研究成果也推动了分布式文件系统体系结构的发展。这一时期，IBM的StorageTank、Cluster的Lustre、Panasas的PanFS、蓝鲸文件系统(BWFS)等是这种体系结构的代表。各种应用对存储系统提出了更多的需求。 大容量——现在的数据量比以前任何时期更多，生成的速度更快； 高性能——数据访问需要更高的带宽； 高可用性——不仅要保证数据的高可用性，还要保证服务的高可用性； 可扩展性——应用在不断变化，系统规模也在不断变化，这就要求系统提供很好的扩展性，并在容量、性能、管理等方面都能适应应用的变化； 可管理性——随着数据量的飞速增长，存储的规模越来越庞大，存储系统本身也越来越复杂，这给系统的管理、运行带来了很高的维护成本； 按需服务——能够按照应用需求的不同提供不同的服务，如不同的应用、不同的客户端环境、不同的性能等。2. 实现方法实现分布式文件系统一般有两种方法： 共享文件系统(shared file system approach)和共享磁盘(shared disk approach)。共享文件系统的方法已被许多分布式文件系统所采用，如NFS、AFS和Sprite文件系统，而使用共享磁盘方法的有VAXCluster文件系统、IBM GPFS、GFS等。共享文件系统是实现分布式文件系统单一映象功能的传统方法，它把文件系统的功能分布到客户主机和服务器上来完成这一任务。挂着磁盘的结点可以作为服务器，其他结点作为客户主机，客户主机向服务器提出请求，服务器通过文件系统调用读写其本地磁盘，然后将结果发给客户主机。在共享磁盘模型中，系统中没有文件服务器，而代之以共享磁盘。共享磁盘往往是一种专用的高端存储设备，如IBM SSA磁盘。共享磁盘和客户主机都联接在系统内部的高速网络上，通常是光通道(Fiber Channel)。每个客户都将共享磁盘作为其一个存储设备，直接以磁盘块的方式来存取共享磁盘上的文件数据。为了保证数据一致性和读写原子性，一般采用加锁或令牌机制。共享磁盘模型是构造NAS(Network Attached Storage)和SAN(Storage Area Network)等存储设备的主要方法。与共享文件系统方法相比，它对设备的要求比较高(高速网络和共享磁盘)，而且实现的难度也要大，往往被用来构造高端或专用的存储设备。共享文件系统模型实现起来比较简单，它对于设备的要求不高，而且通用性好。常见的分布式文件系统有GFS、HDFS、Hadoop、Lustre、Ceph、GridFS、mogileFS、TFS、FastDFS、NFS以及GoogleFS等，每一个都适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。当前比较流行的包括GFS、HDFS。本章重点介绍这两种分布式文件系统。5.2基 本 架 构5.2.1服务器介绍
与单机上的文件系统不同，分布式文件系统不是将这些数据放在一块磁盘上，由上层操作系统来管理,而是存放在一个服务器集群上，由集群中的服务器各尽其责、通力合作，提供整个文件系统的服务。图5.2是分布式文件系统的典型架构，其中重要的服务器包括： 主控服务器(Master/Namenode)、数据服务器(ChunkServer/Datanode)和客户服务器。HDFS和GFS都是按照这个架构模式搭建的。
图5.2分布式文件系统典型架构
1. 主控服务器存储目录结构的主控服务器，在GFS中称为master，在HDFS中称为Namenode。主控服务器在整个集群中，同时提供服务的只存在一个，这种设计策略，避免了多台服务器间即时同步数据的代价，而同时，它也使得主控服务器很可能成为整个架构的瓶颈所在。主控服务器主要的四个功能如下。(1) 命名空间的维护主控服务器负责维护整个文件系统的命名空间，并暴露给用户使用，命名空间的结构主要有典型目录树结构如MooseFS等、扁平化结构如淘宝TFS(目前已提供目录树结构支持)、图结构(主要面向终端用户，方便用户根据文件关联组织文件)。为了维护名字空间，需要存储一些辅助的元数据如文件(块)到数据服务器的映射关系、文件之间的关系等，为了提升效率，很多文件系统采取将元数据全部内存化(元数据通常较小)的方式,如GFS、TFS； 有些系统则借助数据库来存储元数据，如DBFS； 还有些系统则采用本地文件来存储元数据，如MooseFS。(2) 数据服务器管理除了维护文件系统的命名空间，主控服务器还需要集中管理数据服务器，可通过轮询数据服务器或由数据服务器报告心跳的方式实现。在接收到客户端写请求时，主控服务器需要根据各个数据服务器的负载等信息选择一组(根据系统配置的副本数)数据服务器为其服务； 当主控服务器发现有数据服务器宕机时，需要对一些副本数不足的文件(块)执行复制计划； 当有新的数据服务器加入集群或是某个数据服务器上负载过高，主控服务器也可根据需要执行一些副本迁移计划。(3) 服务调度主控服务器最终的目的是要服务好客户端的请求，除了一些周期性线程任务外，主控服务器需要服务来自客户端和数据服务器的请求，通常的服务模型包括单线程、请求线程、线程池(通常配合任务队列)。单线程模型下，主控服务器只能顺序的请求服务，该方式效率低，不能充分利用好系统资源； 请求线程的方式虽能并发的处理请求，但由于系统资源的限制，导致创建线程数存在限制，从而限制同时服务的请求数量，另外，线程太多，线程间的调度效率也存在问题； 线程池的方式目前使用较多，通常由单独的线程接受请求，并将其加入到任务队列中，而线程池中的线程则从任务队列中不断的取出任务进行处理。(4) 主备容灾主控服务器在整个分布式文件系统中的作用非常重要，其维护文件(块)到数据服务器的映射、管理所有的数据服务器状态并在某些条件触发时执行负载均衡计划等。为了避免主控服务器的单点问题，通常会为其配置备用服务器，以保证在主控服务器节点失效时接管其工作。通常的实现方式是通过HA、UCARP等软件为主备服务器提供一个虚拟IP提供服务，当备用服务器检测到主服务器宕机时，会接管主服务器的资源及服务。2. 数据服务器如果主控服务器的元数据存储是非持久化的，则在数据服务器启动时还需要把自己的文件(块)信息汇报给主控服务器。在分配数据服务器时，基本的分配方法有随机选取、RR轮转、低负载优先等，还可以将服务器的部署作为参考(如HDFS分配的策略)，也可以根据客户端的信息，将分配的数据服务器按照与客户端的远近进行排序，使得客户端优先选取离自己近的数据服务器进行数据存取。每一个文件的具体数据，被切分成若干个数据块，冗余地存放在数据服务器。数据服务器的主要工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据。数据服务器的三个主要功能如下。(1) 数据本地存储数据服务器负责文件数据在本地的持久化存储，最简单的方式是将客户的每个文件数据分配到一个单独的数据服务器上作为一个本地文件存储，但这种方式并不能很好地利用分布式文件系统的特性，很多文件系统使用固定大小的块来存储数据，如GFS、TFS、DFS，典型的块大小为64MB。对于小文件的存储，可以将多个文件的数据存储在一个块中，并为块内的文件建立索引，这样可以极大的提高存储空间利用率。Facebook用于存储照片的HayStack系统的本地存储方式为，将多个图片对象存储在一个大文件中，并为每个文件的存储位置建立索引，其支持文件的创建和删除，不支持更新(通过删除和创建完成)，新创建的图片追加到大文件的末尾并更新索引，文件删除时，简单地设置文件头的删除标记，系统在空闲时会将超过一定时限的文件存储空间进行回收(延迟删除策略)。淘宝的TFS系统采用了类似的方式，对小文件的存储进行了优化，TFS使用扩展块的方式支持文件的更新。对小文件的存储也可直接借助一些开源的KeyValue存储解决方案，如Tokyo Cabinet(HDB、FDB、BDB、TDB)、Redis等。对于大文件的存储，则可将文件存储到多个块上，多个块所在的数据服务器可以并行服务，这种需求通常不需要对本地存储做太多的优化。(2) 状态维护数据服务器除了简单的存储数据外，还需要维护一些状态，首先它需要将自己的状态以心跳包的方式周期性地报告给主控服务器，使得主控服务器知道自己是否正常工作。通常心跳包中还会包含数据服务器当前的负载状况(CPU、内存、磁盘I/O、磁盘存储空间、网络I/O、进程资源等，视具体需求而定)，这些信息可以帮助主控服务器更好地制定负载均衡策略。很多分布式文件系统如HDFS在外围提供一套监控系统，可以实时的获取数据服务器或主控服务器的负载状况，管理员可根据监控信息进行故障预防。(3) 副本管理为了保证数据的安全性，分布式文件系统中的文件会存储多个副本到数据服务器上，写多个副本的方式，主要分为3种。最简单的方式是客户端分别向多个数据服务器写同一份数据，如DNFS就是采用的这种方式； 第二种方式是客户端向主控服务器写数据，主控服务器向其他数据服务器转发数据，如TFS就是采用的这种方式； 第三种方式采用流水复制的方式，客户端向某个数据服务器写数据，该数据服务器向副本链中的下一个数据服务器转发数据，依次类推，如HDFS、GFS采取这种方式。当有节点宕机或节点间负载极不均匀时，主控服务器会制定一些副本复制或迁移计划，而数据服务器实际执行这些计划，将副本转发或迁移至其他的数据服务器。数据服务器也可提供管理工具，在需要的情况下由管理员手动地执行一些复制或迁移计划。3. 客户端此外，整个分布式文件系统还有一个重要角色是客户端。主控服务器、数据服务器都是在一个独立的进程中提供服务，而它只是以一个类库(包)的模式存在，为用户提供文件读写、目录操作等APIs。当用户需要使用分布式文件系统进行文件读写的时候，可以配置客户端的相关包，通过它来享受分布式文件系统提供的服务。客户端主要的两个功能如下。(1) 接口用户最终通过文件系统提供的接口来存取数据，Linux环境下，提供POSIX接口的支持，这样很多应用(各种语言皆可，最终都是系统调用)可以不加修改地将本地文件存储替换为分布式文件存储。(2) 缓存分布式文件系统的文件存取，要求客户端先连接主控服务器获取一些用于文件访问的元信息，这一过程一方面加重了主控服务器的负担，另一方面增加了客户端的请求响应延迟。为了加速该过程，同时减小主控服务器的负担，可将元信息进行缓存，数据可根据业务特性缓存在本地内存或磁盘上，也可缓存在远端的Cache系统上。如淘宝的TFS就是利用tair作为缓存(减小主控服务器的负担、降低客户端资源占用)。维护缓存需考虑如何解决一致性问题及缓存替换算法。一致性的维护可由客户端也可由服务器完成，一种方式是客户端周期性地使Cache失效或检查Cache有效性，或由服务器在元数据更新后通知客户端使Cache失效(需维护客户端状态)。使用得较多的替换算法如近期最少使用算法(Least Recently Used，LRU)、随机替换等。5.2.2数据分布在一个文件系统中，最重要的数据就是整个文件系统的目录结构和具体每个文件上的数据。具体的文件数据被切分成数据块，存放在数据服务器上。每一个文件数据块，在数据服务器上都表示为一对文件(这是普通的Linux文件)，一个是数据文件，另一个是附加信息的元文件，简称为数据块文件。数据块文件存放在数据目录下，它有一个名为current的根目录，然后里面有若干个数据块文件和dir0~dir63的最多64个的子目录，子目录内部结构等同于current目录，依次类推。这是磁盘上的物理结构，与之对应的，是内存中的数据结构，用以表征这样的磁盘结构，方便读写操作的进行。Block类用于表示数据块，而FSDataset类是数据服务器管理文件块的数据结构，其中，FSDataset.FSDir对应着数据块文件和目录，FSDataset.FSVolume对应着一个数据目录，FSDataset.FSVolumeSet是FSVolume的集合，每一个FSDataset有一个FSVolumeSet。多个数据目录可以放在不同的磁盘上，这样有利于加快磁盘操作的速度。此外，与FSVolume对应的，还有一个数据结构，就是DataStorage，它是Storage的子类，提供了升级、回滚等操作的支持。但与FSVolume不一样的是，它不需要了解数据块文件的具体内容，它只知道有这么一堆文件放在这里，会有不同版本的升级需求，它会处理升级、回滚之类的业务。而FSVolume提供的接口，都基本上是和Block相关的。相比数据服务器，主控服务器的数据量不大，但逻辑更为复杂。主控服务器主要有三类数据： 文件系统的目录结构数据、各个文件的分块信息和数据块的位置信息。在GFS和HDFS的架构中，只有文件的目录结构和分块信息才会被持久化到本地磁盘上，而数据块的位置信息则是通过动态地汇总过来的，仅仅存活在内存数据结构中。每一个数据服务器启动后，都会向主控服务器发送注册消息，将其数据块的状况都告知于主控服务器。5.2.3服务器间协议如图5.3所示，客户端、主控服务器以及数据服务器之间都遵循着互相的协议，例如客户端与主控服务器之间的ClientProtocol、主控服务器与数据服务器之间的DataNodeProtocol等。在Hadoop的实现中，部署了一套远程过程调用协议(Remote Procedure Call Protocol，RPC)机制，以此来实现各服务间的通信协议。在Hadoop中，每一对服务器间的通信协议，都被定义为一个接口。服务端的类实现该接口，并且建立RPC服务，监听相关的接口，在独立的线程中处理RPC请求。客户端则可以实例化一个该接口的代理对象，调用该接口的相应方法，执行一次同步的通信，传入相应参数，接收相应的返回值。基于此RPC的通信模式，是一个消息拉取的流程，RPC服务器等待RPC客户端的调用，而不会主动把相关信息推送到RPC客户端去。
图5.3分布式文件系统的服务间之间的协议
5.3GFS GFS(Google File System)是由Google开发并设计的一个面向大规模数据处理的分布式文件系统。为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统。它是由几百甚至几千台普通的廉价设备组装的存储机器。以下是对于GFS的一些介绍。(1) 系统包括了许多机器，这些设备中的某些机器出现故障是很常见的事情，所以在GFS集成了持续的监控、错误侦测、灾难冗余以及自动恢复的机制。(2) 系统要存的数据很大，所以要是按照以往的存储文件块大小，那么就要管理数亿个KB大小的小文件，这是很不合理的，所以在这个系统里面他们定义一个文件块的大小是64MB。大的文件块会带来的好处如下。① 减少Client和Master的交互次数，因为读写同一个块只需要一次交互，这样在GFS中假设的顺序读写负载的场景下特别有用； ② 同样也减少了Client和Chunkserver的交互次数，降低TCP/IP连接等网络开销； ③ 减少了元数据的规模，因此Master可以将元数据完全放在内存中，这对于集中式元数据模型的GFS尤为重要。(3) 绝大部分的大数据都是采用在文件尾部追加数据的方式，而不是覆盖数据。对大文件的随机写入基本上是不存在的。5.3.1架构设计GFS采用主/从模式，一个GFS包括一个Master服务器和多个Chunk服务器。当然这里的一个Master是指逻辑上的一个，物理上可以有多个(就是可能有两台，一台用于备用，另一台用于正常的数据管理)。并且我们可以把以及Chunk服务器放在同一台机器上。GFS的系统架构如图5.4所示，其中包括了数据信息和控制信息的流通。
图5.4GFS的系统架构
Master(主服务器)作为管理节点，保存系统的元数据，负责整个文件系统的管理。Chunk服务器作为数据块服务器，主要负责具体的存储工作，数据以文件的形式存储在Chunk服务器上。Master管理着所有文件的元数据，如名字空间、block的映射位置等。Master节点使用心跳信息周期地和每个Chunk服务器通讯，发送指令到各个Chunk服务器并接收Chunk服务器的状态信息。单一节点(逻辑上)的Master可以通过全局信息精确地定位到每个block在哪个Chunk服务器上，从而进行复制决策。由于只有一台Master，所以尽量要减少对Master的读写操作，避免Master成为系统的瓶颈。而且Master的元数据都是存储在内存当中的，这样处理速度比较快，但是也导致了存储的数据是有限制的弊端。Client对数据的读写不是在Master上，而是通过Master获取block在Chunk上的位置信息，直接和Chunk服务器进行数据交互读写。Chunk是真正用于存储数据的机器，用来存储的文件大小为64MB，这个尺寸远远大于一般文件系统的block size。每个block的副本都以普通Linux文件的形式保存在Chunk服务器上。Master服务器并不是持久化地保存Chunk服务器保存的指定block的副本信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器能够保证它持有的信息始终是最新的，因为它控制了所有的block位置的分配，而且通过周期性地心跳信息监控Chunk服务器的状态。5.3.2实现流程(1) Client将文件名和程序指定的字节偏移，根据固定的block大小，转换成文件的block索引。(2) Client把文件名和block索引发送给Master节点。Master节点将相应的Block标识和副本的位置信息发还给Client。Client用文件名和block索引作为key缓存这些信息。(3) Client发送请求到其中的一个Chunk处，一般会选择最近的。请求信息包含了block的标识和字节范围。在对这个block的后续读取操作中，Client不必再和Master进行节点通信，除非缓存的元数据信息过期或者文件被重新打开。实际上，Client通常会在一次请求中查询多个block信息。(4) Chunk服务器返回给Client要读取的Chunk数据。GFS数据的布局如下。GFS将文件条带化，按照类似RAID0的形式进行存储，可以提高聚合带宽，将文件按固定长度切分为数据块，Master在创建一个新数据块时，会给每个数据块分配一个全局唯一且不可变的64位ID。每个数据块以Linux文件的形式存储在Chunk服务器的本地文件系统里。为了提高数据的可靠性和并发性，每一个数据块都有多个副本。当客户端请求一个数据块时，Master会将所有副本的地址都通知Client，Client再择优(距离最短等)选择一个副本。一个典型的GFS集群可能有数百台服务器，跨越多个子网，因此在考虑副本的放置时，不仅要考虑机器级别的错误，还要考虑整个子网瘫痪的时候该如何解决。将副本分布到多个子网去，还可以提高系统的聚合带宽。因此创建一个数据块时，主要考虑的几个因素如下。(1) 优先考虑存储利用率低于平均水平的结点； (2) 限制单个结点同时创建副本的数量； (3) 副本尽量跨子网。5.3.3特点表5.1对GFS和传统的分布式文件系统进行的比较分析，GFS的特点体现在如下几个方面。
表5.1GFS和传统分布式文件系统的比较
文件系统组件失败管理文件大小数据写方式数据流和控制流
GFS不作为异常处理少量大文件在文件末尾追加数据数据流和控制流分开传统分布式文件系统作为异常处理大量小文件修改现存数据数据流和控制流结合1) 控制流和数据流的分离Client首先访问Master节点，获取交互的Chunk服务器信息，然后访问这些Chunk服务器，完成数据读取工作。2) 降低Master的负载Client和Master之间只有控制流，而无数据流，这极大地降低了Master的负载。3) 性能提高Client与Chunk之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个Chunk服务器，从而使得整个系统的I/O高度并行，系统的整体性能得到很大的提高。4) 在用户态下实现利用POSIX编程接口读取数据降低了实现难度，提高了通用性，而且POSIX接口提供丰富的功能。在用户态下有多种调试工具，并且GFS和操作系统是运行在不同的空间中，大大降低了两者的耦合性。5.4HDFSHDFS(Hadoop Distributed File System)是Hadoop的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式进行访问和处理超大文件的需求而开发的，它可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集(Large Data Set)的应用处理带来了很多便利。5.4.1基本概念1. 数据块大文件会被分割成多个block进行存储。每一个block会在多个Datanode上存储多份副本，默认是3份。和GFS一样的是，HDFS默认的最基本的存储单位是64MB的数据块，这个数据块可以理解和一般的文件里面的分块是一样的。不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。2. 元数据节点和数据节点元数据节点(Namenode)用来管理文件系统的命名空间，它将所有的文件和文件夹的元数据保存在一个文件系统树中，并且它管理文件目录、文件和block的对应关系以及block和Datanode的对应关系。这些信息在本地文件系统中以两种形式永久保存： namespace image(包括namespace中所有文件的inode和block列表)和edit log(记录了所有用户对HDFS所做的更改操作)。Namenode也保存着构成给定文件的block的位置，但这些信息并不是永久地保存在磁盘中的，因为这些信息是在系统启动时根据Datanode的反馈信息重建、并且是定时基于Datanode的报告更新的，具有很强的动态性。数据节点(Datanode)就是用来存储数据文件的。大部分容错机制都是在Datanode上实现的。Client或者Namenode可以向Datanode请求写入或者读出数据块。并且周期性地向Namenode汇报其存储的数据块信息。从元数据节点(Secondary Namenode)不是我们所想象的元数据节点的备用节点，其实它主要的功能是周期性地将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。3. HDFS的设计目标如下。(1) 错误检测和快速、自动地恢复是HDFS的核心架构目标。(2) 比起关注数据访问的低延迟问题，HDFS的设计更关键的着重于数据访问的高吞吐量。(3) HDFS应用对文件要求的是writeonereadmany访问模型。(4) 移动计算的代价比移动数据的代价要低。5.4.2架构设计HDFS是一个主/从(Mater/Slave)体系结构。从最终用户的角度来看，它就像传统的文件系统一样，可以通过目录路径对文件进行CRUD(Create、Read、Update和Delete)操作。但由于分布式存储的性质，HDFS集群拥有一个Namenode和一些Datanodes。图5.5为HDFS的系统架构，其中客户端通过Namenode和Datanodes的交互访问文件系统。客户端通过Namenode获取文件的元数据，而真正的文件I/O操作是直接和Datanode进行交互的。
图5.5HDFS的系统结构
1) 文件写入客户端调用create( )来创建文件，DistributedFileSystem用RPC调用Namenode，在文件系统的命名空间中创建一个新的文件。Namenode首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。DistributedFileSystem返回DFSOutputStream，客户端用于写数据。客户端开始写入数据，DFSOutputStream将数据分成块，写入Data queue。Data queue由Data Streamer读取，并通知Namenode分配Datanode，用来存储数据块，分配的Datanode放在一个pipeline里。DataStreamer将数据块写入pipeline中的第一个Datanode。第一个Datanode将数据块发送给第二个Datanode。第二个Datanode将数据发送给第三个Datanode。DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的Datanode告知数据已经写入成功。如果Datanode在写入的过程中失败则关闭pipeline，将ack queue中的数据块放入Data queue的开始位置。整个过程如图5.6所示。
图5.6文件写入的流程
2) 文件读取客户端用FileSystem的open()函数打开文件，DistributedFileSystem用RPC调用Namenode，得到文件的数据块信息。对于每一个数据块，Namenode返回保存数据块的datanode的地址。DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。客户端调用stream的read()函数开始读取数据。DFSInputStream连接保存此文件第一个数据块的最近的Datanode。Data从Datanode读到客户端，当此数据块读取完毕时，DFSInputStream关闭和此Datanode的连接，然后连接距离此文件下一个数据块的最近的Datanode。当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。整个过程如图5.7所示。
图5.7文件读取的流程
5.4.3优缺点分析1. 优点1) 处理超大文件这里的超大文件通常是指数百MB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。2) 流式地访问数据HDFS的设计建立在更多地响应“一次写入、多次读写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及到数据集中的大部分数据，也就是说，对于HDFS来说，请求读取整个数据集要比读取一条记录更加高效。3) 运行于廉价的商用机器集群上Hadoop的设计对硬件需求比较低，只需运行在低廉的商用硬件集群上，而无须在昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性、安全性及高可用性。2. 缺点1) 不适合低延迟数据访问如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。2) 无法高效存储大量小文件因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定的。一般来说，每一个文件、文件夹和block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个文件占据一个block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Maptask的数量是由splits来决定的，所以用MR(MapRedule)处理大量的小文件时，就会产生过多的Map task，线程管理开销将会增加作业时间。举个例子，处理10000MB的文件，若每个split为1MB，那就会有10000个Maptask，会有很大的线程开销； 若每个split为100MB，则只有100个Maptask，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。3) 不支持多用户写入及任意修改文件在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。5.5分布式应用协调器ZooKeeper5.5.1基本概念
ZooKeeper是Hadoop的正式子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括： 配置维护、名字服务、分布式同步、组服务等。1. 角色ZooKeeper中的角色主要有如下三类。(1) 领导者(leader)： 领导者负责进行投票的发起和决议，更新系统状态。(2) 学习者(learner)① 跟随者(follower)： 用于接收客户请求并向客户端返回结果，在选主过程中参与投票。② 观察者(observer)： 可以接收客户端连接，将写请求转发给leader节点。但observer不参加投票过程，只同步leader的状态。Observer的目的是为了扩展系统，提高读取速度。(3) 客户端(Client)： 请求发起方。系统模型如图5.8所示。在ZooKeeper服务集群中，每个服务器都是知道彼此的存在的。客户端在连接ZooKeeper服务集群时，会按照一定的随机算法连接到其中一个服务器上。当其中一个客户端修改数据时，ZooKeeper会将修改同步到所有的服务器上，从而使连接到其他服务器上的客户端也能看到数据的修改。
图5.8ZooKeeper系统模型
2. 设计目的(1) 最终一致性： Client不论连接到哪个Server，展示给它的都是同一个视图，这是ZooKeeper最重要的性能。(2) 可靠性： 具有简单、健壮、良好的性能，如果消息m被一台服务器接收，那么它将被所有的服务器接收。(3) 实时性： ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。(4) 等待无关(waitfree)： 慢的或者失效的Client不得干预快速的Client的请求，这使得每个Client都能有效的等待。(5) 原子性： 更新只能成功或者失败，没有中间状态。(6) 顺序性： 包括全局有序和偏序两种： 全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布； 偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户使用。5.5.2工作原理ZooKeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫作Zab协议。Zab协议有两种模式，它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在Leader崩溃后，Zab就进入了恢复模式，当Leader被选举出来时，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。为了保证事务的顺序一致性，ZooKeeper采用了递增的事务ID号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。在实现中zxid是一个64位的数字，其中高32位是epoch用来标识Leader关系是否改变，每次一个Leader被选出来，它都会有一个新的epoch，标识当前属于那个Leader的统治时期。低32位用于递增计数。每个server在工作过程中有如下三种状态。(1) LOOKING： 当前Server不知道Leader是谁，正在搜寻Leader； (2) LEADING： 当前Server即为选举出来的Leader； (3) FOLLOWING： Leader已经选举出来，当前Server与之同步。选完Leader以后，ZooKeeper就进入状态同步过程，同步流程如下。(1) Leader等待Server连接； (2) Follower连接Leader，将最大的zxid发送给Leader； (3) Leader根据Follower的zxid确定同步点； (4) 完成同步后通知Follower已经成为uptodate状态； (5) Follower收到uptodate消息后，可以重新接受Client的请求进行服务。流程图如5.9所示。
图5.9同步流程
ZooKeeper提供的是类似文件系统的服务，但其设计目的并不是进行数据的存储，而是对一个分布式系统进行协同。ZooKeeper的存储单元叫作ZNode，可以将其理解为是传统意义上的文件与文件夹的混合体，即一个ZNode既可以像文件夹一样包含其他ZNode，又可以同时像文件一样保存一定的数据。ZNode分为两类： 永久性ZNode和临时性ZNode。永久性ZNode是创建之后就会一直存在的ZNode，除非对其进行删除否则不会消失； 而临时性ZNode 的存在与否是与创建这个ZNode的进程是否继续存在相关的。对于一个临时性的ZNode，当创建这个ZNode的进程不再存在时，这个ZNode会随之消失。为了能够对分布式系统提供协同支持，ZooKeeper针对每一个ZNode提供了添加Watch的特性。一个Watch就是ZooKeeper客户端添加在一个ZNode上的监听器，可以监听ZNode的增加、删除以及ZNode本身存储内容的改变。当所监听的内容发生变化时，客户端便会收到通知，从而进行相应的处理。5.5.3ZooKeeper应用对HDFS的改进如上节所讲，Namenode是整个HDFS的核心，HDFS所有的操作均需由Namenode参与。并且，Namenode负责维护整个分布式文件系统中所有文件的元信息以及目录信息，如果Namenode出现了失败，那么HDFS中所有文件信息将全部丢失。虽然HDFS针对每一个文件都可以根据配置进行多份数据备份，但是Namenode却只有一个。这使得Namenode成为了HDFS中的薄弱点，如果Namenode发生单点失败将导致整个HDFS系统的失败。HDFS中使用Secondary Namenode解决Namenode失败的问题。但是利用Secondary Namenode解决Namenode单点失败的方式虽然可以在一定程度上恢复之前的文件系统，但是存在许多问题，例如必须通过人工的方式寻找并拷贝Secondary Namenode中保存的快照文件，手工重启Namenode，无法自动化完成。利用ZooKeeper可以对HDFS中Namenode单点失败进行如下改进。为了解决Namenode单点失败造成的问题，改进的HDFS系统中可配置多个Namenode，每个Namenode与所有的Datanode均有联系，且向ZooKeeper注册自己的存在(在特定的ZNode下创建临时性ZNode，并将自身位置信息保存在对应ZNode中)。与此同时，架构中加入一个角色Dispatcher，负责将读、写请求传递给活跃的Namenode执行、处理多个Namenode的同步以及互斥问题，并根据ZooKeeper提供的信息监控Namenode的健康情况以确保当某个Namenode发生失败后将其从“活跃的”Namenode列表中去除。5.5.4主要应用场景1. 配置管理集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。ZooKeeper很容易实现这种集中式的配置管理，例如将APP1的所有配置配置到/APP1 znode下，这样当APP1所有机器一启动时就对/APP1这个节点进行监控，并且实现回调方法Watcher，那么在ZooKeeper上/APP1 znode节点下的数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可。2. 集群管理应用集群中，常常需要让每一个机器知道集群中(或依赖的其他某一个集群)哪些机器是活着的，并且在集群机器因为宕机、网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。ZooKeeper同样很容易实现这个功能，例如在ZooKeeper服务器端有一个Znode叫/APP1SERVERS，那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，例如Server1创建/APP1SERVERS/SERVER1(可以使用ip，保证不重复)，Server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点，那么也就是当这个父节点下的数据或者子节点发生变化时都会通知对该节点进行watch的客户端。因为EPHEMERAL类型的节点有一个很重要的特性，就是当客户端和服务器端连接中断或者Session过期时就会使节点消失，那么在某一个机器宕机或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知，然后取得最新列表即可。另外有一个应用场景就是集群选Master，一旦Master挂掉可以立刻能从Slave中选出一个Master，实现步骤和前者一样，只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型，这样每个节点会自动被编号。5.6云存储5.6.1基本概念
1. 云状网络结构如图5.10所示，广域网和互联网对于具体的使用者来说是完全透明的，我们经常用一个云状的图形来表示广域网和互联网。虽然云状的图形中包含了许许多多的交换机、路由器、防火墙和服务器，但对具体的广域网、互联网用户来讲，这些都是不需要知道的。这个云状图形代表的是广域网和互联网带给大家的互联互通的网络服务，无论我们在任何地方，都可以通过一个网络接入线缆和一个用户、密码，就可以接入广域网和互联网，享受网络带给我们的服务。
图5.10云状的网络结构
2. 云状结构的存储系统参考云状的网络结构，如图5.11所示，创建一个新型的云状结构的存储系统，这个存储系统由多个存储设备组成，通过集群功能、分布式文件系统或类似网格计算等功能联合起来协同工作，并通过一定的应用软件或应用接口，对用户提供一定类型的存储服务和访问服务。
图5.11云状结构的存储系统
当我们使用某一个独立的存储设备时，我们必须非常清楚这个存储设备是什么型号、什么接口和它的传输协议，必须清楚地知道存储系统中有多少块磁盘，分别是什么型号、多大容量，必须清楚存储设备和服务器之间采用什么样的连接线缆。为了保证数据安全和业务的连续性，我们还需要建立相应的数据备份系统和容灾系统。除此之外，对存储设备进行定期的状态监控、维护、软硬件更新和升级也是必需的。如果采用云存储，参考云状的网络结构，创建一个新型的云状结构的存储系统。那么上面所提到的一切对使用者来讲都不需要了。云状存储系统中的所有设备对使用者来讲都是完全透明的，任何地方的任何一个经过授权的使用者都可以通过一根接入线缆与云存储连接，对云存储进行数据访问。3. 云存储的概念云存储的概念与云计算类似，它是指通过集群应用、网络技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来进行协同工作，共同对外提供数据存储和业务访问功能的一个系统。云计算系统不但能对数据进行处理和运算，系统中还有大量的存储阵列设备，以实现对计算数据的保存和管理。在云计算系统中配置相应的存储设备，该计算系统即拥有了云存储系统功能。云存储与传统存储的区别如下。1) 功能需求云存储系统面向多种类型的网络在线存储服务，传统存储系统则面向如高性能计算、事务处理等应用； 2) 性能需求数据的安全性、可靠性、效率等技术挑战； 3) 数据管理云存储系统不仅要提供传统文件访问，还要能够支持海量数据管理并提供公共服务支撑功能，以方便云存储系统后台数据的维护。5.6.2云存储的分类云存储包括数据块级云存储、文件级云存储和对象级云存储。1. 数据块级云存储数据块级云存储是指提供高速、直接的数据块存储访问服务。前端的计算节点通过光纤网络访问协议、访问存储，获得高速、稳定、有保障的数据访问。这种模型源于在关键业务系统中久经验证的存储局域网SAN模型。不过在云存储的时代，改为分布式的并行扩展模式。由于此模型采用的是高带宽、低延迟、可靠的光纤网络存储访问协议，前端计算节点独享或少量共享存储内容的数据结构，因此，和前端的计算节点是属于紧耦合的关系，性能是最优的。数据块级云存储会把单笔的数据写到不同的硬盘，借以得到较大的单笔读写带宽，适合用在数据库或是需要单笔数据快速读写的应用。它的优点是对单笔数据读写很快，缺点是成本较高，并且无法解决真正海量文件的储存，这一类型的云存储有EMC的VMAX系列以及EqualLogic 3PAR的产品。快速更改的单一文件系统和针对单一文件大量写的高性能计算(HPC)比较适合数据块级云存储。2. 文件级云存储文件级云存储是通过网络文件系统访问协议提供文件级的存储访问服务。这种模型源于网络附加存储NAS的模型，计算节点通过以太网的协议，在其上构建区域内相对快速、安全、可靠的网络文件系统来获得文件的访问服务。不过在云存储的时代，文件级云存储突破了传统NAS访问空间的局限，提供了高达PB级的全局命名空间的访问能力。这种模型和前端节点是C/S的模型，二者采用树状的文件系统结构来存储和访问数据，属于中耦合的关系，在区域内性能有足够的保证。它是把一个文件放在一个硬盘上，即使文件太大拆分时，也放在同一个硬盘上。它的缺点是对单一文件的读写会受到单一硬盘效能的限制，优点是对一个多文件、多人使用的系统，总带宽可以随着存储节点的增加而扩展，它的架构可以无限制的扩容，并且成本低廉。这一类型的云存储有EMC的iSilon、HP的IBRIX以及Parascale等。如果所需的文件及文件系统本身较大、文件使用期较长以及对成本控制要求较高的话比较适合文件级云存储。3. 对象级云存储对象级云存储通过广域网的面向对象的访问协议来获取对象级的存储访问服务。对象和文件既有相似之处，也有区别。对象通常改动较少，并且拥有许多的属性，而且为多租户使用。这种模型源自于早期EMC推出的CAS存储系统。但是，在云存储时代，突破了访问地域的限制，借助于面向对象的访问协议，用户可以在全球任何地点访问对象级存储云中储存的对象内容。对象级云存储面向的是海量的各种尺寸、不同格式的对象内容，为提高访问效率，前端计算节点并不关心对象级云存储内部的存储方法和数据结构的模型。它属于松耦合的关系。这一类型的云存储有EMC的Atmos、华为的OceanStor等。5.6.3云存储的结构模型与传统的存储设备相比，云存储不仅仅是一个硬件，而是一个由网络设备、存储设备、服务器、应用软件、公用访问接口、接入网和客户端程序等多个部分组成的复杂系统。各部分以存储设备为核心，通过应用软件来对外提供数据存储和业务访问服务。如图5.12所示，云存储系统的结构模型由4层组成，分别是存储层、基础管理层、应用接口层和访问层。
图5.12云存储系统的结构模型
1) 存储层存储层是云存储最基础的部分。存储设备可以是FC光纤通道存储设备，可以是NAS、iSCSI等IP存储设备，也可以是SCSI、SAS等DAS存储设备。云存储中的存储设备往往数量庞大且分布在不同地域，彼此之间通过广域网、互联网或者FC光纤通道网络连接在一起。存储设备之上是一个统一存储设备管理系统，可以实现存储设备的逻辑虚拟化管理、多链路冗余管理，以及硬件设备的状态监控和故障维护。2) 基础管理层基础管理层是云存储最核心的部分，也是云存储中最难以实现的部分。基础管理层通过集群、分布式文件系统和网格计算等技术，实现云存储中多个存储设备之间的协同工作，使多个存储设备可以对外提供同一种服务，并提供更大、更强、更好的数据访问性能。CDN内容分发系统、数据加密技术保证云存储中的数据不会被未授权的用户所访问，同时，通过各种数据备份、容灾技术和措施可以保证云存储中的数据不会丢失，保证云存储自身的安全和稳定。3) 应用接口层应用接口层是云存储最灵活多变的部分。不同的云存储运营单位可以根据实际业务类型，开发不同的应用服务接口，提供不同的应用服务。例如视频监控应用平台、IPTV和视频点播应用平台、网络硬盘引用平台、远程数据备份应用平台等。4) 访问层任何一个授权用户都可以通过标准的公用应用接口来登录云存储系统，享受云存储服务。云存储运营单位不同，云存储提供的访问类型和访问手段也不同。5.6.4典型的云存储应用云存储能提供什么样的服务取决于云存储结构模型的应用接口层中内嵌了什么类型的应用软件和服务。云存储可以支持多种应用方式，如云备份、云数据共享、云资源服务等，也可以提供标准化的接口给其他网络服务使用。云存储服务可以分为个人级应用和企业级云存储。1. 个人级应用个人级云存储的应用包括网络磁盘、在线文档编辑以及在线的网络游戏等。1) 网络磁盘很多人都使用过腾讯、MSN、百度等很多大型网站所推出的“网络磁盘”服务。图5.13是目前广泛应用的百度云网盘。百度云网盘等网络磁盘是在线存储服务，使用者可以通过Web访问方式来上传和下载文件，实现个人重要数据的存储和网络化备份。高级的网络磁盘可以提供Web页面和客户端软件等两种访问方式，具体应用包括百度云、阿里云等。网络磁盘的容量空间一般取决于服务商的服务策略，或者取决于使用者想支付服务商费用的多少。例如百度云可以免费提供用户5G的网盘存储，但用户若想要更大的存储空间，则需要付费购买。
图5.13百度云网盘
2) 在线文档编辑经过近几年的快速发展，Google所能提供的服务早已从当初单一的搜索引擎，扩展到了Google Calendar、Google Docs、Google Scholar等多种在线应用服务，一般都把这些在线的应用服务称之为云计算。图5.14是Google Docs的界面，相对于传统的文档编辑软件，Google Docs的出现使我们的使用方式和使用习惯发生转变，用户不再需要在个人PC或者笔记本电脑上安装Office等软件，只需要打开Google Docs网页，通过Google Docs就可以进行文档编辑和修改(使用云计算系统)，并将编辑好的文档保存在Google Docs服务所提供的个人存储空间中(使用云存储系统)。无论走到哪儿，都可以再次登录Google Docs，打开保存在云存储系统中的文档。通过云存储系统的权限管理功能，还能实现文档的共享、传送以及版权管理。
图5.14Google Docs界面
3) 在线的网络游戏近年来，网络游戏越来越受到年轻人的喜爱，各种不同主题和风格的游戏层出不穷，但是由于带宽和单台服务器的性能限制，要满足成千上万个玩家在线，网络游戏公司就需要在全国不同地区建设很多个游戏服务器，这些服务器上的玩家相互之间是完全隔离的，然而通过云存储系统和云计算来构建一个庞大的、超能的游戏服务器群，这个服务器群系统对于游戏玩家来讲，就如同是一台服务器。云计算和云存储的应用，可以代替现有的多服务器架构，使所有人都能集中在一个服务器组的管理之下。2. 企业级云存储企业级云存储的应用包括空间租赁服务、数据备份和容灾等。1) 空间租赁服务信息化的不断发展使得各单位的信息数据量呈几何曲线性增长。数据量的增长不仅仅意味着更多的硬件设备投入，还意味着更多的机房环境设备投入，以及运行维护成本和人力成本的增加。即使是现在仍然有很多的中小企业没有资金购买独立的、私有的存储设备，更没有存储技术工程师可以有效地完成存储设备的管理和维护。通过高性能、大容量云存储系统，可以为无法单独购买大容量存储设备的企事业单位提供方便快捷的空间租赁服务，满足不断增加的业务数据存储和管理服务。同时，大量专业技术人员的日常管理和维护可以保障云存储系统运行安全，确保数据不会丢失。2) 数据备份和容灾随着企业数据量的不断增加，数据的安全性要求也在不断增加。企业中的数据不仅要有足够的容量空间去存储，还需要实现数据的安全备份和远程容灾。不仅要保证本地数据的安全性，还要保证当本地发生重大的灾难时，可通过远程备份或远程容灾系统进行快速恢复。通过高性能、大容量云存储系统和远程数据备份软件，可以为所有需要远程数据备份和容灾的企事业单位提供空间租赁和备份业务租赁服务，普通的企事业单位、中小企业可租用空间服务和远程数据备份服务功能，也可以建立自己的远程备份和容灾系统。5.7小结网络的出现给计算机界带来了新的革命，从开始的实现两台机器之间拷贝文件实现共享，到后来出现了可以透明访问远程文件的文件系统。分布式文件系统将用户的共享性扩展到通过网络连接的不同机器上，从而为海量数据的应用提供了存储基础。云计算的分布式文件系统是整个云计算的基石，它提供上层表格系统所需的可靠和高效的数据存储。在云计算时代，存储理所当然地被作为一种服务提供给用户。无论是应用于公有云环境中的存储资源，还是用于私有云环境中的存储资源，都应该更容易地被分享，并且能够按需付费进行试用。继虚拟化之后，本章介绍的是另外一个实现云计算的基础——分布式文件系统，其中重点讲解了GFS、HDFS这两种目前比较常用的分布式文件系统，包括它们各自的架构设计、基本概念、实现流程以及特点分析； 然后提到了分布式应用协调器ZooKeeper的相关知识，以及它对HDFS的改进； 最后讲解了云存储的相关概念。通过对本章的学习，读者可以更进一步地学习到分布式文件系统的具体知识，同时对云计算有更深的认识。5.8习题1. 分布式文件系统的定义是什么？2. 常用的分布式文件系统有哪些？3. GFS和HDFS有什么区别？4. ZooKeeper的作用是什么？5. 云存储的概念是什么？
云计算导论 pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
