“分布式交换机技术难点讨论”有35个回复

1. anybody 于 2010-09-06 7:48 上午

   呵呵。在华为做下一代路由器平台。这个真正支持HA和NSR了。

2. Xin Qian 于 2010-09-06 8:27 上午

   到了虚拟化的阶段，我自己觉得对于数据中心交换机的热备份或者其他硬件上的热备份的要求都不是那么高了，毕竟虚拟机可以动态地在host之间游动，昂贵和复杂的硬件应该不是数据中心取胜的关键；关键在于一个易于管理的网络设备和虚拟化的软件层次结合到一起的可管理和可控的解决方案。这样一个HA的数据中心就可以被实现了。当然对于整个数据中心的出口，还是需要hot-hot的备份的。

   老实说对于数据中心我觉得H3C的那种IRF2堆叠就很好了，会相当程度的降低管理的难度。cisco的nexus也许是比h3c的玩意好，但是宣传的点很多，我也没看出来它对数据中心的好处。谁能说说对于虚拟化的数据中心来说这玩意到底好在哪里？还有就是这个nexus和cisco的UCS有什么关系？

   我看弯曲上前面几个Juniper的persentation和IRF基本一个思想。Juniper在这个时代生存的杀手锏是啥？

   如果是公有云的实现，也许对网络设备有着其他的考量。这里谁能给个提示？

   现在我就想看看H3C如何借助HP,在虚拟化的时代，在北美的企业网市场和cicso大打一场好仗。但是到目前为止还没看到看到什么。。。欢迎业界牛人们给我们报告点内幕情况。

3. 一点个人观点 于 2010-09-06 2:03 下午

   个人觉得一个好的分布式交换机架构上和路由器很像。
   1：HA分硬件和软件的支持。要做好HA，从硬件上，一般要求给予Cell的Switch Fabric交换机制，其数据的交换是通过切分成Cell方式均分过交换网卡。从保护上可以做到硬件切换。在此基础上，是软件的同步架构，然后就是工作量。
   2：线卡要能实现混插， 关键是要能有真正的分布式处理机制。如入端口的处理和出端口的处理要分别在不同的线卡上做。不然一旦是全局的处理结构，很难保证混插。即使这样也很不容易，因为要保证不同线卡芯片之间的通信报文格式和机制的一致性。
   3. 要真正做到分布式交换，芯片的SDK和底层的适配层放在线卡上。主控上必须做到和芯片无关。
   某种程度上，要佩服思科。一个真正好的机架式产品，从用户的投资保护上，几代产品的线卡和主控能在同一机架上混插，这样的包袱是很难背的。

4. liqiangln 于 2010-09-06 6:17 下午

   1：如果要做到hot standby肯定要做到RAM和table的同时更新，当时在Fabric侧做1+1，1：N的保护是其中的一方面，很多情况线卡接入就做了1+1的保护，数据流1：2分别给Master和Slaver，Slaver是standby状态，当时数据一样是处理的，表项更新有主控来做，Master和Slaver之间有软件和硬件的消息通道来检测和互通一些基础消息。
   2：互插，现在仅仅是接口之卡也就是PHY层的东西比较容易做到，线路处理卡在互插的情况下，跟软件的协调性比较难统一。
   3：同意楼上的，如果线卡的主控平面不是独立的，那不就是集总式的拓扑结构了。

5. bigrong 于 2010-09-06 8:03 下午

   这个话题我超级喜欢。等我闲点啊！

6. alrn 于 2010-09-06 9:28 下午

   HA,我们在开发GW的时候,开始考虑过采样OpenClovis,GoHead等middleware,但是要么太难掌握,要么太贵,都放弃了,最后根系统的需求,自己开发,APP根据会话来备份,底层链路备份,同时结合成熟的VRRP,TRUNK,还有Iu-FLUX等技术,也可以在系统级实现5个9的高可靠性!

7. 毛毛虫 于 2010-09-06 10:40 下午

   @Xin Qian,对你的话题同感兴趣，想知道虚拟化对网络产品到底有哪些特殊的需求，cisco好像为了数据中心发明了一些协议，希望有明白的人能出来说说。

8. august 于 2010-09-06 11:06 下午

   很想了解目前交换机的Switch Fabric是什么结构的
   ，不同级别的交换机（桌面接入、数据中心、汇聚层）有着不同的Fabric吗？
   纯Crossbar？Clos？负载均衡？

