华山论剑新解--软件硬件谁在引领IT技术革命？（获奖名单已公布-2014-6-5）

Heng_Liao

回复 122# niugb

双重数据保护的系统框图：


供你参考。


   

Heng_Liao

回复 126# niugb


同意。最适合容量大的冷存储。单位容量的成本降低。
不过现在Hadoop HDFS依乎流行在各种数据存储，超出了原本map reduce的范畴。你觉得有可能把HDFS或其它3拷贝的分布式文件存储的块层改为这种保护机制吗？如能这样，应用范围就能涵盖更广些。
你看呢？

Heng_Liao

回复 134# ssailing


ssailing:
1）Guest 有某种机制获得真实的物理地址，则可以利用SAS例子中的机制，将数据分段传输出去。这种方案要求guest OS必须感知虚拟化环境，且能通过半虚拟化的方式获得GPA到HPA的映射关系，从而获得HPA。这种方案不支持全虚拟化方式，必须要求guest OS通过半虚拟化实现该驱动
2）其他硬件机制实现GPA到HPA的转化，对guest OS透明。也就是当前IOMMU中的DMA remaping技术。好处是性能高，对guest OS透明，但是需要专门的硬件支持。



楼主所言极是, Intel VT-d 确实通过IOMMU解决了GPA 到HPA的转换。这个方式使得虚拟机的效率提高，并且以广为采用 。
补充一下，在上述SAS 作DMA的例子，有3个地址空间的转换：

Guest Virtual Address  (GVA) ----> Guest Physical address (GPA) ---> Host physical address (HPA).

1）SGL 解决的是 GVA ---> GPA 的转换。
2）IOMMU 解决的是GPA ---> HPA 的转换问题。

这两部地址转换都会导致逻辑上连续的空间在转换后变成不连续的碎片。
在实际系统典型的实现中，通过硬件DMA 以 SGL的方式解决1）， 而用IOMMU解决2）。


   

Heng_Liao

回复 135# ssailing

楼主对采用几种协议来组SAN的优缺点作的总结十分精辟。完全同意。

其实这些协议在地下2层，差异变得越来越小了（都是在串行的总线上以某种数据格式收发数据包），具体到实现SAN的业务，如果能把业务的数据平面的功能以适合硬件实现的方式固定化，就可以对该业务实现低成本和高效率。这包括了业务功能的固定化，还有相关的数据可靠性的保证的方式。其实IP/Ethernet作为网络协议的持久的生命力，是个不争的事实。可惜它依赖的TCP来提高可靠传送的机制，即是它保持灵活简单可扩展的优点，同时也是个硬伤，因为TCP始终是个软件协议／并是网络协议栈的核心，任何在它之上的业务都难以剥离到硬件实现中，所以跑存储业务总是不顺畅。否则，以太网一统岂不太平？

另外，如果所有存储都从计算分离，需要为每个计算节点提供的SAN业务带宽能达到分离前的DAS带宽（大约为以往局域网NIC带宽的10倍），在此前提下， 以太网是否还是最经济的选择？（每个服务器节点要提供100G的以太网街口，TOR 交换要提供大约48个100G口，今天还很贵吧？）。

楼主怎么看？

Heng_Liao

回复 144# ssailing

久等了：老天爷作对，这一贴，操作失误，连续丢失了３遍，重写了４次才贴上来。
   

ssailing 发表于 2014-05-19 23:36




1、TCP实现的传输可靠性导致必须有软件参与的问题，FCoE很好的解决了这个问题，其利用DCB/CEE lossless ethernet的一些增强特性，让FC协议跑在可靠的二层以太网链路上
2、带宽问题，10GE在数据中心已经开始广泛应用了，加之不久机会应用的40GE，其余FC的带宽差异已经很小了，这也让FCoE有了更好的发挥空间。同时iSCSI的带宽劣势也进一步缩小
3、延时/CPU开销问题，iSCSI在收发两端都需要软件参与协议转换，因此延时较大，最重要的是在主机端需要占用一定的CPU资源，因此需要ToE  TCP/IP offload engine功能，但这样的网卡成本较高

