转载

隐藏在云数据迁移中的6个瓶颈

将PB级字节的数据移动到云端是一项艰巨的任务。人们可能知道，在云端中访问时，其应用程序的行为会有所不同，成本结构会有所不同，并且需要一些时间来移动所有数据。

当企业用户认为网络速度是一个令人头疼的问题时，希望能够得到帮助。但在帮助企业克服这一问题的过程中，专业人员发现许多其他因素被忽略，可能会影响企业的云迁移。

收集、组织、格式化和验证数据会给企业带来比迁移更大的挑战。以下是云迁移规划阶段需要考虑的一些常见因素，以便避免出现一些耗时而昂贵的问题。

云迁移瓶颈#1：数据存储

人们在云迁移中看到的最常见的错误是将数据迁移到云存储中而未考虑如何使用这些数据。人们典型的思考过程是，“我想把文档和数据库放在云中，是因为对象存储成本很低。”但是文件、对象和数据库的行为非常不同，将其数据放到错误的位置会削弱企业的云计划。

文件由路径层次结构组成，即目录树。每个文件都可以快速访问，延迟最短，并且快速(数据开始流动时的每秒位数)。单个文件可以很容易地移动、重命名并更改。企业可能有许多小文件，少量大文件或任意大小和数据类型的组合。传统的应用程序可以像在本地一样访问云中的文件，而不需要特别的云感知。

所有这些特点使基于文件的存储成为最为昂贵的选择，但将文件存储在云中还有其他一些缺点。为了实现更高的性能，大多数基于云计算的文件系统(如Amazon EBS)一次只能由一个基于云计算的虚拟机访问，这意味着所有需要该数据的应用程序必须运行在单个云虚拟机上。要为多个虚拟机(如Azure文件)提供服务，需要使用像SMB这样的NAS(网络连接存储)协议来存储，这会严重限制性能。文件系统是快速、灵活和兼容的，但是它们很昂贵，仅适用于运行在云中的应用程序，并且不能很好地扩展。

对象不是文件。请记住，因为它很容易遗忘。对象位于一个平面的命名空间中，就像一个巨大的目录。其延迟时间很长，有时甚至达到数百或数千毫秒，吞吐量也很低，除非使用了巧妙的技巧，否则通常每秒钟可以达到150兆比特左右。关于访问对象的大部分内容涉及到多部分上传、字节范围访问和密钥名称优化等巧妙技巧。对象可以同时从云计算内外进行读取，但传统应用程序需要性能低下的解决方法。大多数用于访问对象存储的接口使对象看起来像文件：键名称按前缀过滤，以看起来像文件夹，自定义元数据附加到对象，以显示为文件元数据。以及某些系统(如虚拟机文件系统上的FUSE缓存对象)，以允许访问通过传统应用。但是这样的解决方法很脆弱并且表现不佳。云存储价格低廉，可扩展，云原生化，但速度慢，并且难以访问。

数据库具有自己的复杂结构，并且可以通过查询语言(如SQL)访问它们。传统数据库可能由文件存储来支持，但它们需要实时数据库进程来提供查询。通过将数据库文件和应用程序复制到虚拟机上，或者通过将数据迁移到云托管的数据库服务中，可以将其提升到云端。但将数据库文件复制到对象存储中仅作为脱机备份，这很有用。数据库可以作为云托管服务的一部分进行扩展，但确保依赖于数据库的应用程序和进程完全兼容，并且基于云原生非常重要。数据库存储是高度专业化和专用的。

对象存储的明显成本节省与文件和数据库功能的平衡需要仔细考虑需要哪些功能。例如，如果要存储和分发成千上万的小文件，请将它们存储为ZIP文件，并将其作为单个对象存储，而不是将每个单独的文件存储为单独的对象。错误的存储选择可能会导致复杂的依赖关系，这些依赖关系在以后更改很困难，并且代价较高。

云迁移瓶颈#2：数据准备

将数据移动到云端，并不像将数据复制到指定的存储类型那样简单。企业在复制任何内容之前需要做大量的准备工作，并且需要仔细规划预算。概念验证项目经常忽略这一步骤，这可能会导致以后出现代价高昂的超支。

过滤掉不必要的数据可以节省大量时间和存储成本。例如，数据集可能包含不需要成为云计算工作流程一部分的备份文件、早期版本或临时文件。也许过滤最重要的部分是优先考虑哪些数据需要先移动。正在积极使用的数据不会容忍在完成整个迁移过程所需的几周、几个月或几年内不同步。这里的关键是想出一个自动化的方式来选择要发送哪些数据以及何时发送，然后仔细记录所有未完成的事情。

不同的云计算工作流可能要求数据的格式或组织与本地应用程序不同。例如，一个工作流可能需要编译成千上万的小型Word或PDF文档并将其打包成ZIP文件，媒体工作流可能涉及代码转换和元数据打包，而生物信息学工作流可能需要挑选和分段TB级数量的基因组数据。这种重新格式化可能是一个非常费时和费力的过程。它可能需要大量的实验，大量的临时存储以及大量的异常处理。有时很容易推迟重新格式化到云环境，但请记住，这不能解决问题，它只是将其转移到企业使用的每种资源的环境中。

存储和格式问题的一部分可能涉及压缩和存档的决定。例如，在将数百万个小文本文件发送到云端之前将其压缩是有意义的，而不是几千兆字节的多媒体文件。归档和压缩数据可以更轻松地传输和存储数据，但考虑在打包和解压缩这些归档所需的时间和存储空间。

