cpc1989
作者cpc19892020-05-18 14:26
存储工程师, 某保险公司

金融行业存储架构升级、替换、迁移难点问题在线答疑活动问答集锦

字数 4682阅读 2802评论 0赞 0

前言

随着金融业务的开展对于 IT 系统的依赖程度越来越高,金融机构需要确保其数据尤其是核心生产数据的高度安全、可用。而在数据爆炸式增长和数据存储设备的更新换代的趋势之下,原有的数据存储不可避免地需要升级、扩容和替换调整。为了高效、安全、完整地完成存储架构升级、替换、迁移的目标,运维人员不仅仅需要有合理的替换迁移策略来指导,还需要有着一定的运维经验积累。在存储架构升级、替换、迁移工作中,主要存在着如下几个方面的难点和问题:

1) 存储架构规划方面的困惑和疑虑

2) 存储替换迁移方法的比较

3) 存储架构升级替换过程中的影响性分析

4) 如何控制存储替换迁移的风险

5) 如何开展存储替换迁移测试工作,如何更好地制定存储替换迁移计划

结合上述这些问题,本次活动将从这些方面展开交流,旨在为同业在此类项目规划、建设、管理过程中提供一些启示和帮助。

以下是此次探讨中大家研讨关注的几个典型问题及嘉宾解答:

一、 存储架构规划问题

1. 对中小金融机构来说,应如何看待存储设备的国产替代趋势以及分布式存储架构转型?存储架构应该如何调整?

答:在当前国际形势下, IT 设备的国产替代和自主可控已上升到国家战略层面。在集中式存储这一块,国产存储的市场占有率比较低,用户评价方面好感度也不高;而分布式存储作为新技术的代表,国产厂商布局较多,但成熟度方面也有待考量。

而技术的成熟度是需要市场去培育的,是需要时间去打磨的。无论是国产 SAN 存储,还是分布式存储,其技术成熟度都会逐渐被市场接受。对于中小金融机构来说,试错的成本较高,引入新技术的阻力也会较大。但也应该做好技术储备,积极交流学习,在合适的时机逐步引入新的技术架构。

2. 对象存储与传统存储的定位是什么?

企业在进行存储选型时,如何针对对象存储和传统存储进行选型?分别适合哪些场景?

答:一般来说,对象存储主要集中在一些互联网业务场景,与云平台联系比较紧密,另外在非结构化数据的存储方面也有自己的优势。而目前传统的 IOE 架构的业务场景,一般还是采用的传统存储。
对于存储选型来说,除了业务场景的适用性以外,不同的企业的决策者对于产品可用性,稳定性,效率,性价比,创新性,扩展性,厂商的信誉等等多方面都会各有侧重,各有取舍。

3. 存储升级时继续考虑集中式?还是考虑分布式?超融合?

公司存储用的是低端存储,随着业务量的增加,和存储使用年限的久远,有必要着手考虑存储升级换代的必要性,现在用的是集中式 SAN 架构,新升级的存储是继续选用集中式 SAN ?还是选用超融合架构?有点理不清头绪,亟待大佬指点一二。

答 1 :一般来说沿用原来的技术比较容易让人接受,而原集中式 SAN 架构是否存在着使用上的痛点,这是存储架构替换的一个关键考虑的方向
二是超融合架构是否更适合,性价比更高,这个方向就要更深入地学习和评估了。可以研究的方向包括原有 SAN 架构的性能怎样,新架构性能提升多少,新旧架构在异常情况下的表现各是如何,新旧架构下不同厂商的产品怎样等等,要有针对性地对比。

答 2 :我个人是偏向比较传统的集中式 SAN 存储,是因为遇到了这样一件事
我公司负责某人社局的一个项目,是一套 vmware 虚拟化,然后项目初期挂了一套华为的分布式存储系统,大概是 10 个节点吧,后期扩容了一套华为 18500 存储。分布式存储是万兆光口, 18500 应该是 16Gb 的 FC 。之前测试的读写速度忘记了,反正分布式的读写速度与 18500 相比,差的不实一星半点。。。

3. V7000 存储与存储之间进行 Mirror 的好处有哪些?

