第十五课时预习笔记_scst pr命令-CSDN博客

本文链接：https://blog.csdn.net/g66kai/article/details/82117605

iptables规则备份和恢复

iptables-save可以将规则重定向保存到指定的文件中：

iptables-restore则是相反，把文件里的规则恢复到iptables中：

其实这两个命令就是把规则备份到指定的文件里，当需要用到备份文件里的规则时，就可以使用iptables-restore恢复回去。

例如我现在备份nat表的规则到指定的文件里，然后把nat表的规则清空，如果我想恢复的话只需要从指定的文件里恢复即可：

firewalld的9个zone

firewalld是CentOS7的防火墙机制，之前我们学习iptables时，把firewalld防火墙禁掉了，所以现在我们要反着操作一下，开启firewalld关闭iptables：

现在使用iptables -nvL查看iptables 的规则会发现多了很多规则：

这是firewalld自带的规则。

firewalld默认有9个zone，zone是firewalld的一个单位，默认的是public zone，每个zone都是一个规则集，规则集就是zone里面自带的一些规则的一个集合体，使用firewall-cmd --get-zones命令可以查看所有的zone：

firewall-cmd --get-default-zone命令可以查看默认的zone：

这些不同的zone的区别与含义：

firewalld关于zone的操作

设定默认的zone：

查看指定网卡：

如果你新添加的网卡显示的是no zone的话，你就需要进入到/etc/sysconfig/network-scripts/目录下，把正常的网卡配置文件复制一份为你新网卡名称命名的文件，然后修改一下配置文件为你新网卡的信息，然后重启一下网络服务：

如果配置了配置文件之后还是显示no zone的话，就给这个网卡设置zone，语法：

firewall-cmd --zone=zone的名称 --add-interface=网卡名称

例如：

针对网卡更改zone：

针对网卡删除zone：

查看系统所有网卡所在的zone：

firewalld关于service的操作

所谓service就是zone下面的一个子单元，可以理解为一个指定的端口，因为防火墙无外乎就是对某个端口进行限制，例如http连接的是80端口、https连接的是43端口、ssh连接的22端等等。

查看所有的service：

查看当前的zone里都有哪些service：

查看指定的zone下面有哪些service：

把http增加到public的zone下面：

现在仅仅是在内存里把zone增加了service，重启之后就会失效，想要永久有效，就要保存到配置文件里：

这个文件会保存在/etc/firewalld/zones/目录下：

除了zones还有service，service默认是没有文件的，只有更改了service的配置文件之后，才会放在/etc/firewalld/services/目录下：

/usr/lib/firewalld/zones/目录下存放的是zone配置文件的模板：

/usr/lib/firewalld/services/目录下存放的是services配置文件的模板：

现在我有一个需求，把ftp的默认端口改一下，改为1121端口，并且在work zone下放行ftp。

第一步，把ftp的配置文件拷贝到/etc/firewalld/services/目录下：

第二步，编辑/etc/firewalld/services/目录下的ftp.xml文件：

第三步，把/usr/lib/firewalld/zones/目录下的work.xml文件放到/etc/firewalld/zones/目录下：

第四步，编辑/etc/firewalld/zones/目录下的work.xml文件：

配置文件修改完成后，重新加载一下：

指定zone为work：

这个需求就完成了。

总结：

firewalled服务有两个角色，一个是zone一个是service，zone是firewalled的一个规则集合，每个zone里都会有对应的iptables规则。每个zone下面都有一些service，这些service就像是这个zone的白名单，放行这些service。如果遇到需求，需要放行某个服务，就可以把这个服务增加到配置文件里去，再重新reload就可以了，操作方式和上面的那个例子一样。

linux任务计划cron

实现linux定时任务有：cron、anacron、at,使用最多的是cron任务

名词解释

　　cron--服务名；crond--linux下用来周期性的执行某种任务或等待处理某些事件的一个守护进程，与windows下的计划任务类似；crontab--是定制好的计划任务表

软件包安装

　　要使用cron服务，先要安装vixie-cron软件包和crontabs软件包，两个软件包作用如下：

　　vixie-cron软件包是cron的主程序。crontabs软件包是用来安装、卸装、或列举用来驱动 cron 守护进程的表格的程序。

　　查看是否安装了cron软件包: rpm -qa|grep vixie-cron

　　查看是否安装了crontabs软件包:rpm -qa|grep crontabs

　　如果没有安装，则执行如下命令安装软件包(软件包必须存在)
　　rpm -ivh vixie-cron-4.1-54.FC5*
　　rpm -ivh crontabs*

