核心银行系统PowerVM规划如何保障高可用和高性能

“Power支撑的都是企业的关键系统。虚拟化前一台生产物理机一般只运行一个系统，虚拟化之后一台物理机可能运行多个系统，做Power虚拟化之后生产环境的稳定性怎么保证呢？很多关键系统对性能要求很高，做Power虚拟化之后会不会影响性能？”此前基于Power的私有云技术交流活动中，有不少会员针对Power虚拟化技术在生产环境使用的高可用性和高性能提出了顾虑和担忧。实际上，Power虚拟化是很成熟的技术，重在规划阶段进行合理设计，可以有效避免可用性和性能的风险问题。
2017年1月18日，AIX专家俱乐部举办了核心银行生产系统Power虚拟化规划设计的经验，邀请了20家中小银行技术专家参与了此次交流。在交流活动中，基于核心银行PowerVM规划如何保障高可用和高性能这个交流话题，大家都提出了些许问题，加上嘉宾基于该话题的一些经验分享，总结如下：

问题一、PowerVM虚拟化如何合理规划网络，既提高网络高可用，又提升整体网络带宽，避免业务高峰流量拥塞？

【嘉宾分享】
powervm虚拟化在针对核心应用或者关键类应用时，需要特别注意考虑网络高可用和整体的网络带宽的使用。

先来谈谈网络高可用方面：
一般来说所有物理网络adapter均分配给vios，在配备两个vios的情况下，每个vios起码需要各分配两块网卡才能保障网络高可用。有人会说，一个vios，我就配一个网卡，网卡含有四个接口，两个端口分别接不同的网络交换机，做主备etherchannel，这样不就满足了高可用需求了么。这种方式当然可以，但作为核心应用和关键类应用，这样仅仅只能满足网络高可用，无法满足网络带宽的需求，尤其是在针对数据传输较多，需要数据共享，或者需要专门的数据备份、带内管理时，完全不够用，所以面对这种需求，每个vios两块网卡是标配，那么该如何规划和设计呢？

设计之前肯定要考虑到网络带宽提升，如何提升？实际上在做powervm时，需要整体权衡和把握的过程，而不是照搬照抄，固定不变的做法，针对每种类型的可以有不同的想法和做法。

（1）跑关键类的应用，无需共享数据，对带宽也没特别高的要求。

这种可以考虑两种，一种是双vios，每个vios双网卡，双网卡做主备etherchannel，每个网卡分别接一个网线至不同的两个网络交换机，再创建虚拟adapter，etherchannel与虚拟adapter绑定成sea，这样就基本完成了网络的高可用配置；另一种就是，每个vios一个网卡，2口／4口网卡均可，每块网卡上接两根线分别至不同的网交，在vios上创建主备etherchannel，后面的步骤和上面的一样。两种方式的不同就是，网卡故障时，需要切换vios，切换vios也就丢1-3个包，有时甚至对业务无感知。网卡故障相对来说较少，即使故障了，也无影响，所以上面两种方式，均满足需求。

（2）跑关键类的应用，需要共享数据，需要备份网络，对带宽有高的要求。

如果有特殊的共享数据需求，那么就应该规划好业务传输网，数据共享网、数据备份网络和云管理网。上面也说了，这种只有每个vios均需要两块网卡，每块网卡的0号口接相同的网交，第一块网卡的1号口接一个网交，在vios中搭建主主备的etherchannel，网交上配置lacp链路聚合，提升带宽，这样既满足了网络带宽的需求，又满足了高可用的需求，能够有效避免，网交故障、网卡故障、网线故障。第一块网卡的2号口和第二块网卡的2号口，组成etherchannel，做为数据共享网络，也可以既作为数据共享网络又作为数据备份网络、云管理网络，如果还需要区分，数据共享网络和数据备份网络，可以第一块网卡的3号口和第二块网卡的3号口，组成etherchannel，作为单独的数据备份网络。如果对数据共享网络的流量需要扩展，也可以考虑和业务网络一样的方式，做成主主备方式的etherchannel，网交上做链路聚合，数据共享网络和备份网络共享一组sea

（3）跑关键类的应用，需要共享数据，需要光纤备份网络

如果是这类需求，可以考虑每个vios两块网卡，网卡为4接口网卡，2口千兆电口，2口万兆光口，2口千兆电口做为业务和数据共享网络的2组sea的需求，2口万兆光口作为单独的备份网络的一组sea的需求。

