分享

缘起：看到弯曲中有审计和SOC的文章，正好自己做了一段时间，有点心得，希望得到诸位高手的指教。
当下国内的等级保护已在如火如荼的进行，据悉今年，C-SOX开始启动，安全审计也就水涨船高，因为国内有的厂商就是通过SOC产品满足其审计要求的。
说到SIEM就不能不提SOC，国内的SOC实际就是一个SIEM产品，而国外的SOC，除了产品还有人，流程等，因此可以基于SIEM产品去建立一个SOC。去年HP以15亿收购Arcsight后，有意思的是其股东抱怨价格过低。Arcsight是SIEM领域的Leader，事实上国内的大部分SOC产品都是模仿Arcsight（先代理后模仿），Arcsight是专注做SIEM的厂商，不象是Symantec，因为专注所以其产品的一个特点就是细节的地方到位，我很佩服那些开发者，软件做的很精致，简洁易用功能强大，可以满足最大规模的企业应用，最著名的一个客户就是国防部。
SIEM系统分为三层：采集层、分析层、展现层，这三层中，采集层是最基础的，分析层是核心层，展现层我认为倒不那么重要，因为既然都有分析结果了，如何展现也就相对简单了。实际中发现即使Arcsight最领先的ESM仍然存在一些问题，并以此为例讨论一下：
标准化问题：采集层的标准化是个极为头疼的问题，尤其是Syslog。开发人员在对现有产品做标准化映射时，由于缺乏对产品的了解或者缺乏运维等经验，导致标准化后丢失某些关键信息，而很多SIEM产品除了字段不足外更是缺乏灵活的定制能力，要支持一个新的产品和应用，将会很困难。更严重的是，由于缺乏足够的扩展能力，针对业务系统定制时，不得不丢弃大量的字段（虽然可以合并），例如要从数据库读取一个表，有80个字段，参与关联分析的字段会可能有40个，但由于无法扩展不得不丢弃或者合并；
关联分析：SIEM的真正价值不仅仅为了满足合规，而在于异构、多系统间的关联分析，但当前所有的产品均是着重对基础设施的关联分析，有些会有一些针对业务的解决防范，如银行卡等，但由于对业务层面了解不够，从而缺乏真正有效的针对业务层面的威胁分析，我想这是Arcsight的防欺诈解决方案在国内至今还没有成功案例的原因之一；
缺乏预警机制：由于SIEM是通过收集其他产品的日志进行分析，意味着最多只能做到事中监视，比如蠕虫爆发，而无法实现事前预警。Symantec SSIM唯一的优势就是可以借助其分布在全球的数万台安全探针所形成的一个僵尸网络库，SSIM系统可以和这个库进行关联分析，实现一定程度的预警；而Arcsight曾经帮助一个银行用户建立反钓鱼系统，但是由于缺乏这些数量庞大的安全探针，只能在客户的邮件网关上进行采集分析，因此我估计效果将会大受限制；
融合不够：为了采集日志，往往要在被采的对象上安装agent，但既然安装了agent，为什么不索性连网管的数据一起采集？在SIEM实现监视告警，和网管系统整合成为一个平台？可惜在其5.0的系统中，还未看到融合，相反国内的厂商开始融合，而这些厂家就是从网管起家的，吼吼；
缺乏策略配置管理：从长远看，SIEM作为安管系统也应该实现统一的策略配置管理，尽管这个难度比日志标准化更大，却是今后的一个挑战和方向，这是当前许多用户的需求，DSL有个TR069，但企业这块还缺乏一个统一的标准，各管各的一亩三分地；
后记： CISCO的MARS早就不玩了，RSA的eVsion停止不前，而据小道消息Symantec的SSIM已经不再开发支持。Arcsight有了HP的渠道支持，还将一支独秀，钱途光明。其基于BI的分析模块我将在一个卡系统中验证其功能，看到底能发挥多大功能，并希望对这块有研究的高手多多指教。

分享

分享

Looking Back on the Language and Hardware Revolutions: Measured Power, Performance, and Scaling
Hadi Esmaeilzadeh¹,  Ting Cao²,  Xi Yang²,  Stephen Blackburn²,  Kathryn McKinley^1
1The University of Texas at Austin, ²Australian National University

点击这里下载 阅读 final-asplos021

Abstract:

This paper reports and analyzes measured chip power and perfor-mance on five process technology generations executing 61 diversebenchmarks with a rigorous methodology. We measure representa-tive Intel IA32 processors with technologies ranging from 130nmto 32nm while they execute sequential and parallel benchmarkswritten in native and managed languages. During this period, hard-ware and software changed substantially: (1) hardware vendors de-livered chip multiprocessors instead of uniprocessors, and indepen-dently (2) software developers increasingly chose managed lan-guages instead of native languages. This quantitative data revealsthe extent of some known and previously unobserved hardware andsoftware trends.    Two themes emerge. (I) Workload: The power, performance,and energy trends of native workloads do not approximate managedworkloads. For example, (a) the SPEC CPU2006 native benchmarkson the i7 (45) and i5 (32) draw significantly less power than managedor scalable native benchmarks; and (b) managed runtimes exploitparallelism even when running single-threaded applications. Theresults recommend architects always include native and managedworkloads to design and evaluate energy efficient designs. (II) Ar-chitecture: Clock scaling, microarchitecture, simultaneous multi-threading, and chip multiprocessors each elicit a huge variety ofprocessor power, performance, and energy responses. This varietyand the difficulty of obtaining power measurements recommendsexposing on-chip power meters and when possible structure spe-cific power meters for cores, caches, and other structures. Just ashardware event counters provide a quantitative grounding for per-formance innovations, power meters are necessary for optimizingenergy.

