0%

Ceph硬件准备

大部分的推荐配置来源于http://docs.ceph.org.cn/

Ceph为普通硬件设计,这可以让维护构建PB级别的数据集群的费用相对来说更低廉。在搭建集群前最初的硬件架构设计极为重要。你需要均衡几个方面的因素,包括区域实效和潜在的性能问题。硬件规划包含要把使用Ceph集群的Ceph守护进程和其他进程所需要的资源恰当合理分布。

通常只推荐在一台机器上运行一种类型的守护进程。我们推荐把使用数据集群的进程(如 Openstack、CloudStack等)安装在别的机器上。

CPU

Ceph元数据服务器对CPU敏感,他会动态地重分布他们的负载,所以你的元数据服务器应该有足够的处理能力(如4核或更强悍的CPU)。Ceph的OSD运行着RADOS服务,用CRUSH算法计算着数据存放位置、复制数据、维护它自己的集群运行图副本,因此OSD需要一定的处理能力(如双核心CPU)。Ceph监视器只简单地维护者集群运行图的副本,因此对CPU不敏感。

但是需要考虑是否未来会在Ceph监视器的机器会运行其他的CPU密集型任务。比如运行用于计算的虚拟机(Openstack NOVA),你就要确保给Ceph进程保留足够的处理能力,所以推荐在其他机器上运行CPU密集型任务。

内存

元数据服务器和监视器必须尽可能快的提供他们的数据,所以元数据服务器与监视器至少每个进程分配1G内存。

OSD的日常运行不需要那么多的内存,但是也要确保每个进程能分配到500M的内存,通常来说在进行数据恢复的期间他们占用的内存比较大,每TB级数据需要1GB的内存。

通常内存越多越好。

数据存储

谨慎的规划数据和数据存储架构,因为期间涉及明显的成本和性能折衷。

来自操作系统的并行操作和到单个硬盘的多个守护进程的并发读写会极大的降低性能。同时文件系统局限性也要考虑,btrfs尚未稳定到可以用于生产环境的程度,但它可以同时记录日志并写入数据,而xfs和ext4不能。

Ceph发送ACK前必须把所有数据写入日志(至少对xfs和ext4来说是),因此均衡日志和OSD性能相当重要。

磁盘驱动器

OSD应该有足够的空间用于存储对象数据。考虑到大硬盘的没GB成本,建议使用容量大于1TB的硬盘。建议用GB数除以硬盘价格来计算每GB的成本,因为较大的硬盘通常会对每GB成本有较大影响。

值得注意的是,单个驱动器的容量越大,其对应的OSD进程所需要的内存就越大,特别是在重均衡、回填、恢复期间。1TB的存储空间大约需要1GB内存。

在单个硬盘上运行多个OSD,这样不太妙!
在运行了OSD的磁盘上又同时运行着监视器或者云数据服务器这样也不太妙!

磁盘驱动器受限于寻道时间、访问时间、读写时间、还有吞吐量这些磁盘的物理局限影响着整体系统的性能,特别是在出现故障系统恢复期间。因此推荐独立的磁盘用于安装操作系统和软件,避免增加OSD存储磁盘的负担以提升性能。

Ceph可以在每块硬盘上运行多个OSD,但这会导致资源竞争并降低总体吞吐量;Ceph也允许把日志和对象数据存储在相同的磁盘驱动器上,但这会增加记录写日志并回应客户端的延迟,因为Ceph必须先写入日志才会回应确认了写动作。btrfs文件胸能同时写入日志数据和对象数据,而xfs、etx4不能。

Ceph最佳实践指示,应该分别在单独的硬盘运行操作系统、OSD和OSD日志。

固态硬盘

一种提升性能的方法是使用固态硬盘SSD来降低随机访问时间和读延时,同时增加吞吐量。SSD和硬盘相比每GB的成本通常要高出10倍以上,但访问时间至少比硬盘快100倍!

SSD没有可移动机械部件,所以不存在和硬盘一样的局限性。但是SSD也有其他的局限性,评估SSD时,顺序读写的性能很重要,在为多个OSD存储日志时,有着400MB/s顺序读写吞吐量的SSD性能远高于120MB/s的。

建议发觉SSD的用法来提升性能,在大量投入SSD前,强烈建议核实SSD的性能指标,并在测试环境下衡量性能。相对廉价的SSD虽然价格很诱人,但是要谨慎使用!一分钱一分货的道理是永恒不变的。

正是因为SSD没有移动机械部件,所以它很适合Ceph里不需要太多存储空间的地方。可接受的IOPS指标对选择用于Ceph的SSD还不够,用于日志和SSD时还有几个重要考量:

  • 写密集语意:写日志数据涉及密集语意,所以要确保选用的SSD写入性能和硬盘相当或者好于硬盘。廉价SSD可能在加速访问的同时引入写延时,有时候高性能的硬盘的写入速度可以和便宜的SSD硬盘相媲美。
  • 顺序写入:在一个SSD上为多个OSD存储多个日志时也必须考虑SSD的顺序写入极限,因为它们要同时处理多个OSD日志的写入请求。
  • 分区对齐:采用SSD的一个常见问题是人们喜欢分区,却常常忽略了分区对齐,这会导致SSD的数据传输速率慢很多,所以请确保分区对齐了。

SSD用于对象存储太昂贵了,但是把OSD的日志存到SSD、把对象数据存储到独立的硬盘可以明显提升性能。osd journal选项的默认值是/var/lib/ceph/osd/$cluster-$id/journal,所以说可以把目录存储的位置更改到SSD磁盘或SSD的分区上,这样它就不再是和对象数据一样存储在同一个硬盘上的文件了。

提升CephFS文件系统性能的一种方法是从CephFS文件内容中分离出元数据。Ceph提供了默认的metadata存储池来存储CephFS元数据,所以你不需要给CephFS元数据创建存储池,但是可以给它创建一个仅指向某主机SSD的CRUSH运行图。具体详情见OSD与Pool池的常见操作及管理

硬盘控制器

硬盘控制器也会对吞吐量有显著影响,要谨慎的选择控制器,以免产生性能瓶颈。

网络

建议每台机器最少两个千兆网卡,现在大多数的机械硬盘都能达到100MB/s的吞吐量,网卡应该能处理所有的OSD硬盘总吞吐量,所以推荐最少两个千兆网卡分别用于公网和集群网络。集群网络用来处理数据复制产生的额外负载,而且可以防止拒绝服务攻击,拒接服务攻击会干扰数据归置组,使OSD数据复制时不能回到active+clean状态。所以最好考虑使用两个万兆网卡。

