第四十四期 数据库的物理隔离
这周干了些啥?除了正常日常工作和协调部署各种新环境和灾备环境以外,有幸于星期三开始被疫情封控在了园区。好的一点呢是目前连续两天全员核酸阴性了,就是不晓得好久才能放出去。
1 背景
本期的内容,其实源自于一位去菊花厂的做售前朋友的提问,是基于Oracle数据库的,如何在多节点RAC环境实现数据库使用者之间的物理隔离。
这里的物理隔离是要实现什么,就是每个数据库使用者使用独立的硬件资源且互不影响;尽可能使用一套数据库底座实现简化管理。
2 Oracle
从Oracle的角度来看,其实用在我刚开始写这一系列文章的那几期内容就能实现。即是多租户+Service+Resource Manager+IO控制。当然,之前的文章写的很散,这里汇总一下。
首先多租户可以实现一套数据库底座的简化管理,维护一套数据集群即可完成多个数据库使用者的管理。其次使用Service来控制这些租户PDB的节点运行状态,让每个节点仅运行一个或极少数PDB,这可以让某些私网连接仅在某些节点之间交互,并在集群已分配节点以外预留一些备用节点。RM和PDB的IO控制可以让某些运行多个小业务PDB的节点上隔离这些PDB的物理资源,这里面也可以在PDB级别加上CPU_COUNT。
针对一般的使用共享存储的架构,为了避免全局IO的争用,还可以将PDB分配在独立的磁盘组中,可以使得这些PDB在所运行节点上仅使用分配给自己的存储LUN的IO链路。
3 分布式
其实分布式数据库最大的优势就是在于节点很多,如果都是使用的物理机,那么每个物理机的资源都是物理隔离的,在集群规划,可以按照业务把一组服务器分给一个业务,相当于在一个大的集群里面嵌套几个分布式集群,管理就相对复杂了很多,但是基于现在大多数分布式数据库都有比较完善好用的管理工具,其实也还好。
但是如果节点是基于虚拟化或者容器,即可能出现一个物理机上运行多个容器的情况,在当前一般使用Cgroup是无法有效隔离IO的,所以。。。
4 终极大招
我只需要100个单位的数据库能力,但是数据库环境提供一个小目标的数据库能力。这个你知道我说的是啥。嘿嘿!只要基础环境能力够,其实也不存在隔离不隔离的问题。
总结
老规矩,知道写了些啥。