很高兴有一篇paper进到了ASPLOS (ASPLOS 是Architecture, programming language, operating system 结合领域的最好会议)。虽然我是Co-author，但也从这个paper里边学到了很多东西。这篇paper其实是我们去年在ISCA一个workshop上发的一篇论文的后续工作（H. Esmaeilzadeh, S. M. Blackburn, X. Yang, and K. S. McKinley, “Power and Performance of Native and Java Benchmarks on 130nm to 32nm Process Technologies,” in Sixth Annual Workshop on Modeling, Benchmarking and Simulation, MoBS 2010, Saint-Malo, France, 2010 http://users.cecs.anu.edu.au/~steveb/downloads/pdf/javavc-mobs-2010.pdf)

目前我在ANU读Master. 我自己的research领域是内存管理，大概想法就是在Run-time (JVM) 层面，把application的语义带进系统。一些paper在review过程，最后结果出来后我会在这写总结。 功耗是我RA部分的工作。 这两篇文章最开始的时候挺好玩。我记得最早的时候是 Hadi (这个系列文章的一作) 有一篇讨论 Dark silicon 的文章，然后我们开会一起讨论。在文章里边有一些是基于TDP或者模型的功耗计算, 我觉得基于模型的完全没有意义，建议测量真正的功耗。Hadi的文章里边讨论了power density 随着工艺变化对系统的影响。 印象中我在 linux symposium 看过一篇测量CPU功耗的文章。然后检查ATX的specification, 主板上4个pin的口是给CPU专门供电的，这样我们只需要一个电流计就可以测量CPU的功耗了。我当时奇怪的是为什么在学术界用类似的方法去测量功耗的很少，大部分是无意义的模型。再加上我们实验室正好有一些不同工艺和不同微结构的PC机。同时老板们是 managed language领域的专家。  那去从功耗的角度，不同工艺不同微结构对native language 写的 benchmark 和 managed language 写的 benchmark 的影响显然是我们关心的一个问题。然后就开始了漫漫测量路。

这是一篇测量文章，或者说是一个抛砖引玉的文章。所有的数据大家都可以访问，每个人的背景不同，看到的和想到的也不同。在ASPLOS review的过程中，有的reviewer 给了非常高的分数，但也得到了非常低的分数。文章接受以后，量化的两位作者对这个论文非常感兴趣，他们也给了我们很多很好的建议。 Dave 让他的一个学生用 data mining 的办法去评估体系结构不同的变化对系统的影响 (Mining火啊，看看Zhou Yuanyuan的文章)。 John 则对 SMT 的 power efficiency 非常感兴趣。 其他成员在和 两位牛人讨论的时候我正好在国内，非常遗憾的错过了这个机会。不过从邮件里边还是看到了两个大牛的风采，思路非常清晰。很多公司也对这个paper很感兴趣。IBM 和 Intel 都很喜欢并且邀请老板去讲了一下。我其实很不解的是难道Intel 或者 IBM 内部没有做过这样的分析？

我想再强调一遍，这是一个抛砖引玉的文章。借用文章里边的一句话 Measurement is key to understanding and optimization.

我总结一下这篇文章我个人的一些想法:

*这个论文讨论的是硬件的变化。但是如果把硬件的变化当成一个镜子。镜子里边就是软件的行为。可以说软件对CPU资源的利用是非常非常差的。这个里边充满了机会。比如说double cache, 性能基本没什么变化。 Yale Patt, 曾经说“CPU厂家实在不好意思再加大cache了”。 其实这句话反过来就是 “你们作软件的怎么这么垃圾！！“。 但是这里边机会多多！！！

*Managed language workload 的重要性。他们一般都有一个run-time system 作 Jit, 内存管理，和 其他的一些管理工作。 即便是single thread 的 managed language applications 也能够在多核下得到加速。同时 run-time system 对功耗，性能的影响非常大。CPU厂家应该重视起来这部分。目前就小道消息，硬件厂商内部貌似队这些理解不是很深刻。

*软件对功耗的影响非常大。比如同样的Java application, 不同的 JVM，跑出来的 performance, power, energy 差距非常大。目前CPU还没有一个类似performance counter  的东西帮助软件优化。

*对功耗决定性作用的其实是工艺。但是把成本考虑进来以后就不好说了。

*Energy efficiency 的 SMT。 ARM 貌似调侃过 P4年代的 SMT。 但是我们的结果显示从 energy & power efficiency 角度， SMT 是非常好的。这也许是 Intel 把 SMT 又高回来的原因。当然，想在 SMT 下边获得非常好的性能还是需要考虑很多 resource contention 的问题。

*强大的 Tick-Tock. Tock的时候尝试新的微结构，利用尽可能多的transistor，性能, power都上去 然后 Tick 的时候 die shrinking，功耗会下来，成品率会上去，可以提高频率。 这个基本就跟一个战车一样。 你说ARM能来 高端市场和 intel 打拼一下？ 我看现在根本没有机会。

