可是最近我们的XenServer上开始出现不稳定的状况。在灾难中，我们积累下一些经验，在此整理一下，以资借鉴：

× 文件系统的性能是最大的瓶颈。如果性能不佳很有可能成为故障的根源
我们的虚拟池(Pool)使用NFS文件系统，架设在一台基于SATA硬盘组装的RAID上。在为多台虚拟进程提供服务时，iops捉襟见肘。甚至逐渐发展到了一些虚拟机Guest误认为文件系统超时而导致了各种故障。而对于Host来说，我们遭遇到的最大灾难就是虚拟机Guest的硬盘掉落，如果没有之前的配置备份或“记忆”，几乎无法找回。

× 对硬盘池的剩余空间保持高度关注
当一个Storage Repository的没有剩余空间时，在其上的虚拟机并不会立刻停止工作或者即刻报警。这样表面上保证了高可用性，但是却会让人大意，进而造成数据大量丢失而导致不可逆的数据灾难。况且在规划虚拟机Guest时，我们通常会习惯性的超量划分硬盘分区，这种情况下，一旦一个虚拟机Guest突然产生大量数据写入时，很有可能导致硬盘池分区满溢的情况。因此对硬盘池保持高度警惕是非常重要的。

× snapshot的极限是30个
在使用XenServer虚拟池的过程中，我们曾对使用snapshot进行断点备份寄以希望。甚至撰写了一个每天自动对所有正在运行的虚拟机Guest制作Snapshot的脚本，停止了手动备份工作。完全没有注意到XenServer中，每个虚拟机Guest至多只能有不超过30个snapshot的限制。直到发生灾难那一天，我们才发现snapshot已经停止多日，回滚中便丢失了大量数据。

× 虚拟池中的Master的数据安全需要全力保证
在多台XenServer组建的虚拟池中，物理主机之间是有Master/Slave之分的。其中Master的数据安全和稳定性尤其重要，容灾能力也会比较差。当Master遭遇不可逆的故障和灾难时，尽管其他Slave上运行的虚拟机Guest进程仍然还能正常工作一段时间，但是此时重启就变成了危险行为。Master的硬件稳定性是如此重要，现在我甚至会推荐Master上不运行任何Guest虚拟进程。

× 留心网卡兼容性问题
我的虚拟池物理主机是使用家用主板自己组装。板载RealTek RTL81xx系列的千兆网卡。幸运的是，XenServer可以识别和使用该系列芯片的千兆网卡，初期大大降低了硬件成本。但是不幸的是，我们发现RealTek 系列网卡至少在最新的Xen 5.6+上无法保证无故障运行，严重是还会导致虚拟机Host主机死锁。最终我们又另外购买了一组TP-LINK TG-3269C 千兆网卡来保证稳定性。

× 升级XenServer版本要谨慎
不只限于前述网卡兼容问题，XenServer生产版本升级会带来诸多不稳定问题。在Citrix论坛上也有大量的抱怨，有人几乎为此丢了工作。而且对于一组虚拟池来说，必须整组升级到相同版本，所以回退的成本也很高。面对这些问题，升级XenServer前务必要谨慎的考察。

× Guest是有可能Crash宿主机的
通常我们认为虚拟机Guest是处于隔离状态的，因此认为Guest进程中无论发生什么不会影响物理主机Host的稳定的。但是实际运行中我们发现，运行的一些Guest操作系统是有可能导致宿主主机死锁或者崩溃的。我们是在安装运行一些FreeBSD的虚拟进程时发现这一现象的，其结果是最终会导致所有同一物理主机下的虚拟进程死锁。而这也是我们现在不再推荐在Master上运行Guest进程的一个原因。因为一旦Master锁死会导致更大的灾难。

× 忘记密码后跳过fsck的方法
在Linux Guest中发生严重的文件系统损坏时，会在启动时要求输入完整的root密码并进行全面的fsck。如果这时候忘记了root密码（特别是全面推进证书登录后）是很尴尬的。碰到这种处境时，可以通过XenCenter设置该虚拟机Guest的属性 – General – Boot Options – OS boot parameters ， 改为 fastboot（跳过fsck阶段）或 single （进入单用户模式）来进入系统并进一步修复文件系统。