总之，基于以上的一系列做法，针对不同的场景和需求，都又对应的方式解决网络规划的问题，既提升网络高可用，又提升网络带宽，满足powervm虚拟化后多lpar共享网卡的需求，通过划分不同网络来区分业务、数据传输、管理和备份，避免流量拥塞。

问题二、PowerVM虚拟化如何合理设计及规划业务网络、数据传输网络和带内管理网络？

【嘉宾分享】
在前面的分享中提到了业务网络、数据传输网络和带内管理网络，对业务网络、数据传输网络和带内管理网络进行隔离，无论从网络安全角度还是运维管理角度来说都是十分重要的，最重要的还是提升整体网络带宽和性能，那么该如何合理设计和规划呢？

首先需要按照不同业务类别进行网络安全分区的划分，如银行来说，可划分为外联区、互联网区、核心区、管理区等等。然后每个网络安全分区再细分为WEB、应用、数据库、带内管理、数据传输或者备份等，每个细分分配一个或者几个VLAN，对于业务来说存在WEB、应用、数据库等VLAN，对于管理来说存在带内管理、数据传输或者备份等VLAN，在PowerVM虚拟化SEA网络设计时，应设计两个甚至三个SEA，业务SEA（多个业务VLAN做Trunk），数据传输/共享/备份SEA(多个VLAN做Trunk)或者数据传输/共享单独一个SEA（一个VLAN ACCESS）备份单独一个SEA（一个VLAN ACCESS，对于数据量较大的备份，可以考虑上万兆网络）。每个网络安全分区都这样设计，最上层再设计一个统一管理网络，实现对每个安全分区管理网络的总管，这样一来整个PowerVM虚拟化资源池的网络架构无论是性能、可靠性还是从网络安全角度、运维管理角度来说都得到了最大的满足。

问题三、PowerVM虚拟化中的双VIOS设计是主备还是完全双活，该如何合理设计？

【嘉宾分享】
PowerVM虚拟化中的双VIOS设计可以提升PowerVM中多个VIOC的IO可靠性，因为所有VIOC均不直接分配物理网络ADAPTER或者物理光纤ADAPTER，所有VIOC均分配虚拟ADAPTER，所有网络流量和存储访问路径均需穿透VIOS。所以VIOS的可靠性不言而喻，通常搭建双VIOS，提升所有VIOC的可靠性是标准做法。

通常来说VIOS均安装在Power小型机的内置盘中，每个VIOS做RAID10的话，需要4块硬盘来保证足够的冗余，但是内置盘后的SCSI控制器只存在一个，倘若该控制器故障，即使存在双VIOS，双VIOS均因无法访问操作系统而HANG住或者宕机，其上所有VIOC届时均会受到影响。该单点风险是无法规避的，就像有人会说，主板也是单点啊，主板上的电源稳压模块也是单点啊什么的，是的，但是基于本期的主题是核心银行POWERVM虚拟化的设计，考虑多重冗余是必须的，所以一般来说，我们的做法是将一个VIOS的操作系统安装于内置盘，另一个VIOS安装于外置存储当中，通过SAN BOOT方式启动，这样可以规避该类风险。SAS控制器故障率虽然低，但一旦故障也不容小觑，VIOS既然又如此重要，那么有办法可以规避时，当然需要考虑该类办法。

回到题目来：POWERVM虚拟化中双VIOS工作时，双VIOS是双ACTIVE工作的方式还是主备模式的工作方式呢？

答案是网络ADAPTER是单VIOS工作，也是就说SEA是主备工作方式，光纤ADAPTER是双VIOS工作的方式。所有VIOC的网络流量均走了一个VIOS，所以人们都认为虚拟化的集中式管理后，网卡性能是一个瓶颈，之前物理LPAR时代，每个LPAR都单独分配了网卡，集中之后，所有LPAR都共享该网卡，如何化解该性能问题，可见以下两个问题中给予解答：

PowerVM虚拟化如何合理规划网络，既提高网络高可用，又提升整体网络带宽，避免业务高峰流量拥塞？
PowerVM虚拟化如何合理设计及规划业务网络、数据传输网络和带内管理网络？

而VIOC的光纤网络的路径会通过两个VIOS出去，每个VIOC的存储访问路径均匀映射在两个VIOS上的物理ADAPTER上，所以两个VIOS的工作方式是双活，均承担了VIOC的存储访问IO流量。当一个SEA备的VIOS故障时，其上的VIOC是不会丢失网络包，SEA主的VIOS故障时，发生VIOS主备切换时，其上的VIOC会出现非常短暂的网络丢包，通常1-3个网络包丢失后，VIOC的网络恢复。两个VIOS中任意一个故障时，VIOC的存储访问路径丢失一半，IO性能稍许下降后恢复正常，不会出现中断情况，对业务无感知。