*引入多核的一个重要的原因是功耗。 打个比方，同样推高一个core frequency 20%, 不如两个Core 同时推高5%。这是其实是不得不走多核的一个非常重要的原因。

有兴趣的读着可以下载数据自己分析。

严重感谢首席，没有您多年来的指导和鼓励，我根本不可能懂 architecture, operating system, compiler! 感谢CLF上边前辈门留下的只言片语。比如首席当年没提过L4， V总当年没提过RTEMS，我本科的毕业设计也不会去作 RTEMS ON L4。

分享

分享

Single CPU, Multi-core, Chassis based, Cluster, Distributed 的网络系统设计，是软件和硬件co-design的过程，硬件方面，诸如ASIC, FPGA, Co-processor, Network processor, Switch fabric, Memory controller等问题，不在本文的讨论范围之内，本文作者也不太了解这方面的知识。但从软件方面来说，首先要面对的是如何分配计算资源：SMP或者AMP，这就涉及到操作系统选择（开源操作系统很多，但都不是为网络设备优化过的，网络设备也是一个嵌入式设备，但是协议栈是通用协议栈，用来做网络设备可能稍差点），编程方式选择（在内核还是在用户空间），API（标准API，还是自己私有的API），程序库等等。然后是任务分配，任务分配的难点在于如何让系统的资源使用达到平衡，避免有些CPU太忙，而有些CPU太闲，在这里，Queue做为连接不同任务的节点就显得很重要。在接下来就是软件层次的划分，无状态包处理还是有状态包处理的选择，最后就是多CPU（chassis based，cluster, Distributed）的通讯，有很多库可以参考，比如MPI或者OpenMP。

当然，做为一个完整的系统，肯定还有很多东西需要考虑，比如内存管理，timer, ager，链表，哈希表，树等等具体的问题，这些都是细节，对系统的整体设计应该没有什么太大影响。硬件设计需要考虑系列化，可扩展；软件设计需要考虑通用，可移植，可扩展。从单CPU到多CPU，从单板到多板，再到多机。硬件可以scale out，软件同样可以scale out，这样的系统才是成功的系统。不管什么样的系统，从更高层次来看都是一样的，所以google的high performance web和cisco的high performance network，上层结构可能是一样的，这个要慢慢体会。

References（只列出了看过的，翻过的，见过的，其他的没有了，读者可以自己补充）

1: Network Systems Design Using Network Processors: Intel 2XXX Version

2: Network Systems Design with Network Processors, Agere Version

3: Network Flows: Theory, Algorithms, and Applications

4: Patterns in Network Architecture: A Return to Fundamentals

5: Pattern-Oriented Software Architecture Volume 1: A System of Patterns

6: Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects

7: Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management

8: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing

9: Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages

10: Design Patterns: Elements of Reusable Object-Oriented Software

11: Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices (The Morgan Kaufmann Series in Networking)

12: Network Routing: Algorithms, Protocols, and Architectures (The Morgan Kaufmann Series in Networking)

13: Designing Embedded Communications Software

分享

分享

［陈怀临注：原文来自：《创业家》2010年12月刊。感觉内幕消息确实不少。该知道的不该知道的；该写的不该写的；都写了。］

二十年前，一批大陆留学生在硅谷相继创办了自己的上市公司。十年前，他们回到中国开始以投资为主的第二人生。两世人生，哪一个是他们的顶峰？他们还会有第三次辉煌吗？
　　据《创业家》报道，邓锋缺席了华源会的年会，9年来这是第一次。
阅读全文»

分享

分享

重大新闻，刚刚获悉，陈首席第一代弟子的一篇文章(co-author)被体系结构红宝书的两位大师亲自（请注意，是亲自）推荐给了Intel的CEO Paul Otellini！当然不知道Paul的人请飘过！

这个弟子是我长期以来培养的，隐藏在学术界的一把利剑！是目前除了Panabit（大弟子，更关注与工程和系统实现方面）中最得意的弟子之一。

这个弟子天天就在这里灌水！

文章还没有最后finalized。该弟子会在ready之后发文。

首席我在前天其实已经得到该文章！

我非常兴奋和自豪！

分享

分享

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

分享

分享

原文发布于《计算机世界》2011年第3期

Nehalem 的遗憾

——英特尔Sandy Bridge 处理器分析测试之一

计算机世界实验室 盘骏

英特尔的“Tick-Tock” 战略已经为人熟知，根据这个策略，英特尔每年都会交替在处理器的制程和微架构上进行更新。上一年，英特尔将处理器工艺从45nm 提升到了32nm，今年，英特尔将处理器架构从Nehalem 升级到最新一代的Sandy Bridge，这个早期被叫做Gesher（希伯来文：桥梁）的处理器微架构担任着特别的桥梁角色。

Bridge 和Gesher 都含有桥梁的意思。而Sandy Bridge 微架构将这个含义发挥到了极致，它是一个集NetBurst 微架构与Nehalem 微架构大成的产品，也是一个首先将CPU和GPU 进行真正融合的产品，更是一个首先将浮点运算密度从128 位引向256 位的X86 处理器产品，它确实像是一个桥梁，引导着芯片设计上和计算模式上的转变。

