読者です 読者をやめる 読者になる 読者になる

Interconnect Casual

Interconnect variations

  • 田籠さん
    • トレジャーデータ
  • インターコネクト ... 分散システム同士の内部の通信
  • ソフトウェアで完結するもの、HWを使うもの
  • なぜそんなことを?
    • 目的を満たすほどに速い
    • スループットとレイテンシ両面において十分に速い、ということ
  • Hadoop
    • Interconnect的に見ると特殊
    • 分散計算するときの単位がデカい
      • データソースが128MB~256MB
      • 並列DBやHPCに比べると遥かに荒い
      • ノードの計算独立性が高い
      • →インターコネクトに対する要求が少ない
    • 分散FS, HDFS
      • 処理エンジンとかなり密接につながっている
      • 各ノード・プロセスに計算を割り当てるときに、localhost内で計算が閉じるかの判断がある
        • TDでは使ってないので今名前をど忘れしてます
      • HWは普通のイーサネット
    • イーサネット
      • ラック内のTOR(トップおブラック)スイッチ、そこから中央スイッチに繋がるという構成
      • rack-awarenessトポロジを設定できる、1台で閉じない処理でもスイッチ内で完結するようにできる
  • ブレードサーバ
    • SIer時代の話なので、うのみにするとヤバイかも
    • 物理層でかなりいろいろやっている
      • ラックを超えるときはスイッチを担当するブレードを経由してからつなぐ、など
    • NWは普通のI/Aサーバと変わらない
    • eg) Egenera BladeFrame
      • ラック1本まるまる専用機、ブレードに仮想化を提供するもの
      • 専用物理レイヤー(Spine)があり、スイッチ担当ブレードはL1スイッチング相当をやっていてNW的にはダイレクト通信になる
      • Oracleラックをこのブレード上で走らせると早かった
  • 処理の粒度によってインターコネクトの要求、要件は変わりますね
    • shared everything/memory/disk/nothing の区別、とか
      • 共有するメディアに負けないくらいの速度がインターコネクトに要求される

InfiniBand利用状況 さくらのクラウドの場合

  • 鷲北さん
    • さくらインターネット
    • 会社が4人の頃からエンジニアをやっています
    • 研究所所長→現場に戻されてクラウドのリーダー
    • 最近のさくらはDC事業は3割くらい、ホスティングが6割になりました
      • このオフィスも都市型DCです、コロケーションで表に出せるお客様があんまりいない
  • さくらとInfiniBbandの関係
    • そもそもなぜさくらとクラウドとの関係が?
    • さくらインターネット研究所
      • 実は今研究をしているのは松本さん一人、幽霊研究員が3人
      • インターネット関連なら何でもOK
      • 10GbE+技術
        • この過程でIBに注目
      • IoT関連の論文を書いたり
      • IBの研究テーマ
        • HCA, SWの評価
        • Linuxサーバで使えるのか、のドライバ検証
        • 10GbEとの比較
  • 2010年頃の評価
    • pros: 10GbEよりもポート単価が安い、レイテンシが低い、広帯域
      • DDR(20Gb)主流の中に40GのQDRが出てきた頃、IB 32Gが実測27Gbpsくらいだった
    • cons: 社内運用実績が少ない、ドライバ安定性が未知数、インターネットにどう繋ぐか?
      • ブリッジが必要になる
    • さくらのくらうどの第1世代で稼働して、4年目くらい
  • さくらのクラウド
    • 1ヶ月目でストレージに大トラブルが
    • IBに対応してるストレージがコレだけだった
      • opensm(subnet manager)が詰め切れてなかった
      • 完全安定まで2ヶ月、それ以降は不具合無し
    • ノード数500くらい
      • eastもwestも帯域は十分に余っていて、10GbEくらいでぜんぜん大丈夫だった、というのが実情
  • HCA: 発熱に注意
    • loadにより加熱しがち
    • CPU負荷は増えない
    • ケーブルが太くて堅い
      • HPCではIBケーブルは一旦挿したっきり抜かないというのが常識らしいが、さくらでそれをやると怒られる
      • 設置の見極めが難しい
      • 2~3習慣
    • 年間10枚くらい故障してる
      • Etherに比べて多め、エラーレートがじわじわ上がってきて壊れる、というパターンが多い
  • ドライバ
    • Mellanoxのドライバが最も安定している、他に2つあるがSWも作っているのでMellanoxは3rt partyというよりはベンダっぽい
    • Xsigoのドライバが鬼門
      • Oracleに買収されちゃった
      • Xsigo時代は1日以内でパッチが返ってきていたが、Oracleになってから社長はBrocadeへ
      • ドライバのアップデートが止まってしまった
    • さくらではXsigoじゃない製品を探しに行く、しかし代わりが見つからない
  • IBは素晴らしい技術だが
    • IBで閉じてれば最強
    • Ethernetとのブリッジが課題、ここにマトモなソリューションがないと厳しい
    • 第2第3は10GbEです
      • 10GbEがすごい安くなった、'12にはほぼ同じくらいの値段に(まだIBの方がぎりぎり安い、くらい)
      • サーバ・スイッチ間は10GbEで足りる、という知見が得られた
    • DC運用・サービスを作る上ではこういう結論になりました
  • IB以外に試したものは実は無い
  • Converged Ethernet(ストレージとのTCP接続)
    • コンバージドだちょっと高い、ストレージはFCじゃなくてiSCSIなのでTCPで十分
    • サーバメーカからも潤沢なオプションがないと手を出しにくい
    • 現状では切り替えてもあんまり性能・運用コストに差が出ない
      • ポート単位の監視ができない、スイッチでは何も出来ないのでサーバ側で監視を頑張っている
    • システムのアップデートがドライバでブロッキングされるのは非常に恐ろしい
      • セキュリティイシューをそれで足止めされるとデッドロックになっちゃう
      • こうなるとカーネルパッチを自分たちで書く、ということをしている
  • トラフィックの種類は?
    • だいたいeast/northwestで同じくらいで、我々も内訳がいまいちわかっていない
  • IBで良かったのはDRBDの同期がスペシャルに早かった

