分布式计算平台Hadoop环境下的组网方案vnew.ppt

上传人:本田雅阁 文档编号:2544732 上传时间:2019-04-06 格式:PPT 页数:43 大小:5.84MB
返回 下载 相关 举报
分布式计算平台Hadoop环境下的组网方案vnew.ppt_第1页
第1页 / 共43页
分布式计算平台Hadoop环境下的组网方案vnew.ppt_第2页
第2页 / 共43页
分布式计算平台Hadoop环境下的组网方案vnew.ppt_第3页
第3页 / 共43页
亲,该文档总共43页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《分布式计算平台Hadoop环境下的组网方案vnew.ppt》由会员分享,可在线阅读,更多相关《分布式计算平台Hadoop环境下的组网方案vnew.ppt(43页珍藏版)》请在三一文库上搜索。

1、分布式计算平台 Hadoop环境下的组网方案,Hadoop起源 MapReduce和HDFS介绍 Hadoop的流量模型 组网设计,Hadoop介绍,Doug Cutting说:这个名字是我的孩子给一头吃饱了的棕黄色大象取的。我的命名标准是简短、容易发音和拼写,没有太多的含义,并且不会被用于别处。小孩是这方面的高手。Google就是小孩子起的名字。 2002年,Hadoop起源于Apache Nutch,一个开源的网络搜索引擎。后来,开发者认为该引擎的架构可扩展度不够,不能解决数十亿网页的搜索问题。怎么办呢? 2003-04年,Google发表了举世闻名的三大论文: BigTable一个分布式

2、的结构化数据存储系统 GFSThe Google File System MapReduce个处理和生成超大数据集的算法模型的相关实现,Hadoop起源 http:/hadoop.apache.org/,5,Hadoop 核心 分布式文件系统HDFS MapReduce框架 并行数据分析语言Pig 列存储NoSQL数据库 Hbase 分布式协调器Zookeeper 数据仓库Hive(使用SQL) Hadoop日志分析工具Chukwa,以Google的论文为基础,Hadoop也有了自己的生态系统,MapReduce和HDFS的工作流,Laod data into the cluster (HDF

3、S Write)。 Analyze the data(Map Reduce) Store the results in the cluster(HDFS Write) Read the results from the cluster(HDFS Read),MapReduce介绍,MapReduce的逻辑数据流,从一堆数据中找出每年的最高温度值,MapReduce运行原理,Map阶段: Input Split Map运算 缓存(内存中) Spill to Disk / Partition 排序 Sort/Merge on Disk Shuffle阶段(In many ways, the shu

4、ffle is the heart of MapReduce and is where the “magic” happens) Reduce阶段 排序 Sort/Merge (内存到磁盘) Reduce运算 Output (输出到HDFS),MapReduce图解,Buffer默认为100MB 超出Buffer的部分为,被Spill到磁盘。可以设置Buffer阀值为80% 默认可将10个Spill文件并行写入Merge文件 Spill、Merge都可以压缩。用CPU换IO 默认情况,Reduce最多只能同时下载5个Map的数据,mapred.reduce.parallel.copies,Jo

5、bTracker和TaskTracker,JobTracker:协调作业(job)的运行。 客户端:提交MapReduce作业。 TaskTracker:运行作业划分后的任务(task)。 一个Job可以被划分成多个Task,每个Maper负责运行一个Task。,MapReduce运行流程,Hadoop Distributed File System介绍,HDFSHadoop分布式文件系统,以集群的方式存储海量数据:PB级 对HDFS来说,一次写入,多次读取是最高效的访问模式。 商用硬件:使用普通的PC Server构建集群。HDFS被设计成,如果某些Server遇到故障,集群应不受到影响,继

6、续运行且不让用户察觉到明显的中断。 低时间延迟的访问:要求时延低的的应用,例如几十毫秒,HDFS不适合。HDFS是为高数据吞吐量应用优化的,这可能会以高时延为代价。目前,对于低延迟的应用,Hbase是更好的选择。,Namenode和Datanode,Namenode:管理者,管理文件系统。记录着每个文件中各个块所在的Datanode信息。 客户端:代表用户与Namenode与Datanode交互来访问整个文件系统。 Datanode:工作节点,根据需要存储并检索数据块,并且定期向Namenode发送它们所存储的块的列表。,HDFS数据写入剖析,HDFS副本的布局,相同节点中的进程。 同一Rac

