Use of InfiniBand in cloud impementation
•
5 likes•6,418 views
Sakura Cloud is a service developed and released in 2011. We use InfiniBand, witch is rare as an Internet service and it is used for connection between server and storage. In this presentation, we will briefly introduce the configuration of the system and explain the reasons and usage if InfiniBand. We are going to introduce operational comparisons and meris demerits with the services provided by Ethernet.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Use of InfiniBand in cloud impementation
Similar to Use of InfiniBand in cloud impementation (20)
Use of InfiniBand in cloud impementation
- 1. クラウド実装における InfiniBand利用 Ethernetとの比較とメリット・デメリット 2019/1/23 (C) Copyright 1996-2018 SAKURA Internet Inc さくらインターネット研究所 鷲北 賢さくらインターネット株式会社
- 2. 自己紹介 • 鷲北 賢（わしきた けん） • 1998年4月入社 • バックボーンのお守りからサービス開発まで ─ 初期の専用サーバ、データセンター構築 ─ オンラインゲームプロジェクト ─ さくらのクラウド開発マネージャー、などなど • 2009年より、さくらインターネット研究所 所長 ─ 仮想化技術の研究（Linux KVM） ─ 高性能リソースを分割するより小型計算機を集めて高性能化する ほうに興味あり • @ken_washikita、https://facebook.com/ken_washikita 2
- 3. 講演概要 1. クラウドサービス開発の経緯 ─開発当時の状況 ─InfiniBand採用に至った事情 2. システム構成 3. 比較検討 4. まとめ 3
- 4. クラウドサービス開発の経緯 • ”CLOUD NATIVE“以前の時期 ─サーバを直接貸し出すサービスが中心だった • 2008年ごろより仮想サービスが本格化 ─2009年より仮想化技術の研究を開始 ─2010年にVPSにより、自社初のサービス化 ─2011年にクラウドサービスの開発・リリース を計画 4
- 5. 開発時の課題 • 最大の課題「リソース・プール」 ─ 有り体に言えば「在庫」 ─ 可能な限り減らしたいというのが本音 ─ 一方で「売り切れ」という事態も恥ずかしい • リソース・プールをどの程度用意すべきか ─ 自社初のサービスであるため予測不可能 ─ 初期投資はともかく、最大キャパシティの設計す らおぼつかない状況 ─ 本講演ではネットワークに絞って議論する 5
- 6. ネットワークキャパシティの予測（１） • パテント（顧客）のモデル ─ パテントはデータセンターにサイト を持つサービス提供者である • VMはランダムにホストに割り当てら れる ─ サーバプールから即座に割り当てる 必要がある ─ 品質を均一にするためランダムに割 り当てる必要がある 6 router DB WebWeb App App DB ホストA Web App ホストB WebDB ホストC router DB App バックプレーン パテントの システム例 物理へmap
- 7. バックプレーン ネットワークキャパシティの予測（２） • North-Southトラフィック ─ VMからインターネットへ抜けるト ラフィック ─ ネットワーク図の上下（南北）方 向を指す ─ 既存事業の延長であるため予測可 能（経験有） • East-Westトラフィック ─ VM間を行き来するトラフィック ─ ネットワーク図の左右（東西）方 向を指す ─ ホストにランダムに配置したVMが どのようなトラフィックを発生さ せるか予測不能（未経験） 7 ホストA Web App ホストB WebDB ホストC router DB App Internet North-South Traffic East-West Traffic
- 8. ネットワークキャパシティの予測（３） • バックプレーン帯域 ─ East-Westトラフィックを運ぶ要ではあるが最大キャパシ ティはある程度予測できる ─ 小さく始めて徐々に規模拡大していきたいがそうはいかない ➢ 「不足してきたから交換」できるパーツではない ─ 初期投資として割り切って大きな装置を準備 • ホストのポート帯域 ─ ホスト数が多数（1000台）になる見込みなのでギリギリま で節約したい ─ しかし帯域不足の事態も避けたい ─ 選択が非常に困難 8
- 9. 2011年ごろのEthernet NIC事情 • サーバにおいては1GbEが多数 ─ 仮想化以前のサーバの話 ─ しかし1GbEではいくらなんでも帯域不足 • 10GbEは高価で、あまり使いたくない ─ サーバのようなエッジではなくバックボーンで主流 ─ ポート単価が高すぎ、収容サービスの料金に見合わな い • 高集積と共に25GbE、40GbEなども検討したが… ─ Experimentalの域を出ていなかった 9
- 10. InfiniBandの“発見” • VirtualSMP（ScaleMP社） ─ 4台の物理サーバをQDRでインターコネクト ─ 32プロセッサの「1台」のSMPシステムとして稼動さ せる ─ 仮想サーバ研究の一環で調査 ─ 初めてInfiniBandに触れる 10
- 11. InfiniBand QDRの調査を開始 • さっそくスイッチとHCAを調達し実験開始 ─ IPoverIB環境を構築 ─ 実効スループットで25Gbps以上をマーク • ポート単価は10GbEとほぼ同等（当時） ─ 同価格で2倍の速度は大変な魅力 ─ ただしEthernet製品と比較してポート密度が中途半端 • Ethernetにはない長所 ─ Ethernetでは面倒なLAG設定がInfiniBandでは簡素 ─ fat tree networkも簡単に組める ⇒ スケーリングできる？ • 一方で短所も ─ Ethernetで培ってきた運用技術がまったく使えない ─ Subnet Managerはほとんどconfigできない 11
- 12. InfiniBand採用決定 • 「まあ何とかイケるんじゃないか」で決定 • というのも… ─開発担当チームが「研究所＋新規事業室」とい うジョイントフォースだった ─本来慎重な意見を出す開発部や運用部のメン バーは、他のサービスで忙殺されていた • もちろんサービス投入前のテストは実施し ています 12
- 13. システム構成 13 : Host Host Host Host Storage Storage TOR TOR IB/Ether bridge (Xsigo) Router • ホストとストレージのインターコネクト はInfiniBandで接続 ─ East-WestトラフィックはIPoverIBで処理 • インターネットへ抜けるトラフィックは ブリッジ装置を介してEthernetへ変換 ─ ブリッジが各ホストにvNICを作成、これを 介してInternetへの経路を確保 ─ これがNorth-Southトラフィックを 処理する • 機材は主副冗長化 ─ KVMがLive Migrationできないため Hostは非冗長 ※ テナント分離のためにVLANを利用していて、その ために仮想ネットワークを縦横無尽に張り巡らせ ていますが、説明しきれないため割愛します AGGRE SM
- 14. サーバ実装 14
- 16. システム構成内訳 16 機器 台数（およそ） ホスト数 270 ストレージ装置 100 スイッチ 50 ブリッジ装置 2 Subnet Manager 2
- 17. 運用して分かったこと（１） 1. HCAやIB-SWは比較的安定している ─ Ethernet NICと比較して遜色ない信頼性 ─ 故障率は変わらないか、若干低い 2. IB部分のソフトウェア不具合も少ない ─ configに融通がきかない部分があるものの 通信断やトラブルはEthernetに比べて少ない印象 3. 仮想サーバから見て物理層は完全に隠蔽できる ─ EthernetかInfiniBandか、テナントには判別できない ─ 導入は成功と言える 17
- 20. 運用して分かったこと（２） 1. 機器の取り回しが困難 ─ 機器の設置やケーブルの抜き差しといった運用の基本動作が洗練されてい ない 2. Stateの計測が困難 ─ SNMPのような基本的なプロトコルが用意されていない ─ InfiniBandネットワーク内で何が起こっているのか思うように計測できな い ─ エッジ（サーバ等）で計測し集計結果から類推する方式で対応 3. 新たな運用ポリシーの策定と訓練が大変 ─ Ethernet運用のエキスパート達を動員するのに苦労 ─ 新たな監視ツールの製作にもコストがかかった 4. Ether/InfiniBand Bridgeへの過度の依存 ─ ホストサーバのドライバを供給してもらう必要があった 20
- 21. 2年後の2013年、新ゾーンはEthernetで再設計 • ホスト収容数／ネットワークトラフィック量の黄金比の把握 ─ テナントの実際の利用状況を観察することができた ─ これによりホストへの適切な収容と最適な帯域が設計できるよう になった ─ 結果、10GbE帯域で十分であるという結論になった • 10GbEの価格が急激に下落 ─ QSFPファクターのケーブル・スイッチが一般化 • 一方でInfiniBandはより広帯域へ • Ethernet/InfiniBand Bridge装置メーカーの買収 運用技術を多様化させるより、Ethernetへ回帰することを選択 21
- 23. 2019年現在 • InfiniBandによるクラウドサービス提供は継続中 ─ ホストサーバの退役にともないEthernetへ徐々に転換中 ─ 初期のストレージ問題を除き通信障害はなく 8年間に渡り安定的にサービス提供できている • InfiniBandは「高火力サービス」で復活 ─ GPUを利用したHPC向け専用サーバサービス ─ 大学、学術研究機関、企業研究機関等で採用事例多数 ─ インターコネクトは標準ではEthernet接続だが InfiniBandで指名いただく事例あり ─ クラウド運用で培ったOP経験を生かして対応 ─ しかし冗長構成は不要だそう ➢ SMを置かない事例がほとんど ➢ ネットワークがダウンしても再起動で大丈夫、とのこと 23