PHPor 的Blog – 第27页

查找网线在交换机哪个口的方法

已知：

我可以登录服务器
我可以登录交换机
服务器上有多块网卡，当前登录走网卡em1

任务：

要给em4配置ip地址

步骤：

首先找到em4在交换机的哪个口

在服务器上：

ip link set em4 up

1

ip link set em4 up
在服务器上：

ping -I em4 1.1.1.1

1

ping -I em4 1.1.1.1
在交换机上

dis mac-address | include xxxx #其中xxxx是em4的mac地址

1

dis mac-address | include xxxx #其中xxxx是em4的mac地址
啥？没有？有可能，继续

在交换机上

display interface brief   | include 100M    #看看有没有speed是100M的端口,现在都是千兆交换机，应该不会出现 100M， 如果有的话，就include 10M

1	display interface brief \| include 100M #看看有没有speed是100M的端口,现在都是千兆交换机，应该不会出现 100M，如果有的话，就include 10M

在服务器上

ethtool -s em4 speed 100 duplex half #将网卡设置为100M

1

ethtool -s em4 speed 100 duplex half #将网卡设置为100M
在交换机上

display interface brief | include 100M #应该可以看到有一个端口是100M的了，那么该端口就是em4网线使用的端口

1

display interface brief | include 100M #应该可以看到有一个端口是100M的了，那么该端口就是em4网线使用的端口
把网卡重新设置为自动协商模式：

ethtool -s em4 autoneg on

1

ethtool -s em4 autoneg on

然后配置交换机上该端口
配置服务器IP

参考：

http://blog.csdn.net/ggxiaobai/article/details/53583290

fuser or lsof

如果要卸载一个目录，那么目录下任何一个文件被占用都是不能卸载的，但是通常会不假思索地使用fuser 挂载目录，如挂载目录为 /data :

我们发现，fuser 并没有觉得谁在占用 /data ，然而lsof 却能知道；实际上fuser仅仅查看当前的inode有没有被占用，还是lsof更适合此场景

其实，fuser -m 选项是可以的; 而且还可以fuser -k 直接杀掉相关的进程；

注意fuser 选项-m与-M的区别：

-m 会根据指定的位置计算该位置所在的挂载点，然后列出该挂载点文件系统相关的进程

-M 必须指定一个确切的挂载点，对于目录可以没有’ / ‘；这个有时更加安全，有时候，对于已经卸载了的挂载点，就已经属于别的文件系统了

gops 工作原理

gops用来查看系统中存在的go进程。

注意事项：

gops有可能没发现你的go进程：

一方面可能进程是藏在容器中的，在宿主机上gops就发现不了

另一种情况，就是gops参考的是进程文件的特征，该特征在不同go版本可能不一样，比如，我的gops能发现go 1.11的go进程，就发现不了go 1.14的go进程

如下：

gops能list出来系统中的go进程，如果内置了agent的话，还能添加个星号，带星号的进程可以进行深度的分析（因为有agent呀）

那么，gops是如何找到所有go进程，又是如何识别出来agent的呢？

关键代码是这么写的：

// isGo looks up the runtime.buildVersion symbol
// in the process' binary and determines if the process
// if a Go process or not. If the process is a Go process,
// it reports PID, binary name and full path of the binary.
func isGo(pr ps.Process) (path, version string, agent, ok bool, err error) {
	if pr.Pid() == 0 {
		// ignore system process
		return
	}
	path, err = pr.Path()
	if err != nil {
		return
	}
	var versionInfo goversion.Version
	versionInfo, err = goversion.ReadExe(path)
	if err != nil {
		return
	}
	ok = true
	version = versionInfo.Release
	pidfile, err := internal.PIDFile(pr.Pid())
	if err == nil {
		_, err := os.Stat(pidfile)
		agent = err == nil
	}
	return path, version, agent, ok, nil
}

// isGo looks up the runtime.buildVersion symbol

// in the process' binary and determines if the process

// if a Go process or not. If the process is a Go process,

// it reports PID, binary name and full path of the binary.

func isGo(pr ps.Process) (path, version string, agent, ok bool, err error) {

if pr.Pid() == 0 {

// ignore system process

return

}

path, err = pr.Path()

if err != nil {

return

}

var versionInfo goversion.Version

versionInfo, err = goversion.ReadExe(path)

if err != nil {

return

}

ok = true

version = versionInfo.Release

pidfile, err := internal.PIDFile(pr.Pid())

if err == nil {

_, err := os.Stat(pidfile)

agent = err == nil

}

return path, version, agent, ok, nil

}

拿到所有的系统进程
分析进程文件可以检测是否go进程
在进程的用户目录下查找 .config/gops/{$pid} 文件，如果存在，就认为是有内置了agent了，该文件中存放的是agentlisten的端口号

如下：

display arp vs display mac-address

首先，对交换机的操作很不熟悉；

