HA和ISSU设计思路

啸傲江湖

(注：HA - High Availability. ISSU - In Service Software Upgrade)
最近陈首席跑到大家这儿来，谈到分布式系统中HA的设计的时候，把Arista企业的EOS吹捧了一通，说是看过到最漂亮的HA的架构，由于没有legacy的包袱，加上设计者是业界顶级牛人，所以设计得非常好，比cisco, Juniper,HUAWEI的都好。而且他们的资料在网站上公开。
正好大家的chassis系统也正在考虑上HA,还有ISSU，听说有此等好东西，自然是不会放过，赶紧去下载下来，研究了一番，文档不长，但是确实如首席所言写得很详细，足够让你了解到他们的思路。我花了不到10分钟就看完了，看完之后的感觉只有两个字：兴奋。
之所以兴奋，一方面是看了他们的描述之后，觉得确实简单却漂亮。另外一方面，则是惊奇地发现他们的设计思路跟大家自己之前的方案居然是一致的，自然是信心大增。
他们的思路说白了很简单，就是所有的进程，在维护自己的数据的同时，都实时地copy一份数据到一个共同的database（名字叫sysdb),这个database就类似于一个database engine. 主备之间的数据同步都只发生在主板的sysdb和备板的sysdb之间。这种设计除了做HA之外，还非常有利于做另外两个事情：进程错误管理和ISSU.
进程错误管理：当一个进程crash掉之后，一个专门用于管理其它进程的叫做procMgr的进程，会马上重启这个crash的进程，由于该进程crash之前的所有数据在sysDb那里都有备份，所以新进程可以很容易地从sysDb恢复所有数据并重新跟其他一些相关模块建立连接。
ISSU：当要对某一个进程进行App升级的时候，可以先把原有的进程kill掉，然后马上把新的image起来，重新到sysDb去读取数据，这个过程不会影响转发面，可以做到真正地In service upgrade.
当然，原理虽然看起来简单，真正要去做，还是有很多难点的。
比如，sysDB这个东西，从他们的描述上看，好像仅仅是一块内存区域，并且也有一些简单的API，那么这个DB的组织就是一个很重要的事情，如何组织，不仅涉及到效率问题，还涉及到稳定性，代码复杂度问题。貌似还需要用share memory。
这么大数据实时写到sysDB并实时（或者定时）同步到备主控，对CPU负荷也是一个挑战，当然，CPU足够强的话，应该问题也不大。
ISSU的时候，如果是要upgrade多个进程或者upgrade整个image，怎么处理？
如果切换之后主控跟线卡之间数据有不同步，如何检查并修正？
另外，如果要做到NSR,那么linux kernel中的TCP/IP连接如何同步？
这些都是需要考虑的。但是这个方向是很好的，能做到什么程度，那就是要看大家自己的本事了。
好东西不能独享，把这个文档也贴上来跟大家分享一下。
附件:
EOSWhitepaper.rar
[时间:2011-6-24 22:09 - 下载次数:4]