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

周末看了一些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来完成简单的轮询。

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

分而治之，任重而道远。