用户要面临的挑战是即要完成服务器迁移又不会损失解决方案A所需的功能和资源或者引发过多的宕机从而招致用户对IT部门的投诉。
因此当你小心谨慎的实施迁移的过程又不愿遭受损失整个系统的风险,那么你该如何应对这种两难的状况呢?你又该如何满足用户对零宕机的苛刻要求呢?以下是帮助你规避这些风险的五个提示。
提示一:了解系统之间的从属性
虽然IT员工可能不愿意承认这一点,但某些员工可能确实不完全了解一项解决方案在既定的迁移战略中是如何工作的。以Exchange Server为例。更改为Exchange Server可以用几种方式完成,从单个用户迁移简单的电子邮箱转移的操作到从整个服务器转移到新的域这种第三方解决方案(如果必要的话)都涵盖在内。
面临的挑战是这种迁移会对诸如Good Technologies服务,黑莓企业级服务器,Lync和移动技术套装向Exchange(Outlook WebAccess/App,OutlookAnywhere和ActiveSync)本地迁移的系统产生影响。与在电子邮箱服务器迁移过程中将这些生态 系统解决方案考虑在内的方法不同,你可以非常快速的导出所有的移动用户。但是无法全面了解所有的外围系统,而你的目标迁移系统可能会依赖这些外围系统或者 相互依赖,从而让你陷入真实迁移的梦魇。
提示二:知道什么是必须要进行迁移的
一套解决方案是 由涉及一个或者多个服务器或者硬件资源的一个或者多个组件所组成的。在迁移过程中正确的步骤能确保你首先了解解决方案的工作原理和迁移部分在开始实际迁移 前会占到所迁移系统中的比例。传真服务器就是这种解决方案类型的最好示例,因为要保证操作正确许多企业都需要物理传真卡。如果你没有确保传真卡与你试图迁 移的新硬件/虚拟化平台相兼容的话,那么再好的迁移计划也会大打折扣。
提示三:了解什么应该被迁移
一旦你计算出必须从目前平台迁移出去的组件,你应该全面分析你可能需要迁移或者不需要迁移的组件。总会有一些系统组件是没必要迁移到新平台上,但是为了将宕机的可能性和复杂性降到最低可能又有必要迁移过去。
举例来说,Windows系统状态信息可能需要适合的工具从一个硬件平台迁移到另一个硬件平台。如果这种信息可以被迁移过去,那么新服务器配置的复杂性就能被大大降低,至少从Windows系统和软件的角度来说是这样的。
提示四:设定期望值并坚持目标
用户都希望实现无宕机的迁移。但是不幸的事实是这种零宕机的梦想在真实的迁移世界中通常是不可能的。即使在实施物理迁移时没有出现可见的宕机(比如在 Exchange或者Notes中迁移电子邮箱),你仍然需要给你的员工一些喘息的空间来应对意料之外的突发状况。迁移系统状态信息和二进位,认真规划和 在迁移之前提前做好每一件事情能让宕机的可能性降到最低。不过消除所有主要硬件迁移过程当中的宕机只是种期许,可能很难实现。
(责任编辑:武林网)
新闻热点
疑难解答
图片精选