论当今存储集群的发展趋势

核心提示： 针对分布式并行处理集群，开发了通用API，论当今存储集群的发展趋势(3)，比如MPI等等，让程序可以充分利用分布式资源， Google利用1万多台PC组成了廉价的分布式集群，是这个思想最成功的典范！理论每秒浮点运算数达到100T！ 分而治之， 一篇清华大学的硕士论文，论述了一种利用独立日志

针对分布式并行处理集群，开发了通用API，比如MPI等等，让程序可以充分利用分布式资源。

一篇清华大学的硕士论文，论述了一种利用独立日志磁盘来同步磁盘数据的技术。日志是用来保证文件系统一致性的普遍利用的技术，比如数据库这种必须保证数据一致性的环境，其原理就是IO操作数据先写入日志，当日志写完后即告成功，然后再从日志中将数据异步的后台转移到数据区磁盘空间，换句话说，日志提供了了一个磁盘IO缓冲区，这个缓冲区虽然提高不了IO性能（因为是磁盘IO不是RAM IO），但是他极大的保证了数据一致性，相比用没有掉电保护的RAM来做缓冲区的做法，这种方式廉价，但性能很低。 有了日志缓冲区，即便突然掉电，日志仍然保存在磁盘上，可以下次上电的时候从日志将数据恢复到数据区。但是保障了可靠性，就要牺牲性能，由于日志写到此盘上，造成了IO的瓶颈，虽然前端数据库实例可以并发，但是写日志，仍然是串行写入，而且还必须面对磁盘的IO瓶颈。要提高性能，就要提高成本，比如，不用磁盘来保存日志数据，用NVRAM，这样成本太高。比如NetApp的NAS系统中用的RAID4，虽然存在校验盘过热现象，但是通过增加NVRAM（也可以通过增加Cache，但是Cache贵，没有掉电保护），成功了解决了RAID4校验盘过热的情况。 同样清华的这个fastsync日志记录系统，其基本原理是这样的：即利用单独的日志记录盘，而不是集成在数据区RAID group中分出的lun来记录日志，为什么这么做呢？因为他用了一种特殊的算法，即每个磁道只记录一条到3条日志，而且，通过预测磁头所处的位置的算法，在当前磁头所处的磁道处，不用寻道，就在当前位置进行写操作，当前磁道写一条或者3条日志，然后切换到下一磁道，继续写，而他参考的前人一篇论文，那篇论文是每个磁道只写一个日志，然后换道，这种一对一的方法，对小的IO比较有效，但是对大量快速到来的IO，换道将是一个耗时的操作，所以fastsync做了一些改进，即通过实验，发现每磁道写3条日志，比较适合快速的，大块的IO环境，所以fastsync可以根据IO速度和大小来自动调整写磁道策略。通过实验，发现这种架构比传统方式快了5倍。 这种做法看似比较不错，不知道有没有实际应用过，而且，对于现在的盘阵系统，如果追求高性能，可以把Cache设置为write back，这样同样保证了高IO速率，而且Cache也有电池保护，所以fastsync要想打赢，还有很多工作要做，不过对于追求性价比的用户，fastsync不妨是个选择。因为fastsync实现机制涉及到了底层的改变，而且Linux没有提供相应的接口来获取磁头当前位置的信息，所以需要重新编译Linux内核。

再来看一下LB集群，将用户的请求，按照一定策略轮询重定向到后端的多台服务器上，实现负载均衡，这也是分的思想。软件比如Linux下的LVS，硬件产品比如F5，radware，甚至普通的Cisco路由器也可以通过NAT来完成简单的轮询。

是什么促使了分而治之？就是一个速度，一个价格，众人拾柴火焰高。

Google利用1万多台PC组成了廉价的分布式集群，是这个思想最成功的典范！理论每秒浮点运算数达到100T！

分而治之，任重而道远。