Microsoft Exchange Server应用案例

我们都知道这种情况:解决方案A托管在服务器1上,但是服务器1的可靠性出于某些原因可能存在一些问题。这样服务器会遭遇故障,更新延迟或者需要虚拟化来保存资源–这只是迁移到服务器2的众多合理原因中的几种。用户要面临的挑战是即要完成服务器迁移又不会损失解决方案A所需的功能和资源或者引发过多的宕机从而招致用户对IT部门的投诉。

用户要面临的挑战是即要完成服务器迁移又不会损失解决方案中所需的功能和资源或者引发过多的宕机从而招致用户对IT部门的投诉。

门窗制造商Pella公司的增长超出了其原有邮件系统的支撑能力,其原有的邮件邮件使用了Microsoft
Exchange Server
5.5。Pella期望更好的性能、更高的可用性以及更好的可恢复性,现有的部署使用了16台运行Microsoft
Exchange
Server的服务器,分布在12个位置,跨越5个Exchange站点,邮件服务托管在基于服务器的存储之上,但它仍然无法满足Pella的需求。现在Pella正在一个双节点
active/passive群集上部署Microsoft Windows Server 2003和Exchange Server
2003,它具有灾难冗余的简单邮件传输协议(SMTP)网关和Outlook Web
Access前端服务器。Pella期望99.999%的可用性,更优良的用户满意度,更容易的IT管理,以及首年度节余超过50%。

因此当你小心谨慎的实施迁移的过程又不愿遭受损失整个系统的风险,那么你该如何应对这种两难的状况呢?你又该如何满足用户对零宕机的苛刻要求呢?以下是帮助你规避这些风险的五个提示。

因此当你小心谨慎的实施迁移的过程又不愿遭受损失整个系统的风险,那么你该如何应对这两种艰难的状况呢?你又该如何满足用户对零宕机的苛刻要求呢?以下是帮助你规避这些风险的五个提示。

背景

了解系统之间的从属性

提示1:了解系统之间的从属性

增长是一件好事,而在变幻无常的经济时代,就是一件更伟大的事情了。但是,增长也带来了挑战。这就是Pella公司面临的情况,它是位于爱荷华州的一家门窗制造商,也许最著名的就是它创新的“隐形”Rolscreen。该公司自1925年创建以来,已拥有超过100个美国专利,为了更好地服务客户,它将自己的制造业务从俄勒岗州延伸到了宾夕法尼亚州。

虽然IT员工可能不愿意承认这一点,但某些员工可能确实不完全了解一项解决方案在既定的迁移战略中是如何工作的。以Exchange
Server为例。更改为Exchange
Server可以用几种方式完成,从单个用户迁移简单的电子邮箱转移的操作到从整个服务器转移到新的域这种第三方解决方案如果必要的话)都涵盖在内。

虽然IT员工可能不愿意承认这一点,但某些员工可能确实不完全了解一项解决方案在既定的迁移战略中是如何工作的。以Exchange
Server为例。更改为Exchange
Server可以用几种方式完成,从单个用户迁移简单的电子邮箱转移的操作到从整个服务器转移到新的域这种第三方解决方案如果必要的话)都涵盖在内。

增长部分归功于Pella对技术应用的增长。为了帮助雇员之间进行通讯和协作,Pella于1998年采用了Microsoft
Exchange Server 5.5,它运行在Microsoft Windows NT Server
4.0上,当时具有400个邮箱。

面临的挑战是这种迁移会对诸如Good
Technologies服务,黑莓企业级服务器,Lync和移动技术套装向Exchange
(Outlook Web Access/App, Outlook
Anywhere和ActiveSync)本地迁移的系统产生影响。与在电子邮箱服务器迁移过程中将这些生态系统解决方案考虑在内的方法不同,你可以非常快速的导出所有的移动用户。但是无法全面了解所有的外围系统,而你的目标迁移系统可能会依赖这些外围系统或者相互依赖,从而让你陷入真实迁移的梦魇。

面临的挑战是这种迁移会对诸如Good
Technologies服务,黑莓企业级服务器,Lync和移动技术套装向ExchangeOutlook
WebAccess/App,OutlookAnywhere和ActiveSync)本地迁移的系统产生影响。与在电子邮箱服务器迁移过程中将这些生态系统解决方案考虑在内的方法不同,你可以非常快速的导出所有的移动用户。但是无法全面了解所有的外围系统,而你的目标迁移系统可能会依赖这些外围系统或者相互依赖,从而让你陷入真实迁移的梦魇。

