沃趣科技—容器化RDS(一)—未来已来-熊中哲

“你不是不够好,你只是过时了”这句话用到IT行业特别合适,每隔一段时间都会有新的技术出现,让码农们应接不暇.借着回顾DBA工作中的几个时期,跟大家分享我们对下一代数据库运维架构的理解和目前正在做的工作.明星DBA层出不穷的时期刚进入阿里时听过一句话一直记到现在,”要像了解自己的老婆一样了解自己管理的数据库”,当年我还没有结婚,对这句话的理解并不深刻.这应该是@冯春培说的,当年进阿里的面试考官之一,大家都服气的称他为大师它后面其实隐含了1个背景.相比现在,当时的应用迭代较慢,架构集中,尤其是数据库层面.用比较流行的叫法是巨石型”monolithic”应用.在数据库数量,容量和业务需求都没有爆发的情况下,更需要DBA做出极致的优化,更强调对数据库内核的掌握,10年前混过ITPUB的都知道,当时的DBA都是以写出极其复杂的SQL和掌握Lock,Pin,Latch运行机制为荣的.还记得,当年每条SQL上线都需要DBA审阅,这也是DBAshowmuscle的最好机会巨石型应用突出了DBA的重要性,那是一个明星DBA层出不穷的时期.DBA的转型期后来有机会去了百度,作为一名DBA,给我的冲击很大,总结下来有几个不同:●数据库以MySQL为绝对多数,并且大多数都是由开发自己运维.●DBA团队刚刚组建,目标是集中管理集团的所有数据库.当时整个团队不到15人,线上运行的MySQL实例1000+.●没有SQLReview1000+实例和15个DBA,这时我刚结婚,虽然时间不长但我马上意识到”要像了解自己的老婆一样了解自己管理的数据库”恐怕是做不到了.工作的重点不再是学习数据库内核和SQLReview,而是转而将大量的日常运维工作脚本化,自动化(其实是人肉+半自动).当时没有Puppet/Ansible,一刀一斧都得自己来.不得已,又捡回编程的手艺.这个时候,我从关注少量库的性能(Load,TPS,QPS),到关注大量库的可用性,主要包括:●监控的配置和有效性●空间是否足够●备库恢复是否正常●是否有备份,备份是否有效●硬件是否有故障没有SQLReview这样奶妈式的贴身服务,如何解决性能问题呢?总结下来就是:●将复杂的SQL拆分成多个简单的SQL,将复杂性留给应用●提前做好ScaleOut架构,性能不够就扩节点多说几句:●ScaleOut:要支持ScaleOut架构,应用需要做些改造.说一个常见问题,MySQL集群的各个分片如何高效的,不重复的获取自增序列作为表的PK或者UK呢?在OracleRac里面,sequence让一切变得简单,DBA关注的只是如何优化获取sequence的效率.但是在百度,我第一次知道原来可以通过zookeeper来解决这个问题.●监控:当时Noah(百度内部的告警平台)有个功能,一旦发现线上运行的服务器负载低于指定阈值时,将会给相关人发送报警,提示有资源浪费.这个报警追踪了资源的使用情况,有效的防止了资源浪费的问题.●SQLReview:从阿里巴巴集团研究员@张瑞(两个面试官中的另外一个)发表的题为《面向未来的数据库体系架构的思考》可以看到类似的描述我也逐渐意识到对DBA的要求发生了变化.从精细化运维到集群化运维,从关注个别库的性能到关注集群的可用性,从依靠个人的能力到借助监控平台和大量的运维脚本.这是一个转型期,对DBA的要求更综合,更全面.不会当厨子的裁缝做不了好司机.拥抱虚拟化2017年,WoquTech已经成立6年,巨石型”monolithic”应用依然广泛存在.同时,用户对于数据库运维自动化的要求越来越高,数据库即服务(DBaaSorRDS)的需求越来越强烈,AWSRDS有个很精炼的总结:总结一下:●所有的日常运维工作自动化●高性能,数据零丢失,安全的需求依然是刚需●通过弹性扩展追求更高的资源利用率(用我们熟悉的语言就是向运维要效益)●不再追求极致的性能如何能满足这些企业级的功能要求?这并不容易，要对数据库，硬件，虚拟化，分布式存储等技术都要熟悉甚至精通。以此为目标，WoquTech首先基于虚拟化技术实现了一套私有数据库服务平台,这款产品叫做QFusion，目前迭代到2.0版本.同时,我们也面临一些棘手的问题:●计算密度难以提高:虚拟化自身开销较大,导致计算资源的有效利用率不高,这导致客户需要更多的硬件●存储开销较大:存储在硬件(SSD,Optane),网络(25Gb,Infiniband),协议层面(NVMEoF)的发生着翻天覆地的变化,但是虚拟化技术一直支持的不好,开销很大,虽然可以通过穿透技术(passthrough)降低开销,但是又给平台管理带来极大成本.●迭代成本:还是以OS的视角建构系统,导致业务开发的成本较高.奔向容器,未来已来面对虚拟化技术在实现RDS上的短板,我们一直在探索,资源利用率更高,整合效率更高的RDS实现方式.所以我们很早就开始确定了容器化的技术方向.容器技术和MySQL本来就不陌生的,阿里很早就将cgroup应用到MySQL生产环境(Google跟阿里的用法非常类似).Oracle作为商用数据库的霸主,也在github.com上推出12C企业版Dockerimage.当然,在生产环境使用容器并不容易,我们需要解决两个问题:●关系型数据库(Oracle,MySQL)如何高效的运行在容器里●如何管理容器集群以Docker+Oracle为例.针对第一个问题,我们进行了很长一段时间的探索和测试.期望在使用相同Oracle版本,硬件配置,负载模型的情况下,以业务的TPS和QPS为指标,对OracleinKVM和OracleinDocker进行对比.调试了很长时间以确保KVM和Docker都能发挥了自身的优势.IBM在2014年发表的文章《AnUpdatedPerformanceComparisonofVirtualMachinesandLinuxContainers》给了我们很多启发数据如下:通过Oracle的AWR报告,可以很清晰的看到.相比KVM,OracleinDocker的执行次数提高2.47倍,同时运行时间减少55.25%.也就是说基于Docker,不但可以提升一倍的业务服务质量,还能够提高2.47倍的业务吞吐量,优势非常明显.针对问题二,如何管理大规模的Docker呢?就像虚拟化和OpenStack的关系.我们需要容器化时代的“OpenStack”,甚至更多,以调度策略为例:●更细粒度的资源调度单位,更弹性的资源申请方式,以实现更高的部署密度●识别不同级别的存储服务(QoS).比如,主库调度到PCIeFlash节点,备库调度到SATASSD节点,备份调度到HardDisk节点●识别业务需要的非亲缘性.比如,在资源都满足的前提下,主库和备库不能调度到同一物理节点站在巨人(Google)的肩膀上,我们找到了答案:Kubernetes简单说,Kubernetes是自动化容器编排平台().其隶属于CNCF基金会(CloudNativeComputingFoundation),CNCF背后有强大的Google站台.Kubernetes一经推出,被大家接受的速度远超想象.Oracle云服务集成了基于Kubenretes的编排架构微软云服务Azure把自己容器编排引擎从ACS改成AKS通过整合Docker和Kubernetes研发WoquTech下一代的RDS架构即QFusion3.0,成为我们新的目标.目前Kubernetes对持久化应用的支持还刚刚起步,下图是基于Kubernetes构建的持久化服务:可以看到,暂时还没有Oracle和MySQL的身影,基于Kubernetes构建关系型数据库业务的难度也可想而知.下面将会展示QFusion3.0(全部以MySQL为例)几个功能:实例高可用实例高可用必不可少,需要说明的是这个功能必须包含数据零丢失.下面将演示这个过程.我们模拟了四次故障,例如kill,重启节点之类,平均下来都可以在35秒内恢复访问（消耗时间与AWSAurora和阿里云PolarDB持平）同时模拟应用进行持续的数据更新操作,可以看到数据库服务在几次故障切换后始终可以保证更新有序,做到零数据丢失.读写分离集群:读库水平扩展大多数应用都是读多写少,读写分离集群的很好的支持了这类业务场景.当读能力不足时,弹性扩展是DBA经常遇到的问题,下面将演示读库水平扩展的过程.通过YAML文件,以申明的方式一键创建读写分离集群无关内容已省略kind:MysqlClustermasterdbspec:replicas:1--主库数量,读写分离集群中,该值只能为1role:Master--主库角色proxyspec:role:RW--数据库中间件类型slavedbspec:replicas:2--读库数量role:Slave--读库角色strategy:MySQLRWCluster--集群类型通过sysbench+Proxy模拟对3个备库的压力通过我们的平台一键式添加1个备库,可以看到读压力较平均的分散到4个备库中分库分表集群:集群高可用这类集群提供了ScaleOut的能力,相比读写分离集群功能更加强大,同时也带来了运维的复杂性.下面将演示集群的一键式创建和集群分片的高可用.通过YAML文件,以申明的方式一键创建分库分表集群无关内容已省略kind:MysqlClustermasterdbspec:replicas:8--主库数量,指定该集群的分片数量role:Master--主库角色proxyspec:role:Sharding--数据库中间件类型strategy:MySQLShardCluster--集群类型一键式创建8分片集群.模拟分片0故障,30秒内该分片恢复完毕,提供服务.分库分表集群:滚动升级功能集群带来了强大功能的同时提升了运维工作的复杂度.比如,修改数据库配置,替换新的数据库版本,常见的做法就是DBA人肉的一个节点一个节点的完成变更工作.下面将演示全自动滚动升级功能修改集群所有实例的参数“innodb_buffer_pool_size”,滚动升级会:●降序从c7到c0●依次进行:选定节点,修改参数文件,重启节点,待节点恢复服务●滚动升级流程会保证即使出现异常,依然可以”断点续传”,已升级节点不会重复操作5.7.5开始,innodb_buffer_pool_size可以通过set命令动态调整,不用重启数据库实例下图可以看到滚动升级的过程.通过版本管理的方式实现集群的滚动升级,通过集群信息,可以看到status:currentReplicas:8--当前版本分片数量currentVersion:clustershard-c-559586746c--集群当前版本updateVersion:clustershard-c-559586746c--集群待升级版本currentVersion等于updateVersion,滚动升级结束Docker,Kubernetes,RDS,未来已来Everyonceinawhile,arevolutionaryproductcomesalongthatchangeseverything.这是乔帮主在第一代Iphone发布会上说的第二句话.确实,未来已经到来.