Archive for the ‘SystemMaintenance’ category

7月25日–全世界系统管理员节日

April 2nd, 2009

一个同事发的邮件,哈哈!!木想到我们SA也有节日啦。。。

—————————————————————-

如果您能看到这个帖子,请感谢这一群人……

每个成功的男人,背后都有一名默默支持的女人;
每个成功的企业,内部都有一群默默奉献的团队,
他们就是 – System Administrator – IT 系统管理员
是他们 —— 安装路由器,配置交换机,建立防火墙,保证线路畅通,维护网络安全,才使我们的信息得以传播;
是他们 —— 安装操作系统,检修电脑硬件,搭建基础架构,提供咨询帮助,确保同仁的工作得以顺利开展;
是他们 —— 无时无刻不在担心病毒,蠕虫,木马,流氓软件,机房停电,火灾,雷害甚至恐怖分子来袭;
是他们 —— 半夜两点得到停电,服务器宕机,网络中断的警报,起床赶到机房;
是他们 —— 维护企业网络,制定系统策略,让员工工作效率高一点,为企业发展保驾护航;
是他们 —— 守护着信息和数据的核心阵地——机房,守护着我们每天的工作成果;
他们 —— 还有许多的别称:工程师,救火队员,电脑医生,黑(骇)客,服务员,民工…..
7月25日是全世界系统管理员的节日。从2000年起,世界上有20多个国家每年都庆祝这个节日。
系 统管理员日,由泰德.卡卡托斯 (Ted Kekatos) 在 2000 年发起,泰德是美国芝加哥的一名IT系统管理员,一名不善言辞,默默付出,却总是被遗忘在网络线堆的那种好人,9年前的一个下午,当他查阅HP杂志上的技 术文件时,一则全班广告吸引了他的目光,广告中,同事们排成一条长龙,轮献鲜花。感谢这位IT人为办公室采购并安装全新的激光打印机,不知为何,泰德心跳 加速,眼眶返红…. 于是,在他的努力下,于2000年7月28日发起了系列纪念活动,从而世界各地的支持者确定每年7月份的最后一个星期五为系统管理员的感恩日。

在每年七月的最后一个星期五,泰德和系统管理员们衷心期待您能到IT部门走一遭,到上次帮您修好电脑的那位老哥座位上,和他亲口说声谢谢(也许他会 很害羞的继续帮忙);泰德希望您能写信告诉全公司这个特别的日子:这天,我们保证会乖乖使用电脑和网络,让辛苦的IT同仁们放今年第一天假!……
作 为一名普普通通的企业系统&网络管理员,总是习惯于在幕后默默无闻的工作,“没有新闻是最好的新闻”是我们的信条,系统和网络每天都能正常的运行 是我们奋斗的目标,而一旦出了任何故障和问题,我们却又不得不马上站出来,承担责任,并寻求最快最好的解决方案,因为时间不等人,系统和网络的任何中断都 会造成企业的巨大损失!所以,功劳,我们常常在平静的日子里流失;责任,却总是要在危急的时间里背负!
我们不需要鲜花和奖励,只需要各位用户发自内心的支持和少许感谢之意!
当你们的工作顺利完成,当你们在网上尽情冲浪的时候,能想起我们的付出,心愿足矣!谢谢!

ZFS性能

February 4th, 2009

在使用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 VS Ascenflow

January 16th, 2009

试用了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群支持!

大量小文件同步时碰到的问题

January 10th, 2009

在对大量小文件在两台机器之间同步的时候,碰到的一些问题,并且一直没找到最理想的办法。

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

不知道各位老大都是如何解决这个问题的?谁有更好的办法,告知一下啊!

fsize

December 29th, 2008

当ZFS启用了压缩之后,文件的真实大小(ls看到的)和你用df/du看到的大小已经不一样,因此写了这个sh来统计目录下的文件的真实大小,即ls列出来的大小,在此保存一下。

http://www.chifeng.name/dist/scripts/fsize

缺点:不支持大量文件。

很快会再写一个Perl版本的或者Python版本的fsize,就解决这个问题了,shell版本的不知道如何修复这个问题。

ipv6 – 0

September 11th, 2008

IPV6

试验了几个ipv6相关的命令。
ping6 -I eth0 fe80::21d:9ff:fe20:b78e
/sbin/ip -6 route show dev eth0
route -A inet6  

关于ipv6的IP规范说明

Grid Computing 1 -LSF

September 2nd, 2008

增加一个节点