7、k上的不同Node。 同一DC中的不同Rack上的Node。 不同DC中的Node。,HDFS数据读取剖析,某电商Hadoop集群案例,某电商Hadoop集群规模,总容量50PB 数据每天增长超过100T 总共2800多台机器 约150000道作业/天 每日扫描数据总量约5PB,产生数据总量约500TB Salve:6 Cores CPU*2、48G Mem、2T12 HD Slave:8 Map、8 Reduce 从0:10-24:00都有任务在运行,但其中80%的任务在0:10-9:00之间完成,这段时间是最重要的生产时段,Hadoop流量特征,MapReduce图解,流量特征,MapRe

8、duce的Shuffle阶段,会造成流量多打一。产生MicroBurst、Incast等现象。 使用TCP作为通讯协议。 整网尽量做到低收敛比。,From The Viewpoint Of Network,Companies like Google, Microsoft, Yahoo, and Amazon use datacenters for web search, storage, e-commerce, and large-scale general computations. In particular, the vast majority of datacenters use TC

9、P for communication between nodes. TCP is a mature technology that has survived the test of time and meets the communication needs of most applications One communication pattern, termed “Incast” by other researchers, elicits a pathological response from popular implementations of TCP. In the Incast

10、communication pattern, a receiver issues data requests to multiple senders. The senders, upon receiving the request, concurrently transmit a large amount of data to the receiver. The data from all senders traverses a bottleneck link in a many-to-one fashion. As the number of concurrent senders incre

11、ases, the perceived application-level throughput at the receiver collapses. The receiver application sees goodput that is orders of magnitude lower than the link capacity The incast pattern potentially arises in many typical datacenter applications. For example, in cluster storage , when storage nod

12、es respond to requests for data, in websearch, when many workers respond near simultaneously to search queries, and in batch processing jobs like MapReduce , in which intermediate key-value pairs from many Mappers are transferred to appropriate Reducers during the “shuffle” stage.,Incast现象、Goodput,组

13、网设计,网络架构,CSW-1,CSW-2,CSW-3,CSW-4,N3548-1,N3548-2,N3548-3,N3548-N,网络架构,四台交换机组成4个CSW平面,CSW平面之间不互联 N3548分别与4个平面的CSW交换机互联 N3548与CSW之间通过动态路由协议实现自路由收敛 通过BFD和IP FRR提升网络的可用性 N3548与CSW之间可以是10GE或40GE互联 N3548与Server之间可以是1GE或10GE互联 CSW交换机可以是N3548、N5K、N7K 所支持服务器数量取决于CSW交换机的端口密度,设计思路,灵感来自于Multi-Chassis Router CRS

14、 : Hadoop集群内部主要是巨大的东西向流量 加速比/Speedup (为什么要有多个平面?) ,相关术语:HOLB、VoQ ECMP ,相关术语: Round Robin、Per Flow Buffering Fabric、Backpressure Self Routing,相关术语: CrossBar Fabric 使用最新的Nexus3548,并利用其最新的特性: Buffer Allocation、Management DCTCP 理论基础出自于上世纪60-70年代的论文CLOS Fat Tree,但是网络结构绝对不是翻新,至少在2010年以前,整个工业界大部分还是使用传统的3层汇

15、聚架构,CRS架构,Good HoLB solutions Virtual Output Queues and Backpressure,TX,TX,RX,RX,40G,40G,112G,112G,VOQ (Virtual Output Queues) Cisco 12000 or ASR9000 per-destination slot queues 4-16 destination slots hundreds VOQs per card!,Fabric QoS + backpressure Cisco CRS-1 (1296 slots!) 2.8x egress overspeed 4

16、 queues at each point vital bit packet packing,Ingress Linecards,TX,TX,RX,RX,Egress Linecards,10G,10G,10G,10G,arbiter,grant,grant,Virtual Output Queues Voice: strict scheduling Multicast: extra queues,Destination Queues Voice: strict scheduling Multicast: extra queues,Overspeed Queues Voice: strict

