Successfully reported this slideshow.
Your SlideShare is downloading. ×

Network for the Large-scale Hadoop cluster at Yahoo! JAPAN

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 84 Ad
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Network for the Large-scale Hadoop cluster at Yahoo! JAPAN (20)

More from DataWorks Summit/Hadoop Summit (20)

Advertisement

Recently uploaded (20)

Network for the Large-scale Hadoop cluster at Yahoo! JAPAN

  1. 1. 2016/10/27 1 Kai Fukazawa, Yahoo Japan Corporation Network for the Large-scale Hadoop cluster at Yahoo! JAPAN
  2. 2. Agenda 2 Hadoop and Related Network Yahoo! JAPAN’s Hadoop Network Transition Network Related Problems and Solutions  Network Related Problems  Network Requirements of The Latest Cluster  Adopted IP CLOS Network for Solving Problems Yahoo! JAPAN’s IP CLOS Network  Architecture  Performance Tests  New Problems Future Plan
  3. 3. Hadoop and Related Network
  4. 4. Hadoop and Related Network 4  Hadoop has various communication events  Heartbeat  Reports (Job/Block/Resource)  Block Data Transfer “HDFS Architecture“. Apache Hadoop. http://hadoop.apache.org/docs/current/hadoop-project- dist/hadoop-hdfs/HdfsDesign.html. (10/06/2016). “Google I/O 2011: App Engine MapReduce”. (05/11/2011). Retrieved https://www.youtube.com/watch?v=EIxelKcyCC0. (10/06/2016).
  5. 5. Hadoop and Related Network 5  Hadoop has various communication events  Heartbeat  Reports (Job/Block/Resource)  Block Data Transfer “HDFS Architecture“. Apache Hadoop. http://hadoop.apache.org/docs/current/hadoop-project- dist/hadoop-hdfs/HdfsDesign.html. (10/06/2016). “Google I/O 2011: App Engine MapReduce”. (05/11/2011). Retrieved https://www.youtube.com/watch?v=EIxelKcyCC0. (10/06/2016).
  6. 6. Hadoop and Related Network 6  Hadoop has various communication events  Heartbeat  Reports (Job/Block/Resource)  Block Data Transfer North/South
  7. 7. Hadoop and Related Network 7  Hadoop has various communication events  Heartbeat  Reports (Job/Block/Resource)  Block Data Transfer East/West
  8. 8. Hadoop and Related Network 8  Hadoop has various communication events  Heartbeat  Reports (Job/Block/Resource)  Block Data Transfer High Low
  9. 9. Hadoop and Related Network 9 “Introduction to Facebook‘s data center fabric”. (11/14/2014). Retrieved https://www.youtube.com/watch?v=mLEawo6OzFM. (10/06/2016).
  10. 10. Hadoop and Related Network 10  Oversubscription  commonly expressed as a ratio of the amount of desired bandwidth required versus bandwidth available 10Gbps 1Gbps NIC 40Nodes = 40Gbps Oversubscription 40 : 10 = 4 : 1 “Hadoop Operations by Eric Sammer (O’Reilly). Copyright 2012 Eric Sammer, 978-1-449-32705-7.”
  11. 11. Yahoo! JAPAN’s Hadoop Network Transition
  12. 12. 12 Yahoo! JAPAN’s Hadoop Network Transition 0 10 20 30 40 50 60 70 80 Cluster1 (Jun. 2011) Cluster2 (Jan. 2013) Cluster3 (Apr. 2014) Cluster4 (Dec. 2015) Cluster5 (Jun. 2016) PB Cluster Volume
  13. 13. 13 Yahoo! JAPAN’s Hadoop Network Transition Cluster1 Stack Architecture Nodes/Rack Server NIC UpLink Oversubscription
  14. 14. 14 Yahoo! JAPAN’s Hadoop Network Transition 20G Cluster1 4 Switches/Stack Stack Architecture Nodes/Rack Server NIC UpLink Oversubscription
  15. 15. 15 Yahoo! JAPAN’s Hadoop Network Transition Cluster1 Stack Architecture Nodes/Rack 90Nodes Server NIC 1Gbps UpLink Oversubscription
  16. 16. 16 Yahoo! JAPAN’s Hadoop Network Transition Cluster1 Stack Architecture Nodes/Rack 90Nodes Server NIC 1Gbps UpLink Oversubscription
  17. 17. 17 Yahoo! JAPAN’s Hadoop Network Transition Cluster1 Stack Architecture Nodes/Rack 90Nodes Server NIC 1Gbps UpLink 20Gbps Oversubscription20Gbps
  18. 18. 18 Yahoo! JAPAN’s Hadoop Network Transition 20Gbps Cluster1 Stack Architecture Nodes/Rack 90Nodes Server NIC 1Gbps UpLink 20Gbps Oversubscription 4.5 : 1
  19. 19. 19 Yahoo! JAPAN’s Hadoop Network Transition 20Gbps Cluster1 Stack Architecture Nodes/Rack 90Nodes Server NIC 1Gbps UpLink 20Gbps Oversubscription 4.5 : 1 Up to ~10 switches
  20. 20. 20 … Cluster2 Yahoo! JAPAN’s Hadoop Network Transition Spanning Tree Protocol Nodes/Rack Server NIC UpLink Oversubscription
  21. 21. 21 … Cluster2 Yahoo! JAPAN’s Hadoop Network Transition Spanning Tree Protocol Nodes/Rack 40Nodes Server NIC 1Gbps UpLink Oversubscription
  22. 22. 22 Yahoo! JAPAN’s Hadoop Network Transition … Cluster2 Spanning Tree Protocol Nodes/Rack 40Nodes Server NIC 1Gbps UpLink Oversubscription
  23. 23. 23 Yahoo! JAPAN’s Hadoop Network Transition … Cluster2 Spanning Tree Protocol Nodes/Rack 40Nodes Server NIC 1Gbps UpLink 10Gbps Oversubscription10Gbps
  24. 24. 24 Yahoo! JAPAN’s Hadoop Network Transition … Cluster2 Spanning Tree Protocol Nodes/Rack 40Nodes Server NIC 1Gbps UpLink 10Gbps Oversubscription 4 : 110Gbps
  25. 25. 25 Yahoo! JAPAN’s Hadoop Network Transition … Cluster2 Spanning Tree Protocol Nodes/Rack 40Nodes Server NIC 1Gbps UpLink 10Gbps Oversubscription 4 : 1Blocking
  26. 26. 26 L2 Fabric … Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack Server NIC UpLink Oversubscription Cluster3
  27. 27. 27 L2 Fabric … Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 40Nodes Server NIC 1Gbps UpLink Oversubscription Cluster3
  28. 28. 28 L2 Fabric … Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 40Nodes Server NIC 1Gbps UpLink Oversubscription Cluster3
  29. 29. 29 Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 40Nodes Server NIC 1Gbps UpLink 20Gbps Oversubscription L2 Fabric … Cluster3 20Gbps 20Gbps
  30. 30. 30 Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 40Nodes Server NIC 1Gbps UpLink 20Gbps Oversubscription 2 : 1 L2 Fabric … Cluster3 20Gbps 20Gbps
  31. 31. 31 Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack Server NIC UpLink Oversubscription L2 Fabric … Cluster4
  32. 32. 32 Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 16Nodes Server NIC 10Gbps UpLink Oversubscription L2 Fabric … Cluster4
  33. 33. 33 Yahoo! JAPAN’s Hadoop Network Transition L2 Fabric/Channel Nodes/Rack 16Nodes Server NIC 10Gbps UpLink 80Gbps Oversubscription 2 : 1 L2 Fabric … 80Gbps 80Gbps Cluster4
  34. 34. 34 Yahoo! JAPAN’s Hadoop Network transition Release Volume #Nodes/Switch NIC Oversubscription Cluster1 3PByte 90 1Gbps 4.5:1 Cluster2 20PByte 40 1Gbps 4:1 Cluster3 38PByte 40 1Gbps 2:1 Cluster4 58PByte 16 10Gbps 2:1 Cluster5 75PByte ? ?Gbps ?:?
  35. 35. Network Related Problems And Solutions
  36. 36. Network Related Problems 36  Effect of switch failure in the Stack Architecture  Load on the switch due to BUM Traffic  Limitations for the DataNode Decommission  Limitations for the Scale-out
  37. 37. 37 Effect of switch failure in the Stack Architecture  One of the switches which formed the Stack failed  This affected the other switches forming the same Stack  Communication interruption among 90 nodes(5 racks)  insufficient computing resources and processing stoppage Network Related Problems
  38. 38. 38 Load on the switch due to BUM Traffic L2 Fabric … … 4400Nodes  Due to ARP traffic from servers, load on the core switch CPU increases  Tuning of ARP Cache entry timeout  The problem is Large Network Address Network Related Problems
  39. 39. 39 Limitations for the DataNode Decommission Network Related Problems  Consideration of the impact on jobs  Limiting the number of nodes for Decommissioning
  40. 40. 40 Limitations for the Scale-out  Stack Architecture  Up to ~10 switches  L2 Fabric Architecture  Depending on the number of chassis Network Related Problems
  41. 41. 41 Requirements 120~200 Racks Scale-out possible up to 10000 Nodes 100~200Gbps UpLink/Rack 10Gbps NIC Server 20Nodes/Rack DataCenter Located in US Network Requirements of The Latest Cluster
  42. 42. 42 How to solve these problems?
  43. 43. 43 How to solve these problems? We adopted IP CLOS Network!
  44. 44. Adopted IP CLOS Network For Solving Problems 44 Google, Facebook, Amazon, Yahoo… Over The Top have adopted DC network architecture “Introducing data center fabric, the next-generation Facebook data center network”. Facebook Code. https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the- next-generation-facebook-data-center-network/. (10/06/2016).
  45. 45. Adopted IP CLOS Network For Solving Problems 45 Improved scalability Improved high availability Cope-Up with increase in East-West traffic Reduction in operating cost
  46. 46. Yahoo! JAPAN’s IP CLOS Network
  47. 47. 47 BoxSwitch Architecture  No limitation on Scale-out  Requires many switches ・・・ ・・ ・・・ ・・ ・・・ ・・ ・・・ ・・ ・・ ・・ ・・ ・・・・・ Spine Leaf ToR Architecture
  48. 48. 48 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Architecture
  49. 49. Architecture 49 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf ・・・ ・・Spine Leaf
  50. 50.  Why was this architecture adopted?  Reduce in items to be managed IP address and cable, Interface, BGP Neighbor…..  Overcomes the physical constraints, such as one floor limit  Reduction in cost Architecture
  51. 51. ECMP Between Spine and Leaf is BGP 51 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf BGP Architecture
  52. 52. 52 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf /31 /26 /27 Architecture Between Spine and Leaf : /31 Rack : /26, /27
  53. 53. 53 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf /31 /26 /27 Architecture Resolved the “BUM Traffic problem”
  54. 54. 54 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Leaf Uplink 40Gbps x 4 = 160Gbps 160Gbps ① ② ③ ④ Architecture
  55. 55. 55 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Leaf Uplink 40Gbps x 4 = 160Gbps ① ② ③ ④ Architecture 10Gbps NIC 20Nodes 160Gbps
  56. 56. 56 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Leaf Uplink 40Gbps x 4 = 160Gbps 160G ① ② ③ ④ Architecture 200 : 160 = 1.25 : 1 10Gbps NIC 20Nodes
  57. 57. 57 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Leaf Uplink 40Gbps x 4 = 160Gbps 160G ① ② ③ ④ Architecture 200 : 160 = 1.25 : 1 Resolved the “Limitations for the DataNode Decommission” 10Gbps NIC 20Nodes
  58. 58. 58 ・・・・・ Internet Spine Core Router Layer3 Layer2・・・・・ Leaf Leaf Uplink 40Gbps x 4 = 160Gbps 160G ① ② ③ ④ Architecture 200 : 160 = 1.25 : 1Improved High Availability 10Gbps NIC 20Nodes
  59. 59. Architecture 59  Effect of switch failure in the Stack Architecture  Load on the switch due to BUM Traffic  Limitations for the DataNode Decommission  Limitations for the Scale-out
  60. 60. Architecture 60  Effect of switch failure in the Stack Architecture  Load on the switch due to BUM Traffic  Limitations for the DataNode Decommission  Limitations for the Scale-out ✔ ✔ ✔
  61. 61. 61 Yahoo! JAPAN’s Hadoop Network transition Release Volume #Nodes/Switch NIC Oversubscription Cluster1 3PByte 90 1Gbps 4.5:1 Cluster2 20PByte 40 1Gbps 4:1 Cluster3 38PByte 40 1Gbps 2:1 Cluster4 58PByte 16 10Gbps 2:1 Cluster5 75PByte 20 10Gbps 1.25:1
  62. 62. Performance Tests(5TB Terasort) 62
  63. 63. 63 Performance Tests(40TB DistCp)
  64. 64. 64 Performance Tests(40TB DistCp) 16Nodes/Rack 8Gbps/Node
  65. 65. 65 Performance Tests(40TB DistCp) 16Nodes/Rack 8Gbps/Node About 30Gbps x 4 = 120Gbps
  66. 66. New Problems 66  Delay in data transfer  Out of 4, 1 error packet is generated in Uplink  That one affected the data transfer delay Slow
  67. 67. New Problems 67  Delay in data transfer  Out of 4, 1 error packet is generated in Uplink  That one affected the data transfer delay “org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write packet to mirror” Slow
  68. 68. New Problems 68  Delay in data transfer  Out of 4, 1 error packet is generated in Uplink  That one affected the data transfer delay “org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write packet to mirror” Slow
  69. 69. New Problems 69  IP changes when the server rack changes  Also has a network address for each rack  Access control using IP address  Requires ACL update according to relocation 192.168.0.0/26 192.168.0.64/26 192.168.0.10 192.168.0.100
  70. 70. Future Plan
  71. 71. Future Plan 71  Detecting error packet failure before affecting the data transfer Error!
  72. 72. Future Plan 72 Error! Auto Shutdown  Detecting error packet failure before affecting the data transfer
  73. 73. Future Plan 73  Use Erasure Coding striping 64kB Originalrawdata
  74. 74. Future Plan 74  Use Erasure Coding D6 striping 64kB Originalrawdata Raw data D5D4D3D2D1
  75. 75. Future Plan 75  Use Erasure Coding D6 striping 64kB Originalrawdata Parity Raw data D5D4D3D2D1 P3P2P1
  76. 76. Future Plan 76  Use Erasure Coding D6 striping 64kB Originalrawdata Parity Raw data D5D4D3D2D1 P3P2P1 D6 D5 D4 D3 D2 D1 P1 P2 P3
  77. 77. Future Plan 77  Use Erasure Coding D6 striping 64kB Originalrawdata Parity Raw data D5D4D3D2D1 P3P2P1 D6 D5 D4 D3 D2 D1 P1 P2 P3 Read
  78. 78. Future Plan 78  Use Erasure Coding D6 striping 64kB Originalrawdata Parity Raw data D5D4D3D2D1 P3P2P1 D6 D5 D4 D3 D2 D1 P1 P2 P3 Read
  79. 79. Future Plan 79  Use Erasure Coding D6 striping 64kB Originalrawdata Parity Raw data D5D4D3D2D1 P3P2P1 D6 D5 D4 D3 D2 D1 P1 P2 P3 Low Data Locality
  80. 80. Future Plan 80 ・・・・・・・・・・・・ Interconnecting various platforms … … BOTTLENECK
  81. 81. Future Plan 81 ・・・・・・・・・・・・・・  Isolation of computing and storage : Storage Machine : Computing Machine
  82. 82. Thank You for Listening!
  83. 83. Appendix
  84. 84. Appendix 84 JANOG38 http://www.janog.gr.jp/meeting/janog38/program/clos

