摘要：本文首先就”弹性云”的存储需求进行分析，尝试的归纳出弹性云应用环境对存储的普遍需求；接下来针对这些具体需求，一一检验了当前林林总总、颇为流行的典型网络存储系统（如dynamo,GFS,HadoopFs等）的功能特性，分析其得失；再最后抛砖引玉——提出一种自认为比较理想的网络存储架构。为了避免空洞的说理。在本文后期，我“试想”在基于XEN虚拟机的弹性云环境中到底如何实施这一理想化的存储系统。概念问题（如hosting，弹性云等），不再啰嗦。我们直接切入正题！一.用于HOSTING目的的弹性云需要什么样的存储系统呢？弹性云环境所托管的虚拟机基本需求大致如下：Ø虚拟机系统故障停机时间尽可能短（甚至号称永不停机！不过一般一年内因不可抗拒的因素，停止10分钟还是能被大度的客户接受的）这首先要求虚拟机的运行数据（包括操作系统和用户数据）非本地存储，而是需要存储于后端的可靠的存储系统中。因为虚拟机的宿主机发生故障（比如断电或者硬件永久故障）在所难免，如果故障时虚拟机的磁盘数据本地存储，长时间的故障停机时间就将不可避免的——甚至人品不好时，碰到本地硬盘物理损坏，则要造成虚拟机系统永久不可恢复。鉴于上述原因，hosting环境的存储需要放在远端的可靠存储系统，且应该写透到远端存储（切记！不要使用本地cache等，否则故障时要丢失数据的！），这样只要后端存储系统正常则虚拟机便可旋即进行”failover”——再其它可用宿主机上重新启动.这样一来停机时间可降低到1分钟内Ø虚拟机系统高用性高可用意味着——Hosting的虚拟机需要”alwaysonline”，那么显而易见对后台存储也应是alwaysonline吧！对于这点我个人认为倒不尽然！远端存储的可用性可略低于虚拟机的可用性。为什么这么说呢？因为虚拟机的I/O请求其实可可以短暂挂起的——I/O挂起时计算型任务还是可以正常运行的，而I/O相关的任务可以临时处于"D"状态,默默地等待I/O请求应完成。当后台存储系统恢复后，则可继续正常工作。这种容错性给了后端存储系统设计留下了不少余地。存储系统可以在扩容、failover、snapshot等非常时期，短暂的停止或者降低服务能力。但是毋庸置疑的是——虚拟机的高可用性必然要求一个高可用的后台存储。如果后台存储不稳定、效率低下、故障频繁则必然破坏到虚拟机的正常运行。Ø弹性云资源利用最大化1.是智能调度。为了能将所有宿主机的资源整合成一个资源池，供虚拟机最大限度使用。弹性云系统需要根据虚拟机的资源使用情况，在各个宿主机之间调度虚拟机——这就是传说中的热迁移（livemigration）。热迁移实现最重要的就是数据远程存储，同时要保证迁移时虚拟机的所有ondisk数据都被刷新到了远端存储中，也就是要求”写透”——至少在迁移时刻。2.资源利用最大化的第二要求就是存储高性能（高吞吐，低响应）。因为每个宿主机将启动多个虚拟机，每个虚拟机的一般而言需要保证2-4BM/s的I/O带宽（对多数用户足够啦）。如果后台的存储性能跟不上，则必然成为虚拟机运行数量的瓶颈。3.资源利用最大化的第三要求是存储系统支持足够大的规模，且能自动扩容/缩容——规模足够大才可消峰填谷式的资源调度——这点几乎适用于所有的云集群系统；扩容和缩容是指可按需向集群补充机器，空闲时抽出空余机器。为了保证虚拟机的高可用性，存储系统的扩容和缩绒都必须是在线、不中断服务的情况下完成的。而且进行时尽可能不引起性能访问性能下降。也要能保证数据和并发压力平衡，不引起明显抖动。Ø数据需要保证一致性。VM镜像存储的数据一致性行低于并行文件系统（如REDHAT的GlobalFileSystem），但高于（如AMAZON的DynamoKV)的数据一致性要求。它要求的是client-orientedconsistent，既面向VM自己看到的数据“实时”一致（readfellowwrite,writefellowwrite等）,而并行文件系统则要求多个客户端看到一致的数据；最终一致性系统则不能保证时刻满足readfellowwrite等要求。Ø廉价、低成本低成本对于后台存储系统而言，具体要求可体现在两个方面。1是硬件价格低廉；2是最好资源能复用。所谓价格低廉不用说就是和传统存储SAN/NAS等相比要更便宜（SAN这东西我确实不熟悉，但听说那是相当的贵呀！）；所谓资源能复用最好的理解是这些硬件除了给虚拟机做后台存储，最好还能在适当的时候用于别用。综合上述两个要求，目前比较流行的存储方案是采用”云存储”思路：使用PC服务器搭建集群存储系统。这样不但便宜，而且其计算资源等也被复用。总之都用通用机器、sata硬盘、普通网卡搭建廉价的存储系统是最低成本的。当然代价就是需要严密设计的软件系统