2013年版の inside windows azure

2013年版のInside Windows Azure

Japan Windows Azure User Group

Microsoft MVP for Windows Azure

はるたま

http://twitter.com/harutama

自己紹介

2@harutama

本セッションのゴール

• Windows Azure の裏側がどんな仕組みで動いているのか、なんとなく理解する。

3

参考リソース

• Windows Azure Internalshttp://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B402

• Windows Azure Role Architecturehttp://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx

4

5

ところで

6

Windows Azureとして管理されてるコンピューティング

リソースってどのくらい？

7

People’s ears usually perk-up when they hear Windows Azure uses more server compute capacity than was used on the planet in 1999.

http://blogs.msdn.com/b/windowsazure/archive/2012/05/24/datacenter-expansion-and-capacity-planning.aspx

http://blogs.msdn.com/b/windowsazure/archive/2012/05/24/datacenter-expansion-and-capacity-planning.aspx

8

PC Watch 1999年10大ニュース

順位項目

1 AMD Athlon登場

2 プレイステーション2発表

3 10万円PC登場、大手メーカーまで波及

4 台湾大地震により、国内PC市場に大きな影響

5 Microsoftと司法省の裁判で、Microsoftに不利な事実認定下る

6 アップル、iMacのデザイン盗用で各社を提訴

7 SDRAM価格高騰、128MBで2万円を越える

8 Pentium III登場、年末には0.18μmプロセスの新世代へ

9 Intel 820チップセット発表直前で延期

10 iモード携帯電話、急速に普及

9

http://pc.watch.impress.co.jp/docs/article/991224/best10.htm

http://pc.watch.impress.co.jp/docs/article/991224/best10.htm

Windows Azure の物理的なアーキテクチャ

10

物理アーキテクチャ(ざっくり)

11

トップオブラックスイッチ

物理マシン

データセンタールーター

ルーターとロードバランサ

データセンター

PDU

外側から見たラックの様子

12

ラックの中身

13

Gen.1 Network: DLA

14

ラック20本がひとかたまり

オーバーサブスクリプション120:1 データセンタールーター

ネットワークアーキテクチャ

• Gen.1は Tree ネットワーク

– 上の階層を経由する通信は転送速度が落ちる。

• トラフィックが集中してしまう

• ブロッキングの影響が大きくなってしまう

– 上の階層では IN/OUT のバランスが悪くなる。＝オーバーサブスクリプションが大きい

• Gen.2以降は Fat-Tree ネットワーク

– 基本的な考え方は “レイヤー間を全部つないじゃう”＝ノンブロッキングで通信可能＝多くの物理マシンを収容できる

15

参考

• 【Force10 Z9000とHPC】スケーラブル10GbEネットワークの設計 - パート１

– http://ja.community.dell.com/techcenter/b/weblog/archive/2012/08/24/force10-z9000-hpc-10gbe.aspx

• 【Force10 Z9000とHPC】スケーラブル10GbEネットワークの設計 - パート2

– http://ja.community.dell.com/techcenter/b/weblog/archive/2012/08/27/force10-z9000-hpc-10gbe-2.aspx

• ビジネス向けIBネットワークを考える～HPCクラスタでの経験を踏まえて～

– http://www.slideshare.net/naotomatsumoto/ib-hpc

16

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/08/24/force10-z9000-hpc-10gbe.aspx

http://ja.community.dell.com/techcenter/b/weblog/archive/2012/08/27/force10-z9000-hpc-10gbe-2.aspx

http://www.slideshare.net/naotomatsumoto/ib-hpc

ボーダーリーフ

スパイン

Gen.2 Network: Quantum10

17

コンピュートラック 80本 7200ノードストレージラック 20本 720ノード

・・・・・・・・・・・・・・・・・・

クラスタースパイン

データセンタースパインセット2

クラスタースパイン

データセンタースパインセット1

ボーダーリーフ

