上一篇分享了:PaaS中OpenShift持久化存储的管理实践和 解密OpenShift内部通信网络

本篇继续分享OpenShift的存储规划

1

OpenShift 使用存储类型选择

选择合适的存储有助于最大限度地减少所有资源的存储使用。通过优化存储, 管理员帮助确保现有存储资源以高效的方式工作。在 OpenShift 上可用的存储类型如下表 2-10 所示:

表 2-10 存储类型

存储类型

描述

示例

块存储

1.在操作系统中显示为块设备。

2.适用于可以完全绕过文件系统在底层块读写的应用

3.也称为存储区域网络 (SAN)。

4. 不可共享, 这意味着一次只能有一个客户端可以装载此类型的一个块。

Ceph RBD,OpenStack Cinder, AWS EBS, Azure Disk,GCE persistent disk和 VMware vSphere

文件系统存储

1.在操作系统中显示为文件系统

2.也称为网络连接存储 (NAS)。

3.并发性、延迟、文件锁定机制和其他功能在协议、实现、供应商和扩展之间差别很大。

Linux NFS,NetApp NFS, Azure File,Vendor NFS,AWS EFS

对象存储

1.通过REST API端点访问。

2.应用程序必须将其驱动程序构建到应用程序和容器中。

3.镜像仓库支持使用对象存储。

Ceph Object Storage (RADOS Gateway),OpenStack Swift,Aliyun OSS,AWS S3,Google Cloud Storage,Azure Blob Storage

上表按目前存在的三种存储类型整理了 OpenShift 支持的存储,主要是帮助读者理清三种存储的区别和分类,可以根据不同的需求选择合适类型的存储。除了公有云存储外,OpenShift 在私有云可以使用的主流的存储包括 NAS、Ceph 以及基于 Linux 实现的 NFS。我们基于不同维度对这几类存储做个对比,如下表 2-11 所示:

表 2-11 OpenShift 常用后端存储对比表

对比项

企业NAS (NFS协议)

OCS

基于Linux的NFS

PaaS平台容器数据持久化的支持

支持

支持

支持

客户端同时读写

支持同时读写

CephFS支持客户端同时读写

支持同时读写

服务端同时读写

支持同时读写

支持同时读写

不支持同时读写,有性能瓶颈

创建与挂载

手动创建,自动挂载

支持自动创建,自动挂载

手动创建,自动挂载

读写性能

高,主要取决于NAS性能

一般,主要取决于NFS使用的磁盘性能

服务器投资

相对较高,取决于NAS厂商和类型

一般,使用X86 Server建设集群

低,使用两台X86 Server建设

扩展能力

一般,取决于NAS本身对于可扩展的实现

高,可以动态增加或缩减数据存储池和节点

一般,可以动态增加或缩减数据存储池

安装和管理

安装简单、维护简单

安装简单、维护复杂

安装简单、维护简单

服务端故障恢复

当节点、硬件、磁盘、网络故障时,系统能自动处理,无须管理员介入

当节点、硬件、磁盘、网络故障时,系统能自动处理,无须管理员介入

底层存储的高可用依赖于存储硬件的高可用

客户端故障恢复

OpenShift平台会自动调度到其它可用节点并完成挂载

OCS管理平面通过OpenShift实现高可用,外置Ceph集群的高可用通过自身的架构设计实现。

OpenShift平台会自动调度到其它可用节点并完成挂载

如上表所示,基于 Linux 的 NFS 方案生产不推荐,因为数据高可用难保证,且有性能瓶颈;企业 NAS 看似是最好的选择,但是也存在成本较高,扩展难等问题。而 OCS 由于与 OpenShift 完美集成,并且支持外置 Ceph 的模式,因此会越来越成为 OpenShift 持久化存储的理想选择。

2

OpenShift 存储容量规划

OpenShift 存储容量规划包括 OpenShift 节点、OpenShift 附加组件、OpenShift 上运行的应用,由于 OpenShift 上运行的应用没有通用的存储容量规划方法,需要根据具体的业务需求规划,这里我们就不再讨论。下面我们将分别说明 OpenShift 节点和 OpenShift 附加组件这两部分的存储容量进行规划。

OpenShift 节点所需要的存储主要是节点文件系统上一些特殊的目录,通常消费本地存储。

2.1

Etcd 数据存储

