论文部分内容阅读
从云存储导航选项到数据传送后的验证，按照如下的步骤可以有效避免云数据迁移中的风险。
将TB甚至PB级的数据转移到云端确实是一项非常有挑战性的工作。但是更重要的是你需要看到比这些字节更深远的地方。你可能知道当在云端访问这些应用程序时，它们的运行行为可能会表现得不一样，它们的成本结构将会有所不同（希望是更好），并且转移所有的数据需要花费大量的时间。
因为我的公司，Data Expedition，从事的生意是高性能数据传输，当客户预期的网络速度成为问题时他们就会来找我们。但是在帮助客户企业解决这些问题的过程中，我们看到了许多其他容易被忽略的因素，有可能威胁到整个过程并导致云数据迁移脱轨。
收集、组织、格式化，以及验证你的数据要远比转移数据的挑战更大。我会列举出云数据迁移计划阶段的一些普遍问题，可以帮助你在接下来的工作中避免浪费更多的时间和财力。
云数据迁移瓶颈 #1： 数据存储
我们看到的云迁移中最常见的错误是将数据堆入云存储而不考虑将会如何使用这些数据。典型的思考过程是“我想把我的文档和数据库放到云中，对象存储很便宜，所以我会把文档和数据库文件放在那里。”但是文件、对象以及数据库的行为模式是完全不同的。如果字节放错了位置会破坏你的整个云计划。
文件由层次结构的路径、目录树来组织。每个文件可以快速访问，以最小的等待时间（到首字节的时间）以及很高的速度 （数据流开始后每秒比特数）。可以轻松地将单个文件移动、重命名和更改到字节级别。可以有许多小文件、少量大文件，或者大小和数据类型的任意组合。传统应用程序可以像在房子里一样在云中访问文件，而不需要任何特殊的云意识。
所有这些优点使得基于文件的存储成为最昂贵的选择，但是将文件存储在云中还有一些其他缺点。为了实现高性能，大多数基于云的文件系统 （比如 Amazon EBS） 一次只能由一个基于云的虚拟机访问，这意味着所有需要该数据的应用程序必须在单个云VM上运行。如果要服务多个 VM （比如 Azure Files），就需要像中小企业那样将NAS存储前置，但这又会使得性能严重受限。文件系统是快速、灵活和向后兼容的，但是它们很昂贵，只对在云中运行的应用程序有用，并且不能很好地扩展。
对象不是文件。请牢牢记住，因为很容易忘记。对象位于平面命名空间中，就像一个巨型目录一样。延迟很高，有时几百或几千毫秒，并且吞吐量很低，除非使用巧妙的技巧，否則通常达到每秒150兆比特。访问对象的很多技巧都可以归结为聪明的技巧，比如多部分上传、字节范围访问和键名优化。对象可以同时被许多云本地和基于web的应用程序从云内外读取，但传统的应用程序则需要一些变通的方法。访问对象存储的大多数接口使得对象看起来像文件： 键名通过前缀过滤，使其看起来像文件夹，将自定义元数据附加到对象上，使其看起来像文件元数据或是一些系统，比如VM文件系统上的FUSE缓存对象，以允许传统应用程序访问。但是这些方法是易碎的且破坏性能的。云存储是廉价的、可扩展的、云原生的，但是它也很慢，并且很难访问。
数据库有它们自己的复杂结构，它们可以由查询语言（如SQL）访问。传统的数据库可能由文件存储支持，但它们需要一个实时数据库进程来提供查询。这可以通过将数据库文件和应用程序复制到VM中或者通过将数据迁移到云托管的数据库服务来提升到云中。但是将数据库文件复制到对象存储中仅作为脱机备份有用。数据库作为云托管服务的一部分可扩展，但是确保依赖于数据库的应用程序和流程完全兼容并且是云原生同样至关重要。数据库存储是高度专业化和特定于应用程序的。
如何在可明显节省成本的对象存储与文件和数据库的功能性之间做出平衡，就需要仔细考虑你到底需要什么功能。举个例子，如果你想存储和分发成千上万的小文件，那么与其将它们存档到单一的ZIP文件中，并作为单个对象来存储，反倒不如将每个单独的文件作为单独的对象来存储更好。不正确的存储选择可能会导致复杂的依赖关系，这些依赖关系在后续更改时既困难又昂贵。
云数据迁移瓶颈#2： 数据准备
将数据移动到云并不像将字节复制到指定的存储类型那样简单。在复制任何东西之前，需要进行大量准备，而这段时间需要仔细编制预算。概念验证这个项目环节常常被忽略，这会导致之后的成本代价大大超支。
过滤掉不必要的数据可以节省大量的时间和存储成本。举个例子，数据集可以包含不需要成为云工作流一部分的备份、早期版本或草稿文件。也许过滤过程中最重要的部分就是优先确定哪些数据需要首先转移。正在频繁使用的数据不能容忍在完成整个迁移过程所需的周、月或年之间失去同步。这里的关键是提出一种自动选择要发送哪些数据以及何时发送数据的方法，然后仔细记录所有已完成和未完成的工作。
不同的云工作流可能要求数据采用与内部应用程序不同的格式或组织。举个例子，一个合法的工作流可能需要翻译成千上万个小Word或PDF文档并将它们打包成ZIP文件，媒体工作流可能包含代码转换和元数据打包，而生物信息学的工作流可能需要挑选和分期万亿字节的基因组数据。这样的重新格式化是一个非常费时费力的过程。它需要大量的实验、大量的临时存储以及大量的异常处理。有时很容易推迟对云环境的任何重新格式化，但请记住，这并不能解决这个问题，它只是把它转移到另一个环境，在那里你所使用的每一个资源都有明码标价。
存储和格式化问题的一部分可能包括关于压缩和归档的决策。举个例子，在发送数百万个小文本文件到云中之前，对它们进行ZIP处理是有意义的，但对于几千兆字节的媒体文件，这个方法就不适用。归档和压缩数据使得传输和存储数据更加容易，但是要考虑在两端打包和解包这些归档所需的时间和存储空间。
云数据迁移瓶颈#3： 信息验证
完整性检查是最重要的步骤，也是最容易出错的步骤。通常假定在数据传输期间发生损坏，无论是通过物理媒体还是网络传输，都可以通过执行之前和之后的总和校验来捕获。总和校验在流程中是至关重要的环节，但实际上在数据的准备和导入环节最有可能遭受数据损坏或丢失。 当数据改变格式和应用程序时，即使字节相同，含义和功能也会丢失。软件版本之间的不兼容性可能使千兆字节的“正确”数据变得毫无用处。提出一个可扩展的进程来验证你的数据是否正确和可用将会是一项艰巨的任务。在最坏的情况下，它可能演变成劳动密集型的、不精确的手动进程，即 “在我看来没问题”，但是即使是这样也比根本没有验证要好。最重要的是确保能够在遗留系统退役之前识别到问题！
云数据迁移瓶颈#4： 传送的安排
将单个系统迁移到云上是相对容易的，只需把准备好的数据复制到物理媒体上或通过互联网上传即可。但这一过程很难规模化，尤其是物理媒体。当许多不同的系统开始发挥作用时，那些在概念验证中看起来“简单”的内容可能演变成为“噩梦”。
一套媒体设备，比如一套 AWS Snowball，必须与每台机器相连接。这可能意味着设备在一个或更多的数据中心周围进行物理行走、适配连接器、更新驱动程序和安装软件。通过本地网络连接可以节省物理移动，但是软件设置仍然具有挑战性，并且复制速度可能下降到远低于直接通过互联网上传可以实现的速度。通过互联网直接从每台机器传输数据可以节省许多步骤，特别是当数据已经在云端时。
如果数据准备包括复制、导出、重新格式化或归档，本地存储会成为瓶颈。有必要设置专用存储器来存储准备好的数据。这具有允许许多系统并行地执行准备的优点，并将可运输媒体和数据传输软件的接触点减少到仅一个系统之中。
云数据迁移瓶颈#5： 数据传送
当我们对比网络传输和媒介交付时，很容易只关注传输时间。举个例子，一个80TB的 AWS Snowball 设备可能次日才能送达，然后实现每秒超过8Gb的数据速率。但是这忽略了获取设备、配置和加载设备、设备返回以及云供应商在后端复制数据所需的时间。我们的客户说完成这一流程，花费四周的周转时间（从设备订购到数据在云中可用）很普遍。这使得实际传送设备的数据传输速率下降到每秒300Mb，如果设备没有完全装满，则还要少得多。
网络传输速度同样取决于许多因素，首要因素是本地上行线路。你发送数据显然不可能超过物理的网速，尽管认真的数据准备可以减少你需要发送的数据量。传统协议，包括云供应商默认用于对象存储的那些协议，在跨越远程互联网路径的速度和可靠性方面存在障碍，这使得实现该比特率变得困难。我可以写很多关于这里包含的挑战的文章，但是你不必非要自己去解决。Data Expedition是少数几个专门研究确保路径得到充分利用的公司之一，无论数据距离其云目的地的距离有多远。举个例子，一条千兆互联网连接，再使用CloudDat的加速软件，可获得每秒900Mb的速率，是 AWS Snowball净吞吐量的三倍。
物理装运和网络传输之间的最大区别在概念验证过程中最常被忽略。对于物理装运，加载到设备上的第一个字节必须等到最后一个字节加载完成后才能装运。这意味着，如果加载该设备需要数周时间，那么在到达云端时，其中的一些数据将过期。即使数据集达到PB级别，物理装运总体上可能会更快一些，但在迁移过程中保持当前优先级数据的能力对于关键资产的网络传输来说仍然是有利的。认真规划在数据准备阶段中的过滤和优先次序是必须的，也可采用混合方法。
将数据放入云提供商网络中并不是数据传输步骤的结束。如果需要将它复制到多个区域或供应商那儿，就需要认真计划如何实现它。通过互联网上传是免费的，如果通过AWS，区域间数据传输的费用高达2美分每GB，传输到其他云供应商的费用高达9美分每GB。这两种方法都面临带宽限制，但是可以受益于像CloudDat这样的传输加速器。
云数据迁移瓶颈#6： 云计算
当数据到达云中的目的地时，迁移过程仅仅只完成了一半。需要首先进行校验和检查： 确保到达的字節与发送的字节一致。这比你可能意识到的更棘手。文件存储使用缓存层，这些缓存层可能会损坏刚刚上传的数据。这种损坏并不常见，但是在清除所有缓存并重新读取文件之前，不能确定进行任何的校验和检查。重新启动实例或解除挂载存储可以完成清除高速缓存的工作。
验证对象存储校验和需要将每个对象读出到用于计算的实例中。与普遍认知相反，对象“E-tags”没有校验和检查有用。特别是使用多部件技术上传的对象，只能通过将它们读回来验证。
一旦所传输的数据被验证，在基于云的应用程序和服务能够使用它之前，可能需要进一步的提取、重新格式化和分发。这与在企业内部进行的准备和编组处理完全相反。
扩展数据的最后一步是验证数据是否正确和有用。这是上面讨论的信息验证计划的另一方面，并且是知道你是否真的完成的唯一方法。
云迁移更多的是进程而不是数据。甚至那些看似简单的任务（如文件分发）也可能需要复杂的迁移步骤来确保生成的云基础设施与预期的工作流相一致。围绕云的大量宣传，从成本节约到可扩展性，都是合理的。但是认真地计划和预估困难对于决定使用哪些所需的工具和方法来实现这些回报才是至关重要的。
将TB甚至PB级的数据转移到云端确实是一项非常有挑战性的工作。但是更重要的是你需要看到比这些字节更深远的地方。你可能知道当在云端访问这些应用程序时，它们的运行行为可能会表现得不一样，它们的成本结构将会有所不同（希望是更好），并且转移所有的数据需要花费大量的时间。
因为我的公司，Data Expedition，从事的生意是高性能数据传输，当客户预期的网络速度成为问题时他们就会来找我们。但是在帮助客户企业解决这些问题的过程中，我们看到了许多其他容易被忽略的因素，有可能威胁到整个过程并导致云数据迁移脱轨。
收集、组织、格式化，以及验证你的数据要远比转移数据的挑战更大。我会列举出云数据迁移计划阶段的一些普遍问题，可以帮助你在接下来的工作中避免浪费更多的时间和财力。
云数据迁移瓶颈 #1： 数据存储
我们看到的云迁移中最常见的错误是将数据堆入云存储而不考虑将会如何使用这些数据。典型的思考过程是“我想把我的文档和数据库放到云中，对象存储很便宜，所以我会把文档和数据库文件放在那里。”但是文件、对象以及数据库的行为模式是完全不同的。如果字节放错了位置会破坏你的整个云计划。
文件由层次结构的路径、目录树来组织。每个文件可以快速访问，以最小的等待时间（到首字节的时间）以及很高的速度 （数据流开始后每秒比特数）。可以轻松地将单个文件移动、重命名和更改到字节级别。可以有许多小文件、少量大文件，或者大小和数据类型的任意组合。传统应用程序可以像在房子里一样在云中访问文件，而不需要任何特殊的云意识。
所有这些优点使得基于文件的存储成为最昂贵的选择，但是将文件存储在云中还有一些其他缺点。为了实现高性能，大多数基于云的文件系统 （比如 Amazon EBS） 一次只能由一个基于云的虚拟机访问，这意味着所有需要该数据的应用程序必须在单个云VM上运行。如果要服务多个 VM （比如 Azure Files），就需要像中小企业那样将NAS存储前置，但这又会使得性能严重受限。文件系统是快速、灵活和向后兼容的，但是它们很昂贵，只对在云中运行的应用程序有用，并且不能很好地扩展。
对象不是文件。请牢牢记住，因为很容易忘记。对象位于平面命名空间中，就像一个巨型目录一样。延迟很高，有时几百或几千毫秒，并且吞吐量很低，除非使用巧妙的技巧，否則通常达到每秒150兆比特。访问对象的很多技巧都可以归结为聪明的技巧，比如多部分上传、字节范围访问和键名优化。对象可以同时被许多云本地和基于web的应用程序从云内外读取，但传统的应用程序则需要一些变通的方法。访问对象存储的大多数接口使得对象看起来像文件： 键名通过前缀过滤，使其看起来像文件夹，将自定义元数据附加到对象上，使其看起来像文件元数据或是一些系统，比如VM文件系统上的FUSE缓存对象，以允许传统应用程序访问。但是这些方法是易碎的且破坏性能的。云存储是廉价的、可扩展的、云原生的，但是它也很慢，并且很难访问。
数据库有它们自己的复杂结构，它们可以由查询语言（如SQL）访问。传统的数据库可能由文件存储支持，但它们需要一个实时数据库进程来提供查询。这可以通过将数据库文件和应用程序复制到VM中或者通过将数据迁移到云托管的数据库服务来提升到云中。但是将数据库文件复制到对象存储中仅作为脱机备份有用。数据库作为云托管服务的一部分可扩展，但是确保依赖于数据库的应用程序和流程完全兼容并且是云原生同样至关重要。数据库存储是高度专业化和特定于应用程序的。
如何在可明显节省成本的对象存储与文件和数据库的功能性之间做出平衡，就需要仔细考虑你到底需要什么功能。举个例子，如果你想存储和分发成千上万的小文件，那么与其将它们存档到单一的ZIP文件中，并作为单个对象来存储，反倒不如将每个单独的文件作为单独的对象来存储更好。不正确的存储选择可能会导致复杂的依赖关系，这些依赖关系在后续更改时既困难又昂贵。
云数据迁移瓶颈#2： 数据准备
将数据移动到云并不像将字节复制到指定的存储类型那样简单。在复制任何东西之前，需要进行大量准备，而这段时间需要仔细编制预算。概念验证这个项目环节常常被忽略，这会导致之后的成本代价大大超支。
过滤掉不必要的数据可以节省大量的时间和存储成本。举个例子，数据集可以包含不需要成为云工作流一部分的备份、早期版本或草稿文件。也许过滤过程中最重要的部分就是优先确定哪些数据需要首先转移。正在频繁使用的数据不能容忍在完成整个迁移过程所需的周、月或年之间失去同步。这里的关键是提出一种自动选择要发送哪些数据以及何时发送数据的方法，然后仔细记录所有已完成和未完成的工作。
不同的云工作流可能要求数据采用与内部应用程序不同的格式或组织。举个例子，一个合法的工作流可能需要翻译成千上万个小Word或PDF文档并将它们打包成ZIP文件，媒体工作流可能包含代码转换和元数据打包，而生物信息学的工作流可能需要挑选和分期万亿字节的基因组数据。这样的重新格式化是一个非常费时费力的过程。它需要大量的实验、大量的临时存储以及大量的异常处理。有时很容易推迟对云环境的任何重新格式化，但请记住，这并不能解决这个问题，它只是把它转移到另一个环境，在那里你所使用的每一个资源都有明码标价。
存储和格式化问题的一部分可能包括关于压缩和归档的决策。举个例子，在发送数百万个小文本文件到云中之前，对它们进行ZIP处理是有意义的，但对于几千兆字节的媒体文件，这个方法就不适用。归档和压缩数据使得传输和存储数据更加容易，但是要考虑在两端打包和解包这些归档所需的时间和存储空间。
云数据迁移瓶颈#3： 信息验证
完整性检查是最重要的步骤，也是最容易出错的步骤。通常假定在数据传输期间发生损坏，无论是通过物理媒体还是网络传输，都可以通过执行之前和之后的总和校验来捕获。总和校验在流程中是至关重要的环节，但实际上在数据的准备和导入环节最有可能遭受数据损坏或丢失。 当数据改变格式和应用程序时，即使字节相同，含义和功能也会丢失。软件版本之间的不兼容性可能使千兆字节的“正确”数据变得毫无用处。提出一个可扩展的进程来验证你的数据是否正确和可用将会是一项艰巨的任务。在最坏的情况下，它可能演变成劳动密集型的、不精确的手动进程，即 “在我看来没问题”，但是即使是这样也比根本没有验证要好。最重要的是确保能够在遗留系统退役之前识别到问题！
云数据迁移瓶颈#4： 传送的安排
将单个系统迁移到云上是相对容易的，只需把准备好的数据复制到物理媒体上或通过互联网上传即可。但这一过程很难规模化，尤其是物理媒体。当许多不同的系统开始发挥作用时，那些在概念验证中看起来“简单”的内容可能演变成为“噩梦”。
一套媒体设备，比如一套 AWS Snowball，必须与每台机器相连接。这可能意味着设备在一个或更多的数据中心周围进行物理行走、适配连接器、更新驱动程序和安装软件。通过本地网络连接可以节省物理移动，但是软件设置仍然具有挑战性，并且复制速度可能下降到远低于直接通过互联网上传可以实现的速度。通过互联网直接从每台机器传输数据可以节省许多步骤，特别是当数据已经在云端时。
如果数据准备包括复制、导出、重新格式化或归档，本地存储会成为瓶颈。有必要设置专用存储器来存储准备好的数据。这具有允许许多系统并行地执行准备的优点，并将可运输媒体和数据传输软件的接触点减少到仅一个系统之中。
云数据迁移瓶颈#5： 数据传送
当我们对比网络传输和媒介交付时，很容易只关注传输时间。举个例子，一个80TB的 AWS Snowball 设备可能次日才能送达，然后实现每秒超过8Gb的数据速率。但是这忽略了获取设备、配置和加载设备、设备返回以及云供应商在后端复制数据所需的时间。我们的客户说完成这一流程，花费四周的周转时间（从设备订购到数据在云中可用）很普遍。这使得实际传送设备的数据传输速率下降到每秒300Mb，如果设备没有完全装满，则还要少得多。
网络传输速度同样取决于许多因素，首要因素是本地上行线路。你发送数据显然不可能超过物理的网速，尽管认真的数据准备可以减少你需要发送的数据量。传统协议，包括云供应商默认用于对象存储的那些协议，在跨越远程互联网路径的速度和可靠性方面存在障碍，这使得实现该比特率变得困难。我可以写很多关于这里包含的挑战的文章，但是你不必非要自己去解决。Data Expedition是少数几个专门研究确保路径得到充分利用的公司之一，无论数据距离其云目的地的距离有多远。举个例子，一条千兆互联网连接，再使用CloudDat的加速软件，可获得每秒900Mb的速率，是 AWS Snowball净吞吐量的三倍。
物理装运和网络传输之间的最大区别在概念验证过程中最常被忽略。对于物理装运，加载到设备上的第一个字节必须等到最后一个字节加载完成后才能装运。这意味着，如果加载该设备需要数周时间，那么在到达云端时，其中的一些数据将过期。即使数据集达到PB级别，物理装运总体上可能会更快一些，但在迁移过程中保持当前优先级数据的能力对于关键资产的网络传输来说仍然是有利的。认真规划在数据准备阶段中的过滤和优先次序是必须的，也可采用混合方法。
将数据放入云提供商网络中并不是数据传输步骤的结束。如果需要将它复制到多个区域或供应商那儿，就需要认真计划如何实现它。通过互联网上传是免费的，如果通过AWS，区域间数据传输的费用高达2美分每GB，传输到其他云供应商的费用高达9美分每GB。这两种方法都面临带宽限制，但是可以受益于像CloudDat这样的传输加速器。
云数据迁移瓶颈#6： 云计算
当数据到达云中的目的地时，迁移过程仅仅只完成了一半。需要首先进行校验和检查： 确保到达的字節与发送的字节一致。这比你可能意识到的更棘手。文件存储使用缓存层，这些缓存层可能会损坏刚刚上传的数据。这种损坏并不常见，但是在清除所有缓存并重新读取文件之前，不能确定进行任何的校验和检查。重新启动实例或解除挂载存储可以完成清除高速缓存的工作。
验证对象存储校验和需要将每个对象读出到用于计算的实例中。与普遍认知相反，对象“E-tags”没有校验和检查有用。特别是使用多部件技术上传的对象，只能通过将它们读回来验证。
一旦所传输的数据被验证，在基于云的应用程序和服务能够使用它之前，可能需要进一步的提取、重新格式化和分发。这与在企业内部进行的准备和编组处理完全相反。
扩展数据的最后一步是验证数据是否正确和有用。这是上面讨论的信息验证计划的另一方面，并且是知道你是否真的完成的唯一方法。
云迁移更多的是进程而不是数据。甚至那些看似简单的任务（如文件分发）也可能需要复杂的迁移步骤来确保生成的云基础设施与预期的工作流相一致。围绕云的大量宣传，从成本节约到可扩展性，都是合理的。但是认真地计划和预估困难对于决定使用哪些所需的工具和方法来实现这些回报才是至关重要的。