编辑…./lsf/conf/lsf.cluster.clustername文件,在Host部分增加一行,类似如下,直接复制之前的行也可以

Begin   Host
HOSTNAME  model    type        server r1m  mem  swp  RESOURCES    #Keywords
hostname      !       !       1       3.5 ()   ()   ()
End     Host

确认可以以当前用户rsh到该主机,然后启动对应的daemon。

chifeng# lsadmin reconfig
chifeng# lsadmin limstartup hostname
chifeng# lsadmin resstartup hostname
chifeng# badmin hstartup hostname

节点增加完成

硬盘

March 23rd, 2008

硬盘

在12.13号那天,www.extmail.org这台服务器,硬盘挂了,并且没有被发现,中间重启过几次也没有发现这个问题。今天一块硬盘突然报错,不响应了,数据一下整体恢复到了12.13日,3个多月的数据一下消失了。:( bbc老大急忙杀去IDC,处理半天,不幸中的万幸是这块硬盘在拔了之后,又识别到了,赶紧把数据sync出来。现在已经基本上安全了,bbc的努力没有白费!!

数据安全永远是最重要的!对线上的机器,最好是raid1+定期backup。否则出问题,1)不是每次都能这么幸运;2)到时候哭都哭不出来啊。

Samba的怪问题

January 17th, 2008

Samba

自从昨天下午这台samba机器reboot后,就发生了一个比较怪异的问题。当我在一个nfs目录下软link了另外一个nfs目录下的东西,并通过samba共享出来后,目录可以进入,但目录里面的文件就不能访问了,读写均不可以。尝试了如下测试:
1,软link一个本地目录到这个nfs目录,通过samba访问正常。(这一定跟NFS相关)
2,link另外一台nfs目录到这个nfs目录,通过samba不能访问。(进一步认为是NFS相关)
3,在另外一台linux启动一个samba,同样的情况下测试,通过samba正常访问。(范围缩小为仅这一台机器,并可以认为跟NFS无关)
4,下载了个最新的samba3.0.28,手工编译了一下然后启动,同样情况下测试,通过samba不能访问。(可以认为跟samba程序本身无关)
经过这4步测试后,基本可以认为是Linux系统本身的问题,系统为RHEL4.2。要不重装系统?但是这样的问题重装系统不一定能解决,即便解决了,好不容易才碰到这样的怪问题,重装完好了怎么办。:P 然后就跟SG兄说了个要不咱替换一下kernel试试,问题终于出来了,SG老大回忆起前几天TY老大把kernel替换为了vmlinuz-2.6.9-55.0.9,不过当时为了不影响服务就没有reboot(目的是为了试试新一点的内核是不是更稳定一些),本来RHEL4.2自带的kernel版本应该是vmlinuz-2.6.9-22.EL,于是我改了引导的内核为原来的vmlinuz-2.6.9-22.EL,重新启动后,一切恢复正常。

由此可以看出,在复杂的网络环境下,linux新的kernel不完全兼容旧的kernel。

rpcbind

November 26th, 2007

rpcbind

周末切换了一台文件服务器到FreeBSD。打开服务后,发现rpcbind占用非常多的CPU,非常不明白为什么他一直在哪儿rpcbind。
9110 root 1 103 0 4812K
1336K CPU3 2 800:43 48.34% rpcbind
9201 root 1 -8 0 2512K 920K CPU1 2 399:10
17.97% nfsd
9202 root 1 4 0 2512K 920K CPU2 2 155:34 6.40% nfsd

重启rpcbind,没用,刚起来没1分钟,CPU占用就又上去了。然后tcpdump抓一下udp的包
chifeng# tcpdump -i bce0 udp port 111 > tcpdump.log
然后看看那个机器发的包较多。
chifeng# awk ‘{print $3}’ tcpdump.log | sort | uniq -c | sort -nr | more
找到大概3,4台机器,跟rpcbind进程通讯的量非常大,登录过去看看,看一下状态。
3210 root      15   0     0    0    0 S 11.4  0.0  19:07.30 rpciod 
client这儿有这个进程在不停的跟主机的rpcbind联系。
[root@]# kill -9 3210
[root@]# kill -9 3210
[root@]# kill -9 3210
[root@]# kill -9 3210
死活杀不掉,难道是个僵尸进程。reboot一下之后,client哪儿正常,并且rpciod进程也自动消失,最终再在主机上抓包看,重复这般操作。在对client几度折腾之后,rpcbind占用高的问题解决,看来是客户端的rpciod进程导致的这个问题。