废话不多说，贴个命令以及回显。这种架构很不错！！应该找个机会在生产环境中跑跑。。。
fb00# ndb_mgm -e SHOW
Connected to Management Server at: 172.20.6.200:1186
Cluster Configuration
———————
[ndbd(NDB)] 2 node(s)
id=2 @172.20.6.201 (Version: 5.4.3, Nodegroup: 0, Master)
id=3 @172.20.6.202 (Version: 5.4.3, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @172.20.6.200 (Version: 5.4.3)
[mysqld(API)] 2 node(s)
id=4 @172.20.6.203 (Version: 5.4.3)
id=5 @172.20.6.204 (Version: 5.4.3)
原始数据共210GB，数据类型各种都有。
root@# df -hl /data/e /backup/
Filesystem Size Used Avail Use% Mounted on
data/e 1.8T 132G 1.7T 8% /data/e
rpool/backup 1.8T 86G 1.7T 5% /backup
数据大小都是一样的，data/e用lzjb压缩，rpool/backup用了gzip-9压缩。
由此可以看出，如果对一些一次写入，然后访问不频繁的数据，采用gzip-9更能节约硬盘空间。
非常适合备份数据，在目前一块SATA硬盘2TB的背景下，ZFS+Amanda或Bacula，磁带机是不是可以退休了？
1，GRUB引导的分区最大不能超过2TB。
是设计本身的限制，暂时还没办法。比较郁闷，恰好我的根分区超过了2TB。
2，queue minfree limit is now 1.5 * message size limit.
在设置message_size_limit的时候，不要盲目的设置过大，否则在磁盘剩余空间(这儿特指邮件队列所在的分区)小于1.5*message_size_limit的时候，日志会报错。
在使用Ganglia的过程中，发现偶尔会发生如下错误，大约每天几次，无规律可循。
Nov 13 10:01:48 labmonitor /usr/local/ganglia/sbin/
if tail -1 /var/log/messages | grep ‘not well-formed’ ; then
/sbin/service gmetad restart
echo `date ` gmetad restart >> /var/log/messages
fi
一个同事发的邮件，哈哈！！木想到我们SA也有节日啦。。。
—————————————————————-
如果您能看到这个帖子，请感谢这一群人……
每个成功的男人，背后都有一名默默支持的女人；
每个成功的企业，内部都有一群默默奉献的团队，
他们就是 – System Administrator – IT 系统管理员。
是他们 —— 安装路由器，配置交换机，建立防火墙，保证线路畅通，维护网络安全，才使我们的信息得以传播；
是他们 —— 安装操作系统，检修电脑硬件，搭建基础架构，提供咨询帮助，确保同仁的工作得以顺利开展；
是他们 —— 无时无刻不在担心病毒，蠕虫，木马，流氓软件，机房停电，火灾，雷害甚至恐怖分子来袭；
是他们 —— 半夜两点得到停电，服务器宕机，网络中断的警报，起床赶到机房；
是他们 —— 维护企业网络，制定系统策略，让员工工作效率高一点，为企业发展保驾护航；
是他们 —— 守护着信息和数据的核心阵地——机房，守护着我们每天的工作成果；
他们 —— 还有许多的别称：工程师，救火队员，电脑医生，黑(骇)客，服务员，民工…..
7月25日是全世界系统管理员的节日。从2000年起，世界上有20多个国家每年都庆祝这个节日。
系 统管理员日，由泰德.卡卡托斯 (Ted Kekatos) 在 2000 年发起，泰德是美国芝加哥的一名IT系统管理员，一名不善言辞，默默付出，却总是被遗忘在网络线堆的那种好人，9年前的一个下午，当他查阅HP杂志上的技 术文件时，一则全班广告吸引了他的目光，广告中，同事们排成一条长龙，轮献鲜花。感谢这位IT人为办公室采购并安装全新的激光打印机，不知为何，泰德心跳 加速，眼眶返红…. 于是，在他的努力下，于2000年7月28日发起了系列纪念活动，从而世界各地的支持者确定每年7月份的最后一个星期五为系统管理员的感恩日。
在每年七月的最后一个星期五，泰德和系统管理员们衷心期待您能到IT部门走一遭，到上次帮您修好电脑的那位老哥座位上，和他亲口说声谢谢（也许他会 很害羞的继续帮忙）；泰德希望您能写信告诉全公司这个特别的日子：这天，我们保证会乖乖使用电脑和网络，让辛苦的IT同仁们放今年第一天假！……
作 为一名普普通通的企业系统&网络管理员，总是习惯于在幕后默默无闻的工作，“没有新闻是最好的新闻”是我们的信条，系统和网络每天都能正常的运行 是我们奋斗的目标，而一旦出了任何故障和问题，我们却又不得不马上站出来，承担责任，并寻求最快最好的解决方案，因为时间不等人，系统和网络的任何中断都 会造成企业的巨大损失！所以，功劳，我们常常在平静的日子里流失；责任，却总是要在危急的时间里背负！
我们不需要鲜花和奖励，只需要各位用户发自内心的支持和少许感谢之意！
当你们的工作顺利完成，当你们在网上尽情冲浪的时候，能想起我们的付出，心愿足矣！谢谢！
在使用ZFS（OpenSolaris200811）的过程中碰到了一个问题，当在DELL2850+220S（8块做raidz）和DELL2850+本地硬盘（5块做raidz）的时候，性能非常差，我拷贝rhel5.3的ISO文件，大概需要10分钟左右才能拷贝完成。这明显是不正常的，跟磕死老大沟通了一下，基本断定是raid卡的驱动不行导致的，raid卡型号是perc 4e，但是仍然不知道根本原因。
基于我目前的几台NFS服务器，做了一些拷贝测试，如下：
RHEL 4.7（DELL2850）
# time cp rhel-server-5.3-x86_64-dvd.iso /export/scratch_qa/test/
real 1m12.942s
user 0m0.212s
sys 0m16.519s
OpenSolaris 200811(DELL 2950)
# time cp rhel-server-5.3-x86_64-dvd.iso /data/export/test/
real 0m44.246s
user 0m0.067s
sys 0m13.097s
Solaris10 update 6(DELL 2850)
# time cp rhel-server-5.3-x86_64-dvd.iso /data/
real 1m43.993s
user 0m0.007s
sys 0m16.932s
虽然不全面，但是基本上也可以看出ZFS的性能并没有大家想像中的那么差，当然OpenSolaris虽然性能好，但是可能是因为硬件好的缘故，不过在旧硬件上，也不应该表现那么差啊，10分钟才拷贝完！！:|
试用了Panabit和Ascenflow，感觉如下：
0，名字
个人感觉喜欢Panabit这个名字，Ascenflow的话多少有点俗！
1，硬件bypass
Ascenflow默认硬件支持，偏好些！而Panabit需要通过工控机实现，不过我不知道能不能买到插服务器上的支持bypass的网卡。
2，协议分析
个人感觉Panabit更适合中国用户，对国内的一些流行的协议分析更细。而Ascenflow这点不如Panabit！
3，界面易用性
用起来，Ascenflow更简单、UI很好，但是Panabit更灵活，组合搭配很牛。Ascenflow支持中文繁简体、英文界面选择，Panabit仅支持中文！
4，解决方案
Ascenflow有一个统一的解决方案，软硬件一起提供，很不错！而Panabit只是提供软件，除非找代理商，而找代理商又不是Panabit公司直接支持，略显山寨一些。
5，稳定性&安全性
Ascenflow厂商说基于Linux，安全性应该还行，稳定性的话，我测试Ascenflow1000死机几天了，我还不知道，幸亏有bypass，唉！！Panabit的话，安全性基于你对FreeBSD的了解程度了，在我这儿的话，肯定是比Linux安全了，如果只跑Panabit并且管理IP用内网的话，安全性不是问题，稳定性要看你用的服务器的品质了，如果用个HP360/DELL1950，估计连续跑个1年2年的也没问题，但是半路死了没有bypass，所以感觉上还是不太爽的！
6，价格
Ascenflow较贵，对外报价吓死人，动不动就几十万，我觉得这玩意也就值个二、三万吧（算上人力成本）！Panabit有个标准版，是免费提供的，很不错！商业版的话，价格也不算太贵。
7，技术支持
Ascenflow有完善的技术支持，而用Panabit标准版的话，只能靠BBS和QQ群支持！
在对大量小文件在两台机器之间同步的时候，碰到的一些问题，并且一直没找到最理想的办法。
0，SCP
不敢用，因为存在循环链接的bug，会直到循环着把分区塞满为止，官方也有人报，但是一直没fix，况且还没法进行增量同步。
1，nfs&cp,tar
通过nfs挂过来，然后cp或tar，如果是一次性拷贝时，比较合适，但是如果量大想提前复制一份过来，之后就没法进行增量同步了。
2，rsync
比较常用这个，但是也有问题。
a）rsync在3.0之前的版本都要先接收文件列表，这个过程很慢，如果再出点啥意外，不好意思，请从头再来。不过在3.0之后的版本，改进了这个情况，只接收增量文件列表了。
b）在对长目录名进行同步的时候，会报IO错误并退出，当我启动同步进程之后，去睡觉了，本来以为第二天就完了，结果同步了几个G的数据后，碰到了超长目录名，真是一个郁闷啊！所作的只能是先把这个超长目录删除了，然后再次启动同步！
c）当使用单进程来同步的话，速度很慢，所以必须启动多进程来拷贝，效率成倍提高。看看我的进程数，网卡、IO都快吃满了，很爽！
root@:/var/log/rsync# ps -ef |grep rsync |wc
66 913 8577
不知道各位老大都是如何解决这个问题的？谁有更好的办法，告知一下啊！
当ZFS启用了压缩之后，文件的真实大小(ls看到的)和你用df/du看到的大小已经不一样，因此写了这个sh来统计目录下的文件的真实大小，即ls列出来的大小，在此保存一下。
http://www.chifeng.name/dist/scripts/fsize
缺点：不支持大量文件。
很快会再写一个Perl版本的或者Python版本的fsize，就解决这个问题了，shell版本的不知道如何修复这个问题。
© 2010 Chifeng’s Blog · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
