第31回「今アツい、分散ストレージを語ろう」(2013/11/28 on しすなま!)
•
36 gefällt mir•18,631 views
下記のしすなま!録画と併せてご覧ください。資料・録画の内容は生放送時点のものです。 第31回「今アツい、分散ストレージを語ろう」(2013/11/28) <出演①> 織 学 日本アイ・ビー・エム(株) ATC. Linux/OSS & Cloud Support Center <出演②> 石川 公基 日本アイ・ビー・エム システムズ・エンジニアリング(株) 仮想インフラ・ソリューション <出演③> 半田 達郎 日本アイ・ビー・エム(株) システムｘ事業部．テクニカル・セールス <出演④>早川 哲郎 日本アイ・ビー・エム(株) システムズ & テクノロジー・エバンジェリスト http://www.ustream.tv/channel/systemxlive#/recorded/41180609
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie 第31回「今アツい、分散ストレージを語ろう」(2013/11/28 on しすなま!)
Ähnlich wie 第31回「今アツい、分散ストレージを語ろう」(2013/11/28 on しすなま!) (20)
Mehr von System x 部 (生!) : しすなま! @ Lenovo Enterprise Solutions Ltd.
Mehr von System x 部 (生!) : しすなま! @ Lenovo Enterprise Solutions Ltd. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
第31回「今アツい、分散ストレージを語ろう」(2013/11/28 on しすなま!)
- 2. 本日のパネリスト 織 学（Manabu Ori) Linux/OSS Cloud サポートセンター 石川 公基 ＩＳＥ．仮想インフラ・ソリューション 半田 達郎 System x事業部．テクニカル・セールス New New New 早川 哲郎（Tetsuro Hayakawa） System xエバンジェリスト 2
- 5. 最近のサーバーは大量ストレージが搭載可能になっている 3.5型 SSD/HDD x 14本 HDD 4TB x 14 = 56TB SSD 800GB x 14 = 11.2TB 2.5型 SSD/HDD x 26本 HDD 1.2TB x 26 = 31.2TB SSD 1.6TB x 26 = 41.6TB 2.5型 SSD/HDD x 32本 HDD 1.2TB x 32 = 38.4TB SSD 1.6TB x 26 = 51.2TB 5 これらのサーバーの用途は何なのか？
- 11. 構成要素 • x86サーバー • ストレージ – – – – サーバーの内蔵ディスクを使用 SAN, iSCSI等で接続する外部ストレージは使われない RAIDを構成せず、JBODで使う場合も多い SSD, PCIe型NAND Flashを使う場合もあるが、多くの場合は容量単価重視でSATA HDD • ネットワーク – 1GbE, 10GbE, InfiniBand • ソフトウェア (ミドルウェア) – 死活監視、データの複製、障害時の自動修正等は全てこの層で自動で行われる 11
- 14. 運用イメージ 「壊れたら 直さず 取り替える」 – データは必ず複製がどこかに保持されているので 運用を単純化して膨大な数のサーバやHDDの管理コストを下げる •例) 壊れてもバックアップから戻したりしない 障害発生のHWを切離して、まっさらな新規HWを追加する 壊れてもすぐ取り替えない 内蔵 HDD 12本のうち、半分が壊れるまで放置 壊れたらサーバごと切り離す 壊れたら壊れっぱなし ラック内の稼働率を見て ラック単位でリプレース データは同じところに再複製する or 別のところに再配置する 14
- 15. RAIDとホットスワップ • RAIDが必要かどうかは、使うソフトウェアによる – RAIDを構成した方がいい場合 •トランザクションのスループットとして、HDD 1個分以上のスループットを出したいとき •例： GlusterFS – JBODでも大丈夫な場合 •HDD 1個分程度のスループットでいいとき •複数HDDに並列アクセスするようなワークロードのミドルウェア •例： HDFS, Swift • ホットスワップが必要かどうか – HDD交換時はノード停止が伴う ⇔ ノード停止のインパクトがどの程度か？ –基本的に、どのソフトウェアを使っても「全同期やり直し」が発生 – RAIDを構成する場合はホットスワップの方がよさそう – JBODの場合はお客様要件による 15
- 16. 分散ストレージソフトウェアの種類 種別 POSIX互換 性 メタデータ管理 分散単位 開発元 API GlusterFS ファイルシステム あり (不完全) メタデータ管理ノードなし ファイル Red Hat POSIX, REST, HDFS, Swift Ceph ファイルシステム あり メタデータ管理ノードあり ブロック Inktank Native, POSIX, REST, Swift (GPFS) ファイルシステム あり メタデータ管理ノードなし ブロック IBM POSIX, HDFS (GPFS FPO) HDFS ファイルシステム なし メタデータ管理ノードあり ブロック Apache Native (Google File System) ファイルシステム なし メタデータ管理ノードあり ブロック Google Native Swift オブジェクトストレージ - メタデータ管理ノードあり ファイル OpenStack Foundation REST (Amazon S3) オブジェクトストレージ - P2P型？ ？ Amazon Web Services REST Cassandra NoSQL - P2P型 - Apache Native, REST HBase NoSQL - P2P型 - Apache Native MongoDB NoSQL - P2P型 - 10gen Native, REST, HDFS Redis NoSQL - P2P型 - Pivotal Native, REST Riak NoSQL - P2P型 - Basho Native, REST(Riak CS) (Google BigTable) NoSQL - 集中管理型？ - Google Native NoSQL - P2P型？ - Amazon REST (Amazon DynamoDB) 16
- 18. GPFS (General Parallel File System) 約20年の実績のある 並列ファイルシステム – データはストライプ分散が基本 – ディスクはRAID構成・共有が基本 フェイルオーバーが十全に行えるような サーバのペアリングや設定は必要です App. App. App. App. App. App. App. App. 高い可用性 – Active-Active構成の 分散コンポーネントにより構成 GPFS or NFS – HAクラスタソフト不要で可用性を保持 •GPFS 自身のコンポーネントは 冗長化機能を提供 •NFSクライアントに対しては Clustered NFS 機能を提供 – 対ディスク障害を想定する場合は、 GPFSレベルでレプリカの作成が可能 全コンポーネントがHA構成 個別のクラスタソフトは不要 GPFS シングルイメージ GPFS snapshot スナップショット機能の活用 18 – ファイルシステム状態の版管理 クライアントはGPFS Native プロトコルか NFSプロトコルでアクセス 3月31日時点 4月1日時点 対ディスク装置障害用に ブロックレプリカ作成も可能
- 19. GPFS-FPO (File Placement Optimizer) GPFSの拡張版 App. App. App. – シェアードナッシング構成 •データ保護はレプリカが基本 従来のGPFSの特長はそのまま – Active-Active構成の 分散コンポーネントにより構成 – HAクラスタソフト不要で可用性を保持 – スナップショット機能の活用 シェアードナッシング構成向けの拡張 – レプリカ作成数の上限拡大 (2 -> 3) – レプリカ配置アルゴリズムの拡張 – パイプライン・レプリケーション – データローカリティ対応用の拡張 19 GPFS シングルイメージ App. App.
- 21. Lustre フェイルオーバーが十全に行えるような サーバのペアリングや設定は必要です HPCで事例の多いファイルシステム 非対称型分散構成 – メタデータとデータを分離 App. App. App. App. App. App. App. App. – データノードのスケールアウトが容易 Lustre Protocol クライアントは Native プロトコルアクセス LustreFS シングルイメージ メタデータサーバ (MDS) 21 データ格納サーバ (OSS)
- 22. GlusterFS 複数ノードのファイルシステムをまと めて仮想的な大きいファイルシステ ムとして提供 ファイル単位で分散配置 ファイルの配置は、専用ハッシュ関 数を通してパス名から算出 レプリケーションボリューム ノード1 ノード2 – Cinder driver – Swift API Red Hat社がRed Hat Storageとして商 用サポート 22 ファイル ファイル A ブリック ブリック A ブリック ボリューム – クライアント側の演算のみで判明 レプリカ数、ストライプ数は設定で変 更可能 OpenStackとの連携 ノード3 ファイル A クライアント ストライプボリューム ノード1 ブリック ノード2 ブリック ボリューム クライアント ノード3 ブリック
- 23. Ceph 独自のオブジェクトストレージRADOSに対して 様々なアクセス方法を提供 – POSIX API (MDS) •クライアントコードはLinuxカーネルに統合ずみ – 専用ネイティブAPI (librados) – S3互換API (RADOS Gateway) – ブロックデバイス (RBD) – OpenStack Swift API ファイルシステムのメタデータは専用の メタデータサーバで管理 – サブディレクトリごとにメタデータサーバをわけて 負荷分散することが可能 スナップショット レプリケーション ストライプ 23 http://ceph.comより引用
- 24. HDFS 普通の階層型ファイルシステム フォールトトレラント – ハードウエアは信頼できないのでソフトウエ ア設計でカバー データスループット志向 – レイテンシーはちょっと犠牲 – POSIX互換も気にしない 巨大で大量なデータを扱う – 1000万ファイル以上 – GigabyteからTerabyte単位のファイル Write once, NO Change． – データ整合性の課題を回避 – Appendはサポートしたい意向 “Moving Computation is Cheaper than Moving Data” – データのあるところにアプリケーションを貼 り付けることを容易にするためのAPIを提供 する 24 まずは量 次に複雑性 安全最後 （でもちょっとほしい）
- 25. Google File System (GFS) x86サーバで構築した分散ファイルシステム 「x86サーバは壊れる」という前提で設計 – 壊れてもデータが失われない、自動的に復旧できる、ことを主眼に開発 ファイルは64MBのチャンクに分割されて、3台の異なるノードに保存 基本的に追記および読み出しを中心に想定 1台+αのマスターノード、複数のチャンクサーバ 25
- 27. Swift オブジェクト・ストレージのサービス (Amazon S3相当) HTTP (REST API) でアクセスするファイルサーバー Glanceと連携して、仮想マシンのイメージ置き場としても使用可能 構成要素 – ストレージノード •オブジェクトを保持する – プロキシーノード •ストレージノードに振り分ける •プロキシーノードへの振り分けはDNSラウンドロビンやロードバランサーを使用 高い可用性、自己修復機能 – – – – RAID不要 デフォルトで３つの複製を作成し、異なるストレージノードに配置 データ破損や消失を自動的に検知して修復 内部ではrsyncを使っている Swift 容易にスケールアウト、容量増加が可能 Client HTTP 27 Proxy Proxy Proxy Node Node Node HTTP Storage Storage Storage Storage Node Node Node Node
- 28. Amazon S3 AWS主力サービスのひとつ 2006年より利用開始 “Webスケール”なコンピューティングを 想定した特徴 – 高いスケーラビリティ – 高い信頼性・堅牢性 – セキュア – 高速 – 低価格 シンプルなAPI – PUT/GET/DELETE/LIST 28
- 30. NoSQLに至る背景 – 原点はmemcached データ層のスケーラビリティ確保に課題 – 大規模なWeb系システムにおいて徐々に問題として顕在化 解決策のひとつとしてMySQLのレプリ (+ memcached) – マスタ + マルチスレーブで負荷分散というアイディアが広まる LoadBalancer 解決が困難だった点 – 極端にライトに負荷がかかる場合 •マスタへのライトがボトルネックになる Master – マルチマスタにする場合 •データ同期の問題 – シャーディングする場合 •アプリケーションのメンテナンス・コスト増大や可用性 •フレームワークでクッションする場合はフレームワークのメンテナンスが課題になる Sharding by App – リード負荷分散でデータ整合性の制御が困難 •MySQLのレプリ任せ + 負荷分散装置のロジックに依存 •データの扱いについては最終的にアプリケーションでの判別ロジックに負荷 RDBMSほど高機能でなくてもいいので 最初から速度やスケーラビリティを重視して アプリ側の負担を軽くする分散型データ・ミドルウェアを新規開発する、という風潮が生まれる 30
- 31. NoSQL NoSQL = Not only SQL – SQL = RDBMS ファイルシステムとRDBMSの中間的存在 – ファイルシステムより機能豊富 •(NoSQLは)後からデータを取り出す”キー”を決めて使う （データベースっぽい点） •一部だけデータを取出したり更新したり加工したりするのが〔ファイルより）速くて便利 – RDBMSほど高機能でない・信頼性はない •NoSQLは（フル・スペックの）SQLが使えない SQLっぽい方式でデータの出し入れが可能なことはある •NoSQLはお金の出し入れなど重要なトランザクション処理を間違えない…とは限らない 間違わせないようにするにはアプリケーションで工夫が必要 – RDBMSより（だいたい）動作速度が高速 •もしくは速度以外の点で RDBMS を凌駕する性質を持つ 利用例 – Webサイトの裏側でよく読まれる情報（キャッシュ） •小さい画像、ユーザの属性情報 – Webサイトの裏側で頻繁に更新される細かいデータ •細かい行動履歴(足あと） – RDBMSに挿す前のトランザクション・データ 31 •ショッピングカートの中身
- 32. Apache Cassandra 読込みも得意（高速）だが 書込みがもっと得意（高速）なNoSQL データを広く分散させるように使いや すい – ひとつひとつのレコードに 素早くアクセスすることに特化 – 連続したデータを集めて、集計する用 途には向いていない token token token Logical Ring Topology token 稼動継続性が高い – 常にデータが読める・書けるが、最新 データとは限らない token token here 著名な利用事例 – Facebook – ebay token メモリ内データ Cassandra Server Hash! here 32 token 先行書込みログ 永続化ファイル
- 33. Apache HBase ユーザからは表のように扱える NoSQLの一種 Hadoopと組合せると超巨大なExcel ワークシートとして使える – 集計関数などは、Hadoopのほかの仕組 みでプログラミングする – Hadoop HDFS の上で稼動する 半ばインメモリデータベースのようにし て使っている例も多い 著名な利用例 – Twitter – Facebook – LINE Application User HTable HMaster HSlaves (HRegionServers) – IBM Smart(er) Cloud Provisioning 33 HDFS
- 34. 10gen MongoDB NoSQLの中では比較的汎用性が高い データの表現形式がJSON JSON形式でのデータ表現例 – 操作体系的には、JavaScriptアプリケーション {name: 'Horny', dob: new (AJAXやサーバーサイドJS)との相性がよいので、 Date(1992,2,13,7,47), Web企業に受けがよい loves: ['carrot','papaya'], weight: 600, •JS以外の言語からでも当然使える RDBMSから転換しやすい – パっと見RDBMSっぽくないものの RDBMSのノウハウや概念も通用する 部分があるのでスキル移行しやすい •テーブルやレコードに近似する概念あり •検索を高速化するためのインデックス •インデックスのメリ/デメのトレードオフ 地理情報演算用の関数組込みなど 時流にそった機能拡張もある gender: 'm', vampires: 63} RDBっぽいクエリ (SELECT/INSERT/UPDATE相当の例) db.unicorns.find({gender: 'f', $or: [{loves: 'apple'}, {loves: 'orange'}, {weight: {$lt: 500}}]}) •ある地点から周囲 X kmの範囲のオブジェクト（店と db.unicorns.insert({name: 'Horny', dob: new Date(1992,2,13,7,47), か）を抽出する、など loves: ['carrot','papaya'], weight: 600, 著名な利用例 gender: 'm', vampires: 63}); – CyberAgent Ameba – 楽天 – …etc. 34 db.unicorns.update({name: 'Roooooodles'}, {weight: 590})
- 35. Redis 分散オンメモリ型のデータ構造ストア – プログラマがよく使うデータ構造と定番操作をそ のまま機能としてサポートしている •ハッシュ、リスト、セットなど •自分でファイルに書いて管理するよりレプリケーショ ンしてくれたり、サポートされているデータ構造の要 素操作のATOMICITYを保証してくれたりするので便 利 – オンメモリ型なので高速 •書込みはバックグラウンドでディスクに書出しされて 永続化される 著名な採用事例 – Github – LINE (Hbase移行前) – Ameba (ランキング) – ニコニコ動画 35
- 36. Basho Riak Cassandraとほぼ同じような特徴 – どちらもAmazon Dynamo Inspiredだから 後発ゆえ下記のような工夫（もしくはマイルドな要素）が付加 – REST API (HTTPによる操作)でのCRUD操作に対応しているので最近のクライアント(JS の動くブラウザやスマホ)アプリから操作しやすい – Map/Reduce演算によるアドホックな集計処理の実行に対応 – セカンダリ・インデックス（プライマリ以外の索引）が持てる •二次索引対応のためGoogle Level DB ライブラリをバックエンドで利用 – 全文検索ベースのクエリが打てる Riac CS (Riak の追加ソフトウェア) を使うとオブジェクトストレージとして利用可能 著名な利用例 – Wikia – Yahoo! 36
- 37. (参考) Amazon Dynamo DB Cassandra, Bashoの元ネタ 2007年に論文公開 – Amazon.comが自社のショッピングカートに利用 – 理論を論文として公開（ソフトウェアは非公開） – CassandraやBashoなどのOSSが登場 2012年からAWSでサービス開始 – 自社構築をやめるユーザも出てくる可能性あり 37
- 38. (参考) Google BigTable CassandraやHBaseの元ネタ – 2006年に論文発表 •Googleが自社の様々サービスのデータ格納庫として利用 – HbaseなどのOSSが登場 – 2008年にGoogle App Engine のデータ層として 利用可能に 38
- 40. Windows ／ VMwareの最近のストレージ機能拡張 Windows Server 2012 / 2012 R2 – ファイルサーバー、ストレージ関連で大幅な機能拡張 New! iSCSI NFS SMB3.0 CIFS スケールアウトファイルサーバー New! NTFS New! ReFS 重複除去 New! New! ストレージサービス •SMB3.0：マルチチャンネル、透過的フェイルオーバー、 暗号化、帯域制御… •スケールアウトファイルサーバー（SOFS） ファイルシステム •NTFS重複排除：オンラインVHDX対応（VDIのみ） •ReFS：耐久性・拡張性に優れた新ファイルシステム •階層化ストレージ 記憶域プール •Write Back Cache SSD HDD HDD ディスク管理 •記憶域プール：物理ディスクのプール化 •(R2~)階層化ストレージ、SSD Write Back Cache vSphere 5.5 – SSD活用とストレージ仮想化機能の強化 •Virtual SAN：分散共有型データストア •Flash Read Cache：SSDを活用したディスクアクセス高速化 40
- 41. スケールアウト・ファイルサーバー（SOFS） ファイルサーバーのアクティブ-アクティブクラスター Microsoft Windows Server 2012より追加されたファイルサーバーのクラスタリン グ方式 Windows の共有フォルダを複数のファイルサーバーホストで分散して提供する フェイルオーバー発生時も（ほぼ）停止なし VM VM VM Hyper-V VM Hyper-V SOFS（¥¥SOFS¥share） アクティブ アクティブ File Server 41 Cluster Shared Volume File Server 特徴 • ファイルサーバーのアクティブ-アクティブクラス ター（WSFCを使用） • 最大8ノードまで構成可能 • SMBの透過的フェイルオーバーをサポート • Hyper-V、SQL Serverなどのアプリケーション・ ワークロードに最適化 • 共有ディスク領域にCSVを使用 • 負荷の自動リバランスなども可能(R2から)
- 42. Hyper-V over SMB with SOFS SOFSの使用例：Hyper-V基盤の共有ストレージ – Hyper-V仮想マシンファイルをSOFS共有フォルダ上に配置する – ファイル共有プロトコル SMB3.0で構成すればSANのスキル不要 – 規模に応じてHyper-Vホスト、ファイルサーバーを個別にスケールアウト WSFC（Hyper-Vクラスター） ゲストOS ゲストOS ゲストOS Hyper-V ゲストOS Hyper-V ゲストOS ゲストOS Hyper-V ファイル共有プロトコル（SMB3.0） WSFC（SOFS） 42 Hyper-V ホスト • WSFCクラスターを構成 ネットワーク構成 • 10Gb EthernetまたはInfinibandを推奨 • SMB DirectやSMBマルチチャンネル を活用 ファイルサーバー（冗長構成） • SOFSでHyper-Vのワークロードを負 荷分散 • 共有ストレージ上にCSVを配置
- 43. Virtual SAN（VSAN） VMware ESXiのローカルディスクを共有ストレージとして使用 vSphere 5.5で追加された共有ストレージ構成。現在パブリックベータとして VMware社より提供されている サーバーハードウェア内蔵のSSDとHDDを利用して共有ストレージを構成する ポリシーベースでのデータ管理を行う（次ページ） vSphereクラスター VMware ESXi VMware ESXi VMware ESXi vSAN Datastore VSAN (分散共有ストレージ) 43 特徴 • 使用可能な実用量はHDD領域の合計容量 • SSDはキャッシュ領域として使用される • ホスト間はVSAN専用のネットワーク構成が必 要 10Gbネットワークでの構成を推奨 • 3ノード～8ノードの構成をサポート • オブジェクトに対するポリシー設定により、データ のレプリカ数・ストライプ数を柔軟に設定できる
- 44. VSANでのストレージポリシーの適用 •仮想マシンの作成 •VMDKファイルに定義済のポリシーを設定 VM 許容障害台数（レプリカ数）=1 ストライプ数=2 データ •データ書込が発生 データ •ポリシーに応じたデータ処理 ※実際の処理はデータのオーナーとなるESXiホストが実行 レプリカ データ 1 2 VMware ESXi 1 データ 1 1 VMware ESXi 2 •SSDに書込処理を実行 •SSDから適宜HDDにデステージ 44 ストライプ 2 2 VMware ESXi 1 VSAN Data Store 1 VMware ESXi 2 2
- 46. 次回 しすなま!第32回のご案内 【日時】 –2013年12月19日(木) 18:00-19:30 (約90分) 【テーマ】 –クリスマス特集 –年末恒例 ネットワークの最新動向 【出演】 –パネラー：今年もサンタクロース登場か？ 46 乞うご期待
- 47. ご清聴ありがとうございました