问题四、PowerVM虚拟化中的存储路径如何规划，HBA卡如何合理分配并充分利用？

【嘉宾分享】
在之前的问题解答中已经详细描述了powervm虚拟化如何合理的设计和规划网络，如下：
PowerVM虚拟化如何合理规划网络，既提高网络高可用，又提升整体网络带宽，避免业务高峰流量拥塞？
PowerVM虚拟化如何合理设计及规划业务网络、数据传输网络和带内管理网络？

那么又该如何合理设计存储光纤网络和规划HBA卡分配呢？提到这个，VIOC的存储光纤网络路径究竟多少条合适？我的答案是4条，手动搭建4条为宜，性能最优，冗余性足够。倘若是通过POWERVC管理，发布出来的VIOC，那么不得已，肯定是每个VIOC 8条路径，8条也可以，但对于核心银行高性能的需求，肯定是4条，AIX的存储多路径软件在4条的情况下，负载分配的性能最优。既然是4条路径，又是双VIOS的设计，那么每个VIOS分配HBA卡的数量和VIOC FC映射情况又该如何呢？如表所示：

可以看到，基于每个VIOS的HBA卡的数量和每块卡的光纤端口利用数量，在4条存储路径时，可以有四种不同的方案：

方案一：核心系统、关键类系统基本不推荐该方案，所有VIOC均共用了4条存储路径。

方案二：核心系统、关键类系统推荐该方案，一半VIOC共用了4条存储路径，一半VIOC共用了另4条存储路径，互不干扰。而POWERVC管理标配方案（POWERVC为8条路径，见附表方案五）中VIOC共用所有8条存储路径。

方案三：核心系统、关键类系统不推荐该方案，一半VIOC共用了4条存储路径，一半VIOC共用了另4条存储路径，互不干扰。但一块HBA卡故障可能会导致VIOS宕机（一VIOS存放于外置存储，一VIOS存放于内置盘，见PowerVM虚拟化中的双VIOS设计是主备还是完全双活，该如何合理设计？），如果是主SEA的VIOS，还会造成网络丢包1-3个，考虑最高可用性要求，不推荐。

方案四：核心系统、关键类系统推荐该方案，性能最优，如表所示，每个VIOC均映射了不同的光纤端口，实现了等同物理机一样的配置，或者对于大于4个VIOC，可以多配HBA卡。

附表：

有人会说，每条存储路径8GB，需要考虑隔离吗，路径共享会对性能有下降吗，我觉得对于核心和关键类应用来说，当然需要，尤其是想通过LAN FREE的方式备份，提升备份速度的。存储光纤带宽当然是需要考虑的因素，倘若所有LPAR均共享4条路径，那显然大数据量吞吐和LAN FREE备份势必受影响，为了减少这份担心，隔离是需要考虑的，但也不是说都要钻牛角尖，方案二也是推荐的。另外在非POWERVC管理的方式下，按照方案二、三、四 三种方案设计的情况下，HBA光纤线路与SAN交换机的连接需要特别注意，不要导致所有VIOC的光纤路径均跑到了单一SAN交换机上，简单来说如表所示：
错误的连接关系表：可见VIOC1的四条存储路径均跑到SAN1交换机，其他VIOC也出现同样错误，需注意！

正确的连接关系表：每个VIOC均匀分布于SAN1和SAN2交换机上！

问题五、PowerVM虚拟化后风险集中了，如何化解风险，软件层还是物理层？

【嘉宾分享】
小型机一直都以稳定性和可靠性著称，核心类的、关键类的应用或者数据库均放在其上运行，之前物理机时代，各个业务系统均分布在不同的小型机上，但是在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方式的双机热备，均需要应用是短连接的数据库连接方式，否则即使切换后，仍需重启应用，才能建立新的数据库连接，那么就起不到应有的效果。
看完了嘉宾的一些实战经验分享，是不是有点收获，更好得帮助到你了呢，在互动问答过程中，嘉宾和大家都探讨了一些实际运维或者架构设计过程中的一些问题，归纳起来如下：

问题六、PowerVM在生产环境应用需要考虑哪些因素？如何实现资源池统一管理？

【问题描述】
PowerVM、PowerVC、ICM、Enterprise Pool之间的关联是什么？PowerVM在生产环境应用需要考虑哪些因素？如何实现资源池统一管理？

