分布式存储，在无限横向扩容时 必然遇到元数据存储集中存储的瓶颈 如何解决？

首先必须表明我的观点，没有无限扩容，不存在的!

且不说在理论上有没有合理的“无限扩展”架构，在实际产品实现和生产部署中基本上是不可能实现“无限”的，连“线性”扩展都很难保证。有时看到互联行业动不动就宣传自己有几千台规模的部署，但往往是多个集群聚合在一起统计的规模，单一集群规模的大小通常不会太大，一旦过大，理智的架构师通常都会建议分成多个ZONE。不能无视管理上的困难和风险的增加。鸡蛋还是不要放一个篮子里，无论卖篮子的怎么说有多么可靠。

离开剂量谈毒性都是耍流氓，离开规模谈分布式也是同样。从实际项目部署来看，最常见的还是在几十台规模以内的，这个规模大小下保证容量性能“线性”扩展是最容易的。当然你可以分布式部署多个集群，统一管理，合并在一起对外宣称最大规模，也没啥问题。

回到问题的分析，具体来看，分布式存储基本上有两种架构分类，对称式和非对称式，取决于元数据节点和数据节点是否分离部署，两种架构需要分别分析。

问题中提到的“元数据集中存储”明显是非对称式架构，这种架构把元数据独立出来，部署于高性能的硬件节点，好处在于便于针对性优化。应对方案嘛一是升级硬件配置，比如多加点SSD，升级CPU内存。二是做元数据集群，这样元数据也能扩展，但这种方式技术含量更高，系统实现也更复杂。

另一种情况是采用对称式架构，元数据的功能模块打散，分布到每一台节点，每一台硬件节点既是数据节点也是元数据节点，当系统扩展时，两者同步扩展，这样猛一看起来就没有瓶颈了。
但瓶颈其实是转移了，转移到网络上。由于节点的功能都一样，互相之间必然存在大量的网络通信，既有元数据的少量数据包，也有数据的大量数据流，网络负载很大且混杂。而且存储内部的通信不仅是对网络带宽要求高，更重要的是对网络延迟的容忍度非常低，所以瓶颈很快就会出现在网络上。（规模越大，对网络的要求成倍增加，并不是线性的）这也是为何很多老牌的分布式存储商业产品要求部署Infiniband网络原因，不仅看上的是40GB的高带宽，更重要的是低延迟。即使是这样，老牌分布式存储iSilon的最大规模也限制为144台，并且实际部署中一般不会到达这个上限。

所以如果是打算建设一个分布式存储系统，最好还是对目标产品的最大扩展规模预先充分了解，理论值是多少，实际生产部署，最优实践是多少？还要同时考虑业务系统是否需要适配（比如同样做一些分布式的改造）。

理想的分布式集群是横向线性扩展，性能没有上限的，然而，在实际的应用过程中缺水存在元数据服务器的瓶颈。
以Ceph为例，根据Sage的论文，CRUSH算法具有相当好的可扩展性，在数千OSD的情况下仍然能保证良好的负载平衡。但这更多是理论层面的，目前还没有人给出在数PB规模的生产环境中的测试结果。

而华为公司的FusionStorage则采用另外一种思路——将元数据分散于集群中的各个服务器之上，每个服务器上部署一个VBS进程，负责卷元数据的管理。这样就避免了局部热点的出现。

目前市场上的scale-out NAS，采用全分布对称架构（即元数据和数据都是均匀分布都所有节点），这样就不会出现瓶颈

实际上，由于架构的不同，对称式的由于将元数据分布在各个节点上，导致集群规模大的时候，会有很大的内部通讯消耗。对称式架构的集群规模也就有了限制，看以前的isIlon，只能做到144.华为刚推出分布式存储的时候也所有参数都是isIlon两倍，也只能是256就是这个原因。
非对称式的架构，内部通讯由于元数据节点少，就不存在规模现在的问题。目前世界上最大的集群就是采用的非对称式架构的（具体记不清楚哪个了，记得冬瓜哥说过）。
对于元数据瓶颈来说，元数据一般也能采用集群模式。但是一般的hadoop，或者ceph等元数据一般采用主备的集群模式，导致这些分布式系统在面临海量小文件或者数据量很大情况时存在元数据瓶颈。
这点我司所采取的是元数据集群模式，多台元数据之间做互备，并且同时对外提供服务，倒是真正做到了元数据集群化。目前元数据虽然不是无限扩展，但是也 能扩展到几百台。目前产品化已经十年。相对目前的存储容量来说还是没有限制的。因为涉及具体细节，有兴趣可以找我们了解。

问题的确不太明确，现在100PB以下应该都不是问题。