云迁移瓶颈#3：信息验证

完整性检查是一个最重要的步骤，也是最容易出错的步骤。通常假设数据传输期间会发生损坏，无论是通过物理介质还是网络传输，并且可以通过在前后执行校验和来捕获。校验和是这个过程的重要组成部分，但它实际上是准备和导入最可能遭受损失或损坏的数据。

当数据转换格式和应用程序时，即使字节相同，意义和功能也会丢失。软件版本之间的简单不兼容可能导致PB级的“正确”数据无用。使用可扩展的流程来验证企业的数据是否正确可用，这可能是一项艰巨的任务。在最糟糕的情况下，它可能会转变为劳动密集型和不精确的“看起来没问题”的人工处理过程。但即使这样做，也比没有验证要好。最重要的是确保企业能够在遗留系统退役之前识别问题!

云迁移瓶颈#4：转移封送

将单个系统提升到云端时，将准备好的数据复制到物理介质或将其推送到全球互联网上相对比较容易。但是这个过程可能难以扩展，特别是对于物理媒体来说。在概念证明中，看起来“简单”的东西可能会在许多不同的系统发挥作用时变成“噩梦”。

媒体设备(例如AWS Snowball)必须连接到每台机器。这可能意味着要在一个或多个数据中心周围移动设备，进行连接，并更新驱动程序和安装软件。而通过本地网络进行连接可以省去物理移动措施，但软件设置仍然具有挑战性，复制速度可能会降至远低于直接通过全球互联网上传可实现的速度。通过互联网直接从每台计算机传输数据可节省很多步骤，特别是在数据准备就绪的情况下。

如果数据准备涉及复制、导出、重新格式化或存档，本地存储可能成为瓶颈。可能需要设置专用存储来分阶段准备好的数据。这具有允许许多系统并行地进行准备的优点，并且减少了用于可运送媒体和数据传输软件的联系点到只有一个系统。

云迁移瓶颈#5：数据传输

将网络传输与媒质传输进行比较时，很容易只关注发送时间。例如，通过快递可能会发送80TB的AWS Snowball设备，从而实现很快的表观数据速率。但是这忽略了获取设备、配置和加载设备，准备返回设备，以及允许云计算供应商在后端复制数据所需的时间。而这样做的客户定期报告说，这样的周转时间(从设备订购到云中可用的数据)是常见的。这将设备运输的实际数据传输速率降低到每秒300兆比特，如果设备没有完全填充，则会大大降低。

网络传输速度同样取决于许多因素，最重要的是本地上行链路。尽管做好充分的数据准备可以减少企业需要发送的数据量，但无法以比物理比特率更快的速度发送数据。传统协议(包括云计算供应商默认用于对象存储的那些协议)在长距离全球互联网路径上的速度和可靠性方面存在困难，这可能导致实现该比特率变得困难。而用户如果采用CloudDat等加速软件的千兆互联网连接，可达到每秒产生900兆比特的速率，是AWS Snowball的净吞吐量的三倍。

物理运输和网络传输之间的最大区别也是概念验证期间最常被忽视的问题之一。通过物理装运，加载到设备上的第一个字节必须等到最后一个字节全部复制之后才能发货。这意味着如果加载设备需要几周的时间，那么一些数据在到达云端时会过时几周。即使数据集达到总体实际传输速度可能更快的PB级别，在迁移过程中保持优先数据流动的能力仍然可能有利于关键资产的网络传输。在数据准备的过滤和优化阶段进行仔细的计划是必不可少的，并且可能允许采用混合方法。

将数据导入云计算提供商可能不是数据传输步骤的结束。如果它需要复制到多个区域或提供商，请仔细规划如何到达那里。通过互联网上传是免费的，而AWS例如对于区域间数据传输的收费高达每千兆字节2美分，对于其他云计算供应商而言，每千兆字节需要收取9美分。这两种方法都将面临带宽限制，这可能会受益于传输加速软件，如CloudDat。

云迁移瓶颈#6：云扩展

一旦数据到达云端的目的地，其迁移过程只完成一半。首先检查校验和，这将确保到达的字节与发送的字节匹配。这可能比人们可能意识到的更复杂。文件存储使用可以隐藏刚刚上传的数据损坏的缓存层。这种损坏非常罕见，但在清除所有缓存并重新读取文件之前，人们无法确定任何校验和。重新启动实例或卸载存储确实可以容忍清除缓存。

验证对象存储校验和需要将每个对象读出到一个实例中进行计算。与流行的观点相反，对象“电子标签”作为校验和是无用的。使用多部分技术上传的对象只能通过读取它们来验证。

一旦传输的数据得到验证，在企业的基于云计算的应用程序和服务可以使用它之前，可能需要进一步提取和重新格式化和分发。这与在场所发生的准备和发送几乎是相反的。

扩展数据的最后一步是验证它是正确和有用的。这是上面讨论的信息验证计划的另一方面，也是了解是否真正完成的唯一方法。

云迁移更多的是关于流程而不是数据。即使看似简单的文件分发任务也需要复杂的迁移步骤，以确保生成的云计算基础架构与所需的工作流程相匹配。而围绕云计算技术的大量宣传，从成本节约到可扩展性都是有道理的。但仔细规划和预测困难对于确定实现这些回报所需的工具和方法至关重要。

原文 http://www.d1net.com/cloud/news/523078.html

正文到此结束