经过这些年企业IT上云，云平台已经成为了企业最关键的IT基础设施了。很多企业甚至全面学习互联网企业的经验，通过云平台将应用架构做了彻底的云化，通过领域建模等将数据库也拆分为规模很小，数量庞大的领域数据库了，这些数据库规模不大，大部分可以使用云上的RDS服务。这种转型让企业的IT基础设施与IT运维变得十分扁平化，也变得很简单。不过大量的传统行业企业的应用系统还无法与互联网企业一样，数据库依然是IT系统里比较重的组件。这些企业大多存在数据库上云的需求，只不过因为技术原因，目前还不敢把未能小型化的数据库完全迁移到云上。
将数据库这个“重”IT组件也上云管理，是很多传统企业用户近些年在努力做的事情，也有一些企业已经把一些“重”数据库迁移上云，不过上云后的效果不尽如人意。
他们在把一些商用数据库迁移到云上的时候，遇到了很多问题。首先必然会遇到的一个问题是云平台对商用数据库原本是不支持的，而且因为商业竞争的问题，哪怕是企业内部部署的私有云，云平台供应商都不大愿意纳管竞品商用数据库产品。商用数据库上云往往只能憋屈地使用云平台上的ECS，在上面进行手工部署。哪怕通过自定义镜像快速部署编排好数据库实例的ECS，在使用的时候也受到种种限制。比如云盘的性能不稳定导致数据库运行不稳定；底层虚拟机的IO优化没有考虑数据库的场景导致数据库丢失IO出现坏块；云盘容量受限导致数据库出现存储空间不足；数据库备份受限于网络带宽不足而无法在维护窗口完成备份，等等等等。
前些年也有很多企业和我交流过这个问题，不过这些年少了不少，很多企业都绕道走了。前阵子和一个金融企业交流云上的国产数据库的性能问题的时候，我问他们这么做的目的是什么。他们觉得以后用了国产或者开源数据库，数据库实例的数量会翻倍，不让IT尽可能扁平化，今后将面临更大的挑战。从这个角度上看在未来较大型的数据库上云依然是很多企业无法避免的事情。
实际上让公有云或者私有云支持国产商用数据库是没有任何问题的，数年前阿里云推出的云速搭CADT，可以通过复杂的模板支持针对Oracle RAC在内的复杂应用系统的编排。从阿里云实现对Oracle RAC的支持，我们也可以学习到很多大型数据库系统上云的一些思路。支撑阿里云支持Oracle RAC的组件包括：
- HAVIP：High Available Virtual IP Address，简称 HAVIP。阿里云虚拟网络实现的是基于二层的高可用 IP，通用、简单、易用。HAVIP 以 secondary ip 的形式存在网卡上，可以有单独的转发策略，通过 HAVIP 可以实现浮动 IP，适用于 HA 主备容灾或者双活高可用的场景；
- 专有网络 VPC：基于阿里云创建的自定义私有网络, 不同的专有网络之间二层逻辑隔离，可以在自己创建的专有网络内创建和管理云产品实例，比如 ECS、负载均衡、RDS 等。在创建前，您需要结合具体业务，规划VPC 和交换机的数量及网段等；
- 弹性网卡 ENI：弹性网卡 ENI（Elastic Network Interface）是一种可以绑定到专有网络 VPC 类型 ECS 实例上的虚拟网卡。通过弹性网卡，可以实现高可用集群搭建、低成本故障转移和精细化的网络管理。
- ECS 7 代存储增强型实例：能够提供高性能的数据库服务器，特点是IO延时较低，IOPS较高；
- ESSD 块存储：阿里云 ESSD（Enhanced SSD）云盘结合 25 GE 网络和 RDMA技术，提供单盘高达 100 万的随机读写能力和单路低时延性能，在此方案中ESSD块存储使用的是NVME共享盘作为底层磁盘资源；
- NVME共享盘：支持 NVMe 协议的 ESSD 云盘被称为 NVMe 共享盘。NVMe 共享盘支持多 ECS 实例并发读写访问，具备高可靠、高并发、高性能等特点。为 ECS实例提供了多实例挂载和 IO 拦截功能。共享盘是为了RAC的多实例并发读写共享存储；
- 云企业网 CEN：云企业网（Cloud Enterprise Network，简称 CEN）是阿里云提供的一款能够快速构建混合云和分布式业务系统的全球网络服务，为用户提供优质、高效、稳定的网络传输环境，帮助用户打造一张具有企业级规模和通信能力的云上网络。适用于集团企业、全球网络等场景；
l转发路由器 TR（Transit Router）：提供连接网络实例、自定义路由表、添加路由条目、添加路由策略等丰富的网络互通和路由管理功能；该功能可以与CEN结合，实现Oracle RAC的INTERCONNECT 多播网络；
- 云速搭 CADT：通过模板实现Oracle rac自动编排。
在云平台上以接近云原生的方式实现一个大型Oracle RAC的编排还是有点费劲的，哪怕是把Oracle RAC搭建好，并能够承受高负载都不是一件很容易的事情。在云纳管大型关键数据库的时候，一般会采用裸金属服务器或者虚拟化云主机两种模式。如何对这两种部署模式进行标准化设计并针对大型关系型数据库进行优化，其实是要事先考虑好的。阿里云的这个方案可以给我们一些启示-网络和存储是其中最为关键的因素。
存储方面，阿里可以提供高性能低延时的ESSD块存储。在我们自己的云环境里，也可以购买一些商用的高性能分布式存储来构建存储资源池，专用于大型数据库存放数据。这些存储在优化上必须满足块存储的所有特征，能够支持通用负载，这样才能尽可能避免分布式存储底层的不兼容而导致数据库丢失IO，出现坏块，引发数据安全的故障。在云主机的物理机上直接连接集中式存储用于存储数据库的文件也是一种在云平台技术无法满足大型关系型数据库需求时的一种常见做法，当年在数据库迁移到VMWARE资源池的时候已经有不少企业试用过这个方法，效果还不错。无论使用哪种方法，确保IO的可靠性和稳定性是关键。IO不能丢失，IO延时必须稳定，并且最好不高于20毫秒，是云平台必须为大型数据库上云提供的保证。
另外一个方面是网络，对于集中式数据库还好，网络问题不突出。对于Oracle RAC这样对于集群网络性能和可靠性要求十分高的场景，网络要求就很高了。另外分布式数据库对于集群网络的性能与延时也是十分敏感的，必须为集群网络提供高带宽，低延时的虚拟网络支持。实际上普通的大型数据库对于网络也有较高的要求，存储网络（使用IPSAN的场景）、备份网络的带宽和延时决定了数据库是否有足够的性能和易于运维管理。
除此之外，数据库的前端连着应用，后端连着数据中台，还和其他云上云下的业务系统保持着复杂的关系，因此对于云上的转发路由器TR也有十分高的要求。而高可用切换、双活等需求又要求VIP能够很方便的漂移。虚拟大二层网络的能力决定了双活是否能跨机房甚至跨数据中心，这些都是要考虑的。阿里云的VPC、CEN-TR解决了这方面的后顾之忧。
对于分布式数据库，还有一个麻烦的事情，那就是云存储的多副本与分布式数据库的多副本之间的多重副本机制带来的问题。很多企业的分布式数据库在云上是跑在云存储上的，二者的副本机制会产生很高的叠加效应，既浪费了存储资源，又影响了数据库的性能。较为大型的高负载的分布式数据库在云上部署最好采用裸金属部署的模式，如果必须使用云主机，可以考虑使用集中式存储或者使用单副本的云存储。