Sandy Bridge 微架构为什么会是现在这个样子呢？ Sandy Bridge 在上一代Nehalem 微架构的基础上进行改进，如果不了解Nehalem 微架构，就无法真正理解Sandy Bridge的进化。

Nehalem 无疑是一个很成功的架构，QPI、IMC 带来的直联架构，再加上超线程的回归，其性能比起上一代提升了一到两倍以上，在企业级市场、主流乃至高端桌面市场以及移动市场的压倒性的占有率充分地说明了Nehalem 的强大。当然，Nehalem 微架构也不是完美的，以笔者的眼光看来，至少有几点Nehalem 微架构是有待改进的：

指令拾取和预解码

Nehalem 微架构在Pentium M微架构的基础上进行改进，整个流水线上几乎所有的组件都得到了增强，变化最少的就是在指令拾取和预解码阶段了。这个阶段的作用是将要执行的指令从L1 I-Cache 中提取到CPU 核心里面来，并随后对其进行预解码。预解码的主要作用就是在一块代码块中辨认每条x86 指令的长度。

和Penryn 一样，Nehalem 以及其改良版Westmere 都仍然采用了16Bytes 的指令拾取宽度，而竞争对手早已经采用了32Bytes 的拾取宽度。由于x86 指令的长度可以从1到15Bytes，因此在很糟糕的情况下，某个时钟周期拾取到的代码块里只包含一个x86 指令，和后端动辄6个、4 个uop（微指令）的能力不相符合。Nehalem 微架构的指令拾取/预解码单元无法跟上后端处理的速度，因此在运行计算密集型的代码中，它很容易成为瓶颈。

寄存器读停顿

这个情形发生在uop 经过RAT（Register Alias Table，寄存器别名表）进行寄存器重命名并发往ROB（ReOrder Buffer，重排序缓冲）之后，在这个被称为ROB-read 的流水线阶段中，uop 们需要读取相关的操作数，也就是读取对应的寄存器，如果这些内容在ROB 当中不存在的话。Nehalem 微架构的RAT 每时钟周期可以输出4 个uop，每个uop可以具有最多两个输入寄存器。这样它最多需要同时读取8 个寄存器。不幸的是，Nehalem 微架构用于保存寄存器的RRF（Retirement Register File，回退寄存器文件）仅具有3 个读取端口，无法充分满足寄存器读取的需求，这很容易导致ROB-read 以及前方流水线的停顿。

访存能力

Nehalem 微架构具有6 个执行端口，其中的3 个运算端口具有充足的计算能力，基本不会是瓶颈。然而，访存能力却不一定足够。Nehalem 微架构只有一个Load 载入端口和一个Store 保存端口。由于Load 操作是如此常见，可以达到uop 总数的1/3，因此相对于3 个运算端口，这个Load 端口是个潜在的瓶颈，特别是对于内存密集型计算来说。

最后， 早期的Nehalem 架构上还存在大页面TLB 数量较少的问题，TLB：Translation Lookaside Buffer，旁路转换缓冲，或称为页表缓冲，里面存放的是虚拟地址到物理地址的转换表。Nehalem 具有较多的标准4KB 页面TLB 项，但是更大容量页面的TLB 很少，因此，相对来说不适合大规模内存下的应用（如大型数据库和大型虚拟化环境，后来的Westmere 通过增加了对1GB 页面的支持缓解了这个问题）。

除了Nehalem 微架构的一些问题之外，英特尔或者说CPU 本身还面临着挑战，来自GPU 的挑战。目前，主要的GPU 厂商包括NVIDIA和AMD ATI 都提供了超越CPU 的强劲浮点处理能力，很多超级计算机通过采用了附加GPU 的方式获得了很强的计算指标。CPU 能力的增强导致了如硬件解压卡、独立声卡被融合进CPU，而GPU 强大的处理能力则被认为是CPU 的有力挑战者。如果运算能力足够强大，CPU 被GPU 取代也不无可能，英特尔怎么应对这个局面？ Sandy Bridge 进行了什么样的改进、能不能解决这些问题呢？请看下回分解。

分享

分享

23) stateless packet processing

Pattern Name and Classification: stateless packet processing
Intent:  简单，快速处理packet
Also Known As: stateless packet filter 
Motivation (Forces):

   无状态的包处理应该是一个很自然的选择，因为ip协议就是一个无状态的协议。无状态意味着每个包都是独立转发的，相互之间没有关系。无状态和有状态的主要区别在于包是否匹配session或者是flow（session和flow这两个词在大多数应用场景里面所指的东西是一样的，所以后面直接用session来代替了，读者明白这个意思就行）。session是路由，策略，MAC地址的cache，这个和“一次路由，多次交换”的机制是一致的。在无状态的处理过程中，每个包都需要查找路由，匹配策略，查找出口的MAC地址等；而在有状态的处理里面，如果存在session，先查找session；如果查找失败，再查找路由，匹配策略，然后创建session。

   无状态好处是在路由，策略，MAC地址等改变时，可以快速感知，而且可以做到per-packet的ECMP。但是无状态对某些应用是不可能实现的，比如NAT和IPSEC。NAT通常是session based，因为它要求同一个session的packet，转换后也是同一个session；IPSEC的每个包都是编号的，而且SA本身也要求有状态。从匹配效率来说，policy/acl/route 匹配并不一定比session匹配效率低，看具体应用。如果是单纯的包转发，当然是无状态处理好；如果要加上更多的service，比如netflow,nat, ipsec等，就需要有状态的处理。
