分而治之－当今存储集群的发展趋势

分而治之－－－－中国成语

周末看了一些hpc的资料，有些感想，写出来以便抛砖引玉。

计算机技术已经发展了半个世纪了，短短几十年内，发展了到了如今的程度，并有加速的趋势，让人一时没法相信。早期的计算机，个把cpu，几M内存，半落软盘，内存总线，io总线，接个ascII字符显示器，完事了，没有什么操做系统之说。想运行什么程序，插入存有程序的软盘，上电，运行程序，完毕，结束，下电。记得我小学34年纪的时候，学校里还有几十台apple机，那时候不到10岁，也就91年左右吧，居然在老师的教导下，用好像是logo语言（一个绿色乌龟）在屏幕上画图，如今想一想真是难以想象。估计当时的计算机老师如今也该是顶极高手了。（如今我却只能看printf（hello world），其余代码一律看不懂，惭愧惭愧）那时候的apple机，不知道是什么架构，记得好像有软驱，忘了怎么开机了，好像是先显示器，后主机，启动的时候显示什么也忘了。初期，硬件方面，除了cpu、“二乔”以外，没有任何其余控制器芯片存在于主板上，也没有文件系统，想把程序运行数据保存在软盘或者磁盘上，只能靠你本身写程序操做磁盘，也没有所谓文件的概念。

幸亏没留级，上了中学，学校退休老师响应了国家号召，下海，开了电脑班赚外块，我参加了，机器用的是486的。这个时期，硬件方面，有了专门的显示适配器（sis系列的），有了io控制器，之前这二者的功能通通由cpu来实现。软件方面，盖茨团伙已经开发出了dos操做系统，以及美国的大学开发的unix系列。应用程序不再用从头写到尾了，操做系统的文件系统已经给你准备好了接口，你只要告诉os建立，读，写文件就能够了。在屏幕上输出不再用一句一句写代码了，一个printf（）就好了（看来我tm还真就只会这一句了），printf会调用显示适配器驱动程序提供的api，在屏幕上显示图象和字符。

好不容易熬到了高中。这个时候，大奔出来了，多媒体计算机出来了，声卡也有了，固然那时候还基本靠cpu来运算发声（软声卡），不像如今的。网卡也有了。磁盘控制器也加入了raid功能。

说了一大堆废话，快迷糊了。。。越说越后悔当初没好好学习。。。。。

进入正题，我想说的是：分而治之中的“分”字。显示输出，音频输入输出，以太网编码×××，磁盘io控制器，这些就像cpu的手臂同样，属于“分”的概念，甚至如今还在不停的分，好比ToE，把tcpip协议处理从cpu转移到独立的芯片上，又好比大型机的前置处理机，好比dcp，3270等，这些“分而治之”的思想，体现了什么？ 是分布式！ san的出现，把磁盘子系统彻底从主机独立还来，分而治之！ NAS的出现，把文件系统从主机分出了一部分，由单独的nas来处理，而后呈现给os，这也体现了一个“分”字。OSI分了7层，也体现了一个分！raid技术将数据分块存放在多块磁盘上，正是“分而治之“思想的完美体现。

再来看hpc中的内容，这里面的“分”的思想就数不胜数了。好比，传统smp架构，存在总线共享的问题，好，那就分，用crossbar也好，infiniband也好，sci也好，都成了交换架构，解决cache一致性问题，不再用总线广播了，只需向曾经读取过对应cache块的节点处理机发送失效信号即可，而这是共享总线作做不到的。软件方面，因为在集群系统中，使用廉价的pc server作节点，在没有san后端存储的状况下，基于本地磁盘的io吞吐量瓶颈很大，远达不到科学计算的要求，怎么办呢？分吧！把数据分别存放在各个节点，把各个节点的direct attached的磁盘存储资源，整合成一个大的共享存储资源，这样齐心协力，提升io吞吐量，这就是分布式文件系统的效能，固然做用还不止这些，不如这些fs通常都支持多节点能够读写同一个文件，利用加锁机制。经过集群网络通讯，保持数据的一致性。在用san作后端存储的条件下，吞吐量问题是缓解了，可是文件共享问题仍是没有解决，虽然能够用nfs之类的nas解决，可是nas须要在san前端加nas头，这个是很大的瓶颈所在。因此出现了专门针对san的集群文件系统，用来解决共享问题，好比sanery以及其升级版合标准化版sanfs，以及国内的BWFS等。这些sanfs，即保证了各个主机对san有直接访问权，消除了nas头形成的瓶颈，又保证了不会形成冲突（用metadata server控制）。

针对分布式并行处理集群，开发了通用api，好比MPI等等，让程序能够充分利用分布式资源。

一篇清华大学的硕士论文，论述了一种利用独立日志磁盘来同步磁盘数据的技术。日志是用来保证文件系统一致性的广泛利用的技术，好比数据库这种必须保证数据一致性的环境，其原理就是io操做数据先写入日志，当日志写完后即告成功，而后再从日志中将数据异步的后台转移到数据区磁盘空间，换句话说，日志提供了了一个磁盘io缓冲区，这个缓冲区虽然提升不了io性能（由于是磁盘io不是ramio），可是他极大的保证了数据一致性，相比用没有掉电保护的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来完成简单的轮询。

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

分而治之，任重而道远。