Linux集群常用指令

姓名：张昊楠   学号：21021210691

存储NAS 文件 *** 作

df -h查看空间使用情况

警惕超大 nohup.out

ls   当前路径下的文件列表

pwd  查看当前路径

cd    进入某个文件夹

任务提交

任务提交前

qhost--查看集群负载状态

qsub / qsub-sge.pl--提交任务

qstat--查看任务状态

qdel / qmod--任务控制

任务查看

qhost -j---列出所有用户在每个节点上的任务

qhost -q---列出每个节点上每个队列的任务数

qhost -u username---列出某个用户在每个节点上的任务

提交命令

qsub -cwd -q queue.q test.sh

qsub-sge.pl --maxproc 50 --resource vf=5G --queue queue.q test.sh

任务查看2

qstat -u username---查看某个用户的任务

qstat -u *,---查看所有用户的任务

qstat –j jobs_ID---查看某个任务的详细信息

查看.e和.o文件

.e：错误信息

.o：标准输出

任务控制

qdel jobID---删除某个任务

qdel -u username---删除某个用户的所有任务

qmod -s jobID--挂起某个任务

qmod -us jobID---继续运行某个挂起的任务

按任务占用内存大小选择相应的队列

查看队列 qstat -g c

QUEUE

PE.q--并行

cloud.q--云平台

general.q--96G节点

middle.q--96G节点

great.q--大内存节点

plus.q--大内存节点

single.q--Trinity组装

single._p.q---Trinity组装（占用内存较大）

本文介绍在Linux HA集群中的仲裁和分区概念。

集群正常工作时，所有节点都在一个分区内（partition），分区内的所有节点将选举出一个仲裁节点，这个仲裁节点负责向其他节点发送集群控制命令。当网络发生故障时，集群中的节点发现无法和仲裁节点通信，则会在可通信的范围内重新选举一个新的仲裁节点。此时集群内可能出现多个仲裁节点，每个仲裁节点的管理范围为一个分区。

下文中将通过防火墙策略的设置模拟集群网络中通信出现异常的各种情况，如：

通过防火墙策略可以精准控制两两节点之间的连通性，使我们能更准确的了解在网络连通性发生变化对集群的影响。

在所有节点上启动防火墙，并添加策略对整个管理网络192.168.56.0/24放通。

保存上述策略，之后在实验过程会使用iptables命名加入新策略模拟网络通信异常效果，如果需要恢复网络通信正常状态，直接不保存策略重启firewalld服务即可。

通过pcs status查看集群状态：

上述结果显示当前集群只有一个分区，分区内的节点包括全部3台主机，仲裁节点是ha-host3，这表示集群间的通信是完好的。下图显示当前集群状态：

在ha-host1上添加以下策略：

该策略将使得ha-host1和ha-host3之间的通信中断，在所有节点上查看集群状态：

上面的结果显示，ha-host1失去和当前仲裁节点ha-host3的联系之后，和ha-host2一起组成新的分区并选举出ha-host2作为新的仲裁节点。有趣的是ha-host2和ha-host3的通信并未中断，但是他被“优先级较高的ha-host1抢走并推举为老大”，剩下ha-host3独自留在其自身所在的分区。此时ha-host3所在的分区提示了“partition WITHOUT quorum”，表示该分区中的节点数目不超过一半。

下图显示当前集群状态：

在ha-host1上再添加策略：

使其和当前的仲裁节点ha-host2的通信中断，集群状态变为：

发现ha-host2和ha-host3一起组成了新的分区，由于ha-host1所在分区节点数不足一半，无法启动资源，虚拟ip资源vip被切换到了ha-host2上。下图显示当前集群状态：

如果再把ha-host2和ha-host3直接的通信中断，此时3个节点间两两均无法通信。每个节点都是一个分区，每个分区的主机数均不过半，因此无法启动任何资源，原先运行在ha-host2上的vip也停止了。

当前集群状态如下图：

1、如果是用apt-get或者yum install安装的redis，可以直接通过下面的命令停止/启动/重启redis：/etc/init.d/redis-server stop/etc/init.d/redis-server start/etc/init.d/redis-server restart

2、如果是通过源码安装的redis，则可以通过redis的客户端程序redis-cli的shutdown命令来重启redis。

redis集群如何解决重启不了的问题

redis使用集群部署，如果遇到断电或者服务器重启，当再次启动的时候，有时候会启动不了。需要使用trib的fix命令进行修复。如果修复还是不行的话，可以清除节点数据再重新建集群，前提要备份之后 *** 作。

1、使用redis-cli连接上redis其中一台：redis-cli -c -h xxx -p 7001，输入cluster info查看当前集群的状态。

2、可以使用trib的check检测的集群状态：redis-trib.rb check xxx:7001，[ERR] Not all 16384 slots are covered by nodes。

3、如果出现以上的错误，可以尝试使用fix命令修复：redis-trib.rb fix xxx:7001。修复完成之后，在使用trib的check命令查看状态。

4、如果通过fix方式修复不了，pkill redis停止之前的redis进程，然后把aof，rdb，nodes节点文件删除，删除之前需要备份。

5、然后启动各个redis节点。

6、创建redis集群：redis-trib.rb create --replicas 1 xxx:7000 xxx:7001 xxx:7002 xxx:7003 xxx:7004 xxx:7005。

7、集群创建完成之后，再次连接redis查看集群状态，redis服务已经启动完成。

---