分布式計(jì)算平臺(tái)Hadoop環(huán)境下的組網(wǎng)方案vnew課件

1、分布式計(jì)算平臺(tái)Hadoop環(huán)境下的組網(wǎng)方案Hadoop起源MapReduce和HDFS介紹Hadoop的流量模型組網(wǎng)設(shè)計(jì)Hadoop介紹Doug Cutting說(shuō)：這個(gè)名字是我的孩子給一頭吃飽了的棕黃色大象取的。我的命名標(biāo)準(zhǔn)是簡(jiǎn)短、容易發(fā)音和拼寫(xiě)，沒(méi)有太多的含義，并且不會(huì)被用于別處。小孩是這方面的高手。Google就是小孩子起的名字。2002年，Hadoop起源于Apache Nutch，一個(gè)開(kāi)源的網(wǎng)絡(luò)搜索引擎。后來(lái)，開(kāi)發(fā)者認(rèn)為該引擎的架構(gòu)可擴(kuò)展度不夠，不能解決數(shù)十億網(wǎng)頁(yè)的搜索問(wèn)題。怎么辦呢？2003-04年，Google發(fā)表了舉世聞名的三大論文： BigTable一個(gè)分布式的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)系

2、統(tǒng) GFSThe Google File System MapReduce個(gè)處理和生成超大數(shù)據(jù)集的算法模型的相關(guān)實(shí)現(xiàn)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運(yùn)行原理Map階段： Input Split Map運(yùn)算 緩存（內(nèi)存中） Sp

3、ill 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 （內(nèi)存到磁盤(pán)） Reduce運(yùn)算 Output （輸出到HDFS)MapReduce圖解Buffer默認(rèn)為100MB超出Buffer的部分為，被Spill到磁盤(pán)?？梢栽O(shè)置Buffer閥值為80%默認(rèn)可將10個(gè)Spill文件并行寫(xiě)入Merge文件Spill、Merge都可以

4、壓縮。用CPU換IO默認(rèn)情況，Reduce最多只能同時(shí)下載5個(gè)Map的數(shù)據(jù)，mapred.reduce.parallel.copiesJobTracker和TaskTrackerJobTracker：協(xié)調(diào)作業(yè)（job）的運(yùn)行。客戶端：提交MapReduce作業(yè)。TaskTracker：運(yùn)行作業(yè)劃分后的任務(wù)（task）。一個(gè)Job可以被劃分成多個(gè)Task，每個(gè)Maper負(fù)責(zé)運(yùn)行一個(gè)Task。MapReduce運(yùn)行流程Hadoop Distributed File System介紹HDFSHadoop分布式文件系統(tǒng)以集群的方式存儲(chǔ)海量數(shù)據(jù)：PB級(jí)對(duì)HDFS來(lái)說(shuō)，一次寫(xiě)入，多次讀取是最高效的訪問(wèn)模式

5、。商用硬件：使用普通的PC Server構(gòu)建集群。HDFS被設(shè)計(jì)成，如果某些Server遇到故障，集群應(yīng)不受到影響，繼續(xù)運(yùn)行且不讓用戶察覺(jué)到明顯的中斷。低時(shí)間延遲的訪問(wèn)：要求時(shí)延低的的應(yīng)用，例如幾十毫秒，HDFS不適合。HDFS是為高數(shù)據(jù)吞吐量應(yīng)用優(yōu)化的，這可能會(huì)以高時(shí)延為代價(jià)。目前，對(duì)于低延遲的應(yīng)用，Hbase是更好的選擇。HDFS數(shù)據(jù)寫(xiě)入剖析HDFS副本的布局相同節(jié)點(diǎn)中的進(jìn)程。同一Rack上的不同Node。同一DC中的不同Rack上的Node。不同DC中的Node。某電商Hadoop集群案例某電商Hadoop集群規(guī)模總?cè)萘?0PB數(shù)據(jù)每天增長(zhǎng)超過(guò)100T總共2800多臺(tái)機(jī)器約150000道