高带宽、低延时、高可靠性，这几个特性也正是Intel RSA方案中的核心 100G 光互联技术所解决的问题，在100G的物理层上跑的是以太网的协议，并且支持lossless ethernet功能，大有一统江湖之势，但短期内这个方案还落不了地，并且初期的成本肯定比较高

PCIe的方案在未来3-5年 基于rack级别的组网还是具备一定的可行性，成本带宽等综合考虑还是不错的  但还是要提供更多的网络类似的特性 才能走得更远...

1)        基于TCP的iSCSI，即使使用了高级Offload的网卡也跑不快，单个服务器节点带不动40G iSCSI， 详见：
  新型I/O架构引领存储之变（二）
http://blog.csdn.net/pmc/article/details/25370131
FCoE 是Cisco等发起的第二次十字军东征。 在这点上我同意冬瓜头，结果恐怕凶险。在超大规模数据中心组网上， Cisco以丢失了大本营 ---- 交换机已被SDN+定制白盒交换机取代。 关键的Lossless Ethernet, 没有见到有部署的用例。

2)        带宽问题，我同意楼主， 第一是：只要有需求，迟早会解决，硅光的技术还能把带宽推上台阶。 第二是：不管用那个协议，物理带宽要达到的速度是共同的，而且成本也基本相同。 第三点：前面论述了iSCSI, FCoE, SAS, FC, PCIe, 都有很多问题，是个两难的选择。以太网的生命力强是大家的共识。在数据中心，很可能会以面向应用的私有的协议（承载在以太网上）的方式继续发展。
3)        iSCSI, 乃至任何基于TCP的协议，如果单线程带宽低的应有，还没问题（可汇聚成大带宽），但单线程带宽高的业务，TCP已成为网络通信的最大瓶颈。除了上述博客文章的分析，我还可提出另一组参考数据：在采用高级网卡的前提下， 每1Gbps单线程TCP要消耗大约0.5Ghz的单线程CPU性能。大家算算看吧。 因此，即使是私有的协议，也要规避TCP带来的问题才可行。
PCIe要解决很多组网方面的问题。这个我们正在努力。不过，我心里一直在想，到底有什么办法可以回到以太网上来解决这个问题？我们要的是：
A）        Lossy Ethernet – 可丢包的以太网
B）        高效的可靠的远程DMA机制，能保证数据可靠传送。
C）        纯硬件实现，不能用TCP
D）        同时，还要和TCP共存，即一张网卡上必须保留原有的完整的功能，不可以触碰到现有的网络协议栈。

Heng_Liao

回复 145# 冬瓜头


  IOMMU　解决的是GPA --> HPA 的转换，并不需要NIC, SAS IOC的支持。在今天VMware等Hypervisor 环境中，我相信网卡，SAS IOC的访问都用到了IOMMU, 即Intel VT-d的技术。

Heng_Liao

回复 146# 冬瓜头

冬瓜头 发表于 2014-05-20 08:38
1. ToE网卡，看offload到什么程度。目前主流nic控制器对tcpip一些非核心状态机相关的外围模块比如checksum，mtu分片，tss分片之类都可以offload。2. 将整个TCPIP全部offload到网卡的话，这种卡用起来就比较尴尬，如果要承载通用tcpip流量的话，就需要驱动向sokect高层去hook，这块很少有人搞，不知道内核会否有bug，windows不开源就更不可知了；另一种用法是直接将某个应用层和TCPIP一起offload到卡里去，比如iscsi initiator，这样的话，就是一张iscsi卡，和sas、fc卡没有区别，驱动直接向scsi mid layer挂接，但是这张卡也就只能跑iscsi流量了。
3. 个人不太看好FCoE。这个技术拖得太长了，而且预后也不佳，它的名字仿佛就决定了它的命运，FC的发展已经几近停滞，预后很差，一个新东西的命名基础如果是想延续老事物的生命，往往不太好，需要破旧立新。网络统一是好事情，但是很少有用户真把现存的FC和以太网融合起来的，假设就算有不少这类需求，结果FCoE也并没有用很简单的方法来满足，而是需要升级到CEE交换机，这一点用户有抵触，如果不升级，那就得买专用FCoE交换机，非常昂贵，FC和以太网都接到这台交换机，那么就相当于为了融合本身而融合，这显得没意义，另外FCoE一开始不支持多交换机级联，还要搞出Multi hop FCoE的概念，本来是为了简单、融合、便捷，结果成了复杂、封闭、昂贵，与初衷背道而驰。 ...

   
1)        ToE，　这些都是隔靴搔痒，不能从根本上解决问题. 即TCP协议的数据通道上必须有软件的参与，而不能完全硬件化。这个要怪互联网历史上的两大名人：
Van Jacobson, 设计了对硬件完全不友好的协议。
Linus Torvalds, 完全排斥硬件掌控TCP协议栈的可能。
当然这些高人的理念自有他们的道理，但结果是TCP 不能被硬件化。
2/3) 同意冬瓜头的高见！