需求：我想从交换机上查看我的服务器是插在了交换机的哪个端口上，进而做一些设置。

已知：我知道我的服务器的mac地址

理论上来讲，交换机里面维护这一个mac <—-> interface 的对照表，我肯定是可以查出来的。

操作：记得display arp可以看到很多mac地址与interface的对应关系，如下：

注意到没？都是192.168.4.* 的，其实我要查看的是10.88.10.* 的，而且，10.88.10.* 属于vlan 4000；难道是： display arp vlan 4000 ？结果更不对

思考：

该交换机的ip为192.168.4.12，上面只显示192.168.4.* 是否和该交换机有192.168.4.12 有关系？如果该交换机上添加了10.88.10.* 的ip的话，是不是也能显示10.88.10.*的mac地址呢？应该是吧。但是交换机是工作正常的，交换机知道哪个mac的包去哪个端口的，这个不会已是否存在10.88.10.*而改变的。display arp可以显示所有的arp请求得到的mac地址，display arp vlan N 则，可以过滤某个vlan下的arp信息。其实：
arp 不等于 mac ，我想要的命令应该是 display mac-address ：

为什么ceph-mon不能放在基于ceph的openstack的虚拟机上

由于对ceph-mon不甚了解，做了下面一件事情：

openstack存储完全基于ceph存储
ceph存储节点单独部署
现有ceph-mon节点2个（mon-1，mon-2），想重装mon-1；但是，没有了ceph-1之后，ceph-2似乎认为脑裂了，不提供服务；于是想找个临时mon顶上
在openstack集群上很轻松地申请了一台机器，很快变安装了一个mon-3，由于安全组（没有放开6789）的原因，虽然mon-3能够找到mon-2，ceph -s也能看到，但是mon-1却因为不能连接到mon-3使得mon-3没有完全加入，调整安全组后，似乎一切变的正常，当mon-1去掉之后，ceph -s 卡住了，mon-3中正在执行的yum也卡住了
观察发现，mon-2 出于probing状态，mon-3出于reop状态，没有leader了
1. 因为mon-3 依赖ceph，但是ceph没有了leader，mon-3就不能落地数据
2. mon-3不能落地数据的话，mon-2、mon-3之间就没法选举出来leader
3. 如此，事情进入僵局，死锁了
分析：
1. 每个mon上都存在一个db，里面放着monmap信息，启动的时候，就根据monmap中的信息加入集群，如果monmap中只有自己，直接启动就可以了，如果有多个mon节点，并且当前不存在leader就得选举
2. 如果能把monmap中的mon节点修改成只有自己，就能正常启动
解决办法：（参考: http://docs.ceph.com/docs/jewel/rados/troubleshooting/troubleshooting-mon/#recovering-a-monitor-s-broken-monmap )
1. 停掉mon-2，不停掉是操作不了monmap的db的
2. 导出monmap：
  ceph-mon -i ID-FOO –extract-monmap /tmp/monmap
3. 查看monmap：
  monmaptool –print -f /tmp/monmap
4. 删除mon-3
  monmaptool –rm mon-3 -f /tmp/monmap
5. 注入monmap
  ceph-mon -i ID –inject-monmap /tmp/monmap
6. 启动mon-2

Inject a monmap into the monitor

Usually the safest path. You should grab the monmap from the remaining monitors and inject it into the monitor with the corrupted/lost monmap.

These are the basic steps:

Is there a formed quorum? If so, grab the monmap from the quorum:

$ ceph mon getmap -o /tmp/monmap

1

$ ceph mon getmap -o /tmp/monmap

No quorum? Grab the monmap directly from another monitor (this assumes the monitor you’re grabbing the monmap from has id ID-FOO and has been stopped):

$ ceph-mon -i ID-FOO --extract-monmap /tmp/monmap

1

$ ceph-mon -i ID-FOO --extract-monmap /tmp/monmap

Stop the monitor you’re going to inject the monmap into.

Inject the monmap:

$ ceph-mon -i ID --inject-monmap /tmp/monmap

1

$ ceph-mon -i ID --inject-monmap /tmp/monmap

Start the monitor

Please keep in mind that the ability to inject monmaps is a powerful feature that can cause havoc with your monitors if misused as it will overwrite the latest, existing monmap kept by the monitor.

http://docs.ceph.com/docs/master/rados/troubleshooting/troubleshooting-mon/

What if the state is probing?

This means the monitor is still looking for the other monitors. Every time you start a monitor, the monitor will stay in this state for some time while trying to find the rest of the monitors specified in the monmap. The time a monitor will spend in this state can vary. For instance, when on a single-monitor cluster, the monitor will pass through the probing state almost instantaneously, since there are no other monitors around. On a multi-monitor cluster, the monitors will stay in this state until they find enough monitors to form a quorum – this means that if you have 2 out of 3 monitors down, the one remaining monitor will stay in this state indefinitively until you bring one of the other monitors up.

