https://www.161616.top/tags/storage/ Recent content in Storage on Cylon's Collection Hugo -- 0.125.7 zh Wed, 16 Apr 2025 23:10:36 +0800 https://www.161616.top/ch10-3-troubeshooting-osd-crash-by-poweroff/ Wed, 16 Apr 2025 00:00:00 +0000 https://www.161616.top/ch10-3-troubeshooting-osd-crash-by-poweroff/ ceph版本 nautilus 处理过程 查看 ceph 集群状态 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ceph -s cluster: id: baf87797-3ec1-4f2c-8126-bf0a44051b13 health: HEALTH_WARN 3 osds down 1 host (3 osds) down 1 pools have many more objects per pg than average Degraded data redundancy: 1167403/4841062 objects degraded (24.115%), 391 pgs degraded, 412 pgs undersized services: mon: 3 daemons, quorum 10. https://www.161616.top/rgw-bucket-sync-with-rclone/ Tue, 24 Sep 2024 00:00:00 +0000 https://www.161616.top/rgw-bucket-sync-with-rclone/ rclone工具的特点 支持增量，配置简单，支持参数调节吞吐量（不同吞吐量使用内存不同，传输差异也不同） copy是复制 source 到 dst sync是根据 src 的内容对比 dst，删除dst不存在的内容 下面是写了一同步的脚本 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 #! https://www.161616.top/ch03-3-ceph-osd-performance-recommendation/ Fri, 13 Sep 2024 00:00:00 +0000 https://www.161616.top/ch03-3-ceph-osd-performance-recommendation/ 本文记录了在使用 ceph 集群时遭遇到的内存问题，以及引用和参考一些资料用于对在 ceph 集群使用时的内存预估。 OSD的内存需求 如何评估 Ceph OSD 所需的硬件也是对于集群选型，集群优化的一个必要条件，这里主要找到两个可靠的参考资料用于评估 OSD 内存配置大小 IBM Storage Ceph IBM Storage Ceph 提供了一个运行 Ceph 用于预估系统配置的一个最小推荐列表 [1]，个人感觉可以参考这些信息用于自己集群的优化。主要用于容器化的 Ceph 集群 Process Criteria Minimum Recommended ceph-osd-container Processor 1x AMD64 or Intel 64 CPU CORE per OSD container RAM Minimum of 5 GB of RAM per OSD container OS Disk 1x OS disk per host OSD Storage 1x storage drive per OSD container. Cannot be shared with OS Disk. https://www.161616.top/ch02-4-ceph-deploy-offline-rgw/ Thu, 12 Sep 2024 00:00:00 +0000 https://www.161616.top/ch02-4-ceph-deploy-offline-rgw/ 本文是Ceph集群部署系列第4章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 记录一次因着急没有检查原因而直接下线 ceph 对象存储的的失败记录 操作流程 ceph 节点内存持续超过90%，因为本身有三个 OSD，检查内存使用情况发现 radosgw bash 1 2 3 4 5 6 7 8 9 10 11 $ ps aux --sort=-%mem | head -10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ceph 1702 0.4 32.9 10128296 4550760 ? Ssl May03 919:18 /usr/bin/radosgw -f --cluster ceph --name client.rgw.node01 --setuser ceph --setgroup ceph ceph 1721 0. https://www.161616.top/ch10-2-troubeshooting-crash-record/ Tue, 13 Feb 2024 00:00:00 +0000 https://www.161616.top/ch10-2-troubeshooting-crash-record/ 处理记录 Ceph版本：octopus 首先遇到問題是，业务端无法挂在 cephfs 查看内核日志发现是 bad authorize reply ，以为是 ceph keyring被替换了 text 1 2 3 4 5 6 7 8 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10. https://www.161616.top/ch10-1-ceph-fscache/ Sat, 11 Nov 2023 00:00:00 +0000 https://www.161616.top/ch10-1-ceph-fscache/ 本文记录了在 kubernetes 环境中，使用 cephfs 时当启用了 fscache 时，由于网络问题，或者 ceph 集群问题导致的整个 k8s 集群规模的挂载故障问题。 结合fscache的kubernetes中使用cephfs造成的集群规模故障 在了解了上面的基础知识后，就可以引入故障了，下面是故障产生环境的配置 故障发生环境 软件 版本 Centos 7.9 Ceph nautilus (14.20) Kernel 4.18.16 故障现象 在 k8s 集群中挂在 cephfs 的场景下，新启动的 Pod 报错无法启动，报错信息如下 bash 1 ContainerCannotRun: error while creating mount source path /var/lib/kubelet/pods/5446c441-9162-45e8-0e93-b59be74d13b/volumes/kubernetesio-cephfs/{dir name} mkcir /var/lib/kubelet/pods/5446c441-9162-45e8-de93-b59bte74d13b/volumes/kubernetes.io~cephfs/ip-ib file existe 主要表现的现象大概为如下三个特征 对于该节点故障之前运行的 Pod 是正常运行，但是无法写入和读取数据 无法写入数据 permission denied 无法读取数据 kublet 的日志报错截图如下 彻底解决方法 需要驱逐该节点上所有挂在 cephfs 的 Pod，之后新调度来的 Pod 就可以正常启动了 故障的分析 当网络出现问题时，如果使用了 cephfs 的 Pod 就会出现大量故障，具体故障表现方式有下面几种 新部署的 Pod 处于 Waiting 状态 https://www.161616.top/ch05-4-s3cmd-in-windows/ Sun, 24 Sep 2023 00:00:00 +0000 https://www.161616.top/ch05-4-s3cmd-in-windows/ s3cmd 是为了管理 Linux 服务器上的 S3 存储桶而创建的。 但我们也在 Windows 服务器上使用这个工具。 本文将帮助您在 Windows 系统中设置 s3cmd Requirment s3cmd 系统要求： s3cmd 需要 Python 2.7 或更高版本才能运行，还需要安装GPG。 步骤1：安装 Python 从 python 官方网站下载并安装 python 2.7 或更高版本并安装。安装python后，将将其加到 PATH 环境变量。 步骤 2： 在 Windows 上安装 GPG Gpg4win (GNU Privacy Guard for Windows) 是一款用于数字加密 (file, email) 的免费软件，可以使用以下链接下载并安装它。 步骤3：配置 s3cmd 下载最新的 s3cmd 源代码 从s3cmd 官方页面 并解压； 提取源代码后，使用以下命令设置 s3 环境。 它会询问您的 对象存储的 AccessKey 和 SecretKey，即 GPG 命令的路径 bat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 C:s3cmd> python s3cmd --configure Enter new values or accept defaults in brackets with Enter. https://www.161616.top/ch05-3-s3cmd/ Sun, 24 Sep 2023 00:00:00 +0000 https://www.161616.top/ch05-3-s3cmd/ s3cmd 是一个 Amazon S3 工具，可以用于创建 s3 bucket、向对象存储中上传，检索和管理数据，在下文将如何在 Linux 上如何安装和使用 “s3cmd” 工具。 在 Linux 上安装 s3cmd s3cmd 在 Ubuntu/Debian, Fedora/CentOS/RHEL 这类发行版上的默认软件包存储库中都是可用的，只需在执行对应发行版的安装命令即可安装。 CentOS/RHEL/Fedora bash 1 2 3 4 # centos 8 $ sudo dnf install s3cmd # centos 7 $ sudo yum install s3cmd Ubuntu/Debian bash 1 sudo apt-get install s3cmd 安装最新版本 通常包管理仓库中的版本比较旧，或者使用的 Linux 没有包管理来获取最新版本的 s3cmd，那么可以使用源代码在系统上安装最新版本的 s3cmd，下载地址可以参考附录1 [1] 下面以 2.2 版本进行安装 bash 1 2 $ wget https://sourceforge.net/projects/s3tools/files/s3cmd/2.2.0/s3cmd-2.2.0.tar.gz $ tar xzf s3cmd-2.2.0.tar.gz 使用以下命令和源文件安装 https://www.161616.top/ch05-2-bucket-policy/ Mon, 18 Sep 2023 00:00:00 +0000 https://www.161616.top/ch05-2-bucket-policy/ CEPH RGW 支持 Bucket 的 S3 策略语言，但又不完全类似于 S3 的策略，因为 S3 中策略是基于 AWS 的，某些属性在 CEPH 中并不存在，下面就解开 RGW 关于桶策略的配置。 Bucket Policy (桶策略，下文中统称为 BP) 是对象存储中的管理权限和对象存储访问的机制。 Policy Language 的组成 BP 的格式采用了 JSON 语言，也就是 PL 是基于 JSON 的一种策略语言，他的格式主要为几个元素 json 1 2 3 4 5 6 7 8 9 { "Version": "2012-10-17", "Statement": [{ "Effect": ..., "Principal": ..., "Action": ..., "Resource": ... }] } 该结构由 ==一个== Version (表示当前版本) 和 ==一个或多个== Statement 数组组成，这些数组定义了希望应用的策略。每个语句数组中都有Effect, Principal, Action, Resource 和可选的 Condition 元素。 https://www.161616.top/ch11-1-ceph-common-cmd/ Wed, 13 Sep 2023 00:00:00 +0000 https://www.161616.top/ch11-1-ceph-common-cmd/ 测试上传/下载对象 存取故据时，客户端必须首先连接至RAD05集群上某存储地，而后根据对像名称由相关的中CRUSH规则完成数据对象寻址。于是为了测试集群的数据存储功能，首先创建一个用于测试的存储池mypool，并设定其PG数量为16个。 sh 1 ceph osd pool create mypool 16 16 而后，即可将测试文件上传至存储池中。例如下面的rados put命令将/etc/hosts rados lspool 显示存储池 rmpool 删除存储池 mkpool 创建存储池 rados mkpool mypool 32 32 sh 1 2 rados mkpool {name} {pgnum} {pgpnum} rados mkpool test 32 32 sh 1 2 $ ceph osd pool create testpool 32 32 pool 'testpool' created 列出存储池 text 1 2 3 4 5 6 7 8 9 $ ceph osd pool ls mypool rbdpool testpool $ rados lspools mypool rbdpool testpool 而后即可将测试文件上传到存储池中，例如将rados put命令将/etc/issue文件上传至testpool存储池，对象名称仍然较保留文件名issue，而rados ls可以列出指定存储池中的数据对象 https://www.161616.top/ch6-1-ceph-rebalance/ Sun, 03 Sep 2023 00:00:00 +0000 https://www.161616.top/ch6-1-ceph-rebalance/ Rebalance 当 Ceph 集群在扩容/缩容后，Ceph会更新 Cluster map, 在更新时会更新 Cluster map 也会更新 “对象的放置” CRUSH 会平均但随机的将对象放置在现有的 OSD 之上，在 Rebalancing 时，只有少量数据进行移动而不是全部数据进行移动，直到达到 OSD 与 对象 之间的平衡，这个过程就叫做 Ceph 的 Rebalance。 需要注意的是，当集群中的 OSD 数量越多，那么在做 Rebalance 时所移动的就越少。例如，在具有 50 个 OSD 的集群中，在添加 OSD 时可能会移动 1/50th 或 2% 的数据。 如下图所示，当前集群有两个 OSD，当在集群中添加一个 OSD，使其数量达到3时，这个时候会触发 Rebalance，所移动的数量为 OSD1 上的 PG3 与 OSD2 上的 PG 6和9 图：Ceph Rebalancing 示意图 Source：https://access.redhat.com/documentation/zh-cn/red_hat_ceph_storage/4/html/architecture_guide/ceph-rebalancing-and-recovery_arch Balancer 执行 Rebalance 的模块时 Balancer，其可以优化 OSD 上的放置组 (PG) ，以实现平衡分配。 可以通过命令查看 balancer 的状态 bash 1 ceph balancer status https://docs. https://www.161616.top/acquaintance-stroage/ Tue, 15 Aug 2023 00:00:00 +0000 https://www.161616.top/acquaintance-stroage/ 存储选择需要考虑的问题：不同的文件访问方式? 在关注存储之前，需要关注下面一些问题： “应用” 访问数据的方式是什么？ 一次读取 或 分块读取 一个连续的“流”传输最好的方式是什么 有序的 或 随机的 “数据的类型是什么”？ 数据库，Text，视频/音频，图像… 静态 / 固定 / 动态 是否需要数据共享？ 由应用共享 / 由存储共享 读 / 写 共享方面关注的问题？ Narrow (只需要更新部分内容，这可以共享特定部分内容，这将不是一个广泛共享) / Broad 安全和访问控制： 应用什么级别的的安全性？ 访问性会影响存储的选择： Local / Network 介质：光纤，以太网，SAS，SATA，PCIe… 有了这些问题，就可以引入存储的类型，以便选择最佳的存储（Balance performance and cost ） DAS Direct Attached Storage (DAS) 直接附加存储是指，直接连接到服务器存储系统，通俗来讲就是直接连接磁盘，服务器与存储系统之间“没有经过网络设备” (如交换机等)，服务器与存储直接由专用的“连接技术”进行连接，如 SCSI, 但现在更常见的是 “eSATA”, “SAS”, 或 “光纤通道”。 图：DAS结构图 Source：https://www.pcmag.com/encyclopedia/term/direct-attached-storage 图：DAS接口类型 Source：https://ramsaihan.wordpress.com/2017/10/16/the-sas-sata-scsi-and-ata-in-storage-and-peripheral-communication/ 外部连接 直连存储也可以通过连接电缆从服务器连接到存储设备，但服务器中必须存在 SAS、以太网或 FC 控制器，只有该服务器可以使用外部磁盘空间。因此直连存储也可以作为是服务器的扩展 SAS 作为连接介质价格低廉，但距离仅限于几米（最大 5 或 10 米，具体取决于制造商）；光纤通道的传输距离可达数公里，因此也可用作灾备系统。 https://www.161616.top/ch02-1-install-ceph-with-cephadm-part1/ Sun, 30 Jul 2023 00:00:00 +0000 https://www.161616.top/ch02-1-install-ceph-with-cephadm-part1/ 本文是Ceph集群部署系列第1章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 开篇常例 - 概述 Ceph 是一个广泛使用的开源存储平台。 它提供高性能、可靠性和可扩展性。 Ceph 分布式存储系统提供了对象存储、块存储和文件级存储。 Ceph 旨在提供无单点故障的分布式存储系统。 在本教程中，将通过 ceph-adm 方式在 CentOS 7 上安装和构建 Ceph 集群。该实验的 Ceph 集群需要以下 Ceph 组件： Ceph OSD (ceph-osd) - 处理数据存储、数据复制和恢复；通常一个Ceph集群至少需要两台 OSD 服务器 。 Ceph Monitor (ceph-mon) - 监视集群状态、OSD 映射和 CRUSH 映射，我们在这里与 cephadm 或 OSD 公用一个节点 Ceph 元数据服务器 (ceph-mds) - 这是使用 CephFS 所需的组件。 有了上面的条件，我们实验环境所需要的节点如下： 三台服务器节点，CentOS 7 注：CentOS 7 可安装最高级别的 ceph 版本就是 O 版 https://www.161616.top/ch02-2-install-ceph-with-cephadm-part2/ Sun, 30 Jul 2023 00:00:00 +0000 https://www.161616.top/ch02-2-install-ceph-with-cephadm-part2/ 本文是Ceph集群部署系列第2章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 离线安装 - ceph-mds ceph-mds (metadata server daemon) 是 cephfs 功能中所需要的组件，是用于收集和管理文件系统名称空间，协调和共享 OSD 集群的组件。 cephadm 部署集群所有组件都打包在 ceph 镜像内，只需要修改一遍就可以全局离线安装了 要部署 cephfs 就需要有一个或多个 ceph-mds 使用 cephadm 部署 mds bash 1 2 ceph orch apply mds *<fs-name>* --placement="*<num-daemons>* [*<host1>* ...]" ceph orch apply mds kubernetes01 --placement="hostname01,hostname02,hostname03" 删除 mds bash 1 2 ceph config set mon mon_allow_pool_delete true ceph fs volume rm kubernetes01 --yes-i-really-mean-it 离线安装 - Ceph Object Gateway Ceph 从 0. https://www.161616.top/ch02-3-install-ceph-with-ceph-deploy/ Mon, 18 Nov 2019 00:00:00 +0000 https://www.161616.top/ch02-3-install-ceph-with-ceph-deploy/ 本文是Ceph集群部署系列第3章 使用cephadm纯离线安装Ceph集群 使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 环境配置 Ceph 是一个开源去中心化存储平台，专为满足现代存储需求而设计。 Ceph可扩展至 EB 级，并且设计为无单点故障，使其成为需要高度可用的灵活存储的应用程序的理想选择。 下图显示了具有 Ceph 存储的示例 3 节点集群的布局。 两个网络接口可用于增加带宽和冗余，这有助于保持足够的带宽来满足存储要求，而不影响客户端应用程序。 图：Ceph存储集群 Source：https://www.jamescoyle.net/how-to/1244-create-a-3-node-ceph-storage-cluster 图中架构表示了一个无单点故障的 3 节点 Ceph 集群，以提供高度冗余的存储。 每个节点都配置了两个磁盘； 一台运行 Linux 操作系统，另一台将用于 Ceph 存储。 下面的输出显示了可用的存储空间，每个主机上的存储空间完全相同。 /dev/sda 是包含操作系统安装的根分区， /dev/sdb 是一个未触及的分区，将用于部署 Ceph 集群，对应的硬件信息如下表所示。 主机名 public IP cluster IP 数据盘 ceph-nautilus01 10.0.0.50 10.0.0.50 /dev/sda /dev/sdb ceph-nautilus02 10.0.0.51 10.0.0.51 /dev/sda/dev/sdb ceph-nautilus03 10.0.0.52 10.0.0.52 /dev/sda/dev/sdb ceph-control 10.0.0.49 10.0.0.49 /dev/sda 部署工具 ceph-deploy 工具是在 “管理节点” (ceph-admin) 上的目录中运行。 https://www.161616.top/ch03-1-acquaintance-rdb/ Mon, 30 Sep 2019 00:00:00 +0000 https://www.161616.top/ch03-1-acquaintance-rdb/ 什么是块存储 RBD Ceph RBD (RADOS Block Device) 是 Ceph 提供的三种存储类型之一 (块存储 RBD, 文件存储 CephFS, 对象存储 RGW)，也是另外两个存储类型 (文件存储 CephFS, 对象存储 RGW) 的底座，位于 RADOS 架构中的最底层，由下图可以看出 图：Ceph RADOS架构图 Source：https://www.supportsages.com/ceph-part-3-technical-architecture-and-components/ RADOS 是可信赖的自动分布式对象存储 (Reliable Autonomous Distributed Object Store) 的简写，通俗来说，RADOS 代表的就是整个 Ceph 集群，数据对象在集群中的存储方式会“将对象复制为多副本” 以实现容错，所以 Ceph 集群的底座就是 RADOS，一个 RADOS 集群的组件通常包含三个，OSD Daemon , MDS, MON Object Storage Device (OSD) Daemon：RADOS集群中负责存储守护进程，与 OSD (数据的物理或逻辑存储单元【通常指一个硬盘】)交互。集群中的每个 Ceph Node 都必须运行 OSD Daemon。对于每个 OSD，可以有一个关联的硬盘 (通常一个OSD Daemon 对应一个存储单元)。 MONITORS (Mon Daemon)：Monitor (ceph-mon) 不是集群存储组件的一部分，但它通过监视 OSD 状态并生成 “Cluster Map” 而成为 RADOS 不可或缺的一部分。它监视 OSD 并跟踪在给定时间点哪些 OSD 处于运行状态、哪些 OSD 处于对等状态、OSD 的状态等。一般来说，它充当存储集群中所有 OSD 的 Monitor Manager (MGR Daemon)：Manager (ceph-mgr) 是与 ceph-mon 一同运行的守护进程，为外部监控和管理系统提供额外的监视和接口。默认情况下，ceph-mgr 除了确保其正在运行之外不需要其他配置。如果没有运行 ceph-mgr，ceph -s 将会看到一条 WARN；不管是使用什么方式部署的集群 ( ceph-deploy, cephadm)，ceph-mgr 总会 与 ceph-mon 同时运行在一个节点上，也可单独运行在 Ceph Node 之上。 通常 Monitor (ceph-mon) 不构成“存储”集群的一部分，只是通过监视 OSD 状态并生成 Cluster map 而成为 ceph存储集群中不可缺少的组件。它通过监视 OSD 并跟踪在给定时间点哪些 OSD 处于运行状态、哪些 OSD 处于对等状态、OSD 的状态等。 https://www.161616.top/ch03-2-rbd-management/ Wed, 31 Jul 2019 00:00:00 +0000 https://www.161616.top/ch03-2-rbd-management/ 上一章提到了 RBD 块设备相关的基本配置，这章主要描述 RBD 操作部分 ceph块设备接口（RDB） Ceph块设备，也称为RADOS块设备（简称RBD），是一种基于RADOS存储系统支持超配（thin-provisioned）、可伸缩的条带化数据存储系统，它通过librbd库与OSD进行交互。RBD为KVM等虑拟化技术和云OS（如OpenStack和CloudStack）提供高性能和无限可扩展性的存储后端，这些系统依赖于libvirt和QEMU实用程序与RBD进行集成。 客户端基于librbd库即可将RADOS存储集群用作块设备，不过，用于rbd的存储池需要实现启用rbd功能并进行初始化。例如，下面的命令创建rbddata的存储池，在启动rbd功能后对其进行初始化。 sh 1 2 3 4 ceph osd pool create rbdpool 64 # 创建存储池 rbd pool init -p rbdpool # rbd create rbdpool/img1 --size 2G rbd ls -p rbdpool 不过rbd存储池并不能直接用于块设备，而是需要事先在其中按需创建影响（image） RBD是建立在librados之上的客户端，全程为Rados Block Devices，是对rados存储服务做抽象，将rados位于存储池当中所提供的存储空间，使用对象式存储数据的能力的机制。 rbd虚拟磁盘设备要想使linux内核所识别使用，要求linux在内核级支持Ceph，内核级有一个Ceph模块，专门用来驱动Ceph设备的。这个驱动就叫librbd。此模块自己是一个客户端，能够连接至RBD服务上，检索出他所管理的镜像文件。从而镜像文件完全可以被linux主机作为一块完整的硬盘来使用。 创建存储池镜像 --object-size 任何数据存储在存储池中都被切分为固定大小的对象，对象通常称之为条带，切分的对象大小，默认4M --image-feature 指定镜像文件的特性，每种特性代表镜像文件能支持哪些种功能，可被单独启用或禁用。 layering(+), 分层克隆 exclusive-lock 排它锁，是否支持分布式排它锁，已用来限制一个镜像文件同时只能被一个客户端使用。 object-map(+*) 对象映射,是否支持对象位图，主要用于加速导入、导出及已用容量统的。 fast-diff(+*), 快速比较，主要用于做快照之间的比较 deep-flatten(+-) , 深层展评 journaling 日志，用户在修改image数据时是否记录日志。 shared image --no-progress：不显示创建过程 sh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 $ rbd help create usage: rbd create [--pool <pool>] [--image <image>] [--image-format <image-format>] [--new-format] [--order <order>] [--object-size <object-size>] [--image-feature <image-feature>] [--image-shared] [--stripe-unit <stripe-unit>] [--stripe-count <stripe-count>] [--data-pool <data-pool>] [--journal-splay-width <journal-splay-width>] [--journal-object-size <journal-object-size>] [--journal-pool <journal-pool>] [--thick-provision] --size <size> [--no-progress] <image-spec> Create an empty image. https://www.161616.top/ch05-1-rgw/ Wed, 31 Jul 2019 00:00:00 +0000 https://www.161616.top/ch05-1-rgw/ 什么是对象存储 对象存储是一种以非结构化格式（称为对象），简单来说，对象存储是一种将文件存储为对象而不是数据块的存储架构。它是一种将非结构化数据存储在跨位置分布的结构化平面文件系统中的方法。在这种格式中，文件空间由元数据标签组成，支持简单的 API 来描述、读取、删除和定位对象。因此，您可以通过 API 协议直接访问任何设备上保存的数据。此类元数据标签包括有助于更好地识别和分类数据的唯一标识符。 这些元数据标签是高度可定制的，让您可以在需要时通过跟踪和索引文件来轻松组织、访问和检索所有数据。对象存储服务可以在设备级、系统级甚至接口级实现。作为对象存储的数据可确保数据可用性、可搜索性并增强数据安全性，因为它可以保护数据免遭意外删除或损坏。 什么是 CEPH 中的对象存储 在知道了对象存储不能作为文件系统磁盘由操作系统直接访问，只可以通过应用程序级别的 API 进行访问。Ceph是一个分布式对象存储系统，通过一个 “网关服务” 来提供对象存储接口，这个服务被称为 RADOS Gateway ( RGW )，RGW是构建在 Ceph RADOS 之上，通过在 librados 之构建出的一个库 librgw，实际上是一个 Civetweb 的服务，rados gateway 内嵌在里面，RGW 为应用程序提供兼容 RESTful 的 S3/Swift 的 API 接口，以在 Ceph 集群中以对象的形式存储数据。Ceph 还支持多租户对象存储，可通过 RESTful API 访问。除此之外，RGW 还支持 Ceph 管理 API，可用于使用本机 API 调用来管理 Ceph 存储集群。 librados 是一个构建在 RADOS 集群和 Ceph 集群的中间层，通过这个库，提供了允许用户应用程序通过C、C++、Java、Python 和 PHP绑定直接访问 Ceph 存储集群。Ceph 对象存储还具有多站点 (MultiSite) 能力，即提供灾难恢复的解决方案。 图：Ceph RGW Structure Source：https://docs.ceph.com/en/octopus/radosgw/ 安装rgw rgw 包 ceph-radosgw https://www.161616.top/ch04-1-cephfs/ Wed, 31 Jul 2019 00:00:00 +0000 https://www.161616.top/ch04-1-cephfs/ Ceph专门提供了文件系统接口CephFS。CephFS是略微不同于RBD的架构形式，在基础的RADOS Cluster存储集群的基础之上，需要额外运行一个守护进程MDS MetaDataServer 元数据服务器。 RADOS Cluster自己是一个对象存储服务，他无法管理传统文件系统上分离去管理元数据和数据的功能。（而且元数据还拥有权限、用户属组、时间戳等。）RADOS Cluster自身是无法实现这个功能的。MDS专用于模拟传统文件系统所应该具有的将数据和元数据分离存储的方式而专门提供的一个服务。MDS只用来管理元数据。 MDS需要工作一个守护进程，客户端必须通过套接字的方式，每一次访问文件时，先去联系到MDS，来获取文件的元数据信息，再到RADOS Cluster以对象方式，将对象模拟成传统文件系统的块，来加载文件数据。 如是挂在CephFS系统的客户端，需先联系到MDS，识别文件系统的各种信息。客户端向挂载目录路径下的任何一个读写操作就相当于由挂载时的内核驱动模块联系到对应的MDS，而后再由客户端之上的模块来联系到RADOS Cluster。为了能够支持CephFS文件系统，也需要内核级模块Ceph.ko模块。挂载过程机制为将内核模块作为文件系统内核的客户端，与文件系统的守护进程进行通讯，必要时将用户数据存取转为对应集群的存储操作。 对于Rados存储集群来讲，存储集群所有数据都会被放在存储池当中，而CephFS管理其数据和元数据分别放置在不同的存储池中。所有元数据都是由MDS管理的。MDS也是客户端，连入CephFS的的metadata，专门用于存储元数据的存储池。 cephfs逻辑 元数据是一类很密集的IO访问。对原数据存储池的操作是放置在存储池当中的，但在本地会使用内存（高速缓存）中完成，过断时间同步到metadata pool中。而数据直接写入data存储池中 meatdata pool只能对mds访问，其他任何客户端时不能被访问的。客户端对元数据的访问必须经由MDS来实现。 当客户端打开一个文本时，首先请求客户端的inode（传统文件系统采用inode来保存文件的元数据）。获得相应授权以后从mds中接收到inode，inode中标示文件的数据究竟放置在data pool的那些对象中。返回对象编号给客户端，客户端基于对象编号访问所有的对象，将数据加载到。 ceph mds stat mds: 2 up:standby 当没有文件系统时，无法进行选举，故所有的都为standby CephFS Client访问CephFS集群的方式 客户端挂载CephFS， 基于内核文件系统完成挂载ceph、libcephfs 用户空间文件系统（FUSE Filesystem in USErspace）：libcephfs与ceph集群进行交互。 ==激活CephFS步骤== 激活CephFS MDS，至少有一个节点运行ceph-mds守护进程 ceph-deploy命令完成的 创建存储池：metadata-pool、data-pool bash 1 2 ceph osd pool create cephfs_metadata 8 8 ceph osd pool create cephfs_data 8 8 激活文件系统： ceph fs new <name> {metadata-pool-name} {pool-name} ceph fs status {filesystem-name} ceph fs stat 获得必要授权，才能使用服务 https://www.161616.top/ch07-1-cephx/ Sun, 30 Jun 2019 00:00:00 +0000 https://www.161616.top/ch07-1-cephx/ 如果需要与osd打交道，需要通过mon检索集群运行图才能够访问的客户端，通常经由mon认证后才能访问ceph存储。Ceph本身实现了数据服务的认证访问和授权控制机制，CephX协议来实现 CephX Protocol CephX本身只负责认证和授权检测，不处理通讯过程是否加密。一般来讲需要与moniotr交互的客户端组件（OSD、RBD、RGW等）一般而言都经由CephX认证 CephX认证机制 Ceph使用cephx协议对客户端进行身份认证 每个MON都可以对客户端进行身份验正并分发密钥，不存在单点故障和性能瓶颈。（在集群模式下，任何一个monitor在实现认证时是无状态的，每个monitor都能完成身份检验的任务） MON会返回用于身份验正的数据结构，其包含获取Ceph服务时用到的session key session key通过客户端密钥进行加密，需事先有一个预共享秘钥存在 客户端使用session key向MON请求所需的服务。session key只是拿来做中间通讯使用。 MON向客户端提供一个ticket，用于向实际处理数据的OSD等验正客户端身份。 MON和OSD共享同一个secret，因此OSD会信任由MON发放的ticket ticket存在有效期限 注意： CephX身份验正功能仅限制Ceph的各组件之间，它不能扩展到其它非Ceph组件。 它并不解决数据传输加密的问题。 为了实现Cephx认证，Ceph服务器端一定会为每一个客户端事先生成一个密码 认证与授权 无论Ceph客户端时何类型，Ceph都会在存储池中将所有的数据存储为对象 Ceph用户需要拥有存储池访问权限才能读取和写入数据 Ceph用户必须拥有执行全年才能使用Ceph管理命令 相关概念 用户 用户是指个人或系统参与者（例如应用） 通过创建用户，可以控制谁（或哪个参与者）能够访问Ceph存储集群、以及可访问的存储池及存储池中的数据。 Ceph支持多种类型的用户，单可管理的用户都属于Client类型 区分用户种类的原因在于，mon、osd、mds等系统组件也使用cephx协议，但它们非为客户端 通过点号来分隔用户类型和用户名，格式为TYPE.ID，例如：client.admin等 授权 使能（Capabilities） Ceph基于"使能(caps)“来描述用户可针对MON、OSD或MDS使用的权限范围或级别。 通用语法格式：daemon-type'allow caps[...] MON使能 包括r、w、x和allow profile cap 例如：mon allow rwx，以及mon allow profile osd’等。 OSD使能 包括r、w、x、class-read、class-write和profile osd 此外，OSD使能还允许进行存储池和名称空间设置。如为指定表示对所有OSD所有存储池都获得相关授权 MDS使能 只需要allow，或留空 各使能的意义 allow 需先于守护进程的访问设置指定 仅对MDS表示rw之意，其它的表示字面意义 r：读取权限，访问MON以检索CRUSH时依赖此使能 w：对象写入权限 x：调用类方法（读取和写入）的能力，以及在MON上执行auth操作的能力。 class-read：x能力的子集，授予用户调用类读取方法的能力 class-write：x的子集，授予用户调用类写入方法的能力 ·*：授予用户对特定守护进程/存储池的读取、写入和执行权限，以及执行管理命令的能力。 profile osd 授予用户以某个OSD身份连接到其他OSD或监视器的权限 授予OSD权限，使OSD能够处理复制检测信号流量和状态报告 profile mds 授予用户以某个MDS身份连接到其他MDS或监视器的权限 profile bootstrap-osd https://www.161616.top/ch01-1-ceph-acquaintance/ Sun, 30 Jun 2019 00:00:00 +0000 https://www.161616.top/ch01-1-ceph-acquaintance/ 初识Ceph Ceph 是一个开源分布式存储系统系统，它不是一种单一的存储，而是面向云提供一种统一存储平台，包含块存储 RBD, 文件存储 CephFS, 以及对象存储 RGW，这种存储的出现允许用户拜托供应商的绑定，它可以提供块存储到 “云平台”，也可以提供对象存储到 “应用”，并支持理论上的无限扩展性，数千客户端访问 PB 甚至 EB 级别的数据 SAN VS Ceph 与传统 SAN 存储相比，Ceph 客户端会计算他们所需的数据所在的位置，这消除了存储系统中需要在“中心化查找”的瓶颈。 这使得 Ceph 集群可以在不损失性能的情况下进行扩展。 Ceph 集群架构组成 Ceph 集群核心是 RADOS，而基于 RADOS，构建出多种类型存储，块存储, 文件系统, 对象存储，而一个基础的 Ceph 集群的组件由 “Ceph monitor” 与 “Ceph OSD Daemon” 组成 Ceph Monitor（进程名称为 ceph-mon，下文中以 ceph-mon 代表 Ceph Monitor） 维护集群映射的主副本。 ceph集群中的monitor，可确保 ceph-mon 守护进程在失败时的高可用性。客户端从 ceph-mon 检索集群映射的副本。 Ceph OSD Daemon 检查”自身“及”其他“ OSD 的状态并报告给 Monitor。 Ceph 中的常见术语 Application 用于使用 Ceph 集群的任何 Ceph 外部的应用程序 Block Device 也称为 “RADOS 块设备” 或 ”RBD“ ，协调基于块的数据存储的工具，Ceph块设备拆分基于块的应用程序数据 成“块”。 RADOS 将这些块存储为对象。 Ceph 块 设备协调这些对象的存储 存储集群。 https://www.161616.top/ch08-1-ceph-crush/ Sun, 30 Jun 2019 00:00:00 +0000 https://www.161616.top/ch08-1-ceph-crush/ 关于存储池 从某种意义上来讲，RADOS所提供的存储空间的管理接口，不应该将其放置在同一个平面当中，因此将其切割成多个不同的"逻辑存储空间"，称之为存储池。 RADOS存储集群提供的基础存储服务需要由"存储池（pool）“分割为逻辑存储区域，此类的逻辑区域亦是对象数据的名称空间。 实践中，管理员可以为特定的应用程序存储不同类型数据的需求分别创建专用的存储池，例如rbd存储池，rgw存储池等，也可以为某个项目或某个用户创建专有的存储池。 存储池还可以再进一步细分为一至多个名称空间（namespace）。同一个存储池内，无论属于哪个、哪些名称空间，数据都是被存储池中的PG进行存放，虽然处于不同名称空间，但可能处于同一个PG之上。 客户端(包括rbd和rgw等）存取数据时，需要事先指定存储池名称、用户名和密钥等信息完成认证，而后将一直维持与其指定的存储池的连接，于是也可以吧存储池看做是客户端的IO接口。 存储池类型 副本池（replicated）：任何一个数据对象存储在此类存储池中其冗余机制是通过创建多个数据对象副本来实现的，而副本数量是用户在创建存储池时指定。如，创建存储池时没指定类型，就是副本池，默认副本数量为3个（1主两从），统称副本数量。把每个对象在集群中存储为多个副本，其中存储于主OSD的为主副本，副本数量在创建存储池时由管理员指定；副本池类型为Ceph为默认的存储池类型。但是此存储池是非常浪费存储空间的。副本池对读IO有很好的附带表现 纠删码池（erasure code）：使用校验码可计算回数据。把各对象存储为N=K+M个块，其中，K为数据块数量，M为编码块数量，因此存储池的尺寸为K+M；纠删码块的数据就 是允许冗余的级别。如4+2，即允许最多两个数据块丢失。不是所有的应有都能支持纠删码池，如rbd必须使用副本池。radosGW可以使用纠删码池。 副本池IO 将一个数据对象存储为多副本 写入操作时，Ceph客户端使用CRUSH算法来计算对象的PG ID和Primary OSD 主OSD根据设定的副本教、对象的名称、存储池名称和集群运行图（Cluster Map）计算出PG的各铺助OSD，而后由主OSD将数据同步给这些辅助OSD。 对于有着三个副本的存储池来讲，任何一个PG都会选择三个OSD，因此，副本池所关联的OSD数量通常与冗余量相同。OSD，成为一个活动集。如图所示，其中一个OSD为主OSD负责读写操作，另外两个OSD负责从主OSD同步数据。当三个副本都存完，才能的到存储完成的消息的。客户的只需与主OSD通信，同步过程是OSD内部自行实现的。 纠删码池IO 纠删码是一种前向纠错码（FEC）代码 通过将K块的数据转换为N块，假设N=K+M，则其中的M代表纠删码算法添加的额外活冗余的块数量以提供冗余机制（即编码块），而N则表示在纠删码编码之后要创建的块的总数，其可以故障的块数为M（即N-K）个。 类似于RAID5 纠删码池减少了确保数据持久性所需的磁盘空间量，但计算量上却比副本存储池要更贵一些 RGW可以使用纠删码池，但RDB不支持。 例如，把包含数据ABCDEFGHI的对象NYAN保存到存储池中，假设纠删码算法会将内容分割为三个数据块：第一个包含ABC，第二个为DEF，最后一个为GHI，并为这三个数据块额外创建两个编码块：第四个YXY和第五个GQC，此时纠删码算法会通过计算哪家出GHI、和YXY 副本池所有从OSD没有次序之分，只有主和从两类角色之分，各个从没有次序。纠删码池是有次序的，这个顺序代表数据拼凑起来的数据。因此，每个分片应指定其在整个数据文件的偏移量是多少。 归置组 归置组（PlacementGroup）是用于跨OSD将数据存储在某个存储池中的内部数据结构。 相对于存储池来说，PG是一个虚拟组件，它是对象映射到存储池时使用的虚拟的层 出于规模伸缩及性能方面的考虑，Ceph将存储池细分为归置组，吧每个单独的对象映射到归置组，并将归置组分配给一个主OSD 存储池由一系列的归置组组成，而CRUSH算法则根据集群运行图和集群状态，将各PG均匀、伪随机地分布到急群众的OSD之上。 若某OSD失败或需要对集群进行重新平衡，Ceph则移动或复制整个归置组而无需单独寻址每个对象。 归置组在OSD守护进程和Ceph客户端之间生成了一个中间层，CRUSH算法负责将每个对象动态映射到一个归置组，然后再将每个归置组动态映射到一个或多个OSD守护进程，从而能够支持在新的OSD设备上线时动态进行数据重新平衡。 归置组作用 在存储池中存放100w数据对象，而使用100个归置组，一组内存放1w对象。归置组是从新平衡和恢复时的基本单元。使得数据单元不至于以文件或对象为单位。 归置组计数 归置组的数量有管理员在创建存储池是指定，而后由crush负责创建和使用 通常，PG的数量应该是数据的合理粒度的子集 例如，一个包含256个PG的存储池意味着每个PG包含大约1/256的存储池数据 当需要将PG从一个OSD移动到另一个OSD时，PG的数量会对性能产生影响 PG数量过少，Ceph将不得不同时移动相当数量的数据，其产生的网络负载将对集群的正常性能输出产生负面影响。 而在过多的PG数量场景中在移动极少量的数据时，Ceph将会占用过多的CPU和RAM，从而对集群的计算资源产生负面影响。 PG数量在集群分发数据和重新平衡时扮演着重要作用 在所有OSD之间进行数据持久存储及完成数据分布会需要较多的归置组，但是它们的数量应该减少到最大性能所需的最小数量值，以节省CPU和内存资源 一般说来，对于有着超过50个OSD的RADOS集群，建议每个OSD大约有50-100个PG以平衡资源使用，取的更好的数据持久性和数据分布，更大规模的集群中，每个OSD大约可持有100-200个PG 至少应该使用多少个PG，可通过下面的公式计算后，将其值以类似于四舍五入到最近的2的N次幂 (Total OSDs * PGPerOSD/Replication factor => Total PGs ) 可以使用的PG数量 = 总OSD数量* 每个OSD可以有多少个PG/复制因子（副本数量） 一个RADOS集群上可能会存在多个存储池，因此管理员还需要考虑所有存储池上的PG分布后每个OSD需要映射的PG数量 PG数量一定是2的N次方倍，这样进行hash计算时，速度才会更快。Ceph要求每一个OSD上最多不能超过256个PG 归置组状态 依据PG当前的工作特性活工作进程所阶段，它总是处于某个活某些个“状态中”，最常见的状态应该为active+clean PG的常见状态 Active 主OSD和各辅助OSD均处于就绪状态，可正常服务于客户端IO请求 一般Peering操作过程完成后即会转入Active状态 Clean 主OSD和各辅助OSD均处于就绪状态，所有对象的副本数量均符合期望，并且PG的活动集和上行集为同一组OSD。 活动集(Acting Set)：由PG当前的主OSD和所有的处于活动状态的辅助OSD组成，这组OSD负责执行此PG上数据对象的存取操作I/O 上行集(Up Set)，根据CRUSH的工作方式，集群拓扑架构的变动将可能导致PG相应的OSD变动活扩展至其他的OSD之上，这个新的OSD集也成为PG的“（Up Set）”，其映射到的新OSD集可能不分地与原有OSD集重合，也可能会完全不相干；上行集OSD需要从当前的活动集OSD上复制数据对象，在所有对象同步完成后，上行集便成为新的活动集，而PG也将转为“活动（active）”状态。 Peering 如数据不一致，需将数据复制过去，这个复制数据过程就称之为对等过程。 一个PG中的所有OSD必须就它们持有的数据对象状态达成一致，而“对等（Peering）”即为其OSD从不一致转为一致的过程。 Degraded 在某OSD标记为“down”时，所有映射到此OSD的PG即转入“降级（degraded）”状态 此OSD重新启动并完成Perring操作后，PG将重新转回clean 一旦OSD标记为down的时间超过5分钟，它将被标记出集群，而后Ceph将对降级状态的PG启动回复操作，直到所有因此而降级的PG重回clean状态 在其内部OSD上某对象不可用活悄然崩溃时，PG也会被标记为降级状态，知道对象从某个权威副本上正确恢复。 Stale 过期 每个OSD都要周期性的向RADOS集群中的监视器报告其作为主OSD所持有的所有PG的最新统计数据，因任何原因导致某个主OSD无法正常向监视器发送此类报告，或者由其他OSD报告某个OSD已经down掉，则所有以此OSD的PG将立刻被标记为stale状态。 Undersized PG中的副本数少于其存储池定义的个数时即转入undersized状态，回复和回填操作在随后会启动已修复其副本为期望值 Scrubbing 一致性保障的非常重要机制，文件完整性检查 各OSD还需要周期性的检查其所持有的数据对象的完整性，以确保所有对等OSD上的数据一致；处于此类检查过程中的PG便会被标记为scrubbing状态，这也通常被称作light scrubs、shallow scrubs或者simply scrubs。 另外，PG还需偶尔需要进行deep scrubs检查以确保同一对象在相关的各OSD上能按位匹配，此时PG将处于scrubbing+deep状态。 Recovering 恢复 添加一个新的OSD至存储集群中或某OSD宕掉时，PG则由可能会被CRUSH重新映射进而将持有与此不同的OSD集，而这些处于内部数据同步过程中的PG则被标记为recovering状态； Backfilling 回填 新OSD加入存储集群后，Ceph则会进入数据重新均衡的状态，即一些数据对象会在进程后台从现有OSD移到新的OSD之上，此操作过程为backfill。 CRUSH 把对象直接映射到OSD之上会导致二者之间的紧密耦合关系，变动底层OSD就会牵一发而动全身，因此在OSD设备变动时不可避免地对整个集群产生扰动 https://www.161616.top/ch01-2-cloud-base/ Sun, 30 Jun 2019 00:00:00 +0000 https://www.161616.top/ch01-2-cloud-base/ 初识Ceph Ceph 是一个开源分布式存储系统系统，它不是一种单一的存储，而是面向云提供一种统一存储平台，包含块存储 RBD, 文件存储 CephFS, 以及对象存储 RGW，这种存储的出现允许用户拜托供应商的绑定，它可以提供块存储到 “云平台”，也可以提供对象存储到 “应用”，并支持理论上的无限扩展性，数千客户端访问 PB 甚至 EB 级别的数据 SAN VS Ceph 与传统 SAN 存储相比，Ceph 客户端会计算他们所需的数据所在的位置，这消除了存储系统中需要在“中心化查找”的瓶颈。 这使得 Ceph 集群可以在不损失性能的情况下进行扩展。 Ceph 集群架构组成 Ceph 集群核心是 RADOS，而基于 RADOS，构建出多种类型存储，块存储, 文件系统, 对象存储，而一个基础的 Ceph 集群的组件由 “Ceph monitor” 与 “Ceph OSD Daemon” 组成 Ceph Monitor（进程名称为 ceph-mon，下文中以 ceph-mon 代表 Ceph Monitor） 维护集群映射的主副本。 ceph集群中的monitor，可确保 ceph-mon 守护进程在失败时的高可用性。客户端从 ceph-mon 检索集群映射的副本。 Ceph OSD Daemon 检查”自身“及”其他“ OSD 的状态并报告给 Monitor。 Ceph 中的常见术语 Application 用于使用 Ceph 集群的任何 Ceph 外部的应用程序 Block Device 也称为 “RADOS 块设备” 或 ”RBD“ ，协调基于块的数据存储的工具，Ceph块设备拆分基于块的应用程序数据 成“块”。 RADOS 将这些块存储为对象。 Ceph 块 设备协调这些对象的存储 存储集群。 https://www.161616.top/vsftp-network-filesystem/ Wed, 28 Sep 2016 00:00:00 +0000 https://www.161616.top/vsftp-network-filesystem/ 配置防火墙，开启FTP服务器需要的端口 CentOS 7.0默认使用的是firewall作为防火墙，这里改为iptables防火墙。 关闭firewall： bash 1 2 systemctl stop firewalld.service #停止firewall systemctl disable firewalld.service #禁止firewall开机启动 安装iptables防火墙 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 yum install iptables-services # 安装 vi /etc/sysconfig/iptables # 编辑防火墙配置文件 # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 10060:10090 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT :wq! https://www.161616.top/samba-network-filesystem/ Thu, 22 Sep 2016 00:00:00 +0000 https://www.161616.top/samba-network-filesystem/ 安装samba服务 text 1 yum install samba -y 配置samba服务 text 1 2 cp /etc/samba/smb.cnf{,.`date +%F`} #<== 修改前备份 vim /etc/samba/smb.cnf smb配置文件 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 #=================== Global Settings[全局选项] ============================== [global] workgroup = WORKGROUP #<==设定Samba Server所要加入的工作组或域 server string = Samba Server Version %v #<==设定注释，宏%v表示显示Samba的版本号 netbios name = zhi #<==设置Samba Server的NetBIOS名称 map to guest = bad user #<==开启匿名访问 # ----------------- Logging Options [日志选项]----------------------------- #设置日志文件存储位置及名称，宏%m(主机名),表示对每台访问Samba Server的机器都单独记录一个日志文件 log file = /var/log/samba/log. https://www.161616.top/nfs-network-filesystem/ Wed, 13 Apr 2016 00:00:00 +0000 https://www.161616.top/nfs-network-filesystem/ NFS介绍 什么是NFS NFS是 Network File System 网络文件系统。它的主要功能是通过网络（一般是局域网）让不同的主机系统之间可以共享文件或目录。NFS客户端（一般为应用服务器，例如Web）可以通过挂载（mount）的方式将NFS服务器端共享的数据目录挂载到NFS客户端本地系统中（就是某一个挂载点下）。从客户端本地看，NFS服务器端共享的目录就好像是客户端自己的磁盘分区或者目录一样，而实际上却是远端的NFS服务器的目录。 一般情况下，Windows网络共享服务或samba服务用于办公局域网共享，而互联网中小型网站集群架构后端常用NFS进行数据共享，如果是大型网站，那么有可能还会用到更复杂的分布式文件系统，例如：Moosefs（mfs）、GlusterFS、FastDFS。 NFS的历史介绍 第一个网络文件系统被称为File Access Listener，由Digital Equipment Corporation（DEC）在1976年开发。 NFS是第一个构建于IP协议之上的现代网络文件系统。在20世纪80年代，它首先作为实验的文件系统，由Sun Microsystems在内部完成开发。NFS协议归属于Request for Comments（RFC）标准，并且随后演化为NFSv2。作为一个标准，由于NFS与其他客户端和服务器的互操作能力很好而发展快速。 之后，标准继续演化，成为NFSv3，在RFC1813中有定义。这一新的协议比以前的版本具有更好的可扩展性，支持大文件（超过2GB），异步写入，并且将TCP作为传输协议，为文件系统在更广泛的网络中使用铺平了道路。在2000年，RFC 3010（由RFC 3530修订）将NFS带入企业级应用。此时，Sun引入了具有较高安全性、带有状态协议的NFSv4（NFS之前的版本都是无状态的）。今天，NFS版本的4.1（由RFC 5661定义）增加了对跨越分布式服务器并行访问的支持（称为PNFS extension）。 NFS系统已经历了近30年的发展。它代表了一个非常稳定的（及可移植）网络文件系统，具备可扩展、高性能等特性，并达到了企业级应用质量标准。由于网络速度的增加和延迟的降低，NFS系统一直是通过网络提供文件系统服务的有竞争力的选择，特别是在中小型互联网企业中，应用十分广泛。 NFS在企业中的应用场景 在企业集群架构的工作场景中，NFS网络文件系统一般被用来存储共享视频、图片、附件等静态资源文件，通常网站用户上传的文件都会放到NFS共享里，例如：BBS产品的图片、附件、头像（注意网站BBS程序不要放在NFS共享里），然后前端所有的节点访问这些静态资源时都可读取NFS存储上的资源。NFS是当前互联网系统架构中最常用的数据存储服务之一，前面说过，中小型网站公司应用频率更高，大公司或门户除了使用NFS外，还可能会使用更为复杂的分布式文件系统，比如Moosefs（mfs）、GlusterFS、FastDFS等。 企业生产集群为什么需要共享存储角色 例如：A用户传图片到Web1服务器，然后让B用户访问这张图片，结果B用户访问的请求分发到了Web2，因为Web2上没有这张图片，这就导致它无法看到A用户上传的图片，如果此时有一个共享存储，A用户上传图片的请求无论是分发到Web1还是Web2上，最终都会存储到共享存储上，而在B用户访问图片时，无论请求分发到Web1还是Web2上，最终也都会去共享存储上找，这样就可以访问到需要的资源了。这个共享存储的位置可以通过开源软件和商业硬件实现，互联网中小型集群架构会用普通PC服务器配置NFS网络文件系统实现。 当集群中没有NFS共享存储时，用户访问图片的情况如图所示。 如果集群中有NFS共享存储，用户访问图片的情况如图所示。 中小型互联网企业一般不会买硬件存储，因为太贵，大公司如果业务发展很快的话，可能会临时买硬件存储顶一下网站的压力，当网站并发继续加大时，硬件存储的扩展相对就会很费劲，且价格成几何级数增加。例如：淘宝网就曾替换掉了很多硬件设备，比如，用LVS+Haproxy替换了netscaler负载均衡设备，用FastDFS、TFS配合PC服务器替换了netapp、emc等商业存储设备，去IOE正在成为互联网公司的主流。 NFS系统原理介绍 NFS系统挂载结构图解与介绍 在NFS服务器端设置好一个共享目录/video后，其他有权限访问NFS服务器端的客户端都可以将这个共享目录/video挂载到客户端本地的某个挂载点（其实就是一个目录，这个挂载点目录可以自己随意指定），不同客户端的挂载点可以不相同。 客户端正确挂载完毕后，就可以通过NFS客户端的挂载点所在的/v/video或/video目录查看到NFS服务器端/video共享出来的目录下的所有数据。在客户端上查看时，NFS服务器端的/video目录就相当于客户端本地的磁盘分区或目录，几乎感觉不到使用上的区别，根据NFS服务器端授予的NFS共享权限以及共享目录的本地系统权限，只要在指定的NFS客户端操作挂载/v/video或/video的目录，就可以将数据轻松地存取到NFS服务器端上的/video目录中了。 什么是RPC 因为NFS支持的功能相当多，而不同的功能都会使用不同的程序来启动，每启动一个功能就会启用一些端口来传输数据，因此，NFS的功能所对应的端口无法固定，它会随机取用一些未被使用的端口来作为传输之用，其中CentOS 5.x的随机端口都小于1024，而CentOS 6.x的随机端口都是较大的。 因为端口不固定，这样一来就会造成NFS客户端与NFS服务器端的通信障碍，因为NFS客户端必须要知道NFS服务器端的数据传输端口才能进行通信，才能交互数据。 要解决上面的困扰，就需要通过远程过程调用RPC（Remote Proce-dure Call）服务来帮忙了，NFS的RPC服务最主要的功能就是记录每个NFS功能所对应的端口号，并且在NFS客户端请求时将该端口和功能对应的信息传递给请求数据的NFS客户端，从而确保客户端可以连接到正确的NFS端口上去，达到实现数据传输交互数据目的。这个RPC服务类似NFS服务器端和NFS客户端之间的一个中介，流程如图10-7所示。 拿房屋中介打个比喻吧：假设我们要找房子，这里的我们就相当于NFS客户端，中介介绍房子，就相当于RPC服务，房子所有者房东就相当于NFS服务，租房的人找房子，就要找中介，中介要预先存有房子主人的信息，才能将房源信息告诉租房的人。 那么RPC服务如何知道每个NFS的端口呢？ 当NFS服务器端启动服务时会随机取用若干端口，并主动向RPC服务注册取用的相关端口及功能信息，如此一来，RPC服务就知道NFS每个端口对应的NFS功能了，然后RPC服务使用固定的111端口来监听NFS客户端提交的请求，并将正确的NFS端口信息回复给请求的NFS客户端，这样一来，NFS客户端就可以与NFS服务器端进行数据传输了。 在启动NFS Server之前，首先要启动RPC服务（CentOS 5.8下为portmap服务，CentOS 6.6下为rpcbind服务，下同），否则NFS Server就无法向RPC服务注册了。另外，如果RPC服务重新启动，原来已经注册好的NFS端口数据就会丢失，因此，此时RPC服务管理的NFS程序也需要重新启动以重新向RPC注册。要特别注意的是，一般修改NFS配置文件后，是不需要重启NFS的，直接在命令行执行/etc/init.d/nfs reload或exportfs-rv即可使修改的/etc/exports生效。 NFS的工作流程原理 当访问程序通过NFS客户端向NFS服务器端存取文件时，其请求数据流程大致如下： 1）首先用户访问网站程序，由程序在NFS客户端上发出存取NFS文件的请求，这时NFS客户端（即执行程序的服务器）的RPC服务（rpcbind服务）就会通过网络向NFS服务器端的RPC服务（rpcbind服务）的111端口发出NFS文件存取功能的询问请求。 2）NFS服务器端的RPC服务（rpcbind服务）找到对应的已注册的NFS端口后，通知NFS客户端的RPC服务（rpcbind服务）。 3）此时NFS客户端获取到正确的端口，并与NFS daemon联机存取数据。 4）NFS客户端把数据存取成功后，返回给前端访问程序，告知用户存取结果，作为网站用户，就完成了一次存取操作。 因为NFS的各项功能都需要向RPC服务（rpcbind服务）注册，所以只有RPC服务才能获取到NFS服务的各项功能对应的端口号（port number）、PID、NFS在主机所监听的IP等信息，而NFS客户端也只能通过向RPC服务询问才能找到正确的端口。也就是说，NFS需要有RPC服务的协助才能成功对外提供服务。从上面的描述，我们不难推断，无论是NFS客户端还是NFS服务器端，当要使用NFS时，都需要首先启动RPC服务，NFS服务必须在RPC服务启动之后启动，客户端无需启动NFS服务，但需要启动RPC服务。 注意： NFS的RPC服务，在CentOS 5.X下名称为portmap，在CentOS 6.X下名称为rpcbind。 安装NFS服务 搭建NFS环境准备 克隆虚拟机 克隆的虚拟机存在的网络问题 原因分析：