Patterns in network system design (7)

作者 | 2011-01-18 19:51 | 类型 行业动感 | 19条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 网络系统设计模型概论

  1. Patterns in network system design (1)
  2. Patterns in network system design (2)
  3. Patterns in network system design (3)
  4. Patterns in network system design (4)
  5. Patterns in network system design (5)
  6. Patterns in network system design (6)
  7. Patterns in network system design (7)
  8. Patterns in network system design (8)
  9. Patterns in network system design （续）

29) Trace

Pattern Name and Classification: Trace
Intent: 提供有效的了解系统状态的工具
Also Known As: Debug; Log
Motivation (Forces):

  在系统出问题的时候，如何有效的跟踪定位问题？答案就是有效的Trace系统。这里所说的Trace和通常在Debug image里加的Debug信息是不一样的，在Debug image里面的Debug信息，在Releaseimage通常会通过开关去掉；而这里所说的Trace是指在Release image里面所包含的Trace。包括对关键路径和出错路径的记录。这里的Trace正常情况下应该是关闭的，但是可以通过开关来打开。有了这样的工具，定位错误就会方便很多。

  系统出错并不可怕，可怕的是不能快速定位并解决问题。所以系统一般都会包含一个Trace系统，也会包含一个在系统崩溃情况下，保存寄存器，调用栈，内存等内容的工具。这些是集成在Release image里面的，出错的时候可以帮助定位问题。

  Trace并不是越多就越好，最好是能够理清楚系统有多少个调用路径。一般来说，data plane的调用路径都不会太复杂，应该还是可以理清楚。Trace太多了，反而找不到有用的信息；太少了，又得不到有用的信息。由于Trace是在Release image里面，太多了也会影响系统性能。所以最好是对每一个Trace都经过Review才加进来，尽量避免多加或者少加。
Known Uses: network system
Related Patterns: counter
References:

1: http://en.wikipedia.org/wiki/DTrace

2: http://en.wikipedia.org/wiki/SystemTap

30) Counter

Pattern Name and Classification: Counter
Intent: 记录系统已发生的事件的数量
Also Known As: No
Motivation (Forces):
  Counter记录了系统已发生事件的数量，比如收发包的个数，处理出错的个数和原因，这些对了解系统状态很有帮助。Counter简单来说有两类：一是系统正常处理的事件数，这类Counter可以帮助了解系统是否正常工作；二是系统异常处理的事件数，这类Counter可以帮助了解系统发生了什么问题。Counter并不是越多越好，特别是在Multi-core的环境里面，atomic counter对系统性能影响很大。Counter的性能是设计系统是需要特别考虑的问题。并不是所有的Counter都需要atomic update，如果可能的话，可以用per-cpu的counter，或者使用普通的update。

Known Uses: network system
Related Patterns: Trace
References:

1: www.cc.gatech.edu/~jx/8803DS08/counter.pdf

2: http://www.cc.gatech.edu/classes/AY2010/cs7260_spring/plentycounter-ancs2009-slides.pdf

31) Performance monitor

Pattern Name and Classification: Performance monitor
Intent: 跟踪系统的性能变化
Also Known As: Performance tracker
Motivation (Forces):

  在产品的生命周期里面，维持或者提高系统性能是很重要的一个工作。黒盒测试可以了解系统的性能变化趋势，但是不能告诉开发者系统性能为什么发生变化。这个时候，就需要集成的performance monitor来跟踪系统性能变化。performance monitor应该只针对主要路径，主要函数。因为performance monitor本身会耗费一定的时间。如何把performance monitor集成到release image并使得performance monitor对系统性能的影响最小，需要仔细设计。performance monitor有时也可以帮助开发者了解系统的热点，这样有助于性能优化。
Known Uses: network system
Related Patterns: No
References:

1: OProfile – A System Profiler for Linux

2: Smashing performance with OProfile

32) High availibility