6、作業(yè)/天每日掃描數(shù)據(jù)總量約5PB，產(chǎn)生數(shù)據(jù)總量約500TBSalve：6 Cores CPU*2、48G Mem、2T12 HDSlave：8 Map、8 Reduce從0:10-24:00都有任務(wù)在運(yùn)行，但其中80%的任務(wù)在0:10-9:00之間完成，這段時(shí)間是最重要的生產(chǎn)時(shí)段Hadoop流量特征MapReduce圖解流量特征MapReduce的Shuffle階段，會(huì)造成流量多打一。產(chǎn)生MicroBurst、Incast等現(xiàn)象。使用TCP作為通訊協(xié)議。整網(wǎng)盡量做到低收斂比。From The Viewpoint Of Network 組網(wǎng)設(shè)計(jì)網(wǎng)絡(luò)架構(gòu)CSW-1CSW-2CSW-3CSW-4N3

7、548-1N3548-2N3548-3N3548-NServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersServersS

8、erversServersServersServersServersServersServersServersServers設(shè)計(jì)思路靈感來(lái)自于Multi-Chassis Router CRS ： Hadoop集群內(nèi)部主要是巨大的東西向流量 加速比/Speedup （為什么要有多個(gè)平面？） ，相關(guān)術(shù)語(yǔ)：HOLB、VoQ ECMP ，相關(guān)術(shù)語(yǔ)： Round Robin、Per Flow Buffering Fabric、Backpressure Self Routing，相關(guān)術(shù)語(yǔ)： CrossBar Fabric使用最新的Nexus3548，并利用其最新的特性： Buffer Allocation

9、、Management DCTCP理論基礎(chǔ)出自于上世紀(jì)60-70年代的論文CLOS Fat Tree，但是網(wǎng)絡(luò)結(jié)構(gòu)絕對(duì)不是翻新，至少在2010年以前，整個(gè)工業(yè)界大部分還是使用傳統(tǒng)的3層匯聚架構(gòu)CRS架構(gòu)Good HoLB solutions Virtual Output Queues and Backpressure TXTXRXRX40G40G112G112GVOQ (Virtual Output Queues) Cisco 12000 or ASR9000 per-destination slot queues 4-16 destination slots hundreds VOQs pe

10、r card!Fabric QoS + backpressure Cisco CRS-1 (1296 slots!) 2.8x egress overspeed 4 queues at each point vital bit packet packingIngress LinecardsTXTXRXRXEgress Linecards10G10G10G10Garbiter grantgrantVirtual Output QueuesVoice: strict schedulingMulticast: extra queues Destination QueuesVoice: strict

11、schedulingMulticast: extra queues Overspeed QueuesVoice: strict schedulingMulticast: extra queues Fabric QueuesVoice: strict schedulingMulticast: extra queues backpressureBene Self-Routing, Buffering Fabric no arbiterIngress LinecardsTXTXTXTXRXRXRXRXEgress LinecardsCRS-1 Switch Fabric dual-stage Ben

12、e Fabric QoS (4 queues) per port backpressure Replicates Multicast scales up to 1176 slots QoS QoS QoS QoS QoS112 Gbps45 GbpsBACKPRESSURES1S2S3CRS-1 Switch Fabric 為什么不使用Crossbar，而要使用Benes？Benes網(wǎng)絡(luò)最大的優(yōu)點(diǎn)是：相對(duì)一個(gè)沒(méi)有中間交換過(guò)程的Crossbar結(jié)構(gòu)，對(duì)于要實(shí)現(xiàn)一個(gè)nn的全交換，Benes網(wǎng)絡(luò)所需要的連接節(jié)點(diǎn) 數(shù)目要小的多。所以這是一個(gè)成本問(wèn)題。Self-RoutingMicroBurst in

