GlusterFs使用解析，关于新版本部分Volume模式废弃！！
原创GlusterFs使用解析，关于新版本部分Volume模式废弃！！
原创
##本文纯手工制作，转载请注明出处！且不可转载为收费，技术共享无边界，作者范体贴。
开篇先大话说一下，希望没了解过GlusterFs的朋友，对这个分布式文件系统能有一个初步了解！
什么是GlusterFs？
下面我们看看Gluster是怎么介绍自己的
GlusterFS is a scalable network filesystem suitable for data-intensive tasks such as cloud storage and media streaming. GlusterFS is free and open source software and can utilize common off-the-shelf hardware.（原文）
翻译出来就是GlusterFs是一种可以伸缩扩展的网络文件系统，适用于流媒体和云存储等数据密集型存储。免费的开源软件，可以使用普通的硬件。（英语水平有限，翻译如果有误差，敬请谅解）
特点：-可扩展为PB级的存储
-支持大量用户访问
-POSIX兼容
-使用商品硬件
-可以使用任何支持扩展属性的ondisk文件系统
-可使用NFS和SMB等行业标准协议访问
-提供复制，配额，地理复制，快照和位置检测
-允许优化不同的工作负载
-开源
企业使用可以根据实际情况扩容，无供应商锁定，支持混合云，私有云，公有云，跨内部部署。
大家大致已经知道这是个什么东西了！！
关于使用方法我在这就不废话了，部署很简单，使用也很简单。如果很多朋友需要部署和使用方法，在文章留言，我会尽快将，使用说明和部署方法写篇文章。
接下来介绍模式：新版本中官方文档中已经表示有关于Strip的所有模式废弃，将Strip更新为Dispersed模式。网上很多的教程也没有更新，大部分还是Strip模式的，为了不让大家像我刚开始一样，误入歧途，发布此文章！！
新的Volume模式减少为四种如下：
1、分布式卷（Distribute）——分布式卷将文件分布在卷中的单元之间。您可以使用分布式卷，其中需要扩展存储，冗余不是很重要，就是由其他硬件/软件层提供。
2、复制（replicated）——复制的卷在卷中的砖块之间复制文件。您可以在高可用性和高可靠性至关重要的环境中使用复制卷。
3、分布式复制（Distribute Replicated ）——分布式复制卷跨卷中的复制块分布文件。您可以在需要扩展存储且高可靠性至关重要的环境中使用分布式复制卷。分布式复制卷在大多数环境中还提供了更好的读取性能。
4、分散（Dispersed）——分散的卷基于擦除代码，提供空间效率高的磁盘或服务器故障保护。它将原始文件的编码片段存储到每个块中，这种方式只需要片段的一个子集就可以恢复原始文件。在不丢失对数据访问的情况下丢失的块的数量是由管理员在卷创建时配置的。
5、分布式分散卷（Distribute Dispersed）跨分散的子卷分发文件。这与分发复制卷具有相同的优点，但是使用分散将数据存储到块中。
关于分散模式：
Redundancy
每个Dispersed Volume都具有在创建卷时定义的Redundancy值。此值确定在不中断卷操作的情况下可以丢失多少Bricks。它还使用以下公式确定卷的可用空间量：
<Usable size> = <Brick size> * (#Bricks - Redundancy)分散组的所有Bricks应该具有相同的容量，否则当最小的Bricks变满时，分散组中不允许有额外的数据。
值得注意的是，具有3个Bricks和Redundancy1的配置将比具有10个Bricks和Redundancy1（90％）的配置具有更少的可用空间（占总物理空间的66.7％）。然而，第一个比第二个更安全（大致是第二个配置失败的概率，如果比第一个配置大4.5倍）。
例如，即使两块Bricks无法进入，由6块4T Bricks和2 Redundancy组成的分散体积也将完全可操作。但是，第三个无法访问的Bricks会降低占用，因为它无法读取或写入。卷的可用空间将等于16TB。
GlusterFS中的擦除代码的实现将Redundancy限制为小于#Bricks / 2的值（或等效地，Rendundancy* 2 <#Bricks）。Rendundancy等于Bricks数量的一半将几乎相当于Replica-2 Volume，并且在这种情况下复制卷可能表现更好。
Optimal volumes
擦除代码在性能方面最糟糕的事情之一是RMW（读 - 修改 - 写）循环。擦除代码以特定大小的Bricks运行，并且不能与较小的Bricks一起使用。这意味着如果用户发出未填满整个Bricks的文件的一部分，则需要从文件的当前内容中读取剩余部分，合并它们，计算更新的编码块，最后，写出结果数据。
这会增加延迟，从而降低性能。某些GlusterFS性能xlator可以帮助减少甚至消除某些工作负载的此问题，但在针对特定用例使用分散卷时应该考虑到这一点。
分散卷的当前实现使用的块大小取决于Bricks数和Redundancy：512 *（#Bricks - redundancy）字节。该值也称为strip大小。
使用为条带大小提供2的幂的#Bridge /Redundancy组合将使分散卷在大多数工作负载中表现更好，因为以两个为一的Bricks（例如数据库，虚拟机）。
这些组合被认为是最佳的。
例如，具有6块Bricks和Redundancy2的配置将具有512 *（6-2）= 2048字节的Strip大小，因此它被认为是最佳的。具有7块Bricks和Redundancy2的配置将具有2560字节的Strip大小，对于许多写入需要RMW循环（当然这总是取决于用例）。
配置这两种模式会出现的问题：
There isn't an optimal redundancy value for this configuration. Do you want to create the volume with redundancy 1 ? (y/n)
如果未指定Redundancy，则会自动计算为最佳值。如果此值不存在，则假定为“1”并显示警告消息
The optimal redundancy forthis configuration is2. Do you want to create the volume with thisvalue ? (y/n)
在自动计算Redundancy并且不等于“1”的所有情况下，都会显示一条警告消息
Redundancy必须大于0，并且Bricks的总数必须大于2 * Redundancy。这意味着分散的体积必须至少有3Bricks。
如果未指定传输类型，则使用tcp作为缺省值。如果需要，您还可以设置其他选项，就像在其他卷类型中一样。
##更新的两种模式介绍就到这，内容有错误，或者缺少什么，留言沟通，我会及时更改。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。