通过 1Gbps 网络复制 1TB 数据耗时 3 小时,而 3TB (典型配置)需要 9 小时,相比之下,如果使用 10Gbps 复制时间可分别缩减到 20 分钟和 1 小时。在一个 PB 级集群中, OSD 磁盘失败是常态,而非异常;在性价比合理的的前提下,系统管理员想让 PG 尽快从 degraded (降级)状态恢复到 active + clean 状态。

增加的硬件成本可用节省的运营(网络安装、维护)成本抵消。使用 VLAN 来处理集群和计算栈(如 OpenStack 、 CloudStack 等等)之间的 VM 流量时,采用 10G 网卡仍然值得。每个网络的机架路由器到核心路由器应该有更大的带宽,如 40Gbps 到 100Gbps 。

其他要注意的点

可以在同一台主机上运行多个OSD,但是要确保OSD硬盘总吞吐量不超过客户端提供读写服务所需的网络带宽;还要考虑集群在每台主机上所存储的数据占总体的百分比,如果一台主机所占百分比太大而它宕机了,就可能导致诸如超过full ratio的问题,此问题会使Ceph中止运作以防止数据丢失。

保证内核是最新的,确保硬件性能可以达到期望值。

OSD数量比较多的主机会产生大量OSD线程,尤其是在恢复和重均匀期间。很多Linux内核默认的最大线程数较小(如 32K 个),如果遇到了这类问题,可以把kernel.pid_max 值调高些。理论最大值是 4194303 。例如把下列这行加入 /etc/sysctl.conf 文件:

kernel.pid_max = 4194303

故障域

故障域指任何导致不能访问一个或多个 OSD 的故障,可以是主机上停止的进程、硬盘故障、操作系统崩溃、有问题的网卡、损坏的电源、断网、断电等等。规划硬件需求时,要在多个需求间寻求平衡点,像付出很多努力减少故障域带来的成本削减、隔离每个潜在故障域增加的成本。

OSD与Pool池的常见操作及管理

查看osd状态

ceph -s

通过ceph -s可以查看集群的概况,其中包括了部分osd相关的健康信息。

ceph-s-osd-down-1-2020-07-26

ceph osd stat

ceph osd stat可以验证当前集群内的状态。

[ceph@servera ~]$ ceph osd stat
9 osds: 9 up, 9 in

当前集群内共有9个OSD,目前这9个OSD的状态均为OK!

ceph osd tree

ceph osd tree 显示所有的OSD列表

ceph-osd-tree-1-2020-10-23

在ID列,可以看到每一个OSD的ID均为正数,并且每个OSD的ID顺序是打乱、分散的。3台机器共9个OSD的ID被随机分配了。

值得注意的点是所有的主机和集群也被进行了ID编号,只不过它们的编号为负数。

ceph osd df

如果要查看每个OSD的使用情况以及数据所占用OSD空间的百分比,可以使用ceph osd df命令查看。

ceph-osd-df-1-2020-07-26

删除Pool

ceph osd pool delete rbd rbd --yes-i-really-really-mean-it

想要删除一个Pool你需要按照上面的格式进行确认,但是即便是一再确认,默认情况下MON节点还是不允许你删除Pool池。会提示Error EPERM: pool deletion is disabled; you must first set the mon_allow_pool_delete config option to true before you can destroy a pool

那么有下面两种方式可以删除Pool:

修改MON配置文件

修改配置文件,在配置文件中标记允许删除Pool,这样在重启集群所有的MON节点后会重新读取到这条配置文件,在删除Pool的时候不会进行阻拦。

vim /etc/ceph/ceph.conf

所有的MON节点下的配置文件中添加下面的配置:

[mon]
mon allow pool delete = true

修改后保存设置,重启集群内所有的MON节点服务

之后执行ceph osd pool delete rbd rbd --yes-i-really-really-mean-it就可以删除掉。

这种方式要登录到所有的MON节点机器中修改配置,并且需要重启MON节点服务,如果你是单节点集群或者对集群的稳定性有严格需求,这种方式不太友好。

使用ceph tell运行时注入配置

Ceph支持运行时注入配置,那么可以进行下面的操作:

ceph tell mon.* injectargs --mon_allow_pool_delete true

之后会看到输出:

mon.vm1: {}
mon.vm2: {}
mon.vm3: {}
mon.vm1: mon_allow_pool_delete = 'true'
mon.vm2: mon_allow_pool_delete = 'true'
mon.vm3: mon_allow_pool_delete = 'true'

此时执行ceph osd pool delete rbd rbd --yes-i-really-really-mean-it就可以删除掉刚才不能删除的Pool。

Pool池

Pool是一个抽象的存储池,它是PG之上的一层逻辑。它规定了数据冗余的类型以及对应的副本分布策略。

目前有两种pool类型:replicated类型和Erasure Code类型。

  • 一个pool由多个PG构成,一个PG只能属于一个Pool
  • 同一个Pool中的PG具有相同的类型,比如,如Pool为副本类型,则Pool中所有的PG都是多副本的

注意:在ceph 12.2.1(luminous)版本中,目前还不支持缩减PG、PGP数量,但是可以增加它们的数量,这适用于OSD存储节点的扩容,但是却不利于缩减OSD存储节点……
不过在

创建副本Pool

使用副本Pool时,每个对象都会被复制到n个osd上进行存储。复制几份由pool的size属性决定,默认情况下会有3个副本,在生产环境下应该至少存在3个副本才可以保证数据可靠性。

ceph osd pool create <poolname> <int[0-]> {<int[0-]>} {replicated|erasure} {<erasure_code_profile>} {<rule>} {<int>}

现在来创建一个名字叫rbd的Pool,使用默认的replicated模式创建并且默认的副本数量为3,将它的PG和PGP数量设置为64。

ceph osd pool create rbd 64 64

创建纠删码Pool

使用纠删码Pool可以减少副本的磁盘占用并且能与副本Pool得到同等的数据保护效果。它可以减少集群为了保护数据而而外付出的存储开销。

不过使用纠删码虽然与副本类型相比会减少很多存储空间,但是需要对数据进行较多的运算。在回复数据时会占用大量的计算资源如CPU、内存。

创建一个名字为reapool的PG、PGP数为50的纠删码类型Pool:

ceph osd pool create reapool 50 50 erasure

纠删码由配置定义,在创建纠删码存储池及其相关的 CRUSH 规则时用到。

创建 Ceph 集群时初始化的、名为 default 的纠删码配置可提供与两副本相同的冗余水平,却能节省 25% 的磁盘空间。在此配置中 k=2 和 m=1 ,其含义为数据分布于 3 个 OSD ( k+m==3 )且允许一个失效。

