私有云下实现中间件数据库服务资源池化的可行性

虚拟整合的前提是可接受的隔离度。比如，iaas下虚机间天生就具有相当的隔离度，不同的操作系统，独立的root用户，具有大多数独立物理机间互不干扰的隔离功能。但是，如果是PAAS层或SAAS层的WEB或DB共享池，那恐怕没有可以适用于大多数需求的原生隔离度吧。收起

银行业私有云已经进入成熟阶段，很多银行都已经有了落地的方案。如果按照私有云的几个层次划分，实现服务器、网络、存储资源池化属于IAAS范畴，也是高层次服务的基础，案例非常多，技术上的问题基本上都解决了。
楼主提到的中间件、数据库，还有WEB服务，都需要基于IAAS构建，至于说叫PAAS、DBAAS都不重要。WEB和中间最容易实现云化，可以简单利用Apache或者WAS、Weblogic的集群功能实现云化，以WAS为例，用户提出中间件的性能需求后，云平台可以根据标准的中间件服务能力进行估算，最终分配给用户若干个WAS运行环境。
DB服务基本上是按照自动化供给DB服务的方式实现的，不过实现起来会比中间件复杂很多，因为有创建实例、创建数据库等操作收起

企业服务中间件有一个问题，很多中间件不支持多租户隔离，比如数据库中间件，这块对于内部业务整合是个风险。。。。这块有自身就支持多租户的中间件吗？收起

在传统的云计算建设过程中，往往解决的是底层硬件资源的集中管理和虚拟机粒度的资源调度。无论是vmware、IBM或者OpenStack的产品，降低的是IT基础设施部门对于虚拟机的管理成本和运维成本。除了缩短机器申请周期，IT部门运维和管理的中间件、数据库等组件和服务的管理和运维复杂性仍然没有得到有效解决，导致云对于效率和成本的改善效果非常有限。

设想一下，开发、测试和运维部门基于共同的配置控制台创建、配置云端的中间件和数据库，无需逐台登陆到机器上进行手工配置；开发提交的版本包可以很轻松地发布到云端的中间件和数据库，无需考虑发版的操作细节；云平台自动监控应用的运行日志并预警，不需要运维人员再手工搜索日志错误——开发、测试和运维的效率才能真正得到极大的提升。

因此，我们建议，研发中心在考虑云时应该着重着眼于PaaS云的建设目标，最终聚焦于研发部门真正关心的IT组件和服务，比如中间件和数据库，将这个作为研发云的管理边界和外部服务接口。企业的云计算建设规划应该包括三个阶段：
1. 底层的硬件资源统一管理和虚拟化管理
2. 标准IT服务的管理，如中间件和数据库的弹性配置
3. 应用程序的架构云化以及基于云的应用平台，如大数据平台

对于第二阶段，当下流行的DevOps可以说就是一剂良药——配置管理、自动化发布、智能监控等帮助企业很好地完成标准IT服务的管理。

“互联网＋”的东风驱使越来越多的业务创新出现，研发企业也面临越来越大的挑战。如何提升弹性和可扩展性，同时实现快速交付的目标，DevOps和针对IT服务组件的PaaS将成为企业必须建设的能力和平台。收起

我个人认为，目前存储、网络、服务器的资源池化逐渐落地，归纳起来，基本上实现了两点。第一，无论是同构还是异构的，通过对物理资源的整合，提高了现有硬件和软件的利用率，避免了新一轮的采购，从而提高投资回报率 （ROI）；第二，对响应当前应用系统的快速上线及业务系统运行性能等方面，虚拟化能提高IT系统的灵活性。然而，对于中间件资源池化的想法，应该是不太新鲜的事了，因为中间件充当了应用层和资源层之间的桥梁，应用层的多样化必然会给中间件层带来更多的挑战：首先，中间件层如何支持各种不同功能的应用？比如，应用是历史遗留的程序，使用特殊的协议，或者其它特别的需求，在涉及资源池化时就需要考虑清楚，哪些应用能够运行在动态环境下，哪些应用必须运行在特定的服务器上；其次，如何在运行的生产环境中及时响应不同级别的应用程序，有的应用非常重要，例如核心应用，必须保证这类应用的请求能得第一时间有效地响应；有的应用重要，但在一定的可容忍的时间内响应其请求即可；有的应用可在后台运行，优先级相对来说比较低等等情况，这此在设计资源池时也得考虑清楚。还有一些我考虑不到的情形，面对这些挑战，我们需要综合考虑，我们的中间件资源池设计的得既能拥有虚拟化带来的资源共享等的优势，又能满足应用不同的需求，我觉得任重而道远。另外，对于数据库的虚拟化，也许会跟随大数据的步伐慢慢出现。收起

个人理解，这个是可以实现的，当然实现的人员，首先不是open的团体，肯定是厂商能够实现。那么既然是厂商实现，那么就要看客户对应用中间件或者数据库中间件这个云平台的需求如何，同时愿意为实现这个需求愿意花多少钱去购买了。谁知道ibm或者oracle是不是早就研发好了这类技术，只是等待着到客户愿意掏钱购买的时机，在推出产品来呢。收起

传统的资源池，主要考虑到的是资源的申请和释放，尽量快的响应请求，保证切换时回话数据的完整性。对于会话的访问安全和资源隔离，QOS等没没有考虑太多。但是云计算环境下的资源池必须考虑这部分的处理，所以应该分两步走，凭借底层设施的管理能力完成QOS是比较合适的选择，在这之上，我们再
通过中间件的集群能力进行再次组成虚拟化的资源池。收起

中间件和数据库服务的池化，是一个比较大的工程。应该分步骤把不同类别的应用所使用的中间件和数据库应用迁移到云上。一个应用的中间件集群可以放在虚拟服务器上，数据库也可使用Oracle12C实现多租户的资源分配和池化。但这一切都要做测试，才能评估和充分满足应用的需求和可持续发展。收起

看到上面大家的讨论，我觉得对数据库在资源池中的部署有不同层面的理解。我觉得数据库部署到资源池中，不一定就是要建立一个数据库池。数据库也可以同其他应用共享资源池中的资源。其所需资源无外乎计算、存储、网络。建一个虚机然后在共享存储池中分配给其高性能的存储空间，再加上足够的网络带宽就可以了。这些资源可以按策略与其他虚机共享，同时保证其性能没有瓶颈。当然，这要看您的虚拟化平台是否能支撑足够的性能需求。如果只是建立了近线级别的存储池，那当然不容易支撑在线的数据库运行需要。收起

回复 7# tong2012


    倒是没有这么夸张，这块工作我们都开发完成了。收起