IBM 的 V7000 存储使用率很广泛,但是一般都是单机使用,如何通过 V7000 存储之间的 mirror 实现数据高可用?好处有哪些?

答 1: V7000 集成了 SVC 的功能,异构存储迁移比较简单。 mirror 的好处对于高可用来说比较好点吧

答 2 :存储镜像的作用是应对存储单点故障的异常情况,能一定程度上保障数据安全和存储高可用。
对 V7000 来说,两台 v7000 存储设备一主一备建立 lun 的镜像关系,故障切换时则将主机和备用存储之间的映射关系打通,一般来说 RTO 要求不高的情况可以这样实施;
如果要提高异常恢复的 RTO ,可以两台 V7000 做 hyperswap 的存储双活架构或者借助其他存储虚拟化设备来实现异构存储双活

二、 数据迁移方法问题

1. 公司准备上 vplex metro 了,请教下数据迁移问题?

当前生产环境:
1 当前正在使用的机房中有 2 套 SAN SWITCH 多套存储
2 另一个机房同样有 2 套 SAN SWITCH 多套存储
数据类型:

  1. 虚拟化平台 LUN
  2. 物理数据库 LUN
    虚拟机用 Storage vmotion 是可以迁到 vplex metro 镜像 LUN 上 但是花费的时间太多了
    请教下可以直接挂到 vplex metro 镜像 LUN 上面吗?停机时间可以考虑 同样的问题物理机的 LUN 可以做吗?

物理机上的 LUN 是否有其他好的方法迁移到 VPLEX METRO 镜像 LUN 中?

答: 不管是虚拟机还是物理机,离线方案的话,就是停应用,主机上删盘,更换存储多路径软件 ( 虚拟机一般用自带的存储路径管理 ) ,修改存储 mapping 和 zone ,将原分配给主机的 lun 分配给 vplex , vplex 再整盘封装,添加镜像,再重新分配给主机识别 lun ,启应用。 VPLEX 对后端存储系统的磁盘设备采用整盘封装的方式,应用系统可以回退到实施前的直接访问后端存储系统的状态。
离线方案的优点是实施快,但需要做好数据备份和配置备份,实施前可以测试一下。一般来说 VPLEX 离线应用系统迁移的方案也比较成熟了,只要做好检查,风险也小。但要注意一些特别的情况,比如 VMware 的版本较低的情况,存储路径管理可能有问题。

2. 刀箱的盘阵列上的存储数据,如何迁移到新的存储上?需要考虑哪些问题?

答:新旧存储设备之间如果没有直接的数据迁移工具或者存储虚拟化设备,采用什么样的数据迁移方式更多的还是看上层的系统类型和数据类型。比如虚拟机系统可以 Vmotion ,数据库,操作系统可以备份恢复,文件系统可以 cp , sync 等工具。

3. 在高端存储上的数据常用的几种迁移模式有哪些?

答:存储虚拟化技术可以通过存储卷镜像高效地更换存储,而且架构成熟之后,在线存储迁移很容易做到。当然不同企业在设备选型方面差异较大,存储架构也要提前做规划

4. 大数据存储系统的迁移是如何做的?

公司大数据平台数据量有数十个 T ,用的传统 X86 服务器本地盘,现在有迁移至分布式存储的打算,但这庞大的数据量和不宽裕的时间窗口让人犯难,不知道有没有好的办法,可以完美的解决这两个毛矛盾点。

答:大数据的存储迁移还是应该更多地从大数据系统层面或者业务层面去找数据迁移的方法,而且数据量庞大和时间窗口不多的现状下,也要考虑规划周全分批分步骤来迁移

5. NAS 上 2PB 非结构化数据迁移至对象存储,如何保证业务零中断?

答: NAS 迁移到对象存储,一般来说上层业务系统是要修改数据访问接口的,没法保证业务零中断。但是如果是一些特定场景的话,比如业务数据访问还是 nas 方式, NAS 存储作为中转站,但是通过数据归档等手段迁移到对象存储,这种方式是可行。

6. vmware5.1 升级到 6.5 数据怎么迁移好一些?

