C0reFast记事本

to inspire confidence in somebody.

0%

之前的Blog:再谈CPU的电源管理(如何做到稳定全核睿频?)最终通过了tuned实现了CPU全核心运行在允许的全核睿频频率上。但是这个只是场景之一,并不是所有场景下都会用到很多的核心,从这些应用角度讲,更需要少量但是更高频率的核心,一个比较简单的例子就是DPDK,作为DPDK应用,一般来说也不会用到很多核心,但是他的polling模型,是希望单核频率越高越好的。针对类似的这种场景,实现少量核心,比如说单核的高频,比多核全开,频率变低更合适。

那么问题来了,怎么在Linux上实现稳定的单核睿频呢?这里给一个稍微暴力点的办法。

阅读全文 »

在之前的一篇Blog: 服务器的能耗控制以及高性能模式配置(Dell)中,说到在Dell的服务器BIOS中打开Performance模式。就可以实现真正非软件管理的高性能模式,让CPU时刻处在最高性能状态上。但是呢,最近的一批机器,升级到CentOS 7.7系统之后,这个行为发生了一些变化,而针对这批机器的两个供应商的表现呢,也不完全一致,这个现象驱使我研究了一下到底怎么样设置,可以实现期望的运行状态。也就是说,希望CPU稳定的运行在全核睿频上,既不需要他提升单核频率到单核睿频,也不希望他降频,这样,至少在我们当前的业务场景下,能获得比较稳定的性能预期。

阅读全文 »

在老的Linux中,特别是CentOS 6系统下,网卡大多数都是命名为eth0eth1这样的形式,但是这样的命名是不稳定的,因为后面的数字是根据驱动的加载顺序来的,那么就有可能出现两次启动导致网卡名称不一样的情况了。
在CentOS 7中,由于有了Systemd,所以引入了一种新的命名规则叫一致网络设备命名,具体的可以参考文档第 8 章 一致网络设备命名,这里就不再赘述了。

现在问题来了,如何真正意义上实现按意愿去设置网卡的名称呢?这里有个通用的方法:

编辑/etc/udev/rules.d/70-persistent-net.rules文件,如果有这个文件,则直接编辑就可以,如果没有就新建一个。
然后在文件中按以下的格式输入规则:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:01", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:02", NAME="ethxyz"

只需要根据情况,填写MAC地址和名字就可以了。另外,针对已有的网络配置,如CentOS下/etc/sysconfig/network-scripts/底下的那些ifcfg-xxxx配置文件,也需要针对性的进行修改。修改完成后重启机器即可生效。

针对udev规则,还有很多可以MATCH和修改的地方,可以实现很多复杂功能,具体的这里就不赘述了,感兴趣的可以参考一下udev - ArchWiki,或者其他udev相关的文章。

在我们的机房服务器上,启用了LLDPD服务,通过LLDP协议实现网络层的自动发现,从而根据收到的消息绘制网络拓扑关系。

之前的大部分机器一直工作正常,也没有多关注,然而今天突然发现有一批机器工作不太正常,因为后期的工作依赖这个拓扑关系,如果关系不正确,后面的工作就没办法进行,所以遇到不正常的机器还是需要具体分析一下为什么。

正常情况下,启动lldpd服务,并调用lldpctl可以看到网卡连接到的交换机信息:

阅读全文 »

事情的起因要算很久之前一次测试,一个同事借了我们的一台机器测试,在测试之前惯例使用cpupower frequency-set -g performance命令将CPU高性能模式打开,避免因为系统处于节能模式导致性能测试不准确。但是在我们这台机器上执行命令却报错了:

]# cpupower frequency-set -g performance
Setting cpu: 0
Error setting new values. Common errors:
- Do you have proper administration rights? (super-user?)
- Is the governor you requested available and modprobed?
- Trying to set an invalid policy?
- Trying to set a specific frequency, but userspace governor is not available,
   for example because of hardware which cannot be set to a specific frequency
   or because the userspace governor isn't loaded?
阅读全文 »

最近遇到了网站不断被一些国外的IP扫描的问题,想了想,决定将所有非国内的客户端全部封锁,只允许国内的用户进行访问。

首先需要找到所有国内的IP段,这个比较简单,ipip.net的github提供了一个china_ip_list项目,记录了目前所有国内的IP地址段,每月更新。
这个列表可以通过wget https://raw.githubusercontent.com/17mon/china_ip_list/master/china_ip_list.txt直接进行下载。