Etcd 用于保存 OpenShift 所有的元数据和资源对象,官方建议将 Master 和 Etcd 部署在相同的节点,也就是 Etcd 数据保存在 Master 节点的本地磁盘,默认在/var/lib/etcd/目录下,该目录最小需要 20 GB 大小的存储。

2.2

Docker/CRI-O 本地存储

Docker/CRI-O 作为容器运行时,在每个节点都会运行,在运行过程中会保存镜像到本地以及为容器运行分配根空间都需要消耗本地磁盘,官方建议在生产环境中专门为运行时配置一块裸磁盘。这部分存储的大小取决于容器工作负载、容器的数量、正在运行的容器的大小以及容器的存储要求,通常建议配置 100G 甚至更大。另外,建议最好定期清理本地无用的镜像和容器,一方面是为了释放磁盘空间,一方面是为了提升运行时性能。

2.3

OpenShift 节点本地日志存储

OpenShift 节点运行的进程的日志默认存放在/var/log 目录下,该目录最小需要 15G。

除了这三个对于 OpenShift 相对关键的目录之外,其余操作系统分区规划遵循企业操作系统安装规范即可。在清楚了 OpenShift 节点存储规划之后,下面我们看看 OpenShift 附加组件的存储规划。OpenShift 包含一些附件组件是需要挂载持久存储的,如镜像仓库、日志存储等,这部分存储是挂载到容器中消费,通常使用的是非本地存储。主要包含如下几部分:

镜像仓库

镜像仓库可以选择的存储类型有块存储、文件系统存储、对象存储,我们推荐优先使用对象存储,其次是文件系统存储,最后才是块存储。如果选择块存储就只能一个实例读写,不利于镜像仓库高可用的实现。

OpenShift 中的镜像仓库包括 OpenShift 内部镜像仓库和外部镜像仓库。内部镜像主要用于存放在开发过程中生成的应用镜像,存储空间增长主要取决于构建生成应用的二进制文件的数量和大小;OpenShift 外部镜像仓库在开发测试环境用于存储应用所需要的基础镜像,如 Tomcat 镜像,存储空间主要取决于保存的基础镜像的数量和大小,对于一个企业来说,基础镜像相对是固定的,存储空间增长不会很大;在生产环境的镜像仓库存放用于发布生产的镜像,存储空间取决于保存应用镜像大小和数量。

经过上述描述,可以发现,开发测试环境的内部镜像仓库的存储空间增长是最快的,因为频繁的构建,每天会产生大量的镜像上传到内部镜像仓库。我们可以根据每天构建应用的次数以及每次构建生成应用二进制的大小粗略估计出该仓库所需要的存储空间,计算公式如下:

内部镜像仓库存储空间=平均每天构建应用的次数 平均应用二进制的平均大小 保留镜像的天数 + 基础镜像总大小

其中,基础镜像总大小可以在开发测试环境的外部镜像仓库拿到这个数据,当然也可以给一个适当足够大的值。

开发测试环境的外部仓库存放基础镜像,相对固定,每个企业对该仓库存储空间的需求是不一样的,按以往经验来说,通常配置 100G 或 200G 是足够的。

生产环境的镜像仓库可以通过平均每天发布应用的次数、平均镜像大小以及保留的天数,计算公式:

生产镜像仓库存储空间=平均每天发布应用的次数 平均镜像大小 保留的天数

到此为止,所有的镜像仓库存储容量就规划完了,如果在使用过程中出现了存储不足的情况,优先考虑清理无用镜像释放空间,如果确实无法释放,再考虑扩容空间。

日志系统

日志系统默认使用容器化的 EFK 套件,唯一需要挂载存储的是 ElasticSearch,可以选择的存储类型有块存储和文件系统存储。出于性能上的考虑,推荐优先使用块存储,其次选择文件系统存储。如果使用文件系统存储,则必须每个 ElasticSearch 实例分配一个卷。

ElasticSearch 存储大小可以使用以下方法进行粗略估算:

统计应用输出日志每行的平均字节数,如每行 256 bytes;统计每秒输出的行数,如每秒输出 10 行。那么一天一个 Pod 输出的日志量为:

256 bytes 10 60 60 24 大约为 216MB

在根据运行的 Pod 数目计算出每天大约需要的日志存储量,再根据需要保留的日志的天数计算出总日志存储空间需求,建议多附加 20%的额外存储量。

