You are currently browsing the monthly archive for December 2009.
摆弄qmail，那是好多年以前的事情
很早以前搭的一套系统，最近垃圾邮件问题严重
第一次去看，已经在前段部署了一个邮件防火墙，没看出个所以然
以为是默认退信机制导致的长队列
改了改配置，就让把防火墙去了
今天又被叫去，防火墙一去，邮件服务器就挂了
简单的排查了下
smtp认证的正常的，open relay是关闭的
怀疑qmail的安全性是不现实的，那么还剩的可能性就是帐号被垃圾邮件商盗用
排查具体被盗的帐号很繁杂
可以通过日志，邮件原文，找到攻击的ip地址
通过ip地址找被盗帐号，不容易
一般来说，垃圾邮件服务器的连接地址有很多
每当其中一个成功发送邮件后，会更新被盗帐号的lastauth文件
对于用户不太多的MTA，可以比对更新最频繁的lastauth
否则的话，就要收集所有的lastauth，再跟所有的垃圾邮件服务器ip比对
太久没写脚本，所以过程很山寨，就不写了
不过这台mta已经发了近一天的垃圾邮件，被很多mta ban了。。。
所以，对邮件服务器状态的监控也挺重要，简单的监控每天发送邮件的数量
就能很好的发现问题
<cluster name="example" config_version="1"> <cman two_node="1" expected_votes="1"> </cman> <clusternodes> <clusternode name="one" votes="1"> <fence> <method name="single"> <device name="human" ipaddr="192.168.2.1"/> </method> </fence> </clusternode> <clusternode name="two" votes="1"> <fence> <method name="single"> <device name="human" ipaddr="192.168.2.2"/> </method> </fence> </clusternode> </clusternodes> <fencedevices> <fencedevice name="human" agent="fence_manual"/> </fencedevices> </cluster>
<cluster name="example" config_version="1">
<clusternodes>
<clusternode name="one" votes="1">
<fence>
<method name="single">
<device name="human" ipaddr="192.168.2.1"/>
</method>
</fence>
</clusternode>
<clusternode name="two" votes="1">
<fence>
<method name="single">
<device name="human" ipaddr="192.168.2.2"/>
</method>
</fence>
</clusternode>
<clusternode name="three" votes="1">
<fence>
<method name="single">
<device name="human" ipaddr="192.168.2.3"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice name="human" agent="fence_manual"/>
</fencedevices>
</cluster>
使用vray的ditributed rendering
之前用qube进行任务分配的时候，只要将源文件放在公共存储(CIFS)上，所有机器以相同路径访问即可
vray这样做不行
简单的试验了下，设置每台节点的working dir为公共存储上的统一文件夹
然后把所有材质都丢到那个目录去，就不会有材质丢失的问题了
说到这，渲染集群如果使用到公共存储，那么公共存储的IO压力是很大的
磁盘上有，网络上也有
而且这种共享，是基于文件的，SAN也不能直接解决问题
CIFS或者nfs或者openais的backend是必须的
如果相对于渲染时间，网络传输的时间及时长但也可以忽略不计，那无所谓
如果真有需求
廉价的
普通的服务器陪RAID0并做好备份，多插几块网卡，一块卡上有两个节点读数据
有钱的
上IB，存储还是RAID0，如果DAC不行，就SAN
很多问题，相当无语。
ubuntu 确实是套相对激进的发行版，上手急了点，装了几个9.10
vmware server 2.02是跑的半死不活，web access说崩溃就崩溃，动不动就提示reinstall plz
vm也挂过几次，这个虚拟平台还是要趁早换了
这几天再缓慢的换成debian5
有FC的刀片是都能看到存储了，问题又来了
IBM ds3400提供双控制器冗余，但是其冗余的RDAC补丁，仅提供RH和SUSE的版本
还没想好咋整，我是真不想用商业的linux
其他发行版凑合能用，没有冗余功能，看到的第二个LUN设备也是无法访问的
也不知道自带的multipath能不能搞一搞
最后，clvm,传说中的clustered lvm
我计划拿来在五台机器上管理阵列的玩意儿
clvm本身没什么需要配置的，但它有个前提组件，cman
cman带出来很多东西，文档少的可怜
在ubuntu的时候，配置了三个节点的环境
总觉得lvm之间的数据同步有问题
现在ubuntu和debian混合了，集群里就各自为政了 ^^
三台ubuntu有3个vote，正常工作，两台debian有两个vote，被隔离…
具体原因不明，估计是cman的版本问题，等都换成debian再看吧
╮(╯▽╰)╭
12.17更新
大部分节点更新为debian5
大部分问题消失了
看着clvm管理下的FC存储，舒畅…
12.22更新
两台服务器mount了同一个gfs2分区
分别提供nfs服务
运行了不到半小时，挂了…
对gfs的印象一落千丈
前面有提到过QUBE!
这是个典型的集群管理软件
适用于很多人要用一个集群的情况
它对任务的切分细度取决于相关软件本身
拿3dsmax来说，frame是最小细粒度
qube!没有能力将一个frame打散再发送给渲染节点
那么对于特别复杂而耗时的单个frame，怎么利用集群的计算能力
这个属于渲染器的功能，主流的几个，v-ray,mental-ray,renderman都支持分布式渲染
它们这里的分布式渲染跟qube!的概念就不一样了
理论上，后者的灵活性应该更好一些
qube!除了管理上的优势，性能上，也还是有一些的
诸如一个1000frame的job，一个10计算节点的集群
如果采用qube!分发frame，那么一个节点计算100frame，效率提高10倍
如果采用第二种方式，10台计算节点理论上相当于一个性能十倍于单台节点的超级节点，处理单帧的时间是单机的十分之一
如果都是理想状况的话，性能没有差别，但实际情况下，随着节点数的增加，第二种方式的综合效率增长并不是线性的
拆分单帧，组合结果的复杂度和开销都会随着节点数的增加而拖慢效率
所以，混合两种方式的集群还是需要的
只是混合的方式还不太确定
一种层级式的，qube!控制的是组后后的超级节点
一种是平行的，qube!控制的还是单个节点，每个节点自身也是渲染器分布式渲染的节点
层级式的方式，每个超级节点的规模如何确定才最有效率，而且，投入所以计算能力处理一张图也就没有可能了
平行的话，两种配置是否会冲突？不同性质的任务提交的方式也不同，增加了一点点复杂度
这几天会用虚拟机先试试效果
如果按照我理想的部署，那么10台服务器统统直接访问SAN
用GFS解决共享访问BLOCK设备的问题
现在FC的链接有限
那么用两台服务器做文件服务器，链接SAN
由文件服务器将SAN以ISCSI的方式提供出去
其余服务器捕获两个ISCSI设备后，设置multipath
再依赖GFS解决共享访问BLOCK设备的问题
哼哼，想的挺美，也不知道会不会有问题
12.09更新
让有FC的都连上SAN
性能好的两台各拿1T空间，为需要IO性能的服务提供支持
文件服务器负责剩下的部分，还是上面的方式吧
其实我还是没有想清楚，还是操作起来再决定细节吧