为了在不增加原始存储空间需求的前提下提升冗余性,你可以新建配置。例如,一个 k=10 且 m=4 的配置可容忍 4 个 OSD 失效,它会把一对象分布到 14 个( k+m=14 ) OSD 上。此对象先被分割为 10 块(若对象为 10MB ,那每块就是 1MB )、并计算出 4 个用于恢复的编码块(各编码块尺寸等于数据块,即 1MB );这样,原始空间仅多占用 10% 就可容忍 4 个 OSD 同时失效、且不丢失数据。

详见修改纠删码副本及冗余数量

管理和操作Pool

为Pool设置应用

在创建一个pool之后,你应该把这个pool分配一个application对这个pool进行标记。可以设置的应用有cephfsrbdrgw

ceph osd pool application enable <poolname> <app>

现在将刚刚创建名字为rbd这个Pool设置为用于rbd应用。

ceph osd pool application enable rbd rbd

在没有设置应用之前,使用ceph -s查看集群状态可能会有警告提示。设置之后再次查询,警告消失。

ceph -sceph health detail

通过eph osd pool application get rbd命令查看application发现已激活rbd应用在这个pool上。

[ceph@servera ~]$ ceph osd pool application get rbd
{
"rbd": {}
}

查看Pool信息

查看集群内的Pool

ceph osd lspools

[ceph@servera ~]$ ceph osd lspools
7 rbd,8 testpool,

ceph osd pool ls

[ceph@servera ~]$ ceph osd pool ls
rbd
testpool

查看集群内Pool的资源使用情况

ceph df

[ceph@servera ~]$ ceph df
GLOBAL:
SIZE AVAIL RAW USED %RAW USED
170G 169G 1071M 0.61
POOLS:
NAME ID USED %USED MAX AVAIL OBJECTS
rbd 7 0 0 82552M 0
testpool 8 0 0 82552M 0

查看每个OSD资源使用情况

ceph osd df

[ceph@servera ~]$ ceph osd df
ID CLASS WEIGHT REWEIGHT SIZE USE AVAIL %USE VAR PGS
0 hdd 0.01849 1.00000 19444M 117M 19327M 0.61 0.99 197
3 hdd 0.01849 1.00000 19444M 117M 19327M 0.61 0.99 213
8 hdd 0.01849 1.00000 19444M 117M 19327M 0.60 0.99 204
2 hdd 0.01849 1.00000 19444M 127M 19317M 0.66 1.08 206
4 hdd 0.01849 1.00000 19444M 117M 19327M 0.61 0.99 185
6 hdd 0.01849 1.00000 19444M 117M 19327M 0.60 0.99 205
1 hdd 0.01849 1.00000 19444M 117M 19327M 0.61 0.99 181
5 hdd 0.01849 1.00000 19444M 117M 19327M 0.60 0.99 200
7 hdd 0.01849 1.00000 19444M 117M 19327M 0.60 0.99 209
TOTAL 170G 1068M 169G 0.61
MIN/MAX VAR: 0.99/1.08 STDDEV: 0.02

查看Pool当前执行的任务,可以使用ceph osd pool stats来查看Pool当前正在执行的任务和写入、读取速度。

[ceph@servera ~]$ ceph osd pool stats
pool rbd id 7
nothing is going on

pool testpool id 8
nothing is going on

重命名Pool

你可以使用ceph osd pool rename命令重新命名你不满意的名字。

osd pool rename <current_poolname> <new_poolname>

对Pool进行快照

你可以创建或者删除一个Pool的快照。

ceph osd pool mksnap/rmsnap <poolname> <snap>

对当前的rbdPool进行创建快照操作:

ceph osd pool mksnap rbd rbd@snap-20200721

查看该Pool中创建的Pool快照:

rados lssnap -p rbd

[ceph@servera ~]$ rados lssnap -p rbd
1 rbd@snap-20200721 2020.07.21 15:26:39
1 snaps

删除刚刚创建的快照:

ceph osd pool rmsnap rbd rbd@snap-20200721

还原快照:

rados -p <poolname> rollback <obj-name> <snap-name>

rados -p <poolname> -s <snap-name> get <obj-name> file

Ceph支持两种类型的快照,一种是pool snaps,也就是Pool级别的快照,是给整个pool中的对象整体做一个快照。另一个是self managed snaps,rbd使用的就是这种类型的快照。
要注意的是:这两种快照类型是互斥的,不能同时存在。如果你要是用Pool快照那么默认情况下就不能在这个Pool下创建RBD了。

更改Pool参数

对Pool进行调整可以设置副本数、纠删码份数,还可以限制该Pool所使用的资源大小等。

ceph osd pool set <poolname> <parameter> <value>

限制Pool所用资源数量

管理员可以对Pool设置限额(quotas)来限制最大使用的存储量和对象(object)数量。

ceph osd pool set-quota <poolname> max_objects|max_bytes <val>

限制rbdPool最大仅能使用1GB存储空间:

ceph osd pool set-quota rbd max_bytes 1073741824

更改副本数/纠删码个数

修改副本数

在实际生产环境中副本数通常在3个或以上。默认的副本数是两个,不过保险起见生产环境下应越多越保险。

ceph osd pool set rbd size 3

修改纠删码副本及冗余数量

使用纠删码创建的Pool可以配置纠删码算法及相应规则,你可以自己新建一个纠删码规则适用于当前的业务需求。

和副本模式相比纠缠码可以大幅减少存储成本,但当集群内的其他OSD遇到数据盘损坏时会重新计算丢失的数据。这会对计算资源和网络资源造成较大的负担!

合理的配置纠删码文件可以带来更好的效率。

使用ceph osd erasure-code-profile get default查看创建一个纠删码模式的Pool时默认的的配置信息。

k=2
m=1
plugin=jerasure
technique=reed_sol_van
  • k 对对象分割的数量,k=2为默认值。对一个对象分割成两部分。
  • m 纠删码数量,默认m=1。假如k=2时,一个对象文件被分割成了两份存在了不同的OSD上,此时有一个OSD坏掉了的话通过纠删码就可以计算出坏掉的那个OSD磁盘中的数据。

创建一个新的纠删码配置

ceph osd erasure-code-profile set {name} \
[{directory=directory}] \
[{plugin=plugin}] \
[{stripe_unit=stripe_unit}] \
[{key=value} ...] \
[--force]
  • directory 设置纠删码插件的路径,需是目录。
  • plugin 指定纠删码插件来计算编码块、及恢复丢失块。
  • stripe_unit 每一个条带中、一个数据块的数据量。例如,在一个配置中,数据块为 2 且 stripe_unit=4K ,数据进来时会把 0-4K 放入块 0 , 4K-8K 放入块 1 ;然后 8K-12K 又是块 0 。为实现最佳性能,这里应该设置成 4K 的倍数。默认值是在存储池创建时从监视器配置选项 osd_pool_erasure_code_stripe_unit 获取的。一个使用着这个配置的存储池,其 stripe_width 值(条带宽度)就是数据块的数量乘以这里的 stripe_unit 值。
  • key 纠删码插件所定义的键/值对含义。