× 切换Master的正确方法是在线状态中，登录Master并任命虚拟池中的另一台Slave担任新的Master
正因为Master在虚拟池中的主要性，当需要对Master进行软、硬件升级或调整时，必须要在Master上执行切换操作，将另一台物理主机制定为新的Master再进行维护。否则一旦Master在维护中出现故障，将会成为新的灾难。

from master:
xe pool-ha-disable
xe host-list
xe pool-designate-new-master host-uuid=

From XenCenter

1) Disable HA
2) Enter maintenance mode on Pool Master, will migrate all VMs to anohter host. During the Enter Maintenance mode dialog you will be asked to elect a new Pool Master.
3) Exit maintenance mode on old master
4) Enable HA

相对于直接调用curl和openssl的方式，sinet-lib 的使用更简单，可以通过动态或静态链接调用，并解决了dll 边界问题。除此之外，sinet-lib还支持下载中途取消，线程安全，处理多任务，跨平台编译，并支持C模式的linking。

项目采用BSD License，通过Google Code发布。 http://code.google.com/p/sinet-lib/ ， 使用 mercurial 进行版本管理。

文档位于： http://code.google.com/p/sinet-lib/wiki/sinetlibmanpage

RouterOS的功能强，配置的复杂度也高。首先简单提一下OpenVPN的配置要点:
1. 将证书文件拖拽之WinBox的文件(Files)项目下
2. 在 System – Certificates 项目中导入刚刚创建的证书文件
3. 在 PPP 项目下创建OpenVPN连接，使用刚刚导入的证书
请务必注意的是，目前RouterOS只支持tcp且不开启lzo压缩的OpenVPN服务端

之后是配置路由表。思路可能与多数人的直觉相反，是将默认路由设为OpenVPN的网关，但Distance设较高的值（即较低的优先级）。而专门为属于中国的IP设置路由走原来默认的专线网关（当然OpenVPN服务端所在的IP也要设为直接连接的路由）。这样做的原因是境外的IP虽然没有直接被封，但是还是受关键字影响。另外中国区的IP段行数少，相对容易维护。

因为路由表还是很大，所以使用命令行/ip route进入console：
之后修改 这个文件，将GateWay=ether1改为真正的直线路由的Interface名称。并将所有内容粘贴至console。

之后整个网络环境都可以无障碍了。 当然常用的网站例如wikipedia、msdn等，建议采用varnish之类的镜像缓存系统，在内网自建镜像，来节省流量。

需求整理
射手科技开发环境需要配置的服务器包括且不限于：版本管理、文件共享、开发测试、模拟生产环境、域控制、VPN服务器等。同时为了配合灵活工时制度，需要一个可以远程登录的开发环境系统阵列。
对于没有虚拟化技术的年代，可能需要十多台服务器和专人维护才能满足这些需求。但是基于虚拟化技术，可以将所有这些需求集中在2-3台服务器来完成。

选型
企业化虚拟环境，除了最出名的VMWare之外就是Xen。但是VMWare的企业版（ESX）价格昂贵，对硬件要求也高。而Xen则有免费版，非常适合射手这种创业型企业。所以我决定尝试一下Xen系列的企业化产品。

方案
Xen系列的产品线也不少，特别分为开源和商业化版本。经过比较，商业化版本的XenServer因为包含XenCenter这GUI的管理工具，更容易管理。且它的免费版本已经包括了所有我所需要的功能，所以我选择了XenServer+XenCenter+XenDesktop的配置方案。

具体的方案配置如上图。2台服务器均通过网络采购配件DIY。XenServer使用4核处理器和SSD硬盘。文件服务器使用5块1.5T SATA硬盘，其中2块组RAID1，另外3块组RAID5，以保证文件系统安全。之间使用千兆交换机互联，实测使用网络存储的瓶颈已不在网络而在硬盘IO，所以性能上并不比原方案低，但是容灾、安全、管理和扩展性等各个方面都更加方便。

