HP 集群软件 - 不能接收节点的设备查询信息:软件引起的连接失败

问题

# cmcheckconf -v -C /etc/cmcluster/cmclconfig.ascii 
Begin cluster verification...  
Checking cluster file: /etc/cmcluster/cmclconfig.ascii  
Defaulting MAX_CONFIGURED_PACKAGES to 300.  
Checking nodes ... Done  
Checking existing configuration ... Done  
Defaulting MAX_CONFIGURED_PACKAGES to 300.  
Gathering storage information  
Unable to receive device query message from mucs3173: Software caused connection abort                                <--- 问题 
Found 148 devices on node mucs3088  
Found 148 devices on node mucs3090  
Found 150 devices on node mucs3091  
Found 0 devices on node mucs3173     <----------  这里 
Found 148 devices on node mucs3179  
Analysis of 594 devices should take approximately 16 seconds  
0%----10%----20%----30%----40%----50%----60%----70%----80%----90%----100%  
Found 59 volume groups on node mucs3088  
Found 59 volume groups on node mucs3090  
Found 59 volume groups on node mucs3091  
Found 0 volume groups on node mucs3173  
Found 59 volume groups on node mucs3179  
Analysis of 236 volume groups should take approximately 1 seconds  
0%----10%----20%----30%----40%----50%----60%----70%----80%----90%----100%  
Gathering network information  
Beginning network probing (this may take a while)  
Completed network probing  
Gathering polling target information  
cmcheckconf: Unable to reconcile configuration file /etc/cmcluster/cmclconfig.ascii

不管是在哪个节点运行 cmcheckconf ,结果都一样.

配置 :

HPUX 11.31.

Serviceguard:A.11.19和修补软件PHSS_40152(在受影响的节点上安装了PHSS_41162,但是没有帮助).

top

解决办法

mucs3173 syslog.log 中包含很多以下信息:

cmclconfd[29685]: Could not get vg (/dev/vg3139_TAQ_A) info: 3

使用 cmscancl 命令取得所有节点的 /etc/lvmtab 内容并且发现只有受影响的节点上有 vg3139_TAQ_A 和 vg3139_TAQ_old :

$ grep -e lvmtab -e vg3139_TAQ scancl.out  
------ Output of strings /etc/lvmtab (mucs3090) ------  
/dev/vg3139_TAQ 
------ Output of strings /etc/lvmtab (mucs3088) ------  
/dev/vg3139_TAQ 
------ Output of strings /etc/lvmtab (mucs3173) ------  
/dev/vg3139_TAQ_A      <---?? 
/dev/vg3139_TAQ_old    <---?? 
/dev/vg3139_TAQ     
------ Output of strings /etc/lvmtab (mucs3179) ------  
/dev/vg3139_TAQ 
------ Output of strings /etc/lvmtab (mucs3091) ------  
/dev/vg3139_TAQ

如果加上 -k 选项cmcheckconf 会顺利执行. 这个选项消除了检查LVM磁盘, 所以这就确定了问题和LVM问题有关系.

动作 :

  • • 检查 /dev/vg3139_TAQ_A 是否存在于受影响的节点上.
  • 如果卷组 vg3139_TAQ_A 不需要了, vgexport 它.

效果 :

vgexport 解决了问题.

地址:http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay?javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken&javax.portlet.prp_ba847bafb2a2d782fcbb0710b053ce01=wsrp-navigationalState%3DdocId%253Demr_na-c02491156-1%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&sp4ts.oid=4162060&ac.admitted=1408344051145.876444892.199480143

HP 集群软件 - 不能接收节点的设备查询信息:软件引起的连接失败

时间: 2024-10-13 16:10:53

HP 集群软件 - 不能接收节点的设备查询信息:软件引起的连接失败的相关文章

mongodb集群安装及延迟节点配置

mongodb集群安装及延迟节点配置 本文主要介绍mongodb安装.副本集模式的配置.mongodb数据库的简单使用及延迟节点搭建和利用延迟节点恢复误删除的数据. 一.系统环境 平台:Centos6.6_x86_64 实验环境:四台主机部署副本集模式集群 主机:192.168.115.21.192.168.115.22.192.168.115.23.192.168.115.24 规划:21为master节点,22为副本节点,23为副本节点,24为延迟节点 目的:完成副本集模式集群的部署 测试延