Known Uses: router, switch, packet filter firewall
Related Patterns: stateful packet processing
References:

1: https://www.mikrotik.com/testdocs/ros/2.9/ip/flow_content.php

2: http://www.multicorepacketprocessing.com/

24) stateful packet processing

Pattern Name and Classification: stateful packet processing
Intent: 基于session或者flow的包处理
Also Known As: stateful packet inspection 
Motivation (Forces):

  stateful packet inpsection (SPI)是防火墙技术的一次飞跃。早期stateless packet filter防火墙，在处理动态协议时碰到了问题。而Checkpoint发明的SPI技术通过动态创建session来解决这个问题。所以stateful packet processing首要任务是创建session或者flow 。什么是session？session是cache；是什么的cache？路由，策略，MAC地址等。能够匹配session，就说明相应的流被允许通过，并且在这之上，有一系列处理。session一般是用五元组（协议，源地址，目的地址，源端口，目的端口）匹配的。在处理动态协议的时候，可能还需要用到expect（请参见linux netfilter），expect是一个不完整的session，在匹配expect之后，可能还需要匹配策略以确定expect是否可以转化成一个session。一句话，session是stateful packet processing的基础。

  stateful的好处是什么？一是有些应用必须是stateful的，比如前面提到的NAT，IPSEC，以及ALG等。stateful的坏处是什么？在系统状态变化时，比如路由，策略，MAC地址变化，维护session的状态比较困难。

Known Uses: stateful packet inspection firewall
Related Patterns: stateless packet processing
References:

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

2: Netfilter IPsec processing

3: http://netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html

4: http://www.soapatterns.org/stateful_services.php

25) per-packet service

Pattern Name and Classification: per-packet service 
Intent: 单包处理
Also Known As: packet-based service 
Motivation (Forces):

  不管是无状态还是有状态的包处理，有些应用是针对单包的，比如NAT，IPSEC。当然，在处理之前，这个包在IP层已经完成了分片组装。对基于UDP的协议来说，per-packet的处理是很自然的，但是对基于TCP的协议来说，由于协议的边界并不是IP包，所以per-packet的处理就不适用了。当然，对基于TCP的协议应用per-packet处理在很多情况下也能工作，只是不能适用于所有情况，特别是包在TCP层被分片的情况。

Known Uses: NAT, IPSEC etc
Related Patterns: stream service
References:

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

2: Per Packet Load Balancing

26) stream service

Pattern Name and Classification: stream service
Intent: 协议的边界是基于流的，需要针对流进行处理
Also Known As: stream-base service, proxy-based service
Motivation (Forces):

  基于TCP的协议，上层应用看到的是一个字节流，而不是单个的packet。协议的边界是基于流的，而不是基于单个包。所以，必须先完成流组装才能进行更高层的处理。协议是分层的，每一层做好自己的事就可以了。stream可以算一个层次，在这之上，有很多应用协议，比如http，还有很多基于http协议的应用协议，所以可能还需要一个http协议层。这样，每一层只关注自己的工作，向上层提供相应的服务。
Known Uses: DPI, URL filter etc
Related Patterns: per-packet service, tcp-proxy
References:

1: http://en.wikipedia.org/wiki/Flow_(computer_networking)

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

27) service plane

Pattern Name and Classification: service plane
Intent: 多种service组成一个有机的整体
Also Known As: application layer
Motivation (Forces):

(http://www.nsfocus.com/1_solution/1_2_10.html, 这张图来自绿盟的网站，如有版权问题，请联系本文作者)

  如上图，在有这么多service运行的情况下，如何把这些service组成一个有机的整体？  是callback based, event-driven, pool-based，或者其他？这些都是细枝末节，最重要的是把service的层次要定义出来，这样才能和传统的data plane区分开来。service这么多，调用顺序是一个问题；如何在规定的时间内完成处理是另一个问题（realtime系统的要求）；service之间如何通讯，service如何管理，service如何配置等等。netfilter做的完全动态，可扩展的框架就很不错，不过性能稍差一点，可以用做参考。
Known Uses: multi service gateway
Related Patterns: per-packet service; stream service
References:

1: http://www.nsfocus.com/1_solution/1_2_10.html

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

3: http://en.wikipedia.org/wiki/Osgi

4: http://en.wikipedia.org/wiki/Netfilter

28) tcp-proxy

Pattern Name and Classification:  tcp-proxy
Intent: 实现stream service
Also Known As: application proxy
Motivation (Forces):

  把tcp-proxy单列出来，看似有凑数之嫌，其实不然。我们常见的application proxy，比如squid，apache等，是应用层的代理，和这里所说的data plane的tcp-proxy完全不同。以squid为例，它完成代理，需要建两个socket，一个包进出内核，需要两次拷贝，这样的开销是不能容忍的。如果忽略内核空间与用户空间之间的内存拷贝，这个tcp-proxy应该能提供哪些功能？首先要支持多种应用协议，其次需要支持多种service（多个service，一个tcp-proxy），而且需要支持多个tcp-proxy同时运行（有可能是per-session的tcp-proxy）。tcp-proxy是TCP协议的一个完整实现，能够工作的实现已经不容易了，高性能的实现是很困难的事情，是业界的难题之一。
