云计算渣渣

[か欢情薄★]

之前在没有接触到云计算之前，只是对云计算有一点点模糊的概念，觉得这是一个很高大上的东西，似乎离我们的还很远。经过老师的介绍和建议，我拜读了Google的三大论文，不敢说理解，至少囫囵吞枣啃下了一大堆看不明白的理论。现在就我浅薄的理解，简单聊聊Google File System 首先我们要知道Google GFS是一种文件系统，是一个面向大规模数据密集型应用的、可扩展的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。 那么他既然是一种文件系统，他首先就具有与过去的分布式文件系统很多相同的目标。但是，对于GFS的设计还是以对自己的应用的负载情况和技术环境的分析为基础的，不管现在还是将来，GFS和早期的分布式文件系统的设想都有明显的不同。 一、设计思路上的不同 1.组件失效被认为是常态事件，而不是意外事件。 2.按照传统的标准，文件都非常大。设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。 3.大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。 4.工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作 5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。 在随机位置对少量数据的写操作也支持，但不必非常高效。 6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。 二、结构体系 一个GFS集群包含了一个单独的Master节点（Master）、多台Chunk服务器（Chunkserver），并且同时被多个客户端（Client）访问。 Master：管理元数据、整体协调系统活动 ChunkServer：存储维护数据块，读写文件数据 Client：向Master请求元数据，并根据元数据访问对应ChunkServer的Chunk 三、GFS主要需要关注的几个问题 （1）系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件 （2）系统存储一定数量的大文件，以通常的标准衡量，我们的文件非常巨大，采用管理数亿个KB大小的小文件的方式非常不明智，因此，设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑 四、启示 无论是硬件设计还是软件设计，一个好的系统应当是一适用性广泛、高性能、可靠性非常高的。为了达到这样一个并不容易的目的，我们除了付出不懈努力，去提高单一部件的性能，也可以考虑通过科学的任务分配，让一个由成本低廉的部件的集群共同分担风险。尤其是在当前硬件技术濒临极限，性能需求水涨船高的当下，用数量保证质量，靠概率保证性能不失为一种可靠的选择。