这篇博文是Glass House Technologies公司副总裁Bill Peldzus先生就如何管理和规划数据中心迁移所写的系列博文的第二部分。上周，在第一部分中，他就数据中心的任何变化都需要进行提前规划必要性（这些变化包括采用新的技术以及数据中心选址和基础设备的迁移）进行了探讨。
“所谓经验，不过是人们给自己人生错误蒙上的一层遮羞布而已。”奥斯卡•王尔德
“只有一件事情比从经验中学习更痛苦，那就是不从经验中学习。”劳伦斯J•皮特
上述这些名言常常被人们引用来教育那些忽略吸取宝贵的经验教训，而片面强调“下一次的机会更好”的行为。当处理一个像数据中心迁移这样的大项目时，无论其是属于基础设施巩固、还是项目升级、或迁移到另一个数据中心，或是同一地点的设备移动。总之，细节决定成败，因此为减少相关风险，适当的规划是至关重要的。
在过去的几年的时间里，我一直在关注数据中心的迁移问题，而这些观察也为我今天关于数据中心迁移问题所遇到的挑战的思考奠定了一定的基础。现在，我们有必要对未来的数据中心迁移进行详细的规划，而不是为了避免断电就突击性的在半夜进行迁移，或者更糟的是，在迁移的最后一刻才完全恢复。但如果进行了很好的规划，不管你实际上是否是为了避免或解决此类问题，在执行的时候，相关经验都会发挥积极主动的作用，而不需要反复调试、考虑。我的执行和赞助团队总是热衷于强调“如果这种情况发生了，我们有相关的步骤，计划采取适当的手段，来解决这个问题。”
关于突发事件的应急预案、以及数据中心迁移的问题，如下是一些可以帮助您提前进行一些详细规划的建议：
新技术的采用通常也就意味着其他方面的升级
如果在迁移活动过程中涉及到要迁移到新的硬件，这通常是要更新到更好、更新的硬件设备（可能会带来成本效益），无论是具体到服务器、存储设备、或网络设备。积极处理报废设备和潜在的即将过时的设备，这都是一件好事。
但与此同时，新的硬件必然需要配套进行一些其他方面的兼容性升级和支持。最明显的便是体现在服务器的操作系统上，一般都需要打或大或小的补丁，或甚至固件升级。但是，其实这只是冰山一角。你还需要考察其对几乎所有的应用程序栈可能带来的影响。这些因素包括数据库版本、中间件版本、以及应用程序本身。这些类型的升级可能会为您的应用程序管理团队带来很大的负担，无论是从认证和测试方面，甚至将有可能对您时间和项目计划都有重大影响。
再有就是，没有人提前展望未来。我回想起曾经的那些痛苦的迁移经历，在没有充分进行压力测试的情况下，我们发现，在迁移之后，对于一个特定的应用程序加硬件组合来说，新的多线程处理器芯片设置实际上大大减慢了单线程应用程序的性能。这很诡异。所以，我们现在要问，是否单线或多线程在规划之前有必要进行适当的和详细的性能测试。
是否将物理移动lift-and-shift作为迁移首选方法？
我的许多客户都倾向于将大规模的物理迁移作为首选的方法。当然，从逻辑上讲，你不需要重新部署电缆、插头、机架等等，但是，这样真的可行吗？嗯……恐怕不是。对于某些项目来说，其存在着一系列重大的风险你需要慎重考虑：
供应商是否需要重新检测设备，特别是对较大的设备，如磁带库或存储阵列？
这其中是否涉及到航运商的选择？
你打算如何处置相关数据，如果这些数据位于存储区域网络（SAN）？
你是打算迁移整个存储区域网络（SAN）吗？
NAS连接状况如何？
何时进行物理运输？
是否针对内部特殊数据的安全问题配套服务器？
如果服务器在迁移过程中丢失或延迟，是否有相关紧急预案？这一预案绝对不便宜……你需要为其进行保险。
当设备重新安装时，将发生哪些变化？包括服务器的名称、IP地址、防火墙规则、备份的基础设施、网络路由、DNS、负载均衡等。
因此，基于上述一系列的原因，lift-and-shift迁移方法通常是我最优迁移选择中最后选择的方案。虽然其针对诸如单机非生产实验室和测试设备等“特殊情况”可能非常有效，但我确实曾因这一方法经历过很多不好的经验。
在这篇专栏的下半部分，我将讨论v-2-v副本、“广域网”和“局域网”之间的差异、以及应用程序和连接速度问题如何影响你数据中心迁移的进展问题。
#p#副标题#e#
“局域网”与“广域网”有着显著的不同——即使只是暂时的 服务器
高速局域网连接与低速广域网连接（都涉及到网络延迟和带宽问题）与应用程序以及用户没有很好的连接到这些应用程序之间是相互依存的关系。太多的本土应用程序始终被认为：1）在同一数据中心和2）最终用户可能是在同一建筑物的不同的楼层。而这无疑就给数据中心迁移工程增加了许多额外的挑战，使得工期延长至好几个礼拜甚至几个月。但是又有多少数据中心迁移工程能够容忍如此长时间的性能损失呢？
虽然现在开发出的新的、更灵活的应用程序似乎使得解决上述问题更容易：尤其在当今互联网可以连接一切，以及各种“XXX即服务”模式的广泛普及，使得数据中心那些极少数的应用程序的迁移已经不再可能长时间影响企业的核心的业务了。您可以让您的应用程序团队及早并经常性的参与迁移工程。以便为延迟做好准备。
从虚拟端到虚拟端（V-2-V）模式蓬勃兴起，但也要意识到其制约性
如果你有许多应用程序采用了虚拟化基础设施和手段，这意味着增加了您的迁移的选项组合。我是虚拟化技术的忠实粉丝，特别是当涉及到服务器虚拟化，作为从虚拟端到虚拟端工作的时候，这真的能为你和您的应用程序团队减轻负担——不用再重新加载操作系统、数据库、中间件等。
但与此同时，您也需要了解所有这些好处和相应的计划的另一面。让我们假设一个简单的v-2-v复制/或者通过广域网迁移到一个新的数据中心的时候。您需要考虑如下问题：
• 在迁移之后需要立即进行测试和验证，因为服务器在迁移之后的当前状态通常是关闭的。理解这一程度需要花费应用和测试团队一定的时间。
• 还必须考虑广域网的传输速度：特别是对于大型数据存储来说。如果超过300GB，您可能需要全天候的v-2-v，而不是几个小时。
• 如果在迁移期间出现v-2-v中断，您的应急预案是什么？这是继续迁移/重新启动或重新迁移？这两种方案的结果是完全不同的。
• 并行会带来什么影响？对于仅仅是25或40台V-2-V运行一个周末来说，该计划可能还是可行的，毕竟每台服务器只有100GB或更少的数据量。但如果要同时迁移所有这些数据呢，如此众多的数据转移将使你的广域网瘫痪，并打乱你的时间安排。
上述这些都是在迁移过程中，通过适当的规划帮助您减轻风险，正确衡量，并最终帮助您的企业成功按计划完成迁移的一些建议。最后，我想强调务必把更多的精力放到你的迁移计划中，须知“今天的好计划胜过明天的完美计划。”
原文链接：http://www.jifang360.com/news/2011823/n521027519.html