【答复一】
PowerVM是IBM具有悠久历史和技术底蕴的虚拟化技术品牌，以技术稳定性和成熟性先进性著称。是目前IBM Power服务器构建云计算的虚拟化的核心.
PowerVC是基于基于OpenStack、面向云计算而设计的管理平台.亮点在于通过GUI方式简单统一的管理计算，存储网络等资源。重点在于对Power服务器进行进行镜像和分区的集中部署.对服务器和分区进行整体管理.
IBM Cloud Manager是实现云计算的管理平台一个整体解决方案.能够实现资源自助申请，调度，交付，监控，回收，计费等。支持对异构虚拟化平台的支持。更加全面和具体。有云服务的门户及其各种接口，能够实现对多种开放平台的技术对接。
Power Enterprise pool是一个只有Power 770+, 780+ E870, E880高端机型支持的技术，目的是跨power服务器的资源有效利用，用户购买了此迁移功能，就可以减少购买成本，可按照一个集群内实际同时需要使用的资源数量来购买授权数量.还可以根据需求手工调整资源的分配，最终保障业务正常运行。

【答复二】
PowerVM是搭建PowerVM虚拟化的关键一环，不可或缺，要实现资源的统一管理必须建立在PowerVM虚拟化完成之后，通常的做法是利用PowerVC实现对PowerVM的接管，实现PowerVM虚拟化实施的自动化，标准化和快速化，满足目前敏捷开发的需求，再通过ICM接管PowerVC,实现Power云部署的流程化，并开放各类openstack接口，对接其他非Power云资源池，如KVM、VMWARE等，最后通过开发或者使用IBM又一款产品ICO，ICO接管整个开放平台云资源池，实现各类资源的部署自动化、标准化、快速化，试想一下，之前上线的一系列痛苦的软硬件安装配置工作，现在均可以通过软件工具和各类脚本编排实现，一键式部署，大大加快了系统开发、测试和上线进度，是多么美好的一件事情。

问题七、PowerVM虚拟化如何实现VIOS配置的快速备份和恢复？

【问题描述】
我们在做一个PowerVM设计和规划的时候，涉及到好多的网络配置、存储配置等等，可能会花费很多时间去做规划和实施。一旦我们的规划设计和实施完成的时候，所有的配置是否可以通过某种方式备份下来，一旦系统发生配置性丢失或者是VIOS本身的故障时，当我们重做VIOS系统之后可以快速将之前的配置导入，而不需要一条一条的去敲之前的配置命令？

【答复】
配置主要有两个方面，一个是在VIOS和VIOC的Profile里面，在HMC里面就可以直接备份，需要恢复的时候直接覆盖原来的就可以；另一个是在VIOS中用命令行的方式新建SEA网络、VIOC FC映射和VIOS光纤卡参数等，这些都是标准的，真没几条命令。如果要备份的话，我推荐如果VIOS是通过SAN BOOT在外置盘启动，操作系统安装在存储中的，直接在存储当中做一份flash copy就完全保留了，需要恢复的时候，直接把flash copy挂载到VIOS上，直接还原了之前的VIOS系统；如果VIOS是装在内置盘的，也可通过挂载外置存储中的卷至VIOS上，利用alt_disk_copy就能复制VIOS操作系统至外置存储卷，当作一份备份，以备不时之需，要用的话直接将卷挂起即可。

问题八、PowerVM中的sea卡的故障问题诊断

【问题描述】
按我平时的规划，一台物理770设备创建40个vmclient,网络通过多块物理网卡绑定成以太通道卡，然后再和虚拟卡绑定成sea卡供所有client分区共享带宽。但是发觉一个问题，由多个网口绑定的sea卡中有一个口损坏了，个别分区即发生了网络不通的现象，重做sea，将该故障网口踢出以太通道，则恢复正常。因此猜测sea是否根据client的ip地址分配网口？如遇到此类故障，重做sea将影响所有分区的网络，请问此类问题如何解决？

【答复】
请问您多块物理网卡绑定成哪种方式的etherchannel？etherchannel中的参数设定能提供下吗？就是运行smit etherchannel看看。
多块物理网卡按照我的理解是3块或者3块以上，那么应当是主主备或者主备备，两种方式的参数均有很多不同的设定方法。主主备，需要主主两个网口接入同一个网络交换机，而且需要该网络交换机端口也配置了LACP（链路聚合），并且mode必须是802.3ad的方式；主备（备）需要mode是standard或者Round-Robin。初步怀疑你多块网卡设定的应该是Round-Robin，轮询导致一块网卡故障，造成偶发性的个别分区网络不同的现象，建议你进行配置更改。当然这只是初步怀疑，更明确的判断需要你提供配置。

