从实体机到xen，一个企业信息管理平台主机系统的变迁之路

分享一下我给某个企业做的信息管理平台的心得吧。

本项目是连软带硬，服务器也交由我们进行托管，本次分享的不是软件开发的经验，而是服务器的变迁史，想看开发经验的，请移步。

一开始，服务器（Xeon 2.13*2/4GB/420G）刚拿回来的那阵，我三下五除二，装了个debian的发行版，装了MySQL，JDK6，Jetty，把应用发布上去，就这么给用户测试的（如下图）：



很简单吧，一个数据库+一个web中间件，搞定。

这个时候，开发完了，用户也基本没意见了，准备上线了，服务器要丢到机房托管了，这时候我是这么想的，服务器丢到机房后，再想物理接触到它就不容易了，安全起见，还是装个xen吧，把应用跑在虚拟机里，主机除了xen，什么都不跑，最大限度保证远程管理的可能性，即使虚拟机当了，至少我还可以通过xen主机远程去重启与修复，当然，为了便于管理和安全，我把web服务与数据库服务分开了。于是，整台主机就变成了这样（如下图）：



这样的配置运行有一段时间了，一直也没什么事，但我管理的另外一个应用（不是这个项目的）频繁当掉，要不就是Oracle线程耗尽，要不就是WebService无响应，估计是代码中开了连接没有释放的结果，但那个项目是委托其他公司开发的，向他们反映了N（N>=10）次也不能解决该BUG，搞得我每隔2星期就要重启一次服务器，从这个事件联想过来，我也害怕这个服务器出现这种情况，于是我计划在前端架个web代理，做web转发，后端架设2个WEB服务，1主1备，主备机通过samba共享另外一台服务器的某个目录做附件目录，实现两台应用服务共享存储的目的（廉价嘛，没有磁盘阵列，也只有这么搞了，还好系统的瓶颈在于出口带宽而不在于内部带宽），提供附件上传下载功能。有个备份服务后，至少一台的应用当掉了之后，另外的一个应用还能做替补，于是服务器变成了这样（如下图）：



这样又过了一段时间，最近客户提出了新的需求，客户原先在别家地方托管的公司主页和邮件服务均到期了，客户觉得我们服务还不错，想把主页和邮件都迁移到我们这里，还是放在这台服务器上，这个时候，我就庆幸，当初这个xen架设的好啊。你看看，客户的主页是asp.net的，要是实体机单个操作系统，那我该如何处理这个asp.net的站点啊（别跟我说mono，别说wine，那玩意兼容性有限，如果是自己开发的代码还好，还可以适当更改，这不是自己的代码，万一有不兼容的地方，我岂不是傻眼了）。另外，客户也反馈了，有时候信息管理平台的附件上传下载不了，我检查了一下，发现是samba的问题，似乎是客户端通过cifs文件系统共享服务器的samba目录，长时间没有读写动作的话，连接会断掉，而且不会断线重连。

最后，经过设置，服务器变成了这样：



你看，一台服务器跑了8台虚拟机，还有1.3G的空闲内存，预计再架个2-3台虚拟机不成问题。xen是多么美妙的东西啊。

整个思路，我是这样考虑的：

该客户的公司只是个小公司，整个系统的出口带宽也才4M专线，访问量不大，因此，在设计上，负载均衡，可以先不考虑，还没有达到需要负载均衡的条件，再说了，在一台机器上做负载均衡，不也是白做嘛，到底是谁负谁的载，谁均谁的衡啊。

需要考虑的是高可用性，鉴于以往做过的项目的经验，硬件故障不说，其实大部分时候服务中断，往往都不是操作系统的问题，经常是应用当掉了，操作系统还在正常运行，那么，这种情况下，LVS+Heartbeat热备方案，就显得太复杂了，直接用Nginx反向代理，应该就可以提升系统的容错性了。相对于LVS+Heartbreat的安装配置，nginx要容易的多。为了确保nginx的稳定性，需要专门给nginx配置一台虚拟机，这样它将不会受到其他软件的干扰，几乎不用考虑它当机的可能性。

存储专门独立出来用一台虚拟机，也是基于稳定性的考虑，只跑samba和nfs，除了硬件故障，我就不信它还能有当机的可能（我在公司另一台服务器的vmware里面跑了linux当samba服务器，2年多没重启了，服务正常的很）。因为出现了samba经常自动断开的情况，这次我决定换用NFS做共享服务，samba之所以还保留，是考虑到日后windows的服务器连接方便，目前是暂时用不上了。

MySQL也独立出来单独用一台服务器，这个我是这么考虑的，目前的应用跑了半年多了还未出现让MySQL当机的行为，我就先假设一台MySQL也能提供稳定服务，如果日后MySQL真的出现了频繁当机的情况，这个时候再考虑架设多台MySQL虚拟机做MySQL集群。当然，为了保证数据的安全性，即使只有一台MySQL，我还是在那台机器上做了一个每日自动备份数据的脚本。备份完后会自动放到存储服务器的共享目录中。

