2008年（8065）
分类： 服务器与存储
2008-08-28 12:53:43
部门在部署电子邮件存档工具时，往往会面临公司性质、IT团队及邮件用户的能力如何/是否成熟等相关问题。如果财务问题是最重要的因素，那就应该强调证据点和强制保留策略。对于那些经常面临昂贵的法律发现（legal discovery）的公司而言，保留策略和简单检索显得格外重要；具有相同需求的公司还需要统一的查找标准。
其它的实施问题更多地是与公司规模相关，并非与行业相关。通常，公司会列出需求清单，部署的存档程序必须满足这些需求。我建议各位花点时间考虑一下存档程序对公司经营和管理的影响，具体影响取决于供应商如何设计程序。
本文陈述的最佳策略——在Microsoft Exchange中主要关注存档——能缓解部署、经营及维护问题。
1存档数据库管理。存档程序将数据写入数据库，这就意味着一些数据表格需要进行常规的内务处理。例如，存档器维护的表格可能包含“可疑”邮件。如果不经常维护，这份表格就可能扩大数据库的规模，直至影响整个应用程序。需要考虑的问题包括：判断哪些是合理、安全的开销，“可疑”表格是否会触发临界警告。查清警告的工作原理，明确警告的处理人员。
2文件清除和处理。如果数据写入非机构化文件，记得弄清哪些功能需要进行日常清除。如果一段时间内无法存档，应考虑会对已选择的存储层带来哪些操作上的影响。如果无法进行常规的日志清除工作，应该设定会触发警报的操作临界值。如果存档环境中的、网络或存储发生故障，就可能需要临界值。
3存档文件结构。存档文件结构是指实际数据的保存地点，最好是独立存储。大公司往往有几十个甚至几百个Exchange。存档程序可能会在多个服务器上运行，有时候是在Exchange服务器上运行，但是应该了解存档和索引数据是否写入单个数据存储中。不过不了解，就应该弄清楚管理存档环境还需在哪些方面做出努力，尤其是当存档规模不断扩大时更应如此。
4应用程序的可用性。邮件是一种变得越来越重要的应用程序，许多公司采用集群或其它高性能的技术，保证Exchange环境的可操作性。同样，存档程序也需要保证可用性（如果只是为了维护日志清理功能）。支持可用性的架构会增加操作负荷。除非存档产品具备某种自动故障恢复能力，否则集群或相似技术就能管理双倍的服务器。
5负载平衡。多个存档服务器支持多个Exchange服务器的时候，负载平衡成为一个非常关键的问题。手工平衡负载费时费力，不能有效利用资源。寻求负载自动平衡能力，可能由传统的中间件提供，也可能集成在存档程序中。
6索引重建。即使是处于最佳运行状态的环境，索引也可能发生故障。如果索引指向成千上万的邮件，重建工作就如噩梦般可怕。需要考虑以下事项：重建过程对用户透明吗？Exchange操作会受感染吗？重建索引会对日志清理产生什么影响？重建完索引后，Exchange或存档软件需要重新启动吗？重建索引会对管理负荷、恢复时间和终端用户的服务级别产生重大影响。
7客户端代理。为了对用户最大程度地透明化，一些产品需要在每个Exchange客户端（Outlook）安全代理。对用户而言，这么做可能比较方便；但是对IT管理人员而言，这就成了很大的负担，尤其是有些公司无法推出的有效客户端代理，IT人员的负担更重。安装客户端代理正处于发展极端，还需不断重复、不断改版，才能适应存档软件或Exchange。
8报告和度量。存档无休止地增长，每天都会保存大量邮件，有了邮件存档工具，你就能处理难以计数的邮件。要管理坏那个，你需要了解有多少邮件和附件（及其大小）在Exchange、存档和分层存储中迁移。管理用户的检索需求，分配合适的服务类别，应付这些工作你需要保留以往的邮件分析报告，明确每组邮件的最后访问日期。综合度量组件能帮你有效管理存档环境。
9备份存档。数据存档以后，再对其每周进行一次完全备份就没有意义了。存档数据能备份到两份或三份复本中，在介质更新期限之前，都不必加以管理。存档程序必须定期通过存储层迁移存档邮件，然后只对最高层进行备份。另外，还要了解备份之前，存档产品是否需要手动关闭服务。
10可扩展性。主要的扩展性问题是存档程序需要多少硬件，才能支持Exchange环境。也可以这么说，存档服务器能支持多少Exchange服务器，支持特定量的邮箱或邮件，需要多上存档服务器。不管选用哪种度量方式，如果邮件会在三至五年内不断增长，都需要考虑将会发生的问题，这点至关重要。如果关键度量——如Exchange服务器或邮箱的数量——双倍增加，存档解决方案也需要双倍增加吗？
人员满意查找标准，让IT人员满意小型Exchange数据库。你还应该明白，要管理存档环境，你需要在管理负荷上作出投资。
考虑以上十点注意事项，以及存档特性和功能需求，你就能利用供应商的陈述和实际结果，了解部署流程。
