Chinaunix首页 | 论坛 | 博客
  • 博客访问: 11698878
  • 博文数量: 8065
  • 博客积分: 10002
  • 博客等级: 中将
  • 技术积分: 96708
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-16 17:06
文章分类

全部博文(8065)

文章存档

2008年(8065)

分类: 服务器与存储

2008-06-23 16:25:03

“分而治之”----中国成语 周末看了一些hpc的资料,有些感想,写出来以便抛砖引玉。 计算机技术已经发展了半个世纪了,短短几十年内,发展了到了现在的程度,并有加速的趋势,让人一时无法相信。早期的计算机,个把CPU,几MB内存,半拉软盘,内存总线,IO总线,接个ASCII字符显示器,完事了,没有什么之说。想运行什么程序,插入存有程序的软盘,上电,运行程序,完毕,结束,下电。记得我小学三、四年级的时候,学校里还有几十台Apple机,那时候不到10岁,也就在91年左右吧,竟然在老师的教导下,用似乎是logo语言(一个绿色乌龟)在屏幕上画图,现在想想真是不可思议。估计当时的计算机老师现在也该是顶级高手了(现在我却只能看printf(hello world),其他代码一概看不懂,惭愧惭愧)。那时候的Apple机,不知道是什么架构,记得似乎有软驱,忘了怎么开机了。顺序似乎是先显示器,后主机,启动的时候显示什么也忘了。初期,硬件方面,除了CPU、“二乔”之外,没有任何其他控制器芯片存在于主板上,也没有文件系统。想把程序运行数据保存在软盘或者磁盘上,只能靠你自己写程序操作磁盘,也没有所谓文件的概念。 幸好没留级,上了中学。学校退休老师响应了国家号召,下海,开了电脑班赚外快。我参加了,机器用的是486的。这个时期,硬件方面有了专门的显示适配器(sis系列的),有了IO控制器。以前这两者的功能统统由CPU来实现。软件方面,盖茨团伙已经开发出了DOS操作系统,以及美国的大学开发的Unix系列。应用程序再也不用从头写到尾了,操作系统的文件系统已经给你预备好了接口,你只要告诉OS创建、读、写文件就可以了。在屏幕上输出再也不用一句一句写代码了,一个printf()就行了(看来我TMD还真就只会这一句了),printf会调用显示适配器驱动程序提供的API,在屏幕上显示图象和字符。 好不轻易熬到了高中。这个时候,大奔出来了,多媒体计算机出来了,声卡也有了。当然那时候还基本靠cpu来运算发声(软声卡),不像现在的。网卡也有了。磁盘控制器也加入了RAID功能。 说了一大堆废话,快迷糊了……越说越后悔当初没好好学习……。 进入正题,我想说的是:“分而治之”中的“分”字。显示输出,音频输入输出,以太网编码解码器,磁盘IO控制器,这些就像CPU的手臂一样,属于“分”的概念,甚至现在还在不停的分。比如ToE,把TCP/IP协议处理从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不是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内核。
再来看一下LB集群,将用户的请求,按照一定策略轮询重定向到后端的多台服务器上,实现负载均衡,这也是分的思想。软件比如Linux下的LVS,硬件产品比如F5,radware,甚至普通的Cisco路由器也可以通过NAT来完成简单的轮询。 是什么促使了分而治之?就是一个速度,一个价格,众人拾柴火焰高。 Google利用1万多台PC组成了廉价的分布式集群,是这个思想最成功的典范!理论每秒浮点运算数达到100T! 分而治之,任重而道远。

阅读(1932) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~