Chinaunix首页 | 论坛 | 博客
  • 博客访问: 641135
  • 博文数量: 102
  • 博客积分: 7242
  • 博客等级: 少将
  • 技术积分: 1440
  • 用 户 组: 普通用户
  • 注册时间: 2005-06-06 14:59
文章分类

全部博文(102)

文章存档

2011年(1)

2010年(12)

2009年(6)

2008年(83)

分类: LINUX

2008-11-18 13:43:21

量化可用性和可伸缩性要求
主题上次修改时间: 2005-05-20
当量化要获得的可用性级别时,请将当前信息技术 (IT) 环境的开销(包括中断的实际开销)与实现高可用性解决方案的开销进行比较,这一点很重要。这些解决方案包括培训工作人员的开销以及设备开销,例如新硬件的开销。计算开销之后,IT 管理人员就可以使用这些数字对高可用性解决方案作出业务决策(而不仅是技术决策)。
设立高可用性目标是多方的责任,这些目标必须适用于所有风险承担者。必须评估设定高可用性目标对邮件管理员、业务用户以及客户的影响。例如,尽管执行管理层和最终用户可能想要 99.999% 的可用性,但邮件系统管理员必须阐明获得这样严格的可用性目标所需的开销。
在决定如何评估组织中的可用性之后,请对系统进行例行监视,以便验证是否满足可用性要求,这一点很重要。有关可帮助您评估服务和系统可用性的监视工具的信息,请参阅实现软件监视和错误检测工具。
 确定可用性要求
了解可用性说明了如何以数字形式将可用性表示为服务可使用的时间的百分比(例如,99.9% 服务可用性)。了解可用性还讨论了,确定可用性百分比时,必须如何考虑服务的上下文以及使用该服务的组织的环境。例如,如果存放非关键公用文件夹的服务器上的某个公用文件夹存储不可用,则可能不会影响生产率。但是,如果存放关键任务邮箱或公用文件夹的服务器上的某个邮箱存储不可用,则可能会立即影响生产率。
在正常运作 24x7x365(每天 24 小时/每周七天/每年 365 天)的组织中,具有 99% 可靠性的系统平均每年有 87 小时(3.5 天)不可用。此外,停机可能在无法预料的时间发生 - 也许是在最不能承受的时间发生。理解 99% 的可用性级别可能使您的业务付出太高的代价,这一点很重要。
相反,应该力争的运行时间百分比是 99.x% 的某一变体——而最终目标为五个九,即 99.999%。对于组织中的一台服务器,三个九(99.9%)是可以达到的可用性级别。获得五个九(99.999%)对于一台服务器是不切实际的,因为此级别的可用性只允许每个日历年有约五分钟的停机时间。但是,通过实现带自动故障转移功能的容错群集,可以达到四个九(99.99%)。如果还实现了容错措施,例如服务器级硬件、高级存储解决方案以及服务冗余,则甚至能够获得五个九。
有关获得这些可用性级别(包括实现容错硬件和服务器群集)所需的步骤的信息,请参阅实现 Exchange 2003 组织容错。
设定可用性目标是一个复杂的过程。为了帮助您完成此任务,请在设定目标时考虑以下信息。
注意:
为了进一步协助您设定可用性目标,请回答在开发可用性和可伸缩性目标时要考虑的问题中的问题。 
停机时间和可用性百分比的注意事项
由于可以将计划的系统中断安排在对生产率影响最低的时间内发生,因此,处理计划的停机时间的方式经常不同于处理计划外的停机时间的方式。可用性公式是否考虑计划的停机时间,取决于业务需求。对于在预先安排的业务时间内发生的计划外中断,三个或四个九(99.9% 或 99.99%)的目标所需的投资低于不间断的可用性所需的投资,后者必须包括计划的和计划外的系统中断。有关 8 小时和 24 小时可用性级别的详细信息,请参阅了解可用性、可靠性和可伸缩性中的“可用性百分比和每年停机时间”表。
甚至最短的预设停机时间(例如,每月 2 小时或每年 24 小时)也可以将可用性降低至 99.73%。通过将预设停机时间减少到每月 30 分钟(即每年 6 小时)可以将可用性提高到 99.93%。此外,如果主邮件系统服务器只用于生产目的,而在具有相同数据副本的辅助服务器上执行数据库备份、健全检查以及其他任务,则很有可能获得 99.99% 或更高的可用性。
维护注意事项
若要确定最佳的高可用性解决方案,必须了解用户何时需要邮件系统。例如,如果有时用户没有频繁地使用或根本没有使用邮件系统,则可以在此时以降低的开销执行维护操作(例如安全修补程序更新或磁盘碎片整理进程)。但是,如果用户位于不同的时区,请确保在规划维护日程安排时考虑了他们的使用时间。
恢复注意事项
设定高可用性目标时,必须确定是否需要将 Exchange 数据库恢复到确切的故障点,是否需要快速恢复,或者二者都需要。此决策是确定服务器冗余解决方案的关键因素。特别是,必须确定如果解决方案导致数据丢失,则该解决方案是不方便的、具有损坏性的还是灾难性的。
有关选择恢复解决方案的详细信息,请参阅 Exchange Server 2003 Disaster Recovery Planning Guide(英文)。
 确定可伸缩性要求
规划高可用性时,确定可伸缩性要求可以在将来为组织提供特定程度的灵活性。但是,由于可伸缩性是基于将来的需求(例如,更大的邮件容量和增大的磁盘空间),因此可能很难量化。结果,规划可伸缩性需要一些估计和预测。为了帮助您确定组织的可伸缩性要求,请考虑以下信息。
硬件注意事项
如果具有充足的硬件预算,则可定期购买硬件以添加到现有的部署中。(所购买的硬件数量取决于确切的需求增长。)如果预算有限,则可购买在将来能够进行升级的服务器(例如添加 RAM 或 CPU)。
增长注意事项
研究组织以前的增长模式可有助于确定 IT 系统需求可能会如何增长。但是,由于业务技术日益复杂,同时对该技术的依赖程度也逐年增长,因此还必须考虑其他因素。预测增长时,请注意组织的某些方面可能会以不同速率增长。例如,某段时间内需要的 Web 服务器数量可能多于打印服务器的数量。对于某些服务器,向上扩展(例如,额外的 CPU 能力)可能足以处理网络流量的增长。在其他情况下,最实用的扩展解决方案可能是横向扩展(例如,添加更多的服务器)。
有关可伸缩性的详细信息,请参阅了解可用性、可靠性和可伸缩性中的“定义可伸缩性”。
有关监视邮件系统以分析长期走向的信息,请参阅监视策略中的“为长期走向分析进行监视”。
测试注意事项
手动或使用诸如 Exchange Server Load Simulator 2003 (LoadSim)、Exchange 压力性能工具 (ESP) 以及 Jetstress 等工具,尽可能准确地在测试环境中重新创建 Exchange 2003 部署。通过这些工具可以测试 Exchange 组织中不同方面的工作负荷能力。在这样的环境下观察邮件系统可帮助您制定扩展优先级。若要下载这些工具,请参阅 Downloads for Exchange Server 2003 网站(英文)。有关试生产测试的信息,请参阅系统级别的容错措施中的“实验室测试和试生产部署”。
监视注意事项
部署 Exchange 2003 后,使用软件监视工具可以在某些组件临近或达到容量时发出警报。特别是,某些工具(如性能监视器,可监视性能级别和系统容量)和程序(如 Microsoft Operations Manager)可帮助您确定何时实现扩展解决方案。有关监视性能级别的详细信息,请参阅实现软件监视和错误检测工具。
阅读(1200) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~