译者 | 布加迪
策划 | 云昭
RDBMS常常是公司所有数据中最关键的，自然不会消失，但也可以充当全面迁移到云端的锚点。
云吞噬软件，那么旧系统消失了么？当然没有。
当今许多顶级企业要么迁移到云端，要么正在迁移中。作为IT组织的一部分，企业通常拥有一个或多个支持业务核心的大型关系数据库管理系统（RDBMS）。这些庞大的老旧单体数据库，往往是公司中最关键的数据，自然不会抛弃，恰恰相反，它反而可以充当全面迁移到云端的锚点。
无论是何种云战略，为了确保成功上云，这些单体数据库对于整个生态系统都必不可少，应该成为迁移战略的一部分。
云迁移示例
当团队试图分离连接到大型关系数据库的应用程序或小系统时，如图1所示，就会出现常见错误。要取得成功，关系数据库和所有连接的资源（无论是应用程序、辅助数据库还是Web服务器等）必须作为一个整体来迁移。此外，这种成功需要一种策略来迁移大量关系数据、多台服务器、安装的软件、作业和网络配置，这些都是数据生态系统的一部分。
网络是最后一个瓶颈，将是需要克服的最大挑战之一。
1.数据引力：大型关系数据库的影响
在过去，关系系统至少有两层：关系数据库层和应用程序或访问层。在较复杂的设计中，它们有多层应用服务器，这些服务器用来管理FTP访问、ETL/ELT、Web服务器、中间件以及与主关系系统密切联系的相应数据库。Oracle等一些平台围绕模式（schema）构建，这带来了更庞大的数据库：除非作为整体来对待，否则更难迁移。
首先，关系数据库不断发展壮大，RDBMS基于模式设计而不是较小的租户架构，每个数据库可能拥有TB甚至PB级的数据。视数据与其他系统的互连性而定，数据库大小会产生自己的“引力”，将系统拉近数据源，进而提供最佳的用户体验。在云端，这种拉力被企业云的庞大覆盖面放大了。
数据引力会将应用程序、连接的数据资产和资源拉到最庞大的数据体，这常常是拥有关键业务数据的遗留关系数据库。
随着更多的数据在应用程序和数据库之间传输到更大的关系系统（通过ETL/ELT处理或数据库链接），所有涉及的系统都需要与更大的关系系统紧密连接以消除延迟。这实际上是数据引力。
为云构建RDBMS时，必须考虑数据引力。不仅对于基础架构而言，甚至对于服务而言，云解决方案必须了解应用程序和数据库连接，才能部署它们以获得最佳性能。设计从最大的系统开始，然后辐射到最小的组件/服务，确保最具影响力的系统获得架构设计成功所需的关注。
2.全部迁移到云端，或什么都不迁移到云端
客户迁移到云时，可能已用几个迁移的系统作了尝试，随后决定将所有内容迁移到云端。考虑到这一点，目标是在本地不留下任何东西，这需要了解旧的关系系统以及将它们迁移到云端的要求。
这种逐渐迁移到云端的策略存在的最大弊端之一是，以前的较小云迁移项目可能已经将各种工作负载转移到多个云上，如果系统之间存在数据交互，这会导致需要发现多云依赖项。网络成为最后一个瓶颈，没有人发现如何克服这个瓶颈。使用对等网络和加速网络，靠近数据中心可能有助于消除一些延迟，但正如图3所示，除非开发新的网络技术，否则这一挑战会继续存在。多云解决方案可以在云提供商之间提供一些数据优势，但它们的运作永远不会像单一云解决方案那样。
云提供商之间的网络延迟差异可能因地区和地理位置而异
克服跨云延迟问题的首要目标是确定每天、每周在诸环境之间需要移动什么数据。第二个目标应该是开发人员如何在本地执行工作，并针对云开发进行优化，尽可能消除多余环节。始终选择简化通过网络拉取或推送数据时可能形成额外IO。
所有跨云数据处理应该经过全面测试，确保它能够满足业务需求，即使数据可能逐渐增多，也是可以接受的。
3.选择：PaaS 还是IaaS？
调查云迁移后，平台即服务（PaaS）和软件即服务（SaaS），是供应商大力推销的、号称是所有本地技术的诱人选择。用户很高兴听到自己可以减少支持基础设施和平台的支出，但忘了在他们想要迁移到云的关系环境中已积累了多少技术债务。
（1）为什么非常大的RDBMS常常局限于Iaas？
一旦PaaS和SaaS显然需要用户放弃许多定制和功能，用户会重新考虑基础设施即服务（IaaS）。这归因于多个因素，但大多数挑战围绕着多年来系统内置的复杂性以及SaaS/PaaS产品缺少功能。在决定云端与迁移到云端的数据资产有哪些选项时，应遵循这些简单的指导原则：
SaaS：
- 新建项目
- 数据库层不需要定制的代码
- 系统采用应用驱动开发，数据存储需求简单
- 较小的用户群和简单的恢复点目标（RPO）/恢复时间目标（RTO）
PaaS：
- 新建项目
- vCPU、内存和 IO的资源使用轻松适应PaaS的限制
- 管理基础设施的IT资源很少，或者希望摈弃这个要求
- 数据库层实现的高级功能或定制选项较少
IaaS：
- 您接触TB到PB级的大型关系系统
- 您需要与本地应用程序相同或相似的架构
- 您对资源有独特的需求——IO、vCPU及/或内存
- 您有要求非常苛严的工作负载，有复杂的RPO/RTO和开发需求
如果需要使用IaaS，重要的是要认识到云供应商可以为一大堆工作负载提供解决方案，而关系工作负载很独特，需要合适的IaaS解决方案来满足要求。
（2）如何扩建RDBMS迁移策略？
迁移具有挑战性，做好准备是取得成功的最佳途径。无论您使用过时的客户端/服务器架构还是大型机解决方案，具有多层系统的关系数据库都需要规划以确保成功。虽然每个项目都很独特，但某些方面是共通的，如果作为计划的一部分得到满足，将有助于确保成功迁移。通用列表常常包括如下：
- 数据库大小和复杂性
- 数据负载和连接的生态系统
- 应用程序、作业、Web 及其他服务器
- 网络延迟
（3）RDBMS中必须识别哪些重要指标？
大多数关系型工作负载耗用大量资源——换句话说，它们对基础架构的要求比其他工作负载更高。但是尽管我们可能专注于CPU和内存，但关系工作负载、尤其是Oracle之类的工作负载可能需要高IO存储解决方案。
大多数IO存储和基准测试侧重于请求（IOP），然而，请求大小会有差异，从而使这些值会有水分。根据我的经验，建议少关注IOP，确保围绕虚拟机和存储IO限制而选择的解决方案能够每秒处理兆字节数（吞吐量）。
（4）创建多层RDBMS复杂性
由于云端的服务、高可用性和备份发生变化，围绕存储的所有决策和解决方案都必须关注RPO和RTO。还应考虑可能与RPO/RTO不同的任何客户正常运行时间SLA，因为服务可能被捆绑到作为架构一部分而选择的存储解决方案中。
确保所有架构决策都基于应如何为推荐的实践设计云架构，而不只是复制客户做入到其本地架构中的内容。这是云端常见的错误，会造成漏洞和冗余。
平移关系数据库工作负载将是一个好的起点，这将消除现有本地硬件中固有的基础架构债务。如果不考虑这种硬件，所有注意力都放在关系工作负载上，可以根据需要设计一种新的架构。
4.重要保证：构架框架
由于大多数数据生态系统不仅需要迁移主数据库和连接的系统，还需要为非生产副本复制，因此构建一个可以作为DevOps实践的一部分进行简化、自动化和部署的框架非常重要。每次在没有框架的情况下执行所有环环相扣的操作将非常耗时、容易出错。
构建云迁移框架始于记录将关系系统从端到端部署到云所需的内容。起步阶段可能类似图4中所示的大体示例，随后可以扩建，以完成迁移项目计划。
一旦扩建完成，使用工具和脚本尽量自动化，同时确保足够大的灵活性，以便将来在众多系统和架构中重用。
云迁移的大体框架示例
确保脚本语言和工具可以像云迁移一样扩展，验证它们可以管理基础架构、关系系统和数据。问题出现并得到解决后，记录下来，确保将来不会重演，从而不断提高效率，作为云迁移策略的一部分。
5.结语
大型关系数据库往往是许多云迁移项目的焦点。一旦迁移到云端，可能提议上多个项目，更新改造和消除这些旧系统，但它们的核心部分往往成为新应用战略的基础，数据驻留在同样的关系系统中，就跟在本地环境中一样。由于资源有限、缺乏ROI或工作量大，更新改造常常消除了改变系统的紧迫性。
随着企业继续向云迁移，将大型RDBMS作为这些数据中心和数据资产的一部分而迁移的推荐实践将必不可少，因为这些关系系统在数据资产中仍将发挥作用。
原文链接：
https://dzone.com/articles/migrate-rdbms-dinosaurs-to-the-cloud
