1、集中式存储向分布式存储的转型，有哪些技术难点和运维管理困难？
转型前期、中期和后期都有哪些注意的要点，对于渠道类、账务类和数据报送类业务，如何合理、分批次进行转型？
@zhuqibs Mcd 软件开发工程师：
技术难度： io的读写，集中存储中数据只要写入一个磁阵就算成功了，分布式存储中是写入大部分的节点才算成功，如果写入全部节点IO性能有影响，写入少量节点即是写入失败。
运维困难：监控上，要采用分布式prometheus来采集各个节点的数据，节点多的时候，监控范围较大。出现故障时， 要判断节点与节点间的相互作用，诊断难度加大。
对不同类型的数据应采用不同的迁移方式：
（1）对渠道类数据通常是多而散，通常分批迁移；
（2）对于账务类数据，通常是实时数据，需要保证其关联性和事务性，需要择业务运维窗口迁移，同时做好新老数据同步工作
（3）对于数据报送类数据，通常是交易历史数据等，可以择时一次性迁移。
在迁移前期，会有数据不同步的现象，需要新老系统并存；在中期，需要进行必要的数据校验和压力测试(分布式存储读写性能很重要)，后期在校验同步基础上，进行迁移（转型）的演练，将少量应用的数据源切换到分布式存储，进行预生产发布。
@宁泽阳 中信银行信用卡中心 系统工程师：
可以先行保留存储访问协议不变，先将集中式存储转为分布式存储；然后在稳定运行一段时间后逐步将存储协议转换为适合分布式存储访问的对象存储协议。
2、分布式存储如何做好集群运维？
@he7yong Canway 研发工程师：
分布式存储做好集群的运维非常的关键，因为正常情况下一个分布式存储是运行一个节点挂掉，如果多个节点挂掉，将会导致分布式存储的灾难。
我的推荐如下：
1.保障性运维，关注在节点服务器的稳定运行，如机器，磁盘，SSD，RAID卡，电池等等，这些关键组件的状态监控；故障后及时的处理；
2.标准化故障处理、增加节点的流程；
3.建立存储服务交付，存储使用配额的管理等等。
@kw002007 存储架构师：
1、良好的架构设计 运维成功的一半；
3、及时处理小问题；
4、熟悉技术原理，避免小问题引发大的故障。如硬盘损坏导致集群整体性能问题。
3、集群规模控制在多少节点，即可以发挥分布式多节点IO的性能优势，又可以防止集群过大造成性能下降？
@宁泽阳 中信银行信用卡中心 系统工程师：
一般推荐的集群规模为20个节点至30个节点，超过30个节点后扩容及故障带来的数据重分布数据量会很大，耗时较长，增加了存储访问不稳定性。
4、如何防止单个磁盘访问缓慢影响整体集群性能？
@宁泽阳 中信银行信用卡中心 系统工程师：
可针对磁盘IO情况设置监控阈值，当磁盘读写IO延迟过大时将其自动标记为out状态，以避免使用该性能差的磁盘，但需注意标记为out的单集群内磁盘存在上线值，该操作只可以进行1次，以避免将多个副本同时标记为out或网络抖动导致大量磁盘被标记为out影响集群整体不可读写。同时，标记为out后续尽快进行更换硬盘及数据重分布操作，防止此时集群内出现第二块满盘而该功能不可用。
5、分布式存储是否需要备份？如果需要的话有哪些常用产品？
@niupengju 银行 研发工程师：
备份的需求是基于数据重要性和系统稳定性。正常来说是需要备份的，即使分布式存储拥有多副本，保证一定的数据可恢复性。但是为了安全期间，防止整个系统的宕机，还是要备份的。备份的选择，主要考虑两个方面，一是分布式存储系统自身支持的备份恢复及双活，可以保证应用系统的稳定性。二是选择第三方备份软件。
@宁泽阳 中信银行信用卡中心 系统工程师：
是否需要备份建议针对业务系统保存的数据重要性级别而定，如业务系统数据需进行本地、同城或异地备份，那么建议在应用端对需要����,France备份的数据进行统一备份，存储端不进行备份，这样可保持整体备份架构统一性，避免备份大量无用数据造成备份设备容量浪费。应用端备份时可使用统一备份软件，如NBU、TSM等。
@anthonyhenry 系统架构师：
依然需要备份，分布式存储的副本或纠删码是防止存储部件损坏造成数据丢失或业务暂停，哪怕分布式存储启用快照功能，也是无法防止物理故障。备份的意义在于使用与存储完全隔离的故障域来保护数据，分离的存储操作系统，不同的物理设备，不同的物理区域，以防止物理故障，逻辑故障。
方式的话有：
1.备份软件+硬盘设备或磁带设备；
2.存储之间的复制；
3.以及现在新的存储至对象存储方式，其本质是存储自带备份小软件将属于备份到硬盘设备的方式。
6、分布式存储节点超过内部通信交换机端口上限后，如何扩展内部通信交换机？业务量大时交换机节点间通信是否会受阻？
@宁泽阳 中信银行信用卡中心 系统工程师：
需要扩容内部交换机，分布式存储的交换机扩展方式与业务交换机的扩展方式都是一致的，最好在网络架构规划时预留交换机在线扩展条件（包括交换机端口等），以避免停机扩容带来的存储不可用。
7、如何做包括元数据在内的数据迁移？
@zhuqibs Mcd 软件开发工程师：
打个比方，大数据的cloudera集群，由于是商业化产品，通常有高可用，namenode都是高可用的，所以，你如果要搬机房迁移的话，我们做过（这是一个悲剧，机房租用期到了），可以先迁移一个namenode，保证网络畅通（幸好是迁移到隔壁机房），再迁移另外一个，然后再迁移各个datanode，基本用户无感知。
@宁泽阳 中信银行信用卡中心 系统工程师：
还是需要结合当前元数据的存储方式和数据迁移的目的综合考虑。
8、AI训练或大数据分析是直接使用对象存储好，还是先把数据抽取到本地文件系统好？
@zhuqibs Mcd 软件开发工程师：
抽取到本地存储，这绝对不是一个好的主意，大数据平台的数据量十分庞大，所进行的操作涉及的数据，少则几个G，多达几十个T，如此多的数据，就算你本地存储够大，请问抽取传输要多少时间。
所以，必定是在计算节点进行分析，可以的话，可以调用有GPU的计算节点进行AI训练。至于对象存储，是可以的，现在aws上大数据分析，有的就是基于对象存储。
@宁泽阳 中信银行信用卡中心 系统工程师：
这个需要结合数据量的大小和本地文件系统和对象存储的访问性能来共同决定。如果数据量过大已经超出了本地文件系统的支持容量，那么就要使用对象存储。本地文件系统如果性能好很多，而数据又需要频繁读写，可以将数据预加载到本地以提升性能。
9、分布式存储场景中是否也可基于AIops进行一些智能运维？有什么建议？
在金融行业目前也有蛮多分布式存储集群案例，那基于存储所关心的集群存储服务故障自愈、磁盘故障的SMART预测是否也可以借鉴这套算法模型去设计？
cherrylook 中国人寿保险集团 软件架构设计师：
算法本身与数据是如何存储的并无直接关系，基于分布式存储的大数据平台正是机器学习、智能运维分析的奠基石，大量、丰富、有效的数据为算法分析提供了分析的可能。磁盘故障的分析需要首先观察磁盘历史数据的趋势及分布，选择相应算法可以实现有效的预测。故障自愈部分的建设需要结合专家建议，给出特定场景下故障自愈方案才可以落地实现。
10、从运维的角度看，分布式存储设计时要考虑哪些方面？运维管理中的监控告警、备份恢复与异地容灾等应该如何规划？
@zhuqibs Mcd 软件开发工程师：
结合流行的ceph分布式做解释：
（1）分布式存储监控: 搭建分布式存储的开源软件通常都是服务器，是以服务器自有磁盘来做存储的，所以监控可以在服务器的磁盘上设置，同时，我们同样可以用prometheus+grafana的方式进行监控，部署开源的ceph_exporter服务。
（2）备份和恢复：分布式存储是不需要备份的，因为故障本身就在其软件设计的计划中，比如ceph，设置2到3个mds+monitor，4~5个osd，坏了几个节点，可以从其他节点恢复。
（3）异地灾备：比如ceph的RBD快照技术，通过差量文件的方式定期将数据备份到灾备中心，当主数据中心发生故障时，从灾备中心恢复最近的备份数据并重启相应的虚拟机，最大程度降低灾难时的数据恢复时间。
@宁泽阳 中信银行信用卡中心 系统工程师：
在设计时应考虑到网络架构对性能的影响、监控内容的合理性、运维的便捷性等方面，监控告警主要为硬件类告警、操作系统告警、应用告警、性能容量告警几大类，针对备份恢复及异地容灾建议在应用客户端进行按需备份容灾。
11、如果选择基于开源软件的分布式存储技术路线，如何做好运维人才队伍建设？如何做好软件产品平滑迭代？如何构建企业基于开源分布式存储系统的业务生态？
@宁泽阳 中信银行信用卡中心 系统工程师：
对于人才建设：
1、找一两名在其他公司有实际落地经验的带头人，最好在社区比较活跃，负责项目规划
2、招聘几名应届实习生负责项目实施，这个过程一般会有新人脱颖而出
对于产品迭代：
只进行非常有必要的升级迭代，避免陷入无限升级的困境，同时在项目规划之初考虑升级迭代的方式，对于分布式系统，逐台升级一般不影响业务使用
对于构建业务生态：
由技术部架构选定场景，制定进相应技术规范中，并由开发、运维进行落实。