【问题详述】我们现在用的netapp的nas存储，总的空间是40T，空间已经接近分配完，但整个存储空间使用才50%（都是以NFS的形式分配给不同的业务）。现在再有新业务新需求了，没有空间可以分配了，这种问题咨询了厂家，说是收缩卷的空间可能不好操作。所以我们面临着NAS扩容的问题。问题来了，领导觉得我们的扩容不能被NETAPP品牌绑架，问下各位专家，有已购扩容的方法或者案例吗？
@Jerry某保险公司信息技术高级主管：
NAS品牌扩容能不能不被品牌绑架？几乎不可能，暂且不论能不能混用其他品牌扩容柜，就算能混用，敢不敢混用都是一个问题，出了事谁承担？传统NAS除了扩容就是购买其他品牌的设备了，没法在一个品牌的机头上混用另一个品牌的扩容柜。收缩卷的操作都是高危敏感操作，极容易出问题，不要轻易尝试。
@王国明戴尔科技集团高级系统工程师：
传统的NAS一定会面临扩充的难题，特别是在现阶段大家数据飞涨的阶段。建议你对你的应用进行评估，看是否选择基于分布式的数据湖技术，从而一劳永逸。给你带来的优势主要有：
1、方便扩充，容量和性能线性扩充；
2、方便扩充节点（60秒）；
3、以后不再需要数据迁移，这一次迁移数据你可以选择基于快照的方式迁移，速度还可以；
4、其它的优点，比如可以随时调节容错级别，新协议支持等等。
【问题详述】对于影像、保单等产生大量非结构化数据的业务系统来说，有没有经验或者数据可以参考，NAS文件数量或存储容量在怎样的数量级，NAS存储可能会出现明显的瓶颈？
1，性能瓶颈，NAS机头的瓶颈始终有限，扩容柜能持续扩容，NAS机头不行。
2，NAS底层文件系统的限制，最常见的就是单目录下文件数量超过限制了，同时文件数量增大到一定量级，读写效率明显降低。
3，备份问题，也是受限于机头和备份方式，再就是NAS文件系统的访问机制，整体效率特别低。
对于传统NAS存储，主要看底层文件系统的单目录下最大文件数限制，尤其是影像、打印这类系统，一旦共享目录下文件数接近或者超过最大文件数限制，访问效率明显下降。其次，非结构化数据的规模和体积会对NAS性能有明显影响，同是同一文件数量规模的影像件类和打印报文结果类非结构化数据，打印报文结果访问效率更低。
@白光茁戴尔科技集团高级系统工程师：
一般情况下，我这边的经验是百万量级的文件。但是具体还是要看企业内部对未来IT技术路线的看法和企业的实际情况。从目前市面上成熟的存储技术来看，在海量非结构化数据的长久保存这个场景，基本上就是对象存储这个选择，因为不管文件是几万量级，还是几十亿量级，都能够很好的处理。在实际项目中，有的企业会优先选择解决当下碰到的问题，有的企业会考虑未来几年的架构的合理性，不同企业在进行技术选型的时候考量点不太一样，这个会导致技术路线的选择也不一样。用对象存储毕竟要涉及到应用访问接口的改造，有的企业在接口改造上困难很大，导致不得已继续使用NAS。我自己就碰到过有的企业的软件开发商破产，导致无法升级改造的事情。
NAS，或者说传统NAS有很多局限，这也是分布式系统在创建之时就有的追求，目的在于解决传统NAS的这些问题：
1、性能依赖控制器，控制器会造成性能瓶颈，不能做大规模的并发负载分担；
3、多协议支持是硬伤，数据湖的访问方式才是符合大数据模式的，太多的数据迁移和复制会由于数据的规模越来越大变得不可操作。
3、非结构化数据备份策略及备份存储？
【问题详述】非结构化数据具有文件多且容量大的特点，无论是NAS还是对象存储，在数据备份策略和备份存储方面有没有合适的方案和经验可以参考？
主流的对象存储都是能够提供免备份功能的。一般对象存储都是分布式的架构，物理部件的故障不会影响的系统的运行，也可以通过跨站点复制实现站点级容灾。在逻辑保护方面，通过多版本功能可以实现误修改、误删除数据的恢复，也可以通过WORM功能来保证数据不会被恶意删除。
@cpc1989某保险公司存储工程师：
从个人运维经验来看，抛开存储系统本身存在的不可控因素，数据丢失也往往会发生在日常运维事件中，对象存储也不例外，免备份并没想象中可靠，可能并不适合于重要数据场景。
同意楼上，但是在做方案的时候，毕竟还是要考虑成本、运维等很多层面，对象存储主要面临的场景还是海量非结构化数据的存储。备份的基本逻辑就是把数据保留多份，所以我们面临的问题就是使用什么系统把海量的非结构化数据再保存一份甚至多份，而且还要考虑随着系统的增多，对运维管理和构建成本带来的提升，以及更多的故障点。当然如果数据量小的情况下，这些问题其实就不是很严重。
【问题详述】对于保险影像系统中存储的大量非结构化数据有无快速有效的备份方案，可以应对在线数据误删除、恶意删除、中病毒被篡改等问题？
对象存储备份和恢复则很依赖对象存储的接口和协议，业务条件允许的话，建议做好冷热分离和数据的归档。
@dawey某大型券商技术经理：
在海量文件环境下，传统的数据备份方案无法有效备份，对象存储采用多副本的方式进行逻辑故障防护。与传统文件存储相比，对象存储在海量非结构化数据长久保存场景下有着独特的优势。
如果底层的存储技术是对象存储的话，可以通过多版本的方式来实现数据防误删除，或者也可以通过WORM的功能来防止误删除和恶意删除。在病毒预防方面，对象存储在存储文件的时候是打散到不同物理节点来存放的，所以病毒文件无法感染同一存储内的其他文件，因此也可以有效的进行防病毒。
备份，换句话说，数据的安全以及历史数据的可访问，不管是不是海量，都需要考虑。由于数据的海量，会让一些传统的方式无法完成，而需要做出调整。一般说来，我们建议采用历史数据归档方式实现数据备份，传统的备份，会涉及到数据的封装，对于海量的数据会有性能和数据可访问性方面的难题，只会用在满足特定需求的数据保护上。而采用包括快照、多副本、同步容错、NDMP备份多种方式方式来满足不同的RPO/RTO要求。
曾有某创业公司怒怼某云，称其放在该云服务器上的数据全部丢失，给其公司业务带来灾难性损失。由此可见，一定需要进行本地备份，数据备份是最后手段，设备坏了可以换，数据丢了对公司来说是灾难性的。
从数据安全的角度，建议还是本地有一份备份，更为安全妥当。另外从保证业务连续性的角度，建议应用也在本地有部署。
取决于你的数据重要性，如果这个数据不能丢，不管你的租赁方给你讲他们有多可靠，你也需要有本地备份。同时，还需要考虑数据恢复的效率问题以及数据取回的成本问题。
对象存储主要面向的是海量非结构化数据的管理，由于数量量大，导致的备份、恢复问题以及长久保存导致的数据安全性问题，对象存储都能够解决。相对于传统存储而言，数据量越大，对象存储的优势体现的越明显。从某些层面讲，对对象存储而言，管理1PB的数据，需要1个人就够了，当数据量增长到了100PB，1个人也能够管理。
这是一个比较宽泛的问题，具体情况还是需要具体分析。传统NAS存在的局限主要包括：不支持更多的协议、容错不灵活、扩展不方便、元数据无优化等等，而这些是分布式解决方案的优势，再加上不需要数据复制而支持就地分析的优势，很多时候分布式是唯一的解决方案。而传统NAS的单流性能的优势，对于分布式或并行解决方案，需要采用闪存来提速，目前还会带来一定的成本上的提升。
金融行业一般考虑的顺序是安全性（监管要求）、性能、成本。如果存储的文件涉及敏感信息的，租用公有云肯定是不合规的。
对于性能，自建和租用都不是问题，要求性能越高，投入也就越大，这是成正比的。成本没有对比过。
云的话，初始成本低，可以按需购买，但无法符合金融行业的合规性要求，其次是上云容易下云难。
自建的话，初始成本高，且需要运维能力，轻松应对监管要求，能够实现一定的自主控制。各有利弊，看公司运营要求决定。从长久使用来看，自建和云综合成本不会有天差地别。
@crasyxbo网络工程师：
抛开金融行业的合规性要求。保险且经济的做法是：
1、本地自建公有云，都使用。
2、使用主要以公有云为主，自建以备份为主，可不用太过考虑性能，公有云异常，能撑起业务即可。
3、不管云还是自建，都建议自己搭建对象存储集群，可控性上的保障会比用公有云的产品强太多。也能有效减少后期的数据迁移成本。
不管是对象存储，还是其它存储，选型的基础条件是：“选择适合自己的产品！'而判断什么样的产品才是适合自己的呢，很重要的一点，是看“生态”，一方面是有前景的技术，另一方面是领先的技术，其三是有足够的人/厂商相互认证支持。Ceph作为一个被广泛使用/抄袭的系统，提供了块/文件/对象的所有支持，是它的优势也是它的劣势。优势在于要什么都有，劣势就是：“万金油，什么病都治，什么病都治不好”，比如在元数据优化、就地多协议访问等方面都存在问题。另一方面，还有一帮人，天天等开源社区解决他们的Bug。这也是很多金融业的用户选择成熟商业产品的原因。
不同的保险公司数据量的差异较大，是一个客观事实，即使是一家保险公司不同业务条线的数据也会存在不小区别。对于非结构化解决方案的选择，个人认为还是要根据企业自身情况出发，因地制宜，并没有一种万能的方案能够彻底非结构化数据的存储问题。
各保险公司非结构化数据常见的一个情况是，DC刚筹建那会儿体量不大，单证类非结构化数据一般简单的采用传统NAS来存储，随着业务的发展，受制于NAS机头的性能限制，各业务系统对单证的存、取、备均不同程度出现效率低下的问题，系统出现瓶颈。
总体而言，建设思路需要根据业务发展的需求、企业内部的人员知识储备、架构发展方向等综合来看。目前我看到比较多的企业采用的做法是资源池化，在基础架构层面尽量通过池化、标准化来构建存储资源池，来降低运维的难度和复杂度。
其实，就算是同一公司，非结构化数据也是十分复杂的，有效的数据存储、治理、共享、访问都需要在统一的架构下解决，这也是数据湖方案的重要作用，通过与后端存储架构与前端存储访问的解耦，数据湖平台对用户屏蔽了数据的复杂性。数据量本身也是建设中的难点，但数据湖方案通过前后一致的扩展方式，以及不停机的容量、功能扩展，确保能够实现“按需购买，即扩即用”，让系统建设“只顾目前的需求”就好了！
发展统一存储方案，我们也提出过，发现细化到各个系统时，就会与系统架构产生衝突。需要开发商做很多修改。有些费用还不少，有些会影响业务。综合权衡后，还是旧系统维持旧架构，新系统用新的统一存储。
你现在面临的问题实际上就是数据湖架构着力解决的问题。
各个系统的存储之间互相隔离「孤岛」，数据湖让已有系统在不安装任何驱动/代理的前提下采用标准的访问协议将数据放置到数据湖中。
当数据放入到数据湖以后，一方面能够被传统的系统共享，另一方面也可以供新形态的应用使用。包括如深度学习这类的应用。
数据湖支持几乎所有主流的访问协议。其核心就是实现数据同专有系统之间的解耦。
补充一下：对于统一架构，我的理解就是指Unified，这种架构实际上就是传统的NAS，当初是为了满足大家在同一设备中实现Block/File而诞生的，只能提供相对简单的文件支持能力，无法满足数据湖架构对众多的协议需求。而对于数据安全上面，统一存储一般是基于传统RAID的，这种方式在数据越来越大，磁盘也越来越大的现在，越来越有问题，大量新的技术希望能解决这种问题。
数据湖支持预置策略，支持安全策略随时调整。另一方面，对于数据权限、数据共享这类的安全，商业产品都能够做到企业级，不用太担心。
这个要看公司对云、自建机房、容灾中心、IDC机房的定位和将来的发展。其次就是对应用架构的梳理。假设在现有应用架构、数据中心架构保持不变的情况下，可以考虑用数据湖解决方案，既能在底层通过资源池化来简化运维提升利用率，又可以通过不同的协议接口对接新旧应用的需求。
6、对象存储的应用场景和行业内的应用标准？
问题2：对象存储与分布式文件系统的应用场景，也有厂商向我们推荐使用分布式文件系统来做影像存储？
问题1：对象存储的优势主要包括：Key的方式使支持海量的数据处理，容易扩展，天生支持多数据中心，短链接方式适合第三平台应用、多协议访问等等。如果你的需求中有以上的一条或几条，就需要评估是否需要对象存储了。影像系统是保险业传统的NAS解决方案的战场，但近年来，大家都在迁移到对象平台，主要的原因是文件系统太大，跑不动了。一般来说，当一个目录下的文件数超过百万级别，从最佳做法的角度，可能就满足迁移的一个前提了。
问题2：看你的主要应用。一般来说，对象存储主要使用对象协议，其它协议作为补充。分布式文件系统主要使用文件协议，同时支持其它协议，支持的对象协议一般是对象协议的子集。其二，你需要看应用，已有应用如果不改，一般来讲是支持文件的，这时候也可以选分布式文件系统存储影像，这也是主流解决方案。
主流对象存储均采用节点式横向扩展分布式架构，以实现从小规模到大规模（10PB级）的容量和性能扩展。为了实现海量非结构化数据管理，主流对象存储均采用分布式元数据管理方式，以使得存储系统在管理海量（亿级）文件时，能够实现访问性能的稳定性。
对象存储抛弃了传统的基于树状文件系统的管理方式，通过Key-Value的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。
此外在海量文件环境下，传统的数据备份方案无法有效备份，对象存储采用多副本的方式进行逻辑故障防护。与传统文件存储相比，对象存储在海量非结构化数据长久保存场景下有着独特的优势。
对象存储抛弃了传统的基于树状文件系统的管理方式，通过Key-Value的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。对象存储通过API接口进行数据访问，应用或者客户端可以直接调用访问数据，更加便捷，支持S3、HDFS、Swift等多种协议。
对象存储经常被比作在一家高级餐厅代客停车。当一个顾客需要代客停车时，他就把钥匙交给别人，换来一张收据。这个顾客不用知道他的车被停在哪，也不用知道在他用餐时服务员会把他的车移动多少次。在这个比喻中，一个存储对象的唯一标识符就代表顾客的收据。当需要获取数据时，只需要告诉对象存储这个唯一标识符，剩下的检索工作均由对象存储本身完成。
由于访问方式上不同，涉及存储变更后应用系统也需要进行访问方式上的改造，需要有一定的过渡期，同时也要考虑老数据的迁移问题。
在数据迁移的过程中，虽然数据的访问方式、数据的层次结构以及目录层级等会发生变化，但是整个过程都是可控的。在实际操作中，比较常见的有两种方案，一种方案是通过应用进行数据迁移，这种也是最推荐的方案，应用进行迁移的时候，可以根据业务的负载灵活的控制迁移速度，也可以在迁移过程中完成对每个对象数据的校验。第二种方案是由迁移工具进行数据迁移，这种情况下需要应用进行相应的配合，首先应用需要能够同时访问源存储和目标存储，并将新增数据写入到新的目标存储中，这样保证源存储内不会有数据的新增，同时通过迁移工具来进行数据迁移，并记录源和目标访问路径的变化，并在迁移完成后，交由应用系统来更新成新的访问路径，并确认从应用端能够正常访问目标存储。整个迁移视数据量的大小可能会分批迁移，从而保证数据迁移能够顺畅完成。所以我建议要讲数据迁移视为一个服务项目来根据实际情况来处理比较好。
在实际的项目里，源存储不一定是块、NAS这种存储，有可能是数据库、应用，所以具体到不同企业的实际情况，迁移方法可能有很大不同。
另外有的企业会在存储和应用之间设置一个轻量级数据抽象层，这个数据抽象层可以屏蔽底层数据存储的差异，对外提供统一的面向业务的应用访问接口，这个抽象层可以兼具数据迁移的功能，从而实现底层存储技术的更换，对上层的应用而言是没有任何感知的。
数据迁移的速度受限于源存储系统、迁移程序、网络和目标存储系统。一般情况下源存储系统会成为瓶颈，同时要保证业务能够继续对外提供服务，迁移不能对源存储系统造成压力，所以迁移的窗口都会非常长。常见的处理方法是通过修改应用访问存储逻辑，所有新增数据全部写入到目标对象存储中，旧的源存储里的数据只用于读取，不会有任何的新增数据，同时通过应用或者迁移程序进行数据迁移。
除此之外，还有的做法是把源存储或者系统的数据通过备份或者复制的方式，拷贝到一套新的系统中，专门用于数据迁移，但是这种做法投入会很高，用的也比较少。
再者就是从应用架构上解决，在底层存储系统和前端应用之间添加一个轻量级的数据抽象层，这个抽象层可以对外提供统一的数据访问接口。这个抽象层也负责在不同的存储技术之间进行数据迁移，这样不管采用何种的存储技术，都可以灵活的进行处理。
具体采用何种方式更优，还是要取决于企业的实际情况，所以我比较建议把数据迁移当成是一个服务项目来处理。
3、关于非结构化数据，存量数据如何从传统存储迁移到非结构化存储？
还有一种解决办法就是，在存储和应用之间引入一个数据抽象层，这个抽象层会对外提供一个统一的数据访问接口，来屏蔽底层存储技术。同时这个抽象层还可以进行数据迁移，这样保证不管底层存储技术如何变化，对外的服务是统一的。当然这个方法更多的是从应用架构上去进行处理，牵扯到的部门会非常多。
我这边做过的项目里，一般迁移方案分两种，第一种是由应用进行迁移，第二种是以迁移服务项目的方式进行迁移。基本的迁移思路是新数据写入到对象存储，老的存储只用于读取，这样整个迁移的数据集就是一个固定的数据集，这样便于并发进行迁移处理，在整个迁移过程中，迁移工具会保证数据能够完整把数据迁移到对象存储。我比较建议把数据迁移当成一个迁移服务项目来看，因为迁移过程还是有很多需要协调工作来做。数据的验证的话，迁移工具是会来做。但是在最终割接以前，还是要请应用部门也进行一次数据验证。
此外有的企业会在底层存储和上层应用之间添加一个很轻量的数据抽象层，来屏蔽底层不同存储技术的差异，对外封装成一个面向应用的统一访问接口。同时这个抽象层会提供数据在不同存储或者不同存储技术之间进行迁移的功能。这样不管是底层存储技术如何变迁，对上层应用基本是没有任何影响的。当然这种做法需要从整个应用架构角度去设计规划。具体采用哪种方案还是要取决于每个企业自己内部的实际情况。
采用数据湖的其中一个重要优势就是不再需要做数据迁移。而对于传统的解决方案，对于大量的非结构化数据迁移，是一个费时费力的工作。针对这种情况，我们提供了一些工具，帮助用户来做数据迁移，如基于快照和迁移、基于并行访问的迁移等等，需要根据具体的情况来选用。
1、DellEMCECS对象存储有什么优势？
DellEMC在Garner的分布文件&对象存储的魔力象限中多年一直处于领导象限的第一位置。这是市场对DellEMC对象存储的认可。ECS扩展了S3的支持：允许用户在bucket层面自定义元数据（metadata）.这些自定义的Metadata跟系统级的Metadata一道，可以让用户以更简单的方式从bucket中批量过滤并提取符合一定条件的对象。
PowerScale作为数据湖平台的核心组成部分，在保险行业有很多的应用场景，从传统的影像系统、数据分析到新型的用户画像、智能风控，都可以使用PowerScale来搭建数据湖平台。
PowerScale是新的平台，是基于Isilon的基础上的一次进化。PowerScale采用OneFS9.0，同时提供PowerScale专用硬件和Isilon硬件的支持，二者支持混装。OneFS9在继承Isilon以前的优点前提下，提供了诸多新的特性，如S3的支持，在线数据缩减等等。
在数据湖解决方案中，PowerScale会是我们Isilon、ECS、SDP的有力补充，提高了需求覆盖以及更好的投入产出比。