Known Uses: multi service gateway
Related Patterns: stream service; service plane
References:

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

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

分享

分享

         数据中心的虚拟接入是新一代数据中心的重点课题，各方已经争夺的如火如荼。目前网络上的中文资料还不多，根据自己的经验写了一点对虚拟接入的理解，意在丟砖，引出真正的大佬。

一、为什么虚拟化数据中心需要一台新的交换机

          随着虚拟化技术的成熟和x86 CPU性能的发展，越来越多的数据中心开始向虚拟化转型。虚拟化架构能够在以下几方面对传统数据中心进行优化：

• 提高物理服务器CPU利用率；
• 提高数据中心能耗效率；
• 提高数据中心高可用性；
• 加快业务的部署速度

         正是由于这些不可替代的优点，虚拟化技术正成为数据中心未来发展的方向。然而一个问题的解决，往往伴随着另一些问题的诞生，数据网络便是其中之一。随着越来越多的服务器被改造成虚拟化平台，数据中心内部的物理网口越来越少，以往十台数据库系统就需要十个以太网口，而现在，这十个系统可能是驻留在一台物理服务器内的十个虚拟机，共享一条上联网线。

           这种模式显然是不合适的，多个虚拟机收发的数据全部挤在一个出口上，单个操作系统和网络端口之间不再是一一对应的关系，从网管人员的角度来说，原来针对端口的策略都无法部署，增加了管理的复杂程度。

          其次，目前的主流虚拟平台上，都没有独立网管界面，一旦出现问题网管人员与服务器维护人员又要陷入无止尽的扯皮中。当初虚拟化技术推行的一大障碍就是责任界定不清晰，现在这个问题再次阻碍了虚拟化的进一步普及。

         接入层的概念不再仅仅针对物理端口，而是延伸到服务器内部，为不同虚拟机之间的流量交换提供服务，将虚拟机同网络端口重新关联起来。   

二、仅仅在服务器内部实现简单交换是不能的 

         既然虚拟机需要完整的数据网络服务，为什么在软件里不加上呢？

        没错，很多人已经为此做了很多工作。作为X86平台虚拟化的领导厂商，VMWare早已经在其vsphere平台内置了虚拟交换机vswitch，甚至更进一步，实现了分布式虚拟交互机VDS（vnetwork distributed switch），为一个数据中心内提供一个统一的网络接入平台，当虚拟机发生vmotion时，所有端口上的策略都将随着虚拟机移动。

        VMWare干得貌似不错，实际上在当下大多数情况下也能够满足要求了。但如果谈到大规模数据中心精细化管理，内置在虚拟化平台上的软件交换机还有很多问题没有解决。首先，目前的vswitch至多只是一个简单的二层交换机，没有QoS、没有二层安全策略、没有流量镜像，不是说VMWare没有能力实现这些功能，但一直以来这些功能好像都被忽略了；其次，网管人员仍然没有独立的管理介面，同一台物理服务器上不同虚机的流量在离开服务器网卡后仍然混杂在一起，对于上联交换机来说，多个虚拟机的流量仍然共存在一个端口上。

         虚拟平台上的软件交换机虽然能够提供基本的二层服务，但是由于这个交换机的管理范围被限制在物理服务器网卡之下，它没法在整个数据中心提供针对虚拟机的端到端服务，只有一个整合了虚拟化软件、物理服务器网卡和上联交换机的解决方案才能彻底解决所有的问题。

         这个方案涉及范围如此之广，决定这又是一个只有业界大佬才能参与的游戏。

三、谁在开发新型交换机？ 

        HP，Cisco。

        一个是PC服务器王者，近年开始在网络领域攻城略地，势头异常凶猛；一个是网络大佬，借着虚拟化浪潮推出服务器产品，顽强地挤进这片红海。

        针对前文所说的问题，两家抛出了各自的解决方案，目的都是重整虚拟服务器同数据网络之间那条薄弱的管道，将以往交换机上强大的功能延伸进虚拟化的世界，从而掌握下一代数据中心网络的话语权。

