在 KVM 上访问 Linux 虚拟机终端

用 OpenNebula 制作 Ubuntu 镜像后可以用这个镜像当作模版来创建 OpenNebula 虚拟机,发现一个问题是,这个 KVM 虚拟机(guest)无法在母机(host)上用 virsh console 登陆和显示终端,这是因为那个模板没有引入 console 需要的参数,而且虚拟机里面也没有做相关的设置。解决办法分两步,首先登陆到虚拟机修改一些配置;然后在运行这个虚拟机的 KVM 节点(host)上修改虚拟机的 xml 配置文件。以下介绍虚拟机是 Ubuntu 和 CentOS 的两种配置情况,FreeBSD 配置情况可以参考:在 KVM 上访问 FreeBSD 虚拟机终端

在 Ubuntu Guest 上配置

登陆 ubuntu 虚拟机增加 ttyS0.conf 文件及其内容:

$ sudo vi /etc/init/ttyS0.conf
# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -L 38400 ttyS0 vt102

如果不只是希望 Linux login 后看到终端,也希望看到 Linux 的启动过程的话需要在 /etc/default/grub 加入 GRUB_CMDLINE_LINUX 一行,记得运行 update-grub2 自动配置 grub:

$ sudo vi /etc/default/grub
...
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"
...

$ sudo update-grub2

在 CentOS Guest 上配置

在 /etc/securetty 文件末尾追加 ttyS0 一行:

# echo “ttyS0″ >> /etc/securetty

在 /etc/grub.conf 文件里的 kernel 一行增加 console=ttyS0:

# vi /etc/grub.conf
...
title CentOS (2.6.32-220.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_roo
ot rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarr
cyrheb-sun16 rhgb crashkernel=auto quiet rd_LVM_LV=VolGroup/lv_root  KEYBOARDTYPP
E=pc KEYTABLE=us rd_NO_DM console=ttyS0
        initrd /initramfs-2.6.32-220.el6.x86_64.img
...

在 /etc/inittab 中增加 ttyS0 一行:

# vi /etc/inittab
...
S0:12345:respawn:/sbin/agetty ttyS0 115200

在 KVM Host 上配置

登陆 KVM 母机(host)用 virsh edit 修改虚拟机的 KVM 启动配置文件,在 device 下面加上 serial 一栏:

# virsh list
Id Name State
----------------------------------
49 one-28 running

# virsh edit one-28
...
<device>
...
    <serial type='pty'>
        <target port='0'/>
    </serial>
    <console type='pty'>
        <target type='serial' port='0'/>
    </console>
...
</devices>

修改后重启 libvirtd,并手动关闭和启动虚拟机:

# /etc/init.d/libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# virsh shutdown one-28
# virsh start one-28

Linux 服务器因 CPU 温度过高自动 shutdown

昨天一台 Linux Xen 服务器莫名其妙就不能访问了,开始以为又碰到 server kernel: ip_conntrack: table full, dropping packet. 问题,没仔细看。后来过了2个小时又不能访问了,看了一下日志是服务器自己 shutdown 了,不是网络的问题。再看日志发现错误信息:

Nov 24 05:32:22 ivps kernel: ACPI: Critical trip point
Nov 24 05:32:22 ivps kernel: Critical temperature reached (76 C), shutting down.

原因是 CPU 温度过高超过了警戒温度,查一下系统默认的警戒温度是75度,所以到了76度系统就自动 shutdown 了:

# cat /proc/acpi/thermal_zone/THRM/trip_points 
critical (S5):           75 C

服务器温度有这么高吗?查看一下当前温度吓一跳,刚启动的系统又到了74度,系统马上又要 shutdown 了:

# cat /proc/acpi/thermal_zone/THRM/temperature 
temperature:             74 C

紧急做法是暂时修改默认报警温度到85度:

# echo 85:0:80:60:0 > /proc/acpi/thermal_zone/THRM/trip_points

# cat /proc/acpi/thermal_zone/THRM/trip_points 
critical (S5):           85 C

一般来说 CPU 温度超过70度都是很高的温度了,如果不是系统和程序的原因要赶紧检查服务器周围的环境,检查机房和机柜温度情况、服务器风扇、内部积灰等,让 CPU 和主板长时间工作在高温下可不是好事情。当然不同 CPU 所能耐的住的温度也不同,VPSee 推荐 Intel Core 2 Quad CPU 保持在70度以下,Intel Core i7 CPU 保持在80度以下,这样 CPU 和系统能全速工作发挥最大效率而温度又不至于损坏 CPU.

服务器出现 server kernel: ip_conntrack: table full, dropping packet. 问题

昨天上午挂在 VPSee 桌子旁边墙壁上的老古董 IBM TP600E 终于发挥作用,连续报警,监视显示某台服务器丢包非常严重,甚至大多时候不能访问,终端登录系统后检查日志发现 ip_conntrack: table full, dropping packet. 错误:

# vi /var/log/messages
...
Nov  8 08:54:58 server kernel: ip_conntrack: table full, dropping packet.
Nov  8 08:55:03 server kernel: printk: 49 messages suppressed.
Nov  8 08:55:03 server kernel: ip_conntrack: table full, dropping packet.
Nov  8 08:55:08 server kernel: printk: 49 messages suppressed.
...

查看当前 ip_conntrack 记录,已经有 36271,超过了系统设置的 16640 (ip_conntrack_max 默认设置为系统内存(MB 为单位)的 16倍):

$ head /proc/slabinfo 
slabinfo - version: 2.1
# name                 : tunables    : slabdata   
ip_conntrack_expect      0      0    192   20    1 : tunables  120   60    8 : slabdata      0      0      0
ip_conntrack        36271  36216    384   10    1 : tunables   54   27    8 : slabdata   1612   1612    108

# cat /proc/sys/net/ipv4/ip_conntrack_max
16640

kernel 用 ip_conntrack 模块来记录 iptables 网络包的状态,并保存到 table 里(这个 table 在内存里),如果网络状况繁忙,比如高连接,高并发连接等会导致逐步占用这个 table 可用空间,一般这个 table 很大不容易占满并且可以自己清理,table 的记录会一直呆在 table 里占用空间直到源 IP 发一个 RST 包,但是如果出现被攻击、错误的网络配置、有问题的路由/路由器、有问题的网卡等情况的时候,就会导致源 IP 发的这个 RST 包收不到,这样就积累在 table 里,越积累越多直到占满,满了以后 iptables 就会丢包,出现外部无法连接服务器的情况。

知道问题就好办了,要么增加 table 容量以便能记录更多的连接信息(会消耗一点内存),要么就卸载 ip_conntrack 模块。

查看当前 ip_conntrack_max 设置,然后增加两倍到 131072:

# cat /proc/sys/net/ipv4/ip_conntrack_max
16640

# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max
或者
# sysctl -w  net.ipv4.netfilter.ip_conntrack_max=131072

还有一个参数 ip_conntrack_tcp_timeout_established 需要注意,默认情况下 timeout 是5天(432000秒),需要的话可以减半:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 
432000

# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=216000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 216000

综合一下,最好把这些内核参数加到 sysctl.conf 文件以便系统启动后自动读取中:

# vi /etc/sysctl.conf
...
net.ipv4.netfilter.ip_conntrack_max = 131072
net.nf_conntrack_max = 131072
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 216000

还有一种办法就是直接卸载 ip_conntrack 模块,这个办法最简单,到在 /etc/sysconfig/iptables-config 文件里删除或者注释掉 ip_conntrack_netbios_ns 后重启系统:

# vi /etc/sysconfig/iptables-config
#IPTABLES_MODULES="ip_conntrack_netbios_ns"

# shutdown -r now

Linux Then and Now

今年 Linux 满20周年,Linux Foundation 做了个漂亮的图片,从 LinuxConf 2011 与会人员的调查数据来看有个惊讶的地方是选择 ArchLinux 版本的人(选择 Other 的人几乎填的都是 ArchLinux)仅次于 Ubuntu 和 Fedora/Redhat,居然用的人比 Debian 还多?!

linux then and now

定期清理和保留 history 记录

有经验的 Linux 系统管理员都喜欢把 Bash 的 HISTSIZE/HISTFILESIZE 设置的很大,这样可以记录更多的历史命令以便以后查阅,这是个好习惯,有个小问题就是 history 记录了的大量信息在系统启动后就被 load 到内存里,并且一直保存在内存里,这样浪费了不少内存,据统计100000条历史记录大概占用 10MB 左右的内存。对于优化过的 64MB/128MB 小内存 VPS 来说 10MB 的可用内存可以干很多事情,比如启用一个 MySQL 服务,开多个 Nginx/PHP-CGI,开个 syslogd, openvpn 等,把 10MB 留给 history 实在太浪费。那么如何保存尽量多的历史记录而又不浪费内存呢?一个办法就是把历史记录定期保存到硬盘上,bash 的当前历史记录保存在 .bash_history 里,只要定期清理这个文件的记录就可以了:

#!/bin/bash
# archive linux command history files
# written by vpsee.com

umask 077
maxlines=2000

lines=$(wc -l < ~/.bash_history)

if (($lines > $maxlines)); then
    cut=$(($lines - $maxlines))
    head -$cut ~/.bash_history >> ~/.bash_history.sav
    sed -e "1,${cut}d"  ~/.bash_history > ~/.bash_history.tmp
    mv ~/.bash_history.tmp ~/.bash_history
fi

上面脚本所做的事情很简单,检查 .bash_history 文件,如果行数超过2000行就剪裁2000行记录并添加到 .bash_history.sav 这个文件里,这样我们就可以保存所有的历史记录,而且当前的历史记录不超过2000行,只占用少量资源。

如何查看 Linux 系统安装的时间

我们 SUN 实验室每台服务器上架后都需要填写一个表格,这个表格包括详细的机器硬件配置、操作系统版本和安装时间、网络配置、机器名、MAC 地址和 IP、安装的软件和用途、安全级别和策略、联系人、上架时间、机柜号等。昨天有位管理员忘了填写操作系统的安装时间,跑来问怎么查看 Linux 系统的安装日期和时间(过了2个月谁还记得啊)。

有个办法是查看 lost+found 目录状态,因为这个目录一般很少用到,改动最少(很可能无任何改动),而其他目录比如 /bin, /home 等因为经常升级系统、创建用户等操作会修改目录状态。VPSee 在自己的一台 VPS 结点服务器上验证了一下,这台服务器是去年3月10日安装的系统,中途升级系统重启一次,然后连续满负荷跑了342天没有重启

$ stat /lost+found/
  File: `/lost+found/'
  Size: 16384     	Blocks: 32         IO Block: 4096   directory
Device: 805h/2053d	Inode: 11          Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-03-11 02:40:20.000000000 -0800
Modify: 2010-03-10 19:14:34.000000000 -0800
Change: 2010-03-10 19:14:34.000000000 -0800

还有一种办法是查看 bin, daemon, sys, adm 等这些帐号的建立时间,这些帐号是在系统安装的时候创建的,所以这些帐号的创建时间基本上就是 Linux 系统的安装时间:

# passwd -S bin
bin LK 2010-03-10 0 99999 7 -1 (Alternate authentication scheme in use.)

# passwd -S daemon
daemon LK 2010-03-10 0 99999 7 -1 (Alternate authentication scheme in use.)

上面这个看帐号创建时间的方式有局限性,不同的 Linux 发行版安装的时候处理 bin, daemon 这些系统帐号的方式不同,有的是直接从安装光盘拷贝这些帐号和相关文件,有的是安装脚本自动创建。只有安装脚本自动创建的发行版本才能根据帐号的创建时间来判断系统的安装时间。

/proc/cpuinfo 里的 CPU flags

Linux 上的 /proc是一个虚拟文件系统,在系统启动后挂载在 /proc 上,/proc 包含了很多内核和系统信息用来展示 Linux 内核是如何展示硬件的,比如在 /proc/cpuinfo 里可以看到一些关于 CPU 的信息,其中的 flags 包含了很多用来表示 CPU 特征的参数:

$ cat /proc/cpuinfo | grep flags
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts 
acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 
sse4_2 popcnt lahf_lm arat tpr_shadow vnmi flexpriority ept vpid

具体每个 flag 缩写代表什么意思呢?关于 Linux 的最权威答案永远来自源代码,VPSee 在内核源代码里找到了每个 flag 的相关注释,通过这些注释可以很方便我们理解这些 flags 缩写:

# vi /home/vpsee/linux-2.6.31.8/arch/x86/include/asm/cpufeature.h
...
/* Intel-defined CPU features, CPUID level 0x00000001 (edx), word 0 */
#define X86_FEATURE_FPU         (0*32+ 0) /* Onboard FPU */
#define X86_FEATURE_VME         (0*32+ 1) /* Virtual Mode Extensions */
#define X86_FEATURE_DE          (0*32+ 2) /* Debugging Extensions */
#define X86_FEATURE_PSE         (0*32+ 3) /* Page Size Extensions */
#define X86_FEATURE_TSC         (0*32+ 4) /* Time Stamp Counter */
#define X86_FEATURE_MSR         (0*32+ 5) /* Model-Specific Registers */
#define X86_FEATURE_PAE         (0*32+ 6) /* Physical Address Extensions */
#define X86_FEATURE_MCE         (0*32+ 7) /* Machine Check Exception */
#define X86_FEATURE_CX8         (0*32+ 8) /* CMPXCHG8 instruction */
#define X86_FEATURE_APIC        (0*32+ 9) /* Onboard APIC */
#define X86_FEATURE_SEP         (0*32+11) /* SYSENTER/SYSEXIT */
#define X86_FEATURE_MTRR        (0*32+12) /* Memory Type Range Registers */
#define X86_FEATURE_PGE         (0*32+13) /* Page Global Enable */
#define X86_FEATURE_MCA         (0*32+14) /* Machine Check Architecture */
#define X86_FEATURE_CMOV        (0*32+15) /* CMOV instructions */
                                          /* (plus FCMOVcc, FCOMI with FPU) */
#define X86_FEATURE_PAT         (0*32+16) /* Page Attribute Table */
#define X86_FEATURE_PSE36       (0*32+17) /* 36-bit PSEs */
#define X86_FEATURE_PN          (0*32+18) /* Processor serial number */
#define X86_FEATURE_CLFLSH      (0*32+19) /* "clflush" CLFLUSH instruction */
#define X86_FEATURE_DS          (0*32+21) /* "dts" Debug Store */
#define X86_FEATURE_ACPI        (0*32+22) /* ACPI via MSR */
#define X86_FEATURE_MMX         (0*32+23) /* Multimedia Extensions */
#define X86_FEATURE_FXSR        (0*32+24) /* FXSAVE/FXRSTOR, CR4.OSFXSR */
#define X86_FEATURE_XMM         (0*32+25) /* "sse" */
#define X86_FEATURE_XMM2        (0*32+26) /* "sse2" */
#define X86_FEATURE_SELFSNOOP   (0*32+27) /* "ss" CPU self snoop */
#define X86_FEATURE_HT          (0*32+28) /* Hyper-Threading */
#define X86_FEATURE_ACC         (0*32+29) /* "tm" Automatic clock control */
#define X86_FEATURE_IA64        (0*32+30) /* IA-64 processor */
#define X86_FEATURE_PBE         (0*32+31) /* Pending Break Enable */

/* AMD-defined CPU features, CPUID level 0x80000001, word 1 */
/* Don't duplicate feature flags which are redundant with Intel! */
#define X86_FEATURE_SYSCALL     (1*32+11) /* SYSCALL/SYSRET */
#define X86_FEATURE_MP          (1*32+19) /* MP Capable. */
#define X86_FEATURE_NX          (1*32+20) /* Execute Disable */
#define X86_FEATURE_MMXEXT      (1*32+22) /* AMD MMX extensions */
#define X86_FEATURE_FXSR_OPT    (1*32+25) /* FXSAVE/FXRSTOR optimizations */
#define X86_FEATURE_GBPAGES     (1*32+26) /* "pdpe1gb" GB pages */
#define X86_FEATURE_RDTSCP      (1*32+27) /* RDTSCP */
#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */
#define X86_FEATURE_3DNOWEXT    (1*32+30) /* AMD 3DNow! extensions */
#define X86_FEATURE_3DNOW       (1*32+31) /* 3DNow! */
...

/* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
...
/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */
...
/* More extended AMD flags: CPUID level 0x80000001, ecx, word 6 */
...

仅有 flags 缩写和注释不足以理解 flag 的含义,但是足够发挥个人的 googleability 了,比如直接搜索 msr 不会得到任何有用信息,但是利用上面的注释搜索 Model-Specific Registers(google “Model-Specific Registers”)就会得到很多信息,学习的过程就是不断提高 googleability 的过程:)

超级计算机11月数据统计

一年前讨论 Linux 发行版的时候提到了一些超级计算机的数据,今年6月份数据有点变化,这次刚发布的11月份超级计算机统计报告的亮点依然是中国,中国的 “天河1A” 第一次拿到冠军宝座,并且前十占有两个席位,排名都很靠前(第一和第三),6月份中国有24台超级计算机上榜,按照国家排名与德国并列第四,这次有42台计算机进入 Top500,仅次于美国。上次上榜的超级计算机的处理能力加起来中国排名第二,这次不管是计算机处理能力还是上榜的超级计算机台数都跃升为第二,短短6个月就造了18台超级计算机并进榜,非常惊讶,难道开始造航母了?(新浪:中国造航母须具备五大科技能力 超级计算机居首

还有一个亮点值得讨论的地方是 Amazon 的云计算集群计算系统(Amazon EC2 Cluster, Xeon X5570 2.95 Ghz, 10G Ethernet)进入 Top500,排名第231位,这是云计算的一次非常大的尝试和进步,VPSee 去年还讨论了 “云计算可以用来替代高性能计算吗?”,当时云计算的性能远远没有达到高性能计算(HPC )的要求,时过一年居然就上了榜,现在普通人用信用卡就可以用上超级计算机服务,这在以前是不敢想象的事情,会不会有人利用这种云计算 HPC 破译密码呢?

Linux 依然是超级计算机的绝对主力,对比6月份数据发现 Linux 总体上升5台,牢牢占有82%的份额,其中 CentOS 上升1台,SLES 9 下降1台,SLES 10 下降2台,SUSE/openSUSE/SLES 系还在下降。以下数据来自:Top 500 Super Computer Sites

操作系统版本 使用的个数 所占百分比 处理器个数
Linux(未知版本) 410 82.00 % 4540212
SLES 9 4 0.80 % 59504
CNK/SLES 9 14 2.80 % 1134592
SUSE Linux 1 0.20 % 26304
Redhat Linux 4 0.80 % 48800
RedHat Enterprise 4 3 0.60 % 14736
UNICOS/SUSE Linux 1 0.20 % 8192
SLES 10 2 0.40 % 14328
SLES10 + SGI ProPack 5 15 3.00 % 135200
RedHat Enterprise 5 2 0.40 % 11928
CentOS 8 1.60 % 114792

限制 Linux 用户的进程数

我们这两天监测到一位客户的 VPS 持续维持 100% 的 CPU 利用率很长一段时间,然后昨天客户向我们报告他的 VPS 无法登录了,从我们这边来看他的 VPS 正在运行,而且网络也有反应,只不过 CPU 利用率满负荷而已,VPSee 收到客户消息的第一反应是客户的 VPS 被 CC (Challenge Collapsar) 攻击了,后来客户告诉我们他没有做网站,只是开了一些 shell 帐号供别人通过 ssh 使用,这有可能是其中某个帐号(被黑了以后)放了 fork 炸弹,这是非常简单而且很常用的一类恶意程序,原理很简单,就是通过不停的 fork 进程来达到消耗 Linux 系统所有资源的目的,使得系统无法(没有资源)运行其他程序。比如被 fork 炸了以后,就会出现:

-bash: fork: retry: Resource temporarily unavailable

下面就是一个最简单的 bash fork 炸弹:

: () { : | : & } ; :

上面几个符号看上去很复杂,其实如果写成下面这个样子就好懂了,: 是函数名,执行一个调用自己的递归并且 pipe 到自己,& 表示后台执行程序,最后的一个 : 是在函数外调用和执行 : () 这个函数的意思:

: () {
    : | : &
}; :

如何避免 fork 炸弹呢?方法很简单,只要限制每个用户可以调用的进程数就可以避免,这个可以通过修改 vi /etc/security/limits.conf 文件来设定:

# vi /etc/security/limits.conf

vpsee           hard    nproc           32
@student        hard    nproc           32
@faculty        hard    nproc           64

上面的配置文件意思是说限制 vpsee 这个用户只能 fork 32 个进程;然后限制 student 这个用户组的每个成员最多能 fork 32 个进程;限制 faculty 这个用户组的每个成员最多能 fork 64 个进程。不过要事先检查系统是否有 pam_limits.so 这个模块以及是否已经加载:

# ls /lib64/security/pam_limits.so 
/lib64/security/pam_limits.so

# vi /etc/pam.d/login
session    required     pam_loginuid.so

如果自己是 Linux 普通用户,不是 root 用户不能修改 limits.conf 和重启系统的话,可以用 ulimit 来临时限制自己允许创建的进程数,ulimit 有 Hard 和 Soft 两种方法限制,用 Hard 的话可以减少最大可用的进程数,但是就不能重新增大这个限制了;用 Soft 的话可以自己自由增大和减小限制(ulimit,-H 和 -S 的详细说明可以参看 man ulimit)。不同的 Linux 版本对这个 ulimit -u 的默认值不同,在 CentOS 上默认情况下最大运行进程数是 8256,在 Fedora 上是 1024,所以这个要看不同的发行版本,不过这个无所谓,反正可以改,不过改成32后就不能再改成比32更大的了(比如64),只能再改成比32小的,ulimit 不带 -H 和 -S 参数的时候同时设置 Hard 和 Soft:

$ ulimit -u
8256
$ ulimit -u 32
$ ulimit -u 64
-bash: ulimit: max user processes: cannot modify limit: Operation not permitted

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8256
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 32
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Bloglines 的技术选择和经验

VPSee 以前常用 Bloglines 的 RSS 阅读器订阅一些博客,后来改成 Google Reader 用了一段时间,再后来干脆直接在 Mac 上装个 NetNewWire 客户端,并且可以和 Google Reader 同步,非常方便阅读和管理。这篇文章介绍了 Bloglines 创始人 Mark Fletcher 的的一些创业经验、技术选择和架构等,值得学习学习,特别是对一边工作一边创业的小团队来说。

Bloglines 是典型的车库文化,Mark Fletcher 当初是一边干着正式的工作一边开始自己的创业的,硅谷有很多 startup(创业公司)都是这样起步的,这是包括著名高科技风险投资公司 Y Combinator 创始人 Paul Graham 在内的很多创业大师都推荐的创业方式,在确定自己的创业/赚钱想法可行之前保持稳定的收入来源,这样有助于减少创业的风险和压力,毕竟不是每个人都是 Bill Gates,不是每个人都可以放弃大学或工作开始创业并取得成功的。让人惊奇的是,Bloglines 2005年卖给 Ask.com 的时候还不到10个人。遗憾的是,Ask.com 决定将在今年的10月1日关闭 Blogline.

创业经验

  • 激情,因为这辈子大部分时间都会花在工作和事业上,如果对自己所做的事情没有兴趣和激情的话是不可能坚持到最后的;
  • 采用廉价的技术,现在是互联网创业的好时候,硬件和软件(开源)越来越便宜;
  • Keep it simple,保持简单,使用简单的技术并让为用户觉得简单;(把简单的事情做好就是不简单
  • 夜晚工作,使用自己晚上或者周末的时间工作在自己的创业项目上,从亲朋好友那里寻找资金,免费的服务=更少的压力,免费服务 down 几个小时不会有人抱怨;
  • 雇佣一个律师
  • Web services API 是个好东西
  • 寻找帮助(尤其需要找个好的系统管理员)
  • 考虑外包(eLance.com)

软件选择

  • DBJ (http://cr.yp.to), qmail, djbdns, daemontools
  • ClearSilver (web templating package)
  • Berkeley DBs
  • Linux/Apache
  • C/C++/Bash/Python
  • Skiplist data structure(一个数据结构算法)
  • 避免使用 NFS
  • 避免在 MySQL 中使用表级别的锁,因为不 scale

硬件选择

  • 是租用独立服务器还是托管呢?Bloglines 选择了租用,起步的费用更少;
  • 一切为廉价硬件设计,Google 就是个用廉价硬件搭建服务器集群的好例子;
  • eBay 是个买便宜硬件的好地方;
  • APC PDUs;
  • HP ProCurve 很不错;
  • 避免使用 Seagate Ultra-SCSI 硬盘;
  • 一个有好的 ssh 客户端的手机,这样可以在任何地方 ssh 到服务器上。

存储选择

  • 关系数据库 vs. 文件,他们的所有博客文章都采用文件方式存储;
  • RAID vs. Redundant,他们在所有机器上都保留博客文章副本,如果一台机器 down 了不影响访问;
  • Linux software RAID 1,非常稳定。

系统管理

  • 网站服务器采用 DNS round robin,不必设置负载均衡;
  • 采用热备份冷处理,每小时备份,但是到线下再处理数据(比如 RSS 的订阅数可以每天线下统计,不必即时统计);
  • 小心服务器温度,如果硬盘出问题,可能是服务器过热、温度不适造成的。