创建一个k=6,m=3的纠删码配置文件:

ceph osd erasure-code-profile set test k=6 m=3

查看test纠删码配置信息

ceph osd erasure-code-profile get test

[ceph@servera ~]$ ceph osd erasure-code-profile get test
crush-device-class=
crush-failure-domain=host
crush-root=default
jerasure-per-chunk-alignment=false
k=6
m=3
plugin=jerasure
technique=reed_sol_van
w=8

创建一个新的纠删码类型Pool并使用刚刚创建的test纠删码配置进行创建。

ceph osd pool create erasurepool 10 10 erasure test

查看Pool信息

ceph osd pool ls detail

pool 12 'erasurepool' erasure size 9 min_size 7 crush_rule 2 object_hash rjenkins pg_num 10 pgp_num 10 last_change 618 flags hashpspool stripe_width 24576

删除Pool

ceph osd pool delete rbd rbd --yes-i-really-really-mean-it

想要删除一个Pool你需要按照上面的格式进行确认,但是即便是一再确认,默认情况下MON节点还是不允许你删除Pool池。会提示Error EPERM: pool deletion is disabled; you must first set the mon_allow_pool_delete config option to true before you can destroy a pool

那么有下面两种方式可以删除Pool:

修改MON配置文件

修改配置文件,在配置文件中标记允许删除Pool,这样在重启集群所有的MON节点后会重新读取到这条配置文件,在删除Pool的时候不会进行阻拦。

vim /etc/ceph/ceph.conf

所有的MON节点下的配置文件中添加下面的配置:

[mon]
mon allow pool delete = true

修改后保存设置,重启集群内所有的MON节点服务

之后执行ceph osd pool delete rbd rbd --yes-i-really-really-mean-it就可以删除掉。

这种方式要登录到所有的MON节点机器中修改配置,并且需要重启MON节点服务,如果你是单节点集群或者对集群的稳定性有严格需求,这种方式不太友好。

使用ceph tell运行时注入配置

Ceph支持运行时注入配置,那么可以进行下面的操作:

ceph tell mon.* injectargs --mon_allow_pool_delete true

之后会看到输出:

mon.vm1: {}
mon.vm2: {}
mon.vm3: {}
mon.vm1: mon_allow_pool_delete = 'true'
mon.vm2: mon_allow_pool_delete = 'true'
mon.vm3: mon_allow_pool_delete = 'true'

此时执行ceph osd pool delete rbd rbd --yes-i-really-really-mean-it就可以删除掉刚才不能删除的Pool。

Pool命名空间

命名空间是Pool池的逻辑组。可以设置一个命名空间限制个个用户能访问到该Pool的范围,限制用户只访问到该Pool的部分范围。当然也可以按照不同应用应用的方式进行分组。

要存储一个对象到命名空间时客户端需要指明Pool和命名空间。

默认情况下每个Pool包括一个孔明成的命名空间作为默认的命名空间使用。

放置对象到命名空间

使用rados命令可以将Object对象放置在Pool上的指定命名空间内。

rados -p <poolname> [-N <namespace>] put <obj-name> [infile] [--offset offset]

rados -p rbd -N system put release /etc/redhat-release

上面这个命令是将/etc/redhat-release这个文件放在了rbd存储池的system命名空间里,并且文件名为release

列出命名空间内的对象

rados -p <poolname> [-N <namespace>] ls [--all]

列出rbd存储池中system命名空间下的对象:

rados -p rbd -N system ls

返回列表如下,返回的这些object都是属于system这个命名空间下的对象。

services-name
release

不过,在不指明命名空间的情况下,只能看得到默认命名空间里的对象,如果要显示出该Pool内全部命名空间的对象的话如何操作?

rados -p rbd ls --all

system  services-name
system release
release

这样就可以显示出全部命名空间里的对象名称了,那么没有名字的release对象就是存放在默认的命名空间下。

还可以以JSON的格式进行输出:

rados -p rbd ls --all --format=json | python -m json.tool

[ceph@servera ~]$ rados -p rbd ls --all --format=json | python -m json.tool
[
{
"name": "services-name",
"namespace": "system"
},
{
"name": "release",
"namespace": "system"
},
{
"name": "release",
"namespace": ""
}
]

Ceph用户管理

本文档叙述了Ceph客户端的用户身份,以及Ceph存储集群的认证和授权。用户可以是个人或是系统角色(像应用程序),它们用Ceph客户端和Ceph服务器守护进程进行交互。

ceph-user-auth-2020-07-26

当Ceph开启用户认证时(默认开启),你必须指定一个用户名和密钥环来证明一个用户认证通过后才可以对Ceph进行相关操作。如果不指明用户名和密钥环,Ceph将会使用client.admin作为用户名,通过查找Ceph keyring设置搜索名称匹配的密钥环。

假如我们执行ceph health命令时没有指明任何用户名和密钥环文件存放地址。那么Ceph会自动的将其解析为如下命令并执行:

ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

另外也可以用CEPH_ARGS环境变量来避免多次输入用户名和密钥。

概述

不论Ceph是从块设备、对象存储、文件系统、还是API中接收数据,最后都会将它们作为对象存储在Pool池中。

Ceph用户必须有权访问池才能读取和写入数据。此外,Ceph用户还应该具有执行权限才能使用Ceph的管理命令。下面的更多概念将会帮助了解Ceph用户管理。

用户

一个用户可以是一个个体,也可以是一个应用程序。通过创建用户,您可以控制哪些人(或什么人)可以访问您的Ceph存储集群以及Pool池中的数据。

Ceph有一个type的用户观念,这是出于用户管理的目的,类型总是client,并且以(.)分割标识不同的用户,以Type.ID这种形式表现。例如client.adminclient.user1

区分用户类型有助于区分客户端和其他用户的访问控制,更方便的进行用户监控和可追溯用户。

有时候Ceph的用户type类型会让你感到很迷惑,因为既可以指定Type来执行Ceph命令,也可以只使用用户名来进行访问。其实这取决于执行Ceph命令行时所使用的选项。当你使用--user或者 --id来指明一个用户时,此时client.user1可以省略为user1。如果使用--name-n来指定用户时,你就必须要加上Type类型了。

推荐使用--name-n提供Type类型和名称的方式进行用户访问。

授权

Ceph用能力(capabilities,caps)这个term术语来描述给某个已认证用户的授权。有一定权限后才可以使用mon、osd和元数据服务器等功能。能力也用于限制对一存储池内的数据、存储池内命名空间、或由应用标签所标识的一系列存储池的访问。

