坚决走容器化之路，oceanbase 助力某运营商打造 iaas 监控数据底座-c7电子娱乐

背景：数字化进入关键期，业务需求不断升级

作为上海中心的核心部门。我们运维团队主要负责管理和维护一百多套it系统，以及承载着1.3万台主机庞大集群的监控任务。这些主机中，不仅有高效的数据库服务，还涵盖了物理机、虚拟机，甚至是仍在“服役”的老旧设备。我们致力于保障这些系统资源的稳定与高效，为运营商的业务发展提供坚实可靠的c7电子娱乐的技术支持。

在公司运营平台数据化升级的大背景下，我们拥有几个关键数字。

第一个关键数字：1.3万台旧主机。我们目前拥有1.3万台主机，预计到2025年底，这一数字将跃升至2.5万台。这一显著增长，背后是系统对安全和可信的要求，意味着从硬件cpu到软件组件，再到业务层面，都将迎来全面的升级与替换。

第二个关键数字：2.5万台新主机。老旧机器需要逐步淘汰，新机器则需不断上线，2.5万台新主机是业务扩张、技术升级的真实写照。然而在这个过程中，我们也同样面临着维护与新开的双重挑战。

第三个关键数字：8个黄金监控指标。鉴于我们维护的主机数量庞大，监控压力也随之增大。因此，我与领导及iaas专家共同精选了8个基础且核心的监控项，如cpu、内存等。虽然监控项数量有限，但乘以我们庞大的1.3万台主机后，情况就变得复杂了。有些主机上运行了众多docker容器，或作为数据库主机挂载了十几个甚至二十多个硬盘。这些文件系统、docker容器等都会生成大量的虚拟网卡和文件目录，导致单台主机的监控项数量急剧增加。综合这些因素，我们的监控系统中目前超过了200万个监控项。

第四个关键数字：156万次。这是我们系统每秒钟对服务器的请求量，高达156万次之多，展现了系统的高并发处理能力。值得强调的是三个关于时间的重要数字：1分钟内必须发现故障，5分钟内要定位故障，10分钟内要解决并处理完故障，确保业务快速恢复正常。

挑战：数据库处理能力不足导致多次故障，快速恢复成难题

与此同时，我们也遇到了一些挑战。我们希望全面实现server、proxy及db的容器化部署，并于去年12月在8个黄金指标基础上新增了时间监控与重启uptime的监控需求。为高效应对这些监控任务，我们采用了zabbix的被动模式，并直接应用其官方模板。这种方式优缺点明显。

优点：大大简化了我们的工作：无需自行编写脚本，节省了大量时间和精力，显著提升了工作效率。更重要的是，官方模板的精准性确保了我们能够更迅速、更准确地实现所需的监控功能。

不足：误告警增多：原先使用的是postgresql数据库，多次遭遇批量宕机的误告警问题，主要原因是数据库处理能力不足，导致系统压力巨大。一旦宕机，恢复过程长达七八个小时，非常影响业务。而且问题通常问题发生在半夜，为了保证系统的稳定性不得不夜间重保。

由于这些原因，我们一度面临1.3万台主机监控的缺失，造成了监控的空白期，极大地增加运维工作的复杂性。特别是随着服务规模的不断扩大，预计2025年底主机数量将持续增加，传统的监控数据管理方式正面临诸多挑战。

• 首先，数据量的激增是一个显著问题。
• 其次，硬件资源也成为瓶颈，尤其是如果我们使用物理机来部署核心生产系统，通常采用主从三节点的模式，这对数据库主机的性能要求极高，往往需要配备闪存卡。
• 再者，实时性的要求也日益严格。就像前面提到的监控系统，要求在一分钟内发现故障，这对系统的实时响应能力提出了很高的要求。
• 最后，性能与系统的稳定性也存在挑战。在面临高并发数据量和大规模数据处理时，传统数据库在虚机或容器化部署中的稳定性存在不足，这直接影响了服务质量。我们的目标是利用多台低性能的虚机，并通过容器化部署来支撑上海中心的1.3万台主机需求。简而言之，就是先实现虚拟化，再在此基础上进行容器化，即“虚上加虚”。这一要求极为严格，我们必须确保这一方案的稳定性和高效性。

探索：坚定不移容器化以及系统优化

对于上述挑战，起初，我们着手调整了监控项的采集频率。具体操作包括：

1、调整采集频次。我们将某些监控项的采集间隔从原来的一分钟调整到了三分钟、五分钟等。