13、MapReduce Shuffle Stage發(fā)生MircroBurst之后：在Node上可以發(fā)現(xiàn)大量的TCP Retransmission，IncastKbytes3847681152153619202304268830723456384061449/15/2012 3:11:01 PM5051090140000009/15/2012 3:11:02 PM00000109010050009/15/2012 3:11:03 PM00000010801105009/15/2012 3:11:04 PM00000100120300009/15/2012 3:11:05 PM051085150000

14、0009/15/2012 3:11:06 PM200500000000001234562448302928272625PacketNexus 3548 Buffer吸收溢出的流量Active Buffer Monitoring# Of SamplesAlgoBoost Buffer Histogram Shared BufferSoftware PollingHardware Polling僅靠Buffer行嗎？一個(gè)有意思的現(xiàn)象，使用了大Buffer的交換機(jī)之后，JOB的時(shí)間會(huì)縮短，吞吐量會(huì)上去，但是仍然會(huì)看到有TCP Retransmission 這是因?yàn)樾奶蚑CP ACK等信令報(bào)文被積壓

15、在了Buffer中，沒(méi)有及時(shí)到達(dá)，導(dǎo)致TCP重傳1234562448302928272625PacketShared BufferTCP數(shù)據(jù)報(bào)文TCP ACK報(bào)文Job Tracker與Task Tracker之間的心跳報(bào)文NameNode與DataNode之間的心跳報(bào)文高吞吐 與 低延遲為了減緩TCP Incast，高吞吐量需要Switch具備一定的Buffer，來(lái)緩存溢出的流量。但是低延遲則相反，留在Buffer中的時(shí)間越短越好。心跳報(bào)文/TCP ACK需要低延遲，需要被快速的送達(dá)目的地。如何讓這類(lèi)報(bào)文避過(guò)Buffer的延遲？使用DCTCP，減少TCP Incast帶來(lái)的流量溢出。在保持高

16、吞吐量的同時(shí)，將Buffer隊(duì)列維持在一個(gè)較小的占用比例，以此讓心跳報(bào)文/TCP ACK在Buffer中停留的時(shí)間大大縮短。N3548支持DCTCP，同時(shí)具備ULL，所以會(huì)讓心跳報(bào)文/TCP ACK傳遞的更快。ECN首先由傳輸層進(jìn)行能力協(xié)商協(xié)商完畢后控制IP頭的ECT、CE標(biāo)致位接收端接收到CE包，向發(fā)送端發(fā)送擁塞通知目前TCP通過(guò)使用兩個(gè)預(yù)留標(biāo)志位來(lái)實(shí)現(xiàn)能力協(xié)商和擁塞通知TCP新建標(biāo)志位為CWR（Congestion Window Reduce）和ECE（ECN-Echo）UDP等其余傳輸層協(xié)議需要應(yīng)用層通知ECN:Congestion NotificationSYN=1, ECE=1, C

17、WR=1支持擁塞通告，也支持擁塞窗口調(diào)整SYN=1, ACK=1, ECE=1，CWR=0支持擁塞通告，不支持擁塞窗口調(diào)整ACK=1，ECE=0，CWR=0 能力協(xié)商結(jié)束TCP 握手階段擁塞發(fā)生IP ECT=1, CE=0IP ECT=1, CE=0IP ECT=1, CE=1ACK=N, ECE=1，CWR=0通知發(fā)生擁塞Data, CWR=1接收到擁塞通知，發(fā)送窗口減半ACK=M, ECE=0, CWR=0接收到CWR=1，ECE清除，否則持續(xù)發(fā)送傳統(tǒng)的ECN模式 Data Center TCP AlgorithmSwitch side: Mark packets when Queue Length K.Queue is not fullSender side:Maintain running average of fraction of packets marked ().In each RTT:Adaptive window decreases:Note: decrease factor between 1 and 2.BKMarkDont MarkSource: Data Center TCP (DCTCP), SIGCOMM 2010, New Dehli, India, August 31, 2010.