Interconnect casual: 『京』

  • 現職: Google Chrome
  • 前職: 富士通 次世代TC開発本部
    • 京のインターコネクトのチップを作っていました
  • HPCの話をします
    • あくまでも既知の情報をまとめています、ということで
  • High Performance Computing、あるいはTechnical Computing
  • 極端な例: スパコン世界ランキング
    • LINPACK
      • n*n線型方程式系 Ax = b を解く
      • 巨大な行列計算
      • サイズはメモリには載り切らないくらい
    • 実効/理論性能: 10.51/11.28[PFlops] = 93.2%
      • 残りの6.8%で通信を行う
    • 実行時間: 約30時間
      • 高信頼: チップあたり10FIT(1億時間平均で1回故障)
        • クルマに載せるミッションクリティカルでも二桁いくかくらい、かなりエクストリーム
      • ボードあたり40FIT → 90%の確率で壊れずに終了
  • 理論性能: 11.28PFlops
    • 積和(=乗算+加算)計算回路4 * 8コア @ 2GHz、が88,128チップ、キャッシュほぼ100%で当てつつこれをNWで同期を取りながら93.2%の稼働率を維持し続ける
  • わかり易い例
    • 宇宙関連
    • 医療関連
      • 生体分子
      • 巨大分子の第一...(創薬)
      • 脳神経シミュレーション
    • こういうケースだとワークロードは10%を切るくらい
  • 要件は複雑
    • 通信パターンは様々
      • 頻度
      • 組み合わせ
        • 隣接間のみ
    • 様々な状況で低遅延、広帯域、高信頼
  • 通信のコストは並列度の関数でもっと大変、サチりやすい

  • Tofu Interconnect

    • その実装、ICC
      • Core 2 Duoくらいの規模のものを0から設計・実装した
    • メッシュかトーラス、6次元
      • 「ここはどんなに説明してもわからない」
      • 3次元が2つある
        • 折りたたまれた3次元(Tofu Unit)の頂点それぞれが独立した3次元トーラス、各ホップが短い(1μs/hop)
    • RDMA
      • チップが自立してDRAMノード間メモリコピー
    • キャッシュインジェクションは検討して捨てた
      • バグが出やすい、デコヒーレンスを詰めきるスケジュールがなかった
    • 宇宙線対策
    • 畳み込まれた次元でトランキング
      • 最初の1hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
        • トランキングに加えて耐故障性
      • 隣接する3つのコントローラを巻き込んで対向に送ることで5GB/s * 4 = 18(実効)/20(理論)GB/s
  • HPC汎用 = 万能が求められる

    • 高機能
      • 自立通信・演算
      • 仮想記憶
    • 高性能
      • 低遅延
      • 広帯域
    • 信頼性
      • 10 FIT
      • 故障検出
    • 柔軟性
      • 任意サイズの仮想1/2/3次元トーラス
      • 故障迂回
  • 当時アメリカのBluewaterは動かしきれずにポシャった
    • 「bluewaterが上積みしても出し抜けるようにTofuは理論的にはもうちょっと伸ばせるように設計しておいた」
  • アクセラレータは計算する分野を絞る、Tofu・京はベンチマークマシンで終わらせてはならないという至上命題があった、それで高くなったという側面がある
  • 汎用とはいえセキュア演算回路を普通じゃありえないくらい載せてます
  • 中心メンバー10人、外注含めたら50人、プラス検証で10人
    • 全部が出来ないと動かないので、仕様自体は数人

たまにはTeradataのこと、思い出してあげてください

  • tweetはしないでいただきたい...
  • 青木峰郎
  • 最強の並列RDBMSであるTeradataのインターコネクト
  • ジョブズWWDCで喋ってる時のラックが何故かTeradataのラック

  • 30年前から並列

    • Teradata RDBMS(1983~)
    • 全部専用HW
    • v2は486を1000台くらい繋げる構想だったらしい
  • Shared Nothing Parallel
    • AMP(プロセッサ)が自分専用のdiskを持って、ノード間をまたぐことはない
    • 最大2000ノード、リニアにスケール
    • ex.)Oracleに代表されるのがShared Everything(diskが1つ)
  • Redshiftの構成
    • Leader Node *1
      • SQLを受け付ける
    • Compute Nodes *n
    • Hadoopにもある、名前はいろいろあるけど大差はない
  • Teradataのマルチマスター
    • すべてのノードがマスターになれる
    • PE(パースソフトウェア)とAMPを繋ぐのがBYNET、専用ハードウェア
  • 業界最強WLM、割愛します
  • Shared Nothingはインターコネクトが急所
    • ノードローカル処理最高
    • 突然の再分散
      • インターコネクトに一気にデータが集中して死ぬ
    • 他ノードのデータとJOIN/GROUP BYしたいとき
    • 並列DBのインターコネクト
      • Hadoopだと10GbEが一般的
      • TeradataはBYNET v5、10Gbps * n
        • カタログに* nって書いてある
        • 「ノード数に比例して帯域が増えます」
  • BYNETのすごいスイッチ
    • 全体全
    • 一時期AT&Tが使っていたようで、その時ベル研究所に作ってもらったらしいです
    • 数十台につきスイッチを増やさないといけない、らしい
    • InfiniBandに取って代わられ、最上位機種100台以上のときだけ登場する
  • Teradata on AWS
    • BYNETはない
  • さらばBYNET
    • たまにはTeradataのことも思い出してあげて下さい