宕机问题是导致服务器数据丢失和用户访问延迟的最常见原因，而高可用（HA）可有效减少服务器宕机和虚拟机重建所需时间窗口。

　　Xen之前的各个版本都缺乏高可用方案。这一情况在Xen 4.0版本中随着Project Remus在去年的发布得以改善，管理员可以创建高可用架构确保发生宕机后虚拟机保持在线。

　　Project Remus是British Columbia大学计算机技术学院开发的高可用方案。通过在备份服务器上保留实时更新的副本来为运行在Xen hypervisor 平台上的虚机提供高可用性。

　　Project Remus只能支持Xen平台，它是建立在Xen的Live Migration功能之上的。和其它虚拟化方案的整合还在研发中。

　　防止服务器宕机

　　为避免宕机的影响，您需要为每个虚拟机至少保留两个副本，而且要保持备份数据的同步。这就是高可用技术面临的主要挑战：如何确保在同步的时候数据不丢失？

　　针对该问题有两个可选方案：使用CPU锁频技术确保它们运行的命令完全一致；或者假设所涉及的机器并不需要完全意义上的同步。Project Remus是基于后者的。

　　Project Remus在文件级别上创建虚拟机的完整拷贝。如果虚拟机是活动的，那么它的完整状态(包括CPU指令、磁盘缓存请求、内存事件、网络包等等)都必须进行精确拷贝。对虚拟机状态的拷贝几乎是精确的，但是会有一定的延迟，换句话说备份并没有严格地执行实时同步。

　　不过用户不会注意到活动虚拟机和镜像之间存在区别，因为Project Remus进行数据拷贝的时间间隔是200毫秒。为保证拷贝过程的高效，Project Remus只同步那些标记为dirty的磁盘页面。也就说只有最近使用过的用户数据块进行同步，而不是整个虚拟机。

　　网络数据同步是高可用方案的另一个难点。在网络上传输到活动和备份虚拟机的数据包状态应该保持一致，Project Remus通过缓存在200毫秒间隔内的所有网络数据包达到该目的。如果您感觉间隔时间太长，还可以调整到25毫秒来降低延迟。

　　借助这些机制，Project Remus保证了无论从虚拟机角度还是网络的角度看，活动和备份虚拟机始终处于同一状态。

　　测试Project Remus

　　Project Remus Xen高可用方案已经开放测试。完成测试环境搭建所需做的只是定义每个虚拟机的磁盘文件。由于同步并不是完全实时的，所以活动虚拟机和镜像拷贝不能访问同一个虚拟磁盘。也就说您不需要购买共享存储，而这是其它高可用方案所必须的。

　　测试Project Remus的Xen高可用，建议的方法是把虚拟磁盘文件拷贝到两个主机上。然后，用Xen命令xm create vm启动虚拟机，用如下命令启动Project Remus，用dom0机器的IP地址替换dom0-IP：

　　remus vm dom0-IP

　　该命令可以分别激活两台主机上的虚拟机和镜像。分别运行xm list命令可以验证其工作状态。

　　Project Remus的不足

　　在启动阶段，由于Project Remus还是个半成品，所以保证其始终正常运行还有一些困难。最终，一些不足会得到改善，例如和Xen管理工具的集成。

　　受到设计原理限制，有些问题很难修复。最重要的一点就是网络性能的损失，使得Project Remus不适合于网络密集型虚拟应用。

　　Project Remus通过频繁地心跳监控机制来检查另一台主机上的虚拟机是否可用，而支持高频率访问会带来额外成本。用户会感觉到明显的网络性能问题，因为虚拟机在一秒钟内至少需要同步五次。

　　根据Project Remus开发人员的数据，内核编译工作量上限大约是50%，而网络性能有可能降到原来的25%。这个性能损失，尤其是网络层面还是非常明显的。

　　至少在现有版本下，Project Remus不是那些网络流量密集型应用的理想选择。为降低性能损失，可以使用专用的网卡完成同步。开发者也在尝试其它的一些途径，包括对复制数据的压缩，这样可以有效减少同步所需的数据量。不过，对于那些无法接受服务器宕机而网络带宽压力并不明显的Xen架构而言，Project Remus依然是重要的高可用方案。