If you have a quorum, however, the monitor should be able to find the remaining monitors pretty fast, as long as they can be reached. If your monitor is stuck probing and you have gone through with all the communication troubleshooting, then there is a fair chance that the monitor is trying to reach the other monitors on a wrong address. mon_status outputs the monmap known to the monitor: check if the other monitor’s locations match reality. If they don’t, jump to Recovering a Monitor’s Broken monmap; if they do, then it may be related to severe clock skews amongst the monitor nodes and you should refer to Clock Skews first, but if that doesn’t solve your problem then it is the time to prepare some logs and reach out to the community (please refer to Preparing your logs on how to best prepare your logs).

Start request repeated too quickly

参考： http://blog.csdn.net/styshoo/article/details/64091744

openstack 网络问题

同网段的机器ping的时候报没有路由的问题
1. arp -an查看，发现mac地址都没查到
2. 通过宿主机直接看虚拟机，发现虚拟机的网卡、ip都是在的
3. 解决：
  1. 虚拟机桥接的网桥重启过，而虚拟没有重启，相当于“网线断了”
4. 结论：
  1. 不要随便重启网桥，重启之后端口信息就没了，其下属的机器就相当于断了网线，后果很严重
openstack启动的机器我们都可以看到libvirtd的xml配置文件，xml配置文件中有关于网卡机器对应的tap的信息；我们直接virt-manager上通过桥接方式配置的网卡，在xml文件中找不到关于tap的名字的信息，但是对应的网桥下确实会多出来一个类似于vnet的网络设备

ceph 移除node问题

背景：

由于原来的ceph-4的系统盘没有做raid，为了更加靠谱，决定重装ceph-4；首先，按照官方文档给出的方法，一个一个卸掉osd，然后

ceph osd purge {id} --yes-i-really-mean-it

1	ceph osd purge {id} --yes-i-really-mean-it

但是，发现crush中还是存在ceph-4，虽然没有了osd，看着很是碍眼，于是看了写help，执行

ceph osd crush unlink ceph-4

1	ceph osd crush unlink ceph-4

然后，crush中就看不到ceph-4了

后来，ceph-4重装后，执行：

ceph-deploy install ceph-4 --repo-url=http://mirrors.aliyun.com/ceph/rpm-luminous/el7/
ceph-deploy mgr create ceph-4
ceph-deploy mds create ceph-4
ceph-deploy rgw create ceph-4
ceph-deploy osd create ceph-4:/dev/vdb
ceph-deploy osd create ceph-4:/dev/vdc
ceph-deploy osd create ceph-4:/dev/vdd
ceph-deploy osd create ceph-4:/dev/vde

ceph-deploy install ceph-4 --repo-url=http://mirrors.aliyun.com/ceph/rpm-luminous/el7/

ceph-deploy mgr create ceph-4

ceph-deploy mds create ceph-4

ceph-deploy rgw create ceph-4

ceph-deploy osd create ceph-4:/dev/vdb

ceph-deploy osd create ceph-4:/dev/vdc

ceph-deploy osd create ceph-4:/dev/vdd

ceph-deploy osd create ceph-4:/dev/vde

结果，ceph osd tree时，发现 ceph-4 在crush中的结构和别的host不一样，无论如何也不向这里的osd分配数据，如下：

后经 Ceph中国社区2群 @孤舟指点，他说我的pool走的都是default，ceph-4 没有在default，然而，我根本不知道是哪里的不同导致出现了这样的差异，于是@孤舟赐我一锦囊，拆看如下：

ceph osd crush move ceph-4 root=default

1	ceph osd crush move ceph-4 root=default

结果：

疑问：

ceph-1 ceph-2 ceph-3 ceph-4 ceph-5 我都是按照相同的命令来执行的，为什么ceph-4就例外了呢？

我能想到的ceph-4唯一的不同就是ceph-4曾经存在过，可能删除的时候没有处理利索，难道是：

ceph osd crush unlink ceph-4

1	ceph osd crush unlink ceph-4

使用的不当？文档中还有一个

ceph osd crush rm <name>

1	ceph osd crush rm <name>

的用法，不知道二者有何差异，不过很可能是这样：

ceph osd crush remove ceph-4

1	ceph osd crush remove ceph-4

这个remove似乎也可以移除osd的，但是purge似乎对于osd来讲更加彻底

稍后研究

问题2

ceph osd out 的时候会rebalance一次
- 这次是因为数据的问题
ceph osd purge 的时候（也可能是ceph osd crush remove ceph-4 的时候）也会rebalance一次
- 这次是因为hash的问题
那么，能否通过设置 ceph osd set norebalance ，避免两次rebalance呢？似乎不行，set norebalance似乎只对于osd down掉有效，而out、remove操作似乎都不参考该设置，参考： http://www.xuxiaopang.com/2016/11/11/doc-ceph-table/