Ceph管理用户可以在创建或更新某一用户时赋予、更新他的能力。

能力的语法符合下面的形式:

{daemon-type} '{cap-spec}[, {cap-spec} ...]'

  • mon 监视器能力:监视器能力包括r 、 w 、 x 访问选项或 profile {name},例如:

    mon 'allow {access-spec} [network {network/prefix}]'
    mon 'profile {name}'

    {access-spec} 语法如下:

    * | all | [r][w][x]

    可选项 {network/prefix} 是个标准网络名和前缀长度( CIDR 表示法,如 10.3.0.0/16 )。如果设置了,此能力就仅限于从这个网络连接过来的客户端。

  • OSD 能力:OSD能力包括 r 、 w 、 x 、 class-read 、 class-write 访问选项和 profile {name} 。此外,OSD能力还支持存储池和命名空间的配置。

    osd 'allow {access-spec} [{match-spec}] [network {network/prefix}]'
    osd 'profile {name} [pool={pool-name} [namespace={namespace-name}]] [network {network/prefix}]'

    其中, {access-spec} 语法是下列之一:

    * | all | [r][w][x] [class-read] [class-write]

    class {class name} [{method name}]

    可选的 {match-spec} 语法是下列之一:

    pool={pool-name} [namespace={namespace-name}] [object_prefix {prefix}]

    [namespace={namespace-name}] tag {application} {key}={value}

    可选的 {network/prefix} 是一个标准网络名、且前缀长度遵循 CIDR 表示法(如 10.3.0.0/16 )。如果配置了,对此能力的使用就仅限于从这个网络连入的客户端。

  • 元数据服务器能力:对于管理员,设置 allow * 。对于其它的所有用户,如 CephFS 客户端,参考 CephFS 客户端用户

存储池

存储池是用户存储数据的逻辑分区。在Ceph部署中,经常创建存储池作为逻辑分区、用以归类相似的数据。例如,用Ceph作为Openstack的后端时,典型的部署通常会创建多个存储池,分别用于存储卷宗、映像、备份和虚拟机。

应用程序标签

可以将访问限定于指定存储池,正如其应用程序元数据所定义的那样。通配符 * 可以用于key参数、value参数或者二者全部。all* 同义。

命名空间

对象Object在Pool池中可以关联到命名空间,他是池中对象的逻辑组。用户对Pool池的访问可以与命名空间想关联,比如限制一个用户在命名空间内的读写权限。

命名空间主要适用于 librados 之上的应用程序,逻辑分组可减少新建存储池的必要。 Ceph 对象网关(从 luminous 起)就把命名空间用于各种元数据对象。

用 namespace 能力可以把访问权限局限于特定的 RADOS 命名空间。命名空间支持有限的通配;如果指定的命名空间最后一个字符是 * ,那就把访问权限授予所有以所提供参数打头的命名空间。

管理用户

用户管理功能赋予Ceph存储集群管理员直接从Ceph存储集群中间、更新和删除用户及能力。

挡在Ceph存储集群中创建或删除用户的时候,可能得把密钥文件分发到各客户端,一边加入他们的密钥环。详见密钥环管理

罗列显示用户

罗列显示集群内的用户,使用ceph auth ls命令。Ceph将罗列出集群内的所有用户。例如,在一个上节点示例集群中,ceph auth ls会显示类似如下的内容:

installed auth entries:

osd.0
key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.1
key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA==
caps: [mon] allow profile osd
caps: [osd] allow *
client.admin
key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw==
caps: [mds] allow
caps: [mon] allow *
caps: [osd] allow *
client.bootstrap-mds
key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww==
caps: [mon] allow profile bootstrap-mds
client.bootstrap-osd
key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw==
caps: [mon] allow profile bootstrap-osd

Type.ID 这种表示方法对于用户来说,如osd.0标示用户类型是osd,其ID是0;client.admin表示用户类型是client,ID是admin(即默认的client.admin)用户。还有,每条都有一行 key: 条目、和一或多行 caps: 条目。

你可以给 ceph auth ls加上-o {filename}选项,把输出保存到一个文件。

获取用户

想要获取一个用户的key和能力,执行下面的命令:

ceph auth get {Type.ID}

ceph auth get client.admin

得到如下结果:

[ceph@serverc ~]$ ceph auth get client.admin
exported keyring for client.admin
[client.admin]
key = AQDtYxJf2UeZHRAAZmPGLhLr3kLzHXh3Glba6g==
caps mds = "allow *"
caps mgr = "allow *"
caps mon = "allow *"
caps osd = "allow *"

如果想要保存输出结果到文本文件中,可以使用-o 选项,和上面的一样。

ceph auth export {Type.ID} 使用export命令等价于get。它会把auid显示到终端上。

新增用户

添加一个用户,让其拥有密钥和应该有的能力。

用户的密钥是用户可以通过Ceph存储集群进行身份认证。可以对用户的能力进行授予,使他们拥有在Ceph监视器mon,Ceph OSD,或者Ceph元数据mds上的读取、写入或执行权限。

有下面几种方式添加用户:

  • ceph auth add:这种添加用户的方式是最规范的方法。它将创建用户,生成密钥并添加任何指定的能力。
  • ceph get-or-create-key:这个命令添加用户后并返回用户密钥环文件信息。这对于需要密钥的客户端非常方便。如果用户已经存在,那么会返回密钥文件格式,并不会重新生成一个新的用户去替换重名用户。使用-o选项将密钥环保存在本地文件。
  • ceph auth get-or-create-key:这种方式创建用户后会输出到控制台密钥,仅仅是密钥而不包括更多的钥匙环格式。
  • 如果需要批量新建用户,可以尝试使用密钥环批量创建用户

当创建了用户之后,可能没有给用户赋予任何的能力。一个用户如果没有任何能力就是一个毫无卵用的用户,因为客户端无法从监视器mon中获得任何集群信息。当然,你可以先创建一个没有能力的用户,之后再使用ceph auth caps命令赋予能力给用户。

标准的用户至少要用用Ceph监视器mon的可读的能力,并且在Ceph osd上具有读写的能力。此外,用户的OSD权限通常会限定至一个特定的Pool池中。

ceph auth add client.yeefire mon 'allow r' osd 'allow rw pool=rbd'
ceph auth get-or-create client.paul mon 'allow r' osd 'allow rw pool=liverpool'
ceph auth get-or-create client.yeefire mon 'allow r' osd 'allow * pool=rbd namespace=system' -o ceph.client.yeefire.keyring
ceph auth get-or-create client.george mon 'allow r' osd 'allow rw pool=liverpool' -o george.keyring
ceph auth get-or-create-key client.ringo mon 'allow r' osd 'allow rw pool=liverpool' -o ringo.key