Heng_Liao

回复 147# 冬瓜头

冬瓜头 发表于 2014-05-20 08:53
关于tcpip运行在host内核还是运行在芯片firmware里更快的问题。个人肤浅理解，还请廖博指正，这也是一直以来 ...

看来还是逃不脱对这个问题展开讨论。
我们看看Wikipedia 怎么说：
TCP is a complex protocol. However, while significant enhancements have been made and proposed over the years, its most basic operation has not changed significantly since its first specification RFC 675 in 1974, and the v4 specification RFC 793, published in September 1981. RFC 1122, Host Requirements for Internet Hosts, clarified a number of TCP protocol implementation requirements. RFC 2581, TCP Congestion Control, one of the most important TCP-related RFCs in recent years, describes updated algorithms that avoid undue congestion. In 2001, RFC 3168 was written to describe explicit congestion notification (ECN), a congestion avoidance signaling mechanism.
The original TCP congestion avoidance algorithm was known as "TCP Tahoe", but many alternative algorithms have since been proposed (including TCP Reno, TCP Vegas, FAST TCP, TCP New Reno, and TCP Hybla).
TCP Interactive (iTCP) [28] is a research effort into TCP extensions that allows applications to subscribe to TCP events and register handler components that can launch applications for various purposes, including application-assisted congestion control.
Multipath TCP (MPTCP) [29][30] is an ongoing effort within the IETF that aims at allowing a TCP connection to use multiple paths to maximise resource usage and increase redundancy. The redundancy offered by Multipath TCP in the context of wireless networks [31]enables statistical multiplexing of resources, and thus increases TCP throughput dramatically. Multipath TCP also brings performance benefits in datacenter environments.[32] The reference implementation[33] of Multipath TCP is being developed in the Linux kernel.[34][35]
TCP Cookie Transactions (TCPCT) is an extension proposed in December 2009 to secure servers against denial-of-service attacks. Unlike SYN cookies, TCPCT does not conflict with other TCP extensions such as window scaling. TCPCT was designed due to necessities of DNSSEC, where servers have to handle large numbers of short-lived TCP connections.
tcpcrypt is an extension proposed in July 2010 to provide transport-level encryption directly in TCP itself. It is designed to work transparently and not require any configuration. Unlike TLS (SSL), tcpcrypt itself does not provide authentication, but provides simple primitives down to the application to do that. As of 2010, the first tcpcrypt IETF draft has been published and implementations exist for several major platforms.
TCP Fast Open is an extension to speed up the opening of successive TCP connections between two endpoints. It works by skipping the three-way handshake using a cryptographic "cookie". It is similar to an earlier proposal called T/TCP, which was not widely adopted due to security issues.[36] As of July 2012, it is an IETF Internet draft.[37]
Hardware implementations[edit]
One way to overcome the processing power requirements of TCP is to build hardware implementations of it, widely known as TCP Offload Engines (TOE). The main problem of TOEs is that they are hard to integrate into computing systems, requiring extensive changes in the operating system of the computer or device. One company to develop such a device was Alacritech.

