精华内容
下载资源
问答
  • Longhorn 是用于 Kubernetes 的轻量级、可靠且功能强大的分布式块存储系统。 Longhorn 使用容器(containers)和微服务(microservices)实现分布式块存储。Longhorn 为每个块设备卷(device volume)创建一个专用的存储...

    Longhorn 是用于 Kubernetes 的轻量级、可靠且功能强大的分布式块存储系统。

    Longhorn 使用容器(containers)和微服务(microservices)实现分布式块存储。Longhorn 为每个块设备卷(device volume)创建一个专用的存储控制器(storage controller),
    并跨存储在多个节点上的多个副本同步复制该卷。存储控制器(storage controller)和副本(replicas)本身是使用 Kubernetes 编排的。

    功能特性

    • 无单点故障的企业级分布式块存储
    • 块存储增量快照
    • 备份到辅助存储(NFSS3兼容的对象存储)建立在高效的更改块检测之上
    • 定期快照和备份
    • 自动化(Automated)、无中断升级(non-disruptive upgrades)。您可以升级整个 Longhorn 软件堆栈,而不会中断正在运行的存储卷。
    • 直观的 GUI 仪表板

    Longhorn 是什么?

    LonghornKubernetes 的轻量级、可靠且易于使用的分布式块存储系统。

    Longhorn 支持以下架构:

    1. AMD64
    2. ARM64 (实验性的)

    Longhorn 是免费的开源软件。最初由 Rancher Labs 开发,现在作为 Cloud Native Computing Foundation 的沙箱项目进行开发。

    使用 Longhorn,您可以:

    • 使用 Longhorn 卷作为 Kubernetes 集群中分布式有状态应用程序的持久存储
    • 将块存储划分为 Longhorn 卷,这样无论是否有云提供商,都可以使用 Kubernetes
    • 跨多个节点和数据中心复制块存储以提高可用性
    • 将备份数据存储在 NFSAWS S3 等外部存储上
    • 创建跨集群灾难恢复卷,以便可以从第二个 Kubernetes 集群的备份中快速恢复来自主 Kubernetes 集群的数据
    • 安排卷的定期快照,并安排定期备份到 NFSS3 兼容的辅助存储
    • 从备份恢复卷
    • 在不中断持久卷的情况下升级 Longhorn

    Longhorn 带有独立的 UI,可以使用 HelmkubectlRancher app catalog 进行安装。

    使用微服务简化分布式块存储

    由于现代云环境需要数万到数百万的分布式块存储卷,一些存储控制器已经成为高度复杂的分布式系统。
    相比之下,Longhorn 可以通过将一个大块存储控制器划分为多个较小的存储控制器来简化存储系统,只要这些卷仍然可以从一个公共磁盘池构建。
    通过每个卷使用一个存储控制器,Longhorn 将每个卷变成了一个微服务。控制器称为 Longhorn 引擎。

    Longhorn Manager 组件编排 Longhorn 引擎,使它们协同工作。

    在不依赖云提供商的情况下在 Kubernetes 中使用持久化存储

    Pod 可以直接引用存储,但不推荐这样做,因为它不允许 Pod 或容器是可移植的。
    相反,应在 Kubernetes 持久卷 (PV) 和持久卷声明 (PVC) 中定义工作负载的存储要求。
    使用 Longhorn,您可以指定卷的大小、IOPS 要求以及在为卷提供存储资源的主机上所需的同步副本数量。
    然后,您的 Kubernetes 资源可以为每个 Longhorn 卷使用 PVC 和相应的 PV
    或者使用 Longhorn 存储类(storage class)为工作负载自动创建 PV

    Replicas 在底层磁盘或网络存储上进行精简配置。

    跨多个计算或存储主机调度多个副本(Replicas)

    为了提高可用性(availability),Longhorn 创建了每个卷的副本。副本包含卷的一系列快照,每个快照都存储来自前一个快照的更改。
    卷的每个副本也在一个容器中运行,因此具有三个副本的卷会产生四个容器。

    每个卷的副本数量可在 Longhorn 中配置,以及将安排副本的节点。Longhorn 监控每个副本的健康状况并执行修复,并在必要时重建副本。

    为每个卷分配多个存储前端

    常见的前端包括 Linux 内核设备(映射在 /dev/longhorn 下)和一个 iSCSI 目标。

    指定定期快照和备份操作的计划

    指定这些操作的频率(每小时、每天、每周、每月和每年)、执行这些操作的确切时间(例如,每个星期日凌晨 3:00),以及保留多少定期快照和备份集。

    展开全文
  • 分布式存储的对象存储、块存储、文件存储的各自优缺点、使用场景以及与传统存储架构DAS、SAN、NAS之间的关系介绍

    承接上文Ceph分布式存储系列(一):Ceph工作原理及架构浅析梳理

    分布式存储总体分为对象、块、文件三种存储类型,且ceph同时支持这三种存储类型,那么这里再简单谈一下三种存储类型的差异点及各自优势和适用环境。

    回顾存储史 之 三种传统的存储架构:

    了解三种存储类型之前,先来回顾下传统以来的 三种存储架构:

    • DAS(Direct Attached Storage) 传统的直连式存储,硬盘等物理存储与设备直连的方式,如个人电脑,普通服务器等
      • 连接方式:客户端 - - 物理硬盘
    • SAN(Network Attached Storage): 网络附加存储,后端存放大量的硬盘,通过用FC_SAN协议或者IP_SAN协议连接服务器的一种方式,客户端挂载后端存储服务器共享的卷,用来当做裸盘,格式化使用,成本高
      • 连接方式:客户端 - - FC光纤交换机 - - 存储服务器(默认模式为FC_SAN)
      • 连接方式:客户端 - - 网络交换机 - - 存储服务器(基于iscsi协议的IP_SAN模式,成本较低)
    • NAS(Storage Area Network): 存储区域网络,通过nfs或smb等协议共享目录的方式,可以理解为Windows中的共享文件夹,不能当做裸设备来用,可直接挂载使用,成本较低
      • 连接方式:客户端 - - 网络交换机 - - 存储服务器

    三种存储类型的原理 和 传统存储架构的关系

    • 块存储: 通俗来讲,单个硬盘或单个分区,可以支持单独格式化和挂载的块,即为块存储,例如lvm划分逻辑卷,ceph的创建rbd卷等,分区挂载等操作和本地硬盘设备没有什么区别,在传统存储架构中,DAS和SAN都算块存储的范畴
    • 文件存储: NAS就相同于文件存储,通过共享目录(文件夹)的方式,实现可以让多人操作的目的,大多数使用NFS、Samba等协议。因服务端共享的是文件夹,所以客户端就无需也不能再做格式化或者分区的操作,对客户端来说这只是一个远端的可存放数据的地方
    • 对象存储: 不同于传统架构的一种新型存储类型,扁平化结构,不需要去维护复杂的文件目录。用户数据存取方便,通过常用的S3协议,可通过URL来访问一个空间及其中的文件,适用于智能视频监控、web类应用等等

    三种存储方式的各自优缺点:

    块存储:

    主要是将一个裸磁盘空间(没有格式化文件系统的盘)映射给主机适用

    优点:

    1. 使用磁盘映射,如RAID/LVM的方式提供磁盘空间给主机使用,进一步维护了数据的安全性
    2. 因为是多块磁盘组合而成的逻辑盘空间,所以多块盘可以并行执行读写操作,提升IO效率
    3. 很多大型企业或数据中心使用SAN架构组网,数据传输速度和读写效率进一步得到提升

    缺点:

    1. 如果采取FC_SAN的方式,需要HBA光纤通道卡和光纤交换机,成本较高
    2. 不利于不同操作系统主机间的数据共享,例如Linux主机把盘给格式化为ext4格式,那么在Windows中对这个盘的操作使用就不太友好了,或者无法操作
    文件存储:

    为了文件共享而诞生的存储类型,如FTP、NFS、Samba

    优点:

    1. 成本低,随便一台服务器都可以来搭建
    2. 方便于公司内部的文件共享,内网云盘共享一些资料等等

    缺点:

    1. 受网络带宽影响,读写效率慢,传输速率稍低
    2. 所有客户端的读写操作都汇总到一台服务器中,一块或多块硬盘承担IO,压力大,速率稍低
    对象存储:

    结合了块存储和文件存储的优点,读写效率快,还支持共享

    优点:

    1. 后端使用大量硬盘组,且不受复杂目录系统影响,达到高水平的读写效率
    2. 集群可扩展性强,且支持多副本存储,保证数据安全性
    3. 通过URL直接访问存储文件,简单易管理

    缺点:

    1. 不适合存放内容变动性大的文件,不然每次变动都要重新更新上传对象,适合放静态的图片镜像等非结构性的文件
    2. 不太适合作为数据库存储数据使用
    3. 操作系统无法像常规磁盘一样安装或挂载对象存储

    三种存储类型的适用环境

    • 块存储:适用于存储量大,对读写效率要求高,且存储设备单独区域管理的企业,如银行等,多用来存放数据库数据信息
    • 文件存储:适用于需要访问和共享大量文件,且操作方便的企业环境
    • 对象存储:适用于搭建公有云或私有云盘,存放非结构化的大量静态文件

    各有各的优势,无优劣之分,根据不同的场景选择不同的产品即可~

    End……

    展开全文
  • 分布式存储简介

    千次阅读 2021-01-28 13:37:23
    一、概述 分布式文件系统是分布式领域的一个基础应用,...分布式存储 GlusterFS 介绍与部署 本文试图分析和思考,在分布式文件系统领域,我们要解决哪些问题、有些什么样的方案、以及各自的选择依据。 二、过去的样

    一、概述

    分布式文件系统是分布式领域的一个基础应用,其中最著名的毫无疑问是 HDFS/GFS 。如今该领域已经趋向于成熟,但了解它的设计要点和思想,对我们将来面临类似场景/问题时,具有借鉴意义。

    并且,分布式文件系统并非只有 HDFS/GFS 这一种形态,在它之外,还有其他形态各异、各有千秋的产品形态,对它们的了解,也对扩展我们的视野有所俾益。分布式存储 GlusterFS 介绍与部署

    本文试图分析和思考,在分布式文件系统领域,我们要解决哪些问题、有些什么样的方案、以及各自的选择依据。

    二、过去的样子

    在几十年以前,分布式文件系统就已经出现了,以 Sun 在 1984 年开发的“Network File System (NFS)”为代表,那时候解决的主要问题,是网络形态的磁盘,把磁盘从主机中独立出来。

    这样不仅可以获得更大的容量,而且还可以随时切换主机,还可以实现数据共享、备份、容灾等,因为数据是电脑中最重要的资产。NFS 的数据通信图如下:

    图片

    部署在主机上的客户端,通过 TCP/IP 协议把文件命令转发到远程文件 Server 上执行,整个过程对主机用户透明。

    到了互联网时代,流量和数据快速增长,分布式文件系统所要解决的主要场景变了,开始需要非常大的磁盘空间,这在磁盘体系上垂直扩容是无法达到的,必须要分布式,同时分布式架构下,主机都是可靠性不是非常好的普通服务器,因此容错、高可用、持久化、伸缩性等指标,就成为必须要考量的特性。

    三、对分布式文件系统的要求

    对一个分布式文件系统而言,有一些特性是必须要满足的,否则就无法有竞争力。主要如下:

    • 应该符合 POSIX 的文件接口标准,使该系统易于使用,同时对于用户的遗留系统也无需改造;

    • 对用户透明,能够像使用本地文件系统那样直接使用;

    • 持久化,保证数据不会丢失;

    • 具有伸缩性,当数据压力逐渐增长时能顺利扩容;

    • 具有可靠的安全机制,保证数据安全;

    • 数据一致性,只要文件内容不发生变化,什么时候去读,得到的内容应该都是一样的。

    除此之外,还有些特性是分布式加分项,具体如下:

    • 支持的空间越大越好;

    • 支持的并发访问请求越多越好;

    • 性能越快越好;

    • 硬件资源的利用率越高越合理,就越好。

    四、架构模型

    从业务模型和逻辑架构上,分布式文件系统需要这几类组件:

    • 存储组件:负责存储文件数据,它要保证文件的持久化、副本间数据一致、数据块的分配 /合并等等;

    • 管理组件:负责 meta 信息,即文件数据的元信息,包括文件存放在哪台服务器上、文件大小、权限等,除此之外,还要负责对存储组件的管理,包括存储组件所在的服务器是否正常存活、是否需要数据迁移等;

    • 接口组件:提供接口服务给应用使用,形态包括 SDK(Java/C/C++ 等)、CLI 命令行终端、以及支持 FUSE 挂载机制。

    而在部署架构上,有着“中心化”和“无中心化”两种路线分歧,即是否把“管理组件”作为分布式文件系统的中心管理节点。两种路线都有很优秀的产品,下面分别介绍它们的区别。

    1、有中心节点

     

    图片

    以 GFS 为代表,中心节点负责文件定位、维护文件 meta 信息、故障检测、数据迁移等管理控制的职能,下图是 GFS 的架构图:该图中 GFS master 即为 GFS 的中心节点,GF chunkserver 为 GFS 的存储节点。其操作路径如下:

    • Client 向中心节点请求“查询某个文件的某部分数据”;

    • 中心节点返回文件所在的位置 (哪台 chunkserver 上的哪个文件) 以及字节区间信息;

    • Client 根据中心节点返回的信息,向对应的 chunk server 直接发送数据读取的请求;

    • chunk server 返回数据。

    在这种方案里,一般中心节点并不参与真正的数据读写,而是将文件 meta 信息返回给 Client 之后,即由 Client 与数据节点直接通信。其主要目的是降低中心节点的负载,防止其成为瓶颈。这种有中心节点的方案,在各种存储类系统中得到了广泛应用,因为中心节点易控制、功能强大。

    2、无中心节点

    以 ceph 为代表,每个节点都是自治的、自管理的,整个 ceph 集群只包含一类节点,如下图 (最下层红色的 RADOS 就是 ceph 定义的“同时包含 meta 数据和文件数据”的节点)。图片无中心化的最大优点是解决了中心节点自身的瓶颈,这也就是 ceph 号称可以无限向上扩容的原因。但由 Client 直接和 Server 通信,那么 Client 必须要知道,当对某个文件进行操作时,它该访问集群中的哪个节点。ceph 提供了一个很强大的原创算法来解决这个问题——CRUSH 算法。

    五、持久化

    对于文件系统来说,持久化是根本,只要 Client 收到了 Server 保存成功的回应之后,数据就不应该丢失。这主要是通过多副本的方式来解决,但在分布式环境下,多副本有这几个问题要面对。

    • 如何保证每个副本的数据是一致的?

    • 如何分散副本,以使灾难发生时,不至于所有副本都被损坏?

    • 怎么检测被损坏或数据过期的副本,以及如何处理?

    • 该返回哪个副本给 Client?

    1、如何保证每个副本的数据是一致的?

    同步写入是保证副本数据一致的最直接的办法。当 Client 写入一个文件的时候,Server 会等待所有副本都被成功写入,再返回给 Client。

    这种方式简单、有保障,唯一的缺陷就是性能会受到影响。假设有 3 个副本,如果每个副本需要 N 秒,则可能会阻塞 Client 3N 秒的时间,有几种方式,可以对其进行优化:

    • 并行写:由一个副本作为主副本,并行发送数据给其他副本;

    • 链式写:几个副本组成一个链 (chain),并不是等内容都接受到了再往后传播,而是像流一样,边接收上游传递过来的数据,一边传递给下游。

    还有一种方式是采用 CAP 中所说的 W+R>N 的方式,比如 3 副本 (N=3) 的情况,W=2,R=2,即成功写入 2 个就认为成功,读的时候也要从 2 个副本中读。这种方式通过牺牲一定的读成本,来降低写成本,同时增加写入的可用性。这种方式在分布式文件系统中用地比较少。

    2、如何分散副本,以使灾难发生时,不至于所有副本都被损坏?

    这主要避免的是某机房或某城市发生自然环境故障的情况,所以有一个副本应该分配地比较远。它的副作用是会带来这个副本的写入性能可能会有一定的下降,因为它离 Client 最远。所以如果在物理条件上无法保证够用的网络带宽的话,则读写副本的策略上需要做一定考虑。

    可以参考同步写入只写 2 副本、较远副本异步写入的方式,同时为了保证一致性,读取的时候又要注意一些,避免读取到异步写入副本的过时数据。

    3、怎么检测被损坏或数据过期的副本,以及如何处理?

    如果有中心节点,则数据节点定期和中心节点进行通信,汇报自己的数据块的相关信息,中心节点将其与自己维护的信息进行对比。如果某个数据块的 checksum 不对,则表明该数据块被损坏了;如果某个数据块的 version 不对,则表明该数据块过期了。

    如果没有中心节点,以 ceph 为例,它在自己的节点集群中维护了一个比较小的 monitor 集群,数据节点向这个 monitor 集群汇报自己的情况,由其来判定是否被损坏或过期。

    当发现被损坏或过期副本,将它从 meta 信息中移除,再重新创建一份新的副本就好了,移除的副本在随后的回收机制中会被收回。

    4、该返回哪个副本给 Client?

    这里的策略就比较多了,比如 round-robin、速度最快的节点、成功率最高的节点、CPU 资源最空闲的节点、甚至就固定选第一个作为主节点,也可以选择离自己最近的一个,这样对整体的操作完成时间会有一定节约。

    六、伸缩性

    1、存储节点的伸缩

    当在集群中加入一台新的存储节点,则它主动向中心节点注册,提供自己的信息,当后续有创建文件或者给已有文件增加数据块的时候,中心节点就可以分配到这台新节点了,比较简单。但有一些问题需要考虑。

    • 如何尽量使各存储节点的负载相对均衡?

    • 怎样保证新加入的节点,不会因短期负载压力过大而崩塌?

    • 如果需要数据迁移,那如何使其对业务层透明?

    1)如何尽量使各存储节点的负载相对均衡?

    首先要有评价存储节点负载的指标。有多种方式,可以从磁盘空间使用率考虑,也可以从磁盘使用率 +CPU 使用情况 + 网络流量情况等做综合判断。一般来说,磁盘使用率是核心指标。

    其次在分配新空间的时候,优先选择资源使用率小的存储节点;而对已存在的存储节点,如果负载已经过载、或者资源使用情况不均衡,则需要做数据迁移。

    2)怎样保证新加入的节点,不会因短期负载压力过大而崩塌?

    当系统发现当前新加入了一台存储节点,显然它的资源使用率是最低的,那么所有的写流量都路由到这台存储节点来,那就可能造成这台新节点短期负载过大。因此,在资源分配的时候,需要有预热时间,在一个时间段内,缓慢地将写压力路由过来,直到达成新的均衡。

    3)如果需要数据迁移,那如何使其对业务层透明?

    在有中心节点的情况下,这个工作比较好做,中心节点就包办了——判断哪台存储节点压力较大,判断把哪些文件迁移到何处,更新自己的 meta 信息,迁移过程中的写入怎么办,发生重命名怎么办。无需上层应用来处理。

    如果没有中心节点,那代价比较大,在系统的整体设计上,也是要考虑到这种情况,比如 ceph,它要采取逻辑位置和物理位置两层结构,对 Client 暴露的是逻辑层 (pool 和 place group),这个在迁移过程中是不变的,而下层物理层数据块的移动,只是逻辑层所引用的物理块的地址发生了变化,在 Client 看来,逻辑块的位置并不会发生改变。

    2、中心节点的伸缩

    如果有中心节点,还要考虑它的伸缩性。由于中心节点作为控制中心,是主从模式,那么在伸缩性上就受到比较大的限制,是有上限的,不能超过单台物理机的规模。我们可以考虑各种手段,尽量地抬高这个上限。有几种方式可以考虑:

    • 以大数据块的形式来存储文件——比如 HDFS 的数据块的大小是 64M,ceph 的的数据块的大小是 4M,都远远超过单机文件系统的 4k。它的意义在于大幅减少 meta data 的数量,使中心节点的单机内存就能够支持足够多的磁盘空间 meta 信息。

    • 中心节点采取多级的方式——顶级中心节点只存储目录的 meta data,其指定某目录的文件去哪台次级总控节点去找,然后再通过该次级总控节点找到文件真正的存储节点;

    • 中心节点共享存储设备——部署多台中心节点,但它们共享同一个存储外设 / 数据库,meta 信息都放在这里,中心节点自身是无状态的。这种模式下,中心节点的请求处理能力大为增强,但性能会受一定影响。iRODS 就是采用这种方式。

    七、高可用性

    1、中心节点的高可用

    中心节点的高可用,不仅要保证自身应用的高可用,还得保证 meta data 的数据高可用。

    meta data 的高可用主要是数据持久化,并且需要备份机制保证不丢。一般方法是增加一个从节点,主节点的数据实时同步到从节点上。也有采用共享磁盘,通过 raid1 的硬件资源来保障高可用。显然增加从节点的主备方式更易于部署。

    meta data 的数据持久化策略有以下几种方式:

    • 直接保存到存储引擎上,一般是数据库。直接以文件形式保存到磁盘上,也不是不可以,但因为 meta 信息是结构化数据,这样相当于自己研发出一套小型数据库来,复杂化了。

    • 保存日志数据到磁盘文件 (类似 MySQL 的 binlog 或 Redis 的 aof),系统启动时在内存中重建成结果数据,提供服务。修改时先修改磁盘日志文件,然后更新内存数据。这种方式简单易用。

    当前内存服务 + 日志文件持久化是主流方式。一是纯内存操作,效率很高,日志文件的写也是顺序写;二是不依赖外部组件,独立部署。

    为了解决日志文件会随着时间增长越来越大的问题,以让系统能以尽快启动和恢复,需要辅助以内存快照的方式——定期将内存 dump 保存,只保留在 dump 时刻之后的日志文件。这样当恢复时,从最新一次的内存 dump 文件开始,找其对应的 checkpoint 之后的日志文件开始重播。

    2、存储节点的高可用

    在前面“持久化”章节,在保证数据副本不丢失的情况下,也就保证了其的高可用性。

    八、性能优化和缓存一致性

    这些年随着基础设施的发展,局域网内千兆甚至万兆的带宽已经比较普遍,以万兆计算,每秒传输大约 1250M 字节的数据,而 SATA 磁盘的读写速度这些年基本达到瓶颈,在 300-500M/s 附近,也就是纯读写的话,网络已经超过了磁盘的能力,不再是瓶颈了,像 NAS 网络磁盘这些年也开始普及起来。

    但这并不代表,没有必要对读写进行优化,毕竟网络读写的速度还是远慢于内存的读写。常见的优化方法主要有:

    • 内存中缓存文件内容;

    • 预加载数据块,以避免客户端等待;

    • 合并读写请求,也就是将单次请求做些积累,以批量方式发送给 Server 端。

    缓存的使用在提高读写性能的同时,也会带来数据不一致的问题:

    • 会出现更新丢失的现象。当多个 Client 在一个时间段内,先后写入同一个文件时,先写入的 Client 可能会丢失其写入内容,因为可能会被后写入的 Client 的内容覆盖掉;

    • 数据可见性问题。Client 读取的是自己的缓存,在其过期之前,如果别的 Client 更新了文件内容,它是看不到的;也就是说,在同一时间,不同 Client 读取同一个文件,内容可能不一致。

    这类问题有几种方法:

    • 文件只读不改:一旦文件被 create 了,就只能读不能修改。这样 Client 端的缓存,就不存在不一致的问题;

    • 通过锁:用锁的话还要考虑不同的粒度。写的时候是否允许其他 Client 读? 读的时候是否允许其他 Client 写? 这是在性能和一致性之间的权衡,作为文件系统来说,由于对业务并没有约束性,所以要做出合理的权衡,比较困难,因此最好是提供不同粒度的锁,由业务端来选择。但这样的副作用是,业务端的使用成本抬高了。

    九、安全性

    由于分布式文件存储系统,肯定是一个多客户端使用、多租户的一个产品,而它又存储了可能是很重要的信息,所以安全性是它的重要部分。

    主流文件系统的权限模型有以下这么几种:

    • DAC:全称是 Discretionary Access Control,就是我们熟悉的 Unix 类权限框架,以 user-group-privilege 为三级体系,其中 user 就是 owner,group 包括 owner 所在 group 和非 owner 所在的 group、privilege 有 read、write 和 execute。这套体系主要是以 owner 为出发点,owner 允许谁对哪些文件具有什么样的权限。

    • MAC:全称是 Mandatory Access Control,它是从资源的机密程度来划分。比如分为“普通”、“机密”、“绝密”这三层,每个用户可能对应不同的机密阅读权限。这种权限体系起源于安全机构或军队的系统中,会比较常见。它的权限是由管理员来控制和设定的。Linux 中的 SELinux 就是 MAC 的一种实现,为了弥补 DAC 的缺陷和安全风险而提供出来。关于 SELinux 所解决的问题可以参考 What is SELinux?

    • RBAC:全称是 Role Based Access Control,是基于角色 (role) 建立的权限体系。角色拥有什么样的资源权限,用户归到哪个角色,这对应企业 / 公司的组织机构非常合适。RBAC 也可以具体化,就演变成 DAC 或 MAC 的权限模型。

    十、其他

    1、空间分配

    有连续空间和链表空间两种。连续空间的优势是读写快,按顺序即可,劣势是造成磁盘碎片,更麻烦的是,随着连续的大块磁盘空间被分配满而必须寻找空洞时,连续分配需要提前知道待写入文件的大小,以便找到合适大小的空间,而待写入文件的大小,往往又是无法提前知道的 (比如可编辑的 word 文档,它的内容可以随时增大);

    而链表空间的优势是磁盘碎片很少,劣势是读写很慢,尤其是随机读,要从链表首个文件块一个一个地往下找。

    为了解决这个问题,出现了索引表——把文件和数据块的对应关系也保存一份,存在索引节点中 (一般称为 i 节点),操作系统会将 i 节点加载到内存,从而程序随机寻找数据块时,在内存中就可以完成了。通过这种方式来解决磁盘链表的劣势,如果索引节点的内容太大,导致内存无法加载,还有可能形成多级索引结构。

    2、文件删除

    实时删除还是延时删除? 实时删除的优势是可以快速释放磁盘空间;延时删除只是在删除动作执行的时候,置个标识位,后续在某个时间点再来批量删除,它的优势是文件仍然可以阶段性地保留,最大程度地避免了误删除,缺点是磁盘空间仍然被占着。在分布式文件系统中,磁盘空间都是比较充裕的资源,因此几乎都采用逻辑删除,以对数据可以进行恢复,同时在一段时间之后 (可能是 2 天或 3 天,这参数一般都可配置),再对被删除的资源进行回收。

    怎么回收被删除或无用的数据? 可以从文件的 meta 信息出发——如果 meta 信息的“文件 - 数据块”映射表中包含了某个数据块,则它就是有用的;如果不包含,则表明该数据块已经是无效的了。所以,删除文件,其实是删除 meta 中的“文件 - 数据块”映射信息 (如果要保留一段时间,则是把这映射信息移到另外一个地方去)。

    3、面向小文件的分布式文件系统

    有很多这样的场景,比如电商——那么多的商品图片、个人头像,比如社交网站——那么多的照片,它们具有的特性,可以简单归纳下:

    • 每个文件都不大;

    • 数量特别巨大;

    • 读多写少;

    • 不会修改。

    针对这种业务场景,主流的实现方式是仍然是以大数据块的形式存储,小文件以逻辑存储的方式存在,即文件 meta 信息记录其是在哪个大数据块上,以及在该数据块上的 offset 和 length 是多少,形成一个逻辑上的独立文件。这样既复用了大数据块系统的优势和技术积累,又减少了 meta 信息。

    4、文件指纹和去重

    文件指纹就是根据文件内容,经过算法,计算出文件的唯一标识。如果两个文件的指纹相同,则文件内容相同。在使用网络云盘的时候,发现有时候上传文件非常地快,就是文件指纹发挥作用。云盘服务商通过判断该文件的指纹,发现之前已经有人上传过了,则不需要真的上传该文件,只要增加一个引用即可。在文件系统中,通过文件指纹可以用来去重、也可以用来判断文件内容是否损坏、或者对比文件副本内容是否一致,是一个基础组件。

    文件指纹的算法也比较多,有熟悉的 md5、sha256、也有 google 专门针对文本领域的 simhash 和 minhash 等。

    十一、总结

    分布式文件系统内容庞杂,要考虑的问题远不止上面所说的这些,其具体实现也更为复杂。本文只是尽量从分布式文件系统所要考虑的问题出发,给予一个简要的分析和设计,如果将来遇到类似的场景需要解决,可以想到“有这种解决方案”,然后再来深入研究。

    同时,市面上也是存在多种分布式文件系统的形态,下面就是有研究小组曾经对常见的几种分布式文件系统的设计比较。图片

    从这里也可以看到,选择其实很多,并不是 GFS 论文中的方式就是最好的。在不同的业务场景中,也可以有更多的选择策略。

    展开全文
  • Oracle RAC部署到分布式存储上,可以解决数据集中存储的IO瓶颈,同事还能支持横向扩展,有了真正的分布式存储,才能真正意义上的云架构。再数据读写速度上面有几倍的提升。1:实现方式a:Turn standard NVMe PCIe ...

    Oracle RAC部署到分布式存储上,可以解决数据集中存储的IO瓶颈,同事还能支持横向扩展,有了真正的分布式存储,才能真正意义上的云架构。再数据读写速度上面有几倍的提升。

    1:实现方式

    a:Turn standard NVMe PCIe SSDs inside database servers into scalable shared storage

    b:0.4 to 50 TB per node; 2 to 100 nodes

    c:Leverage proven Oracle ASM for high availability and data mirroring

    d:Maximize database performance with ReadLocal™ Technology

    结构图

    9616c25d1da6911f7fb50e40528e3400.png

    architecture highlights

    ‥shared storage based on standard NVMe PCIe SSDs

    ‥use of high-capacity SAS HDDs for bulk storage needs

    ‥storage located inside the database nodes (converged nodes) or in separate storage nodes

    ‥x86 servers used as database and storage nodes

    ‥FlashGrid software manages SSD devices and connectivity, integrates with Oracle ASM

    ‥ASM manages data, volumes, mirroring, snapshots

    ‥2-way or 3-way mirroring of data across separate nodes

    ‥Choice of 10/40/100 GbE or InfiniBand/RDMA for network connectivity

    ‥FlashGrid Read-Local Technology minimizes network overhead by serving reads from local SSDs at the speed of PCIe

    服务器架构方式1

    ae99e4c6fd881d5902ef10812ee6d63f.png

    服务器架构方式2

    21f17f592b6ed037eda16321cd1c19f3.png

    2:Minimize Costs with Commodity Hardware and Free Software

    Reduce storage costs by up to 90% compared to proprietary storage hardware. Commodity

    servers and SSDs have lower costs and allow second-sourcing for better pricing and parts

    availability. Pay only for the flash capacity that you actually need for a particular cluster,

    even if required capacity is as small as 1TB. Fully eliminate or cut the amount of the high-cost

    Fibre Channel infrastructure.

    3:Standardize High Bandwidth and Low Latencies

    with NVMe PCIe SSDs

    NVMe, the industry standard for PCIe SSDs, delivers outstanding performance of up to 3 GB/s

    and up to 750,000 random IOPS per SSD. Multiple NVMe SSDs can be installed per server,

    up to 18 SSDs in some server models. The hot-plug capability makes adding or replacing

    an NVMe SSD as easy as adding or replacing a HDD.

    4:Prevent Network Congestion with FlashGrid ReadLocal™ Technology

    A congested storage network can limit the performance advantages of flash storage. The FlashGrid ReadLocal™

    Technology reduces network traffic by up to 90% or more by serving read requests from local SSDs instead of moving data

    over the network. In 2-node or 3-node clusters 100% of the read traffic can be served locally. Unlike caching, the FlashGrid

    Read-Local™ Technology accelerates even large table scans and backup operations.

    如图:

    f2de70330552d03aeda286eb8b11b855.png

    展开全文
  • 盘点分布式文件存储系统

    千次阅读 2021-02-08 22:14:23
    在项目的数据存储中,结构化数据通常采用关系型数据库,非结构化数据(文件)的存储就有很多种方式,服务器本地存储、Nas挂载、ftp等等,今天就来盘点一下,分布式文件存储系统。
  • 块存储分布式存储块存储,简单来说就是提供了块设备存储的接口。通过向内核注册块设备信息,在Linux中通过lsblk可以得到当前主机上块设备信息列表。本文包括了单机块存储介绍、分布式存储技术Ceph介绍,云中的...
  • 这三者的本质差别是使用数据的“用户”不同:块存储的用户是可以读写块设备的软件系统,例如传统的文件系统、数据库;文件存储的用户是自然人;对象存储的用户则是其它计算机软件。首先要说明一下的是,这三个概念都...
  • 分布式对象存储

    2021-07-23 10:53:43
    分布式对象存储 前言 一、对象存储S3 二、gateway 三、metaproxy 四、dataproxy 五、metaserver 六、datanode 七、数据存储区域 前言 在实习期间记录一下在公司期间学习到的东西 一、对象存储S3 对象存储(Object ...
  • 作者 |张轲1983来源 |https://www.jianshu.com/p/fc0aa34606ce一、概述分布式文件系统是分布式领域的一个基础应用,其中最著名的毫无疑问是 HDF...
  • 在项目的数据存储中,结构化数据通常采用关系型数据库,非结构化数据(文件)的存储就有很多种方式,服务器本地存储、Nas挂载、ftp等等,今天就来盘点一下,分布式文件存储系统。 一、分布式存储简介 1、什么是...
  • 分布式存储架构

    2021-08-02 06:41:01
    分布式存储架构由三个部分组成:客户端、元数据服务器和数据服务器。客户端负责发送读写请求,缓存文件元数据和文件数据。元数据服务器负责管理元数据和处理客户端的请求,是整个系统的核心组件。数据服务器负责存放...
  • 基于阿里云的块存储介绍

    千次阅读 2021-05-19 15:19:17
    块存储 1.块存储概述 块存储是阿里云为云服务器ECS提供的块设备产品,具有高性能和低时延的特点,支持随机读写。您可以像使用物理硬盘一样格式化并建立文件系统来使用块存储,满足大部分通用业务场景下的数据存储...
  • 1.分布式文件系统应用场景 互联网海量非结构化数据的存储需求 电商网站:海量商品图片 视频网站:海量视频文件 网盘 : 海量文件 社交网站:海量图片 1.1 Minio介绍 MinIO 是一个基于Apache License v2.0开源...
  • ceph 的统一体现在可以提供文件系统、块存储和对象存储,分布式体现在可以动态扩展。在国内一些公司的云环境中,通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。Ceph项目最早起源于Sage就读博士...
  • 分布式存储技术体系当中,分布式文件存储是其中的分类之一,也是大数据架构当中常常用到的。得益于Hadoop的高人气,Hadoop原生的HDFS分布式文件系统,也广泛为人所知。但是分布式文件存储系统,并非只有HDFS。今天...
  • 分布式存储(MFS)

    2021-03-05 14:31:48
    Moose File System 是一个具备容错功能的网络分布式文件系统,它将数据分布在网络中的不同服务器上,MooseFS通过FUSE使之看起来就是一个Unix的文件系统。即MFS文件系统:将分布在各个范围的计算机将他们未使用的分区...
  • 分布式存储指的是通过分布式存储软件将若干X86服务器的内置硬盘组合成一个大的存储空间,对外提供、文件、对象存储服务,它们之间的对比可以从以下几个方面来展开: 从性能上来讲,存储性能主要体现在几个参数,...
  • 分布式存储问题及解决方案

    千次阅读 2021-03-16 19:49:30
    分布式存储存在的问题 分布式存储一般情况下都是靠“副本”来确保数据的安全性和完整性。每盘记录的数据内容都不一样,当某一盘出现问题,都需要从其他不同盘内的数据中进行快速的数据重构。 数据重构是需要...
  • 原标题:ceph分布式存储创建块存储及快照通过一张官方的图了解ceph分布式存储的架构: 底层是服务器硬件设备,服务器之上是操作系统,通常使用linux操作系统进行构建。操作系统之上是分布式存储,在分布式存储上创建...
  • Ali块存储

    2021-04-18 16:33:25
    块存储的概念 块存储概念 块存储是阿里云专门为云服务ECS提供的块设备产品,具有高性能和低延时的特点,支持随机读写。可以像使用物理硬盘一样格式化并建立文件系统来使用块存储,可满足大部分通用业务下的数据...
  • Ceph分布式存储系统

    2021-05-14 10:40:38
    Ceph是根据加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统,其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性。Ceph其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这...
  • 3.4 大数据存储策略 3.4.1 虚拟化存储 虚拟化技术:通过映射或抽象的方法屏蔽物理设备复杂性,增加一个管理层面,激活一种资源并使之更易于透明控制。它可以有效简化基础设施的管理,增加IT资源的利用率和能力,...
  • 分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用与大规模,高并发场景下的Web访问问题。它采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了...
  • minio 是一款高性能、分布式的对象存储系统. 它是一款软件产品, 可以100%的运行在标准硬件。即X86等低成本机器也能够很好的运行MinIO。它最适合存储非结构化数据,如照片,视频,日志文件,备份和容器/ VM映像。对象...
  • san对外呈现的是一个磁盘,用户根据自己需求使用磁盘,以设备偏移为地址进行io操作。 2、nas直接连接入以太网,通过TCP/IP协议访问数据,采用标准文件共享协议如:NFS、CIFS实现共享。San则是通过光纤连接服务器...
  • 查询Glance服务状态 #glance-control all status [root@controller ~]# glance-control all status glance-api (pid 2074) is running… glance-registry (pid 2344) is running… glance-scrubber is stopped ...
  • 1.华为分布式存储fusionstorage介绍

    千次阅读 2021-08-13 11:12:25
    行业分布式解决方案: 1.Ceph 应用最多的开源分布式解决方案 2.Glusterfs 3.VMware VSAN 4.fusionStorage 华为 一、传统企业级别存储和Fsuion storage 对比 1.传统企业级存储控制器扩展有瓶颈,存储例如18000V6扩展...
  • 大数据背景下的分布式存储

    千次阅读 2021-03-02 14:48:01
    随着人工智能、机器学习领域技术的持续进步,以及国家“新基建”战略的推进,新的技术和...随着物联网、人工智能、5G的迅速发展,预测到2023年,存储架构中或40%都是分布式架构。 分布式存储架构 分布式存储最早是由
  • ​ Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。 对比说明 TFS FASTDFS MooseFS GlusterFS CEPH 开发语言 C++ C C C C++ 数据存储方式 文件/Trunk 文件/ 对象/...
  • 长城分布式存储介绍

    2021-01-12 09:19:44
    1.1软件定义存储概述 伴随着云计算的发展,IDC预测,到2023年70%的工作负载将会被部署在超大规模的云平台上,而到2020年,50%的企业在使用公有云的同时也会使用企业级私有云平台,35%的组织将对原生应用的自动化、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 165,501
精华内容 66,200
关键字:

分布式块存储