《多重云厂商数据迁移三障碍.docx》由会员分享，可在线阅读，更多相关《多重云厂商数据迁移三障碍.docx（3页珍藏版）》请在金锄头文库上搜索。
1、优选文档多重云厂商数据迁移三阻挡迁移应用其实不是一件十拿九稳的事情。无论是你想将当地基础架构转移到云端，还是跨多重云厂商分别开来，都会面对阻挡。转移虚拟机、迁移数据和配置网络在迁移过程中会制造麻烦。迁移虚假机。在当地基础架构和云之间迁移虚假机时，有很多项选择择：使用共享的机器图像格式、导入也许重构。迁移VM最简单的选择是跨多个平台共享图片格式。选择一个云提供商，IT管理者很可能就其现有的VM图像文件格式权衡数个因素，因此找到一种通用的格式需要计划和一点运气。一些云厂商导入虚假机作为服务，经过为不同样的虚假化平台成立导入VM图像。比方，亚马逊Web服务（AWS）已经导入详尽的服务到基于VMwar
2、e的VM图像。该服务导入了VMwareESXVMDK、CitrixXenVirtualHardDisk（VHD）以及微软Hyper-VVHD图像。VM图像也能够作为这些格式导出到VMwareESXOVA。重构虚假机图像格式是一种选择，但是要求使用像Puppet和Chef这样的配置工具。为了做到，你需要详尽化脚本生成VM图像，并在你的目标平台中运转这些脚本。配置脚本赞同你轻松且频频的重构VM图像，因此你会素来拥有软件组件的最新版本。这很重要，但是在应用重过程中不能够犯任何错误；软件组件升级版本与其他组件不适应。在云中迁移数据。从一个云平台到另一个云平台迁移数据有很多挑战。第一步是接见享有的数据储
3、藏配置，并过滤出哪些数据转移到云3端。注意，还有其他的一些事情，读写负载、你潜藏要转移的数据量以及网络延缓问题。关系型数据库典型的应用于客户端-服务器结构中，客户端应用从一个服务器的数据库中读取，在另一个服务器上的数据库中写入。你能够选择共同迁移客户端和服务器，也许只迁移一个组件。哪一种方法更好取决于因素的数量。考虑一种情况，你有一个计算密集应用，在复杂的计算器终端的数据库中写入数据。假设最小的读取在这个数据库上执行。应用和数据库当前当地运转，但是会出现峰值工作负载。在这个例子中，转移计算负载到云端就有意义了，但是数据库留在当地。因为应用读写可是一小部分数据，数据库仍旧在当地，其实不会降低性能
4、；用户累计转移数据也许从云中抽取数据的网络计费在这个场景中不足挂齿。但是让我们假设应用是读取密集型数据库。当地数据库和基于云的应用之间的网络延缓就会降低性能。在这个案例中，迁移整个数据库到云端就更有意义，假设应用将会运转一段时间。为云配置网络。在迁移应用到云端，也许从云端迁移应用时，必定解决大量网络配置问题。最显然的问题就是围绕域名服务（DNS）的问题。在这样的实例中，就需要升级记录。网络问题不那么显然的是内网配置。比方，若是你使用负载均衡器来分别应用工作负载，你需要升级负载均衡器，以便在新的地址使用服务器。其他应用，像数据库，可能需要重新配置，需要解决新的数据库服务器IP地址。在当地基础架构和云之间转移应用时，转移VM图像以及数据和配置网络设置会遭到挑战。从一个虚假环境到另一个虚假环境转移虚假机图像相对简单。迁移大型数据库也许数据集，显然是有问题的。重新配置网络设定不应该是禁止的，应该尽早准备。