Pattern Name and Classification: High availibility
Intent: 设计具有高可靠性的系统
Also Known As: reliability
Motivation (Forces):

  High availibility是系统设计必须面对的问题。所谓的high availibility，就是那些99.9%, 99.99%, 99.999%,99.9999%。没有100%可靠的系统，除非系统不用，或者只用一次，用过之后就不再用了，否则的话100%是没法测试的。在电信领域，一般都用一年宕机多长时间来衡量系统的可靠性。如何保证系统的可靠性哪？最直接的就是系统冗余，不管是硬件还是软件，提供冗余。冗余包括某些部件的冗余，也包括整个系统的冗余；有双机的冗余，也有多机的冗余。

  引入High availibility的概念后，很多软件设计就需要做相应的变化，比如说配置同步，状态同步，NSR，ISSU等。虽然系统本身是冗余的，但呈现给用户的还是单一系统，这就是high availibility所面临的难题，用户不需要了解，也不能感知切换，为了这个目标，需要做很多工作。
Known Uses: network system
Related Patterns: fault tolerance
References:

1: http://en.wikipedia.org/wiki/High_availability

2: http://en.wikipedia.org/wiki/High-availability_cluster

33) Fault tolerance

Pattern Name and Classification:  fault tolerance
Intent: 考虑各种可能性，使系统避免崩溃，能够正常工作
Also Known As: stablility; robust
Motivation (Forces):

  Fault tolerance与high availibility不同。简单地说，fault tolerance是high availibility的基础，但是faulttolerance并不能保证high availibility，是必要条件，而不是充要条件。Fault tolerance有很多方面，最简单的，系统要能处理收到的任何包，这里的处理也包括丢弃。畸形包是最常见的攻击之一，如果不能正确处理，就会导致系统崩溃，或者系统的功能错误。

                      Be conservative in what you do,
                be liberal in what you accept from others.
              （http://graphcomp.com/info/rfc/rfc1812.html)

   避免崩溃是一方面，系统的功能正确才是最终目的，任何异常处理都不能损害系统的功能，否则就是在功能定义阶段没有把功能定义清楚。
Known Uses: network system
Related Patterns: high availibility
References:

1: http://en.wikipedia.org/wiki/Fault-tolerant_design

2: http://en.wikipedia.org/wiki/Fault-tolerant_system

34) Watchdog

Pattern Name and Classification: watchdog
Intent: 定时监控，避免某一任务占用CPU时间过长
Also Known As: timer; keepalive
Motivation (Forces):

   一般来说，网络系统是实时系统，任何一个任务，都应在规定的时间内结束，否则就是系统错误。所以需要watchdog来监控每个任务。watchdog还可以帮助开发者发现系统中的死锁，过长的循环，任务分配不合理等问题。如果某一任务执行时间过长，它就会阻塞其他任务，如果所有的CPU都被这类任务占用了，系统就无法相应事件，也有可能无法将这些任务调度出去。

   有些需要定时执行的任务，比如HA里面的heartbeat，IPsec里面的DPD等，与watchdog类似，用途也差不多。  

   有些公司拿watchdog来复位整个系统，当然这个watchdog的粒度就比较大了，和前面说的watchdog不一样。在某些情况下（比如无法定位的错误），必须重启机器才能使系统正常工作，这个办法还是可以用一用的，当然这是最后的选择，不要轻易使用。
Known Uses: network system
Related Patterns:
References:

1: http://en.wikipedia.org/wiki/Watchdog_timer

2: http://en.wikipedia.org/wiki/Keepalive

系列前一篇 系列下一篇
(没有打分)

工具箱
本文链接 | | 打印此页 | 19条用户评论 »

雁过留声

