Interconnect Casual
Interconnect variations
- 田籠さん
- トレジャーデータ
- インターコネクト ... 分散システム同士の内部の通信
- HPC
- 分散DB
- Hadoop
- ソフトウェアで完結するもの、HWを使うもの
- なぜそんなことを？
- 目的を満たすほどに速い
- スループットとレイテンシ両面において十分に速い、ということ
- Hadoop
- ブレードサーバ
- 処理の粒度によってインターコネクトの要求、要件は変わりますね
- shared everything/memory/disk/nothing の区別、とか
- 共有するメディアに負けないくらいの速度がインターコネクトに要求される
- shared everything/memory/disk/nothing の区別、とか
InfiniBand利用状況 さくらのクラウドの場合
- 鷲北さん
- さくらインターネット
- 会社が４人の頃からエンジニアをやっています
- 研究所所長→現場に戻されてクラウドのリーダー
- 最近のさくらはDC事業は3割くらい、ホスティングが6割になりました
- このオフィスも都市型DCです、コロケーションで表に出せるお客様があんまりいない
- さくらとInfiniBbandの関係
- 2010年頃の評価
- さくらのクラウド
- １ヶ月目でストレージに大トラブルが
- IBに対応してるストレージがコレだけだった
- opensm(subnet manager)が詰め切れてなかった
- 完全安定まで２ヶ月、それ以降は不具合無し
- ノード数500くらい
- eastもwestも帯域は十分に余っていて、10GbEくらいでぜんぜん大丈夫だった、というのが実情
- HCA: 発熱に注意
- loadにより加熱しがち
- CPU負荷は増えない
- ケーブルが太くて堅い
- HPCではIBケーブルは一旦挿したっきり抜かないというのが常識らしいが、さくらでそれをやると怒られる
- 設置の見極めが難しい
- 2~3習慣
- 年間10枚くらい故障してる
- Etherに比べて多め、エラーレートがじわじわ上がってきて壊れる、というパターンが多い
- ドライバ
- IBは素晴らしい技術だが
- IB以外に試したものは実は無い
- Converged Ethernet(ストレージとの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%の確率で壊れずに終了
- 高信頼: チップあたり10FIT(1億時間平均で1回故障)
- LINPACK
- 理論性能: 11.28PFlops
- 積和(=乗算+加算)計算回路4 * 8コア @ 2GHz、が88,128チップ、キャッシュほぼ100%で当てつつこれをNWで同期を取りながら93.2%の稼働率を維持し続ける
- わかり易い例
- 要件は複雑
- 通信パターンは様々
- 頻度
- 組み合わせ
- 隣接間のみ
- 様々な状況で低遅延、広帯域、高信頼
- 本来トレードオフであるべきものが全て求められる
- 通信パターンは様々
通信のコストは並列度の関数でもっと大変、サチりやすい
Tofu Interconnect
- その実装、ICC
- Core 2 Duoくらいの規模のものを0から設計・実装した
- メッシュかトーラス、６次元
- 「ここはどんなに説明してもわからない」
- ３次元が２つある
- 折りたたまれた3次元(Tofu Unit)の頂点それぞれが独立した３次元トーラス、各ホップが短い(1μs/hop)
- RDMA
- チップが自立してDRAMノード間メモリコピー
- キャッシュインジェクションは検討して捨てた
- バグが出やすい、デコヒーレンスを詰めきるスケジュールがなかった
- 宇宙線対策
- 畳み込まれた次元でトランキング
- 最初の１hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
- トランキングに加えて耐故障性
- 隣接する3つのコントローラを巻き込んで対向に送ることで5GB/s * 4 = 18(実効)/20(理論)GB/s
- 最初の１hopだけ決定論的に決まるものをあえて使わずに、隣接するものを巻き込んで送る
- その実装、ICC
HPC汎用 = 万能が求められる
- 高機能
- 自立通信・演算
- 仮想記憶
- 高性能
- 低遅延
- 広帯域
- 信頼性
- 10 FIT
- 故障検出
- 柔軟性
- 任意サイズの仮想1/2/3次元トーラス
- 故障迂回
- 高機能
- 当時アメリカのBluewaterは動かしきれずにポシャった
- 「bluewaterが上積みしても出し抜けるようにTofuは理論的にはもうちょっと伸ばせるように設計しておいた」
- アクセラレータは計算する分野を絞る、Tofu・京はベンチマークマシンで終わらせてはならないという至上命題があった、それで高くなったという側面がある
- 汎用とはいえセキュア演算回路を普通じゃありえないくらい載せてます
- 中心メンバー10人、外注含めたら50人、プラス検証で10人
- 全部が出来ないと動かないので、仕様自体は数人
たまにはTeradataのこと、思い出してあげてください
- tweetはしないでいただきたい...
- 青木峰郎
- Rubyの標準ライブラリ作者、著者
- テラデータ→クックパッド
- 好きなバス: HyperTransportとBYNET
- 最強の並列RDBMSであるTeradataのインターコネクト
30年前から並列
- Teradata RDBMS(1983~)
- 全部専用HW
- v2は486を1000台くらい繋げる構想だったらしい
- Shared Nothing Parallel
- AMP(プロセッサ)が自分専用のdiskを持って、ノード間をまたぐことはない
- 最大2000ノード、リニアにスケール
- ex.)Oracleに代表されるのがShared Everything(diskが1つ)
- Redshiftの構成
- Teradataのマルチマスター
- すべてのノードがマスターになれる
- PE(パースソフトウェア)とAMPを繋ぐのがBYNET、専用ハードウェア
- 業界最強WLM、割愛します
- Shared Nothingはインターコネクトが急所
- BYNETのすごいスイッチ
- Teradata on AWS
- BYNETはない
- さらばBYNET
- たまにはTeradataのことも思い出してあげて下さい