问题九、vmclient如何批量复制操作系统

【问题描述】
我当前的做法是先通过nim server恢复一套系统给vmclient,然后通过vio server将其他lv mapping到同一个vhost,在该系统中写个脚本进行顺序批量的alt_disk_intall. 全部完成后将所有lv分别mapping到各个client. 请问能否通过cplv对系统所在逻辑卷进行批量复制，如此复制出来的系统是否可用，在管理上是否有隐患？

【答复】
按照你所说的，VIOC用的是内置盘，采用了VSCSI的方式连接。不推荐用cplv的方式，赞同用alt_disk_copy或者alt_disk_install的方式，原因是alt_disk_copy有专门的参数不保留原操作系统的任何信息，包括os唯一id,odm库的信息等，外设信息等，否则用cplv的话，原操作系统的所有信息都复制过去了，包括IP地址信息，启动后可能会造成IP地址冲突，还有需要删除很多外设信息，删除存储路径中miss的，删除odm库的一些信息，RSCT的node id等，工作量较大，搞不好有些信息没删掉，比如说rsct的node id，配置好的HA后，如果rsct node id主备机一致，则会造成系统宕机等，一句话，后果很严重，非专业人士不要采用该方法。对于NPIV的存储连接方式来说，很简单，搭建一个AIX IMAGE模板，利用存储批量复制该image即可。

问题十、在PowerVM设计规划过程中，如何合理规划物理机中LPAR的数量？

【答复】
具体LPAR的数量是根据不同的业务类型，不同的用途来的。资源上整体上需要参考实时的整机的CPU利用率和计算内存利用率两个指标来的，整机的CPU利用率在闲时不能超过30%，计算内存使用率闲时不能超过总内存的80%，只结合CPU是片面的，只结合计算内存也是片面的，另外还需考虑VIOC的实际CPU使用率，可参考ENTC%，对于实时性业务，整机在CPU利用率小于30%，ENTC%大于500%时，需要考虑VIOC的扩大EC或者VP。综合来说物理机中lpar的数量可以到多少，真的很难回答。通常我们的做法是搭建一个大的安全分区power资源池，再结合上面几个指标综合判断是否该资源池是否可以再放置VIOC，还是需要扩容。而不是预先规划好放置多少LPAR，也很难规划，因为没有任何数据提供依据，除非在测试环境已经有详细数据提供支持。

问题十一、PowerVM高可用，哪些场景可以触发切换？

【问题描述】
PowerVM架构中，是否能够按照网络或者存储分别故障的应用场景，进行高可用切换。或者，在高可用切换方面，有哪些参数和最佳实践。

【答复一】
有些最佳实践参数，比如VIOS 上物理网卡的参数，修改建议：jumbo_frames=yes, large_send=yes, large_recieve=yes, flow_ctrl=yes
VIOS 上 SEA 参数的建议：jumbo_frames=yes,large_send=yes,large_recieve=yes
还有对于 PowerVM 环境中的物理光纤卡，建议修改 fscsi 设备的 fc_err_recov 和 dyntrk 两个参数

【答复二】
网络故障切换主要是网卡的切换和VIOS的切换，当主网卡故障，自动切到VIOS的另一备网卡，当两块网卡均故障时，自动切到另一VIOS。
存储故障时有好多个方面，如果是存储控制器故障，还有另一存储控制器，对powervm来说就是存储路径丢失了一半，并不会造成切换。整个存储故障的话，一来可能性非常低，但是这种情况属于存储单点，如果你本地没有备存储的化，那么你只能切灾备。对于我们来说，我们是双存储通过SVC做了VDM，通过SVC分配卷给POWERVM中的VIOC，即使存储故障也不会出现造成数据丢失，通过SVC层的存储切换完成。或者你所说的存储是内置硬盘通过VSCSI的方式挂载给VIOC的盘，该内置硬盘在VIOS当中做了RAID10，坏一块盘来说无任何影响，倘若内置硬盘全故障或者SAS控制器故障，这种可能性也非常低，假设的话，那么整个机器都会宕机，这时候必须靠主机的HA热备或者应用集群等软件层的集群实现切换，如果这一层保障也没有的话，你还可以通过LPM实现VIOC迁移至另一POWERVM主机，但是这是手动的方式。

问题十二、powerVM承载的虚机是否定制监控工具

