客户是一家台资企业,作为全球的制造业龙头企业的上游企业,提供了向全球知名品牌提供相应的配件。客户前期使用Exchange 2003 邮件系统,前期使用Exchange 2003 后端来实现基于Cluster 的架构,前端使用两台 Exchange 2003 作为前端服务器,防止出现任何一台服务器出现宕机状态其他机器无法提供相关应用。
从09年10月份起,客户Exchange 数据库就出现了类似队列缓慢的状况。经过紧急沟通,客户需要我们到场服务。到场服务后,发现磁盘队列非常长。磁盘队列的计算公式如下:
单个磁盘队列超过 1.5
多个磁盘队列的长度:
RAID 0,1 N*1.5
RAID 5 (N-1)*1.5
客户Exchange 2003 群集模式采用的 两个节点+盘阵方式来实现整个群集方式
磁盘阵列使用的IBM 系列磁盘阵列方式,磁盘柜拥有4个磁盘,依据这样的判断来看,磁盘阵列的瓶颈大约在 4.5-6
而当前客户磁盘队列的长度达到了100, 非常明显的超过了IBM 盘柜能够提供的IO请求, 非常明显的表明磁盘IO是整个应用的瓶颈。
同时经过磁盘阵列的状况分析发现磁盘阵列柜的电池基本处于无电状态。这部分可导致盘柜的CACHE被禁用掉,这样来说就会出现类似的问题。
由于上面跑的用户数量比较多,前端服务器虽然当前有两台,但是安装在AD角色上,而AD两台服务器整体来看,性能也没有达到相应的级别。
而客户端的状况同时也反映出当前在管理上的问题,当前客户端的邮件可以发送无限制大的邮件,这样的话如果一个人发送一封100M的邮件给10个不同域名的人带来的结果会出现带宽阻塞的问题。而这个问题属于传统的管理问题,一时半会可能无法解决。
我们也只有从性能的角度去查看整个问题可能存在的地方。后来将邮件进行分流。把所有可访问的重要用户的Exchange 邮件利用EX2003 Cluster 来实现。其他的用户分流在2台服务器上面。而前端服务器分流在两台AD服务器上面,这样来说,性能得到了一些提升。最终的修改后的架构图如下所示:
但是当前的架构无法满足长期状况下的问题,我们建议客户将Exchange 2003 升级到2010。应用到最新的Exchange 2010 应用模式下可以实现相应的功能。
请接着阅读下一节。