像我们的大多数客户一样，Cloudera的内部运营也非常依赖于数据。十多年来，Cloudera主要在单个生产的CDH集群上构建了内部工具和数据分析。该集群为每个部门运行工作负载-从支持的实时用户界面到Cloudera Data Platform（CDP）升级顾问中的建议，再到分析我们的业务并关单。在此博客中，我们讨论了此关键集群的CDP之旅。您可以了解有关我们如何迁移到CDP的更多信息。
升级前的内部环境
成功升级到CDP私有云基础版的最重要步骤是了解您的环境。您所依赖的CDP特定组件（例如HBase、Impala等），基础架构的使用时间以及工作负载的特征都影响着迁移到CDP的复杂性。我们首先查看CDP升级文档，其中特别注意要求和支持的版本以及升级前的过渡步骤，这些步骤指出了产品中变化最大的部分。在我们的案例中，我们面临着几个显着的挑战：
- 具有多个工作负载的单个长期运行的集群。经过十多年的运营，我们的集群已经建立了各种各样的工作负载。因为我们是在单一的多租户集群中进行架构设计的，所以升级到CDP需要同时准备所有团队的所有工作负载。
- 基础设施老化。尽管我们的团队始终很快采用新的Cloudera产品，但我们的基础架构并没有同样快。在我们的案例中，升级到CDP意味着对操作系统、RDBMS进行重大升级，并对Java进行次要升级。该CDP升级顾问识别大多数这些我们。
- 24×7关键业务用例。我们的支持组织使用基于我们软件的自定义案例跟踪系统与客户互动。我们将竭尽所能，以最大程度地减少该工具的停机时间，这在大型升级期间提出了独特的挑战。
尽管面临这些挑战，我们知道我们想进入CDP私有云基础版。升级之前，我们的集群正在运行CDH 5.16.2。对于我们所依赖的产品（例如HBase和Solr），我们在CDP的许多主要版本升级中也缺少创新。更重要的是，升级到CDP使我们可以选择增加一套新功能，并为将来提供更现代的数据平台。
转移到CDP的准备
转到CDP时，首先要做出的决定是升级现有集群还是迁移到新集群。在与我们的专业服务团队进行了升级前评估之后，出于以下几个原因，我们选择升级现有集群：
- 首先，我们希望尽快完全迁移到CDP。进行迁移后，我们会将每个工作负载一个接一个地移到CDP，我们估计完成此工作将比升级花费更长的时间。
- 其次，我们不想为一个全新的硬件平台投入大量资金。我们确实增加了一些额外的功能，以简化测试和验证过程的一部分，但是许多用户的集群希望在不增加硬件的情况下进行升级，我们通过自身集群的升级来增强信心。
- 最后，我们有许多相互关联的工作负载。我们运行的单一的多租户集群的部分原因是可以合并来自不同部门的数据并全面了解我们的业务。这种架构使将工作负载迁移到新集群变得更加困难，因为许多工作负载需要一次迁移。
由于这些原因，就地升级对我们来说很有意义。在就地升级和侧车迁移之间做出决定后，就可以开始进行深入的准备过程。
在决定升级后，我们浏览了升级文档，以确定我们需要做哪些准备工作。除了上述基础架构更改之外，我们还有许多工作任务要从Spark 1迁移到Spark2。还有许多Cloudera Search集合需要转换，还需要进行一些与HBase 2相关的更改。估计将CDH部署准备好用于CDP所需的时间。我们还将通读所有升级要求和文档，以收集系统级更改（如操作系统升级）的列表并进行估算。这些估算值已成为升级的项目计划，您可以在其中添加我们的升级清单。
执行升级
将我们的CDH集群升级到CDP只花了一天的时间；为成功升级做准备需要花费更长的时间。我们的项目计划跨越三个月，其中大部分时间用于准备升级工作负载，在CDP环境中进行测试以及逐步进行我们需要准备的系统级更改。我们在非生产环境中进行了多次测试升级，以尽可能应对升级过程中可能出现的问题。
通常，我们尝试将生产升级与升级本身分开做。例如，我们将所有Spark 1作业移至Spark 2，并在升级前删除了Spark 1。我们本可以在升级后不久将迁移到Spark 2作为部署操作，但是我们决定，如果可以提前进行更改，我们将这样做是为了简化升级当天发生的事情。
我们在生产中进行了升级前的停机，以完成一些先决条件任务，例如在Master主机上进行数据库升级和操作系统升级。停机时间还使我们能够测试灾难恢复环境，在产品升级过程中，我们的24×7用户将与之交互。我们希望提前完成这些任务，因此我们只能专注于在时机成熟时从CDH升级到CDP。
升级本身花了我们一整天的时间。我们非常努力地遵循说明。这些提供了许多检查和备份，旨在防止您陷入困境，并在出现问题时帮助您进行恢复。我们在升级过程中遇到了一些问题，但是我们经验丰富的运营团队能够使用与客户相同的支持和升级程序快速解决这些问题。我们向Cloudera支持提交了有关我们在环境中遇到的问题的案例，以便我们在升级之前可以解决遇到的任何问题。
CDP上的生活
进入CDP时，我们不会假装一切都能正常运行，但是由于我们进行了工作负载测试和迁移过程，因此几乎所有应用程序以及所有24×7服务在升级后不久都能正常运行。我们遇到了很多长期的问题，这些问题是我们在计划中遗漏的工作负载（很难跟踪数十个人的十年发展历程）或需要进行一些细微调整的。幸运的是，有了记录在案的升级准备工作，并且脑海中浮现了新的活力，我们可以迅速解决大多数问题。当确实出现问题时，我们还可以与Cloudera的优秀支持或专业服务团队联系以寻求帮助。
我们必须进行的主要调整是围绕新功能。对我们来说，主要是Ranger。经过多年的Sentry后，我们不得不围绕处理授权请求的方式来修改一些内部流程，但总体而言，所做的改变变得越来越好。我们终于可以设置用户级别的访问权限了！
CDP上生活中最令人兴奋的部分是拥抱我们可用的新工具的机会。我们正在快速设置Cloudera Machine Learning，Cloudera Data Catalog和Cloudera Data Warehouse等产品，以提高围绕数据发现，高级数据建模和资源隔离的功能。我们希望在未来的博客中分享更多有关我们使用这些工具的信息。
经验教训
以下是我们经验的三点启示，它们可以帮助您为过渡到CDP做准备：
- 您将需要一个运行CDP的测试环境。我们使用Cloudera专业服务团队提供的模板快速构建了一个测试集群来运行我们的代码，以确保它可以在CDP上运行。因为我们预计需要几个月的时间来更改工作负载，所以我们不想立即升级我们的开发环境，因此我们添加了一个临时CDP集群进行测试。
- 了解您的工作量。您的集群可能运行许多不同的工作负载。了解它们的本质并了解迁移到CDP对每个人的影响至关重要。我们遍历了集群中的每个工作负载，并指出了升级后是否需要重新部署它们，是否必须更改代码以及遇到问题时应与谁联系。升级后出现问题的工作负载是记录或理解不充分的工作负载。
- 尽早经常沟通。我们在Cloudera上有数百名用户，每个人都会以不同的方式受到升级的影响。在Cloudera Data Science Workbench中计划了工作的用户可能需要进行更改以准备CDP，而我们应用程序的用户可能只需要知道计划的停机时间即可。与用户沟通对于获得流畅的体验至关重要。大致估计了升级时间后，我们便开始与用户进行交流，并随着情况的变化提供频繁的更新。
如果您想了解有关升级故事的更多信息，我们将举办一个网络研讨会，题为“ Cloudera如何通过迁移到CDP来推动更快的业务洞察力”。请在这里注册以加入我们。
要计划升级或迁移到CDP私有云基础，请联系您的Cloudera客户团队，他们将安排一些时间与您一起探讨可用的选项。另外，这里有一些有用的资源：
- 升级顾问工具
- CDP升级文档
- SmartUpgrade数据表
- CDP知识中心
原文作者：Alan Jackoway
原文链接：https://blog.cloudera.com/drinking-our-own-champagne-cloudera-upgrades-to-cdp-private-cloud/