web应用不用多说了，当然是一主一备两台，用jetty当中间件，可进行session同步（jetty的session同步方法参见我的另一篇文章）。用一主一备session同步的方式，我发现我在线部署代码完全不用考虑客户，因为客户的服务基本上都不会中断，基本上没有感觉（当然，客户如果在传输大文件，就会出现断掉的可能），其他的操作是不会中断的。

电子邮件也独立出来单独一台服务器，这个倒没有什么别的考虑，只是因为我用的是现成的别人做的邮件系统解决方案，是基于centos 5.3的，带webmail的，而我其他的虚拟机的linux都是定制的，不带应用才占20M的空间，所以只能让电子邮件单独装一台虚拟机，跑centos。

我还装了台测试服务器，这是没事拿来玩的，呵呵，开玩笑啦，是跑debian的，用来定制其他虚拟机用的，比如说编译内核或编译其他应用什么的，这是我这么多虚拟机里面唯一一台装了编译器的，不装不行啊，有些linux的软件debian里面找不到，只能下载源码来编译。虽然说主机上的dom0也是跑的debian，但那个系统我是几乎不动的，除了管理虚拟机，那个系统不做其他的任何事情。因为它太重要了，比所有虚拟机都重要，所以稳定压倒一切，宁愿专门装个测试系统来做这些事情，也不能让主机上的系统做。

最后一个，就是windows 2003了，幸好，这次的服务器的CPU终于支持VT-x技术了，前后装了3台xen，终于让我遇到一个有VT-x支持的cpu了，不跑个windows，岂不是对不起自己？更何况是用户有需求，用户的原站点，是用asp.net+access开发的，我不知道是不是可以用mono来跑，但方便起见，装台windows吧，反正客户有个license正好没地方用。如果没有license。。。。。。。你猜我会装什么吧，我不发表意见，你懂的。这是china，XX的天堂。

后续计划：

这样的设置，够健壮了吗？我觉得应付目前的局势，应该够了吧。除了那台windows的稳定性我不敢保证外，其他的应该都比较健壮吧。那台windows还是需要跑一段时间看看效果，如果不稳定，我再考虑是否需要再装一台做热备或者直接换成mono，但目前还不需要。

除了windows，MySQL、Mail，都是可以通过再装1台做热备的，这要看后续的表现。

我的建议是，不要动不动就搞什么heartbeat，搞什么windows集群，搞什么双机热备，我见过好几个搞双机热备失败的例子了，那都是噱头，骗客户玩的，真正要保证系统服务的不间断性，那是需要不断调整的。只要保证最关键和最容易当机的应用有一定的容错性就可以了。

顺便聊聊我见过的失败的双机热备的例子吧，我就举两个典型的，一个Windows 2008集群，4台服务器+1台磁盘阵列，跑SQLServer和Tomcat，装完后演示给客户看的时候，就是失败的，为啥，演示是把网线拔掉，结果呢，虚拟IP备机是自动接管了，备机的tomcat+sqlserver也自动起来了，但tomcat连不上数据库，为啥我是不知道，也不想知道，反正我只是负责windows 2008集群的安装，应用部分，不是我负责，我不需要管，反正开发商跟客户的解释是主机当了后，需要用户去重启一下备机的sqlserver服务，客户也不关心这个，反正他们的目的是把钱花出去，至于是不是真的能实现双机热备，好像也不是很关心。我笑死了，这就是双机热备。

另外一个，2服务器+1磁盘阵列，跑centos+oracle+weblogic，我那是友情支持，帮他装了centos自带的一个集群软件，最后装好了演示也成功了，拔掉主机的网线，备机的oracle+weblogic会自动启动并接管，客户也满意了，但问题是，这样真的能实现热备吗？缺省判断是通过ping，ping不同对方的时候会自动接管，但现实是什么样子的呢，往往是应用当掉了，服务器还正常，也就是说，ping是正常的，当然，你可以说，我可以监控端口，而不仅仅是ping，这个说下去话就长啦，我也不否认最终是能够解决的，我只是感慨，有些人理解错了热备的概念，以为热备主要防范服务器断电啦，死机啦，其实我觉得应用系统当掉的可能远远大于操作系统当掉的可能，更别说硬件损坏的几率远远小于应用系统当掉的几率，毕竟，硬件经过厂家专业的认证，操作系统和一些较流行的软件也经过大量用户的实际检验，往往是我们自己写的应用，限于水平也好，是测试条件也好，成熟度远远达不到前面两者的高度，这才是服务中断的主因之一。因此，把重心放在如何检测应用系统中断和提供后备服务，才是热备最需要做的工作，而不是去考虑操作系统当机啊，服务器断电啊之类的事情。