Subversion系统的冗余及备份- 有感于中国银行IBM大型机宕机事件

最近的IT领域的热点事件"IBM大型机永不宕神话破灭 两地三中心备份成摆设"引起了大家的广泛关注及讨论，原文http://digi.tech.qq.com/zt2013/syibm/index.htm. 不得不承认，IBM Mainframe依然是最稳定的服务器之一，这个例子恰好说明即便是世界上最可靠的服务器也会宕机，长达数小时，损失以百万美金计算。采用的主备库模式并不理想。

同样，作为世界上使用最为普及的研发配置管理/版本管理系统，Subversion，管理着研发的关键资产，支撑着研发的每日不间断运行，同样承担相同的风险，尤其是只有单一SVN服务器的模式后果可想而知。有些公司尽管已经采用了Subversion的主备库模式，同样Subversion的主备库模式同样不能保证高可用性，先天的不足在哪？而SVN Multisite的Active-Active实时对等模式如何化解这一风险，相信以下的一点总结可以给大家在SVN配置管理部署上以启发。

--------

Subversion系统的冗余及备份

配置管理属于研发的支撑性系统，所有的源代码，各种文档及发布文件都存储在SVN里，所以其关键性是不言而喻的。这也就要求，特别是企业级SVN系统一定要有完备的冗余和备份方案，来保证发生意外时的高可用度。

备份属于基础级的保障，即保障SVN数据的安全。常见的有svnadmin dump 和hotcopy, dump只能导出数据文件不能导出hook，但可以在不同的svn环境下导入。Hotcopy可以导出数据包括hook,但只能在相同的svn环境下恢复。另外，现在企业里普遍应用了单独的商业备份系统，也可以达到相同的目的，最低的要求是每日增量备份，每周全备份。

备份只能保障到系统级，而不能保障到应用级，即如果SVN服务应用本身出现问题，只有数据的安全是不够的，只有SVN服务器恢复，才能再恢复数据，而如果单一服务器出现这种情况时就会使得整个研发受到影响甚至中断，这是不可接受的。所以在大规模SVN系统里一定要有冗余服务器。企业研发里的Subversion服务器推荐架设日常访问服务器，持续集成服务器以及测试用服务器。日常访问服务器即生产服务器，用户进行正常操作的服务器；持续集成服务器用来进行build等持续集成访问，使其不影响日常访问服务器的性能。另外需要冗余服务器来进行SVN patch等升级的验证，同时提供冗余保障功能。SVN服务器之间可以使用svnsync进行定期同步或svn Multisite进行实时对等同步。svnsync主备库模式的致命弱点是非实时，而且主从服务器结构(从服务器只读),这样主服务器（生产服务器）一旦出现问题，从服务器无法立即承担生产服务器。

而svn Multisite可以把所有服务器组成一个SVN集群，专利的Active-Active技术使得服务器间完全对等（全部可进行读写），同时进行实时同步，这样生产服务器或任何一台服务器出现问题或宕机，其他服务器照常服务，对于用户没有任何影响，从而保证了研发系统的高可用性。

确实有很多公司已经意识到了这一点，目前SVN Multisite的Active-Active方案已经为惠普全球超过20个研发中心，Intel,Juniper Networks,Cisco,华为等公司所采用，为这些公司的研发提供了高可靠性及实施协同。