从那时起,由于采用邮件作为通讯和协作的媒介,Pella的工作能力有了充分的增长。Pella的基础体系已从1998年的400个邮箱增加到今天的3000个邮箱。但是邮箱数量的增长仅仅是Pella实际邮件增长的一小部分,因为每个用户现在都要比5年前发送接收更多的邮件。

提示2:知道什么是必须要进行迁移的

Exchange Server
5.5实现自首次部署以来已扩展到以前未预料到的极限。性能成了问题。邮箱宿主在跨越5个Exchange站点12个位置上的16台Exchange服务器上,使得管理困难、昂贵并且费时。

一套解决方案是由涉及一个或者多个服务器或者硬件资源的一个或者多个组件所组成的。在迁移过程中正确的步骤能确保你首先了解解决方案的工作原理和迁移部分在开始实际迁移前会占到所迁移系统中的比例。传真服务器就是这种解决方案类型的最好示例,因为要保证操作正确许多企业都需要物理传真卡。如果你没有确保传真卡与你试图迁移的新硬件/虚拟化平台相兼容的话,那么再好的迁移计划也会大打折扣。

用户经常发现他们的邮件被冻结或传输运行缓慢。当服务器崩溃时,需要一天甚至更长时间才能恢复在线。

提示3:了解什么应该被迁移

“对我们来说,服务器停工将影响数以千计的用户,”
Pella的资深业务系统管理员以及资深技术管理员Jim
Thomas说。“当你衡量生产损失时,成本很容易就达到6位数。但是成本只是最小的问题。E-mail对于我们已经成为关键任务。如果我们的人员由于邮件停止而无法有效的协同工作,那将是不可接受的。”

一旦你计算出必须从目前平台迁移出去的组件,你应该全面分析你可能需要迁移或者不需要迁移的组件。总会有一些系统组件是没必要迁移到新平台上,但是为了将宕机的可能性和复杂性降到最低可能又有必要迁移过去。

解决方案

举例来说,Windows系统状态信息可能需要适合的工具从一个硬件平台迁移到另一个硬件平台。如果这种信息可以被迁移过去,那么新服务器配置的复杂性就能被大大降低,至少从Windows系统和软件的角度来说是这样的。

为了解决这些问题,Pella决定部署Microsoft Exchange Server
2003,它是微软通讯和协作软件的最新版本。作为Microsoft Windows Server
System的一部分,该软件运行在Microsoft Windows Server
2003操作系统之上,雇员在客户端使用Microsoft Office Outlook
2003消息与协作客户端软件。

提示4:设定期望值并坚持目标

Pella计划将16台运行Microsoft Exchange 5.5
Server的服务器整合到1个站点的6台服务器上,它们在一个active/passive群集中运行Exchange
2003,以实现负载平衡和灾难冗余。另外,存储功能分布在具有一个EMC
SAN的服务器上。

用户都希望实现无宕机的迁移。但是不幸的事实是这种零宕机的梦想在真实的迁移世界中通常是不可能的。即使在实施物理迁移时没有出现可见的宕机比如在Exchange或者Notes中迁移电子邮箱),你仍然需要给你的员工一些喘息的空间来应对意料之外的突发状况。迁移系统状态信息和二进位,认真规划和在迁移之前提前做好每一件事情能让宕机的可能性降到最低。不过消除所有主要硬件迁移过程当中的宕机只是种期许,可能很难实现。

该配置将包含2个邮件服务器,2个简单邮件传输协议(SMTP)网关服务器,以及2个支持Outlook
Web
Access的前端服务器。Pella首次增加了基于Web的邮件访问,该公司实际上将原有的邮件容量从16台服务器整合到了仅仅4台服务器。

设定合理的宕机数量,确保从IT员工到用户每一个人都知道什么时候可能发生宕机,宕机的时间会持续多久。如果这种宕机无法被用户所接受,要解释清楚为什么必须这么做的原因以及一意孤行给系统可能导致的灾难性后果。

Pella也整合了它的目录结构,将Windows Active Directory服务和一个Exchange
5.5目录整合到仅仅一个活动目录中。新实现的硬件平台由Dell PowerEdge
6650服务器组成,连接到一个用于备份和恢复的EMC SAN设备。