波折
万事开头难，期间也有不少意外的波折：
* 因为XenServer基于Linux，所以原计划将存储和文件共享一并做成RAID，与XenServer使用同一台设备，这样只需要配置1台服务器。但是最终我发现所有家用/商用级主板自带的RAID均不能被XenServer识别。经过资料检索发现，家用/商用主板自带RAID均属于FakeRaid，就是说所谓主板自带的RAID其实仅是存储了一些配置信息，真正的RAID分配读写操作均需操作系统的驱动来完成。而XenServer是没有这种驱动的（对应的开源版本Xen Cloud Platform也有同样问题）。好在XenServer的设计可以将虚拟硬盘通过nfs存储在远程文件服务器上。便少许追加预算，另外配置一台基于Centos的Raid1+Raid5的NFS服务器，兼做samba文件共享存储。同时因为将存储和运算设备分离，容灾性能也可以更好。

虚拟池
XenServer的管理有一个最大的优点，就是虚拟池技术（Pool）。简单的说，就是每台Guest虚拟机，并不一定只能在一台XenServer上运行。你可以将多台XenServer配置为一组虚拟池。而Guest虚拟机可以在多台XenServer之间迁移甚至按需分配。而我将文件存储与XenServer分离的方案更加方便了这种池内的迁移。这个好处不仅提高了运算资源的利用率，在维护上也更加方便（硬件维护升级可以做到几乎无缝迁移），而且降低了设备灾难带来的风险。

XenDesktop
Xen系列产品中还有个有趣的XenDesktop，根据官网介绍，使用XenDesktop可以高效的远程登录虚拟机上的桌面环境，同时因为是在虚拟服务器上，非常方便阵列管理。对于射手科技来说，意味着可以配置一台开发环境后，迅速克隆多台。之后可以在任一地点登录到该虚拟环境立刻开始进行工作。且XenDesktop的免费版允许10个用户，非常适合射手科技目前的规模。听上去真是非常美好，所以好奇的我也忍不住动手一试。
不过实际使用的结果并不理想。XenDesktop的配置很大程度上依赖Win的域控制。对于常见的企业环境来说，可能是可以非常快的融入。但对于不熟悉Windows域控管理的我，则是非常痛苦。尽管Xen的企业官网提供了配置向导视频，但缺乏方案上的指导，让我还是感到困难重重：
* 不要听视频中的鬼话，Domain Controller 和 Desktop Delivery Controller 别放在同一台虚拟服务器
* Domain Controller 和 Desktop Delivery Controller 不能Clone，域内不能有2台SID完全相同的设备。所以各自都重头安装才好。
* 每个XenDesktop的远程连接都需要一套虚拟环境资源（这一点在介绍视频中语嫣不详）。所以建议还是使用XP环境为主，因为Win7 x64需要最低2G内存才能运行，一台8G RAM的XenServer最多也只能跑3个桌面了（要留给XenServer系统一点）。
* 免费的产品版本中似乎还不能做到配置1台Guest Desktop即可完成部署的程度。配置好后需要逐台Clone。如果谁有更高效的管理和部署经验，还请指导。

迁移
人生难免留下一些之前VMWare上的虚拟机，迁移到XenServer可不算是一件容易的事情。甚至可以说是最大的一个麻烦。这个问题上我尝试多次，也没有找到可以称为最好的方法。只是一些积累的经验分享出来以免更多的人犯同样的错误。
* 最好的格式转换工具应该是VMWare自带的导入、导出工具，而不是XenConverter。VMWare为了便于虚拟机在多个产品之间迁移，大部分产品都可以导出到ovf（一个开放标准的虚拟机配置及存储格式）。例如 http://support.citrix.com/article/CTX116603 。但是这个导出有一些先决条件，如果条件没有满足，就不会出现可以导出到ovf的选项，也没有明显提示。
* 一篇详细的迁移参考 http://forums.citrix.com/message.jspa?messageID=1465589
* VMWare的虚拟机最好是单硬盘的。如果不是，最好想办法合并一下。
* VMWare的虚拟机硬盘千万不要“按2G大小分割”，其结果就是不能导出到ovf。如果木已成舟，可以用VMWare自带的 vmdisk-manager 命令行先转换为单文件存储。
* 迁移前移除VMWare-Tool，比迁移后移除方便。
* 能不迁移就不迁移（难以预料的问题太多）