Gen.3 Network: Quantum10v2

18

コンピュートクラスター 900ノードストレージクラスター 720ノード

・・・・・・・・・・・・・・・・・・

本当のところは…

19

前の図では全部同じ太さの線で機器をつないでいますが、実際にはちょっと違ったりします。

32ポートだとして

8ポート＝1

24ポート＝3

Windows Azure の論理的なアーキテクチャ

20

論理アーキテクチャ• データセンター内の物理マシンは「クラスター」という

単位で分割されている。

– 1つのクラスタは約1000台の物理マシンで構成される

– 不具合の影響がクラスター内で閉じ込められるような設計

• 各クラスターは「ファブリックコントローラー(FC)」によって管理されている。

21

クラスター

ファブリックコントローラー


… …

クラスターの内部構造とファブリックコントローラー

22

ラック内部

ラック内にある1台の物理マシンはファブリックコントローラー用に予約される

ラック内部

ラック内部

クラスター内にある1つのファブリックコントローラーは

マスターとして動作する

他のファブリックコントローラーとは

マスター経由で状態を同期している

ファブリックコントローラーの役目

• データセンターにおけるカーネルの役割

– データセンターのハードウエア管理

– 動作しているサービスの管理

23

物理マシン

OfficeSQL

Server


IaaSPaaS

AzureDatabase

ファブリックコントローラーの仕事

• リソースの割り当て

– 新しい仮想マシンの作成（もちろん効率的に）

– 仮想マシンのスケールアップ・スケールアウトの対応

• リソースのプロビジョニング

– 物理マシンが故障した際は健全なマシンに移動させる

• サービスのライフサイクル管理

– アプリケーションのアップデート

– ゲストOSの自動アップデート

• サービスのヘルスチェック

– アプリケーションの死活監視

– ゲストOSの状態管理

24

起動の仕組み

• ユーティリティファブリックコントローラーにより起動される。

– ファブリックコントローラーの複製元

– アップデートの際にも使用される

• ユーティリティファブリックコントローラーは各ファブリックコントローラーのFeed (Datacenter.xml)を購読している。

– 各サーバーのIPアドレス

– サービスに割り当てるためにプールされたIP

– ネットワーク機器やPDU(Power Distribution Unit)のIPアドレス

25

ファブリックコントローラーの中身

• 仮想マシンを作成するための仕組みを持っている

– 各種のイメージファイル

• 物理マシンのメンテナンス用OS

• ホスト用OS

• ロールインスタンス用OS

– 配布するための仕組み

• PXEサーバー

• Windows 展開サービス(Windows Deployment Services)

26


メンテOS

ホストOS

ロールOS

Windows展開サービス

PXE サーバー

クラスター

3種類の物理マシン

27

ラック内部

ラック内部

ラック内部

レプリカファブリック

コントローラー

プライマリーファブリック

コントローラー

ノードorブレード（意味的には同じもの）

ノードの中身• ノード上では、ホストVM(1個)とアプリVM(n個)が

動作している。

• アプリVMとホストVMは、エージェント同士が通信する。

• ファブリックコントローラーには、ホストエージェントからアプリケーションVMの情報が伝えられる。

28

ノード


ハイパーバイザー

ホストOS

アプリVM

ホストエージェント

ゲストエージェント

ノードの準備が完了するまで

29

(1)ノードのブート

• ノードに電源が投入されると、ファブリックコントローラーが持っているメンテナンスOSでPXEブートされる。

30

ノードファブリックコントローラー

メンテOS

ホストOS

ロールOS


PXE サーバー

エージェント

メンテナンスOS

(2)ホストOSのインストール

• エージェントはホストOSをインストールする

– ノードが持つ物理ディスクをフォーマット

– ファブリックコントローラーのWindows 展開サービスからインストールされる

31


メンテOS

ホストOS

ロールOS


PXE サーバー

エージェント

メンテナンスOS