2、修改代理数据库的连接数。我们之前在部署时，没有调整过proxy上zabbix原生postgresql的配置。后来，我们根据官方文档，将其最大连接数调整到了2000。

3、对个别触发器进行了优化。在查看server日志时，我们发现某些postgresql库在插入数据时，触发器包含的c代码行数很多。因此，我们尝试先禁用这些触发器，以观察效果。仍然出现了批量误告警。底层表现为postgresql数据库压力大，处理速度慢。

初步调整的效果并不理想。业务侧的表现是批量主机宕机或误告警，原因是监控项的数据无法成功写入到server上。正常情况下，数据应先被写入数据库的表中，然后根据触发器中的sql语句来判断哪些监控数据超过了阈值，从而触发告警。然而，如果数据无法成功落表，触发器就无法进行判断。当数据延迟超过一定时间，比如一分钟或两分钟，系统就会错误地认为这是一个宕机误告警的情况。这就是最外层的业务表现。此前我在zabbix的社区群咨询，了解到我们有1.3万台主机，都表示震惊，但他们也没有更好的解决办法。那时，我们甚至考虑过是否应该放弃容器化。经过内部讨论之后，我们认为应该坚持探索容器化这条路线。原因在于：首先，我们的监控系统即使暂时挂掉，也不会对业务造成太大影响，只是监控平台会出现一段空白期；其次，我们还是应该勇于探索，追求技术上的进步和升级。

因此我们开始对系统进行二次调优。

1、服务拆分：将这一万多台主机按照科室拆分成5套服务器。拆分后，每套服务器大约负责2500台机器，这样的规模容器化是能够承载的。拆分工作在六月完成，之后每套服务器的性能都表现得非常稳定。

2、初告警平台：我们还开发了一个初告警程序，它在监控系统上触发动作后，会生成告警信息，并将这些信息发送到一个汇聚平台，再由短信网关进行调度和发送。

经过本次系统调整之后，问题得到缓解。不过最根本问题即底层数据库处理能力不足问题仍然存在。

选型：oceanbase与postgresql的压测性能

目前我们zabbix存储面临的主要问题是：

• 扩展能力受限。当主机规模增加的时候，采集到的监控数据会越来越庞大，对当前 zabbix 的postgresql存储来说是一个挑战，无法满足存储的弹性扩展。
• 性能不佳。在 agent 采集数据入库之后，系统根据配置告警条件进行查询时，指标数据返回慢甚至超时产生大量的误告警，影响业务判断。
• 容灾能力不足。集中式数据库在日常情况下容灾能力有限，故障发生率高。

我们决定进行深入的调研和选型工作，以寻找更合适的c7电子娱乐的解决方案。我们对数据库的要求大致分为六点。

第一， 系统需满足高性能要求，具备大规模数据处理能力并保证高效的查询响应时间。

第二， 系统需具备强大的容灾能力，包括自动恢复能力，确保服务的持续可用，并支持多租户模式。

第三， 系统应打破存储瓶颈，考虑到主机数量未来必然增加，需具备虚机水平扩展的能力。

第四， 系统需与zabbix兼容，支持作为后台数据库存储配置数据和历史数据，实现功能上的无缝对接。

第五， 系统需符合国产和安全等级要求。

第六， 要求具备容器化部署能力。这里并非要放弃容器化，而是能够复用当前的容器化环境。

经过调研与筛选，我们认为oceanbase可能符合选型要求，因此对oceanbase与postgresql进行了压力测试，对比了两者性能。一方面，我们测试了oceanbase的容器化数据库；另一方面，我们也进行了性能对比测试。结果显示：

• 在qps等各项指标上，oceanbase均优于postgresql，32线程下，oceanbase的只读性能是postgresql的16倍，oceanbase的延迟只有0.09ms，而 postgresql 是 2ms。
• oceanbase容器化和非容器部署对比，容器化的qps略高于非容器化的，但是各项延迟都高于1。
• 至于实时性要求，要求高的系统用非容器部署更合适。而容器化部署虽然前面提到了一分钟的延迟，但实际测试中差距很小，仅几十毫秒延迟，这是可以接受的。即使是100毫秒的延迟差距对于监控系统来说，也完全可以忽略不计。

oceanbase容器化部署的管理功能相当全面。首先，它提供了集群租户管理功能，方便用户高效管理多个租户和集群。其次，备份功能确保数据的安全性和可靠性，而ob-operator则能自动管理数据库进程，减轻用户负担。另外，监控功能通过图形化仪表盘直观展示数据库状态，让用户一目了然。同时，终端连接功能允许用户在web界面直接编写sql语句，极大地提升了操作的便捷性。

