1同行回答
小型机一直都以稳定性和可靠性著称，核心类的、关键类的应用或者数据库均放在其上运行，之前物理机时代，各个业务系统均分布在不同的小型机上，但是在PowerVM虚拟化后，业务虚拟机一下全集中了，相对来说风险也集中了，那怎么办？一台PowerVM虚拟化的小型机故障宕机了，会影响上面的VIOC全部宕机了，该如何防范？如何规划与设计?
我的解决方案有两个方面：
1.物理层方面：
非计划防范：
（1）业务虚拟机分散部署与两台PowerVM虚拟化的小型机中。
（2）采用HA双机热备方式或者TSA双机热备方式虚拟机主机分散于两台不同的物理机中，即A物理机放置业务a主机和业务b备机，B物理机放置业务a备机和业务b主机。
计划性防范：
（1）采用动态LPAR迁移至另一物理机中，维护故障的物理机。（推荐）
（2）在好的物理机中手动新搭PowerVM环境和VIOC，直接将需迁移的LPAR的SAN BOOT卷和数据卷挂载至新搭的VIOC。（停机操作，不推荐）
2.软件层方面：
数据库：采用HA热备、ORACLE RAC、DB2 HADR+TSA甚至DB2 PURESCALE双活等来避免该风险
（1）HACMP大家都知道，扩展来说有HACMP+SVC PPRC实现跨中心热备，甚至HACMP+SVC Strech Cluster跨中心热备等
（2）ORACLE RAC ORACLE数据库双活方案
（3）DB2 HADR实现基于日志级别的DB2复制，TSA实现DB2主备的切换、和浮动IP的切换，实现主库写，备库只读，读写分离
（4）DB2 PURESCALE DB2的数据库双活方案，而且可以实现跨中心DB2双活，实际上利用了GPFS并行文件系统方式，实现跨中心两台DB2主机的数据库共享，可同时读写。该方式需要配备专门的万兆网卡实现跨中心数据复制。
应用：采用HA热备、GPFS+TSA、应用负载+GPFS、WAS集群等方式避免该风险
（1）HACMP
（2）GPFS+TSA
GPFS实现应用数据共享，TSA实现软件层双活热备
（3）应用负载+GPFS
GPFS实现应用数据共享，应用负载方式实现应用双活/多活
（4）WAS集群+应用负载
实现WAS类应用双活/多活
通过以上硬件层和软件层的解决方案，可以规避PowerVM虚拟化之后VIOC过于集中的风险，物理机宕机，实际上对业务来说并不受影响，大大降低了对物理机稳定性的要求，但是需要值得注意的是数据库无论是采用了HACMP还是TSA方式的双机热备，均需要应用是短连接的数据库连接方式，否则即使切换后，仍需重启应用，才能建立新的数据库连接，那么就起不到应有的效果。
收起