关于OpenStack孵化项目trove(DBaaS)之我见

          转载请务必注明出处及链接，谢谢！

          说起来DBaaS使用云计算的用户都不会陌生，亚马逊云、阿里云等都提供了该服务，试想有多少网络服务能撇开数据库呀。

          最近一直在搞trove这块，实话实说设计的过于简单，与实际的应用场景严重脱节，且整个项目参与开发的人员很少，推进比较慢，只怕是在2014年难以实现成为OpenStack核心项目的目标。这里说它的过于简单也许有些过了，毕竟任何一个项目都是从无到有，然后慢慢发展起来的，我这里只从我的感受出发，只是我的主观意思，并不能以这一句话否定了那么多无私的开发者、贡献者的劳动。

        首先说下trove整个服务的构成，整个trove由四大部分构成，虚拟机服务、trove-api、trove-taskmanager、trove-guestagent，其中虚拟机服务包括compute和volume服务，至于compute服务具体是由kvm、lxc、xen等哪个来提供，trove并不关心，当用户请求创建一个数据库实例时，虚拟机只要能提供运行数据库服务的环境即可。trove-api接收用户的各种请求(数据库实例创建、删除、备份、重启等)，通过rpc消息队列与trove-taskmanager服务通信(这一点与OpenStack的其它系统一样)。trove-taskmanager是实际的服务管理器，负责管理一个请求任务整个过程，主要是与nova-compute通信创建compute、与cinder-volume通信创建volume、与trove-guestagent通信在虚拟机内完成包括启动数据库服务/创建用户/初始化数据库/备份数据库服务/重启数据库服务等等操作。trove-guestagent是运行与虚拟机内完成数据库操作的“机器人”(具体任务由trove-taskmanager下达)。

        trove项目的帮助文档详细的介绍了整个项目的安装、示例，提供的镜像是供给kvm使用的qcow2镜像，下载下来后可以直接上传到glance进行使用。

         从以上来看，trove提供的服务基本上能满足DBaaS的要求，提供数据库服务。但我们从实际的应用做如下考虑：

         1、kvm的cpu、memory、io能力与物理主机相比，会有多大的性能损失？

         2、创建一个实例就新建一个kvm虚拟机，这个是不是内存消耗有点大？

         3、数据库的高可用需要用户通过手工的配置来保证，小白用户怎么办？

         4、没有提供只读实例，还是要用户手工配置，小白情何以堪？

         5、单实例物理主机宕机数据可以恢复多少呢？

         6、用户不调用备份接口，难道就永远不做备份？

         7、高可用实例的主挂掉后trove能进行容错处理吗？

         8、trove的实例有监控不？

         ..............

         好了，有了以上这些考虑我回过头来在看下trove当前的情况，它是不是有些简陋？因为有太多的事情我们需要手工的去做，而且数据库服务的性能还得不到保障。

         拿出其中一二说道说道，创建高可用的实例，应该是无可厚非的吧？不好意思trove暂时还没有，只能敬请期待。那我们创建两个实例吧，创建完了手工配置一下？当然可以啦，给管理员找点事情干吧，不让他部署数据库服务已经给他减轻很多工作了，ok管理员大哥很不情愿的把活干了，心里一直不爽，这是什么破服务，还要手工配置？某天晚上，管理员大哥高枕无忧的睡着觉，正梦到与某美女偶遇，突然手机响了，把管理员惊醒，一看是老板的电话，怎么回事？数据库服务挂了？不能吧，那可是高可用的呀，赶紧电话运维同事，大家挑灯夜战呀，原来机房一台部署nova-compute服务的节点挂掉，悲剧的是居然高可用的数据库服务是在一台物理主机上创建的.......

       原来高可用不只是要配置一下两个虚拟机中数据库复制关系那么简单哟，从根儿上就要能支持主从不能在一台物理主机上！不好意思啦，现有的接口没有提供创建实例忽略某个物理主机......

        不仔细推敲则可，仔细推敲，现在的trove是不是还差点儿味儿？咖啡是煮好了，咖啡伴侣没有，咖啡糖没有......

        路还很长，以trove目前参与开发的人数和开发进度而言，只怕是很难实现2014年将trove推成OpenStack的核心项目。