17、scheduling Multicast: extra queues,Fabric Queues Voice: strict scheduling Multicast: extra queues,backpressure,Bene Self-Routing, Buffering Fabric no arbiter,Ingress Linecards,TX,TX,TX,TX,RX,RX,RX,RX,Egress Linecards,CRS-1 Switch Fabric dual-stage Bene Fabric QoS (4 queues) per port backpressure Rep

18、licates Multicast scales up to 1176 slots,BACKPRESSURE,S1,S2,S3,CRS-1 Switch Fabric 为什么不使用Crossbar,而要使用Benes? Benes网络最大的优点是:相对一个没有中间交换过程的Crossbar结构,对于要实现一个nn的全交换,Benes网络所需要的连接节点 数目要小的多。所以这是一个成本问题。,Self-Routing,MicroBurst in MapReduce Shuffle Stage,发生MircroBurst之后:在Node上可以发现大量的TCP Retransmission,Inca

19、st,Nexus 3548 Buffer吸收溢出的流量 Active Buffer Monitoring,# Of Samples,AlgoBoost Buffer Histogram,Shared Buffer,Software Polling,Hardware Polling,仅靠Buffer行吗?,一个有意思的现象,使用了大Buffer的交换机之后,JOB的时间会缩短,吞吐量会上去,但是仍然会看到有TCP Retransmission 这是因为心跳和TCP ACK等信令报文被积压在了Buffer中,没有及时到达,导致TCP重传,Shared Buffer,TCP数据报文 TCP ACK报

20、文 Job Tracker与Task Tracker之间的心跳报文 NameNode与DataNode之间的心跳报文,高吞吐 与 低延迟,为了减缓TCP Incast,高吞吐量需要Switch具备一定的Buffer,来缓存溢出的流量。但是低延迟则相反,留在Buffer中的时间越短越好。 心跳报文/TCP ACK需要低延迟,需要被快速的送达目的地。如何让这类报文避过Buffer的延迟? 使用DCTCP,减少TCP Incast带来的流量溢出。在保持高吞吐量的同时,将Buffer队列维持在一个较小的占用比例,以此让心跳报文/TCP ACK在Buffer中停留的时间大大缩短。 N3548支持DCTC

21、P,同时具备ULL,所以会让心跳报文/TCP ACK传递的更快。,ECN首先由传输层进行能力协商 协商完毕后控制IP头的ECT、CE标致位 接收端接收到CE包,向发送端发送拥塞通知 目前TCP通过使用两个预留标志位来实现能力协商和拥塞通知 TCP新建标志位为CWR(Congestion Window Reduce)和ECE(ECN-Echo) UDP等其余传输层协议需要应用层通知,ECN:Congestion Notification,SYN=1, ECE=1, CWR=1 支持拥塞通告,也支持拥塞窗口调整,SYN=1, ACK=1, ECE=1,CWR=0 支持拥塞通告,不支持拥塞窗口调整,

22、ACK=1,ECE=0,CWR=0 能力协商结束,TCP 握手阶段,拥塞发生,IP ECT=1, CE=0,IP ECT=1, CE=0,IP ECT=1, CE=1,ACK=N, ECE=1,CWR=0 通知发生拥塞,Data, CWR=1 接收到拥塞通知,发送窗口减半,ACK=M, ECE=0, CWR=0 接收到CWR=1,ECE清除,否则持续发送,传统的ECN模式,Data Center TCP Algorithm,Switch side: Mark packets when Queue Length K. Queue is not full,Sender side: Maintain

23、 running average of fraction of packets marked (). In each RTT: Adaptive window decreases: Note: decrease factor between 1 and 2.,B,K,Mark,Dont Mark,Source: Data Center TCP (DCTCP), SIGCOMM 2010, New Dehli, India, August 31, 2010.,Incast Results with DCTCP,2MB,4MB,8MB,每台服务器使用翻倍的以太网链路接入交换矩阵,消除TCP Incast。以空间换时间。,简单粗暴:增加Server与网络之间的带宽,总结,MapReduce的运行方式会造成TCP Incast,降低Hadoop的运算效率。 网络架构设计灵感来自于CRS ,设计要点包括: 加速比/Speedup、ECMP 、 Self Routing、Buffer 解决TCP Incast的方式: 大Buffer 适量的Buffer + DCTCP(N3548) 使用翻倍的以太网链路接入交换矩阵,消除TCP Incast,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1