“Patterns in network system design (7)”有19个回复

  1. 陈怀临 于 2011-01-18 8:17 下午

    1. 在session小节，你可以mention一下N元组。效果会好一些。另外，建议加上vr，vsys等相关内容的介绍。可以作为一个pattern。
    2. HA方面也忒点到为止了。应该谈谈Active/Passive

    总之，相当优秀。努力。我一定为你整个弯曲评论荣誉出品。。。

  2. aaa 于 2011-01-18 8:41 下午

    请问这系列的内在联系是什么？排序的依据是什么？

  3. kernelchina 于 2011-01-18 9:21 下午

    还有第8季，第8季是一个总结，能看出来整体的一个想法。至于排序，开始没排好，后来就这样了。不过第8季的pattern language会有一个更好的印象。

    首席的建议很好，以后修订的时候，我会考虑的，谢谢。

  4. xwill 于 2011-01-18 10:09 下午

    感觉kernelchina兄写出了常见的网络系统以及组成（或者开发）这些系统的一些内部模块，可否再详细一些？比如简单描述一下各个模块的设计实现原理？

  5. droplet 于 2011-01-19 1:09 上午

    可以到www.kernelchina.org上看看有没有有用的东西，或者你在北京，我们当面聊，或者首席组织一个弯曲的北京沙龙或者论坛之类的。细节需要一些参考代码，目前还没找到合适的开源项目可以用，或者自己做一个也行。

  6. aaa 于 2011-01-19 1:51 上午

    5：
    有意BUILD 一个（或者几个）开源的框架吗？然后再制定一些标准，让厂商去遵循。安全产品的共性还是很强的，所以框架制定还是有据可依的。

  7. kernelchina 于 2011-01-19 7:21 上午

    嗯，学comer写了XINU来教网络和操作系统，好主意，就是实现起来有点难度。
    个人认为comer的书条理清楚，浅显易懂，不知道为什么大家都喜欢stevens的书，comer是学院派，stevens是实践派，不过两个都是实力派。

  8. 妞妞果冻 于 2011-01-19 8:02 上午

    回楼上的：
    因为可以马上拿来用。。

  9. 新手 于 2011-01-19 7:52 下午

    向楼主请教一个细节问题，atomic update（例如linux下的atomic_inc）在多核下对系统的影响有多大？跟spin_lock+update相比谁大谁小？有没有实际的比较数据？

  10. kernelchina 于 2011-01-19 9:12 下午

    我感觉应该是atomic operation要比spin_lock+update快，从指令数量上来比较也应该是啊，至于测试数据，没有做那么细过，不好回答。

  11. Panabit 于 2011-01-20 1:10 上午

    不仅仅如此，atomic operation一般可能就touch到一个CACHE LINE，spin_lock + update一般都有可能touch到两个CACHE LINE（如果lock variable和update的cunter在一个CACHE LINE里那就例外了）。我测试过，atomic操作是很费时间的（spin_lock里也是atomic操作），这个原因我估计主要是因为要涉及到内存的写等待。所以很多时候你会发现，用spin_lock的时候，即使没有冲突，也会降低多核下的程序的性能。总之，能避免这些操作，就尽量避免。

  12. kernelchina 于 2011-01-20 1:56 上午

    Counter有时候并不需要atomic，假如执行不依赖于counter，是不是可以不用atomic，如果仅仅是一个统计值，如果不是atomic的，它出错的几率应该有一个范围，这种情况下，错一点，应该也没关系。当然，为了保险期间，还是用per-cpu counter会更好一点，不过内存会浪费。
    Panabit是实践高手啊，以后多多请教。

  13. Hui Liu 于 2011-01-20 1:58 上午

    多个CPU同时轮询一个spinlock会带来cache bouncing问题。

    spinlock=原子操作的开销（锁总线带来的延迟）+cache同步的开销+额外的cache操作

  14. Lucifer 于 2011-01-20 2:04 上午

    原子操作是操作系统底部提供的原语，spin-lock应该是更高层的结构，所以开销应该通常后者大吧

  15. 三千大千世界 于 2011-01-20 5:36 上午

    2. HA方面也忒点到为止了。应该谈谈Active/Passive

    HA确实写得简单了点。要高度概括和总结那功力得了得啊。期待能有更深入的讨论。

  16. alrn 于 2011-02-07 5:20 上午

    IPSec的DPD是什么呢？

  17. alrn 于 2011-02-07 5:21 上午

    关于HA的，如果朋友们有兴趣的话，可以看看OpenClovies/GoAhead/openais/SA的文档。
    以下网站可能对大家有帮助：
    http://www.saforum.org/
    http://www.openais.org/doku.php?id=welcome
    HA和您的系统应用有密切的关系，上述的文献资料不是万能的，很多细节地方都要靠自去想。。。。

  18. kernelchina 于 2011-02-07 7:49 上午

    http://tools.ietf.org/id/draft-ietf-ipsec-dpd-04.txt

  19. Will Chie 于 2011-02-08 10:40 上午

    简而言之，就是dead peer detect，涉及端到端通信的应用都可以用（事实上IKE也是端到端通信的应用），QQ也可以用。