　　如果本地没有安装包，在能够连网的情况下可以在线安装

　　yum install vixie-cron
　　yum install crontabs

查看crond服务是否运行

　　pgrep crond 或 /sbin/service crond status 或 ps -elf|grep crond|grep -v "grep"

crond服务操作命令

　　/sbin/service crond start //启动服务
　　/sbin/service crond stop //关闭服务
　　/sbin/service crond restart //重启服务
　　/sbin/service crond reload //重新载入配置

配置定时任务

　　cron有两个配置文件，一个是一个全局配置文件（/etc/crontab），是针对系统任务的；一组是crontab命令生成的配置文件（/var/spool/cron下的文件），是针对某个用户的.定时任务配置到任意一个中都可以。

　　查看全局配置文件配置情况: cat /etc/crontab

　　---------------------------------------------
　　SHELL=/bin/bash
　　PATH=/sbin:/bin:/usr/sbin:/usr/bin
　　MAILTO=root
　　HOME=/

　　# run-parts
　　01 * * * * root run-parts /etc/cron.hourly
　　02 4 * * * root run-parts /etc/cron.daily
　　22 4 * * 0 root run-parts /etc/cron.weekly
　　42 4 1 * * root run-parts /etc/cron.monthly
　　----------------------------------------------

　　查看用户下的定时任务:crontab -l或cat /var/spool/cron/用户名

chkconfig 工具

在 Centos 6 以及之前的版本是使用 chkconfig 工具来管理系统的服务，使用 top 命令可以看到进程号为 1 的进程是 init，即 Sys V 。但在 Centos 7 里面已经默认不使用了，Centos 7 中 top 命令可以看到进程号为 1 的已经替换成了 systemd ，但为了和之前的版本兼容，作为过渡，Centos 7 中还可以使用。

语法：

chkconfig （选项）

选项：

–add：增加所指定的系统服务，让chkconfig指令得以管理它，并同时在系统启动的叙述文件内增加相关数据；
–del：删除所指定的系统服务，不再由chkconfig指令管理，并同时在系统启动的叙述文件内删除相关数据；
–level<等级代号>：指定读系统服务要在哪一个执行等级中开启或关毕。

等级代号列表：

等级0表示：表示关机
等级1表示：单用户模式
等级2表示：无网络连接的多用户命令行模式
等级3表示：有网络连接的多用户命令行模式
等级4表示：不可用
等级5表示：带图形界面的多用户模式
等级6表示：重新启动

[root@localhost ~]# chkconfig --list

注：该输出结果只显示 SysV 服务，并不包含
原生 systemd 服务。SysV 配置数据
可能被原生 systemd 配置覆盖。 

      要列出 systemd 服务，请执行 'systemctl list-unit-files'。
      查看在具体 target 启用的服务请执行
      'systemctl list-dependencies [target]'。

netconsole      0:关    1:关    2:关    3:关    4:关    5:关    6:关
network         0:关    1:关    2:开    3:开    4:开    5:开    6:关
[root@localhost ~]# chkconfig --level 345 network off
[root@localhost ~]# chkconfig --list

注：该输出结果只显示 SysV 服务，并不包含
原生 systemd 服务。SysV 配置数据
可能被原生 systemd 配置覆盖。 

      要列出 systemd 服务，请执行 'systemctl list-unit-files'。
      查看在具体 target 启用的服务请执行
      'systemctl list-dependencies [target]'。

netconsole      0:关    1:关    2:关    3:关    4:关    5:关    6:关
network         0:关    1:关    2:开    3:关    4:关    5:关    6:关

新增一个服务：

服务脚本必须放在 /etc/init.d/ 目录下；
使用命令 chkconfig --add service_name 在 chkconfig 工具列表中添加此服务;
使用命令 chmod 755 service_name 赋予执行权限；
使用命令chkconfig --level 35 service_name on 更改启动级别。

在启动脚本中：

#!/bin/bash
#chkconfig: 2345 80 90
#description:auto_run

第一行，告诉系统使用的shell,所有的shell脚本都是这样。
第二行，chkconfig后面有三个参数2345,80和90告诉chkconfig程序，需要在rc2.d~rc5.d目录下，创建名字为 S80auto_run的文件连接，连接到/etc/rc.d/init.d目录下的的auto_run脚本。第一个字符是S，系统在启动的时候，运行脚本auto_run，就会添加一个start参数，告诉脚本，现在是启动模式。同时在rc0.d和rc6.d目录下，创建名字为K90auto_run的文件连接，第一个字符为K，系统在关闭系统的时候，会运行auto_run，添加一个stop，告诉脚本，现在是关闭模式。
注意上面的三行中，第二，第三行是必须的，否则在运行chkconfig –add auto_run时，会报错。
80 数字越小启动优先级别越高
90 数字越小关闭优先级别越高

