数据容量规划策略如何有助于灾难恢复?
2010-2-8
【TechTarget中国原创】想想看下述场景是否在你的IT部门出现过?
系统管理员Joe把他的头探进办公室说,“告诉大家一个坏消息,我们Exchange服务器的容量已经达到97%,我收到了系统的警告信息。”
如果发生这种情况,那就说明过去所做的容量规划工作失败了。此时不用再做无谓的努力了,即已经处在失败的情形了。极有可能的情况就是申请更多原来根本没有预算的费用。在这样的一个经济时代,可能永远无法知道这样糟糕的状态到底会是什么情况。
虽然说时光不能倒转,但是仍然可以改变未来。如下是一个推荐的方法,可以用来开发容量规划策略以帮助用户摆脱这样的噩梦,并且类似情况防止再次发生……
【TechTarget中国原创】想想看下述场景是否在你的IT部门出现过?
系统管理员Joe把他的头探进办公室说,“告诉大家一个坏消息,我们Exchange服务器的容量已经达到97%,我收到了系统的警告信息。”
如果发生这种情况,那就说明过去所做的容量规划工作失败了。此时不用再做无谓的努力了,即已经处在失败的情形了。极有可能的情况就是申请更多原来根本没有预算的费用。在这样的一个经济时代,可能永远无法知道这样糟糕的状态到底会是什么情况。
虽然说时光不能倒转,但是仍然可以改变未来。如下是一个推荐的方法,可以用来开发容量规划策略以帮助用户摆脱这样的噩梦,并且类似情况防止再次发生:
- 第一阶段:合适的时间解决合适的问题
- 第二阶段:短期执行
- 第三阶段:长期规划
第一阶段:合适的时间解决合适的问题
通常我们看这个世界都会有一定的视野局限性。首先提出一个问题,再解决这个特定的问题,然后再向前发展。
遗憾的是,如果无法打开视野的话,处理一个这样的问题往往就是忽略一个瓶颈问题的同时暴露另外一个问题。很多容量管理问题都是非常复杂,也会有若干种解决方案。在这些场景中,容量管理就不再是一个问题了。这是我的亲身体会得到的……
几年前,有一个客户让我每个月输出一份数据库性能报告。在这项工作持续几个月以后,他发现性能有所下降,这就迫使他给予过多地关注,并且他也丝毫不隐瞒对这种情况的关心。他下意识地反映就是表示对数据库性能的关注。
实地演习就开始了,并且逐一开始解决,从更换服务器到升级内存都考虑过。最终的调查结果表明,问题不在于数据库变得慢了,而是报告的输出频率不够,导致的结果就是很小的性能波动都会给整个报告带来非正常影响。我们通过提高报告输出频度来解决“容量”问题。
底线:回顾所出现的问题,标识出所有的因素,然后再开始着手使用合理的解决发难解决问题。
第二阶段:短期执行
在标识出问题原因之后,就可以开始规划紧急救援。在文章开头我提出的那个Exchange危机中,我们最终使用Microsoft EXBPA工具分析Exchange服务器,并且迅速查明有几个用户的收件箱太大。
底线:分析这些事实,弄清楚短期规划的优势所在以及这些规划如何可以辅助摆脱危机模式。
第三阶段:长期规划
通常情况都是我们完成短期执行阶段后就回到日常工作中,并且很快就忘记并没有真正的解决这个问题。无可非议,我们把Exchange的利用率从容量的97%降低到了85%,但这只是一个短期解决方案。
在这个案例中,我们需要长期战略。例如邮箱规模的限制、归档离职员工的数据、对邮件服务器的定期升级(依据企业自身的规定)以及报告容量度量的系统以防止再次超过90%的占用率。
底线:除非长期规划得到很好的实施,否则最终仍然会回到最初的问题。
还需要注意的是:除了上述这些方法,还有很多工具也可以辅助完成容量规划工作——但具体的工具和方法取决于具体情况。微软提供了几种工具,如EXBPA和Microsoft系统中心。但是即使同样的工具就算可以帮助用户摆脱麻烦,但通常也会使用户无法摆脱危机。