今天早上在 Xen 服务器上增加一个 domU 虚拟机的时候遇到一个问题：

# /usr/sbin/xm create vm05
Using config file "/etc/xen/vm05".
Error: Device 2049 (vbd) could not be connected. Failed to find an unused loop device

上面错误显示没有找到可用的 loop device，可能是当前使用的内核版本或者内核配置对 loop devices 有最大数目的限制，查看一下当前正在使用的的 loop devices：

# /sbin/losetup -a
/dev/loop0: [fd00]:32014427 (/vm/vm01.swap)
/dev/loop1: [fd00]:44105729 (/vm/vm01.img)
/dev/loop2: [fd00]:32014432 (/vm/vm02.img)
/dev/loop3: [fd00]:32014433 (/vm/vm02.swap)
/dev/loop4: [fd00]:32014429 (/vm/vm03.swap)
/dev/loop5: [fd00]:43057161 (/vm/vm03.img)
/dev/loop6: [fd00]:1376674 (/vm/vm04.img)
/dev/loop7: [fd00]:32014428 (/vm/vm04.swap)

CentOS/RHEL 5

在 CentOS/RHEL 5 系统上默认的 active loop devices 数目是8，如上面看到的 loop0-loop7，只创建了4个 vm，用到了8个 loop devices，4个用来挂载 os image，4个用来挂载 swap image. 对于基于 file 的 Xen OS image 来说，需要修改这个默认值以便获得更多的 loop devices 挂载更多的 image. 编辑 /etc/modprobe.conf 来修改 active loop devices 最大限制数目：

# vi /etc/modprobe.conf
options loop max_loop=64

CentOS/RHEL 6

在 CentOS/RHEL 6 系统上更改 loop 最大数目更容易，最多支持256个，还不用重启：

# MAKEDEV -v /dev/loop

不过上面更改重启就会消失，所以把上面命令要加到 /etc/rc.local 里：

# vi /etc/rc.local
...
MAKEDEV -v /dev/loop

Ubuntu/Debian

在 Ubuntu/Debian 上修改默认 loop devices 最大限制数目：

# echo 'options loop max_loop=64' >/etc/modprobe.d/loopdev

Xen Dom0 需要多大内存来支持各个 DomU 的正常运行要看具体情况，没有一个 magic formula （神奇公式）可以参考；而 Xen DomU 需要多大内存能正常运行则主要取决于运行在 DomU 上的 Guest OS 及应用的需求。

DomU

给 DomU 安排内存较简单，主要看什么样的 Guest 操作系统以及上面跑什么样的应用，复杂的图形桌面系统、还是简单的 Web 服务器，这里有一些操作系统厂商提供的推荐配置：

• 根据 Ubuntu 官方文档 推荐的最小内存配置，运行 Ubuntu 9.04 Desktop 版本和 GNOME/KDE 等完整桌面图形系统，最小建议 384MB，我试过 256MB，可以运行，速度也可以，但是可用内存剩下不多，已经开始频繁 swap 了；如果使用中量级窗口管理器，像 xfce，最小建议 192MB；使用类似 fvwm/fluxbox/twm/icewm 等轻量级窗口管理器或者完全使用命令行，最小建议 64MB. 运行 Ubuntu 9.04 Server 版本，不用 GUI，最小安装，完全当作服务器使用，最小可以小到 32MB，不过 VPSee 推荐至少 64MB 才可以运行一个由 mysql/php/nginx 支持的小网站、博客。
• 运行 CentOS 5.3 需要的内存要多一些，不用 GUI，最小安装，完全当作服务器使用，RedHat 推荐最小内存是 256MB；VPSee 推荐最小建议 128MB，我试过 64MB 虽然可以运行，但是明显感到慢，使用 yum 升级就能感觉到，就不用提 mysql/php/nginx 了，就算能运行起来也没多大实际意义。
• Debian 5.0 的内存需求和 Ubuntu 类似，稍微可以偏低一些。
• Gentoo 官方推荐最小 64MB，但是每次升级系统都需要编译，即使可以在 64MB 下安装运行意义也不大，因为每次升级软加包都需要下载代码编译，编译需要消耗大量 CPU 和内存。这也是 VPSee 不推荐在小 VPS 上使用 Gentoo 的原因。
• Freebsd 官方推荐最小 24MB，同样的主要看应用，对于一个 mysql/php/nginx 应用，VPSee 推荐 64MB.

Dom0