如果你给用户分配了访问 OSD 的能力,但是没有限制他可以访问哪些存储池,那么他可以访问集群内的所有存储池!最好对用户能力再进行namespace上的限制,以达到最小能力。

更改用户能力

ceph auth caps 命令可以用来修改指定用户的能力。设置新能力时会覆盖当前能力。

ceph auth caps USERTYPE.USERID {daemon} 'allow [r|w|x|*|...] [pool={pool-name}] [namespace={namespace-name}]' [{daemon} 'allow [r|w|x|*|...] [pool={pool-name}] [namespace={namespace-name}]']

ceph auth get client.john
ceph auth caps client.john mon 'allow r' osd 'allow rw pool=liverpool'
ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=liverpool'
ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

删除用户

要删除一用户,使用ceph auth del {Type}.{ID}命令:

ceph auth del client.yeefire

查看用户密钥

要想查看用户的密钥,可以通过以下方式进行获取:

ceph auth print-key client.yeefire
ceph auth get-key client.yeefire
ceph auth get-or-create-key client.yeefire -o key

他们都可以使用-o选项将标准输出内容输出到文件中。

使用auth print-keyauth get-keyauth get-or-create-key返回的结果基本都是一样的。只不过auth get-or-create-key在输出key的时候会在行末尾添加一个换行符。

导入用户

通过ceph auth getceph auth export导出的用户文件可以通过ceph auth import导入的方式恢复用户及他们的能力。

要导入一个或多个用户,可以用 ceph auth import 命令,并指定一个密钥环:

ceph auth import -i /path/to/all.keyring

Ceph 存储集群会新增用户、他们的密钥以及其能力,也会更新已有的用户们、他们的密钥和他们的能力。

管理密钥环

当你访问Ceph使,你的客户端会在一些目录下寻找当前用户的keyring。Ceph默认情况下会使用下面四个路径来搜索与当前用户对应的密钥环。

  • /etc/ceph/$cluster.$name.keyring
  • /etc/ceph/$cluster.keyring
  • /etc/ceph/keyring
  • /etc/ceph/keyring.bin

$cluster是你的集群名称,如client$name是你的用户类型和用户ID,如client.admin。因此合起来的话是/etc/ceph/ceph.client.admin.keyring

用户管理部分详细介绍了如何直接在Ceph存储群集中列出,获取,添加,修改和删除用户。Ceph还提供了ceph-authtool实用程序,使您可以从Ceph客户端管理密钥环。

把用户加入到密钥环

当你在 Ceph 存储集群中创建用户后,你可以用获取用户里面的方法获取此用户、及其密钥、能力,并存入一个密钥环文件。

当你希望每个密钥环中只有一个用户时,使用ceph auth get命令与-o选项搭配,将该用户的钥匙环保存在文件中。

ceph auth get client.yeefire -o ceph.client.admin.keyring

当你想把其他用户的钥匙环导入到一个目标钥匙环里,为了方便import的话,可以使用ceph-authtool工具进行导入:

ceph-authtool ceph.client.yeefire.keyring --import-keyring ceph.client.yeefire.sirius.keyring

通过钥匙环创建用户

Ceph提供了创建用户的功能,可以直接在集群中创建用户。但是如果要是批量新建用户,先在密钥环上创建用户之后再导入到Ceph集群中也是一个不错的选择!

可以将用户导入Ceph存储集群。例如:

ceph-authtool -C ceph.42team.keyring -n client.42team.admin --cap mon 'allow *' --cap osd 'allow *' --cap mgr 'allow *' --gen-key

可以继续创建新的用户,然后导入到ceph.42team.keyring密钥环文件中:

ceph-authtool -n client.42team.sirius --cap mon 'allow r' --cap osd 'allow rw pool=42team' ceph.42team.keyring -g

现在查看ceph.42team.keyring密钥环文件中的内容:

[ceph@serverc ~]$ cat ceph.42team.keyring
[client.42team.admin]
key = AQCmVB1fTffGIBAAoBiwyBPEgggX+UtPzsnFoQ==
caps mgr = "allow *"
caps mon = "allow *"
caps osd = "allow *"
[client.42team.sirius]
key = AQDLVx1fxsuyOBAAvLtLw6vqnAqTLu5uND+LgQ==
caps mon = "allow r"
caps osd = "allow rw pool=42team"

将密钥环文件导入到Ceph中创建用户:

ceph auth import -i ceph.42team.keyring

导入完成后使用ceph auth ls命令进行验证:

[ceph@serverc ~]$ ceph auth ls | grep client.42team -A5
installed auth entries:

client.42team.admin
key: AQCmVB1fTffGIBAAoBiwyBPEgggX+UtPzsnFoQ==
caps: [mgr] allow *
caps: [mon] allow *
caps: [osd] allow *
client.42team.sirius
key: AQDLVx1fxsuyOBAAvLtLw6vqnAqTLu5uND+LgQ==
caps: [mon] allow r
caps: [osd] allow rw pool=42team

成功将2个用户导入到Ceph集群。

接下来将钥匙环放置到/etc/ceph/ceph.keyring

cp ceph.42team.keyring /etc/ceph/ceph.keyring

尝试使用client.42team.admin用户去执行Ceof osd命令:

[ceph@serverc ~]$ ceph osd tree -n client.42team.admin
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.16644 root default
-3 0.05548 host serverc
0 hdd 0.01849 osd.0 up 1.00000 1.00000
3 hdd 0.01849 osd.3 up 1.00000 1.00000
8 hdd 0.01849 osd.8 up 1.00000 1.00000
-7 0.05548 host serverd
2 hdd 0.01849 osd.2 up 1.00000 1.00000
4 hdd 0.01849 osd.4 up 1.00000 1.00000
6 hdd 0.01849 osd.6 up 1.00000 1.00000
-5 0.05548 host servere
1 hdd 0.01849 osd.1 up 1.00000 1.00000
5 hdd 0.01849 osd.5 up 1.00000 1.00000
7 hdd 0.01849 osd.7 up 1.00000 1.00000

修改密钥环中用户能力

要修改密钥环中用户的能力,请指定密钥环,然后再指定用户,修改用户的能力不会重置用户的key

ceph-authtool ceph.42team.keyring -n client.42team.sirius --cap mon 'allow r'

撤销client.42team.sirius用户对osd的所有权限,目前该用户仅可以查看mon信息。

[client.42team.sirius]
key = AQDLVx1fxsuyOBAAvLtLw6vqnAqTLu5uND+LgQ==
caps mon = "allow r"