使用Systemd来管理服务

Systemd是linux下的一款系统服务管理器。Systemd的特征有：支持并行化任务；同时采用socket式与D-Bus总线式激活服务；按需启动守护进程（daemon）；利用Linux的cgroups监视进程；支持快照和系统恢复；维护挂载点和自动挂载点；各服务间基于依赖关系进行精密控制。

其中的监视和控制功能的主要命令就是systemctl。

Systemd有很多不同类型的使用单元，主要包括：系统服务（.service）、挂载点（.mount）、sockets（.sockets）、系统设备（.device）、交换分区（.swap）、文件路径（.path）、启动目标（.target）。当然一般我们常用的就是其中的系统服务。

单元文件目录按优先级从高到低分别为：

/etc/system/system/

/usr/lib/systemd/system/

对于系统服务而言，比较重要的就是其中的.service文件。

例如：testencd.service

[Unit]

Description=java test

[Service]

Type=forking

ExecStart=/opt/java/bin/java -jar /home/apps/test1-encrypt-master-SNAPSHOT-exec.jar > /home/apps/testenc.log &

Restart=always

RestartSec=1

[Install]

WantedBy=multi-user.target

.service文件由三个部分组成：Unit\Service\Install

[Unit]主要是为了解决依赖关系。常见的添加Requires、After，如果这个依赖是可选的，那么是Wants、After。依赖关系通常被用在服务（service）而不是（target）上，所以上述的httpd所依赖的仅仅是一些target，因而也就没有Requires和Wants出现。

[service]可选择几种不同的服务启动方式，启动方式通过Type参数进行设置。

Type=simple（默认值）：systemd认为该服务将立即启动。服务进程不会fork。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket激活型。

Type=forking：systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定 PIDFile=，以便systemd能够跟踪服务的主进程。

Type=oneshot：这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。

Type=notify：与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式启动，当指定的 BusName 出现在DBus系统总线上时，systemd认为服务就绪。

新增服务：在单元文件目录创建.service文件，需systemctl daemon-reload重新加载，然后可以使用systemctl start testenc，有守护进程功能，异常退出后会自动唤起。可直接使用stop,restart等

修改服务：在单元文件目录修改.service文件，需systemctl daemon-reload重新加载

可以使用journalctl来进行systemd相关启动日志的查看。

journalctl -b -0 # 显示本次启动的信息

journalctl -b -1 # 显示上次启动的信息

target介绍

1. STGT

在2.6.38之后，STGT默认只剩下用户态的实现，这对于iSCSI target来说，用户态即可满足要求。如果需要iSER等，需要自己将kernel的部分打上。另外从以上功能图表上可以看出，STGT主要专注于iSCSI上。

它的优点是：
1）简单，方便使用和维护；
2）另外已经有ceph的target driver，只是需要做性能优化；
3）因为工作在用户态，所以即使挂掉了，也不会对其他运行的程序产生影响；

它的缺点是：
1）支持的传输协议较少；
2）对SCSI协议支持比较简单，一些cluster中的特性比如PR等都不支持，所以基于stgt的方案不能在cluster中使用；
3）对于多initiator访问同一target的场景，性能表现不好，这个主要是因为tgt的实现所致，即它目前的策略是针对一个lun创建16个线程处理IO。不过可以通过one lun per target的方案解决；

2. SCST

SCST的核心模块工作在内核里，可以支持通过系统模块（VFS、块层）访问的后端存储如块设备、文件设备以及passthrough的scsi设备。对于通过library库访问的ceph rbd以及glusterfs等后端存储，SCST也提供了一个模块scst_user，不过你得自己写插件。

