wanger5354的博客

微信公众号：运维开发故事作者：wanger。

我是乔克，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！所以就打开控制台，使用natstat-ano，不看不知道，一看吓一跳，发现非常多的链接都是和47.95.x.x进行的。试着删除该文件，当然是失败了，不过，也知晓了该进程是通过.net服务托管着的，那我就把.net停掉呗，反正没用这个服务。但是出了问题，不得不管呀，歌也没唱了，跑到车库，打开电脑，开始一顿瞎操作。...

在讲解事件、故障处理思路前，先讲一个故障场景（以呼叫中心系统作为一例子）：业务人员反映呼叫中心系统运行缓慢，部分电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有……时间不知不觉地在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？”…… 运维人员赶紧敲键盘，写sql，看交易量；敲键盘，写命令，看系统资源、情况…… 最终，定位到问题

本文主要介绍ceph16版本集群节点系统磁盘故障后的集群恢复，虽然系统盘很多都是做了raid1，但从实际做的项目看，总是有很多未知意外发生，节点挂掉后，上面的mon和osd，mgr都会down掉，如果所在节点的mgr服务是激活状态，则其他节点所在的备用节点将会升级为激活状态。移除问题主机节点挂掉后，在确定不能继续开机进入系统的情况下，需要在其他正常的节点将故障节点进行移除，此次宕机的节点为node4，以下命令可能会导致数据丢失，因为 osd 将通过调用每个 osd 来强制从集群中清除。ceph o

今天发现一个Pod一直处于ContainerCreating状态，通过Describe查看，发现以下错误。Warning  FailedMount  15s        kubelet, node-2    MountVolume.WaitForAttach failed for volume "p

微信公众号：运维开发故事，作者：华仔问题描述最近在某个k8s集群其中一个节点(master1)上执行kubectl get nodes大概需要45s的时间才有数据返回，而在另外的master上执行同样的命令却是很快返回。通过kube-apiserver的日志来看，是无法连接上metrics-server，从而导致超时。进而发现这个master无法与其他节点的flannel.1的IP互相ping通。于是就有了这一篇文章。排查结果因为我们的网络组件使用的canal，跨主机通信时，通过flannel(.

微信公众号：运维开发故事，作者：wanger问题描述昨天fusion computer的一台CNA节点，突然挂掉了，重启之后也找不到引导，由于vrm管理平台的虚拟机也部署在那个节点上，vrm没做主备部署，导致了vrm管理平台也无法使用,后来重装了那个坏掉的节点和上面的vrm，虽然这个节点坏了，但另一个节点上的虚拟机还是可以用的，当我准备将原先正常的节点添加到新装的vrm的时候，上面的虚拟机突然都没了，使用virsh list --all查询显示为空，好在查看存储发现数据存储并没丢失存储数据恢复进.