甲骨文的Engineered System一体化产品家族三剑客，以Exadata起家，目前已经发展到本地专有云平台-Exadata Cloud@Customer和数据库零数据丢失保护平台-Zero Data Loss Recovery Appliance RA21，在国内都有不少客户部署。Exadata已经有十多年的发展历史，它的特性是经过众多客户验证的，下面我们对Exadata和ExaCC在客户使用感受与大家分享。

UNIX+SAN迁移到Exadata，实现应用透明横向扩展和极致性能

之前的微信文章曾经讲过几个Exadata极致性能、横向扩展和高可用性的独特创新。但是可能会有人会说，仅看到这样技术原理，是不是太广告了，是不是有夸大的成分。那今天笔者在这里就用一个真实的客户从POWER UNIX服务器+高端SAN存储的两节点RAC，而且客户原来一直坚持RAC必须进行应用分隔，以避免节点之间的GC通信带来的性能问题的核心系统“OLTP”迁移到Exadata上，实现4节点负载均衡；并且让很多人误以为Exadata的SQL offload只有对OLAP/DW才起作用，然而在“OLTP”实现加速的真实案例。

这套支撑着某客户核心交易系统，原来采用的是典型的IOE架构，两台高端E880，单机128 POWER 8核心。之所以如此大的配置，是因为客户早年使用RAC时，互联只有千兆网络，导致跨节点通信延迟较大，带宽不高，因此客户希望通过应用分隔，两个RAC节点业务是处理不同的数据，降低通过GC跨节点数据传输导致的性能下降。这样的结果也导致一个重要的容量估计依据，就是如果一个RAC节点损坏情况下，剩下的单个节点在算力上能承受全部业务，这也导致了日常数据库服务器的CPU负荷不要超过45%成为了一个很重要指标。

在迁移到Exadata后的架构上，从RAC on Exadata的特点-应用透明横向扩展考虑，给出的建议是不用再考虑应用分隔，直接4节点负载均衡，所有应用采用SCAN（Single Cluster Access Network）连接，如下图所示：

这样做的好处是多方面的：首先，能实现多节点负载均衡而且修改应用配置，将来在处理能力不够的情况下，增加数据库节点即可（当然IO能力不够增加存储节点即可），完全对应用透明；单个硬件节点故障后，负荷在剩余节点自动负载均衡，避免一旦单节点故障，1对1接管会导致剩余节点连接暴增而导致的连接风暴；同时这样由于负荷在剩余节点平摊，对于4节点来说，峰值负荷不超过70%情况下单节点DOWN机也不会超过剩余节点总体能力，可以让硬件有更高的利用率。

当然，采用这种架构最大的挑战就是在负载均衡的情况，跨节点GC会不会影响应用性能。从传统大家采用UDP+以太网运行RAC的经验来说，即便采用了10GE，不进行适当的应用分隔就很容易影响系统的吞吐量和响应时间，因为本质不是带宽不够，而是跨节点通信的延迟几百微妙甚至毫秒级别，比本地内存延迟慢上千倍。另外，由于和核心OLTP应用，其他这样的应用使用Oracle数据库都是用全闪存的解决方案满足业务的SLA，而这里的Exadata 8M-2主存储还是7200 RPM的硬盘，究竟Pmem Cache和Smartflash Cache的加持能不能满足业务要求也成了某种的担心。那迁移到Exadata上以后的情况究竟怎样呢，这里是实际生产的AWR截图:

我们可以看到，通过Exadata上Exafusion互联协议的加持，在单节点超过200MB/S的双向收发流量的压力下，跨节点Exafusion ping通信延迟在<10us，这样才保证了虽然我们看到GC等待仍然存在，但是对应用性能的影响完全可以忽略，实现了应用透明的横向扩展。Pmem Cache和Smart Flash Cache的加持让数据库单块读端到端平均等待降低到<100us，明显比其他全闪存的存储还要快几乎一个数量级。而且这个典型的OLTP应用，居然88%的IO流量是因为全表扫描所导致，而这部分的压力大部分offload到Exadata存储进行处理，降低了存储访问的网络流量，加速的大查询的处理速度，而且也降低了数据库服务器CPU负荷。从本质的要应用负载来说，不可能真正所有数据访问都应该使用索引才是最优的纯OLTP系统，即便OLTP应用，实际也少不了类DW/OLAP查询的存在。

