从遗留发行版到CDP的四种升级和迁移路径

进入任何新技术都需要进行计划和协调一致的努力，以确保成功过渡。该博客将描述、

从遗留平台的发行版到CDP的所有路径的每种机制都有共同的工作、缓解风险和取得成功成果的方面。其中包括工作负载审查、测试和验证、管理服务级别协议（SLA）、以及在移动期间最大程度地减少工作负载的不可用。

无论选择哪种方式，成功的升级或迁移都需要详细的计划工作。在具有许多工作负载、多个租户和复杂数据依赖关系的大型环境中，该声明尤其如此。

就地升级

就地升级是将现有的旧版CDH或HDP集群直接升级到CDP的过程。此过程涉及计划内的停机时间、并且需要所有租户之间进行协调一致。协调是必要的，因为它可以使每个人都做好准备在同一天进行升级。

基于要从其升级的旧平台，这种升级过程将保留一些现有设置以及用于各种服务的其他配置。在过渡到CDP私有云基础版时，Cloudera替换了多个旧组件。在可能的情况下，Cloudera会提供了工具和自动化功能的升级过程，以帮助将这些旧组件转换为等效的CDP组件。例如，CDH用户将使用自动转换工具将其Apache Sentry实现转换为Apache Ranger，而HDP用户将使用AM2CM将Ambari配置转换为Cloudera Manager。但是，两个平台上的Spark 1.6用户仍可能需要手动更新代码以与Spark 2和Spark 3兼容。

此图描述了就地升级从评估和发现到升级开发、测试和生产环境的逻辑阶段和主要工作领域。

优点

• 使用现有硬件，并添加很少的新节点（如果需要）。
• 许多服务的现有设置和配置将保持不变。
• 没有其他环境或相关开销。

缺点

• 从CDP私有云基础7.1.6开始，就地升级当前仅限于HDP2.6.5，HDP3.1.5和CDH5.13 +。CDH6升级支持将在CDP私有云基础版7.1.7中提供。
• 就地升级需要集群停机。预先安排某些类型的工作可以最大程度地减少升级当天的停机时间，例如操作系统升级或组件转换，如Spark 1.6到Spark 2.X代码更新。
• 所有租户必须同时准备升级。如果一个租户遇到必须首先解决的问题，则可能会延迟该过程。

何时使用

就地升级最适合具有更多重要数据足迹的大型集群。应用程序的SLA和停机时间要求在决策中起着至关重要的作用，因为这种升级过程需要计划停机时间。在决定就地升级策略时，旧集群的寿命和硬件刷新周期是另一个重要的考虑因素。如果集群节点在近期内不应该进行硬件刷新，则就地升级可能是获取CDP的最佳选择。

Cloudera最近对其内部操作集群执行了就地升级，由于以下原因，决定执行就地升级：

1. 希望尽可能快地走到CDP。
2. 避免大量的资本支出。
3. 具有许多深度互连的工作负载，这将使每个租户之间的迁移变得复杂。

有关更多信息，您可以在此处阅读有关Cloudera升级经验的更多信息。

侧车迁移

侧车（Side-car）迁移方法是CDP的第二条路径。在第二套硬件上配置了一个新的未开发的CDP私有云基础版集群。该过程旨在最大程度地减少单个工作负载的停机时间，同时在每个工作负载的基础上提供一种直接的回滚机制。侧车迁移分为三个主要阶段。

首先，构建并配置新的CDP私有云基础版集群。其次，配置复制过程以提供数据、元数据以及随附的治理策略的定期且一致的快照。第三，将工作负载部署到新集群上，对其进行测试，并在验证后将其转变为生产状态。移动后，请在旧版集群上禁用它们。此更改意味着在迁移期间，您将临时使生产工作负载跨多个集群运行。

Cloudera提供了辅助此过程的工具，包括DistCP，用于数据复制的Replication Manager（以前称为BDR）以及用于Hive模式和迁移的hms-mirror。Authzmigrator提供从Sentry到Ranger的策略转换路径。FS2CS简化了从YARN FairScheduler到CapacityScheduler的切换。在不需要转换的情况下，通过将策略和配置导出导入CDP中的相应组件，可以直接重用。

优点

• 由于遗留版本和CDP版本可以并行运行而不会互相影响，因此更容易满足各个工作负载的服务级别协议。
• 设施齐备的单个租户可以一次移动一个工作负载，而无需在所有租户之间进行任何协调的活动。
• 回滚仅需要在工作负载级别或租户级别进行协调，而无需在整个集群级别进行协调。
• 支持从任何HDP2 / 3或CDH5 / 6版本直接迁移到CDP。该方法还可以推广到非Cloudera发行版。

缺点

• 此方法需要一组重复的硬件，以与旧版环境一起实施未开发的CDP集群。这种新硬件可能会对资本支出和预算产生重大影响。
• 直到所有租户都迁移到新环境之前，额外的环境维护开销。

何时使用

