基于生产系统虚拟化资源池进行核心数据库的架构设计难点在哪里？如何解决？

1、资源的隔离（如cpu和io），很多时候数据库是一个高IO消耗的应用，但是在虚拟化的时候，资源隔离和调度就是一个难点
2、未知的BUG，因为虚拟化导致的各种失败、丢包等等。。。
3、部分优化，因为有时候的优化会直接针对内核参数，但是由于多了一层虚拟层，部分优化会失效甚至反而影响性能

综上所述：测试环境和非核心的系统可以放在虚拟化上。生产还是用单独的物理机更好。另外有些os和数据库也许会有对虚拟化定制的版本。

1. 要弄清自己的需求，虚拟化的目的是啥；
2. 了解自己的系统的特性，看看虚拟化能否带来好处，比如性能提升，管理方便，成本下降等
3. 既然称之为核心数据库，一般单位的核心数据库数量都是很少的，又是非常重要的，个人观点没必要拿核心数据库去试验新技术，很可能得不偿失

通常都认为虚拟化环境不适合运行Oracle数据库，但是不实际进行测试、对比分析如何能知道是否能够运行，可以借给物理机、虚拟机进行测试，形成对比报告后，形成虚拟化部署的规范；
在计划将Oracle放入虚拟化环境运行之前，要尽可能做更多的测试，如功能测试、性能测试等，结合实际业务情况，评估是否可以运行在虚拟化环境中。

还是那句话，不是为了虚拟化而虚拟化。
核心数据库的压力一般都不小，在哪个行业里面压力都不小。虚拟化能帮助我们在物理资源绝对够用的情况下，分离应用和硬件资源的硬绑定，增加资源利用的灵活性和应用的灵活性。如果核心数据库的高峰负载接近物理设备本身运力，还是不要虚拟化了。如果核心数据库的高峰负载都非常低的话，性能优化就不是关键了。
个人观点。