为 Dom0 配置内存要稍微复杂一些，配置多了 DomU 可使用的内存就少了，配置少了就会担心 Dom0 不够用。有效限制 Dom0 的内存大小还有助于安全。假设 Dom0 本身不做任何其他的应用（当然也不包括 GUI）。如何分配内存让 Dom0 的内存最小而且又能最有效的管理那些 DomU 呢？ Running Xen: A Hands-on Guide to the Art of Virtualization 这本书介绍了一些有用的经验，给 Dom0 分配多大内存没有一般公式可循，只能提供一些经验参考：

1. 首先看 Dom0 上运行的 OS 对内存的需求怎么样，比如：Dom0 上如果跑的是 CentOS，这样 Dom0 通常最低需要 128MB，如果是 Debian 可能最低需要 64MB；
2. 再看看需要一些什么样的服务，比如可能会在 Dom0 上运行 DNS/DHCP/SSH 之类的服务来支持 DomU；
3. 可能需要在 Dom0 上做一些日常维护，比如：备份、管理 DomU、升级、运行一些 shell script、检查日志等，这会需要一些内存运行；
4. DomU 与外界网络通信需要与 Xen 虚拟出来的网卡打交道，比如：bridge，routing，firewall 什么的，Dom0 要管理这些需要消耗一些内存；
5. 为了保障安全，最好最小化 Dom0 的功能，最小化安装，只启动必须的服务，让 Dom0 只负责管理 DomU，最小化的策略还可以增加整个服务器的安全性。

举个实例，对于一个 2G 的双核机器来说，如果 Dom0 只是用来管理 DomU，给 Dom0 配置 128-256MB的内存就可以了，剩下的内存可以分出10-15个 128MB 的 DomU.

今天有人跑来实验室抱怨说给他们配置的 4GB Xen 虚拟硬盘太小，系统占了 2GB，再装一些工具，比如 jdk/mysql/tomcat/red5/asterisk 之类的空间就不够了。如何增加 Xen 虚拟硬盘的大小呢，也就是说如何扩充 Xen 的镜像文件大小呢？（这里的方法适用于镜像文件在 ext2 和 ext3 文件系统的情况）

关闭虚拟机：

# /usr/sbin/xm shutdown vm01

给虚拟机镜像文件（.img）追加 4GB 空间：

# dd if=/dev/zero bs=1024k count=4096 >> /vm/vm01.img

扫描检查镜像文件：

# /sbin/e2fsck -f /vm/vm01.img

这个时候只是增加了镜像文件（硬盘）的大小，这个镜像文件不是普通的文件，里面包含可 mount/umount 的 loop 文件系统，所以需要调整文件系统大小，不然的话进入虚拟机后 df 会发现硬盘大小没变：

# /sbin/resize2fs /vm/vm01.img

重新启动 Xen 虚拟机：

# /usr/sbin/xm create vm01

进入虚拟机后查看硬盘大小：

# /usr/sbin/xm console vm01
# df -h

这里提到了 mount/umount，说一点题外话，从技术角度来说现在的 VPS 其实都不安全，因为 VPS 服务商随时可以 mount/umount 你的虚拟机文件、分区来读取、甚至写入内容，如果你的虚拟机所在的那台服务器的 root 密码被坏人拿到，那就毫无安全可言了，坏人可以随意在你虚拟机上做手脚。所以说安全性是云计算的一个大问题，尤其是那些搭建在虚拟技术上的云计算，这也可能是企业迟迟不愿意使用公有云的原因吧，一些 Startup 也只是把不重要的数据放在类似 Amazon S3 之类的云存储上，对于机密数据还是自己保存比较好。所以 VPSee 认为私有云会有更大的发展空间。

这个周末看了一篇关于快速克隆 Virtual Machine（VM）的文章，SnowFlock: Rapid Virtual Machine Cloning for Cloud Computing。SnowFlock 是 University of Toronto 的一个项目，核心想法是把 Unix 操作系统中 fork 的概念引入到云计算，不过不是用来 fork 进程，是 fork 虚拟机，这个 fork 与原始的 Unix fork 有几点不同：

1、VM fork 可以 fork 到其他物理机器上，Unix fork 只能在本机操作系统内 fork；
2、parallel fork，一次 fork 调用可以创建多个 child VMs；
3、VM fork 从 parent VM 那里复制所有的进程和线程。

SnowFlock 从不同的物理机器上 fork 出相同的 VM，这些 VMs 连在一起构建一个私有 cluster，拥有自己的虚拟网络。SnowFlock 根据计算的需要分配计算资源，从众多的物理机器中创建一个合理大小的 Xen VM Cluster，由这个 cluster 来完成目标计算，完成计算后，这个 cluster 就自动消失了。