要将刚刚在密钥环上的修改应用到ceph集群,必须将密钥环的用户更新到Ceph集群中的用户条目。

ceph auth import -i ceph.42team.keyring

成功导入后对修改进行验证:

ceph auth ls | grep ^client.42team -A5

[ceph@serverc ~]$ ceph auth ls | grep ^client.42team -A5
installed auth entries:

client.42team.admin
key: AQCmVB1fTffGIBAAoBiwyBPEgggX+UtPzsnFoQ==
caps: [mgr] allow *
caps: [mon] allow *
caps: [osd] allow *
client.42team.sirius
key: AQDLVx1fxsuyOBAAvLtLw6vqnAqTLu5uND+LgQ==
caps: [mon] allow r

对导入用户不了解可以参见导入用户

不想使用ceph-authtool工具或者不想以密钥环方式添加用户可以参见更改用户能力新增用户

身份验证命令行

Ceph命令行几乎全局支持用户名和密钥的下列用法:

  • --id | --user:Ceph 用一个类型和 ID( 如 TYPE.ID 或 client.admin 、 client.user1 )来标识用户, id 、 name 、和 -n 选项可用于指定用户名(如 admin 、 user1 、 foo 等)的 ID 部分,你可以用 –id 指定用户并忽略类型,例如可用下列命令指定 client.foo 用户:
    ceph --id foo --keyring /path/to/keyring health
    ceph --user foo --keyring /path/to/keyring health
  • --name | -n:Ceph 用一个类型和 ID (如 TYPE.ID 或 client.admin 、 client.user1 )来标识用户, –name 和 -n 选项可用于指定完整的用户名,但必须指定用户类型(一般是 client )和用户 ID ,例如:
    ceph --name client.foo --keyring /path/to/keyring health
    ceph -n client.foo --keyring /path/to/keyring health
  • --keyring:包含一或多个用户名、密钥的密钥环路径。 --secret 选项提供了相同功能,但它不能用于 RADOS 网关,其 --secret 另有用途。你可以用 ceph auth get-or-create 获取密钥环并保存在本地,然后您就可以改用其他用户而无需重指定密钥环路径了。
    ceph --id 42team.admin --keyring /etc/ceph/ceph.keyring health

Ceph认证的局限性

cephx协议提供Ceph客户端和服务器间的相互认证,并没打算认证人类用户或者应用程序。如果有访问控制需求,那必须用另外一种机制,他对于前端用户访问Ceph对象存储可能是特定的,其任务是确保只有此机器上可接受的用户和程序才能访问Ceph的对象存储。

用于认证Ceph客户端和服务器的密钥通常以纯文本存储在权限合适的文件里,并保存于可信主机上。

密钥存储为纯文本文件有安全缺陷,但很难避免,它给了 Ceph 可用的基本认证方法,设置 Ceph 时应该注意这些缺陷。

尤其是任意用户、特别是移动机器不应该和 Ceph 直接交互,因为这种用法要求把明文认证密钥存储在不安全的机器上,这些机器的丢失、或盗用将泄露可访问 Ceph 集群的密钥。

相比于允许潜在的欠安全机器直接访问 Ceph 对象存储,应该要求用户先登录安全有保障的可信机器,这台可信机器会给人们存储明文密钥。未来的 Ceph 版本也许会更彻底地解决这些特殊认证问题。

当前,没有任何 Ceph 认证协议保证传送中消息的私密性。所以,即使物理线路窃听者不能创建用户或修改它们,但可以听到、并理解客户端和服务器间发送过的所有数据。此外, Ceph 没有可加密用户数据的选项,当然,用户可以手动加密、然后把它们存在对象库里,但 Ceph 没有自己加密对象的功能。在 Ceph 里存储敏感数据的用户应该考虑存入 Ceph 集群前先加密。

让你的Mac睡的更香

最近Mac的睡眠让我感到不太舒服,明明已经合上盖子拔掉电源,可是它还在熬着夜!不好好睡觉真让人生气!

所以得好好调教一下,让他该睡觉的时候老老实实趴下,该干活的时候就得全力以赴工作。

Mac是怎么睡觉的

Mac有两种睡觉有两个阶段,一开始是睡眠,在一定条件之后会从睡眠进入休眠。这两种睡觉方式就像我们人的小憩和睡大觉。小憩醒得快,睡大觉醒的就会慢一些。

在长时间无操作,或者把Macbook的盖子合上时以及手动点击进入睡眠时则进入睡眠状态,在睡眠状态下数据存储在内存中,此时的系统可以被快速唤醒,快速恢复到睡眠前的状态。

如果睡眠持续了一段时间之后,Mac会根据设定进入更深一层的休眠状态,此时Mac要根据你的配置来决定要不要把内存中的数据写入到磁盘中,然后会放弃对内存及设备的大部分供电,达到更加节省电量的目的。如果在休眠模式下唤醒,则Mac会将保存在硬盘中的数据再重新写入到内存之中并恢复程序运行,这样的话耗时比较长,速度比较慢。

pmset工具

Apple 提供了一个工具叫pmset来管理Apple 设备的电源选项。pmset这个工具的名字来源于 Power Manager Setting(pmset) ,通过调整macos的睡眠计划,可以让Mac睡的更香。

pmset用法

sudo pmset [-选项] <参数>

实例:

  • pmset -g cap: 查看当前供电方式下可以调节的参数
  • pmset -g custom : 查看全部供电方式下的电源参数信息
  • pmset restoredefaults : 还原自定义的设置

pmset常用选项

  • pmset -a : 全局调整睡眠电源计划
  • pmset -c : 仅调整外部供电时睡眠计划
  • pmset -b : 仅调整电池供电时睡眠计划
  • pmset -g : 查看当前供电方式下的睡眠计划

常用参数

  • sleep: 睡眠计时器,进入睡眠所需要的时间
  • hibernatemode: 睡眠模式
    • hibernatemode = 0 将数据保存在内存中持续为内存供电 非笔记本机器默认配置
    • hibernatemode = 3 safe sleep模式,数据保存在内存中并写入内存镜像到硬盘中备份。笔记本默认模式
    • hibernatemode = 25 将内存镜像直接写入到硬盘中
  • standby: 休眠计时器
  • highstandbythreshold: highstandbythreshold(电池剩余电量百分比)它是standbydelay模式选择阈值,默认 50% 电量。
    • 高于阈值,采用standbydelayhigh计算时间。
    • 低于阈值,采用standbydelaylow计算时间。
  • gpuswitch: 这个参数用来管理独立显卡的选择
    • gpuswitch=0 只使用集成显卡
    • gpuswitch=1 只使用独立显卡
    • gpuswitch=2 自动切换显卡

