Azure Storage Partition Internals

Azure Storage Partition Internals

Takekazu Omi [email protected]

2016/10/1 R.1.0.NET Fringe Japan 2016

自己紹介近江　武一JAZUG Azure Storage 担当（自称）Microsoft MVP for Azure http://www.slideshare.net/takekazuomi

kyrt @takekazuomi 2

kyrt.in

github.com/takekazuomi

white paper

監訳

2016/10/1

http://www.slideshare.net/takekazuomi

3

Deep ・・・　・・・・・・ Drive 　・・・ Zzzzzzz

kyrt @takekazuomi2016/10/1

4

Partition は、スケーラビリティ対策の基本であり鬼門Range Partition では、 Partition Key に悩み水平分割（ Sharding ）と聞くと、ムムと思いPartition リバランス、 Split, Merge とか聞くと、リソースの心配しか出てこないそんな人々に、 Azure Storage の Partition の話を


5

元ネタWindows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency

23rd ACM Symposium on Operating Systems Principles で、 2011 年に公開翻訳： Windows Azure ストレージ: 高可用性と強い一貫を両立するクラウドストレージサービス


http://download.microsoft.com/download/C/0/2/C02C4D26-0472-4688-AC13-199EA321135E/23rdACM_SOSP_WindowsAzureStorage_201110_jpn.pdf





6

Design GoalsHighly Available with Strong Consistency

⇨ 障害時やネットワークパーテーショニング時にもデータアクセスを提供Durability

⇨ データセンター内、あるいは DC に跨ったリプリケーションScalability

⇨ Exabyte 以上へのスケール⇨ 世界中のデータへのグローバルなネームスペースでのアクセス⇨ トラフィックに応じた自動的なロードバランシング


7

Azure Storage アーキテクチャ概要


Storage Stamp

LB

Front-Ends

Partition Layer

Stream Layerintra-stamp replication

Storage Location Service

Storage Stamp

LB

Front-Ends

Partition Layer

Stream Layerintra-stamp replication

Inter-stamp replication

8

Storage Stamp

Storage Stamp は、複数の storage node が配置された N 個のラックで構成されるクラスター各ラックがネットワークと電源が冗長化された、個別の障害ドメインクラスターは通常、大容量のストレージノード

18 台をそれぞれ含むラック 10 ～ 20 個から構成（ 2011 年時点）kyrt @takekazuomi2016/10/1

9

ラックってどんな感じ？


Storage はがどうなっているのかは未公開なのでわからないが・・・・

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/SpecsAndDesigns


11kyrt @takekazuomi2016/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 例↓


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

14

Stream Layerappend only な distributed file system全てのデータは、 Stream Layer に保存Stream は、 extents のリストで構extents は、 3 重に保存


ExtentsSM

SM SM

Extents Extents

Extents ExtentsExtents Extents

Paxos

15

Partition Layer 高レベルなデータ抽象化 (BLOB 、テーブル、キュー ) オブジェクトに対するトランザクションと一貫性の確保 Stream layer へのオブジェクトデータの保存スケーラブルなインデックス（ stream layer 内の場所を保持） stamp 間のリプリケーション


PartitionServer

PartitionServer

PartitionServer

PartitionServer

LockService

PM

16

Storage Stamp Architecture


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

PSPS PS PS

PS

PSPS

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 @takekazuomi2016/10/1

18

ざっくり言うと実データは、 Stream layer に保存Stream layer の何処に Object があるかの

Index を Partition layer で保持FE layer は、 Object を操作するリクエストの受け口それぞれのレイヤーがクラスター構成


19

Partition Layer

2016/10/1 kyrt @takekazuomi

20

課題膨大な数のパーテーションをどう扱うか

⇨stamp 内には数千億規模のパーテーションを収容⇨大きく変わるトラフィックパターンにどのように対応するか


kyrt @takekazuomi 21

Partition layer architecture

2016/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

updateread

update leaseread/write

watch lease

assign partition

22

主要コンポーネントPM: Partition Manager

⇨OT のメンテナンスPS: Partition Server

⇨パーテーションの処理Lock Service

⇨パーテーション分割の調停ロック管理kyrt @takekazuomi2016/10/1

23

主要 Data modelOT: Object TableOT は、 Object の Stream layer 上の位置を保持する

index 、メタ情報数 PB まで拡張可OT は、トラフィック負荷に基づいて複数の

RangePartition に動的に分割される分割された OT には、それぞれ１つの Partition

Server が割当てられるkyrt @takekazuomi2016/10/1


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 にルーティングする

2016/10/1


PM: Partition Manager PM は、スタンプ内で OT を N 個の RangePartition に分割割り当て情報は partition map table に格納複数の RangePartition 間で重複が発生しないように調整 RangePartition が割り当てられた PS 間の負荷分散をする Stamp 内では、 PM のインスタンスは複数実行されており、ロックサービスでリースを取れた PM のインスタンスが partition layer を制御するアクティブな PM となる2016/10/1

26

PS: Partition Server PS は、 PM に割り当てられた RangePartition に対する要求を処理する。 PS は、パーティションのすべての永続状態をストリームに格納し、パーティション状態をメモリキャッシュに保持 RangePartition を処理する PS は１つだけ。 RangePartitionで、同時実行されるトランザクションの一貫性とシリアライズが可単一の PS は、異なる OT の複数の RangePartition を同時に処理可能。現在の WAS では、 PS により、常に平均 10 個の RangePartition が処理されている（ 2011 ）


27

account container blob

ssss sssss sssss

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

