Azure Storage Partition Internals
•Als PPTX, PDF herunterladen•
4 gefällt mir•3,076 views
.NET Fringe Japan 2016 Azure Storage の Partation の実装
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Azure Storage Partition Internals
Ähnlich wie Azure Storage Partition Internals (20)
Mehr von Takekazu Omi
Mehr von Takekazu Omi (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
Azure Storage Partition Internals
- 1. Azure Storage Partition Internals Takekazu Omi takekazu.omi@kyrt.in 2016/10/1 R.1.0.NET Fringe Japan 2016
- 2. 自己紹介 近江 武一 JAZUG Azure Storage 担当（自称） Microsoft MVP for Azure http://www.slideshare.net/takekazuomi kyrt @takekazuomi 2 kyrt.in github.com/takekazuom i white paper 監訳 2016/10/1
- 3. Deep ・・・ ・・・ ・・・ Drive ・・・Zzzzzzz kyrt @takekazuomi 32016/10/1
- 4. Partitionは、スケーラビリティ対策の基本であり鬼門 Range Partition では、 Partition Keyに悩み 水平分割（Sharding）と聞くと、ムムと思い Partition リバランス、Split, Merge とか聞くと、リ ソースの心配しか出てこない そんな人々に、Azure StorageのPartitionの話を kyrt @takekazuomi 42016/10/1
- 5. 元ネタ Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency 23rd ACM Symposium on Operating Systems Principles で、2011年に公開 翻訳：Windows Azure ストレージ: 高可用性と強い一貫を両 立する クラウド ストレージ サービス kyrt @takekazuomi 52016/10/1
- 6. Design Goals Highly Available with Strong Consistency ⇨ 障害時やネットワークパーテーショニング時にもデータアクセス を提供 Durability ⇨ データセンター内、あるいはDCに跨ったリプリケーション Scalability ⇨ Exabyte以上へのスケール ⇨ 世界中のデータへのグローバルなネームスペースでのアクセ ス ⇨ トラフィックに応じた自動的なロードバランシング kyrt @takekazuomi 62016/10/1
- 7. Azure Storage アーキテクチャ概要 kyrt @takekazuomi 72016/10/1 Storage Stamp LB Front-Ends Partition Layer Stream Layer intra-stamp replication Storage Location Service Storage Stamp LB Front-Ends Partition Layer Stream Layer intra-stamp replication Inter-stamp replication
- 8. Storage Stamp Storage Stampは、複数のstorage nodeが配置 された N 個のラックで構成されるクラスター 各ラックがネットワークと電源が冗長化された、 個別の障害ドメイン クラスターは通常、大容量のストレージ ノード 18 台をそれぞれ含むラック 10 ～ 20 個から構 成（2011年時点） kyrt @takekazuomi 82016/10/1
- 10. Open CloudServer OCS V2.1 Specification Open Compute Project ⇨MSのOpen Source 傾倒ぶりはハードに至る ⇨2016/2/9、最新 OSC V2.1を確認！ ⇨参照 http://www.opencompute.org/wiki/Server/Spec sAndDesigns kyrt @takekazuomi 102016/10/1
- 11. kyrt @takekazuomi 112016/10/1 Open CloudServer OCS V2.1 Specification Blade spec update P10 より http://www.opencompute.org/wiki/Server/SpecsAndDesigns
- 12. 汎用ラックに最大4chassisが搭載可 chassis に、12 tray。trayにblade 各2で、最大24 OSC bladeが搭載可 blade 例↓ kyrt @takekazuomi 122016/10/1 Open CloudServer OCS V2.1 Specification Blade spec update P11 より http://www.opencompute.org/wiki/Server/SpecsAndDesigns
- 13. Three Layers within a Storage Stamp ストレージスタンプ内の３つのレイヤー 2016/10/1 kyrt @takekazuomi 13
- 14. Stream Layer append onlyなdistributed file system 全てのデータは、 Stream Layer に保存 Stream は、extentsのリストで構 extentsは、3重に保存 kyrt @takekazuomi 142016/10/1 Extents SM SM SM Extents Extents Extents Extents Extents Extents Paxos
- 15. Partition Layer 高レベルなデータ抽象化 (BLOB、テーブル、キュー) オブジェクトに対するトランザクションと一貫性の確保 Stream layer へのオブジェクト データの保存 スケーラブルなインデックス（stream layer内の場所を保持） stamp間のリプリケーション kyrt @takekazuomi 152016/10/1 Partition Server Partition Server Partition Server Partition Server Lock Service PM
- 16. Storage Stamp Architecture kyrt @takekazuomi 162016/10/1 Massive Scale Out & Auto Load Balancing Index Layer Distributed Replication Layer FE REST Front End Layer Partition Layer Stream Layer FE REST FE REST FE REST FE REST FE REST FE REST FE REST PS PS PS PS PS PS PS write request read request
- 17. read request flow FE は、リクエスト からのパーテーション情報と Partition layer のpartition mapを参照してPSへ routing。ステートレスなレイヤー PSは、リクエストからStream layer上のどこにデー タがあるかをindex情報から判断してStream Layer から読む Stream layer は、データを3重に保存してあり、どこ からでも読める kyrt @takekazuomi 172016/10/1
- 18. ざっくり言うと 実データは、Stream layer に保存 Stream layer の何処にObjectがあるかの IndexをPartition layerで保持 FE layerは、Objectを操作するリクエストの受 け口 それぞれのレイヤーがクラスター構成 kyrt @takekazuomi 182016/10/1
- 19. Partition Layer 2016/10/1 kyrt @takekazuomi 19
- 21. Partition layer architecture kyrt @takekazuomi 212016/10/1 partition map table partition manager partition server 1 partition server 1 partition server 1 paxos lock service front end stream layer partition layer update read update lease watch lease assign partition
- 22. 主要コンポーネント PM: Partition Manager ⇨OTのメンテナンス PS: Partition Server ⇨パーテーションの処理 Lock Service ⇨パーテーション分割の調停ロック管理 kyrt @takekazuomi 222016/10/1
- 23. 主要 Data model OT: Object Table OTは、ObjectのStream layer上の位置を保持 するindex、メタ情報 数 PB まで拡張可 OTは、トラフィック負荷に基づいて複数の RangePartitionに動的に分割される 分割されたOTには、それぞれ１つのPartition Serverが割当てられる kyrt @takekazuomi 232016/10/1
- 24. OT: Object Table の種類 1. Account table: スタンプに割り当てられている各ストレー ジ アカウントのメタデータと構成を格納 2. Blob Table: Blob オブジェクトを格納 3. Entity table: Table entityを格納 4. Message table: Queue のすべてのメッセージを格納 5. Schema table: すべての OT のスキーマを保持 6. Partition map table: すべての OT の現在の RangePartition と、各rangeを処理しているPSをトラック。 FEはこのテーブルを使用して、要求を適切なPSにルー ティングする kyrt @takekazuomi 242016/10/1
- 25. PM: Partition Manager PM は、スタンプ内でOTを N 個のRangePartitionに分割 割り当て情報は partition map tableに格納 複数の RangePartition 間で重複が発生しないように調整 RangePartitionが割り当てられたPS間の負荷分散をする Stamp内では、PM のインスタンスは複数実行されており、 ロック サービス でリースを取れたPMのインスタンスが partition layer を制御するアクティブな PMとなる kyrt @takekazuomi 252016/10/1
- 26. PS: Partition Server PS は、PMに割り当てられた RangePartition に対する要 求を処理する。PS は、パーティションのすべての永続状 態をストリームに格納し、パーティション状態をメモリ キャッシュに保持 RangePartition を処理するPS は１つだけ。 RangePartitionで、同時実行されるトランザクションの一 貫性とシリアライズが可 単一のPS は、異なる OT の複数のRangePartitionを同 時に処理可能。現在の WASでは、PS により、常に平均 10 個のRangePartitionが処理されている（2011） kyrt @takekazuomi 262016/10/1
- 27. account container blob ssss sssss sssss ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ zzzzz zzzzz zzzzzz account container blob lllll lllll lllllll ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ rrrrr rrrrrr rrrrrr 例 kyrt @takekazuomi 272016/10/1 account container blob aaaa aaaa aaaa ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ kkkk kkkk kkkk Partition map A-K : PS1 K`-R: PS2 R`-Z:PS3 PS1 A-K : PS1 PS2 K`-R: PS2 PS3 R`-Z:PS3 Blob Index(RangePartition) Partition layer FE Cache A-K : PS1 K`-R: PS2 R`-Z: PS3
- 29. RangePartition – Log Structured Merge-Tree commit log stream meta data stream row data stream blob data stream stream layer partition layer memory table row page cache bloom filter read/querywrite 2016/10/1 kyrt @takekazuomi 29 index cache
- 30. RangePartitionのフロー OTは、各RangePartition 毎にstreamに永続化される 永続化には、 Log Structured Merge-Tree を使う 書き込み ⇨ commit log のstream と、commit logに書けた時点でFEに完 了を返し、 memory tableを更新する。 ⇨ memory tableが溢れた場合、データをblobは、blob stream へ、それ以外は row streamに書く 読み込み ⇨ memory tableを参照し無い場合は、stream layerから読む kyrt @takekazuomi 302016/10/1
- 32. RangePartitionの動的変更 Load Balance トラフィックが集中している PS を特定し、RangePartition を負荷の少な い PS に移動 Split 負荷が集中している RangePartitionを特定して 2 つ以上のより小さな分 離したRangePartitionに分割し、2 つ以上の PS 間で負荷を分散 (再割 り当て) Merge 連続するキー範囲を持ち、かつコールド状態や低負荷な状態になってい る複数のRangePartitionを結合。結合を使用することで、境界内の RangePartitionの数とスタンプ内の PS 数を調整する kyrt @takekazuomi 322016/10/1
- 33. 負荷状況の確認、heartbeats PMは、各 RangePartitionの負荷を追跡 PM は各 PS とのheartbeat を保持 テレメトリは、 heart beatの応答 A) transactions/second B) average pending transaction count C) throttling rate D) CPU usage E) network usage F) request latency G) RangePartition のデータ サイズ kyrt @takekazuomi 332016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat
- 34. Load Balance PS に過負荷が発生して いるが、個々の RangePartitionごとの負 荷は正常である場合 PM はその PS から RangePartitionを選択し、 より負荷の少ない PS に 再割り当てする kyrt @takekazuomi 342016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat R4をPS2へ移動
- 35. Load Balance 操作 PM はオフロード コマンドを PS に送信 PSは、RangePartition の現在のチェックポイントを書き込ん だ後にオフロードを実行。 完了後、PS はPMにオフロード完了を通知 PM はRangePartitionを新しい PS に割り当て、Partition map table を更新 新しい PS がRangePartitionを読み込み、トラフィック処理を 開始 kyrt @takekazuomi 352016/10/1
- 36. Split kyrt @takekazuomi 362016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat R4’ R4を分割R4’をPS2へ 指標に対して高すぎる負荷の RangePartition を PM が発見 PM はパーティションの分割を 決定し、split を実行するコマン ドを PS に送信
- 37. Split 操作 RangePartitionの分割するのは、負荷が高い場合と、行データ ストリームまたは BLOB データ ストリームのサイズが大きい場合 状況を特定した PM は、該当のRangePartitionを処理する PS に対して負荷ま たはサイズに基づく分割を指示 パーティションの分割位置を示すキー (アカウント名, パーティション名) は PS が 選択 サイズに基づく分割の場合、RangePartitionは、パーティション内のオブジェクト の合計サイズと、パーティションのサイズが約半分になる位置の分割キー値を保 持し、PS はこれらを使用して分割位置を示すキーを選択 負荷に基づく分割の場合、PS は Adaptive Range Profiling ※を使用してキー を選択し分割 kyrt @takekazuomi 372016/10/1 ※ S. Mysore, B. Agrawal, T. Sherwood, N. Shrivastava, and S. Suri, "Profiling over Adaptive Ranges," in Symposium on Code Generation and Optimization, 2006.
- 38. RangePartition (B) split (C、D) 1. PM が、PS に対して、B を C と D に分割するよう指示 2. B を所有する PS は、B をチェックポイント。以下のステップ 3 の実行中はトラフィックの処 理を一時的に停止 3. PS は、特別なストリーム操作 “MultiModify” を使用して、B の各ストリーム (メタデータ、コ ミット ログ、データ) を基に、C および D 用の新しいストリームのセットを作成。ストリームは 単なるエクステントへのポインターのリストなので、処理はすぐに完了する。その後、PS は、 C および D の新しいパーティション キー範囲を、それぞれのメタデータ ストリームに追加 する 4. PS は、2 つの新しいパーティション C および D をそれぞれ分離したRangePartition範囲 で扱い、これらに対する要求の処理を開始する 5. PS は、分割の完了を PM に通知。PM は パーティション マップ テーブルとメタデータ情報 を適切に更新した後、分割されたパーティションのうち 1 つを別の PS に移動する kyrt @takekazuomi 382016/10/1
- 39. Merge操作 1. PM は、同じ PS によって処理されるよう C と D を移動し、その PS に対して、C と D を結 合するよう指示 2. PS は、C と D をチェックポイント。以下３ステップの実行中はこれらに対するトラフィックを 一時的に停止 3. PS は、”MultiModify” ストリーム コマンドを使用して、E 用の新しいコミット ログおよびデー タ ストリームを作成する。（C とD のストリームのすべてのエクステントを連結） 4. PS は、E 用のメタデータ ストリームを作成します。このメタデータ ストリームには、新しいコ ミット ログおよびデータ ストリームの名前、結合された E のキー範囲、C と D から継承さ れた E のコミット ログにおける各コミット ログ領域の最初と最後を示すポインター (エクステ ント + オフセット)、そして、E のデータ ストリームのデータ インデックスのルートを含む 5. 5. この時点で、E 用の新しいメタデータ ストリームが正常に読み込まれ、PS は、新たに結 合された E というRangePartitionの処理を開始 6. 6. PM は、結合を反映するよう、パーティション マップ テーブルとメタデータ情報を更新す る kyrt @takekazuomi 392016/10/1
- 40. RangePartition変更のコスト WASでは、 RangePartitionの変更は、Index 情報の切り替えだけで、実データの移動は発 生しない Stream layer 内では、extent（実データ）の移 動を伴わずにStreamの分割、結合出来る Extentに対して、複数のStreamからリンクで きるのでSplitしてもExtentの移動は必要ない kyrt @takekazuomi 402016/10/1
- 41. kyrt @takekazuomi 412016/10/1 Massive Scale Out & Auto Load Balancing Index Layer Distributed Replication Layer Partition Layer Stream Layer PS PS1 PS PS PS2 PS PS PSは、すべてのStreamにアクセス可
- 42. Stream Layer Concepts kyrt @takekazuomi 422016/10/1 Extent • リプリケーション単位 • blockのシーケンス • 最大サイズあり( 1GB) • Sealed/unsealed Block • read/writeの最小単位 • Checksum • 最大N byte(4MB) Stream • 階層的なnamespace • extentのordered list • Append/Concatenate pointer of extent E1 B1 1 B1 2 ・・・ B1 x extent E1 - sealed pointer of extent E2 B2 1 B2 2 ・・・ B2 x extent E2 - sealed pointer of extent E3 B3 1 B3 2 ・・・ B3 x extent E1 - sealed pointer of extent E4 B4 1 B4 2 B4 3 extent E1 - unsealed stream //bar/kinmugi.data
- 44. Range vs. Hash Partition Partition layerのOTには、ハッシュベースのインデックス作成 キーのハッシュ値ではなく範囲ベースのパーティション分割/イン デックス作成を使用 範囲ベースのパーティション分割の場合、アカウントのオブジェクト がRangePartitionのセットの中にまとめて格納されるため、テナン トの毎にパフォーマンス分離できる（ストレージアカウント単位での パフォーマンスターゲットがあります） アカウント内のオブジェクトの列挙が効率化される ハッシュベースの方法ではサーバー間の負荷分散を簡素化でき ますが、オブジェクトのローカリティが失われ、分離と効率的な列 挙を実現できないという欠点がある kyrt @takekazuomi 442016/10/1
- 45. Range vs. Hash Partition（２） RangePartitionが不利になるのは、アクセスが一部のRangeに集 中する場合 例えば、ユーザーが、テーブルのキー範囲の最後にすべてのデー タを書き込もうとする場合 (例: 2011-06-30:12:00:00、2011-06- 30:12:00:02、2011-06:30-12:00:10 のキーを順番に挿入)や、 Blobのファイル名が時系列で変わるような命名規則になっている 場合 この場合、特定の（最後のRangePartition）に、すべての書き込み が送られることになり、WAS のシステムが提供するパーティション 分割と負荷分散を活用できない この関連の課題は、 ログ系のデータを書くときに発生する kyrt @takekazuomi 452016/10/1
- 46. コンピューティングリソースとストレージの分離 Windows Azure では、ユーザーの VM ベースのコンピューティングをス トレージから分離している ユーザー サービスのコードを実行するノードと、それらにストレージを提 供するノードが切り離され、ネットワーク経由で接続している メリット ⇨ コンピューティングのコア部分とストレージをそれぞれ個別にスケールアウト して、各データ センターにおけるユーザーの需要に対応できる ⇨ コンピューティングとストレージの間に独立したレイヤーが確保され、マルチ テナント運用にあたり両方のシステムの負荷分散を個別に実行できる デメリット ⇨ コンピューティングのコア部分とストレージの接続がネットワーク経由なので、 レイテンシが大きい。（帯域はそれなりになりつつあるが） kyrt @takekazuomi 462016/10/1
Hinweis der Redaktion
- 2016/5/21 R.1.0
- 設計時の最初のデザインゴール、Azure の開発初期では、Bingのストレージ周りを基盤にしてスタートした。 WAS の開発においては、Cosmos を基盤に、パーティション レイヤーとの連携による一貫性実現のメカニズム、ストリーム操作によるパーティション分割/結合の効率化、ジャーナリング、イレージャー コーディング、スピンドルのスタベーション回避、読み取りの負荷分散、その他のさまざまな強化機能を追加して、独自のストリーム レイヤーを構築しました。
- 数は古い
- Storageはがどうなっているのかは未公開なのでわからないが
- Partition Layer ではとても面白い課題に取り組んでいます どのオブジェクトが何処にあるのかを管理するてーブルが
- コンポーネントをざっくり説明して、データモデル、そのあと詳細に入ります。
- 、それぞれに固定スキーマがある。Blob、Entity、Message のTableの主キーは、アカウント名、パーティション名、およびオブジェクト名の 3 つのプロパティで、 OT のインデックス作成と並べ替えは、この 3 つのプロパティに基づく
- Hbaseで言うと、memory table が、memstore、Commit log , sstable が、row data stream, blob data stream になる
- PMは、PSの負荷状況を把握している。
- MultiModifyの詳細は分からないけど、Extent listを操作してStreamを作成するコマンドらしい