(3)sysprepの実行

• ノードが再起動してホストOSがブートされる。

• sysprepコマンドを実行して新しいSIDを作成。その後、再び再起動。

32


メンテOS

ホストOS

ロールOS


PXE サーバーハイパーバイザー

ホストOS

sysprep/specialize

(4)準備完了！

• ホストOS内で動作しているホストエージェントがファブリックコントローラーとの通信を開始。

33



メンテOS

ホストOS

ロールOS


PXE サーバー

ホストOS


(5)その後

• 各ノードが持っているイメージリポジトリに、ファブリックコントローラーが持っているOSイメージを配布する。

– 各種ロールのOSイメージやzipファイルなど

34



メンテOS

ホストOS

ロールOS


PXE サーバー

ホストOS


外から見たWindows Azure

35

RDFE


外から見たWindows Azure

36


管理ポータルWindows Azure

PowerShell Cmdlets


…

RDFEって何？

• RedDog Front End の略称

– Windows Azureに対するAPIをインターネットに公開しているフロントエンド

– ユーザからのすべてのリクエストはRDFEを通る

• Red Dog って何？

– Windows Azureがまだ開発中だった頃のコードネーム

– ちょっと間違えていたらPink Poodleになっていたhttp://japan.zdnet.com/cio/sp_07microsoft/20384470/

37

Pink Poodle? なにそれ?

38

RDFEの役割• Windows Azureのフロントエンドとしての役目

– サブスクリプションの管理

– 課金のカウント

– 各種サービスの管理

• ストレージとコンピュートのインスタンスを効率良く運用する

– データセンターリージョンの決定

– アフィニティグループの考慮

– データセンターのVirtual IPやノードの状況も考えつつ

39

Cloud Services へのデプロイ

40

(1)ユーザーからの指示

• 新しいパッケージをデプロイする際、クライアントから.csdefファイルがRDFEに対してアップロードされる。

41

RDFE

クライアントノード



ホストOS


.csdefファイル

(2)クラスターの選択

• RDFEは適切な状態にあるデータセンター内のクラスターを管理しているファブリックコントローラーを選択する。

– 指定されたリージョンのデータセンターの中で、クラスターの負荷状況やIPの利用状況などなどを考慮する

42

RDFE

クライアントノード



ホストOS


.csdefファイル

(3)ノードの選択

• ファブリックコントローラーはアプリケーションが動作するのに適切なノードを選択する。

– アプリケーションが要求するインスタンスのサイズや数を考慮

43

RDFE

ノード



ホストOS


クライアント

(4)VMの作成• アプリケーションが動作する仮想マシンを作成する。

これが最終的にロールインスタンスとなる。

– VMの元となるOSイメージ（Dドライブ）はホストにあるイメージリポジトリ内にある。

– ローカルディスク領域（Cドライブ）とロールが配置される領域（EもしくはFドライブ）は動的にイメージが生成される。

44

RDFE

ノード



ホストOS

アプリVM


クライアント

(5)内部通信の確立• エージェントの間での通信を確立させる。

このとき通信を保護するための転送証明書をゲスト側で作成し、公開鍵だけをホスト側に送る。

• エージェント間通信が確立すると、ホストエージェントはゲストエージェントのハートビート監視を開始する。

45

ノード



ホストOS

アプリVM



秘密鍵

公開鍵

(6)外部通信の設定

• 仮想マシンのネットワークを設定する

– 外部につながるDynamic IPを割り当てる

– 内部のVirtual IPとポートを設定し、外部のDynamic IPを紐付ける

– 仮想マシン間の通信にパケットフィルターを適用

– 外部と内部をつなぐロードバランサーの設定を行う

46

ノード



ホストOS

アプリVM



ルーター

ロードバランサー

サービスの監視

• ファブリックコントローラーは、ソフト・ハードの監視によって、サービスの可用性を管理する。

– 基本的にハートビートを監視