把 Unix 中的 fork 概念用到云计算 VM 克隆中是个很有意思的想法，SnowFlock 如何做到快速克隆呢？做到 fork 并不难，最土的想法就是 fork 时利用虚拟机的 suspend/resume 功能，把 VM suspend 后将整个 VM 文件拷贝到别的机器上然后 resume 运行。但是这个过程太慢，在 VPSee 的 Mac 上 suspend 一个 vmware 虚拟机大概需要 30秒，又需要另外 30秒 resume。SnowFlock 克隆 VM 只需要不到1妙，它是如何做到这点的？

1、VM 文件里包含 memory image，disk image，各种状态、配置信息等，SnowFlock 只复制必要的状态信息（VM descriptor），这样就不必复制包含整个操作系统在内的 VM 文件，如果 disk image 设的是 10GB，那就不必复制 +10GB。Memory-On-Demand 允许 child VM 只在需要某个 memory 页面的时候才去 parent VM 那里克隆，可以在 fork 后进行，减少了初始克隆 VM 的体积；
2、VM 克隆的时候不必克隆所有的 memory image，只需要原始 image 中一小部分信息（Memory State），这又减少了需要克隆的体积；
3、child VM 可以在 fork 到其他机器上后再分配内存。如果先分配内存会造成 memory image 过大，影响克隆速度。如果 parent VM 分配了页面，比如 malloc，但是还没有用到这些页面、没有数据的话这些页面也用不必克隆到 child VM。还有一些可以循环使用的 kernel buffer 也不必克隆，，进一步减少克隆体积；
4、child VM 通常执行类似的代码和数据结构，如果 fork 多个 VMs 的话有助于 multicast；
5、把数据 multicast 给多个 VMs，只要有1个 VM 请求页面，这个页面也会被 multicast 给其他 VMs。一次操作就把数据分发给所有 VMs 还可以减少网络负载。

简单的说就是，尽可能减少 VM 携带的信息量来达到快速克隆的目的，这篇论文指出只需要克隆原 VM 0.1% 的信息就足够运行一个 child VM 了。SnowFlock 在 Xen 3 上实现了上述快速克隆的概念，具体实现过程很复杂，如有兴趣可参考论文和代码。SnowFlock 实现的简单图示：

（图片来自 SnowFlock 官方网站和资料。）

周末看了来两篇关于 Xen 的论文，一篇是 University of Cambridge 发表的 Xen and the Art of Virtualization；另一篇是 Clarkson University 的 Xen and the Art of Repeated Research。Repeated Research 这篇是对 Virtualization 那篇做的重复试验，两篇论文的测试数据相似，很好的证明了 Xen 的性能优势，并且回答了 VPSee 感兴趣的4个问题：

本文数据、部分结论和图片均来自以上两篇论文。

1、Xen 相对 Native，VMware 等来说性能好多少？
从理论来说，使用 para virtualization 技术的 Xen 要比使用 full virtualization 的 VMware 性能要好。测试的结果也证明了这个说法， Xen 相对 Native Linux 来说性能损失不大，相对 VMware 来说性能要好1倍左右。

2、Xen 适合做 Web/VPS Hosting 吗？
Xen 非常稳定、可靠，一个普通的服务器（如果内存够的话）完全能够承受16个左右的 DomU/VPS 同时运行，但是如果同时运行128个左右的虚拟系统的话性能会很差，即使内存、硬件配置足够。下图中随着 DomU 的增加，Xen 总体性能基本能和 Native 持平。很显然 Xen 等虚拟技术并不是用来提高整个服务器性能的，而是通过隔离操作系统来充分发挥每个 DomU 上的计算能力，相比独立服务器虚拟技术极大的节约了计算资源、电力、物理空间、管理维护、IP地址等，所以被称之为“绿色计算”。

3、Xen 能在一般老机器（5年左右）上运行吗？
可以，不但可以运行，而且运行得很好。在1台配置为 P3 1GHZ/512MB/40GB 的老机器上和1台 Xen 2.4GHz/2GB/146GB 的新机器上测试的结果显示，Xen 的性能损失比较稳定，与硬件配置好坏关系不大。也就是说在好机器上 Xen 的性能相对 native 来说损失是5%的话，那么在差机器上也相应损失5%，可以把 Xen 看作是真实硬件一样，随着硬件配置逐步升高相应性能也逐步提高。VPSee 做得简单测试显示有10%左右的性能损失。

4、Xen 在普通服务器上运行和在专门为虚拟设计的服务器上运行的差别？
就从性能方面来说，专门为虚拟环境设计的的 IBM zServer 服务器和普通的 Dell 服务器在相同硬件配置下性能基本没什么差别。但是就价格来说 zServer 要卖得要贵得多，这就是专门服务器专门的地方，卖的不是硬件配置，卖的是高可靠性、高扩展性、可管理性、可维护性等。

