多 IP 绑定的问题

主要涉及内核的 promote_secondaries 这个参数。

目前 eth0 接口只有 10.18.101.5 这个 ip:
# ip add sh eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 54:04:a6:98:bf:d6 brd ff:ff:ff:ff:ff:ff
    inet 10.18.101.5/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5604:a6ff:fe98:bfd6/64 scope link
       valid_lft forever preferred_lft forever


给 eth0 新添加几个 ip:
# ip addr add 10.18.101.6/24 dev eth0
# ip addr add 10.18.101.7/24 dev eth0
# ip addr add 10.18.101.8/24 dev eth0

# ip add sh eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 54:04:a6:98:bf:d6 brd ff:ff:ff:ff:ff:ff
    inet 10.18.101.5/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.6/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.7/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 10.18.101.8/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5604:a6ff:fe98:bfd6/64 scope link
       valid_lft forever preferred_lft forever

Continue reading

rh6.2 kernel panic 级别的 bug

线上已经稳定运行了半年多,一共遇到了两次不同的 kernel panic。以下的使用的是 6.2 的标准内核 2.6.32-220.el6.x86_64。

1. Kernel panic on divide-by-zero in get_dirty_limits
这个现象是在执行 reboot 之后,出现 panic,导致机器无法启动
这个在 vm.dirty_ratio 以及 vm_dirty_bytes 同时被置为 0 时,会出现 overflow,这个 private bug 目前还没 patch 出来(rhel 6.5 会修复这个 bug),比较好的方式是将 vm.dirty_ratio = 1。

2. kernel panic at nf_nat_setup_info
如果机器上部署了 SNAT 的话,就会中标。这个只能升级 kernel 到 2.6.32-220.30.1.el6 或者更高。在升级的过程中还遇到了一个小插曲。
由于完全进不了系统,只能通过 rescue mode 进行升级。进入之后:
# uname -a
Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

将需要更新的 kernel* 上传到该机器上:
# ll kernel-*
-rw-r–r– 1 root root 26408880 Feb 25 11:15 kernel-2.6.32-279.el6.x86_64.rpm
-rw-r–r– 1 root root  7990420 Jun 15  2012 kernel-devel-2.6.32-279.el6.x86_64.rpm
-rw-r–r– 1 root root  9099056 Feb 25 11:09 kernel-firmware-2.6.32-279.el6.noarch.rpm
-rw-r–r– 1 root root  1988972 Feb 25 11:09 kernel-headers-2.6.32-279.el6.x86_64.rpm

安装:
# rpm -ivh *rpm
会出现如下的 error:
kernel-firmware-2.6.32-220.el6.x86_64 conflicts with file from package kernel-firmware-2.6.32-279.el6.x86_64

只有先覆盖原来的 firmware,再安装剩余的三个:
# rpm -Uvh kernel-firmware-2.6.32-279.el6.noarch.rpm
# rpm -ivh kernel-2.6.32-279.el6.x86_64.rpm kernel-devel-2.6.32-279.el6.x86_64.rpm kernel-headers.2.6.32-279.el6.x86_64.rpm

完成,检查确认:
# cat /etc/grub.conf
# rpm -qa | grep kernel

关于第二个 bug 还要再说几句,本来这个 bug 也不是个多大的事,SNAT 挂了顶多是内网的机器无法访问外网,悲剧的是,为了省事我们的 web server 跟 SNAT 部署在同一台机器上,更悲剧的是,当时紧急上线,web server 连个 failover 都没有,最后的结果就是我们的这台前端机器两天挂了六次,损失了 [email protected]#$%^%。
总之教训就是,1)不要图省事。2)可以做 failover 的必须做。现在侥幸的迟早会出事。
单台硬件是不稳定的,单台软件也是不稳定的,但是两台同时宕的几率应该是小之又小了,除非发生了网络故障。

除了上面两个,还有个 2.6.32 都会发生的 208.5 day 的 bug,之前线上的 ubuntu 也遇到了这类悲剧,10.04 的可以升级到 2.6.32-38;rh 6.x 的可以升级到 kernel-2.6.32-279.el6

最后,我们的一个跑在 rh6.2 的 hadoop 集群曾经遇到过 sys time、load 高出正常水平的问题,究其原因,6.2 默认开启了 THP,关闭即可。

使用 kdump 收集 kernel panic 信息

某台机器在执行 sync;reboot 后出现了 kernel panic,给 rhn 提 issue,指导我们使用 kdump 把 panic 时的内存给 dump 下来,很早就听说 kdump,趁此机会学习下使用方法

kdump 需要两个不同目的的内核,生产内核和捕获内核。生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启动起来,与相应的 ramdisk 一起组建一个微环境,用以对生产内核下的内存进行收集和转存。