其他参数

  • lidwake:开盖时是否唤醒
  • tcpkeepalive:合盖时是否保存网络连接
  • displaysleep:屏幕休眠时间
  • disksleep:硬盘休眠时间
  • acwake:被同一 iCloud ID 下的设备唤醒

我的个人参数

外部供电环境下:

外部供电睡眠设置使用的是默认参数。

外部电源供电-2020-07-15

电池供电:

电池供电-2020-07-15

// 20分钟后睡眠
sudo pmset -b sleep 20

// 休眠模式使用3,在给内存供电的同时写入内存的镜像备份到磁盘中
sudo pmset -b hibernatemode 3

// 显示器15分钟后关闭
sudo pmset -b displaysleep 15

// 硬盘30分钟后休眠
sudo pmset -b disksleep 30

// 休眠后断网
sudo pmset -b tcpkeepalive 0

// 开盖唤醒
sudo pmset -b lidwake 1

// 关闭被同一 iCloud 下的设备唤醒
sudo pmset -b acwake 0

// gpuswitch 0 在使用电池的情况下只使用核心显卡
sudo pmset -b gpuswitch 0

// 在电池剩余电量高于75%的情况时,休眠计时器设定为2小时。低于75%的情况下1小时后进入休眠。
sudo pmset -b highstandbythreshold 75
sudo pmset -b standbydelayhigh 7200
sudo pmset -b standbydelaylow 3600

参考文章:

https://sspai.com/post/61379

Ansible 学习文档

Ansible自动化运维学习。大部分操作及示例基于RHEL8实现。

文档未进行过任何校对和查错,目前仅用于个人学习使用。文档中可能会包含错误,请您雅正,谢谢。

最近一次的更新日期:2020年6月27日

本次更新内容:继续完成《Ansible 常用模块》 ⭕️

近期持续更新Ansible常用模块。

文档列表

更新日志

2020年6月27日

  • 继续完成《Ansible 常用模块》 ⭕️

2020年6月22日

  • 完成《Ansible 技巧之场》✅

2020年6月18日

  • 修复《Ansible 任务控制》中部分Markdown解析错误

2020年6月16日

  • Ansible角色 ✅
  • 添加部分刚刚没有同步到文档中的内容
  • 添加软件包管理模块使用

Splunk 数据搜索和报表

Splunk 是?

Splunk是机器数据分析平台,他可以收集并处理所有有机器产生的日志数据,在Splunk中可以做到”any data from any source”。我们作为管理员可以使用Splunk生成这些数据的报表、仪表盘等,赋予这冰冷枯燥日志数据的新生。

搜索是Splunk核心功能之一,基本上近乎所有的功能都是由搜索展开的。充分挖掘这些数据并从中获得有价值的信息,这让我想起在泥沙中淘金的感觉。从基本的报表和仪表,再到数据模型和功能完备的Splunk应用程序,这些都是由Splunk搜索在后台提供着支撑。

Splunk使用自己的搜索语言(SPL)。SPL有很多搜索指令,其中大部分包含有多种函数,参数和字句。

阅读全文 »

42Team Flask框架

前排提示

《42Team-Flask框架》系列教程仅限大连东软信息学院网络中心所属的42Team社团内部使用,该系列文档属于内部资料,仅用于所有42Team社团成员学习使用。

最近一次的更新日期:2020年4月24日

本次更新内容:请求与响应

阅读全文 »

How to install RHEL8(Centos) on Dell R710/R610 server

When I install RHEL8.x I cound’t discover my RAID Controller’s devices on Install Storage set-up optional.When I try to google find the resolutions I know a large number of storage controller device’s drivers has been removed from RHEL8,which means the Dell R710/R610 installed H700 RAID controller card won’t be supported RHEL 8.X natively.

Nevertheless you can still install RHEL8 on these machines with use of driver update disk(DUD).

Setup DUD

Using this link below ,you are specifically looking for the megaraid_sas drivers.

dmesg | grep raid
[ 3.702959] megaraid_sas: loading out-of-tree module taints kernel.
[ 3.703082] megaraid_sas: module verification failed: signature and/or required key missing - tainting kernel
[ 3.705684] megaraid_sas 0000:03:00.0: FW now in Ready state
[ 3.705687] megaraid_sas 0000:03:00.0: 63 bit DMA mask and 32 bit consistent mask
[ 3.705915] megaraid_sas 0000:03:00.0: firmware supports msix : (0)
[ 3.705918] megaraid_sas 0000:03:00.0: current msix/online cpus : (1/16)
[ 3.705919] megaraid_sas 0000:03:00.0: RDPQ mode : (disabled)
[ 3.750024] megaraid_sas 0000:03:00.0: controller type : MR(512MB)
[ 3.750027] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR) : Enabled
[ 3.750029] megaraid_sas 0000:03:00.0: Secure JBOD support : No
[ 3.750030] megaraid_sas 0000:03:00.0: NVMe passthru support : No
[ 3.750032] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeout : 0 secs/0 secs
[ 3.750036] megaraid_sas 0000:03:00.0: megasas_init_mfi: fw_support_ieee=67108864
[ 3.750069] megaraid_sas 0000:03:00.0: INIT adapter done
[ 3.750071] megaraid_sas 0000:03:00.0: Jbod map is not supported megasas_setup_jbod_map 5389
[ 3.795034] megaraid_sas 0000:03:00.0: pci id : (0x1000)/(0x0079)/(0x1028)/(0x1f17)
[ 3.795039] megaraid_sas 0000:03:00.0: unevenspan support : no
[ 3.795041] megaraid_sas 0000:03:00.0: firmware crash dump : no
[ 3.795042] megaraid_sas 0000:03:00.0: jbod sync map : no

If you specific DUD drivers that you need for RHEL8 is below address to download.

https://elrepo.org/linux/dud/el8/x86_64/dd-megaraid_sas-07.707.51.00-1.el8_1.elrepo.iso

When you downloaded the DUD ISO driver.Using the dd to burn it in another USB or DVD media devices.

dd if=dd-megaraid_sas-07.707.51.00-1.el8_1.elrepo.iso of=/dev/sdc

Installation System

The install process is as follows:

  • Download RHEL8.x media file and burn to usb or dev devices media.
  • Download DUD drivers in iso format and burn to usb drive.
  • Boot with both RHEL8 and DUD mounted before booting Install RHEL.
  • Installer should detect the DUD iso and install the proper drivers.

During booting RHEL8 Installer and When you see a countdown on the screen.At this time interrupt the installer with the TAB key and append the following to your boot options last.

inst.dd=/dev/sdb

On my system, the DUD was /dev/sdb and the RHEL8 install media was /dev/sda.

Soon after you can view the RAID Devices find it out.

Install it usually.