分布式计算平台-hadoop环境下的组网方案v02new

分布式计算平台Hadoop环境下的组网方案,Hadoop起源MapReduce和HDFS介绍Hadoop的流量模型组网设计,Hadoop介绍,Doug Cutting说：这个名字是我的孩子给一头吃饱了的棕黄色大象取的。我的命名标准是简短、容易发音和拼写，没有太多的含义，并且不会被用于别处。小孩是这方面的高手。Google就是小孩子起的名字。2002年，Hadoop起源于Apache Nutch，一个开源的网络搜索引擎。后来，开发者认为该引擎的架构可扩展度不够，不能解决数十亿网页的搜索问题。怎么办呢？2003-04年，Google发表了举世闻名的三大论文： BigTable一个分布式的结构化数据存储系统 GFSThe Google File System MapReduce个处理和生成超大数据集的算法模型的相关实现,Hadoop起源/,5,Hadoop 核心分布式文件系统HDFSMapReduce框架并行数据分析语言Pig 列存储NoSQL数据库 Hbase分布式协调器Zookeeper数据仓库Hive(使用SQL)Hadoop日志分析工具Chukwa,以Google的论文为基础，Hadoop也有了自己的生态系统,MapReduce和HDFS的工作流,Laod data into the cluster (HDFS 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 shuffle 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,JobTracker和TaskTracker,JobTracker：协调作业（job）的运行。客户端：提交MapReduce作业。TaskTracker：运行作业划分后的任务（task）。一个Job可以被划分成多个Task，每个Maper负责运行一个Task。,MapReduce运行流程,Hadoop Distributed File System介绍,HDFSHadoop分布式文件系统,以集群的方式存储海量数据：PB级对HDFS来说，一次写入，多次读取是最高效的访问模式。商用硬件：使用普通的PC Server构建集群。HDFS被设计成，如果某些Server遇到故障，集群应不受到影响，继续运行且不让用户察觉到明显的中断。低时间延迟的访问：要求时延低的的应用，例如几十毫秒，HDFS不适合。HDFS是为高数据吞吐量应用优化的，这可能会以高时延为代价。目前，对于低延迟的应用，Hbase是更好的选择。,Namenode和Datanode,Namenode：管理者，管理文件系统。记录着每个文件中各个块所在的Datanode信息。客户端：代表用户与Namenode与Datanode交互来访问整个文件系统。Datanode：工作节点，根据需要存储并检索数据块，并且定期向Namenode发送它们所存储的块的列表。,HDFS数据写入剖析,HDFS副本的布局,相同节点中的进程。同一Rack上的不同Node。同一DC中的不同Rack上的Node。不同DC中的Node。,HDFS数据读取剖析,某电商Hadoop集群案例,某电商Hadoop集群规模,总容量50PB数据每天增长超过100T总共2800多台机器约150000道作业/天每日扫描数据总量约5PB，产生数据总量约500TBSalve：6 Cores CPU*2、48G Mem、2T12 HDSlave：8 Map、8 Reduce从0:10-24:00都有任务在运行，但其中80%的任务在0:10-9:00之间完成，这段时间是最重要的生产时段,Hadoop流量特征,MapReduce图解,流量特征,MapReduce的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 TCP for communication between nodes. TCP is a mature technology that has survived the test of time and meets the communication needs of most applicationsOne communication pattern, termed “Incast” by other researchers, elicits a pathological response from popular implementations of TCP. In the Incast 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 allsenders traverses a bottleneck link in a many-to-one fashion. As the number of concurrent senders increases, the perceived application-level throughput at the receiver collapses. The receiver application sees goodput that is orders of magnitude lower than the link capacityThe incast pattern potentially arises in many typical datacenter applications. For example, in cluster storage , when storage nodes 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,组网设计,网络架构,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 ： 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层汇聚架构,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 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 QueuesVoice: strict schedulingMulticast: extra queues,Destination QueuesVoice: strict schedulingMulticast: extra queues,Overspeed QueuesVoice: strict schedulingMulticast: extra queues,Fabric QueuesVoice: strict schedulingMulticast: 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 Replicates 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，Incast,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报文Job Tracker与Task Tracker之间的心跳报文NameNode与DataNode之间的心跳报文,高吞吐 与 低延迟,为了减缓TCP Incast，高吞吐量需要Switch具备一定的Buffer，来缓存溢出的流量。但是低延迟则相反，留在Buffer中的时间越短越好。心跳报文/TCP ACK需要低延迟，需要被快速的送达目的地。如何让这类报文避过Buffer的延迟？使用DCTCP，减少TCP Incast带来的流量溢出。在保持高吞吐量的同时，将Buffer队列维持在一个较小的占用比例，以此让心跳报文/TCP ACK在Buffer中停留的时间大大缩短。N3548支持DCTCP，同时具备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支持拥塞通告，不支持拥塞窗口调整,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通知发生拥塞,D