[发明专利]用于迁移活动文件系统的方法、设备和系统

说明书

一种在处理对元数据进行操作的命令时将元数据从具有有根树结构的提供者文件系统D迁移到受让者文件系统B的计算机实现的方法可以包括，当没有接收到对元数据进行操作的命令时，通过将提供者文件系统D的节点的元数据顺序复制到受让者文件系统B来在受让者文件系统B处复制提供者文件系统D。当只有一些参数存在于受让者文件系统B中时，该命令可以入队，至少直到该命令的所有参数都存在于受让者文件系统B中。当其所有参数都存在于受让者文件系统B中时，入队的命令可以出队并被调度执行。

背景技术

如今，所谓的大数据在云中找到了天然的归宿。在云中，领先的公司正在充分利用廉价、可扩展的存储以及强大的云分析平台带来的灵活性。然而，尽管将大数据迁移到云有令人信服的优势，但也存在潜在的业务风险。

将大数据迁移至云的一种方法是手动完成。手动迁移是拷贝大数据的一种定制的战术方法。当管理员手动迁移数据时，他们会创建、管理、安排和维护自定义或开源脚本来迁移大型数据集。当数据传输设备添加到大数据到云的迁移计划中时，需要额外的自定义脚本来上传数据。这种手动大数据云迁移方法的业务风险包括数据不一致、业务中断和高IT资源要求。

数据不一致的风险

大型数据集迁移至云需要时间。以每秒1千兆位(Gbps)的速度迁移1拍字节(PB)的数据大约需要100天。即使有数据传输设备，供应商的加载时间也需要数周。虽然使数据在云中可用，但仍然需要更改和接收。在漫长的迁移时间内更改数据会增加将大规模数据集准确引入云的风险。然而，由于手动迁移依赖于侧重于复制数据的自定义或开源脚本，迁移团队可能无法验证迁移的准确性。事实上，大规模手动对账并不能保证数据结果完全一致。此外，这种方法不支持迁移过程中可能发生的新更新。通常，大规模数据迁移的手动方法不支持迁移期间修改或创建的数据更改。

业务中断的风险

由于规模和适用性优势，组织已将越来越多的任务关键型工作负载部署到Hadoop。企业关键型工作负载带来了对可用性、一致性、安全性和可审核性的期望。就复杂性而言，移动不变的数据集很简单，而移动具有这些预期的动态变化的数据集则非常具有挑战性。在大数据迁移期间，手动迁移通常需要对本地应用程序操作进行有意义的中断。选择在数月内将数据集引入云的增量迁移策略的管理员面临着处理破坏性更新的问题，并面临无法满足其企业服务级别协议(SLA)的风险。

高IT资源需求和成本增加的风险

公司为构建数据中心以托管其Hadoop数据和工作负载而进行的重大资本投资刚刚超过了通常的两到四年折旧期，因此这些成本可以注销。从资本硬件折旧转移到云运营支出变得非常简单。公司还在支持内部数据基础架构的人员、流程和应用程序方面进行了大量投资。将手动迁移添加到这些沉没成本中会给IT预算带来风险。尝试无中断、无停机大数据迁移的活动开销非常大。在数据迁移项目开始时，创建、测试、管理、安排和维护自定义迁移脚本所需的资源范围可能没有被完全理解，甚至无法量化。由于手动迁移的自定义性质，此类迁移计划容易出现代价高昂的延迟。

附图说明

图1A是提供者(donor)D和受让者(beneficiary)B的有根树结构的图示。

图1B是根据一个实施例，显示从由前缘和后缘界定的一组节点中拉出的内容的滑动窗口的图示。

图1C是根据一个实施方案，说明内容从提供者文件系统D迁移到受让者文件系统B时，栅栏柱(fencepost)F的示意图。

图2所示为本计算机实施的方法和系统的一个实施例的各方面。

图3为说明本计算机实施的方法和系统的其他方面的框图。

图4为显示未迁移区域和迁移区域之间的重复重命名会阻碍迁移的方式的示意图。

图5显示了将受让者文件系统B的未迁移部分重命名为其已迁移部分的命令的各个方面。