http://www.dbaleet.org/about_rac-interconnectjumbo-frame
Jumbo Frame也叫9000字节帧， 此术语广泛的应用在计算机网络和存储网络行业。Jumbo在中文中的意思是“超大”。之所以叫它为超大帧，是因为传统的以太网的标准帧的最大值为1518字节，（其中数据帧1500字节， 头部大小14字节，CRC校验位为4字节）相比而言， Jumbo Frame几乎是其6倍。
那为什么要使用Jumbo Frame呢，也就是说它相比标准帧而言有什么好处呢？跟Oracle RAC的私网又有什么关系呢？
Jumbo Frame 相比传统的标准帧而言，其主要的优势在于它能减少在拆包，传输，解包过程中带来的CPU开销并且提升数据的传输效率。下面举个例子来说明一下传统的以太网标准帧对于Oracle数据块传输的一些不足之处：
Oracle数据库的块大小默认为8192字节， 如果使用以太网标准帧进行传输，至少需要将这个数据块拆分为至少6个帧进行传输。在发送的过程中，发送端网卡需要将数据块进行拆分，然后再进行发送，拆分数据块这个过程单靠网卡是无法完成的，主要依靠CPU进行计算，也就是这实际是一个软件算法。这么一来拆包的过程势必会造成一定额外的CPU开销，另外我们知道CPU是多线程的，频繁的拆包必然会带来较大的上下文切换（Context Switch）的开销。在传输的过程中，目标端的网卡一直在等待所有这六个数据包就绪，如果其中的一个发送失败，则需要重传，那么这个时间，目标端的网卡除了等待什么也不能做，直到6个数据帧全部传输完成。很明显这个过程会增大传输的延迟，尤其是对于带宽较小的网络而言。最后目标端的网卡又通过一定的算法对这些数据帧进行组装，将拆散的数据帧重新还原出一个完整的数据块。这个过程与拆分的时候一样，同样会消耗额外的CPU资源。
早期的以太网采用1500字节作为标准实际上是有其历史原因的：那个时候网络普遍都是半双工的，如果采用较大的帧则可能会造成单方向的传输会长期占据所有的带宽。如果采用较小的帧，则有拆包/解包这个过程需要花费一定的时间，使得对方节点有机会进行通信。同理可以类比计算机键盘采用qwert布局而非abcde布局的原因。
现在的网络几乎都是全双工， 也就是双向收发互不阻塞。这个时候1500字节帧就显得有点捉襟见肘了。但是网络发展的时间这么长，以太网已经成为网络的标准，要兼容大于1500字节的帧比想象中难度要大很多，事实上几乎没法完全兼容的。好在可以用其它技术进行弥补，例如拆包解包需要消耗CPU资源就增加CPU资源，网络传输带宽小就增大其带宽，这些技术对于提高传输效率都是至关重要的。那为什么还需要大于1500字节的帧呢？
理由很简单，之前已经叙述过了，还是提升CPU开销和提升传输效率。如果使用9000字节的巨帧，则对于单个标准8192字节数据块，只需要一个帧就可以进行传输了。没有繁琐拆包解包的过程，自然也就没有CPU的开销。同时不需要等待多个数据帧同时传输成功才进行组装，则传输本身的效率要更高。但是如果一个巨帧传输失败，则需要重传整个巨帧，所以如果传输失败，开销相比标准帧而言要更大，所以jumbo frame特别适合于比较稳定可靠的网络传输，例如RAC的私网通信。
Oracle的最佳实践推荐使用jumbo frame提升私网的传输效率，试验显示使用jumbo frame能提升大约10%的传输效率，见附录。但是请注意使用jumbo frame存在如下一些限制：
1. Jumbo Frame尽管听起来很诱人，但是目前还并不是IEEE的标准，所以并不是所有厂商都支持这种。（主流操作系统和交换机厂商都支持，Oracle VM server2.2不支持jumbo frame,如果需要请单独申请oneoff，见mos文档Oracle VM: Jumbo Frame on Oracle VM Doc ID 1166925.1， 另外较早的交换机可能不支持jumbo frame）
2. Jumbo Frame的牵涉面较广，不仅仅是收发的网卡的MTU size需要调整到9000, 所有涉及到私网的通信的所有交换机的MTU size都需要调整到9000, 否则节点之间可能无法进行通信。
在网络存储行业实际上很早就开始推荐使用jumbo frame作为最佳实践，例如nas，iscsi san之类的设备使用jumbo frame能明显提升传输的效率和减少cpu开销。可以自行google： jumbo frame best practice, 就能发现很多netapp， emc， dell cisco的白皮书。Oracle早期比较谨慎使用Jumbo frame作为私网的最大传输单元，主要是涉及到过多的中间环节，还涉及到交换机MTU的修改。很多客户因为某个环节遗漏或者配置错误导致RAC无法启动。目前Oracle推荐使用Jumbo frame作为私网最大传输单元，原因主要在于经压力测试发现确实其能减少global cache之类的等待事件，对于share-everything的RAC架构而言，其短板毫无疑问在于私网通信，因为私网很大程度决定了其是否具备类线性的可扩展性。
最后谈一些我个人的看法：
国内很多客户（例如通信行业）都是很多套RAC私网使用同一个核心交换机（有的甚至公网和私网走的是同一个交换机。。。汗），如果打算使用jumbo frame，除了主机本身的MTU以外，核心交换机的MTU也需要进行调整。一旦调整核心交换机的MTU，则连接在这个交换机上所有的节点都会受到影响，而没有办法只有一套系统使用jumbo frame， 这种调整可谓牵一发而动全身，千万要慎重。如果只有一套系统有大量的gc等待，则建议在其它层面例如应用进行调整，不要轻易去尝试jumbo frame。
对于新上线的系统，新采购的设备，则尽量使用jumbo frame来提高传输效率，可以作为RAC最佳实践的规范来执行。
附： 以下是Rene Kundersma （From Oracle Exadata Max Availability Architecture team）对于标准帧和Jumbo frame对比测试的一些结果, 原文链接在此，供参考：
Rene通过测试得出的结论如下：
1. you will hardly notice the benefits of using Jumbo on a system with no stress
2. you will notice the benefits of Jumbo using Frames on a stressed system and such a system will then use less CPU and will have less network overhead.
Comment