如果您有更严格的服务级别协议，而这些协议又无法使得您的工作负载延长进行长时间的停机时间，则最好采用这种机制。此外，升级过程通常是实施完整的硬件更新以利用更新的、功能更强大的设备的绝佳时机。在决定采用侧车迁移方法的同时，诸如硬件的寿命及其刷新周期，数据中心重定位的需求等因素可以发挥重要作用。结合了硬件更新和数据中心重定位的客户已使用此机制来实施和缩短升级生命周期，并将对业务计划的多重影响降至最低。

滚动式侧车迁移

滚动式侧车迁移是对典型侧车迁移的修改。在此路径中，您会耗尽现有遗留集群的容量，并将其重新用作新的绿地CDP集群，这与传统“侧车迁移”路径中的过程非常相似。新集群运行后，将为应用程序或租户进行初始数据、元数据和工作负载迁移。

进行工作负载测试和验证，这时，将在新集群上提升工作负载，并在旧集群上禁用该工作负载。工作负载及其数据从旧集群中删除，从而释放了新的备用容量。现在，该容量已从旧版集群中耗尽，并移至新的CDP集群中。

此过程将反复进行多次，直到所有租户、工作负载和数据完全过渡到CDP环境为止。

优点

• 重用现有的备用容量或购买最少的新容量，以构建初始的小型绿地CDP私有云基础版环境。与标准的Side-car路径相比，资本支出得以最小化。
• 由于遗留版本和CDP版本可以并行运行而不会互相影响，因此更容易满足各个工作负载的服务级别协议。
• 设施齐备的单个租户可以一次移动一个，而无需在所有租户之间进行任何协调的活动。
• 回滚仅需要在工作负载或租户级别进行协调，而无需在整个集群级别进行协调。
• 支持从任何HDP2 / 3或CDH5 / 6版本直接迁移到CDP。该方法还可以推广到非Cloudera发行版。

缺点

• 它需要足够的可用容量。对于HDFS利用率大于70％或始终始终使用大于90％的计算资源的集群而言，这是不可行的。
• 由于容量减少，该路径可能会暂时影响遗留环境中现有工作负载的性能。
• 由于将节点从旧集群中退役并将它们重新部署到CDP私有云基础版环境中，因此它包含更多步骤，这将影响总体计划。
• 由于节点移动过程，自动化程度较低。
• 考虑到将节点和数据从一个集群转移到另一个集群的过程，需要更多的协调和计划来确定租户的正确迁移顺序。
• 直到所有租户都迁移到新环境之前，额外的环境维护开销。

何时使用

对于拥有备用容量但不能忍受就地升级而延长停机时间的客户，滚动侧车迁移是一个不错的选择。由于此路径试图将常规的“侧车迁移”引起的初始资本支出减至最小，因此，精打细算的客户可能希望考虑使用此路径。

迁移到公共云

从旧平台迁移到CDP公共云与“ Side-car迁移”路径非常相似，但进行了一些小的修改。在Side-car中，您将在旧环境的基础上构建新的CDP环境，并将数据复制到新的HDFS。迁移到云时，数据将复制到云对象存储，然后将以计算为中心的CDP Datahub集群与这些存储桶相关联。

这种设计使您能够独立扩展计算和存储。此外，将租户转移到隔离的集群中，您可以扩展其资源并调整其各自的需求，而不是在多租户环境中达到高峰使用。

优点

• 减少昂贵的数据中心占地面积。
• 无需经历较长的硬件购买周期，即可更快、更有效地扩展各个工作负载。
• 支持在迁移过程中调整特定于工作负载的环境的大小，以最大程度地降低成本和峰值资源使用量，同时维护经常在具有竞争性工作负载需求的受限，整体式集群中受到影响的SLA。
• 通过仅在必要时扩展辅助站点来启用对成本敏感的灾难恢复策略。

缺点

• 如果您缺乏专用的网络资源来将数据迁移到云中，则可能需要花费大量时间。作为参考，使用具有足够并行性的Replication Manager，单个10GB的网络链接每天可以移动约85 TB的数据。

何时使用

当您的本地环境处于生命周期尽头且您希望过渡到更灵活的基础架构模型时，迁移到云是一个不错的选择。当您需要更多的适应性和控制资源分配的资源时，通常由于较长的预算和硬件购买周期而使速度变慢时，此路径也非常有用。在某些情况下，您可以使用混合方法，其中特定的租户和工作负载迁移到公共云以获得更好的成本优化机会，而定义明确的工作负载仍在本地，而集群仍在进行就地迁移或侧向迁移。公共云也非常适合突发性工作负载或CPU密集型工作负载。

选择你的道路

乍一看，选择正确的道路似乎很困难。最终决定取决于您所需的SLA、以了解其可用性、对硬件的访问权或对迁移到云的兴趣。该决策树可以帮助您指出正确的方向。我们将在后续博客中对此进行深入讨论。

了解更多

要计划升级或迁移到CDP私有云基础版，请联系您的Cloudera客户团队，他们将安排一些时间与您一起探讨可用的选项。另外，这里有一些有用的资源：

• 升级顾问工具
• CDP升级和迁移入门
• CDP升级文档
• SmartUpgrade数据表
• CDP知识中心

原文作者：Travis Campbell & Kiran Anand

原文链接：https://blog.cloudera.com/the-four-upgrade-and-migration-paths-to-cdp-from-legacy-distributions/