racktables 的使用感受

racktables 是什么,能做什么,可以看这里
先简单的说下安装,跟普通的 lamp 一个套路。PHP 常见的 extension 该安装的安装。接着开始正式安装 racktables。
途中遇到几个 "NOT PASS":
Multibyte string extension
JSON extension
BC Math extension

一个个安装上即可:
# yum install php-bcmath php-mbstring
# yum install gcc make php-devel php-pear
# pecl download json
# pear install json-1.2.1.tgz

# cat /etc/php.d/json.ini
extension=json.so

测试下:
# service httpd reload
# php -r 'var_dump(function_exists("json_encode"));'

还有几个是 "NOT PRESENT",不是强制性的:
LDAP extension
PCNTL extension
accessed over HTTPS

建库建表:
# touch '/var/www/html/racktables/inc/secret.php'; chmod 666 '/var/www/html/racktables/inc/secret.php'
> CREATE DATABASE racktables_db CHARACTER SET utf8 COLLATE utf8_general_ci;
> GRANT ALL PRIVILEGES ON racktables_db.* TO [email protected] IDENTIFIED BY 'MY_SECRET_PASSWORD';

以上就是安装过程了,还是很简单的,使用也蛮简单的,简单的没找到一个正式的 manual,只有一个残缺不全的 wiki

使用过程中,除了遇到不少 bug 之外,还忘记过一次密码,重置一下就好了:
> UPDATE UserAccount SET user_name = 'admin', user_password_hash = SHA1('mynewpassword') where user_id = 1;

下面说说我们使用一段时间的感受:
当初在 freshmeat 上看到这个项目,眼前一亮的感觉。我们看中他的功能主要包括如下的几个:

1. 可以将服务器交换机机柜机房等部件以及关系图形化
2. 可以管理 ip(vlan, vip 等),算是一个简单的 IPAM,类似我们之前调研过的 gestioip, Device42(Commercial)。  
3. 可以通过 snmp 的方式(半自动)导入网络设备的信息

主要就这几个了。我们当时试用的是 0.20.3 版本,对于第一点,这个需要手动的生成,对于喜欢自动化的人的来说,简直是灾难;第二点现在看来不算优势;第三点需要 racktables 里面代码的支持,只能支持有限的型号,基本等于残废。总体的使用的感受就是比上不足比下有余,跟我们的三观不是很匹配。最终的结果是我人肉导入了一两个机架的机器,后面就没再继续了。
如果你要使用,不妨先试试他提供的 demo。我的建议是,对于有不超过两位数机器,也就是机架数量差不多在 10 个以内的,使用应该完全没有问题的。超过这个范围的还是另觅新途(cmdbuild)或者自己开发吧。

是否需要端口自动协商(Autonegotiation)

对于服务器或者交换机来说,是否需要开启端口的自动协商(autoneg)?
答案很明确,必须要。除非你的设备是 10 年之前的老古董,这个对于目前托管在 IDC 的机器来说基本不存在这个问题。并且,越是新的设备越是需要支持自动协商。由于目前所有的主流设备出厂默认设置即为自动协商,因此,对于工程师来说,没有任何的工作量可言,何乐而不为。
为什么要这样?请看这里(1,2 )。

随便挑台交换机看看:
#show interfaces Gi0/25 capabilities
GigabitEthernet0/25
  Model:                 WS-C2960G-48TC-L
  Type:                  10/100/1000BaseTX
  Speed:                 10,100,1000,auto
  Duplex:                half,full,auto

对于服务器来说,不管是 1G 的还是 10G 的,默认都是 auto:
# ethtool  eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supported pause frame use: Symmetric
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on

# ethtool  eth2
Settings for eth2:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseT/Full
                            10000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseT/Full
                            10000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 10000Mb/s
    Duplex: Full
    Port: FIBRE
    PHYAD: 0
    Transceiver: external
    Auto-negotiation: on

Continue reading

从 ubuntu 到 redhat

这里说的是我们的生产系统(server),而非个人的笔记本(desktop)。做这个决定由来已久。之前写过一篇博客,总结了自使用了 [email protected] 机器上出现的诸多问题,再加上 ubuntu 没有专业的支持(发布的时候发现目前 ubuntu 已经有专业的技术团队支持了, ubuntu advantage),有问题只能去 launchpad 上提 issue,能不能解决还是另外一回事,如果遇到一些 kernel panic,比如之前我们线上机器遇到的 208 天宕机这类及其严重的事故,这对一个线上的系统来说绝对是一个非常大的打击。之后,我们着手调研了两大商业系统,redhat 以及 suse,由于之前没有正式的使用过,再加上我司一贯的作风,人少(我一个全职带人)事多(负责从上架到下架的所有过程包括周边的 IDC 等),因此我们更多的是通过同行之间的交流获取到的一些信息。另外,好歹当年我也是满分通过的 RHCE,对 redhat 还是有一些感情的。所以,最终我们决定使用 redhat,我们挑选了某个业务的一小部分集群做线上的测试,使用了大半年的时间,除了遇到过几次 panic,其他的都比较稳定,再加上 redhat 售后技术支持的给力工作,尤其是海外的团队专业专注,几个 panic 都得到了比较好的解决;一些日常的小问题提交到其 portal 上也能得到很快的回复解决。总体说来,这是一次比较成功的转变。
当然,我们绝对不是说 ubuntu 不好,只能说是适用场景不同。对于一个刚孵化的公司,使用 ubuntu server 绝对是一个很好的选择,就像我们初期那样,0 成本(费用,这个对刚开始创业的公司是一个非常重要的因素),社区丰富,上手快,仅这几点就有足够的吸引力了。然而,当一公司进入了快速成长的阶段,发展到了一定的规模,需要的是更加的稳定的对外服务、出现问题的及时解决以及一对一的更加有效的服务,这时候选择 redhat/suse 就是一个比较好的方式,因为通过花费一定的费用,可以得到令人满意的服务,这个服务最终的是体现在出现问题后的及时有效的解决以及各种软件包的推送更新(主要是安全方面)。
再扯一句,说到系统的定制,我认为,除非你的机器数量超过 5 位数,做系统的定制甚至是内核的定制,对于业务的提升有帮助,哪怕只有 1% 的提升,从单台机器的角度看没什么大不了,但是放大到一万台,十万台,效果显而易见,最终解决的就是成本,说白了就是白花花的银子。但是如果规模只有数百台或者只有数十台,那就完全没有必要了,有这个空去做那百分之几的提升,不如花更多的时间放在核心业务的稳定高效上。

下面谈正题,在我们正式投入使用之前,有差不多一个月的测试时间,从机器的下单,到远程卡配置 RAID 建立 BIOS 升级、系统安装服务部署监控系统等,在此期间还是遇到了一些问题。这篇博客主要涉及的是 redhat 系统本身的一些问题。相对底层的会在系统部署的这一阶段通过 cobbler 的 snippet 解决,而比较上层的则通过 puppet, saltstack 解决。

Continue reading