【问题描述】
目前我们对aix系统的监控主要通过nmon和tivoli。vmware有专门针对虚机的巡检和监控工具。powerVM是否也有相关的监控工具

【答复一】
可以通过两款监控产品IBM PowerVP和Lpar2rrd进行监控

【答复二】
有的，tivoli当中就有专门的powervm监控代理，可安装于HMC中，还有专门的VIOS监控代理，上面两种监控代理，都能实现对物理资源的实际使用率、分配率、PowerVM的操作事件等进行实时监控。如果没有tivoli，可能就得利用HMC自带的监控采集工具进行信息采集，人工定时去查看的方式，就没有tivoli那么自动化了。

问题十四、针对老旧Power小机应用向新的PowerVM环境迁移，应该怎样规划资源？

【答复】
需要对原有系统的资源使用情况，最好包含各个时间点的资源使用情况，调度情况等进行统计。
然后根据这些信息进行LPAR资源分配，VIOS资源分配以及相关IO、网络等技术方面的设计。需重点考虑可用性、切换流程及性能。

问题十五、powervm虚拟网络的问题

【问题描述】
原虚拟网络结构

现在物理端口ent3不用了，vioc端跑着生产业务不想动，想改造下结构成这样

结果两台主备机上的vioc1之间不能通信了，主备机vioc2之间也无法通信，但是各自可以通到网关，求问大神们问题出在哪里啊？先谢过大神们了！

【答复】
结合你的描述和图来看，新的网络结构到是没问题，但是可靠性太低，新的结构物理的ent2一断，你所有网络不就断了？测试环境下到是可以。
从你的描述来看暂不能确定问题所在，能否请你再提供些细致的信息：能否从外面连通vioc1和vioc2的所有网络接口的ip地址，能否提供veth1的adapter配置信息以确定vlan id，能否在网络交换机上查一下ent2的网络端口是否设置为trunk，并且vlan id和veth1 adapter的vlan id一致？

【总结】网络通信问题是件大家运维过程中，都会遇到的问题，如何快速排查问题解决此问题？基于PowerVM虚拟化的通信问题，以下几点方法或许可能帮助到您：
一是观察现象，VIOC能否通本网段？VIOC能否通跨网段？VIOS能否通本网段？VIOS能否通跨网段？基于上面四个问题，如果VIOC不能通本网段，请排查VIOC虚拟网卡的VLAN ID配置，VIOS的VLAN ID列表，网交上的端口的VLAN配置；如果VIOC能通本网段不能通跨网段，VIOC的网关配置有问题；VIOS不能通本网段，排查VLAN ID列表，VIOS虚拟网卡的VLAN ID配置；VIOS不能通跨网段，能通本网段，需要排查VIOS的网关配置。基于以上的现象观察，基本能确定是整个网络问题还是部分VIOC的问题，部分VIOC的网络问题，基本能定位到是配置问题，需要严格确保网络交换机端口（所有与PowerVM相关的端口）上VLAN ID与VIOS上的VLAN ID列表、VIOC虚拟ADAPTER上的VLAN ID一致，即网交VLAN ID=VIOS VLAN ID包含VIOC的VLAN ID。如果是整个网络都有问题，基本上就是VIOS与网交的配置问题。
二是排除法，VIOC本网段不通，跨网段也不通，那么将VIOC的网络配置到VIOS上的虚拟网卡上呢？是否结果一样？结果一样，可以判断是SEA的问题或者VIOS配置文件的问题，或者是网交的配置问题，就排除了VIOC端的问题，如果是VIOS能通，就是VIOC的问题，查看VIOC的虚拟网卡VLAN ID是否在VIOS配置文件中VLAN ID列表中存在且一致。

问题十六、powervm 就企业而言，在什么情况下采用比较合适？

【答复一】
以前是开发测试环境用的多，毕竟配合PowerVC之类的解决方案，在虚拟机交付上速度还是非常快的，而且也节省资源。现在，运行很稳定，生产上也在采用。

【答复二】
企业有如下业务需求可以考虑使用PowerVM:
1.备份,灾难恢复,业务连续性.
2.构建灵活高可用系统,减少宕机时间.
3.服务器整合和数据中心整合.
4.资源管理和动态应用部署.
5.应用软件测试与开发.
6.支持原有旧应用.
7.容量规划和存储虚拟化等.

【答复三】
搭建power环境虚拟化，有利于资源动态分配调整，提高机器资源利用率，结合powervc，加快部署和环境搭建，是power私有云建设的必要一环。