它的优点是：
1）支持更多传输协议
2）针对性能做了特殊的优化
3）除了基本的SCSI协议支持外，还有一些高级支持：
SCST支持永久性预留（Persistent Reservation, PR）；这是一个用于高可用集群中的存储设备的 I/O 隔离与存储设备故障切换、接管的特性。通过使用 PR 命令，initiator 可以在一个 target 上建立、抢占、查询、重置预留策略。在故障接管过程中，新的虚拟资源可以重置老的虚拟资源的预留策略，从而让故障切换更快、更容易地进行。
SCST 可以使用异步事件通知（AEN）来通告会话状态的变更。AEN 是一个 SCSI target 用来向 initiator 进行 target 端的事件告知的协议特性，即使在没有服务请求的时候也可以进行。于是 initiator 就可以在 target 端发生事件时，如设备插入、移除、调整尺寸或更换介质时，可以得到通知。这让 initiator 可以以即插即用的方式看到 target 的变化。
4）SCST 的开发者声称，它们的设计在健壮性和安全性方面更加符合 SCSI 标准。SCSI 协议要求，如果一个 initiator 要清除另一个 initiator 的预留资源时，预留者必须要得到清除通知，否则，多个 initiator 都可能来改变预留数据，就可能会破坏数据。SCST 可以实现安全的预留、释放操作，避免类似事情发生。
5）SCST 也支持非对称逻辑卷分配（ALUA）。ALUA 允许 target 管理员来管理 target 的访问状态和路径属性。这让多路径路由机制可以选择最好的路径，从而根据 target 的访问状态，优化带宽的使用。换句话说，在多路径环境下，target 管理员可以通过改变访问状态来调整 initiator 的路径。
6）各大存储服务提供商都是基于SCST。
7）提供更细粒度的访问控制策略以及QoS保证机制（限制initiator连接的个数）。

它的缺点是：
1）结构复杂，二次开发成本较高。
2）工作在kernel，如果挂了，会导致整个机器down掉，影响其他程序。
3）kernel部分没有并入linux，需要手工编译。

关于scst_user，这里多说一点它的工作原理。它在内核创建一个字符设备作为用户态存储和SCST内核模块之间的接口，通过IOCTL，用户态存储可以向SCST注册一个块设备以及进行IO。当然就我了解到的情况是，你要扩展scst_user对你的存储的支持，你只能自己搞，目前没有任何案例可以参考，只有一个接口spec文档：
http://scst.sourceforge.net/scst_user_spec.txt

3. LIO

LIO的核心模块也工作在内核，和SCST一样即支持通过内核模块访问的后端存储，也支持通过library访问的分布式存储，对应的模块是TCMU。这个模块已经在3.17并入linux内核里了，可以参考它的设计文档：
https://www.kernel.org/doc/Documentation/target/tcmu-design.txt

优点：
1）支持较多传输协议
2）代码并入linux内核，减少了手动编译内核的麻烦。
3）提供了python版本的编程接口rtslib。
4）LIO在不断backport SCST的功能到linux内核，社区的力量是强大的。
5）LIO也支持一些SCST没有的功能。

LIO 还支持“会话多连接”（MC/S）。MC/S 让 initiator 可以和 target 在一条或多条物理路径上建立多条连接。这样，在一条路径发生错误的时候，已经建立好的会话可以不中断会话，直接使用其他的路径。MC/S 还可以用来进行所有连接之间的负载均衡。这种情况下，会在所有通信路径上保持会话命令的顺序性。
不过我觉得MCS是一个比较鸡肋的feature，因为现在Linux内核已经有Device Mapper的支持。
6）LIO支持最高级别的ERL。iSCSI 连接的错误可能会发生在三个层面上：会话、校验或是连接层。错误恢复工作也可以在这三个层面开始进行，这样就可以在当前的层面开始进行恢复，不会让错误到达下一个层面。错误恢复首先是检查断开的连接。在这种情况下，iSCSI initiator 驱动会主动建立新的到 target 的 TCP 连接它会告诉 target，SCSI 指令路径已经变到新的连接上了。这样 target 就可以在新的连接上处理 SCSI 命令了。这时，上层的 SCSI 驱动对新的连接已经建立、控制信息已经通过新连接传输的事还是毫无知觉的。iSCSI 会话在这期间会保持正常，不会重新变换状态。LIO 支持的最大错误恢复级别（ERL）为2，这就是说，它可以在会话、校验或连接层进行错误恢复。而SCST 支持的 ERL 为 0，也就是说，它智能恢复会话级别的错误，所有连接层面的错误都会转到 SCSI 驱动层面来处理。

缺点：
1）不支持AEN，所以target状态发生变化时，只能通过IO或者用户手动触发以检测处理变化。
2）结构相对复杂，二次开发成本较高。
3）工作在内核态，出现问题会影响其他程序的运行。

4. 总结

总的来说，如果你的需求只是构建一个iSCSI target，并且规模不是很大，stgt是一个不错的选择。
如果你要构建一个企业级的存储方案，即高性能、高稳定性的，并且围绕这个有长远计划的，本人觉得SCST是正确的选择。
如果你对性能、稳定性要求不是那么高，但又想支持FC、SRP等协议，你可以选择LIO。