如在生产环境 200 个容器,24 小时积累日志 43G 左右。如果保留一周,则需要 300G 的存储空间。

上述计算只是估算了保存一份日志的存储空间,我们都知道 ElasticSearch 是通过副本机制实现数据的高可用的,这样为高可用 ElasticSearch 规划空间时还需要考虑副本数的影响,通常是根据一份日志的存储空间直接乘以保留的副本数。

以上方法只是一个粗略估计,如果需要更为精确的估算,则最好在应用稳定上线之后,通过 ElasticSearch 每天增加的存储空间推算每天的日志增长量。

OpenShift 监控系统

OpenShift 的监控系统使用 Prometheus 套件,需要挂载存储的组件有 Prometheus、AlertManager。可以使用存储类型都是块存储和文件系统存储,推荐优先使用块存储,其次使用文件系统存储。如果使用文件系统存储最好经过测试后再使用。

OpenShift 中的 Prometheus 默认使用 Operator 部署,配置存储需要配置动态存储类或提前创建好可用的 PV。Prometheus 有两个实例,AlerManager 有三个实例,总共需要 5 个 PV。

AlertManager 所需要的存储空间较小,按经验配置 40G 是足够的。Prometheus 所需要的存储与集群节点数、集群 Pod 数、保留数据天数(默认 15 天)等因素有关。官方在默认配置下,给出四组 Prometheus 测试数据供我们参考,如下表 2-12 所示:

表 2-12 Prometheus 存储需求测试数据

节点数

Pod总数

Prometheus每天增长的存储

Prometheus每15天增长的存储

50

1800

6.3GB

94GB

100

3600

13GB

195GB

150

5400

19GB

283GB

200

7200

25GB

375GB

根据上述测试数据,在默认配置下,Prometheus 在 15 天需要的存储量基本与节点数和 Pod 数呈线性增长,我们根据这个比例估算我们需要的存储量即可,同样建议在计算时多附加了 20%的额外存储量预防意外情况。

3

本文选自《OpenShift 在企业中的实践》(第 2 版),经出版社授权发布。

推荐语:经典畅销书再次升级!红帽首席解决方案架构师联合撰写,20 位全球知名企业 IT 负责人推荐,基于 OpenShift v4,详述 PaaS、DevOps、云原生、微服务治理。完整描绘企业数字化转型路线,为企业通过 OpenShift 实现 IT 转型给出具体建议和参考架构。


推荐阅读

限流 & 熔断的考量

2021-10-19

用企业架构下好数字化转型这盘大棋

2021-10-25

技术架构的战略和战术原则

2021-10-25

2021 编程语言排行榜

2021-10-22

微服务等于Spring Cloud?了解微服务架构和框架

2021-10-21

一个电商供应链系统的DDD实战

2021-10-20

解密OpenShift内部通信网络

2021-10-29

“钉钉打卡神器”开发者被判五年半!

2021-10-28

菜鸟技术专家胡斌:技术架构的战略和战术原则

2021-10-27

从0开始搭建公司后台技术栈,这套架构值得拥有...

2021-11-01

八个维度讲解秒杀系统架构分析与实战

2021-11-02

为什么国内 996 干不过国外的 955呢?

2021-11-01