Cisco和VN-TAG

          虚拟化平台软件如VMWare ESX部署之后，会模拟出一整套硬件资源，包括CPU、硬盘、显卡，以及网卡，虚拟机运行在物理服务器的内存中，通过这个模拟网卡对外交换数据，实际上这个网卡并不存在，我们将其定义为一个虚拟网络接口VIF（Virtual Interface）。VN-tag是由Cisco和VMWare共同提出的一项标准，其核心思想是在标准以太网帧中增加一段专用的标记—VN-Tag，用以区分不同的VIF，从而识别特定虚拟机的流量。

          VN-Tag添加在目的和源MAC地址之后，在这个标签中定义了一种新的地址类型，用以表示一个虚拟机的VIF，每个虚拟机的VIF是唯一的。一个以太帧的VN-Tag中包含一对这样新地址dvif_id和svif_id，用以表示这个帧从何而来，到何处去。当数据帧从虚拟机流出后，就被加上一个VN-Tag标签，当多个虚拟机共用一条物理上联链路的时候，基于VN-Tag的源地址dvif_id就能区分不同的流量，形成对应的虚拟通道，类似传统网络中在一条Trunk链路中承载多条VLAN。只要物理服务器的上联交换机能够识别VN-Tag，就能够在交换机中直接看到不同的VIF，这一下就把对虚拟机网络管理的范围从服务器内部转移到上联网络设备上。

          思科针对VN-Tag推出了名为Palo的虚拟服务器网卡，Palo卡为不同的虚拟机分配并打上VN-Tag标签，上联交换机与服务器之间虽然只有一条网线，但通过VN-Tag上联交换机能区分不同虚拟机产生的流量，并在物理交换机上生成对应的虚拟接口VEth，和虚拟机的VIF一一对应，好像把虚拟机的VIF和物理交换机的VEth直接对接起来，全部交换工作都在上联交换机上进行，即使是同一个物理服务器内部的不同虚拟机之间的流量交换，也通过上联交换机转发。这样的做法虽然增加了网卡I/O，但通过VN-Tag，将网络的工作重新交回到网络设备。而且，考虑到万兆接入的普及，服务器的对外网络带宽不再是瓶颈，此外，利用Cisco Nexus 2000这种远端板卡设备，网管人员还能够直接在一个界面中管理数百台虚拟机，每个虚拟机就好象在传统的接入环境中一样，直接连接到一个交换机网络端口。

         目前，思科推出的UCS服务器已经能够支持VN-tag，当Palo卡正确安装之后，会对上层操作系统虚拟出多个虚拟通道，每个通道对应一个VIF，在VMWare EXS/ESXi软件中可以将虚拟机绕过vswitch，直接连接到这些通道上，而在UCS管理界面上则能够看到对应的虚拟机，使网管人员能够直接对这些端口进行操作。

          Cisco同VMWare已经将向IEEE提出基于VN-Tag的802.1Qbh草案，作为下一代数据中心虚拟接入的基础。

HP和VEPA

          Cisco提出的VN-Tag，在IT业界引起的震动远远大于在客户那得到的关注，如果802.1Qbh成为唯一的标准，Cisco等于再一次制定了游戏规则，那些刚刚在交换机市场上屯下重兵的厂商，在未来数据中心市场上将追赶得异常痛苦。此外，VN-Tag是交换机加网卡的一揽子方案，还能够帮助Cisco快速切入服务器市场，对其他人来说是要多不爽有多不爽。

         很容易猜到，这其中最不爽的就是HP，在交换机和服务器领域跟Cisco明刀明枪地干上之后，被这样摆上一道，换谁也不可能无动于衷。HP的应对很直接，推出一个类似的方案，替代VN-Tag。

          HP的办法称为VEPA（Virtual Ethernet Port Aggregator），其目的是在部署了虚拟化环境的服务器上实现同VN-tag类似的效果，但VEPA采取了一条截然不同的思路来搭建整个方案。

          简单来说，VEPA的核心机制就是两条：修改生成树协议、重用Q-in-Q。

          VEPA的目标也是要将虚拟机之间的交换行为从服务器内部移出到上联交换机上，当两个处于同一服务器内的虚拟机要交换数据时，从虚拟机A出来的数据帧首先会经过服务器网卡送往上联交换机，上联交换机通过查看帧头中带的MAC地址（虚拟机MAC地址）发现目的主机在同一台物理服务器中，因此又将这个帧送回原服务器，完成寻址转发。整个数据流好象一个发卡一样在上联交换机上绕了一圈，因此这个行为又称作“发卡弯”。

         虽然“发卡弯”实现了对虚拟机的数据转发，但这个行为违反了生成树协议的一项重要原则，即数据帧不能发往收到这个帧的端口，而目前虚拟接入环境基本是一个大二层，因此，在接入层，不可能使用路由来实现这个功能，这就造成了VEPA的机制与生成树协议之间的矛盾。

         但是VEPA没有vPC，在接入层还是要跑生成树。HP的办法就是重写生成树协议，或者说在下联端口上强制进行反射数据帧的行为（Reflective Relay）。这个方式看似粗暴，但一劳永逸地解决了生成树协议和VEPA机制的冲突，只要考虑周全，不失为一步妙棋。

         除了将虚拟机的数据交换转移到物理服务器上之外，VN-Tag还做了一项重要的工作，就是通过dvif_id和svif_id这对新定义的地址对不同虚机流量进行区分。HP在这里的搞法同样简单直接，VEPA使用Q-in-Q在基本的802.1q标记外增加了一层表示不同虚拟机的定义，这样在VLAN之外，VEPA还能够通过Q-in-Q区分不同的虚拟机，只要服务器网卡能够给数据帧打上Q-in-Q标记，上联交换机能够处理Q-in-Q帧，基本就可以将不同的虚拟机流量区分开来，并进行处理。

           至此，VEPA看起来已近能够实现同VN-Tag类似的功能，因此HP也将VEPA形成草案，作为802.1Qbg的基础提交至IEEE。不得不说，VEPA是个非常聪明的设计，不管是对生成树行为的修改，还是利用Q-in-Q都不是什么不得了的创新，目前的交换机厂商只要把软件稍微改改，就能够快速推出支持802.1Qbg的产品，重新搭上数据中心这班快车，追上之前被Cisco甩下的距离。

