powervc通过svc创建存储卷模式的问题及风险
powervc通过svc创建存储卷的模式为manage模式，该模式下的卷无法脱离svc单独存在，比如v7000映射卷给svc，svc再通过认到的mdisk，创建卷，该卷可以映射给主机，但是一旦svc故障无法恢复，数据虽然在v7000存储上存在，但是也无法挂载给主机。这是存在的一点风险隐患，用powervc和svc无法避免的，有专家解释下么。
10同行回答
- powervc通过svc创建出来的卷是manage模式的，脱离不了svc而存在，也就是说svc不可用时，虽然数据还在v7000中，但是v7000也无法挂载。
这些跟svc可靠性啊，灵活性，相不相信svc什么的无关，我只是说目前powervc这一层还没考虑到，是个风险点。
倘若powervc能够做到自动在后端存储划卷映射给svc，做成image模式，再映射给主机，并且自动镜像给备的后端存储，你还会选manage模式？manage模式搞得后端两份存储都无法直接挂载，只能通过svc挂载，这样是灵活的？风险全堆积到svc上，而没有后路了。powervc只是这点还没考虑到，考虑到了，不仅灵活还风险可控。
收起- 按照你的说法，image后端存储挂了怎么办
- [此评论已删除]
- [此评论已删除]
- svc vdm复制卷至另一存储，挂一台没事。但manage模式，svc完蛋，底层存储都挂不了卷
- [此评论已删除]
- 使用svc，我倾向于使用manage模式，image模式侧重于系统迁移，有很多的限制。
- 个人感觉你的需求应该再往上拔一点。首先，powervc不能利用svc来管理后端存储，这样中间层故障，会导致应用不可用。最好的实现方式应该是powervc直接通过api支持各厂商的存储，并提供disk mirror功能实现存储高可用。这样的设计既避免了中间层带来的影响，又可以灵活选择不同厂商的存储，避免被单一厂商绑定。我喜欢这个想法，真的。如果以后openstack支持类似功能，相信powervc也有可能利用openstack实现这种需求。
1.SVC属于存储池核心组件，可靠性应当是最高的。如果SVC也挂了，世界就清净了；
2.为了提高SVC的可靠性，建议4node节点或以上；
3. 如果不相信SVC，核心应用的建议使用gpfs，disk不通过svc虚拟化；
收起这里牵涉到灵活性和最高可用性的平衡。选择了powervc通过svc管理后端存储，就是看着其数据管理的灵活性。即使powervc增加image选项，如果全部要做成image格式，需要提前在后端都把lun逐个划分好。这复杂性又和灵活性相背离。
一个架构考虑的主要方向是朝着更灵活的方向走。当然，也会有极端需求存在。
如果考虑svc全部故障场景，那么是否也应该同时考虑后端存储控制器全部故障的场景？推导到最后，总有一个点无法满足。所以，在选择时，适当的平衡是需要的。
收起用单一的v7000当然问题不存在，可是要是用到了svc下挂v7000和其他存储呢，ppwervc只能推出manage模式的卷，就无法脱离svc而存在，v7000上即使有数据卷，也无法挂载。powervc除非推出了image模式才能解决该问题。
收起理解提问者的需求，但是可能很多技术的发展都需要一个过程。
目前PowerVC的技术聚焦在于对PowerVM计算资源池的纳管和快速VM部署的实现上，对于楼主提出的VDisk模式选择需求可能会在PowerVC之后的版本提供么？这个答案在于IBM给出。
从软件定义数据中心的角度讲，目前的PowerVC提供了基本的PowerVM虚拟化中计算、存储、网络的功能，实现了自动化的VM供给功能，而我们用户的胃口都比较大，呵呵。。。。