如何运用闪存技术快速解决生产系统 IO 性能瓶颈或者异常隐患, 业务系统所用传统存储又如何快速切换至闪存阵列解决燃眉之急, 存储切换时系统停机窗口如何安排和停机, 数据迁移风险等等重重问题.
传统机械磁盘存储受限于存储架构的发展, 很难在速度上进一步突破和提升. 更快的闪存存储系统突破了传统机械磁盘系统的物理限制, 让数据的读写处理更加快速和高效. 然而企业用户也必须考虑: 如何运用闪存技术快速解决生产系统 IO 性能瓶颈或者异常隐患, 业务系统所用传统存储又如何快速切换至闪存阵列解决燃眉之急, 存储切换时系统停机窗口如何安排和停机, 数据迁移风险等等重重问题.
针对以上问题, 社区举办了相关主题探讨活动, 重点帮助大家更好的了解了如何利用闪存存储阵列迅速消除交易类系统数据库 IO 性能瓶颈. 活动中, 来自多家金融机构的技术大拿踊跃发言和解答, 并提出了许多宝贵和针对性的观点, 在此由社区专家邓毓对活动内容进行梳理总结, 方便大家参考.
一, 核心议题
1, 如何将系统所用的传统存储阵列切换至闪存阵列?
解答:
方案一, 操作系统层数据镜像技术
如 AIX LVM
1. 映射闪存阵列的 LUN 至 AIX OS, 并加入 VG
2. 将原传统阵列 LUN 和闪存阵列 LUN 做 LVM
3. 同步完成后, 找停机窗口, 从 VG 中拆除镜像, 剔除原传统阵列 LUN
4. 重新激活 VG, 并挂载数据文件系统, 验证
方案二, 数据库备份恢复和 OS 层面的克隆技术
如数据库: DB2 BACKUP/RESTORE,ORACLE RMAN,OS 克隆: AIX ALT_DISK_COPY,VM SNAPSHOT,VM P/V to V 等
1. 搭建新环境, 该环境存储采用闪存阵列
2. 通过 OS 层面的克隆技术, 将 OS 数据复制 / 迁移至新环境,
3. 通过数据库层备份恢复, 将数据库数据恢复至新环境, 并验证
方案三, 存储本身自带的 LUN 镜像技术
如 IBM V9000 等
1. 找停机窗口, 将原传统阵列 LUN 映射至 V9000
2. 在 V9000 中, 将原传统阵列 LUN 数据镜像 (VDM) 至 V9000LUN
3. 待镜像同步完成后, 将两个 LUN 主备关系反转, 闪存作为主存储, 原传统阵列 LUN 作为备存储
4. 将两个 LUN 虚拟化后形成的 VDISK 映射至主机, 验证, 此时主机存在 V9000 和原传统阵列两份数据保护
方案四, 存储虚拟化网关的 LUN 镜像技术
如 IBM SVC,EMC VPLEX 等
1. 找停机时间, 取消原传统阵列 LUN 至主机的映射, 将该 LUN 映射至虚拟化网关进行管理
2. 虚拟化网关将该 LUN(mdisk)虚拟化成虚拟 LUN(vdisk), 并映射给主机
3. 创建 vdisk 的闪存阵列 LUN 镜像拷贝
4. 待拷贝完成后, 将闪存阵列 LUN 置为主拷贝, 原传统阵列 LUN 置为备拷贝
5. 验证
2, 如何评估系统所用的传统存储阵列是否已达瓶颈, 无法满足业务需求?
解答:
通常而言, 每个厂商都有自己的一套评估办法. 对于磁盘 IO 来说, 大的方向, 主要看磁盘的 IO 响应时间. 对于 OLTP 业务, 读 IO 响应时间 5-8ms 内算是正常值, 写 IO 响应时间, 1-2ms 还算 ok. 高达 20ms 以上的响应时间, 通常都意味着存储内部存在瓶颈. 这个瓶颈可能存在于后端磁盘上, 存在后端磁盘卡上. 通常而言, 这种情况, 增加缓存并不能解决性能问题, 就需要看看是否可以增加更多物理磁盘 (前提是后端磁盘卡处理能力未达到瓶颈) 来解决问题.
那么到了现在闪存的时代, 如果考虑解决磁盘性能问题, 可以更多的看看闪存是否可以一劳永逸的解决性能问题, 同时还可以达到更好的经济比.
3, 高端传统存储阵列和闪存阵列如何取舍? 稳定性 OR 性能 OR 兼顾?
解答:
闪存的发展, 到现在为止, 变成了两个主要方向性的选择. 一是抛弃传统存储的架构, 采用全新架构设计的全闪存产品. 另外一种是沿用原来存储架构, 但是内部磁盘变成 SSD 磁盘. 如果是要拿闪存阵列和高端传统磁盘阵列别, 那么性能方面肯定是全闪存完胜, 稳定性高端存储占优. 因此, 个人理解可能您是不是想比较传统高端存储带 SSD 磁盘的架构和全闪存阵列对比.
对于全闪存架构, 由于是新的架构, 没有传统存储架构里面那些考虑后端磁盘慢的因素所要做的很多折中设计, 可以发挥出闪存的性能. 同时, 为了降低闪存产品的每 GB 成本, 这些架构中通常会包含压缩和除重功能.
对于传统磁盘阵列带 SSD 磁盘, 例如现在到处都在宣传的高端全闪存阵列, 主要架构并未发生变化, 限制性能输出的瓶颈部位还是在后端磁盘卡, 以及传统的 RAID 模式上. 在性能方面, 比全新架构的全闪存还是有一定差距. 同时, 这类闪存, 由于架构限制, 很难增加压缩和除重功能, 性价比也不是最后. 但是, 这种架构适合原来一直沿用类似高端存储架构的客户, 可以方便的过渡到新的平台, 获得更好的性能. 另外, 这一类架构, 容灾功能比较丰富, 适合有类似三站点需求的客户. 在性能得到提升的同时, 还可以保留原来所需的功能.
在这里想说的是, 稳定是需要时间和客户环境的不断适错才能获得一个相对稳定的微码环境. 因此, 传统阵列 + SSD 磁盘, 相对全新设计的全闪存架构, 是有一定的优势. 通常意义上说, 一个经历过 10-20 年磨砺的代码平台, 比发布才 3-5 年的全新产品, 代码成熟度还是要高一点的. 另外, 如果在高可用上考虑的比较齐全, 使用全新闪存架构, 也是一种很好的选择.
最后, 客户还是要根据自身的需求, 选择合适的产品.
二, 闪存的价值及优劣势
1, 目前全闪存存储阵列优缺点有哪些?
解答:
优点: 时延性能, IOPS, 占用机柜 U 位少, 绿色节能. 有些型号具备一定软件功能, 如异构虚拟化, 云存储, 软件定义存储, 数据删重, 压缩等.
缺点: 相对而言, 价格较高, 比高端存储可靠性和略差. 高端功能有所欠缺(高端全闪除外), 比如两地三中心 MGM 架构.
2, 如何从传统到全闪, 优势有多大? 目前交易数据库几乎都跑在企业核心高端存储, 升级到全闪阵列在哪些性能得以提升? iops 会提升多大?
解答一:
性能的提升主要还是在读响应时间和读写 IOPS 上, 尤其是读响应时间, 通常可缩短至 1MS, 甚至 0.5MS 左右, 而传统核心高端存储如果没有配置 SSD 盘或者 SSD 加速卡(利用 EASYTIER 等技术提升热点数据性能), 也需要 5MS 左右的响应时间, 至于 IOPS 的提升的话, 通常靠的是物理硬盘的盘的数量来提升读写 IOPS 性能, 数据 LUN 尽量分散于多个阵列上多块盘上, 这样利用每块盘的可支持的 IOPS 来叠加起最大可支持的 IOPS. 比如一块 SAS 盘最大的 IOPS 为 200, 一个 ARRAY 有 7 块盘做 RAID5, 数据分散于 N 个 ARRAY 上, 这样最大可支持的 IOPS 为 200 X 6 X N, 可见 IOPS 是很有限的. 而闪存不一样, 每个闪存阵列有多个盘, 每个盘有多块板卡, 板卡中又有 N 个芯片, 每个芯片中又有多个闪存模块等, 所以相比物理硬盘的话, 芯片级别的闪存可提供更为强大的 IOPS.
解答二:
性能方面, 尤其是 IOPS 和响应时间方面, 全闪存相对于传统磁盘存储, 相当于降维打击.
3, 重删功能在全闪存阵列中有何意义?
解答一:
重删功能主要是解决闪存 SSD 寿命较短的问题. 闪存 SSD 的数据写入和更新是电子式擦除方式, 必然带来数据块的频繁擦除动作, 而数据块的擦除是有次数限制的, 所以寿命自然不长, 寿命到了, 数据块也就无法使用了, 无法使用的数据块达到一定程度时, 整个 SSD 盘也就寿命到期了, 需要更换.
而重删功能, 可以在数据写入或者擦除数据块时, 在闪存的软件层, 就判断了是否要写入该数据. 如果写入的数据时重复的, 就不再写入, 这样自然降低了数据块的擦除频率, 提升了 SSD 盘的寿命, 另外也大大提升了闪存阵列的利用率, 虚拟容量也提升了好几倍.
当然类似的提升 SSD 寿命的方式还有数据压缩功能. 这里不再赘述.
解答二:
要看全闪存要支持的业务类型是什么. 如果上层业务系统是类似虚拟机, VDI 等环境, 会产生很多重复的虚拟机资源, 那么重删是很有用的.
如果支持是像数据库类型或文件系统类型的业务, 重删用处不大, 反而需要压缩功能.
4, 闪存对联机事务处理高峰期的改善效果?
解答:
这张图是连续四天的读响应时间和读峰值响应时间, 切换前后的对比情况, 包括了切换后, 14 号晚间的曲线图. 对比也是很明显的, 不过鉴于信贷批量的模型是写 IO 占据了 70-80%, 读 IO 占据了 20-30%, 读响应时间的明显提升, 写响应时间切换前后一直维持在 1MS 左右, 所以信贷批量时间仅仅缩短了 30 分钟 - 1 小时而已. 可以想象, 如果批量的模型是读比例高, 写比例低, 那么闪存对批量的提升意义还是非常明显的.
5, 任何一项存储产品, 不可能只有优势没有劣势, 除了价格(甚至很多人说价格也不存在劣势), 闪存的缺点在哪里, 瓶颈在哪里?
解答一:
劣势在于稳定性, 可靠性相比传统高端存储要低. 除非是高端存储的全闪, 性能也有, 可靠性也是 N 个 9.
当然还有软件功能性劣势, 比如两地三中心同步 / 异步复制, 有些闪存阵列可没有, 或者热点数据迁移, 分层, 压缩等等. 当然这些靠闪存前面接一个 SVC 可以解决.
解答二:
缺点购买成本贵, 因此起配容量较高, 但是平均每 GB 成本不见得比高端存储柜. 另外, 高级功能比传统存储要少一点. 性能瓶颈在于 CPU core 数不够, 发挥不出所有闪存芯片的性能.
三, 闪存的使用
1, 如何定位存储是性能瓶颈?
解答一:
这个问题没有背景描述, 那么暂时假定一个场景: Oracle 数据库的批量作业非常慢. 那么接下来的步骤:
首先, 从 Oracle 的 AWR 报告去找 IO 相关的统计信息. 首先要明确的是 IO 的问题是集中在某个数据文件, 还是所有的数据文件都存在这种问题? 如果是某一个数据文件或者是表空间的 IO 非常特殊, 那么多数原因是因为数据库设置或者应用本身的设计, 例如数据文件配置模式, 索引, 统计分析等问题. 如果是所有的数据文件和日志文件多数面临 IO 问题, 那么这个时候可以去看存储的日志.
接着, 从存储的性能分析日志去看. 不要看端口啊, 引擎啊这些信息. 直接看对应那几个存储卷的重要指标(延时, 读写速度, 队列). 如果这几个指标严重出现问题, 那么再去看对应的端口或者是引擎的相应信息(内存, 承载卷的个数, 端口是否有负载过量的情况等等).
解答二:
看这个应用系统用的存储卷是否性能能够满足应用系统的需求. 可以用工具软件, 比如 TPC, 查看当前存储卷的 IOPS, 读写响应时间, 吞吐量等. 再结合操作系统层或者数据库层的分析, 如果有异常, 一定会有所体现的.
2, 全闪的选购要点是否和传统一样?
解答:
闪存主要分三类:
1. 纯闪存阵列, 不带任何软件功能, 追求的是时延优先
2. 带异构虚拟化功能的闪存阵列, 在闪存之上, 增加了很多软件功能, 丰富闪存的应用场景, 如异构虚拟化, 迁移, 压缩, 双活等.
3. 云环境下的闪存阵列, 多个闪存节点通过以太网或者 infiniband 高速互联, 提升闪存扩展性, 并具备数据重删和压缩等功能, 解决的是云计算环境下闪存集群的应用场景.
4. 高端存储的全闪架构, 集性能和可靠性为一身, 应用于大型核心系统.
上图帮助理解:
3, 使用 GPFS 的 AFM 工具把数据由传统存储阵列迁移至闪存阵列需要进行哪些操作?
解答一:
AFM 用于在集群间传输数据. 如果是把一个集群内的数据, 从传统存储阵列迁移到闪存阵列, 不需要 AFM 功能.
解答二:
原有存储是否是 GPFS 文件系统? 是否是 nsd 格式的磁盘, 如果不是, 那么不适合用 GPFS 和(或)AFM 迁移
4, 如何有效利用闪存的 io 性能?
解答一:
将多个闪存盘做 RAID 保护, 形成一个 ARRAY, 所有 ARRAY 均加入至同一闪存 POOL, 在 POOL 中划分 LUN,LUN 的大小尽量小, 将 LUN 分配给主机 OS, 在 OS 上建文件系统或者以裸设备的方式给数据库使用.
这样就尽量把数据都打散在所有闪存 SDD 盘中. 读写并发性能最大化.
解答二:
简单的说, 应用端要尽量的增加并发度, 服务器 CPU 核数, HBA 卡数量和磁盘 queue depth 值要遵循厂商建议, 基本上可以获取最好的闪存 IO 性能.
另一方面, 闪存主要适合随机小块 IO 读写, 因此适用场景一定要规划清楚. 对于高吞吐的顺序读写 IO 而言, 闪存并不会比传统阵列要好很多.
5, 现有的文件系统, 数据库系统都是基于传统的机械式磁盘来设计, 而 SSD 为了适应现有文件系统, 数据库系统, 必须在 SSD 内部增加一层 FTL, 这样限制了 SSD 性能的发挥, 如何让 SSD 极大发挥性能?
解答:
这个取决于 FTL 算法, 每个闪存阵列厂商都有自己的 FTP 算法, 算法好的, SSD 性能也能得到极大发挥, 算法差的, SSD 性能也会差别很大. 这些都属于机密性的东西, 我们用户唯一能做的就是对他们的闪阵做测试, 测试他们主控中 FTP 算法的优劣. 重点是测试不同页面大小的随机写操作.
6, 全闪存存储阵列如何保证数据安全? 容错如何实现?
解答一:
采用虚拟网关 + 闪存 + 中端备存储, 甚至 + DR 容灾架构, 保证三份数据冗余. 或者直接采用带异构虚拟化功能的闪存阵列 + 中端备存储.
如果只是简单的闪存阵列, 那和传统存储一样, 定期做数据备份的方式, 闪存 SDD 盘做 RAID 保护, 多配置热备盘.
解答二:
不管是传统存储还是全闪存, 数据的安全是存储设计的第一目标. 围绕这个目标, 存储内部会有很多机制, 类似 ECC 校验的功能, Cache destage/stage 设计机制等等. 目前的存储平台, 在数据安全性上, 应该是没有问题的.
容错, 这是一个很大的话题. 存储架构本身, 主要部件都是冗余设计, 可以实现一定的容错. 对于应用而言, 数据层面的容错, 大部分都是通过 log 机制来实现 recovery, 比如文件系统的缓存, 数据库缓存等等. 存储层, 内部也有很多机制来实现写入的数据的一致性或者说容错. 比如说端到端的校验, PI, 就是在数据传输过程中增加校验值, 到底存储后进行比较, 来确认数据的传输的完整性. 存储内部呢, 前端 ->Cache->后端 ->磁盘, 都有类似校验机制. 就像我们通常说的数据块的最小单元是 512 byte, 但是存储内部处理起来, 可能是 520/528, 甚至更多 byte 的格式, 都是为了实现数据校验功能.
7, 闪存的可靠性如何保证? 传统机械式磁盘比较可靠, 不存在写次数的限制, 但是电子式的闪存存在写次数的限制, 这样对闪存 SSD 的寿命有影响, 即可靠性存在影响, 尤其是热点数据的写入更是如此. 如何解决这个问题?
解答:
现在的闪存技术已经基本可以规避掉 SSD 寿命和数据坏块问题了. 数据坏块和寿命耗尽的数据块, 会重新写入新的数据块, 坏块会自动标记为故障点, 不再使用. 整个 SSD 盘寿命也越来越长了, 甚至比机械磁盘更可靠, 更不易坏. 即使单个 SSD 出现故障, 多块 SSD 间也通过 RAID 技术保持冗余. 所以 SSD 的可靠性是可以相信的.
8, 使用 SVC 对接高端的 DS8870, 会影响 DS8870 哪些特性? DS8870 属于高端存储, 在性能, 稳定性上都有较好的表现, 如果前端使用 SVC, 是否会影响 DS8870 的性能, 同时 DS8870 的哪些特性会受到 SVC 的影响?
解答:
前端接入 DS8870, 几乎不对 DS8870 有影响. 读 IO 是直接读 DS8870 的数据, 写 IO, 是写 SVC CACHE, 后续再刷入 DS8870, 接入 SVC, 可以理解为 DS8870 的写 CACHE 扩大了. 要说影响, 可能仅仅是 SVC IOG 两个节点间缓存同步微小的时延增加了. 所以性能的话, 几乎没任何影响.
稳定性的, 接入 SVC 可增加 DS8870 的可靠性, 可以通过 SVC VDM 将 DS8870 和某中端存储做镜像保护, 存储不再单点.
至于 DS8870 的功能性的话, 会影响 DS8870 的 METRO MIRROR 和 GLOBAL MIRROR 两地三中间的功能, 简单说就是引入 SVC,SVC 的 MM 和 GM 功能没有 DS8870 的强大.
9, 在存储双活保护上, 使用 DS8870 和 FS900, 在性能上是否存在拖后腿现象?
解答:
基本不会拖后腿, SVC 下的 DS8870 和 FS900, 读 IO 是在 FS900 上, DS8870 不参与, 写 IO 是直接写 SVC CACHE, 对主机端来说, 不知道写的是哪个存储, 写完这个 CACHE, 主机端就完成了本次写周期, 等到 CACHE 的水位线达到一定值时, 再一次性刷入后端 DS8870 和 FS900 中. 所以对于写来说, 只要 CACHE 足够, 写和读的比例不太高, 即使 DS8870 的写响应时间和写 IOPS 弱于 FS900, 但基本主机端是无法感受到的.
来源: http://stor.51cto.com/art/201804/569798.htm