请教高手!在VM下配置服务器双机集群,总是在添加节点2的时候,出现错误0x8007042c依存服务或组无法启动。

请教高手!在VM下配置服务器双机集群,总是在添加节点2的时候,出现错误0x8007042c依存服务或组无法启动. 请教高手!在VM下配置服务器双机集群,总是在添加节点2的时候,出现错误0x8007042c依存服务或组无法启动.

使用kubeadm部署k8s集群09-配置worker节点

使用kubeadm部署k8s集群09-配置worker节点 2018/1/4 配置 worker 节点 初始化 加入集群 切换 worker 节点连接到 apiserver 的 LB 入口 调整集群中节点角色和调度策略 初始化 /etc/hosts ### k8s master @envDev 10.10.9.67 tvm-00 10.10.9.68 tvm-01 10.10.9.69 tvm-02 k8s worker @envDev 10.10.9.74 tvm-0310.10.9.75 t

Hadoop概念学习系列之Hadoop集群动态增加新节点或删除已有某节点及复制策略导向

hadoop-2.6.0动态添加新节点 https://blog.csdn.net/baidu_25820069/article/details/52225216 Hadoop集群动态增加新节点 一.在新增节点配置运行环境 1.安装和其他节点相同的java环境,jdk版本要相同. 2.修改/etc/hosts配置文件,添加ip与hostname的对应关系并分发到集群各个节点. 3.关闭防火墙.相关软件工具的安装等. 4.配置ssh免密码登录,使新增节点和集群其他节点能实现免密码登录. 5.修改s

使用 kubectl drain 从集群中移除节点

对节点执行维护操作之前(例如:内核升级,硬件维护等),您可以使用 kubectl drain 安全驱逐节点上面所有的 pod.安全驱逐的方式将会允许 pod 里面的容器遵循指定的 PodDisruptionBudgets 执行优雅的中止. 注: 默认情况下,kubectl drain 会忽略那些不能杀死的系统类型的 pod,如果您想了解更多详细的内容,请参考kubectl drain kubectl drain 返回成功表明所有的 pod (除了前面排除的那些)已经被安全驱逐(遵循期望优雅的中止

Cassandra集群管理-替换异常节点

Cassandra集群管理-替换异常节点 替换异常集群节点,使用JVM启动标志 Dcassandra.replace_address_first_boot = <dead_node_ip>启动.一旦启用此属性,节点将在休眠状态中启动,在此期间所有其他节点将看到此节点关闭.替换节点将立即开始从集群中的其余节点引导数据. 新节点的正常引导的主要区别在于此新节点在此阶段不会接受任何写入.一旦引导完成,节点将被标记为"UP",我们依赖于隐性启动保障新节点数据独立存在.(因为自引导开

Kubernetes容器集群管理环境 - Node节点的移除与加入

一.如何从Kubernetes集群中移除Node 比如从集群中移除k8s-node03这个Node节点,做法如下: 1)先在master节点查看Node情况 [[email protected]-master01 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-node01 Ready <none> 47d v1.14.2 k8s-node02 Ready <none> 47d v1.14.2 k8s-node03 R

为什么redis哨兵集群只有2个节点无法正常工作?

由于redis的响应速度快,每秒支持的并发极高(号称10万),现在redis越来越流行了redis支持的存储有: string, hash(map),list, set, sortset 同时可以使用redis的setnx 来实现分布式锁首先谈谈redis的哨兵模式: 哨兵支持对主从的监控,并且当主节点挂机之后,可以启动从节点升级为主节点继续提供服务同时哨兵也支持对客户端提供发现服务,客户端通过连接哨兵从而获取主节点的信息,如果主节点挂机,在升级从节点为主节点之后,客户端通过哨兵可以连接上新的主

集群的消息接收通道

与消息发送通道对应,发送的消息需要一个接收端接收消息,它就是ChannelReceiver.接收端负责接收处理其他节点从消息发送通道发送过来的消息,实际情况如图每个节点都有一个ChannelSender和ChannelReceiver,ChannelSender向其他节点的ChannelReceiver发送消息.本质是每个节点暴露一个端口作为服务端监听客户端,而每个节点又充当客户端连接其他节点的服务端,所以ChannelSender就是充当客户端的集合,ChannelReceiver充当服务端.