9. aaa 于 2010-09-07 3:44 上午

   哦哦，既然扯到了交换机，那就顺便扯到路由器，有没有人了解juniper的programmable asic大约是怎样搞的，里面的具体实现大约是怎样的思路，与ezchip的pipiline NP是怎样的区别。。

10. aaa 于 2010-09-07 3:50 上午

    ps,我一直觉得黑猫警长哥网络方面很厉害，能否在抓老鼠的闲暇多写文章多吹牛多扔砖。。

11. 陈怀临 于 2010-09-07 10:29 下午

    一点个人意见。从你的文章内容来看，建议贵公司暂时不要考虑HA：-）。（希望不是大宋的顶尖公司，咔咔）。

    切入市场，HA要靠后。先主攻low latency，multicast等环节。HA这个东西，押后，押后。。。

    AristaNetworks够火的吧？还没有HA Yet呢。所以HA不是一个卖点的问题。Switching不丢包才是大问题。。。

12. Metro_Ethernet 于 2010-09-08 8:07 上午

    嗯，我们目前还不是顶尖公司，资源有限，所以我对要不要做HA也比较犹豫，投入太少做不好，投入太多又没那么多资源。
    所以才来咨询一下。
    不过Arista Networks面对的是数据中心。而我们则主要是运营商和企业网，不知道运营商对这个的要求到底有多严格？是must have?

13. 理客 于 2010-09-08 9:07 上午

    看网络中的位置，HA的核心目标是把网络故障对业务的影响缩到最小，是一定要有的，但是具体做到什么程度，差异太大了，但最少要有另个主控板的冷备份，因为你不能指望一个主控坏了，维护人员3分钟给你换个好板子还能软件配置也OK，所以HA做到什么程度，是跟公司要提供的解决方案相关的，不是一个独立事件

14. mpc8240 于 2010-09-08 2:15 下午

    运营商*和*企业网。呵呵，摊子够大的。要做运营商的市场能不考虑HA吗？Arista还是攻企业网的吧。
    另外，HA难, Multicast恐怕也同样难。HA即便开始不支持，也应该纳入Architecture考虑。否则后来肯定是个烂摊子。Same applies to Multicast..

15. liqiangln 于 2010-09-08 6:00 下午

    楼上说的提前布局是对的，省得到准备上HA的时候，才发现硬件不支持，不能mesh所有的卡，这个就比较烦了。

16. 陈怀临 于 2010-09-08 6:33 下午

    这是哪家公司涅？好奇的说。。。敢同时考虑Carrier Switch和Enterprise Switch。。。胆子很大的说：–）。

    说个Idea吧。要做一个total user level的STATE模型。这是HA将来能活下来的一个关键。否则HA就是一个烂摊子，天天打补丁。。。搞死人。。。

    BTW，为什么不请我去？：-）

17. alrn 于 2010-09-08 7:32 下午

    请问有没有哪个大牛开发过热补钉呢?谢谢!

18. 陈怀临 于 2010-09-08 9:28 下午

    问了一个超难的问题。热补丁在通信领域可比OS范畴里的复杂多了。热补丁其实就是ISSU。。。如何做？我不说。。。

19. shuttle 于 2010-09-08 9:43 下午

    这公司应该是苏州的一家公司吧，应该是很需要首席这样有眼界的大牛。。但是据说老大的容人以及内部的组织都有些问题

20. Test 于 2010-09-08 10:40 下午

    Test

21. 理客 于 2010-09-09 7:25 上午

    在系统运行中做函数调用前，跳转到补丁函数，原理不复杂，但细节较多，需要熟悉具体OS，不是非常难。这已经是成熟的东西了，应该在网上可以找到一些用用的资料

22. droplet 于 2010-09-09 8:10 下午

    跳到补丁函数，这个是不难，但是怎么维护哪？补丁的补丁等等。这是一个管理问题，技术上是不难。所以这种打补丁的方式不是正当的ISSU的途径。

23. 帅云霓 于 2010-09-10 12:10 上午

    不是熟悉具体OS，是熟悉CPU体系结构和编译器

