【IT168 方案】本文首先就 ”弹性云” 的存储需求进行分析，尝试的归纳出弹性云应用环境对存储的普遍需求;接下来针对这些具体需求，一一检验了当前林林总总、颇为流行的典型网络存储系统(如dynamo,GFS,Hadoop Fs等)的功能特性，分析其得失;再最后抛砖引玉——提出一种自认为比较理想的网络存储架构。
为了避免空洞的说理。在本文后期，我“试想”在基于XEN虚拟机的弹性云环境中到底如何实施这一理想化的存储系统。
概念问题(如hosting，弹性云等)，不再啰嗦。我们直接切入正题!
一.用于HOSTING目的的弹性云需要什么样的存储系统呢?
弹性云环境所托管的虚拟机基本需求大致如下：
Ø 虚拟机系统故障停机时间尽可能短(甚至号称永不停机!不过一般一年内因不可抗拒的因素，停止10分钟还是能被大度的客户接受的)
这首先要求虚拟机的运行数据(包括操作系统和用户数据)非本地存储，而是需要存储于后端的可靠的存储系统中。因为虚拟机的宿主机发生故障(比如断电或者硬件永久故障)在所难免，如果故障时虚拟机的磁盘数据本地存储，长时间的故障停机时间就将不可避免的 —— 甚至人品不好时，碰到本地硬盘物理损坏，则要造成虚拟机系统永久不可恢复。
鉴于上述原因，hosting环境的存储需要放在远端的可靠存储系统，且应该写透到远端存储(切记!不要使用本地cache等，否则故障时要丢失数据的!)，这样只要后端存储系统正常则虚拟机便可旋即进行”failover”——再其它可用宿主机上重新启动. 这样一来停机时间可降低到1分钟内。
Ø 虚拟机系统高用性
高可用意味着——Hosting的虚拟机需要 ”always online”，那么显而易见对后台存储也应是always online吧!
对于这点我个人认为倒不尽然!远端存储的可用性可略低于虚拟机的可用性。为什么这么说呢?因为虚拟机的I/O请求其实可可以短暂挂起的 —— I/O挂起时计算型任务还是可以正常运行的，而I/O相关的任务可以临时处于"D"状态 ,默默地等待I/O请求应完成。当后台存储系统恢复后，则可继续正常工作。这种容错性给了后端存储系统设计留下了不少余地。存储系统可以在扩容、failover 、snapshot等非常时期，短暂的停止或者降低服务能力。
但是毋庸置疑的是 —— 虚拟机的高可用性必然要求一个高可用的后台存储。如果后台存储不稳定、效率低下、故障频繁则必然破坏到虚拟机的正常运行。
Ø 弹性云资源利用最大化
1. 资源利用最大化的第一要求是智能调度。为了能将所有宿主机的资源整合成一个资源池，供虚拟机最大限度使用。弹性云系统需要根据虚拟机的资源使用情况，在各个宿主机之间调度虚拟机——这就是传说中的热迁移(live migration)。热迁移实现最重要的就是数据远程存储，同时要保证迁移时虚拟机的所有on disk数据都被刷新到了远端存储中，也就是要求 ”写透”——至少在迁移时刻。
2. 资源利用最大化的第二要求就是存储高性能(高吞吐，低响应)。因为每个宿主机将启动多个虚拟机，每个虚拟机的一般而言需要保证2-4BM/s的I/O带宽(对多数用户足够啦)。如果后台的存储性能跟不上，则必然成为虚拟机运行数量的瓶颈。
3. 资源利用最大化的第三要求是存储系统支持足够大的规模，且能自动扩容/缩容——规模足够大才可消峰填谷式的资源调度——这点几乎适用于所有的云集群系统;扩容和缩容是指可按需向集群补充机器，空闲时抽出空余机器。为了保证虚拟机的高可用性，存储系统的扩容和缩绒都必须是在线、不中断服务的情况下完成的。而且进行时尽可能不引起性能访问性能下降。也要能保证数据和并发压力平衡，不引起明显抖动。
Ø 数据需要保证一致性。
VM镜像存储的数据一致性行低于并行文件系统(如REDHAT 的 Global File System)，但高于最终一致性系统(如AMAZON 的Dynamo KV)的数据一致性要求。它要求的是client - oriented consistent ，既面向VM自己看到的数据“实时”一致(read fellow write, write fellow write 等), 而并行文件系统则要求多个客户端看到一致的数据;最终一致性系统则不能保证时刻满足read fellow write等要求。
Ø 廉价、低成本
低成本对于后台存储系统而言，具体要求可体现在两个方面。1 是硬件价格低廉;2是最好资源能复用。
所谓价格低廉不用说就是和传统存储SAN/NAS等相比要更便宜(SAN这东西我确实不熟悉，但听说那是相当的贵呀!);所谓资源能复用最好的理解是这些硬件除了给虚拟机做后台存储，最好还能在适当的时候用于别用。综合上述两个要求，目前比较流行的存储方案是采用”云存储”思路：使用PC 服务器搭建集群存储系统。这样不但便宜，而且其计算资源等也被复用。总之都用通用机器、sata硬盘、普通网卡搭建廉价的存储系统是最低成本的。当然代价就是需要严密设计的软件系统来保证系统的健壮性—— 数据怕丢，就需要采用多副本冗余存储;机器怕坏，就需要能自动、快速failover . 总之你需要一套坚强的存储软件系统做支持。
Ø 高速的中小I/O请求处理
Hosting目的的虚拟机的I/O请求有自己的特点。应用统计出的规律大约是： 1读操作多余写操作(相差往往10倍);2 请求以小块数据为主(多数在50-100个扇区左右)。因此后台存储系统最好能是“读优先”，且对“小块数据优先”。
读优先问题不谈了(好的定位索引、大的cache 和多副本均衡读等通用技术就差不多了)，就说小数据访问性能问题，就够让很多存储系统头疼的。尤其是对于廉价PC服务器组成的存储网，其使用普通千兆网卡——网络包的相应速度可不敢和光纤相比呀。这时小包传送来回的网络延迟时间可不容忽视。因此最好存储系统能提供“异步请求接口”。以便客户端能非堵塞的异步发送请求，这样才不至于让VM的I/O堵塞，响应速度更高;并且如果结合广播方式异步传输请求，则理论传输速度可线性scale到很大(想想P2P软件)。
当然除了上述要求外，差点忘了基本要求是能随机修改——准确说是以扇区大小为单位变长的随机读写。
注：1 这里的一般hosting应用，不包括那些爬虫、日志分析等”惹事生非”的肇事者，这些应用应该规劝其使用hadoop等类似的分布文件系统。2 读写比例和I/O请求大小可观察cat /sys/block/
分析了这么一通，可以概括一下弹性云中Hosting服务需要的后台存储特点了：
n 后台非本地的网络存储系统
n 高可用性,几乎always online !
n 支持足够大的规模，且能在线扩容，负载均衡。
n 面向client的实时数据一致性
n 客户端不能缓存数据
n 廉价，最好使用通用pc服务器(当然对于EMC、华为、IBM本身就做存储、做网络的企业;或者电信、银行这种有钱的主，当然采用可专用存储设备啦!)
n 高吞吐、低响应。
n 读优先，支持异步访问，支持以扇区大小为单位变长的随机读写。
