如何整合当前存储系统，实现存储资源池化、云化转型？
前言
随着各行业业务的快速发展和新型业务的建设，面对互联网业务的冲击及敏态IT的建设需求，一方面企业业务所处的基础架构环境需要具备足够灵活的IT软硬件基础平台以提供对业务能力支撑，另一方面，企业快速增长的业务目标和IT基础设施发展也越来越不平衡，急剧上升的客户量、持续增长的日交易量、工作日高峰的并行压力、负载分析的响应时间要求等等，导致系统越来越不能满足日益增长的性能需求，这些性能需求首先反映在后端存储系统的响应上。
因此如何整合当前IT基础架构中的存储系统，实现存储资源池化、云化转型，并进一步满足业务系统的高并发、低延时的性能需求，成了企业信息化的迫切需求。
一是要借助FLASH闪存阵列来大幅提高生产系统性能，摆脱传统机械磁盘系统的物理限制，让数据的读写处理更加快速和高效；二是要利用先进的存储架构，实现不同性能的存储资源池间/多云存储池间在线无缝切换，大大增强生产系统存储资源调度的灵活性；三是要实现存储资源“质量分层”，根据业务系统的业务特性和需求，可灵活地选择不同性能或不同质量的存储作为后端服务存储，当前存储不满足性能需求时，可立即迁移至性能高的存储，并无缝切换，对上层业务系统无任何感知和影响。
但由于每家企业IT基础架构中的存储系统都有差异，或是涉及到了多种类型的存储产品，或是已经有部分已经实现了存储资源池化，或是原来的存储系统已经老旧，需要进行系统更换，等等。因此，要实现存储资源池化、云化转型，还需要根据各家企业的实情来进行分别对待，提出合理且有针对性的解决方案。
以下是社区中已经实现了存储资源池化、云化转型企业中的实践专家进行的技术交流。由邓毓汇编总结供大家参考。
一、存储整合需考量的因素，可能带来的新问题和性能影响等问题
【Q1】存储整合时所要考虑哪些因素？对任何现有业务的改造我觉得都不如新建来的容易。但很多时候又不得不硬着头皮去这样做。虽然衍生出了很多的产品和方案。但风险终究还是多了很多。对于现有的多套业务。多格不同时期，不同应用规格的存储。在整合时有哪些要考虑的因素呢？
@aditowh：
应结合不同的业务场景实施存储整合或者存储迁移，例如不可长时间停机的数据库数据，尽量通过数据库主备同步或者数据存量备份方式，直接实施数据迁移后的业务短暂切换即可；
对于虚拟机应用服务器迁移，负载均衡可实施类似灰度升级方式，业务低峰期停机或者在线迁移到新存储（前提是可共享挂载存储到宿主机）；
数据整合评估时，需要多考虑存储性能要求（IOPS/读写延时）、横向扩展（容量需求）要求、IO路径的变化等，是否能满足迁移后的要求。
@DK：
在整合的过程中，需要考虑各环节的兼容性；
考虑用于作为整合后的虚拟化管理节点自身的能力，包括性能功能等；
考虑虚拟化管理节点的横向或纵向兼容；考虑能够用于割接的窗口；
考虑厂家执行整合案例的经验案例。
【Q2】存储整合及集中之后,如何解决系统架构深度带来的IO延时问题？存储整合及集中之后，必然会导致系统架构深度加深，如何解决系统架构深度带来的IO延时问题？
@aditowh：
进行存储整合，需要实现了解清楚整合后业务的IOPS要求、延时要求，选择合适的后端存储再进行迁移；
降低IO延时，还是可以通过高端存储的动态分层技术、业务错峰规划部署、业务服务器应用层面IO整合，还可以引入性能更高的全闪盘集中式存储、分布式SSD群集等满足IO的延时要求；
并且还可通过引入高IO的网络设备、高速网卡、高速HBA卡，系统层面实现bond4扩充带宽等来满足性能要求。
@邓毓：
不会，原因很简单，读还是和以前一样，直接读底层存储，加了层网关，并不会增加延时；
写和以前类似，之前的写是写底层存储缓存，存储双控间完成缓存同步后，返回主机完成写IO周期，加了层网关后，先写网关缓存，待存储网关双节点完成缓存同步后，返回主机完成写IO周期；
对比这两个过程，写延时也没见哪里增加了。所以该问题不存在的。
@DK：
您提到的架构深度，可能是考虑到存储层之上增加了虚拟化引擎这一层级会不会导致io延时，您在用SVC或FS9100的时候，这两个产品本身所提供的写缓存能力和easy tier热点分层，或者是vdm镜像场景下的优先读机制，其实都是可以实现性能的加速的。
【Q3】存储资源池化对读写速度的影响？存储系统实现存储资源池化后，对读写速度有多大影响？是否会造成I/O瓶颈？
@aditowh：
存储资源池化，从最上层来看，目前的架构方案大部分的实现方案还是通过上层控制器就行IO终端的纳管，其实对于IO路径来说基本没有变化；
例如Openstack中对于FCSAN的纳管方案，是通过cinder纳管盘机驱动、纳管光纤交换机驱动，通过WWN进行划zone，对于纳管的每台物理机来说，只是纳管挂盘的方式通过控制器来实现，而物理机到盘机的路径没有实际变化，因此我们认为读写速度没有影响，只是要防范数据热点，因此要通过抽象出一定的盘机选择算法通过控制来实现，尽量避免数据热点和过多的IO争用。
@邓毓：
存储资源池化跟单存储比较，并不影响读写速度，不会造成IO瓶颈，无非多了道物理到虚拟的转换而已，这种级别的转换效率是非常高的，与实际物理落盘和机械寻址相比，不是同一个级别的延时，几乎可忽略。
而单存储如有有IOPS的压力，通过LUN数据打散在多个存储中，反而还可以增加整体IOPS，对业务性能也是有所提升的。
@刘文：
我理解存储虚拟化不等于存储的池化，池化的重点在于存储管理和分配方式的变化。
存储池化决定了用什么形式去进行管理，是用cinder接口直接连接各类型存储，或者自己基于smis等协议开发的平台，这些对于业务是无感知的，不影响使用，自然也不影响读写速度。
至于用不用存储网关设备，比如通过SVC等网关设备间接管理，这个就依赖于管理水平了。
二、如何实现存储整合，转向存储云化，资源池该如何划分，新老存储数据如何迁移与复用，集中式存储是否使用云化环境等问题
【Q1】存储池化的统一网关如何实现？在云环境下，越来越多的自主开发工具，云平台，是否还有SVC这种存储网关设备存在的必要，直接通过smis等协议开发，暴露api接口，直接调用，实现存储底层黑盒化，是否可行？
@DK：
您这样做，其实就是通过定制开发去覆盖类似于虚拟网关的能力，并非不可以，但是，估计要考虑到以下三个方面:
一是这样做代价不一定更小，人力和时间的投入；
二是成熟度稳定性和商用专业设备的差别，毕竟类似产品是商业公司经历了较长的研发和实际使用产品更迭周期的；
三是不一定所有的存储都能提供合适的API，并且被调用。
@邓毓：
通过更好的方式去调用吧，比如IBM自己的POWERVC，但前提是要有POWER。
用您所说的SMIS也并非不可，需要进行二次开发，像TPC和IBM的容灾切换工具，都是可以对接SVC的，就说明SVC也的确是有接口的，看IBMER愿不愿意和云平台合作，自己查资料弄得话，折腾折腾估计也行，就是得不到IBM认证，怕有后续的维保风险。
我们之前就实现了TSM调用脚本来实现SVC自动化进行卷的快照，从侧面反映这个对接难度其实不大的。
@aditowh：
如果不是研发性单位，建议还是采用成熟一点的管理工具平台，或者采用开源社区生态比较好的开源组件，如果选择自行开发，还是需要有原厂支持进行，管理平台的二次开发，对于API的理解还是有一定要求。
但对于存储产品来说，一般厂商开放的API还是比较少，而且市面上除了Openstack生态中有一部分比较老的API提供出来，接口还是相对较少。并且对于代码的健壮程度、兼容性，功能性测试可能也是个挑战。
【Q2】存储池化按什么原则进行存储池的划分？划分存储资源池的原则是什么，业务类型？应用场景？容灾级别？如何实现存储池的分级呢？有没有实现自动化管理的同行可以分享下成功经验？
@aditowh：
从经验来看，我认为应用场景和业务类型是划分存储池需要考虑的2个主要因素；举个栗子来说，was应用服务器基本可接受3s以内数据中断，ftp甚至可以忍受时间更长，但数据库业务或者ETCD的应用场景来看，忍受的数据中断要在ms级；我们在制定方案时，IO压力较低，平均IOPS再几十以下可以选择分布式sata存储；数据库重要的业务场景建议使用集中式存储；IOPS压力超过数百的建议采用分布式SSD存储；
存储池分级，本身FCSAN盘机已经有动态分成技术，对于热点数据可以通过增加SSD缓存层增加磁盘响应效率，而我们再此基础上要做的是通过管理平台进行好不同级别存储的管理，例如抽象出金银铜级存储，每个级别存储对接不同的后端存储，总之还是要划分逻辑存储池，抽象逻辑存储划分算法，通过控制平台实现管理
【Q3】测试环境目前有多台旧存储（全部是15K sas盘），计划将其整合，并提升性能，有以下2个疑问：
1、使用全闪，或者混合存储（ssd+sas）的方式，两者性能差距能有多大？混合存储方式，感觉只要将oracle log这类高IO的数据放到ssd上，不会比全闪性能差多少
2、数据迁移，目前主流的架构，是否扔需要svc或者vplex这类设备的支持？还是说有其他更先进的方式？
@潘延晟：
个人觉得旧存储随着时间的推移。存在的不仅仅是性能问题。还有可靠性和稳定性的问题。
所以如果配合闪存形成混合存储，可以采用数据分层来提高效率。另外在条件允许的情况。还是过度一段时间后逐渐将旧存储脱离重要业务。逐步替换。保证存储的可靠性
@aditowh：
使用全闪存储，在SSD设备成本降低、稳定性越来越高的趋势下，以后会成为主流，全闪的IO延时一般可以在1ms以下，而且主要IOPS的能力会大幅提升，对于单盘质量非常好的SSD来看，IOPS会是sas盘的上百倍，组成群集后也会有数十倍的IOPS提升；选择存储类型，还是要根据业务场景来看，IO密集型，而且IOPS要求非常高、延时要求高的重要数据库业务场景下，建议选择稳定的全闪存储，消除存储性能带给业务的压力；
除了磁盘间的数据迁移外，对于跨平台或者异构，我们采用比较多的业务层面迁移，如Oracle数据库的TTS技术，其他数据库厂商也有自己的数据迁移方案可以采用
【Q4】如何不停机的把数据迁移过来？
@邓毓：
之前没有接入存储虚拟化网关的，存在底层存储映射给存储网关，再映射给主机这样的过程转变，才能完成后面的数据迁移工作，映射改变的过程必然要停机。
如果不采用存储虚拟化网关的方式，不停机的话，能允许部分数据丢失也是可行的，比如新搭一套系统，利用备份、恢复、前滚的方式迁移数据也是可行的
不停机的方式，还可以用OS层的LVM镜像，待同步完成后，解除原存储的镜像即可。
@DK：
不知道您这个问题是不是指的通过FS9100去实现异构存储的数据迁移，在已有FS9100等虚拟化设备的前提下，可以实现不停机的数据迁移，但是之前没有部署好FS9100的情况下，需要停机窗口。
@刘文：
如果已经有存储网关设备，一般都可以进行在线migration的任务。
如果没有网关设备，很多同品牌的存储间迁移都提供在线迁移的工具，可以咨询厂商工具。
操作系统层，通过lvm mirror、rsync等方式做数据层的同步，如果是GPFS等特殊文件系统的话，也支持从工具层的迁移。
【Q5】集中存储在云化环境中的未来如何？分布式存储会在云环境中大行其道吧，已经开始试水ceph了，无论从接口耦合，自动化分配，云环境的存储管理来说，分布式存储的优势尽显，云环境中集中存储有非存在不可的可能吗？
@aditowh：
从分布式存储提供的基本功能来看与集中式存储并无大的区别，但是从稳定性、IO路径、性能要求来看的话，集中式存储还是有一定的应用场景。
例如IO密集型的应用会要求较高的IOPS，虽说通过SSD群集可以解决IOPS，但是从实现架构的原理来看，分布式存储的稳定性易受到单节点网络因素或者单盘亚健康因素的影响，因此对于IO稳定性要求高的业务场景下，尽量还是采用集中式存储。
@邓毓：
分布式存储归根到底，性能相对集中式存储来说，肯定是比不上的，尤其是闪存大行其道的时代，一代要比一代强，从SATA接口的SSD到SAS，再到NVMe接口，IO响应时间已经缩短到了us级别，对响应时间要求严格的数据库起码不怎么会选择分布式存储，云环境下也是同样，集中式存储如果开放了API接口，或者通过间接的方式对接云平台，也是可以适用云环境的。没有谁替代谁的关系，看业务的要求。
看了大神的回答，突然想再接一个问题，那超融合的未来呢。现在或未来是不是集中存储和分布式相互靠拢的过程？
@aditowh：
超融合，我认为也是针对一定业务场景出现的，也不是适用于所有场景，超融合理论上所有的支持分布式架构的应用都可以承载，但如果对于运维要求比较高的单位，会有一定不便性，例如节点维护时，需要同时考虑到计算和存储的停机时间；
但对于机房环境紧张而且停机敏感性没那么高的企业还是可以尝试推行。
集中式和分布式存储，以后也是根据应用场景来的，根据定位的业务特性进行不同平台的选择，借用邓老师一句话，没有谁代替谁的，只能是谁更适合，结合性能、扩展、各种成本。
文章地址：http://www.talkwithtrend.com/Article/241887
欢迎点击阅读原文关注社区 “存储” 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场