公司有一套老的集群 4 台服务器 +2 台存储,运行的是 vmware esxi5.1 ,最近新购进一套集群 3 台服务器 +1 存储。现在想把旧的数据导到新的集群里,我能想到的就是用 p2v 一台一台机器的搬。各位大神有啥好的办法或者是有过这方面的经验求指导一下。多谢

答 1 :方案供参考:新存储上划分空间老集群,然后 vmotion 迁移老集群的主机到新存储上,再把这块空间分配给新集群,关闭老集群虚机,从这块存储中找到虚机文件,在新集群拉主机。具体实施前最好测试验证下可行性,熟悉下具体操作。

答 2 : 6.5 的 vcsa 应该可以添加 esxi 5.1 ,虚拟机直接在线 vmotion , cpu 迭代太多就开 evc ,或者关机 vmotion ,就算是克隆虚拟机也比 p2v 强一些

三、 替换迁移风险问题

1. 异构存储之间的数据迁移有哪些要注意的风险点?

EMC 存储要往 NetApp 存储上迁移,准备不动应用,在 Linux 的 LVM 层面做迁移,有没有哪些风险点需要重点考虑的?

答:首先是存储和系统的兼容性,存储多路径软件以及 HBA 微码等等要确定好;
其次基于操作系统层 LVM 的数据迁移,其实就是 LVM 配置修改,做好数据备份和配置备份,操作的脚本要好好核对;
另外,在线迁移对上层应用是透明的,但是变更风险也较高,估算好操作时间,选好变更时间段。

2. 结合实践谈谈,存储架构升级、替换、迁移的风险具体有哪些?在项目实施过程中应该如何规避?

存储架构升级、替换、迁移的过程,很多时候对于应用来说是透明的,但是这个过程中是存在着很多未知风险的。在具体的实践过程中,到底存在着哪些风险,又该如何规避?

答:兼容性风险:存储替换升级需要通盘考虑系统之间的兼容性,比如存储微码升级工作,要关注连接存储的所有主机,确认与操作系统的兼容性,主机存储驱动程序的兼容性, HBA 硬件微码的兼容性,存储虚拟化设备的兼容性等等。兼容性风险有些表现很明显,而有些则是隐性的,但都会在特定场景下造成很大的麻烦。
操作风险:比如迁移方案的不合理或者升级替换过程中触发了其他的风险隐患,从而出现了风险叠加。这样来看,迁移前的健康检查做的越细致,风险也会越小。
验证风险:实施完成后还需要细致的检查,如果验证不够仔细,风险也较大。

3. 使用存储网关,迁移异构存储需要考虑哪些问题 ?

答:如果使用存储网关的话,要查看兼容性列表,前期的梳理很重要。

4. 原 SAN 存储中有大量卷快照 / 精简卷 / 自动分层等功能如何规避迁移存储的风险?

原有生产 SAN 存储中存有大量卷虚快照 / 精简卷 / 自动分层等功能若迁移存储怎么做?如何规避迁移存储过程的风险?对象存储有无类似这些功能,怎么使用?

答:存储快照 / 精简卷 / 自动分层对于存储卷 lun 都是透明的,都是存储策略层面,这些功能不会直接影响到存储迁移过程。当然如果迁移的新存储有这些功能,重新新建适配的策略,也会方便存储管理工作的一致性。
对象存储有很多厂商的产品,也有开源的,部分高级存储功能也要根据相应的对象存储产品来确认。

四、 迁移测试问题

1. 存储替换迁移的测试工作如何开展?具体需要测试哪些方面,测试方法有哪些?

答:测试工作需要先确定测试目的,才能细化测试项。个人意见是测试至少需要验证其兼容性,性能等方面,确保替换迁移的方向不会有问题,同时可以获取设备的性能基线。另外还需要模拟测试,模拟存储替换迁移工作的每个步骤,一是熟悉整体操作流程,二是验证替换迁移方案,三是估算正式迁移的时间

2. 如何在不影响业务的情况下,进行升级测试?

答:一般来说在生产环境的升级测试需要谨慎,有条件还是专门的测试环境做可用性的验证测试

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

相关文章

相关问题

X社区推广