24. 理客 于 2010-09-10 7:27 上午

    商用主要考虑实际情况，减少不必要的复杂性，比如补上补的处理是新补把旧补cover了，不做补丁摞补丁

25. oxygen.yang 于 2010-09-10 7:47 下午

    1. 热补丁的代码如果不能和源代码在一个地方管理，那实际就是假的。管理上导致无法商用。

    2. ISSU，NSR这些玩意还是水很深的。没有上百人的团队就不要趟这个浑水了。这个玩意还是留给HW，ZTE和老外去玩吧。

26. asr1k 于 2010-09-11 5:15 上午

    haha …其实iSSU这些还好啦… 也不需要上百人的团队…一大堆abstract layer 才是王道…

27. 阿来 于 2010-09-11 5:51 上午

    呵呵，其实ISSU，主要依赖于操作系统。多线程的，要实现ISSU其实也不难。怕就怕在单个线程上累加做ISSU，很麻烦。重点是需要考虑的细节很多，后续的版本维护很麻烦。注定而来ISSU就是一个赚眼球的功能，实际的应用场景其实很有限。

28. 阿来 于 2010-09-11 5:52 上午

    热不丁的功能开发确实不难，其实难的就是后期的补丁文件维护和版本管理上。理顺了，问题也不会很多了。

29. os9600 于 2010-09-11 6:20 上午

    城域网、园区网、数据中心交换机区别很大。城域网交换机，基本上用作L2设备(ME除外），GR/NSF/NSR都用不上，最多做做设备级HA。
    如果是数据中心交换机，那就复杂了。技术难点在于高性能（支持40G/100G接口）以及对服务器虚拟化的适应（包括FCoE）；

30. os9600 于 2010-09-11 6:37 上午

    未来交换机发展的主要方向在数据中心。Cisco和HP/H3C在网络虚拟化方面领先业界。支持VSS的C65、支持Stackwise的C3750系列以及H3C支持IRF的设备都是对等设备N:1的虚拟化。Nexus是另外一种虚拟化，N7K是1:N虚拟化，N5K/2K是不对等设备之间的N:1的虚拟化。
    UCS是一个以网络为核心的系统，6100=N5K，2000=N2K，实质就是将FEX延伸到服务器Blade Chasiss。

31. asr1k 于 2010-09-12 9:46 上午

    其实cisco OTV才是关键

32. 吴辉 于 2010-09-12 11:30 下午

    1.HA
    2.能不能混插，前后几代Packet processor能不能相互parse各自的头部。如果是NP、FPGA、通用处理器实现的packet processor基本上应该可以的。 如果是Broadcom和Marvell的ASIC实现的线卡要混插几乎不可能。
    3.做为分布式系统，不仅应该把和PP相关的程序放在线卡处理器上运行，而且线卡处理器还应该考虑怎么给主处理器OffLoad；如果把所有程序都尽量放到主处理器上去，这样的设计团队还是不碰“分布式”为好。

    资源不够的公司，是哪家呢？

33. southbayer 于 2010-09-13 12:36 上午

    如果是B或M的ASIC, 混插的问题是啥? 如果是同一家公司同系列的芯片, 不同芯片feature set, table size或许不同, 基本的互通应该还是可以做到的

34. abc 于 2010-09-15 7:25 上午

    交换机市场也会洗牌的，跟得上HA才能玩，跟不上就淘汰。
    现在应该说可以做HA的已经不止4，5家了。到了该用新技术淘汰些player的时候了。

35. alrn 于 2010-09-15 6:56 下午

    我们开发RNC的过程中,充分考虑了HA的需求,在架构上预留了必须的资源(ATCA平台).对于补丁的理解是:
    1)冷补丁,其实就是升级一个新的版本.编译一个新版本,上传下到FLASH中去,reset系统,OK!感觉和ISSU类似.
    2)热补丁,是在内存进行涵数替换,开发热补丁需要你理解OS,CPU,编译器,为啥呢?因为,大家都知道C语言中,编译,连接,生成二进制代码,不同的处理器+OS,函数的徧移地址不同.热补丁是要算补丁涵数的徧移地址,分析定位函数的跳转指令.MIPS和X86的涵数跳转和程序的内存映射是不一样的.
    3)热补丁的管理策略也很重要,累加/覆盖,自己来定吧!

    以上是个人理解,请大家多建议,把弯曲办好!