Juniper证券行业案例交流 for Partner meeting.pptxVIP

Juniper Networks证券交易行业案例分享;从一封邮件聊起吧;某期货交易所客户;期货实行T+0交易制度，再加上交易接口的公开性，极大地促进了程序化交易。交易所是每500ms发送一次行情信息，高频交易者希望自己在收到行情之后，第一时间发送委托，将当前已经存在的买卖盘中的报价“抢”到手。 低时延 很多客户采用程序交易或者算法交易，这样相对于人工操作速度要快，有利于抢单，所以时延就占有很大的比重，所以大客户均采用把服务器托管在期货公司的数据中心，以使时延最小化， 这样比通过internet下单速度要快几十ms,数据中心内的网络时延越小越有利于抢单。 期货行情较证券之类要快，证券行情一般为5秒/跳，而期货行情为2跳/秒，时延越小，也就越有利于抢单。 风控的需要，在必要时强平也要能抢到单才行 ;官方数据;深交所案例分享;案例一：深交所新一代交易系统;新一代交易系统的要求;新一代交易系统架构与特点;交易所数据中心(3套独立系统） 新一代生产交易系统\期权交易系\新一代测试系统(~240台QFX5100) 交易系统~200台物理server(交易服务器、行情服务器、撮合服务器、管理服务器) 前端通信Server主要是用于接收用户交易数据和发布行情数据；通过总线网和后端TE进行交互，完成交易。 内部采用可靠组播协议传递（基于IBM的中间件系统自行开发的ACK机制），相关的业务流量几乎全为组播，管理类流量为单播。 主/备Server之间的通信中断8s ;用户接入网（EBGP\PIM-SSM\BFD）： 广域核心和接入 综合网托管接入 行情网接入 采用Juniper MX960/MX480/MX104共10多台路由器，QFX5100万兆交换机／EX4300/EX4200千兆交换机几十台，SRX防火墙多对。 ;MC-LAG: 消除STP，独立管理平台，支持运行不同版本 上联接口或链路故障监测;Dual-DR PIM SM (Auto-RP, BSR, or Anycast RP/MSDP);测试拓扑比较——Juniper;方案差异 接入层需要作VPC(不支持上联接口或链路故障监测) Nexus3548不能在组播数据流的路径上部署为RP,需要单独部署RP ;Cisco： 二层单机单播：各数据帧大小下平均延迟为232-246ns，平均抖动为3-7ns 三层单机单播：各数据帧大小下平均延???为240-245ns，平均抖动为3-6ns 二层单机组播：各数据帧大小下平均延迟为231-246ns 三层单机组播：各数据帧大小下平均延迟为240-254ns Juniper： 二层单机单播：各数据帧大小下平均延迟为626-1022ns，平均抖动为17-35ns 三层单机单播：各数据帧大小下平均延迟为622-1025ns，平均抖动为27-35ns 二层单机组播：各数据帧大小下平均延迟为631-1030ns 三层单机组播：各数据帧大小下平均延迟为626-1024ns ;挂应用测试两个厂商产品性能基本一致 Cisco： 应用记录最大延时1613us，平均延时385us Juniper： 应用记录最大延时1419us，平均延时391us ;Cisco： vPC的心跳分为keepalive和peerlink，如果2根link同时中断，会出现脑裂，流量长时间中断。 vPC的2端，若控制平面Master down，会导致近70s的业务中断。在核心层和接入层有相同的问题。 Nexus3548无法在组播数据流的路径上部署RP，所以，需要单独在各DC再部署一个PIM RP。 Juniper：;低延迟：挂应用系统的测试中，QFX5100和Nexus3548二者在交易所这样的低时延应用系统上时延基本没有区别（391us VS 385us） 高可用性：Nexus3548存在的VPC脑裂（双主），导致网络故障长时间无法恢复；另外VPC控制平面Master down，会导致近70s的业务中断。Juniper QFX5100的MC-LAG没有类似的问题, Juniper方案整体故障收敛速度较快。 组播支持能力：PIM RP的功能（Nexus3548不能在组播数据流的路径上部署为RP，需要部署额外的RP设备）；QFX5100支持丰富的组播特性（RP／MSDP／PIM BFD等） 扩展性：QFX5100除了48口万兆外，并具备6个40G线速接口，更易于40G扩展；Nexus35