VN-Tag和VEPA

           自从Cisco祭出VN-Tag大旗后，各种争议就没停过，直到HP推出VEPA，这场口水仗达到高潮，随着2011年，802.1Qbh和802.1Qbg标准化进程的加快，围绕虚拟接入下一代标准的争夺将进入一个新的阶段。

          这也不难理解，随着数据中心内虚拟机数量的不断增加，越来越多的物理网口转化为虚拟的VIF，如果一家网络厂商没法提供相应的接入解决方案，它的饼会越来越小，活得非常难受。

          VN-Tag就是Cisco试图一统下一个十年数据中心的努力，HP虽然同思科正面开战时间不长，但从VEPA来看，其手法相当老辣。由于VEPA没有对以太网数据结构提出任何修改，实现成本非常低，以往被思科扫到大门之外的厂商，一下子见到了曙光，前仆后继地投靠过来，Juniper、IBM、Qlogic、Brocade等等都毫不掩饰对VEPA的期待，Extreme甚至表示，已近着手修改OS以保证对VEPA的支持。待各方站队结束，大家发现Cisco虽然有强大的盟友VMWare，但另外一边几乎集结了当今网络界的所有主流厂商，舆论也逐渐重视VEPA的优点，甚至Cisco自己也不得不松嘴说会考虑对802.1Qbg的支持。

          戏演到这里，很多人幸灾乐祸地等着看Cisco怎么低头。但有一个问题，VEPA这么完美，为啥Cisco之前没有采用类似的思路？仅仅为构建一个封闭的体系架构吗？我认为不是。

          回答这个问题前，我们首先要弄清楚另一个问题。以VMWare ESX/ESXi为例，由于ESX/ESXi自带的vswitch只是模拟了一台二层交换机，当一台物理服务器上两个处于不同VLAN的虚拟机之间需要交换数据时，vswitch是无能为力的。只能将数据送到上联物理交换机上，由物理交换机完成VLAN间的三层转发。听起来是不是很熟悉？这和之前提到的VN-Tag与VEPA的机制很相似，如果现有的虚拟化环境已经能够将数据交换的行为转移到上联交换机，为啥还要大费周折地提出一个新标准呢？

          这是因为，当下的这种方案是利用VLAN来隔离不同虚拟机，通过TRUNK将对应多个虚拟机的VLAN送到物理交换机上。这种方式打破了数据中心内对VLAN的使用惯例，比如，网管人员通常会把负责同一业务的多台服务器放在一个VLAN内，如果VLAN标签都被用来隔离虚拟机了，则没法按照传统方式来区分不同业务，解决了一个问题，带来另外的问题，这是绝对行不通的。

           现在，我们可以回答之前的问题了，新一代的虚拟接入方案是要在不影响802.1Q等原有网络行为的前提下，完成对虚拟机的接入、区分和管理。有人会说，用PVLAN不可以吗?但我们怎么保证PVLAN没有其他的用处呢？出于这样的思路，Cisco没有利用现有的任何技术，提出了一个全新的实现方案，正因为VN-Tag从出生起就“干干净净”，同谁都没有瓜葛，因此VN-Tag携带的信息就能够在整个数据中心内自由的传递，从而快速为用户搭建起一个清晰、完整的虚拟接入平台，所谓“磨刀不误砍柴工”。

            HP充分利用了现有条件，VEPA的整个架构看上去简洁、高效，但是对生成树协议改动和利用Q-in-Q无疑会影响到现网的行为。生成树协议的效率和问题一直是个老大难，但无数聪明绝顶的高手琢磨了这么多年，协议的变动仍然不大，说明对这种基本协议的修改不是一蹴而就的，往往迁一发而动全局，现有的模式是各方协调、妥协的结果。VEPA要在短时间内拿出一个完美的方案，所需花费的精力也许并不比重新提一套方案少。

            除了协议本身之外，摆在HP和VEPA面前还有两个难题，首当其冲就是VMWare的支持。VEPA虽然对交换机硬件改动不大，但要真正跑起来，还需要虚拟化平台软件的支持，虚拟网卡和虚拟交换机得主动把所有数据帧扔到上联交换机上，后面的故事才能续上。可是VMWare还是Cisco在VN-Tag上最大的盟友，虽然Cisco已经表示会支持802.1Qbg，但会有多及时就难说了。

           时间也就是VEPA的第二个困难。目前，思科的UCS服务器已经能够提供端到端的VN-Tag部署。而HP的Virtual Connect解决方案仅实现了Q-in-Q的多链路，对“发夹弯”的支持并不好，也没有VMWare的支持，说白了，VEPA还只是图纸上的设计，没有实际产品支撑。此外，虚拟接入只是下一代数据中心组成之一，FCoE、THRILL等都非常重要，针对这些技术，HP仍拿不出成型的产品，相反，Cisco在所有领域几乎都布局完毕，留给HP的时间不多了。

           这场针对数据中心接入的争夺，在2011年必将愈演愈烈，Cisco携全线产品势在必得，而HP的VEPA评价聪明的设计，得到业界广泛支持，故事结局如何，还待静观其变。

分享