我发表些谬论供大家参考：
１）        TCP 没有一个正则(formal)的单一规范（即以形式语言，或状态机表述）。而是一系列的自然语言的描述文本，有些描述属于需求性的描述而非行为性描述。因此最接近正则描述的就是广为人接受的Linux Kernel中的源代码。由于缺乏正则性描述，而又有诸多需求复杂性，因此，具体实现就成了规范，当然，也就带来了依赖于具体实现的性能局限和开销。比如，恐怕没有人能回答这个问题：TCP单一连接，可否以1Tbps的速率传送数据？因为相关的因素太多，连接的长度？网络延迟， 每一步骤所需的跳变世界，包长？数据长度？ ACK的到达时间，是否在不同阶段丢包？
２）        TCP在协议栈中所处的核心地位，对上，对下，都耦合了大量其它协议，这些协议是不同的软件模块，因此很难把它单独提取出来硬化。
３）        TCP的核心地位，直接影响系统稳定性，兼容性，还直接影响网络协议栈上层和下层的今后发展的耦合关系。因此， Linus要牢牢把握住Kernel 软件对它的绝对掌控，是考虑到这些大局的长远因素。
结论：ＴＣＰ不能完全硬件化，单一线程TCP的通信速度是不能无限提速的，协议本身已经成为性能瓶颈。想突破这个瓶颈，必须另辟蹊径。




   

Heng_Liao

回复 155# 冬瓜头

阅读了你附件中的Viking NVDIMM的材料。这类NVDIMM （哈哈，PMC也将会发表类似的产品哦）在存储容量上DDR和NAND需要容量相同的两份镜像。因此性能达到DDR, 访问也是以内存方式直接访问，而不采用block IO的存储协议栈，因此性能高。不过成本也高，考虑到目前单位存储的价格，DDR要比NAND高好几倍哦。因此，可作为特殊的非易失的高价内存使用。
当然，要用这个需要BIOS和Kernel的一系列小改动，包括文中提到的SAVE/RESTORE，还要特殊的nv_malloc等等，还得考虑这个特殊内存是否影射成cacheable, 还是uncached。 如果追求性能把它影射成cachable, 就得小心在适当时机把它writeback才能确信数据到了DIMM里面。这些小改动，对软件来说不是太大的问题。成本是个大问题。

我文中提到的NVDIMM当然包含了这类，但也考虑了更广泛的情况，如果NVDIMM上的DDR, 或RAM空间为了低成本，只是它的NAND的很小一部分，比如1%， 那这个RAM就只能作为访问整个NAND空间的一个小窗口，而且需要管理这个对换窗口的数据和NAND的对换/写回，动态移动窗口位置，淘汰算法， 还要对NAND FTL的管理等复杂功能，这些设计到的MMU代码的改动就比较可怕，而那部分功能适合在DIMM的内部由硬件/固件来做，那部分由主机的内核代码作，还有很多讲究需要研究。


   

Heng_Liao

回复 155# 冬瓜头

阅读了你附件中的Viking NVDIMM的材料。这类NVDIMM （哈哈，PMC也将会发表类似的产品哦）在存储容量上DDR和NAND需要容量相同的两份镜像。因此性能达到DDR, 访问也是以内存方式直接访问，而不采用block IO的存储协议栈，因此性能高。不过成本也高，考虑到目前单位存储的价格，DDR要比NAND高好几倍哦。因此，可作为特殊的非易失的高价内存使用。
当然，要用这个需要BIOS和Kernel的一系列小改动，包括文中提到的SAVE/RESTORE，还要特殊的nv_malloc等等，还得考虑这个特殊内存是否影射成cacheable, 还是uncached。 如果追求性能把它影射成cachable, 就得小心在适当时机把它writeback才能确信数据到了DIMM里面。这些小改动，对软件来说不是太大的问题。成本是个大问题。

我文中提到的NVDIMM当然包含了这类，但也考虑了更广泛的情况，如果NVDIMM上的DDR, 或RAM空间为了低成本，只是它的NAND的很小一部分，比如1%， 那这个RAM就只能作为访问整个NAND空间的一个小窗口，而且需要管理这个对换窗口的数据和NAND的对换/写回，动态移动窗口位置，淘汰算法， 还要对NAND FTL的管理等复杂功能，这些设计到的MMU代码的改动就比较可怕，而那部分功能适合在DIMM的内部由硬件/固件来做，那部分由主机的内核代码作，还有很多讲究需要研究。