docker stop 卡死的问题

场景：

宿主机信息：

docker信息：

容器信息：

centos6.8

启动进程： /sbin/init （因为启动这个可以直接利用 init-scripts 配置自动启动的进程，比如： mysqld等）

 

操作

docker stop $name

 

现象： 卡死了，进不去了

 

分析：

/sbin/init进程不退出，由init进程启动的子进程也处于defunct状态； 很可能是上级的某进程存在bug； 逐级上朔，找到shim进程，该进程kill 默认信号是不死的，看来可能有问题，直接kill -9 ； 然后，容器就干净地退出了

ceph health 之 status & overall_status

缘起：

为什么我执行ceph health时都是HEALTH_OK，但是搭建了Prometheus+grafana： （参考：https://www.2cto.com/net/201801/712794.html ），看到的状态却是HEALTH_WARN，why？

分析：

我们使用的ceph_exporter: github.com/digitalocean/ceph_exporter ； 参考源码发现，这里使用json格式获取的health，而且参考的是overall_status ; 自己在命令行看看：

果不其然，overall_status 为 HEALTH_WARN

办法一：

参考status，不参考overall_status;

缺点：

  1. exporter并没有收集status信息，只收集了overall_status ，如果要使用status，还得修改exporter
  2. HEALTH_WARN 毕竟是有问题，查明问题才是根本解决办法

办法二：

查明为什么overall_status 为HEALTH_WARN ， 应该确实存在问题

 

查原因：

我的ceph版本： ceph version 12.2.1 (3e7492b9ada8bdc9a5cd0feafd42fbca27f9c38e) luminous (stable)

在 luminous 之前，ceph 输出的都是 overall_status ， luminous开始，就开始使用status了，但是，为了兼容以前的版本，还是输出了overall_status了，不过，为了让使用者意识到 overall_status 不建议使用了，所以，就强制将 overall_status 设置为了 HEALTH_WARN； 有时候，这个逻辑显得不太友好，于是，从12.2.2 开始添加了一个选项：

可以通过设置该选项，来禁止这个警告。

但是，我使用的是12.2.1 ，咋办？ 要么修改exporter，要么干脆升级ceph

比较稳妥的做法是，在一个测试的机器上，启动一个12.2.5版本的ceph-mon，设置：

然后，ceph.conf中指定连接该ceph-mon，测试效果如下:

没有了overall_status； 如此的话，ceph_exporter 就是要overall_status的话，还真就得修改ceph_exporter了, fork 后修改之：

https://github.com/phpor/ceph_exporter

 

参考：

https://github.com/ceph/ceph/pull/17930

http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-September/021031.html

bash 对单行中的单词进行排序

排序一般使用sort命令，但是，sort命令是基于行的：

这个是不会输出 ： a b c d 的

可以这样：

也或者：

总之，把空白换成换行

bash 之 <

注意，这个脚本里面的cat，这里很容易写作echo的，因为php中就是用的echo； 我们很容易将这种语法视为写复杂字符串的一种方法，而在shell中，这不是一个复杂的字符串，而是把这些内容作为命令的标准输入提供给命令的，而不是命令的参数：

知道了原理之后，就再也不用担心写错了

以发展的眼光看问题

时移世易，变法宜矣

上胡不法先王之法，非不贤也，为其不可得而法。先王之法，经乎上世而来者也，人或益之，人或损之，胡可得而法？虽人弗损益，犹若不可得而法。
凡先王之法，有要於时也，时不与法俱至。法虽今而至，犹若不可法。故释先王之成法，而法其所以为法。先王之所以为法者何也？先王之所以为法者人也。而己亦人也，故察己则可以知人，察今则可以知古，古今一也，人与我同耳。有道之士，贵以近知远，以今知古，以益所见，知所不见。故审堂下之阴，而知日月之行、阴阳之变；见瓶水之冰，而知天下之寒、鱼鳖之藏也；尝一脟肉，而知一镬之味、一鼎之调。

http://blog.sina.cn/dpool/blog/s/blog_5d245fe70102w9j9.html

openstack 命令行之 安全组

列出所有安全组：

 