该部署方式还支持自动故障恢复和弹性伸缩，确保数据库的稳定运行和灵活扩展。特别是，它集成了kubernates集群管理功能，方便用户进行集群的部署、管理和维护。滚动升级和替换功能则使得数据库升级和替换变得更加简单、安全。

落地：使用oceanbase zabbix未曾出现故障

经过测试后，oceanbase符合我们的要求，便很快实施oceanbase zabbix方案。总的来说，使用效果让我们非常满意：

• 性能表现异常稳定。自九月份上线以来，即便在1.3万台主机的规模下，也未曾出现过故障。数据库磁盘的io响应时间始终保持在10毫秒左右，展现出卓越的性能。
• 用户界面友好度大幅提升，为用户提供了更加直观、便捷的操作体验。
• 高可用性方面达到了新的标准。故障恢复时间已缩短至秒级，确保监控系统的实时性和稳定性。
• oceanbase与zabbix的兼容性极高，底层数据库从postgresql替换为oceanbase之后，zabbix不需要做改造，实现了无缝衔接，大大降低了迁移成本和风险。

谈效果离不开聊收益。我们目前使用的是oceanbase社区版，节省了一部分成本。同时，社区版的支撑力度非常强大，在我们的使用过程中给于了充分的支持。

oceanbase社区版也提供了直观的页面工具，让我们使用和维护变得非常简单且容易上手。这极大地提高了我们的工作效率。最重要的是，该系统具备出色的数据压缩功能，能够有效节省磁盘空间，进一步降低了我们的存储成本。

此外，在运维管理方面,：

• 部署极为便捷，我们选择的容器化技术栈在 oceanbase 得到了完美的复用。仅需提供镜像和yaml配置文件即可完成，大大简化了操作流程。
• 容灾能力出众。系统能够自动检测数据库节点故障，并迅速恢复，这是容器化部署带来的显著优势。同时，系统还具备良好的扩展性，未来可根据需求轻松增加主机，实现横向扩展。
• 特别值得一提的是，我们的监控数据处理方式与众不同：监控数据无需数据割接，也不存在平稳过渡的问题。我们只需确保下一秒的监控数据稳定、可靠即可。
• 界面化运维也是一大亮点。通过直观的界面，非专业运维人员也能轻松进行展示和操作，提升了运维的便捷性和实用性。

最后总结我们在运维过程中，遇到的两个较为显著的问题及解决经验，供大家参考。

第一个经验：磁盘性能至关重要。

当部署迁移的虚拟机数量超过7000台后，我们观察到oceanbase主机的i/o负载异常高。由于这些虚拟机均为云主机，其i/o响应时间普遍超过了300ms，这对系统性能产生了显著影响。

为应对这一问题，我们与云服务商进行了协调，并成功引入了极速型ssd作为支撑。对于像oceanbase这样的数据库应用场景，虽然不一定需要采用最高规格的闪存卡，但ssd盘的引入无疑是必要的，以确保数据库的性能和稳定性。

因此，建议大家在生产环境中按照 oceanbase 的要求使用 ssd 盘，否则很影响集群的性能。

第二个经验：通过odc工具对大表分区。

在运维过程中，我们遭遇了一次与oceanbase无关的故障。问题的根源在于我们对zabbix数据库中的history表进行分区或数据切割时，未能充分预见潜在的问题。这个表主要用于存储性能数据，而在部署上线后的短短两周内，其数据量就激增至50亿行。

为了应对这一数据膨胀，我们最初选择了清空表作为临时c7电子娱乐的解决方案。然而，当系统再次出现性能瓶颈时，我们错误地沿用了之前的做法，再次清空了history表，修改了表结构。这一改动引发了严重的后果，导致前端系统无法删除或添加主机，新开设的主机也无法接入系统。这一故障对我们的业务运营造成了极大的困扰。为了解决这个问题，我们不得不投入4名工程师，耗费一周的时间，将所有1.3万台虚拟机重新迁移到新的服务器上，相当于对整个数据库系统进行了重建。

最后，在oceanbase专家的建议下，我们对zabbix中的7张数据量庞大的表进行了日分区处理。这一处理过程非常便捷，通过odc工具即可在页面上直接完成。此举有效降低了数据快速积累可能带来的性能风险，从而确保了监控系统的稳定性。