zzzzz zzzzz zzzzzz


lllll lllll lllllll

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

rrrrr rrrrrr rrrrrr

例



aaaa aaaa aaaa

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

・・・・・・

kkkk kkkk kkkk

Partition mapA-K : PS1K`-R: PS2R`-Z:PS3

PS1A-K : PS1

PS2K`-R: PS2

PS3R`-Z:PS3

Blob Index(RangePartition)Partition layer

FECache A-K : PS1 K`-R: PS2 R`-Z: PS3

Cache

28

OT の永続化2016/10/1 kyrt @takekazuomi

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 から読む


31

RangePartition の動的な変更2016/10/1 kyrt @takekazuomi


RangePartition の動的変更 Load Balanceトラフィックが集中している PS を特定し、 RangePartition を負荷の少ない PS に移動 Split負荷が集中している RangePartition を特定して 2 つ以上のより小さな分離した RangePartition に分割し、 2 つ以上の PS 間で負荷を分散 (再割り当て ) Merge連続するキー範囲を持ち、かつコールド状態や低負荷な状態になっている複数の RangePartition を結合。結合を使用することで、境界内の RangePartition の数とスタンプ内の PS 数を調整する

2016/10/1

33

負荷状況の確認、 heartbeats PMは、各 RangePartition の負荷を追跡 PM は各 PS とのheartbeat を保持テレメトリは、 heart beat の応答A) transactions/secondB) average pending transaction countC) throttling rateD) CPU usageE) network usageF) request latencyG) RangePartition のデータサイズ


PM

PS1

R1 R3 R4 PS2

R2 R5 R8

PS3

R6 R7 R9

heartbeat

34

Load Balance PS に過負荷が発生しているが、個々の

RangePartitionごとの負荷は正常である場合 PM はその PS から

RangePartition を選択し、より負荷の少ない PS に再割り当てするkyrt @takekazuomi2016/10/1

PM

PS1

R1 R3 R4 PS2

R2 R5 R8

PS3

R6 R7 R9

heartbeatR4 を PS2 へ移動

35

Load Balance 操作 PM はオフロードコマンドを PS に送信 PS は、 RangePartition の現在のチェックポイントを書き込んだ後にオフロードを実行。完了後、 PS は PM にオフロード完了を通知 PM は RangePartition を新しい PS に割り当て、 Partition map table を更新新しい PS が RangePartition を読み込み、トラフィック処理を開始


36

Split


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 ※ を使用してキーを選択し分割


※ S. Mysore, B. Agrawal, T. Sherwood, N. Shrivastava, and S.Suri, "Profiling over Adaptive Ranges," in Symposium onCode 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 に移動する



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 は、結合を反映するよう、パーティションマップテーブルとメタデータ情報を更新する2016/10/1

40

RangePartition 変更のコストWAS では、 RangePartition の変更は、 Index情報の切り替えだけで、実データの移動は発生しないStream layer 内では、 extent （実データ）の移動を伴わずに Stream の分割、結合出来るExtent に対して、複数の Stream からリンクできるので Split しても Extent の移動は必要ない



Massive Scale Out & Auto Load Balancing Index Layer

Distributed Replication Layer

Partition Layer

Stream Layer

PSPS1 PS PS

PS2

PSPS

PS は、すべての Stream にアクセス可

42

Stream Layer Concepts


Extent• リプリケーション単位• block のシーケンス• 最大サイズあり ( 1GB)• Sealed/unsealed

Block• read/write の最小単位• Checksum• 最大 N byte(4MB)

Stream• 階層的な namespace• extent の ordered list• Append/Concatenate

pointer of extent E1

B11

B12

・・・B1x

extent E1 - sealed


B21

B22

・・・B2x

extent E2 - sealed


B31

B32

・・・B3x

extent E1 - sealed


B41

B42

B43

extent E1 - unsealed

stream //bar/kinmugi.data

43

おまけ2016/10/1 kyrt @takekazuomi

44

Range vs. Hash Partition Partition layer の OT には、ハッシュベースのインデックス作成キーのハッシュ値ではなく範囲ベースのパーティション分割 / インデックス作成を使用範囲ベースのパーティション分割の場合、アカウントのオブジェクトが RangePartition のセットの中にまとめて格納されるため、テナントの毎にパフォーマンス分離できる（ストレージアカウント単位でのパフォーマンスターゲットがあります）アカウント内のオブジェクトの列挙が効率化されるハッシュベースの方法ではサーバー間の負荷分散を簡素化できますが、オブジェクトのローカリティが失われ、分離と効率的な列挙を実現できないという欠点がある


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 のシステムが提供するパーティション分割と負荷分散を活用できないこの関連の課題は、ログ系のデータを書くときに発生する


46

コンピューティングリソースとストレージの分離 Windows Azure では、ユーザーの VM ベースのコンピューティングをストレージから分離しているユーザーサービスのコードを実行するノードと、それらにストレージを提供するノードが切り離され、ネットワーク経由で接続しているメリット

⇨ コンピューティングのコア部分とストレージをそれぞれ個別にスケールアウトして、各データセンターにおけるユーザーの需要に対応できる⇨ コンピューティングとストレージの間に独立したレイヤーが確保され、マルチテナント運用にあたり両方のシステムの負荷分散を個別に実行できる

デメリット⇨ コンピューティングのコア部分とストレージの接続がネットワーク経由なので、レイテンシが大きい。（帯域はそれなりになりつつあるが）



終

Azure Storage Partition Internals

Technology

Transcript of Azure Storage Partition Internals