列出所有名叫default的安全组的ID：

 

列出指定安全组下的所有规则： （–long 显示每条规则的方向，默认不显示方向）

可以通过–ingress   –egress  只显示指定方向上的规则； 通过 –protocol 显示指定协议相关的规则

 

实际应用：

检查是否所有的“default” 安全组都设置了允许所有tcp、udp都可以主动外出的规则：

结果输出：

如果输出了tcp和udp就意味着是正确的

 

添加安全组规则：

允许所有tcp主动外出访问：

 

ssh-copy-id 之后ssh还是提示输入密码的问题

问题： 如题。

现场情况：

  1. 我~/.ssh/下有多个秘钥
  2. 配置了 .ssh/config 文件，不同类型的机器使用不同的秘钥，也有一些机器使用默认的秘钥

问题原因：

  1. ssh-copy-id 默认使用的秘钥并不是 id_rsa.pub，而是最新修改过的秘钥：
  2. ssh 命令默认使用的秘钥是 id_rsa.pub
  3. 所以，ssh-copy-id 和 ssh 默认不同的秘钥时，就会出现上述问题
  4. 说明：
    1. ssh-copy-id 时，会提示使用的秘钥是哪个的：
    2. 可以通过 -i 选项来指定ssh-copy-id来使用哪个秘钥：

openstack 之 计算节点名字

如下图： 虚拟机管理器和计算主机中显示的主机的名字不同，为什么呢？

 

说明：

虚拟机管理器说的是hypervisor，具体来讲就是libvirtd

主机说的是虚拟机管理器所在的宿主机，就是我们所谓的计算节点

二者的信息都是记录在nova.compute_nodes 表中的，二者都没有唯一约束；

当然，host是不会重复的；特殊情况下hypervisor_hostname 重复是有可能的； 从dashboard来看，节点资源是hypervisor的，而不是host的。

而且也可以存在一个host上有多个虚拟机管理器的情况，一个nova-compute接到任务后，可以通过不同的虚拟机管理器来创建虚拟机

 

分析：

不同计算节点上使用相同hypervisor_hostname时，hypervisor将拥有了多个机器的资源，那么虚拟机调度时参考hypervisor_hostname的资源的话，虚拟机分配的任务最终会被分配到哪个host上呢？毕竟不同host上都有nova-compute进程的； 另，上报资源时使用的是node的uuid还是host还是hypervisor_hostname？

node的uuid又是如何生成的呢？

hypervisor_hostname 是如何获取到的呢？hypervisor_hostname是不是第一次注册的时候写入后来就不再修改了呢？

主机资源是记录在 nova_api.resource_providers 表中的：

当然，只有nova.compute_nodes 表中记录的uuid才是有效的resource_providers，才会被dashboard显示

 

为什么node节点的hostname已经修改了，虚拟机管理器中显示的还是以前的名字？

nova-compute.log 中会有错误信息：

 

问题： 谁和谁不一致？重启谁？

解决办法：

比较： hostname 和virsh hostname的结果：

二者是不同的，前者的信息是从libvirtd中获取到的，也就是说，libvirtd中显示的主机名和当前的主机名不一致，需要重启libvirtd， 相关逻辑：

 

 

问题：

  1. 重启libvirtd需要先关闭所有虚拟机吗？
    答案： 不需要的，直接重启就行
  2. 虽然我重启了libvirtd，但是virsh hostname 还是 和 hostname不一样，为什么？
    答案： 因为我在/etc/resolv.conf 中配置了search i.beebank.com, libvirtd会自动suffix上search domain的
  3. 虽然现在virsh hostname 和hostname一致了，但是dashboard中看到的还是原来的，为什么？
    答案： 重启一下openstack-nova-compute

 

总结：

  1. 确认一下 /etc/resolv.conf  的配置
  2. systemctl restart libvirtd && systemctl restart openstack-nova-compute

注意：

  1. 修改了libvirtd的hostname之后，需要去数据库中手动修改相关虚拟机（nova.instances表中）的hypervisor_hostname，否则，就找不到这些机器的hypervisor了，而新的hypervisor下也是没有虚拟机的