后记
使用虚拟化产品部署后，整个服务器环境成本大幅下降：
XenServer配置：AMD 4核+8G内存+SSD 约3000元
文件服务器配置： 最低端的CPU+1G内存+5x 1.5T硬盘 约5千元
总成本控制在1万元内，却完成了原本需要超过10台硬件设备才能完成的功能。同时非常易于维护，并因为硬件设备的减少，能耗也大幅降低。

Tips
* Xen企业产品的官网提供了很多详细指导视频，建议先进行直观的了解。部分教程可以下载回来，协助配置。
* XenServer的免费版也是需要注册激活的，不收钱，但是也别忘记了。
* 如果需要安装GUI的Centos，不要选默认的Centos模板，要选择”Other Install Media”才能识别显卡
* 个人观点：lvm是非常不适合虚拟机环境的文件系统。难以迁移和管理，硬件变化对lvm的影响可能是灾难的。我很迷惑为什么现在的Linux都要以lvm为默认的文件系统。

媒体播放工具，这里主要指视频播放，因为要面临庞大的兼容性和纷繁复杂的算法，从架构上看，能脱颖而出的体系屈指可数。大体来说业界主要有3大架构：MPC、MPlayer和VLC。这3大架构及其衍生品占领了90%的市场，凡是用户能看到的免费媒体播放软件，无一不是源自这3大架构。

MPC/HC架构
MPC（Media Player Classic）和它的后续者MPC-HC应该并列而说。MPC基于DirectShow架构，是Windows系统下元祖级别的播放器。包括KMP之流最早也就是抄来MPC的代码再换个界面。MPCHC则在MPC的原作者Gabest渐渐退出开发后的继承者，MPCHC有很多创新特性，包括开始融入ffmpeg和支持更多DirectX特性和DXVA等等。

优点：更直接的支持DXVA，对一些稀奇古怪的Windows平台上的格式可以通过调用第三方的Filter组件等，拥有更好的兼容性
缺点：有人说DirectShow是Windows中最难掌握的SDK，开发复杂；DirectShow允许第三方封装的特点也让兼容性和稳定性问题复杂化；第三方Filter出现异常时非常难以分析处理，更难以复用；
射手播放器的架构主要来自MPC-HC，但更多的融合了FFmpeg的优势，对DirectShow Filter进行了多处改写，大大加强了对ffmpeg的利用，提高了解码稳定性，同时扩展了解码能力和兼容性。

mplayer架构
如果说MPC是Windows上的元祖，那么mplayer就是linux上媒体播放的元祖了。mplayer使用ffmpeg作为解码核心，也是与ffmpeg结合最紧密的项目，ffmpeg的代码就是由mplayer来host，开发者群也有非常大的交集。借助linux开发/使用者的强大实力，mplayer建立了要比DirectShow稳定的多的工作流程。超越ffmpeg本身的功能外，后来又通过反向工程使之可以调用Windows上的DirectShow Filter DLL，让mplayer架构越来越吸引人，成为兼具稳定性和性能的优秀作品。

优点：稳定，兼容性也可以说相当不错
缺点：代码结构不清晰；纯C语言开发，难于阅读；显卡硬件加速还需要越过更多障碍

VLC架构
VLC是个后起之秀，开发速度的进展可以说是一只奇葩。虽然同样基于ffmpeg，但可能是相对于“左三年右三年缝缝补补又三年”的mplayer架构来说，VLC的架构在设计之初就很好的考虑到模块化开发，所以使它更吸引年轻的开发人员。成为近年发展非常快的架构。

优点：稳定，兼容性也可以说相当不错
缺点：纯C语言开发，难于阅读；硬件加速略有障碍

很多人都会发现，3大架构中都可以看到ffmpeg的名字。说起ffmpeg，那真是”One Ring to rule them all，One Ring to find them, One Ring to bring them all“。在#ffmpeg有人和我说过，想不用ffmpeg去写媒体播放器，就像是造汽车而不用车轮。但是ffmpeg本身仅作为命令行工具或类库（常见的如libavcodec）出现。终端用户很少能直接接触到ffmpeg，所以知名度也较小。ffmpeg的详细架构，下次有时间时再续……

*注1：所有优缺点均仅针对架构本身而言
*注2：文中观点为个人意见，仅供参考