– 影響のあるノードは自動的に修復される

47

問題の種類検出の方法対処方法

ロールインスタンスのクラッシュ

ファブリックコントローラーがゲストエージェント経由で監視

・ロールを再起動

ゲストVMやゲストエージェントのクラッシュ

ホストエージェントがファブリックコントローラーにハートビートがなくなったことを警告

・ロールの再起動や、ゲストVMの再起動

ホストOSやホストエージェントのクラッシュ

ファブリックコントローラーがホストエージェントのハートビートを監視

・ロールの回復を試みる・他ノードにロールをマイグレート

ノードのハードウエア障害

ホストエージェントがファブリックコントローラーに警告

・他ノードにロールをマイグレート・ノードに対して“out for repair”とマーキング


48

割り当てられる IP アドレス

• パブリック仮想 IP アドレス＝ Virtual IP ＝ VIP– インターネット側からアクセスする

際の IP アドレス。

• 内部 IP アドレス＝ Dynamic IP ＝ DIP– Windows Azure の内部で割り当て

られた IP アドレス。

– 内部 IP アドレスはWindows Azureのソフトウエアロードバランサーで管理がされる。

49

絵で描くとこんな感じ

• ロードバランサーを経由すると0.5msec程度の遅延が入る。

• Windows Azure のロードバランサーはソフトウエアです。ハードウエアではありません。

50

インスタンス010.2.3.4（内部IP）

インスタンス110.2.3.5（内部IP）


65.123.44.22（仮想IP）

インターネット

0.5msec 程度のレイテンシー

全体はこんな感じ

51


テナントマネージャー

ネットワークマネージャー

ソフトウエアロードバランサーマネージャーロール

ソフトウエアロードバランサーマネージャー

ダイナミックIP ヘルスモニター

ノード


ホストOS

アプリVM



MUX ロール

ルートマネージャー

MUX エージェント

MUX ドライバー

仮想スイッチ

(1)アプリのデプロイ開始

52







ファブリックコントローラーがアプリケーションをデプロイ

↓ファブリックコントローラーが

仮想IPアドレスを払い出す↓

ファブリックコントローラーのテナントマネージャー

↓ネットワークマネージャー

↓ソフトウエアロードバランサー

マネージャーに仮想IPが伝えられる

(2)アプリVMの作成

53







ノード


ホストOS

アプリVM



アプリVMの作成が完了すると、ホストエージェントのソフトウエアロードバランサーホストプラグインが、ソフトウエアロードバランサーマネージャーにIPを問い合わせて、ノードの仮想スイッチを構成する。

仮想スイッチ

(3)モニタリングの開始

54




ノード


ホストOS

アプリVM



MUX ロール


MUX エージェントMUX ドライバー

アプリVMの監視対象となるポートに対してのモニタリングをヘルスモニターが開始する。

仮想スイッチ

(4)MUXロールの構成

55




ノード


ホストOS

アプリVM



MUX ロール



MUX ロールに対して、仮想IPアドレスと内部IPアドレスの関係を通知。これをもとにして、エージェントとドライバの動作を変更する。

仮想スイッチ

(5)物理ネットワークの構成

56

ノード


ホストOS

アプリVM



MUX ロール



物理ネットワークデバイス

ルートマネージャーが物理ネットワークデバイスの構成を変更して、仮想IPアドレスに対する外部からのパケットのルーティングを開始。


仮想スイッチ

(6)これで完成

57

ノード


ホストOS

アプリVM



MUX ロール



物理ネットワークデバイス


仮想スイッチ

こんな感じでインターネットからWindows Azure の内部にパケットが流れ始める。

MS社内用ツールで見ると…

58

59

60

61

ちょっと寄り道

ふむ…

62

ほぅ…

63

64

65

Let’s dream and then let’s build.- Ray Ozzie

はるたま (@harutama)http://twitter.com/harutama

Documents

2013年版の inside windows azure