Editor's Notes

  • それではヤフーの深澤から Network for the Large-scale Hadoop cluster at Yahoo! JAPAN
    と題しまして発表をさせていただきたいと思います。
  • 本日のアジェンダはこのような内容になっています。
    まずは簡単にHadoopとネットワークの関係について説明をさせていただきたいと思います。
    その後にヤフーで採用されてきたHadoop用のネットワークについてとネットワークに関連する問題点、
    その解決策として、実際に導入したIPClosNetwork をヤフーの構成を交えて説明したいと思っております。
  • まず Hadoop とネットワークの関連について簡単にお話したいと思います。
  • Hadoop では様々種類のデータのやり取りが行われます。
    例えば、DataNode などの SlaveNode 系のコンポーネントから、
    NameNode などのマスター系のコンポーネントへの死活監視のためのHaertbeat。
    その他には Job、Block などのReport の送信。さらにはデータのレプリケーションや再配置などによるブロックデータの転送があります。
  • 特にブロックデータの転送にはより多くのトラフィックが発生します。
    それは HDFS ではブロックのレプリケーションや再配置、MapReduce ではShuffle フェーズが該当します。
  • また、Hadoop では従来のユーザからサーバへのアクセスのような North/South の方向つまり、縦のトラフィックだけでなく
  • データレプリケーションなどによる、マシン同士での通信が発生します。
    そのため台数が多くなるとラック間での通信が発生するためEast/West 横方向での通信が発生します。
  • Hadoopでは、North/South の方向の通信よりも East/West 横方向の通信より多く発生します。
  • また、これはFacebookのブログのものですが、このようにマシンToユーザではなく、マシンToマシン
    つまりマシン同士のトラフィックが増えていると書かれています。
    これより、Hadoop に関わらずラック間でのトラフィックの意識は重要だと考えられます。
  • このようにラック間での通信はHadoopに関わらず重要だと話してきましたが、
    ラック間通信ではオーバーサブスクリプションを意識する必要があります。
    オーバーサブスクリプションとは求められる帯域と実際に使用できる帯域の比率のことです。
    このような1ラックに1Gbps NICのサーバが40台積んであるラックを想定したときに、
    ラックスイッチの UpLink が10Gbps の場合は 40:10 つまりオーバーサブスクリプションは 4:1 になります。
  • 続いてこれまでのヤフーでのHadoop用ネットワークについてお話したいと思います。
  • まず、こちらのグラフを御覧ください。こちらはヤフーのいままでのHadoopクラスタのクラスタサイズをグラフ化したものです。
    横軸がクラスタのリリース時期で、縦軸がクラスタのサイズとなっています。
    ヤフーのクラスタは2011年の最初のクラスタから、このようにクラスタサイズが大きくなっています。
    このクラスタの変化に合わせてHadoop用に採用されてきたネットワークも変化してきました。
    ここからはそのネットワークの変遷についてお話したいと思います。
  • まずは1番古いクラスタ1のネットワーク構成についてです。
    こちらのクラスタのネットワークは複数のラックスイッチをStack構成。
    つまり複数のスイッチを仮想的に1台に見せたスイッチをコアスイッチに接続しています。
  • すべてのスイッチでStack構成を組んでいるわけではなく、4スイッチごとに一つのStackを構成しています。
  • ひとつのStack構成には1GigabpsのNICのサーバが90台接続されています。
    この構成場合上位のコアスイッチを経由して他のStack構成のラックへ通信する場合は
  • このような経路を通ります。
  • UpLnkが20Gbpsとなっているため、サーバの台数とUpLinkの数値よりオーバーサブスクリプションを求めると。
  • 4.5:1という数値になります。
  • このStack構成の問題点としては、構成が組めるスイッチの数が10台程度までという、スケールアウトに限度があります。

  • 二つ目のクラスタ2のネットワーク構成はスパニングツリープロトコルを利用した標準的な構成となっています。
  • このネットワーク構成のHadoopクラスタには、1ラックに1GigabpsのNICのサーバが40台設置されています。
    この構成ではラック間で通信する場合、
  • スパニングツリープロトコルのため、2本のUpLnkのうち片方のUpLinkを利用する形となり、このような経路を通ります。
  • また、このネットワーク構成ではUpLink が 10Gigabps のため、
  • オーバーサブスクリプションが 4:1となります。
  • この構成では、UpLinkの片方がループ防止のためにブロッキングされているため、帯域を活かしきれていません。
  • こちらは3番目のクラスタにリリースしたクラスタのネットワーク構成です。
    こちらの構成は L2 Fabric と Channel という複数の物理ポートを単一の論理ポートにみせる技術を用いた構成になっています。
    そのため、先程の構成とは違いUpLinkを片方のみ使うのではなく、UpLinkを両方とも使用する構成となっております。
  • この構成で1ラックに1Gigabps のサーバが40台設置されています
  • ラック間の通信経路ですが、こちらの構成では先程お話したように2本のUpLinkを
    Channel構成にしているため、UpLink2本とも使用するようになっております。
  • UpLinkの帯域ですが、ラックスイッチのUpLinkは20Gigabps でとなっています。
  • そのため、オーバーサブスクリプションは2:1となっています。
    先程のスパニングツリープロトコルを採用していた構成よりもオーバーサブスクリプションが
    良くなっています。
  • 最後にクラスタ4の構成ですが、こちらは先程のクラスタ3と同じ構成になっています。
  • ラック間の通信の仕方などは一緒ですが、こちらは10Gbps NICのサーバを1ラックに16台設置されています。
  • この構成ではアップリンクが80Gigabpsとなっているため、10Giga bps のサーバでもオーバーサブスクリプション 2:1を維持しています。
  • これまでのクラスタとネットワークに関する情報をまとめるとこのようになります。
    クラスタが新しくなるにつれて規模が大きくなっていますが、オーバーサブスクリプションは改善されていることがわかります。
  • 次にここまで紹介してきたヤフージャパンのHadoop用ネットワークで起きた障害や問題点とその解決策についてお話したいと思います。
  • これまでのヤフージャパンでのHadoopの運用の中でネットワークに関連した障害と問題点はこちらになります。
    上から順番に紹介していきたいと思います。
  • まず一つ目は、最初にご紹介したクラスタで使用しているStack構成のネットワークでの障害です。
    こちらはStackを組んでいるスイッチのうち1台が不調になったことで、同じStackを組んでいるスイッチにも
    影響が及んでしまい、90台のサーバに対してネットワークリーチがとれなくなってしまいました。
    それにより、計算リソースが不足し処理の停止が発生してしまいました。
  • 次に BUM Traffic によるスイッチへの負荷です。
    ちなみに BUM トラフィックとは、ブロードキャスト、ユニキャスト、マルチキャスト によるトラフィックのことです。
    このとき同じネットワークアドレスの中に4000台以上、さきほどのCluster3とCluster4のノードが存在し、それぞれから短い間隔でARPのトラフィックが発生していたことが原因でした。
    こちらはネットワーク内のサーバからのARPによるブロードキャストが原因で上位のコアスイッチに負荷を与え、CPUの上昇の原因となっていました。
    対応としてサーバ側のARPエントリの保持時間を伸ばす対応でスイッチへ負荷を軽減させました。
  • 次にこちらの、DataNodeのデコミッション時の制限ですが、
    UpLinkの帯域や既存のジョブを考慮し、DataNode のデコミッションを実施する場合に限られた台数で実施していました。
    みなさまはご存知だと思いますが、デコミッションではレプリケーションの再配置でデータの転送が発生します。
    ちなみに弊社だと、電源のメンテナンスなどのために数ラック単位でのデコミッション処理が通常の運用で発生したりします。
    そのような場合全台同時に実施するのではなくある程度数を区切って実施していました。
  • こちらのスケールアウトの限界ですが、これはクラスタのスケールアウトに合わせて
    物理的な制約などで制限がかかってしまうという問題です。
    先程もお話しましたように、Stack構成では最大で10台程度が限度です。
    L2 ファブリックなどの構成でもシャーシのポートの数に依存してしまうという問題がありました。
  • また、このような問題があったなかで、去年の春頃にこのようなHadoopチームから
    ネットワークチームへこのような要件を出しました。規模としては120-200ラック。
    10000ノードクラスのクラスタでも問題ないネットワークというものです。
    また、場所は国内ではなくアメリカのデータセンターです。
  • ヤフーはこの問題を解決するために
  • IP CLOS Networkを選択しました。
  • そもそもIP CLOS Networkとは世界の技術Top会社が採用しているネットワーク構成です。
  • IP CLOS Network にはこのような特徴があります。
    まずはスケーラビリティや耐障害性の向上、
    East-West トラフィックの増大に対応が可能となっています。
    1番下の運用コストの軽減ですが、耐障害性の向上による運用負荷の軽減と
    BGPやOSPFといった一般的なルーティングプロトコルを用いるため
    Switchメーカーに依存した運用と言ったものがなくなります。
    各特徴の詳細はこの後構成を交えて説明させていただきます。
  • ここからヤフージャパンのIP CLOS Network について説明したいと思います
  • まず IP CLOS Network の構成にはこのような3層構造のボックススイッチ型の構成があります。
    この構成の場合、SpineとLaefと呼ばれるSwitchを追加することでいくらでもスケールアウトが可能となります。
  • こちらが現在Hadoopで採用しているネットワーク構成は先ほどご紹介したボックススイッチ構成のような
    3層ではなくこのような シャーシ型スイッチを用いた2層のSpine-Leaf 構成になっています。
  • 先程の Spine/Leaf の部分がシャーシに収まった形になります。
  • 今回なぜこのような構成を採用したかというと、3層構造のBoxSwitchの構成だと管理するIPやケーブルが多くなってしまう点と
    1フロア限定など物理的な制約があったためです。
    今回初めてヤフーとしてCLOSNetworkの構築だったため、なるべく管理コストを減らす目的がありました。
    また、シャーシ型のSwitchのコストが軽減したのも一つの要因です。
  • このネットワーク構成では、Spine と Leaf の間を一般的なネットワークルーティングプロトコルである
    BGPで経路広報を行っております。また、SpineとLeafの通信はECMP(イコールコストマルチパス)となっているので
    一部の経路のみを使用するのではなく、すべての経路を使用します
  • Spine-Leaf の接続は各配線のそれぞれのインターフェースにIPを持っているため、
    /31 でネットワークアドレスを割り当てています。
    また、ラック毎に/26や/27のネットワークアドレスを持っています。
  • この構成になったことで、ラック毎にネットワークアドレスをもつことによりL2の範囲が小さくなったため、BUMTraffic の影響が小さくなり
    先程紹介したBUMTrafficの問題は解消されました。
  • ラックスイッチからのUpLinkの帯域に関しては40Gigabps×4本で合計160Gigabpsとなっています。
  • このHadoopクラスタでは 1ラックあたり10GNICのサーバが最大20台設置されているため、
  • この場合オーバーサブスクリプションがこのように 1.25:1という形になります。
  • これにより、DataNode のデコミッション処理にたいしてジョブの実行への影響を
    ネットワークに関して考慮しなくてよくなりました。
  • さらにUpLinkが4本となり、より冗長になったため耐障害性も向上しました。
    先程このHadoopクラスタはアメリカに構築されているとお話したと思いますが、
    より冗長化したことでネットワーク障害時の即時対応が求められることが軽減されました。
    これは24時間365日在住しているわけではないアメリカのデータセンターでは大きなメリットです。
  • ここまでのお話でIP CLOS Network を採用したことで、今まで起きていた問題が
  • このように解決することができました。スケールアウトの限界については
    今回は先程お話したとおりフロアなどの別の制約があったため、限界があります。
  • 先程の表にIP CLOS Network上のHadoopクラスタを加えるとこのような形になります。
    オーバーサブスクリプションが大幅に改善されています。
  • こちらは IP CLOS Network 上に構築した実際のHadoopクラスタで5TB のTeraSort を実施したときのネットワークトラフィックになります。
    左がネットワーク機器からみたインプットトラフィックで右がアウトプットトラフィックです。
    グラフからわかるように、インプットとアウトプットともに4つのUplinkにほぼ均等にトラフィックが分散されているのがわかります。
  • また、DistCp で実際にパフォーマンスを出し切れるか実施したときの結果こちらになります。

  • 1ラックに16Nodeサーバがあり、1台あたり8gigabpsトラフィックが出ていました。
  • 一つのラックスイッチから約120Gigabps 出すことができました。
  • ただ、IP CLOS Network にしたことで新たな問題も発生しました。
    まずはデータ転送の遅延です。あるときデータのプットやMapReduceのジョブが遅いという報告がユーザからありました。
  • 原因を調査すると特定のラックで、SlowBlockReceiver というログが出力されていました。
    これはデータ転送が遅いときなどに出力されるログです。
  • 原因はUpLinkの4本中1本でエラーパケットを出してしまっているため、そのラックへのデータ転送が遅延していました。
    つまり、本数が増えたことで障害ポイントも増えてしまっています。
  • また、運用上の注意点として、サーバラック毎にネットワークアドレスをもっているためラックを移動させた場合に
    サーバのIPアドレスが変わってしまう点があります。
    これは、弊社の場合ですとIPアドレス単位でACLを設定しているためサーバの移設によってACLの変更も必要になります。
  • 最後に今後についてです
  • まずは、データ転送へ影響が起きる前のネットワーク障害への対応です。
    先程お話したような一部のUpLinkにエラーパケットの上昇などが起きた場合に、それを検知し
  • エラーカウンターの上昇などを検知し自動でインターフェースをShutdownなど実施して影響が出る前に対応することを目指しています。
    これはUpLink が4本で冗長化がされているため、1本程度全断のリスクが減っているためです。
  • 次にErasure Codingの採用です。弊社ではErasure CodingをIP CLOS Network上の
    Hadoop クラスタでの利用を開始しています。Erasure Coding とは
  • 次にErasure Codingの採用です。弊社ではErasure CodingをIP CLOS Network上の
    Hadoop クラスタでの利用を開始しています。Erasure Coding ではブロックのデータを6分割し
  • そこから3つパリティを作成します。そのため、一つのデータに対して9つのデータが生成されます。
  • そしてErasure Codingではこの9つのデータを基本的にはすべて別のラックに配置します。
  • そのため、特定のノードでデータをリードしたいときは
  • このようにラック間の通信が発生してしまいます。
  • ここからわかるようにデータローカリティが低くなっているため、通常のレプリケーションよりも一つのブロックを読み込むときに
    ラック間のデータ転送が多く発生することになります。
    そのためラック間のネットワークトラフィックは重要になります。
  • 次ですが、今後は Hadoop だけでなく様々なプラットフォームをCLOSNetwork上に載せることで
    ネットワーク帯域を気にせず、プラットフォーム毎の相互接続を可能にしたいと考えています。
    現状ですと、プラットフォームごとに別のコアスイッチの配下にいるためネットワークがボトルネックになってしまっているため、
    すべてのプラットフォームをCLOS Networkに載せることで解決したいと考えております。
  • 最後ですが、こちらは今までのようなCPUとストレージをバランス良く考慮したサーバを導入するのではなく・
    データローカリティを考慮をしないようにすることで、コンピューティングに特化したマシンと
    ストレージに特化したマシンを別々に置くことを目指しています。これにより、処理のリソースが足りなければ
    CPUをたくさん積んだサーバ、容量が足りなければストレージをたくさん積んだサーバを購入といったリソースの効率化を図れます。
  • 以上となります。ご清聴ありがとうございました。

×