任何人都可以在一个服务器上安装和配置Exchange Server。但是,简单安装与创建一个完美的Exchange部署是有很大区别的。在实际环境中部署Exchange需要精心的规划。你需要考虑从硬件维护到服务器监控的所有事情。正如你将在本文中看到的,稳定、强力的Exchange部署包括一些微软提供的与Exchange相关的外部工具,同样也需要精心的规划。
校验硬件兼容性
Windows Server 2003和Exchange只能运行在x86服务器或PC上,这也是微软硬件兼容性列表(HCL)存在的一个理由;它包含了一个硬件列表,微软对其进行了彻底的测试并保证它们与Windows Server OS 100%兼容。我建议您只使用微软认证的硬件。这仅仅是避免了兼容性问题,但是也许使你可以更容易获得技术支持。
当你采购服务器硬件时,你需要了解微软关于HCL列表硬件的策略。尽管HCL列举了独立组件(例如系统主板、SCSI控制器、显示卡等等),但是微软只认证完整的系统。如果你用未经微软认证的组件构建服务器,该服务器不会获得支持。但是微软允许你从一个经认证的服务器开始,然后向系统中添加未被HCL列出的组件。
规划你的部署
对于Exchange部署最重要的部分在规划阶段。要将规划部署所需要了解的所有事情完全展现,需要相当大一块面积的图纸,因此让我们只关注于冗余和灾难恢复。毕竟,不管你如何规划Exchange组织,总会发生某种类型的失败。在规划期间,你需要确定组织所能够容忍的失败级别。
群集。如果邮件是你所在组织的关键任务应用,并且无法接受任何级别的失败,则应该考虑使用群集数据库服务器。这样,如果一个数据库服务器失败,群集中的另一个服务器会接管工作。拥有一个群集还使你可以关闭一台服务器进行维护,同时不影响邮件服务的可用性。
有两种群集模式:主动/主动和主动/被动模式。在主动/主动模式中,所有的服务器同时并行工作,而在主动/被动模式中,至少有一台服务器在无故障情况下是待机的。主动/被动模式是首选的;在主动/主动模式下,如果发生失败,没有多余的服务器用来接管工作负载。在主动/被动模式下,剩余的群集节点会执行自己以及失败节点的工作。最糟的情况是,性能将会下降,工作负载也可能完全超出剩余节点的承受能力。但是要记住,主动/被动模式的群集可以多于两个群集节点。因此,当群集节点增加时,未使用的群集硬件会减少,除非你将多个节点设计为被动。
不熟练的Exchange管理员错误地认为群集数据库服务器可以防护任何类型的失败。但其实群集数据库服务器只能防护数据库服务器失败。你的组织可能遇到大量其它类型的失败点,例如DNS服务器、全局编目(GC)服务器、前端Exchange服务器,甚至是一个WAN连接。好消息是你可以利用冗余来克服所有这些故障。
正如你可以群集Exchange数据库服务器一样,你也可以群集Exchange前端服务器。在这种情况下,主动/主动模式和主动/被动模式都不适用,因为一个前端Exchange服务器实际只是一个托管Outlook Web Access(OWA)的Microsoft IIS服务器。因此你应该使用网络负载平衡(NLB)服务来群集前端Exchange服务器,就像群集其它Web服务器一样。
巩固AD、DNS和GC。记住Exchange完全依赖于AD,它也可能是一个失败点。如果AD失败,或者AD对于Exchange不可访问,Exchange也将失败。
如果你有多个域控制器(DC),你也许假设你的AD不会失败。这是一个好的开端,但是你仍然要关注AD的依赖性。也许最常见的问题就是AD没有DNS服务器就无法工作。因此,至少具有一个辅助DNS服务器是至关重要的,如果主要DNS服务器失败,AD仍然可以继续工作。许多大型组织会在每个分支部门放置DC和辅助DNS服务器,以便在WAN连接失败时分支部门内部的系统仍然可以相互通讯。当然,在分支部门放置DNS和DC服务器导致总部与分支部门之间WAN连接的与复制相关的传输。你需要考虑是否有足够的带宽来支持额外的传输。
当你在一个新的森林中创建第一个DC时,Windows将新的DC配置为一个DNS服务器(即假设你没有一台DNS服务器),同时它为该服务器指派了多个AD角色。这些角色中的大多数在整个森林中只能指派给一台服务器(森林级别的角色),或者只能是每个域中的一台服务器(域级别角色)。如果具有这样角色的DC不可挽回地失败,则这些角色总是可以被指派给其它的DC。但是如果是域中的第一台DC失败,那么你将遭遇噩梦,除非你事先曾对此进行过规划。默认情况下,这个DC主管所在森林和域的全部操作主机角色。该服务器通常也作为一个DNS服务器和GC服务器,缺少其中任何一个,Exchange都无法工作。我本人曾处理过这样的情况,并且它没有辅助DC和DNS服务器,确实很糟糕。
有多个原因使得GC服务器非常重要。例如,如果没有可用的GC服务器,则管理员将是唯一被允许登录的用户。另外,Exchange服务器必须查询GC服务器以便解析消息收件人的邮件地址。当Microsoft Outlook客户端打开全局地址列表(GAL)时,GC服务器也是至关重要的。
我的观点是你应该允许DNS服务器或GC服务器成为网络上的单一失败点,特别是两个服务位于同一台服务器时。好消息是将一台服务器指派为一个辅助DNS服务器很简单,同时你可以将任何DC配置为一个GC服务器。但是你肯定不想将组织中的所有DC配置为GC服务器,除非你的网络只有一个域。
基本上,你应该在任何包含一个Exchange服务器的AD站点放置一个GC服务器。例外情况是站点内的邮箱少于100个,并且你具有到其它包含GC服务器的站点的可靠WAN连接。当然,如果WAN连接失败,将没有GC服务器可以访问。当你规划GC服务器的位置时,你也要确保对于每4个Exchange CPU至少有一个GC服务器。这样可避免GC服务器过载。
测试你的规划
现在你已经具有了部署Exchange的思路,你需要测试你的设计方案。微软提供了名为System Center Capacity Planner的工具,非常适合于测试部署的潜力。
这个工具允许你创建一个部署的虚拟模型。不仅是Exchange组织拓扑以及服务器放置的模型,还可以包括服务器硬件提案以及网络连接速度等因素。你可以根据模型来进行模拟,比如在每个Exchange服务器上具有一定数量邮箱的用户,以及预期的每个用户的活动。进行了完全的模拟后,System Center Capacity Planner会显示设计方案中不能可靠满足预期工作负载的部分。
当然,你必须记住模拟仿真只是在模拟的硬件上的模拟用户,而不是真实的性能数据。模拟仿真并非完全精确,因为在实际情况下,服务器性能并不总是在预期的水平,用户通常也并不遵从预期的使用模式。因此,为了留出余地,我建议增加10%的预期工作负载。
显然,System Center Capacity Planner对于判定设计方案是否适合组织的需求来说是一个很好的工具。这个工具也允许你为未来进行规划。在测试了你的模型之后,并且你已确认了你的规划,则你可以进行不同“What if?”游戏。例如,你也许希望看到向特定服务器增加100个邮箱后的效果。如果你的网络使用冗余WAN连接,你甚至可以查看一个连接失败后的网络性能。System Center Capacity Planner不能从Microsoft Web站点下载,但是它包含在TechNet和MSDN订阅中。
优化调整
即便你为规划Exchange部署投入了全部精力,在部署完成之后,你仍然可能需要进行一些优化调整。你需要确保一切都如期望的那样执行,同时你的配置应该遵从微软建议的最佳实践。幸运的是,微软提供了一个非常适合于该任务的工具:Microsoft Exchange Best Practices Analyzer(ExBPA)。
ExBPA从多个源收集配置和性能数据,比如Windows注册表、AD、性能监视器以及元数据库。当它完成数据采集后,ExBPA将其与多个最佳实践规则进行对比。在此期间,ExBPA可以生成详细的报告,指导你一步一步地获得更好的性能、稳定性以及安全性。
维护
对Exchange部署进行了优化调整后,你可以将注意力转移到长期的监控和维护上,有多种理由说它很重要。首先,你的Exchange组织不可避免地随时间而改变。即使你并不计划增加服务器或者重新安排部署(尽管两种情况都有可能),使用的水平也仍然会变化。数据库将会增长,你可能会创建更多的邮箱。Exchange收到的垃圾数量也总是会不断波动。所有这些因素都会对Exchange组织的性能造成某种影响。
其次,常规维护对于确保可靠性至关重要。一个服务器的性能指标和事件日志经常包含潜在问题的线索,如果不及时处理,将会很快变为现实问题。保持跟踪这些信息可以使你在服务中断之前纠正问题。
许多组织忽视监视Exchange服务器的任务。全面的性能监视是一个全天候工作,并且要准确地解释数据,负责查询日志和性能指标数据的人员必须高度理解Exchange和Windows,因此许多公司只能手划十字并祈祷一切OK。几年以前,Microsoft Operations Manager (MOM)通过将服务器监视任务自动化改变了这一状况。MOM根据服务器健康标准监视性能指标和事件日志。MOM在许多场合下也能提前预示问题的发生。System Center Capacity Planner对于设计MOM服务器部署同样很有帮助。
关注关键地带
我不能过分强调精心规划和测试对于Exchange部署的重要性。我也并不装作能在此说明一个优秀的Exchange组织所涉及的全部方面,但是我希望我指明了特定的地带,对其进行精心的准备将会为你的组织的长期稳定性带来很大的帮助。
声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。