这是青年学子在通往梦想中的象牙塔的一次迁徙，这样的场面，与当年的衣冠南渡、走西口、闯关东的场景一起，千万次的脑补都觉得兴奋吧。
云与大数据时代，与人类的每一次迁徙引起热烈反响不同，数据的大规模迁徙往往是悄无声息的，它们以比人类数量超出N次方的体量在网络世界中以0和1的形态飞速奔跑，而这不需要大巴车，没有欢送队伍，只需敲打键盘，安装英方的迁移工具。
某大型国有电力公司拥有近百台X86服务器和工作站，包含了各类生产系统，大部分系统都分部在电力大厦机房的X86刀片服务器和机架式服务器上，相应服务器已经服役了一定的年限。为了各类业务的信息化发展需求，电力公司引进新技术，大力推进虚拟化资源池的建设，需要把部分老旧物理服务器的生产系统迁移到虚拟机上（P2V系统迁移），未使用英方迁移方案时，用户有两种解决思路：
A、电力专责人员在虚拟机上从新部署应用生产系统，自行迁移。
B、使用相关专业厂家的系统迁移解决方案进行P2V系统迁移。
但在具体的尝试实施当中，这两种思路分别都遇到了困难和问题：
1、因为老旧服务器上的各个生产系统相对复杂繁多，系统和数据在新旧服务器上的迁移（P2V）都非常麻烦而且容易出错，不管是前期系统备份、离线和移除，还是后续新系统的安装、测试、数据恢复，直到最终的服务配置，都需要具有一定经验的技术人员来完成。所以采用第一种解决办法所遇到的问题如下：
A、生产数据需要在业务空闲时段进行备份，整个过程需要停止原生产系统业务（停机）。如果数据量较大，备份和恢复时间延长，造成停机时间过长，影响业务持续性。
B、重新部署前需逐一协调原生产系统的停机时间，非常不便，而且很容易影响生产系统业务的运行，具有隐性风险。
C、因当初部署系统的部分原厂家已倒闭或技术人员更换，相关应用业务系统的技术服务终止，而大部分老旧系统的初始化配置相对复杂，调度专责人员也不清楚各个系统的具体配置，导致在虚拟环境上的从新部署困难重重，失败几率较大。
D、部分生产系统的应用程序有操作系统或硬件方面的许可证绑定，而专责人员在实施部署之前也无法准确判断哪些生产系统存在许可证绑定的情况，导致生产系统无法迁移或迁移后的系统无法使用。
2、采用第二种解决办法需要对迁移解决方案进行测试验证，目前市场上有很多容灾厂家都可以做P2V系统迁移，但技术层面和实施效果却参差不齐。根据电力系统目前的实际情况，传统厂家的P2V系统迁移都遇到一定的技术瓶颈，大致分为以下几类：
A、根据需要迁移系统的数据量大小估计停机时间，无法做到在线实时迁移。
B、只能做结构化数据方面的迁移，无法做到应用及配置或非结构化数据的迁移。
C、原生产系统若有操作系统或硬件许可证的绑定限制，则无法迁移或迁移失败。
D、系统和数据的迁移或备份过程中，若有新数据的产生，无法处理增量数据的同步存储，造成迁移后部分数据丢失。
英方服务用户之后，根据用户的生产环境，制定了“P2V系统迁移方案”，并采用以下的实施方案帮助用户成功进行服务器的迁移。
生产服务器：包含各类生产服务器，在其上均安装客户端软件，通过客户端软件将系统文件和数据实时的传送到对应虚拟化服务器上。
虚拟化服务器：将生产端发送的系统文件写入虚拟端的临时空间中，数据写入虚拟端指定文件中，当迁移完成后，系统重启，临时空间中的系统文件覆盖原系统的系统文件接管虚拟端的数据。
针对数据库类应用通过配置单独的规则严格保证数据的一致性，完整性和时序性。实时备份的同时，不需要通过任何数据库脚本，实现全web方式图形化操作，方便用户使用。
通过流量控制功能设置工作时间的灾备可用带宽，甚至暂停备份；工作时间外可以随意放宽限制，避免对生产系统的冲击。
所有的配置和监控可通过控制机实现，通过WEB的方式实现迁移的配置、流量监控、恢复等。控制机可以是网内的任一台服务器，其上安装控制机模块，该服务器必须和对应被管理的服务器可达。控制机软件一般安装在被迁移端（虚拟端）内部。
通过字节级的数据捕获，极大地减少了数据的传输量，在带宽有限以及恶劣网络环境中均能很好地实现数据复制的任务。
针对未来的系统扩展，只需在新的需保护的系统上安装英方产品模块即可，无需采购同构的硬件或其它的灾备模块。
英方灾备观点
英方助力用户进行服务器的迁移，不仅是因为英方解决了用户对数据/系统实时的热迁移、不限制应用类型等需求，还解决了迁移过程中增量数据同步迁移的业界难题，保证用户系统迁移前后数据的一致。
更重要的是i2COOPY、i2Active、i2Move等英方优势产品都支持主备端的异构平台，比如生产端是物理机，备端是虚拟机；生产端是华为硬件，备端是戴尔的硬件；生产端是华为虚拟化、备端是VMware虚拟化，这些技术优势可以减少用户系统迁移遇到的很多麻烦，缩小迁移的周期，减少迁移的工作量，系统迁移的安全性、稳定性都等到保障。
云迁移相关阅读：
沪公网安备 31010102007331号