安装和配置完 Xen 后很好奇虚拟出来的系统性能怎么样，虚拟化后性能肯定会有牺牲。VPSee 决定做个简单的测试看看性能差多少。

测试环境

测试工具：unixbench-5.1.2

Native:
CPU：Dual-Core AMD Opteron(tm) Processor 1220, 2800 MHz
内存：2 GB DDR2/667 ECC RAM
硬盘：2×500G SATA II
操作系统：CentOS 5.3

Dom0:
CPU：2
内存：1.8 GB RAM
操作系统：CentOS 5.3

DomU:
CPU：1
内存：256MB RAM
操作系统：CentOS 5.3

下载 unixbench-5.1.2 解压后，打开 Makefile，找到 GRAPHIC_TESTS = defined 一行注释掉，不进行图像测试。

vi Makefile
#GRAPHIC_TESTS = defined

测试结果

继续阅读 »

现在实验室 Masters 都配有1台 PC 和 1台笔记本，但是 Honours 只配有1台 PC，1台机器做项目很不方便，开发经常会用到多系统，比如有的人做的是手机 VoIP 的相关项目，手机客户端界面要在 Windows 平台上做，VoIP 服务器端要用到 Linux，所以要用虚拟机虚拟一个 Linux 出来，如果这些都跑在一台物理机器上会很慢。现在给 Honours 配置的 PC 只有 1G 的内存，如果运行 Windows + 手机模拟器 + Elipse IDE（需要 Java）+ VMware（VMware 上再跑个 Linux + Asterisk + MySQL），然后开个客户端收邮件、开几个浏览器看资料就会很困难。

所以 VPSee 打算把自己在用的1台 SUN 服务器捐出来做成 Xen 服务器，给每个 Honours 分一个虚拟系统，省下他们自己装虚拟机的时间和资源，VPSee 成了免费的 Xen VPS provider 了：）。SUN 服务器上同时运行16个 Xen 虚拟系统实例，每个配 256 MB 内存，4GB 硬盘，不开 GUI。下面的安装步骤和配置过程是基于 CentOS 5.3 版本，Ubuntu 版本可以参看：在 Ubuntu 上安装和配置 Xen，Debian 版本参看：在 Debian 上安装和配置 Xen，OpenSolaris 版本参看：在 OpenSolaris 上安装和配置 Xen，NetBSD 版本参看：在 NetBSD 上安装和配置 Xen. 对 OpenVZ 和 KVM 感兴趣的童鞋可以看：在 CentOS 上安装和配置 OpenVZ 和 在 CentOS 上安装和配置 KVM.

安装 Xen

安装支持 Xen 的 Linux 内核 和 Xen：

# yum install kernel-xen xen

安装成功后，可以看到 xen.gz-2.6.18-128.2.1.el5 内核已经装好，修改 default 的值默认启动 Xen 内核。

# vi /etc/grub.conf 

default=0
timeout=2
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-128.2.1.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.18-128.2.1.el5
	module /vmlinuz-2.6.18-128.2.1.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.18-128.2.1.el5xen.img
title CentOS (2.6.18-128.1.16.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-128.1.16.el5 ro root=/dev/VolGroup00/LogVol00
	initrd /initrd-2.6.18-128.1.16.el5.img

继续阅读 »

37signals 是除了 Twitter 以外的又一个高流量 Ruby on Rails 架构的示例。

数据

数据来源（2007）：Ask 37signals: Numbers?

约30台服务器组成的 cluster，从 1 CPU 的文件服务器到 8 CPU 的应用服务器，加起来大慨 100 CPUs 和 200GB 内存（正计划把服务器数量减到16台，92 CPUs 和 230GB 内存，性能更高，架构更简单更易管理）。
客户总共上传约 5.9TB 的数据

Stack

以下是 37signals 用到的一些 stack：

Apache
HAProxy
Ruby on Rails
Mongrel
Memcached
MySQL
Xen
Amazon S3

值得注意的是用到了 Xen 虚拟技术和 Amazon S3 云存储。Memcached 现在已是高访问量网站的标准配置了，就不介绍了。有意思的是，DHH 在 Interview with David Heinemeier Hansson 提到，随着技术的发展，硬件越来越便宜，如果能用硬件解决问题就尽量用硬件，除非绝对必要，否则 shard 数据库来分载流量很痛苦。所以 37signals 不太赞成随便 shard，他们现在的主程序就跑在1台 128GB 的主服务器上，然后有多个备份服务器支持，主服务器不久会扩充到 256GB。VPSee 推测他们的 load balancing 是 Xen 之间的 load balancing，不是物理服务器之间的分载。

继续阅读 »