通过上面这个真实生产的案例其实不难发现，Exadata利用起架构上和工程设计上的革命性创新，让复杂OLTP的应用透明高性能横向扩展成为现实，而且解决了所有OLTP应用中都存在的混合负载支持，并且保障了应用的服务质量。

ExaCC：体验Exadata的高性能+云

Exadata Cloud@Customer，简称为ExaCC，不仅仅具备Exadata自身的极致性能，极致可靠性和横向扩展能力，还把真正的DBaaS的云能力提供给了客户。尤其对于由于安全、应用响应时间和数据主权要求不能直接使用公有云的客户，在客户现有的数据中心和防火墙内部提供了完整的Oracle DB As Service的能力。这其中的云能力包括：基于订阅的付费、基于按秒的数据库集群OCPU算力计费、在线动态修改集群算力弹性云能力，基于云的基础架构自动运维、基于云的安全加固、基于web GUI/API/CLI的云自动化能力等等。

在这里的另外一个客户，就是通过基于ExaCC X9M的专有云平台，享受了这样的高性能+云的体验。某公司其核心应用几乎全部采用了Oracle套装软件支撑，整个公司的日常运营都依赖这些应用的支撑。和绝大多数应用一样，所有的应用对数据库的压力都存在明显的波峰波谷的情况，如下图所示:

基于这些情况，Oracle建议采用新一代基于OCI的Exadata Cloud@Customer X9M-2作为新的支撑套装软件数据库的DBaaS解决方案，提升弹性、云自动化服务等多方面提升业务SLA。同时，新一代的X9M-2，相比该客户原有产品，采用了基于KVM的云虚拟化方案，配合新的部署在存储节点的持久化内存，以及更多的最大弹性算力，即便相同OCPU的算力相比原有产品的巨大提升，在性能上也能更好满足业务要求。另外，由于套装软件都要求提供比较完善的UAT测试环境，基于GEN2云的ExaCC X9M-2的云自动化也能更方便地提供生产、容灾、UAT等多套 DBaaS环境。

整个项目涉及了多达6套生产应用+容灾环境，每套生产应用还有自己对应的UAT测试环境，从原有的OCI-C架构迁移到新的基于OCI的Exadata X9M-2，从到货到全部投产只用了不到120天，期间还充分利用了Oracle的Cloud@Customer进行硬件更新时运行的免费过渡期，充分降低了TCO，客户也非常乐于接受这样基于云的消费模式。

整个项目迁移到Exadata X9M-2以后，客户明显感受到两个收益：首先就是核心应用吞吐量和响应时间的明显提升

如上图所示，在旧的架构上，受限于技术和其他原因，随着客户业务的发展，业务量相比刚刚投产的2019年巨增，在2022年尚未迁移到新架构的最后一次月结可以看到核心EBS数据库的active session数量暴增到600多以上，系统大量非CPU等待事件，严重影响应用的性能。而新的架构，云的弹性则只受限于专有云硬件能提供的最大算力，在月结期间直接通过API在线弹性扩容数据库集群OCPU达到248 OCPU。这时候可以看到EBS的数据库active session直接变成健康的120以下，而且等待事件几乎都是CPU，是最健康的状态。当然，这也是因为在X9M-2 ExaCC上有持久化内存PMEM的加持，对IO又有了巨大的加速。

到了这里，可能有人会疑问，增加了那么大的算力，对于云来说就会消费多了啊？这里恰好就利用了ExaCC的更好的弹性的能力，在这里通过提供给客户具备一个监控VM CLUSTER内部各种指标能力的工具，能够做到按照业务需要，弹性的挑战云订阅的算力。而且在ExaCC上，OCPU算力的计费是按秒计费的，也就是说，一旦降低了VM CLUSTER的OCPU，计费立刻就便宜了。在线动态调整VM CLUSTER也做到应用完全无感知，而且能很快地在分钟级别迅速完成，真正做到了云弹性和云消费模式。

这样就真正做到云上支撑IT系统的好处能实现，  “削峰填谷”，将闲时节省的CPU用到繁忙的时刻， 精准掌握CPU资源的使用情况，及时发现异常情况，快速响应负载变化，平均1-2分钟内完成调整。

总结一下关于ExaCC在客户使用的感受，不仅仅享受到Exadata的极致性能、可靠性和可扩展性，还在自己的机房内部享受公有云的消费模式，云自动化，让企业应用的云转型更加简单和容易。

• 编辑：黄沛

*活动最终解释权归甲骨文公司所有