有了IP列表,接下来的事情相对简单不少,虽然理论上可以通过iptables针对文件里的每一个IP段添加规则,但是这样会添加几千条规则,不是最优解,所以就借助ipset和iptables进行封锁。

阅读全文 »

安装

sudo yum install libguestfs-tools      # Fedora/RHEL/CentOS
sudo apt-get install libguestfs-tools  # Debian/Ubuntu

挂载

mkdir -p /tmp/mnt
guestmount -a xxxx.qcow2 -m /dev/sda1 --rw /tmp/mnt

其中/dev/sda1参数是目标文件中的分区名称,如果输入错误,会报错并提示正确的分区名。

卸载

guestunmount /tmp/mnt

参考

guestfs-recipes - libguestfs, guestfish and virt tools recipes页面提供了libguestfs其他工具的一些使用方法,可供参考。

最近往K8s集群中添加节点的时候,发现部分节点的kubelet进程无法启动,导致节点处于NotReady状态。journalctl -u kubelet查看日志可以发现类似的日志:

....
Nov 29 23:32:13 localhost kubelet[3830]: I1129 23:32:13.311881    3830 server.go:333] Adding debug handlers to kubelet server.
Nov 29 23:32:13 localhost kubelet[3830]: W1129 23:32:13.311922    3830 cni.go:203] Unable to update cni config: No networks found in /etc/cni/net.d
Nov 29 23:32:13 localhost kubelet[3830]: E1129 23:32:13.312092    3830 kubelet.go:2192] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Nov 29 23:32:13 localhost kubelet[3830]: I1129 23:32:13.382130    3830 kubelet_node_status.go:278] Setting node annotation to enable volume controller attach/detach
Nov 29 23:32:13 localhost kubelet[3830]: I1129 23:32:13.383695    3830 cpu_manager.go:155] [cpumanager] starting with none policy
Nov 29 23:32:13 localhost kubelet[3830]: I1129 23:32:13.383705    3830 cpu_manager.go:156] [cpumanager] reconciling every 10s
Nov 29 23:32:13 localhost kubelet[3830]: I1129 23:32:13.383713    3830 policy_none.go:42] [cpumanager] none policy: Start
Nov 29 23:32:13 localhost kubelet[3830]: F1129 23:32:13.384272    3830 kubelet.go:1384] Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level BestEffort QOS cgroup : failed to set supported cgroup subsystems for cgroup [kubepods besteffort]: Failed to set config for supported subsystems : failed to write 4611686018427387904 to hugetlb.1GB.limit_in_bytes: open /sys/fs/cgroup/hugetlb/kubepods.slice/kubepods-besteffort.slice/hugetlb.1GB.limit_in_bytes: no such file or directory
Nov 29 23:32:13 localhost systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
阅读全文 »

最近一段时间在折腾虚拟化,想把SR-IOV硬件直通给用起来,所以免不了要利用lspci这个工具,用来查看当前系统连接的所有PCI/PCIe设备。其实之前也有用到过,也有一些不理解的地方,只是当时无脑跟着文档设置,也就没多关心了,这次需要好好的理解一下相关的概念什么的。

首先很简单,看看不加参数直接调用lspci命令的输出结果,下面的是我笔记本上的输出:

00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:04.0 Signal processing controller: Intel Corporation Broadwell-U Processor Thermal Subsystem (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3)
00:1c.4 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #5 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)
阅读全文 »

之前线上运行的K8S集群出现了一个Pod IP无法访问问题,调查了一下,发现和CalicoIP地址的分配策略相关,具体表现为一个/26的IP Block192.168.100.0/26分配给了A机器之后,在另外一台B机器上又出现了该IP Block内的一个IP 192.168.100.10,同时因为A机器上有该IP Block的blackhole路由blackhole 192.168.100.0/26 proto bird,所以导致A机器上所有的Pod访问192.168.100.10时因为黑洞路由原因直接失败。

遇到这个问题之前,只是通过文档大致了解Calico的IP分配策略,没有深入源码看看实际的情况,现在出现了相关问题,还是需要阅读一下相关代码,当然在这过程中也发现了一些问题,有些问题Calico官方也没有很好的解决。

阅读全文 »