kdump 使用 kexec 机制来 dump kernel panic 时候的内存信息 从 rhel5 开始,kexec-tools 已被默认安装在发行版。当出现 kernel panic 时,kdump 使用 kexec 启动到第二个内核,也叫 capture kernel 或者 second kernel,出现 panic 的那个叫做 production kernel 或 first kernel,在 first kernel 崩溃时,second kernel 会启动起来,该 first kernel 保留了内存的一部分给 second kernel 启动使用,这个 second kernel 就能够收集和转存 first kernel 的内存信息以提供诊断。

/proc/vmcore 可以选择 dump 到本地的 fs,nfs、ssh,或者是设备。默认(kdump.conf 里面的 path 选项)是直接 dump 到 /var/crash/ 目录下。其他的比较方便的诸如 ssh 直接 RTFM 就好了,kdump.conf 里面的注释写的很清楚。

要使用 kdump,首先要在 /etc/grub.conf 追加上 crashkernel=128M。其实正确的格式是 [email protected],X 是为 kdump 捕获内存保留的内存,Y 是保留部分内存的开始位置。不过正常情况下,可以直接忽略 @X 这部分,对于 Y,正常的 amd64 128M 就可以了。

设置完上面这些之后,重启:
# chkconfig kdump on
# reboot
# service kdump status 
  Kdump is operational 
# service kdump start

查看 /sys/kernel/kexec_crash_loaded 值判断 second kernel 是否加载,1 为已加载否则未加载。

测试一下,正常情况下应该在 /var/crash/ 下面产生一个类似 127.0.0.1-2013-01-24-19:05:36 的目录,里面有一个叫 vmcore 的文件:
# echo c > /proc/sysrq-trigger
# ll /var/crash/127.0.0.1-2013-01-24-19\:05\:36/

total 147924
-rw——- 1 root root 151467950 Jan 24 19:06 vmcore

正常情况下,产生的 vmcore 会比较大,可以使用 kdump.conf 里面的 core_collector 来进行『裁剪』,包括哪些类型(zero, cache, private, user, free)的 pages 需要保留,这面这个表示
zero pages, cache pages, cache private, user pages, free pages 都不需要 dump 到 vmcore 里面,并且将剩下的数据做压缩:
core_collector makedumpfile -d 31 -c

每次修改完 kdump.conf,需要重启服务:
# service kdump restart

除了使用命令行的方式,RH 还提供一个图形化的叫做 system-config-kdump 工具,可以试试。

对于事后的诊断,可以使用 crash 这个工具,需要安装 kernel-debuginfo 内核调试的工具,详细的使用可以参见这里

Linux Kernel in a Nutshell 笔记(五)

Kernel Configuration Recipes

插一句,在 make 的时候,可以选择配置界面的颜色:
$ make MENUCONFIG_COLOR=<theme> menuconfig

mono       => selects colors suitable for monochrome displays
blackbg    => selects a color scheme with black background
classic    => theme with blue background. The classic look
bluetitle  => a LCD friendly version of classic. (default)
Continue reading

Linux Kernel in a Nutshell 笔记(四)

7.Customizing a Kernel

判断系统需要哪些驱动的最简单的办法就是查找发行版本内核的配置;或者可以查找 /proc/ 下面的 config.gz 文件:
$ ll /proc/config.gz
-r–r–r– 1 root root 31089 May  1 20:40 /proc/config.gz
$ cp /proc/config.gz ~/linux
$ cd ~/linux
$ gunzip -dv config.gz

解压之后将其复制到 kernel 的顶层目录,然后就可以参照之前的步骤编译了。当然不是每个系统都有 config.gz 文件,这个要看当初该内核的配置文件里面有没有下面这两行:
$ cat /boot/config-$(uname -r) | grep -i ikconfig
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

如果没有的话,就不会在 /proc/ 下面发现 config.gz 文件了,可以在编译内核的时候加入下面的选项:
General setup —>
<*> Kernel .config support
[*] Enable access to .config through /proc/config.gz
Continue reading

Linux Kernel in a Nutshell 笔记(三)

5.Install and Booting from a kernel
6.Upgrading a Kernel

通过 make 得到了可执行的二进制文件以及内核模块,接下来需要安装,下面所有的步骤都需要 root 权限。

大多数发行版本都有个叫 installkernel 的脚本,该脚本可以将内核安装到正确的位置并且修改 bootloader,该脚本通常位于 mkinitrd 的包中。ubuntu 下的叫 initramfs-tools:
$ sudo apt-cache show initramfs-tools | head
Package: initramfs-tools
Priority: required
Section: utils
Installed-Size: 432
Maintainer: Ubuntu Kernel Team <[email protected]>
Original-Maintainer: Debian kernel team <[email protected]>
Architecture: all
Version: 0.92bubuntu78
Provides: linux-initramfs-tool
Depends: initramfs-tools-bin (= 0.92bubuntu78), klibc-utils (>= 1.5.9-1), busybox-initramfs (>= 1:1.13.3-1ubuntu5), cpio, module-init-tools, udev (>= 147~-5), findutils (>= 4.2.24), util-linux (>> 2.15~rc1)
Continue reading