剖析云计算技术及架构（3 云存储）

 

       存储在计算机系统中非常重要，前面的博文中的存储主要是基于已有的数据库系统，这一篇，我们就来看看不采用数据库系统，怎么来做云存储。在云存储中，我们不考虑单台存储设备的支持，因为这已经是现成的，我们将讨论的云存储将基于已有的操作系统和文件系统，从头开始不太可能也不太现实，我们只需要关注我们现在应该关心的一些地方。云存储要达到的一个根本目标就是随需应变，对于用户来讲，其实就是要求空间是无限大的，数据是非常安全可靠的，而用起来是非常简单的。当然性能和低廉的成本也是必须考虑的。
       要降低成本，购买昂贵的存储设备当然就不是首选了，现在一般的PC机价格低廉，我们完全可以利用这个优势。因此我们就可以用PC机或者廉价的存储设备做存储节点。怎么去实现呢？我们知道，单台设备的能力的提高总是有限的，因此利用很多廉价的设备组成一个大的存储系统就不失为一种好的选择。
       首先，我们要保证一定的存储能力，假设单台计算机的存储空间是1T,那么我用m台计算机组成集群，存储能力就可以达到mT，因为扩展都是以节点为单位的，是通过软件来管理的，因此这种方式要扩展存储能力是非常灵活和方便的。
        其次，要保证可靠性。其实保证可靠性除了提高单台计算机的存储可靠性之外，就是进行数据冗余存储，一份数据在多个地方进行备份，这种备份方式也不用非常多，对于一般应用来说3份就足够了。如果存3份，那么m台存储设备的实际存储能力就成了(m/3)T,但这个不是问题，要可靠也要付出代价的。这三份怎么放可靠性比较好呢？当然不能都放在一台机器上，应该是3份在存储位置上，物理的距离越远越好。但事情总是有利有弊，因为备份之间是要维持一致性的，相距越远，这种一致性维护成本就越大（通信和带宽）。雅虎的那种几大洲分布式数据中心方式，对于一般云存储厂商来说还是比较贵，如果是私有云，一般企业也没有这个能力做到这种。为了便于实现，其实m台存储设备可以分为3组，组之间保持一定的距离，这样既提高了存储的可靠性，还便于云存储管理软件的设计。3个组虽然不需要严格的对应，但所能提供的存储空间还是需要大致相同。
       第三，为了提高数据的可靠性，我们可以采用上述的冗余存储的方式，但具体如何存储呢？我们提供给客户的存储，也是以文件的形式存在。如果采用以文件为基本单位来存储数据，冗余在3台物理的存储设备上，简单是简单，但会有一个问题，假设文件在A1,B1,C1三台机器上已经存在，现在附加数据超过了三台设备中某些台的空间，问题就来了，需要重新找能够存放这个文件的设备，在某些情况下如果非常大的话，还不一定能找到，而且也会带来存储设备的利用率也会降低。处理的办法其实也很简单，就是学习操作系统存放文件的方式，以文件块为基本单位来存放。每个文件维持一个文件块列表，只要文件块保持3份，每份都放在不同的组，至于组内是否在同一台机器，就不要求了。因为文件块得大小是可以设置的，一般都比文件小很多，所以不会带来上述空间利用率不够或者是文件太大无法找到可用的存储位置的问题。文件块得大小可以根据自己的应用确定，一般以存图片或者小视频的网站，选用2M或者4M都可以，目的就是让大多数的文件的文件块都比较少。Google的GFS采用的64M，适合于大文件处理。一般来讲，如果文件块太小，文件的文件块就多，不利于索引，但如果文件块太大，而文件访问都是基于文件块的，并非每次访问都需要全部读过来，因此就会造成读写浪费。大家注意，这些文件块在单台计算机上是以文件的形式存在的。
       第四，文件的访问需要比较方便，操作要比较容易，如果文件在这种分布式存储体系中的信息需要用户自行维护，那肯定是不现实的。因此需要一台专门的服务器Master来维护文件的存放信息和控制信息（权限等）。这台服务器（可采用传统的磁盘阵列之类的手段来提高可靠性）维护用户文件到文件块映射关系。现在有两种方式来处理用户的读写，一种是用户发出读写命令（假设以文件名，文件块集合为参数），由服务器来完成实际读写，把结果反馈给用户，这种方式大家一看就知道有个非常大的局限，服务器的压力太大，因为文件的读写数据流都是比较大的。但这种方式也有好处，就是接口单一，用户透明，用户程序可以比较简单。另外一种方式就是，用户向服务器只是发送读写请求，服务器返回文件的位置信息，有用户本身直接与存储设备通信完成实际文件块得读写，这样，Master服务器的压力就小很多。这其实就是GFS所采用的方式（里面叫数据流和控制流分离）。但这种方式有个缺点，就是用户程序需要直接参与到存储服务中，易用性和透明性都比较差。当然，在GFS中这是数据存储与应用Api协调设计的理念体现。
        到这里，一个云存储的底层架构就出来了：将低廉的计算机（每台kT空间）作为存储节点，存储节点n台，分为3组（每组存储能力大致相同），一台主服务器负责管理这些节点，服务器存放着用户文件的文件块映射和访问权限控制等信息，文件块在每个节点计算机里以一个文件的形式存在，每个文件块给个唯一编号，每块在每组中各存一份，如果某个节点坏了，可以从其它组复制一份到没坏的节点上存放，保证安全。这样就形成了n+1台机器所构成的存储。大家注意，这种方案中三份数据之间其实是相互备份，地位相同，这跟传统的备份不一样，传统的备份仅仅是备份，除非主本坏掉，用来恢复，一般是不会参与应用的。因此上述这种方式在性能上会好很多，特别是读方面，同一份数据有3台计算机可以提供服务。
        要实现上述系统，从原理上来讲非常简单，用到的算法或者技术：B+树（文件索引），网络文件传输，RPC等，都不是很难的，这也是很多个人就可以搞成这样的系统的原因。当然，真正去做的时候，还是要点功夫的，特别是细节上的处理。
        总的来讲，在云存储时代，大而全的存储解决方案已经不再是首选策略，特别是在非结构化或者简单结构化数据应用方面，有针对性的存储解决方案会越来越多。另外上述的存储架构相对比较底层，Google的BigTable,微软的Azure里的大数据表(Table)也差不多基于上述原理来进行。

PS：提高数据的可靠性，最简单饿方法就是冗余存储；上述方式的冗余存储还可以增加读性能（读吞吐量）；提高数据性能的另一种方法就是切割数据，用分布式计算来加快数据处理（这种方式不会增加可靠性），GreenPlum云数据库就是利用这种思想。我觉得大部分的应用（特别是企业应用）还是会基于数据库系统来完成，这样使用简单，延续性强，至于数据库系统本身的存储发展，是不是真正的云无关紧要，但至少会号称云。

虽然这种思想和相关的技术早已存在，云计算也更多的是一种商业应用上的概念，但无论如何，这种可以节省成本，提高资源利用的计算（或者叫应用）模式，会越来越受到欢迎。安全不是问题，信任也不是问题，利润才是首要问题。（安全和信任都是相对的）。

更多信息请查看 java进阶网 http://www.javady.com/index.php/category/thread