解析OpenShift的存储规划相关推荐

  1. PaaS中OpenShift持久化存储的管理实践

    在 OpenShift 中,Pod 会被经常性的创建和销毁,也会在不同的主机之间快速的迁移.为了保证容器在重启或者迁移以后能够使用原来的数据,就必须使用持久化存储.所以,持久化存储的管理对于 PaaS ...

  2. PVS的内存和存储规划设计

    提示:这篇文章是本人在2012年12月11日有感而写的一篇电子邮件,因为其中的内容会在即将发表的一篇新博文被引用,故重新贴于此处.由于是近三年前的内容,技术也在不断进步,其中的部分内容已经不再适合于现 ...

  3. MySQL的三层架构(连接认证、解析优化和存储引擎)

    对于数据库的认识,相信很大一部分人像我一样只停留在写各种SQL.优化各种查询语句以及索引的建立之上,只是停留在"会用"的基础上.但是如果想要充分发挥MySQL的性能,就必须要了解其 ...

  4. oracle安装rac前存储配置,Oracle11g RAC+ASM安装前存储规划注意事项

    关于Oracle数据库性能优化,最好从什么时候开始更合适呢?,根据自己几年下来的实际经验,我想从安装前的存储规划开始最好.存储 关于Oracle数据库性能优化,最好从什么时候开始更合适呢?,根据自己几 ...

  5. 巨杉Tech | SequoiaDB数据域及存储规划

    1 背景 近年来,企业的各项业务发展迅猛,客户数目不断增加,后台服务系统压力也越来越大,系统的各项硬件资源也变得非常紧张.因此,在技术风险可控的基础上,希望引入大数据技术,利用大数据技术优化现有IT系 ...

  6. OpenShift集群规划

    NSX ALB + Harbor + OpenShift 4.8 UPI安装配置实验笔记系列目录 目录 前言 1. OpenShift集群部署过程与节点说明 2 OCP LAB规划 2.1 虚机节点配 ...

  7. 桌面虚拟化最佳实践4—存储规划(下)

    上面我们从系统层面以及VIEW的软件层面详细描述了如何进行存储的优化,下面我们从硬件以及协议层面来看看如何规划桌面虚拟化项目中的存储. 存储协议选项 VMware ESX 3.0 及更高版本支持为虚拟 ...

  8. 深度解析数据湖存储方案Lakehouse架构

    简介:从数据仓库.数据湖的优劣势,湖仓一体架构的应用和优势等多方面深度解析Lakehouse架构. 作者:张泊 Databricks 软件工程师 Lakehouse由lake和house两个词组合而成 ...

  9. 案例解析|从数据规划、业务分析到管理决策的数据治理方案

    随着技术的发展,IT逐渐面临越来越多的挑战,尤其是数据治理方面.而九州通医药集团在IT建设方面不畏艰险,自主研发ERP系统.物流系统,在解决企业自身问题的同时还创新投入商业化,为同行业提供服务,树立标 ...

最新文章

  1. SAP Retail MM41 维护商品主数据,报错 - 估价范围 NM01 还没有生产式的物料帐簿 – 之对策
  2. SQL语句利用日志写shell
  3. KVM virtio_net之NAPI机制(十七)
  4. web项目中关于引入JS/css文件, 浏览器console出现 net::ERR_ABORTED错误的解决方法
  5. 简单使用URLConnection、HttpURLConnection和HttpClient访问网络资源
  6. SpringBoot与Spring的对比
  7. 在linux下,如何在C语言中使用正则表达式
  8. 组合数 com(n,r)
  9. 淘宝商品数据库设计的一些经验
  10. 计算机控制面板图标怎么删除,电脑如何找回消失的“添加或删除程序”图标
  11. SDUTOJ3469_深度优先搜索练习之神奇的矩环(DFS)
  12. docker知识总结
  13. 菜鸟裹裹电脑版_天猫淘宝“基本盘”放缓,阿里云、菜鸟爆发,马云迎来拐点?...
  14. 系统集成项目管理工程师-历年真题分析与解答 Android版
  15. cmd关闭kill进程
  16. java读取propertiies文件例子
  17. python训练数据集_python 划分数据集为训练集和测试集的方法 python中如何实现将数据分成训练集与测试集...
  18. C语言中的 pow 函数 使用方法及注意事项,和常见报错原因,且分享实战中的使用
  19. 电脑端知乎不显示图片
  20. J-Link 下载程序 接线图

热门文章

  1. vaex 处理海量数据_Vaex真香!几秒钟就能处理数十亿行数据,比Pandas、Dask更好用...
  2. 闭式系统蒸汽管径推荐速度_空调水系统设计、空调风系统设计要点
  3. 已跳过全部重新生成_2020年最新跳对公技术1+5,1+10,5+50(必读)
  4. linux打开文件int open,Linux下C语言open函数打开或创建文件与read,write函数详细讲解...
  5. linux系统chmod缩写,文件属性控制命令chmod
  6. java web访问webroot_java web 之 WebRoot和WebContent目录
  7. linux 统计目录大小并按大小排序
  8. apache shiro版本查看_深入学习SpringBoot(四):springboot整合shiro
  9. (王道408考研数据结构)第四章串-第一节:串的定义和基本操作及存储结构
  10. 3-2:类与对象上篇——类的对象模型和计算类的大小以及this指针问题